ee579u/12 #1 spring 2004 © 2000-2004, richard a. stanley ee579u information systems security and...

Spring 2004© 2000-2004, Richard A. Stanley

EE579U/12 #1

EE579UInformation Systems Security

and Management12: Planning for Success –

Answering the Difficult Questions

Professor Richard A. Stanley


EE579U/12 #2

Overview of Today’s Class

• Project scheduling

• Review of last class

• Which O/S to choose?

• What about new regulations?

• A review of auditing


EE579U/12 #3

Last time…

• Business continuity planning is critical to the continued existence and functioning of any business in the face of unexpected events, man-made or natural

• It requires attention to detail, broad view of the business, and buy-in from above

• Planning requires facing some hard issues, and making public things that might otherwise be kept very secret in normal circumstances


EE579U/12 #4

Is WINDOWS more secure than UNIX, or vice-versa?

“It all depends”


EE579U/12 #5

How buggy is UNIX?

• According to earthweb.com, the majority of “visible” attacks occur on Windows-based operating systems

• However, there are also vulnerabilities with Unix, as anyone who has been bitten by things such as the sendmail buffer overflow will attest

• Steven Sundermeier, a vice president at Central Command, an anti-virus company based in Medina, Ohio, states that out of 85,000 documented bugs only 200 are Unix related.


EE579U/12 #6

How buggy is WINDOWS?

• If it appears that the majority of “visible” attacks occur on Windows-based operating systems, we could conclude that this might be true because the majority of computers used by end-users are Windows-based

• Steven Sundermeier, cited previously, also states that out of 85,000 documented bugs about 65,000 to 70,000 are Windows-related

• Are these “statistics” useful for planning secure systems?


EE579U/12 #7

Common Vulnerabilities & Exposures

• CVE was developed and is maintained by The MITRE Corporation (http://cve.mitre.org)

• CVE is a list of standardized names for vulnerabilities and other information security exposures

• CVE aims to standardize the names for all publicly known vulnerabilities and security exposures

• The idea is not to provide a hacking encyclopedia, but to have one name for one vulnerability


EE579U/12 #8

Operating System Statistics

• Total unique entries

• Total entries referencing “windows”, “microsoft”, or “iis”

• Total entries referencing “unix”, “redhat”, “bsd”, ”irix”, ”aix”, ”sun”, “sgi”, “suse”, “debian”, “hpux”, “vax”

• Others

• 2,572

• 554

• 1296

• 725


EE579U/12 #9

Buffer Overflow Statistics from CVE

• Total unique “buffer overflow” entries

• Total entries referencing “windows”, “microsoft”, or “iis”

• Total entries referencing “unix”, “redhat”, “bsd”, ”irix”, ”aix”, ”sun”, “sgi”, “suse”, “debian”, “hpux”, “vax”

• Others

• 537

• 89

• 383

• 65


EE579U/12 #10

So How’d We Get the Stats?

• Download the CVE database from CVE in CSV format to a UNIX system. [http://www.cve.mitre.org/cve/downloads/full-cve.csv]

• Using the “grep” command search on a specific word, such as “buffer overflow”. [e.g. ‘grep -i "buffer overflow" full-cve.csv’]

• The results of the grep are ”piped” in the UNIX word-count program. [e.g. ‘grep -i "buffer overflow" full-cve.csv | wc’]

• This yields the number of lines where the word ”buffer overflow” appears in the .csv. Since each line of the csv files represents a complete record, there is no duplicate counting of lines.


EE579U/12 #11

Analysis?

• One source (earthweb.com) says that Windows by far is more vulnerable, and the other source (CVE) by analysis Unix is more vulnerable.

• Obviously, neither is secure and both have issues• You might want to choose the more authoritative

database (CVE) over the stats from a company that has a dog in the fight

• You might also want to count candidate vulnerabilities rather than only those that are voted on through the CVE process


EE579U/12 #12

How to Find Out If You Have Vulnerabilities?

• Use the OVAL (open vulnerability assessment language) tool, also from MITRE (http://oval.mitre.org)

• You could also use a scanner, but it’s best to use one that is CVE-compatible– ISS (http://www.iss.net/)– Retina, et al. (http://www.eeye.com/html/)– Nessus (http://www.nessus.org/)


EE579U/12 #13

Things to Think About

• Vulnerability analysis can lead to analysis paralysis – what you get may not be what you want

• There are new laws and regulations that also need your attention– GLB

– SOX

– HIPPA

– … etc.


EE579U/12 #14

What is Sarbanes-Oxley (a.k.a. SOX or Sarbox)?

• Named after authors – Rep. Michael Oxley

– Sen. Paul Sarbanes

• Passed the Congress nearly unanimously• Signed by President Bush on July 30, 2002• Compliance deadline

– June 15, 2004 for most larger public companies

– April 15, 2005 for small and foreign public companies


EE579U/12 #15

Scope of Sarbanes-Oxley?

• Amends the Securities and Exchange Act of 1933

• Sweeping changes across all public companies

• Act’s Goals:– Bolster public confidence in our capital markets– Prevent scandals


EE579U/12 #16

Why Sarbanes-Oxley?

• Forbes Scandal Report for 2001-2002– Reports 23 large corporate scandals from Jan of 2001 to

Sept of 2002

– Approximately $10 - $20 Billion in “losses”

• Scandals that caught the public eye– Enron

– Arthur Andersen

– WorldCom

– GlobalCrossing

And this is only the tip of the iceberg!


EE579U/12 #17

How Does Sarbanes-Oxley Work?

• To reach it’s goal of restoring public confidence, it tries to accomplish the goal through regulations, criminal prosecutions, and fines

• Affects ALL PUBLIC COMPANIES!– An important distinction, but may be blurred in

the future


EE579U/12 #18

Sarbanes-Oxley Titles I – IVhttp://news.findlaw.com/hdocs/docs/gwbush/sarbanesoxley072302.pdf

• Title I: Public Company Accounting Oversight Board

• Title II: Auditor Independence

• Title III: Corporate Responsibility– Section 302

• Title IV: Enhanced Financial disclosures– Section 404 and Section 409


EE579U/12 #19

Sarbanes-Oxley Titles V - IX

• Title V: Analyst conflicts of interest• Title VI: Commission Resources and

Authority• Title VII: Studies and Reports• Title VIII: Corporate and Criminal Fraud

Accountability• Title IX: White-Collar Crime Penalty

Enhancements


EE579U/12 #20

Sarbanes-Oxley Titles X - XI

• Title X: Corporate Tax Returns

• Title XI: Corporate Fraud and Accountability


EE579U/12 #21

What Does Sarbanes-Oxley Have to do with Information Assurance?

• Most organizations rely heavily on the use of technology for business with customers, partners and suppliers

• This reliance puts pressure on the CIO and CISO to give their Senior Executives greater assurance that their IT systems are secure and can be audited

• There is significant risk that companies will not be Sarbanes-Oxley compliant if the IT Systems fail a system audit


EE579U/12 #22

HIPAA

• HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 – “It is the purpose of this subtitle to improve the

Medicare program under title XVIII of the Social Security Act, the medicaid program under title XIX of such Act, and the efficiency and effectiveness of the health care system, by encouraging the development of a health information system through the establishment of standards and requirements for the electronic transmission of certain health information.”

– http://aspe.hhs.gov/admnsimp/pl104191.htm


EE579U/12 #23

HIPAA Worries

• If you handle health data, you need to understand and comply with HIPAA

• Don’t be too sure you do not handle such data—most employers do!

• Despite a lot of scare tactics, HIPAA is basically technology-neutral

• It is not policy-neutral!• Compliance is required now

– Which is why we have all been asked to sign for receipt of hospital & physician privacy policies recently


EE579U/12 #24

Privacy

• HIPAA, again• Privacy Act of 1974 (5 USC § 552)

• Privacy Protection Act of 1980 (42 USC § 2000aa)

• Non-U.S. privacy laws and regulations• Attention to privacy needs of non-citizens

– e.g. US VISIT

• Increasing needs for Privacy Impact Assessments on information systems


EE579U/12 #25

How to achieve compliance?

• Step 1. Choose or set up a policy

• Step 2. Identify the systems to be secured

• Step 3. Schedule or activate an audit

• Step 4. Run a report and assess the results

• Step 5. Comply with your policy

• Step 6. Do it again


EE579U/12 #26

Best Practices for Getting to Compliance

• Process and Procedure– ISO17799– COBiT/COSO– GAO

• System Best Practices– SANS– NIST– Microsoft


EE579U/12 #27

Getting and Staying Compliant

• Properly configure and patched systems are less vulnerable to attacks, reducing incident-response risks– CVE, OVAL, scanners, etc. help here

• Use Best Practices and enforce the Security Policy • Audit regularly to ensure continuous compliance

with Sarbanes-Oxley, HIPPA, etc.


EE579U/12 #28

What is Auditing

• Auditing is a post-facto technique for determining violations of security polices.

• Auditing and Security Polices can be considered two sides of a coin.

• Major role in the detection of security violations and post-mortem analysis.


EE579U/12 #29

What is Auditing (continued…)

• Auditing an Information system for security violation.

• Review of polices, standards, procedures, state/federal regulations against the existing operational standards and procedures to ensure compliance.

• Review of operating procedures to ensure business continuity.


EE579U/12 #30

Why Auditing

• Auditing helps in evaluating the compliance of current operating procedures/process with the documented procedures/process.

• Auditing identifies violation of security policy

• Auditing reveals potential threat/risks associated with the information system.


EE579U/12 #31

Types of Audit

Based on the person performing

1. Internal Audit – Audits performed by individuals inside the company

2. External Audit – Audits performed by external auditors

3. Regulatory Audit – Audits performed by Government Authorities


EE579U/12 #32

Types of Audit (continued…)

Based on Objective of Audit1. Compliance Audit – Checking the compliance of the

operating polices/procedures against documented polices/procedures

2. Platform Specific Audit – System Software, Network, Application Software and databases.

3. Technology Audit – Technology infrastructure implemented against security policy

4. Event Audit – Analyzing events from event log to ensure all activities meet the security policy


EE579U/12 #33

Anatomy of Auditing System

Three main components

1. Logger

2. Analyzer

3. Notifier


EE579U/12 #34

Logger

• Mechanism used to record information relating to the access/usage of the information system.

• Kind and quantity of information collected depends on the configuration of the system.

• Two methods– Binary logging– Plain-Text logging


EE579U/12 #35

Analyzer

• Takes the information collected from the logger and performs analysis on it.

• Analysis of the logs may result in events that might have violated the security policy of the system or not.

• Examples – Text processing tools can be used against the text-based logs (swatch) is a pattern matching tool used to analyze syslog.


EE579U/12 #36

Notifier

• Takes the information from the Analyzer and informs appropriate entities responsible for managing the system.

• Example – security violations determined from the analyzer can be send as an email to the system administrator responsible for maintaining the system.


EE579U/12 #37

Goal of Auditing System Design

• Let Ai be the set of possible actions on the

system and Pi be the set of constraints that

the system must meet in order to be secure, then the system should log all the actions Ai

that fail the constraint Pi


EE579U/12 #38

Logging sub-system design

• State-Based – Records information about the systems state. Analyzer detects invalid system state.– Design Issue – State should be recorded while the

system is at quiescent state.– Examples – ‘tripwire’

• Transition-Based – Records information about an action on a system– Design Issue – Current state should recorded– Examples – ‘tcp_wrappers’


EE579U/12 #39

Log Sanitization

• Mechanism by which certain information in the logs are hidden from the view of certain set of users who are not authorized to view the hidden information.

• Motivation –Confidentiality policy may prevent a set of users from viewing certain information stored in the logs.


EE579U/12 #40

Log Sanitization (continued…)

• Mathematical Definition– Let ‘U’ be a set of users. The policy ‘P’ defines

a set of information ‘C(U)’ that members of ‘U’ are not allowed to see. Then the log ‘L’ is sanitized with respect to ‘P’ and ‘U’ when all instances of information in ‘C(U)’ are deleted from ‘L’.


EE579U/12 #41


Realization of Log Sanitizer I

Information System Logging System

Sanitizer

Viewer


EE579U/12 #42


Realization of Log Sanitizer II

Information System Logging System

Sanitizer

Viewer

Confidential Logging

Authorized Viewer


EE579U/12 #43

Overview of ISO17799

• Provides guidelines for framing policies and procedures for a company.

• Defines Information Security• Need for Information Security• Process for establishing Security requirements• Guidelines in assessing risks and managing risks.• Very good starting point for developing policies

and procedures.


EE579U/12 #44

Table of Contents from ISO17799

a. INTRODUCTION

b. SCOPE

c. TERMS AND DEFINITIONS

d. SECURITY POLICY

e. ORGANIZATIONAL SECURITY

f. ASSET CLASSIFICATION AND CONTROL


EE579U/12 #45

Table of Contents from ISO17799

g) PERSONNEL SECURITY

h) PHYSICAL AND ENVIRONMENTAL SECURITY

i) COMMUNICATIONS AND OPERATIONS MANAGEMENT

j) ACCESS CONTROL

k) SYSTEMS DEVELOPMENT AND MAINTENANCE

l) BUSINESS CONTINUITY MANAGEMENT

m) COMPLIANCE


EE579U/12 #46

Compliance Audit

• Compliance with legal requirement– Objective is to avoid breach of any criminal or

civil law, regulations or contracts. Example – information system should ensure intellectual property rights, which includes copyrights, safeguarding organizational records, data protection, etc.


EE579U/12 #47

Review of Security Policy and Technical Compliance

• Regular review of information systems, system providers, owners of information and information assets, users and management should be done to ensure compliance against security policy of the company.

• Technical compliance involves checking IT systems to ensure hardware and software controls are properly implemented.


EE579U/12 #48

Audit Requirements

a. Audit requirements should be agreed with appropriate management.

b. The scope of the checks should be agreed and controlled.

c. The checks should be limited to read-only access to software and data.

d. Access other than read-only should only be allowed for isolated copies of system files, which should be erased when the audit is completed.

e. IT resources for performing the checks should be explicitly identified and made available.


EE579U/12 #49

Audit Requirements (continued..)

f. Requirements for special or additional processing should be identified and agreed.

g. All access should be monitored and logged to produce a reference trail.

h. All procedures, requirements and responsibilities should be documented.


EE579U/12 #50

AUDIT PLANNING (1/2)

• Audit objectives comply with auditing standards

• Audit Plan includes– List of personnel– Resources required– Schedule for the work – Procedure – Budget


EE579U/12 #51

AUDIT PLANNING (2/2)

• Materiality

• Risk Assessment

• Knowledge of the organization

• Policy review

• Planning Documentation

• Plan Endorsement and custody


EE579U/12 #52

PERFORMING AUDIT WORK

– SUPERVISION

• Supervision by the customers

– EVIDENCE

• Reliable, relevant, sufficient


EE579U/12 #53

AUDIT WORK – EVIDENCE (1/4)

• Procedure– Inquiry– Observation– Inspection– Confirmation– Performance– Monitoring

• This procedure can be applied manually or using computer assisted audit techniques or a combination of the two approaches


EE579U/12 #54


• Audit Sampling– Statistical Samplings method

• Random Sampling

• Systematic Sampling

– Non statistical sampling method• Haphazard Sampling

• Judgmental sampling

• Sample Evaluation


EE579U/12 #55


• Computer Assisted Audit Techniques– Assurance of the integrity, reliability, usefulness, and

security of the CAATs through appropriate planning, design, testing, processing

– CAATs are used to extract information for data analysis

– CAATs can be used to extract sensitive program/system information and production data

– Application Software Tracing and Mapping– The step-by-step CAATs process should be sufficiently

documented


EE579U/12 #56


• Use work of Other Auditors and Experts– Review Work papers– Review Reports

• IS auditor should perform sufficient audit work to confirm that the other auditor’s work was appropriately planned, supervised, documented and reviewed

• The IS auditor should perform sufficient reviews of the other auditor’s final reports.


EE579U/12 #57

REPORTING (1/2)

• Title

• Addressee

• Description on scope of audit

• Description of area of activity

• Audit plan

• Criteria used

• Procedure


EE579U/12 #58

REPORTING (2/2)

• CAATs used• Bunch of Legal statements

– Audit was conducted in accordance with Standards

• Conclusions and Recommendations• Auditor’s signature• Auditor’s Address• Date


EE579U/12 #59

FOLLOW-UP ACTIVITES

• Appropriate actions in timely manner• Evaluating Audit results

– Assess the severity of the findings– Deciding if external help is needed – Is a change to the security policy needed?– Rank problems: what to fix first; where to stop?– Match vulnerabilities and problems to legal liability

issues– Evaluate what, if any changes to security policy are

warranted based on findings


EE579U/12 #60

Applying ISO17799

• Gap analysis is normally performed to compare the company security polices and procedures against ISO17799.

• Similar approaches are used with other audit tools.


EE579U/12 #61

Summary

• Many important choices must be made in planning and securing an information system

• Most of these choices turn out to be non-technical, in the sense that they involve law and policy

• Applying law and policy without a technical understanding of the results is a fool’s errand

• The field changes constantly – you need to work to stay current

ee579u/12 #1 spring 2004 © 2000-2004, richard a. stanley ee579u information systems security and...

Documents

stanley slide

vulnerability slide

iis total entries

review of auditing slide

cve database

unix system

secure systems

operating systems