Download as pdf or txt
Download as pdf or txt
You are on page 1of 195

Cryptography and Network Security

Key Management
public-key encryption helps address key distribution problems have two aspects of this:
distribution of public keys use of public-key encryption to distribute secret keys

Distribution of Public Keys


can be considered as using one of:
public announcement publicly available directory public-key authority public-key certificates

Public Announcement
users distribute public keys to recipients or broadcast to community at large
eg. append PGP keys to email messages or post to news groups or email list

major weakness is forgery


anyone can create a key claiming to be someone else and broadcast it until forgery is discovered can masquerade as claimed user

Publicly Available Directory


can obtain greater security by registering keys with a public directory directory must be trusted with properties:
contains {name,public-key} entries participants register securely with directory participants can replace key at any time directory is periodically published directory can be accessed electronically

still vulnerable to tampering or forgery

Public-Key Authority
improve security by tightening control over distribution of keys from directory has properties of directory and requires users to know public key for the directory then users interact with directory to obtain any desired public key securely
does require real-time access to directory when keys are needed

Public-Key Authority

Public-Key Certificates
certificates allow key exchange without realtime access to public-key authority a certificate binds identity to public key
usually with other info such as period of validity, rights of use etc

with all contents signed by a trusted PublicKey or Certificate Authority (CA) can be verified by anyone who knows the public-key authorities public-key

Public-Key Certificates

Public-Key Distribution of Secret Keys


use previous methods to obtain public-key can use for secrecy or authentication but public-key algorithms are slow so usually want to use private-key encryption to protect message contents hence need a session key have several alternatives for negotiating a suitable session

Simple Secret Key Distribution


proposed by Merkle in 1979
A generates a new temporary public key pair A sends B the public key and their identity B generates a session key K sends it to A encrypted using the supplied public key A decrypts the session key and both use

problem is that an opponent can intercept and impersonate both halves of protocol

Public-Key Distribution of Secret Keys


if have securely exchanged public-keys:

Hybrid Key Distribution


retain use of private-key KDC shares secret master key with each user distributes session key using master key public-key used to distribute master keys
especially useful with widely distributed users

rationale
performance backward compatibility

Diffie-Hellman Key Exchange


first public-key type scheme proposed by Diffie & Hellman in 1976 along with the exposition of public key concepts
note: now know that Williamson (UK CESG) secretly proposed the concept in 1970

is a practical method for public exchange of a secret key used in a number of commercial products

Diffie-Hellman Key Exchange


a public-key distribution scheme
cannot be used to exchange an arbitrary message rather it can establish a common key known only to the two participants

value of key depends on the participants (and their private and public key information) based on exponentiation in a finite (Galois) field (modulo a prime or a polynomial) - easy security relies on the difficulty of computing discrete logarithms (similar to factoring) hard

Diffie-Hellman Setup
all users agree on global parameters:
large prime integer or polynomial q a being a primitive root mod q

each user (eg. A) generates their key


chooses a secret key (number): xA < q xA compute their public key: yA = a mod q

each user makes public that key yA

Diffie-Hellman Key Exchange


shared session key for users A & B is KAB:
KAB = a mod q xB = yA mod q (which B can compute) x = yB A mod q (which A can compute)
xA.xB

KAB is used as session key in private-key encryption scheme between Alice and Bob if Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys attacker needs an x, must solve discrete log

Diffie-Hellman Example
users Alice & Bob who wish to swap keys: agree on prime q=353 and a=3 select random secret keys:
A chooses xA=97, B chooses xB=233

compute respective public keys:


yA=3 mod 353 = 40 (Alice) 233 yB=3 mod 353 = 248 (Bob)
97

compute shared session key as:


KAB= yB A mod 353 = 248 = 160 x 233 KAB= yA B mod 353 = 40 = 160
x 97

(Alice) (Bob)

Key Exchange Protocols


users could create random private/public D-H keys each time they communicate users could create a known private/public D-H key and publish in a directory, then consulted and used to securely communicate with them both of these are vulnerable to a meet-in-theMiddle Attack authentication of the keys is needed

Security Management Practices

20

What Is Information Security


The quality or state of being secure to be free from danger

Security is achieved using several strategies simultaneously or used in combination with one another

Security is recognized as essential to protect vital processes and the systems that provide those processes Security is not something you buy, it is something you do

What Is Information Security


The architecture where an integrated combination of appliances, systems and solutions, software, alarms, and vulnerability scans working together

Monitored 24x7
Having People, Processes, Technology, policies, procedures, Security is for PPT and not only for appliances or devices

People Who we are


People who use or interact with the Information include:

Share Holders / Owners Management Employees Business Partners Service providers Contractors Customers / Clients Regulators etc

Process what we do
The processes refer to "work practices" or workflow. Processes are the repeatable steps to accomplish business objectives. Typical process in our IT Infrastructure could include
Helpdesk / Service management Incident Reporting and Management Change Requests process Request fulfillment Access management Identity management Service Level / Third-party Services Management IT procurement process etc...

Technology what we use to improve what we do


Network Infrastructure:
Cabling, Data/Voice Networks and equipment Telecommunications services (PABX), including VoIP services , ISDN , Video Conferencing Server computers and associated storage devices Operating software for server computers Communications equipment and related hardware. Intranet and Internet connections VPNs and Virtual environments Remote access services Wireless connectivity

Technology what we use to improve what we do


Application software:

Finance and assets systems, including Accounting packages, Inventory management, HR systems, Assessment and reporting systems Software as a service (Sass) - instead of software as a packaged or custom-made product. Etc..

Physical Security components:


CCTV Cameras Clock in systems / Biometrics Environmental management Systems: Humidity Control, Ventilation , Air Conditioning, Fire Control systems Electricity / Power backup

Access devices:
Desktop computers Laptops, ultra-mobile laptops and PDAs Thin client computing. Digital cameras, Printers, Scanners, Photocopier etc.

INFORMATION SECURITY

1. 2. 3. 4. 5.

Protects information from a range of threats Ensures business continuity Minimizes financial loss Optimizes return on investments Increases business opportunities

Business survival depends on information security.

Security breaches leads to

Reputation loss Financial loss Intellectual property loss

Legislative Breaches leading to legal actions


(Cyber Law) Loss of customer confidence Business interruption costs

LOSS OF GOODWILL

Information Security is Organizational Problem


rather than IT Problem More than 70% of Threats are Internal

More than 60% culprits are First Time fraudsters


Biggest Risk : People Biggest Asset : People

Social Engineering is major threat


More than 2/3rd express their inability to determine
Whether my systems are currently compromised?

Change control & management


Why is change control & change management a security issue?
Many businesses live or die on data integrity Changes can break a security model Modifying system breaks warranty

Needed since change requester does not understand the security implications of their request Security administrator must analyze and assess carefully the impact to the system

Change control & management


Tools
ESM Tripwire

Effective change control can uncover:


Cases of policy violation by staff; Where programs are installed or changed without following the proper notification procedures Possible hardware failure leading to data corruption Viruses, worms, malicious code

Change control & management


For change control & management to work, you must have:
Secure infrastructure. Software must be securely stored on physically protected media. If an intruder can get root, and change the golden copies, then the change control tools will be ineffective.

Hardware

Change control & management

Disks, peripherals Device drivers

Application and operating systems software


Upgrades Service packs, patches, fixes Changes to the firewall rulebase/proxies Router software

Change control & management


Policies, procedures and processes
Develop polices that will stabilize the production processing environment by controlling all changes made to it Formal change control processes will help to ensure that only authorized changes are made, that they are made at the approved time, and that they are made in the approved manner Promptly implement security patches, command scripts, & similar from vendors, CERT, etc. Have procedures for roll-back to prior versions in case of problems, AKA, dont burn your software bridges

Classification is part of a mandatory access control model to ensure that sensitive data is properly controlled and secured DoD multi-level security policy has 4 classifications:
Top Secret Secret Confidential Unclassified

Data classification

Other levels in use are:


Eyes only Officers only Company confidential Public

Data classification benefits


Data confidentiality, integrity & availability are improved since appropriate controls are used throughout the enterprise Protection mechanisms are maximized A process exists to review the values of company business data Decision quality is increased since the quality of the data upon which the decision is being made has been improved

Data classification
Top Secret - applies to the most sensitive business information which is intended strictly for use within the organization. Unauthorized disclosure could seriously and adversely impact the company, stockholders, business partners, and/or its customers Secret - Applies to less sensitive business information which is intended for use within a company. Unauthorized disclosure could adversely impact the company, its stockholders, its business partners, and/or its customers Confidential - Applies to personal information which is intended for use within the company. Unauthorized disclosure could adversely impact the company and/or its employees Unclassified - Applies to all other information which does not clearly fit into any of the above three classifications. Unauthorized disclosure isnt expected to seriously or adversely impact the company

MAC data classification


In MAC systems, every subject and object in a system has a sensitivity label and a set of categories:
classification [category] Top Secret [CEO, CFO, Board Members] Confidential [Internal employees, auditors]

The function of categories is that even someone with the highest classification isnt automatically cleared to see all information at that level. This support the concept of need to know
38

Misc. data classification issues


In a commercial setting, responsibility for assigning data classification labels is on the person who created or updated the information With the exception of general business correspondence, all externally-provided information which is not public in nature must have a data classification system label. All tape reels, floppy disks and other computer storage media containing secret, confidential, or private information must be externally labelled with the appropriate sensitivity classification Holders of sensitive information must take appropriate steps to ensure that these materials are not available to unauthorized persons.

Data classification
Roles & responsibilities
Information owner Information custodian Application owner User manager Security administrator Security analyst Change control analyst Data analyst Solution provider End user

40

Employment policies & practices


Background checks/security clearances Checking public records provides critical information needed to make the best hiring decision. Conducting these often simple checks verifies the information provided on the application is current and true, and gives the employer an immediate measurement of an applicants integrity.
41

Background checks
What does a background check prevent potentially prevent against:
lawsuits from terminated employees lawsuits from 3rd-parties or customers for negligent hiring unqualified employees lost business and profits time wasted recruiting, hiring and training theft, embezzlement or property damage money lost (to recruiters fees, signing bonus) negligent hiring lawsuit decrease in employee moral workplace violence, or sexual harassment suits

42

Background checks
Who should be checked? Employee background checks should be performed for all sensitive positions. Information security staff in sensitive positions include those responsible for:
firewall administration e-commerce management Kerberos administrator SecurID & Password usage PKI and certificate management router administrator
43

Background checks
What can be checked for an applicant:
Credit Report SSN searches Workers Compensation Reports Criminal Records Motor Vehicle Report Education Verification & Credential Confirmation Reference Checks Prior Employer Verification
44

Military security clearance


Of the most meticulous background checks is those requiring a DoD security clearance. After reviewing the 30-page Defense Industrial Personnel Security Clearance Review, one will get a new understanding of painstaking review. A defense security clearances is generally only requested for individuals in the following categories whose employment involves access to sensitive government assets: Members of the military; Civilian employees working for the Department of Defense or other government agencies; Employees of government contractors.

Military security clearance


A DoD review, more correctly known as a personnel security investigation is comprised of the following:
a search of investigative files and other records held by federal agencies, including the FBI and, if appropriate, overseas countries a financial check field interviews of references (in writing, by telephone, or in person), to include coworkers, employers, personal friends, educators, neighbors, and other individuals, as appropriate a personal interview with the applicant conducted by an Investigator
46

Employment agreement
Non-compete Non-disclosure Restrictions on dissemination of corporate information, i.e., press, analysts, law enforcement

47

Hiring & termination


Policies and procedures should come down from HR Should address:
how to handle employees departure shutting down accounts forwarding e-mail and voice-mail lock and combination changes system password changes
48

Separation of duties
The principle of separating of duties is that an organization should carefully separate duties, so that people involved in checking for inappropriate use are not also capable of make such inappropriate use No person should be responsible for completing a task involving sensitive, valuable or critical information from beginning to end. Likewise, a single person must not be responsible for approving their own work

49

Separation of duties
Separate:
development/production security/audit accounts payable/accounts receivable encryption key management/changing of keys

Split knowledge
Encryption keys are separated into two components, each of which does not reveal the other
50

Information security policies


Policy is perhaps the most crucial element in a corporate information security infrastructure Marcus Ranum defines a firewall as the implementation of your Internet security policy. If you havent got a security policy, you havent got a firewall. Instead, youve got a thing thats sort of doing something, but you dont know what its trying to do because no one has told you what it should do Corporate computing is a complex operation. Effective policies can rectify many of the weaknesses and faults
51

Information security policies


Benefits:
Ensure systems are utilized in the manner intended for Ensure users understand their roles & responsibilities Control legal liability

52

Information security policies


Components of an effective policy:
Title Purpose Authorizing individual Author/sponsor Reference to other policies Scope Measurement expectations Exception process Accountability Effective/expiration dates Definitions

53

Information security policies


How to ensure that policies are understood: Jargon free/non-technical language Rather then, when creating software authentication codes, users must endeavor to use codes that do not facilitate nor submit the company to vulnerabilities in the event that external operatives break such codes, use passwords that are guessable should not be used. Focused Job position independent No procedures, techniques or methods Policy is the approach. The specific details & implementations should be in another document Responsibility for adherence Users must understand the magnitude & significance of the policy. I thought this policy didnt apply to me should never be heard.

54

Risk Management

Introduction
Risk management: process of identifying and controlling risks facing an organization Risk identification: process of examining an organizations current information technology security situation Risk control: applying controls to reduce risks to an organizations data and information systems

An Overview of Risk Management


Know yourself: identify, examine, and understand the information and systems currently in place Know the enemy: identify, examine, and understand threats facing the organization Responsibility of each community of interest within an organization to manage risks that are encountered

The Roles of the Communities of Interest


Information security, management and users, and information technology all must work together Management review:
Verify completeness/accuracy of asset inventory

Review and verify threats as well as controls and mitigation strategies


Review cost effectiveness of each control Verify effectiveness of controls deployed

Risk Identification
Assets are targets of various threats and threat agents Risk management involves identifying organizations assets and identifying threats/vulnerabilities Risk identification begins with identifying organizations assets and assessing their value

Asset Identification, Valuation, and Prioritization


Iterative process; begins with identification of assets, including all elements of an organizations system (people, procedures, data and information, software, hardware, networking) Assets are then classified and categorized

Table 4-1 - Categorizing Components

People, Procedures, and Data Asset Identification


Human resources, documentation, and data information assets are more difficult to identify People with knowledge, experience, and good judgment should be assigned this task These assets should be recorded using reliable data-handling process

People, Procedures, and Data Asset Identification (continued)


Asset attributes for people: position name/number/ID; supervisor; security clearance level; special skills Asset attributes for procedures: description; intended purpose; what elements it is tied to; storage location for reference; storage location for update Asset attributes for data: classification; owner/creator/ manager; data structure size; data structure used; online/offline; location; backup procedures employed

Hardware, Software, and Network Asset Identification


What information attributes to track depends on:
Needs of organization/risk management efforts Management needs of information security/information technology communities

Asset attributes to be considered are: name; IP address; MAC address; element type; serial number; manufacturer name; model/part number; software version; physical or logical location; controlling entity

Information Asset Classification


Many organizations have data classification schemes (e.g., confidential, internal, public data) Classification of components must be specific to allow determination of priority levels Categories must be comprehensive and mutually exclusive

Information Asset Valuation


Questions help develop criteria for asset valuation Which information asset:
is most critical to organizations success? generates the most revenue/profitability? would be most expensive to replace or protect? would be the most embarrassing or cause greatest liability if revealed?

Figure 4-3 Example Worksheet

Information Asset Prioritization


Create weighting for each category based on the answers to questions Calculate relative importance of each asset using weighted factor analysis List the assets in order of importance using a weighted factor analysis worksheet

Table 4-2 Example Weighted Factor Analysis

Data Classification and Management


Variety of classification schemes used by corporate and military organizations Information owners responsible for classifying their information assets Information classifications must be reviewed periodically Most organizations do not need detailed level of classification used by military or federal agencies; however, organizations may need to classify data to provide protection

Security Clearances
Security clearance structure: each data user assigned a single level of authorization indicating classification level Before accessing specific set of data, employee must meet need-to-know requirement Extra level of protection ensures information confidentiality is maintained

Management of Classified Data


Storage, distribution, portability, and destruction of classified data

Information not unclassified or public must be clearly marked as such


Clean desk policy requires all information be stored in appropriate storage container daily; unneeded copies of classified information are destroyed

Dumpster diving can compromise information security

Threat Identification
Realistic threats need investigation; unimportant threats are set aside Threat assessment:
Which threats present danger to assets? Which threats represent the most danger to information? How much would it cost to recover from attack? Which threat requires greatest expenditure to prevent?

Vulnerability Identification
Specific avenues threat agents can exploit to attack an information asset are called vulnerabilities Examine how each threat could be perpetrated and list organizations assets and vulnerabilities Process works best when people with diverse backgrounds within organization work iteratively in a series of brainstorming sessions At end of risk identification process, list of assets and their vulnerabilities is achieved

Risk Assessment
Risk assessment evaluates the relative risk for each vulnerability Assigns a risk rating or score to each information asset

Likelihood
The probability that a specific vulnerability will be the object of a successful attack

Assign numeric value: number between 0.1 (low) and 1.0 (high), or a number between 1 and 100
Zero not used since vulnerabilities with zero likelihood removed from asset/vulnerability list Use selected rating model consistently Use external references for values that have been reviewed/adjusted for your circumstances

Risk Determination
For the purpose of relative risk assessment, risk equals:
Likelihood of vulnerability occurrence TIMES value (or impact) MINUS percentage risk already controlled PLUS an element of uncertainty

Identify Possible Controls


For each threat and associated vulnerabilities that have residual risk, create preliminary list of control ideas Residual risk is risk that remains to information asset even after existing control has been applied

Access Controls
Specifically address admission of a user into a trusted area of organization Access controls can be:
Mandatory access controls (MAC): give users and data owners limited control over access to information Nondiscretionary controls: managed by central authority in organization; can be role-based or taskbased Discretionary access controls (DAC): implemented at discretion or option of data user

Documenting the Results of Risk Assessment


Final summary comprised in ranked vulnerability risk worksheet Worksheet details asset, asset impact, vulnerability, vulnerability likelihood, and riskrating factor Ranked vulnerability risk worksheet is initial working document for next step in risk management process: assessing and controlling risk

Risk Control Strategies


Once ranked vulnerability risk worksheet complete, must choose one of four strategies to control each risk:
Apply safeguards (avoidance)

Transfer the risk (transference)


Reduce impact (mitigation)

Understand consequences and accept risk (acceptance)

Avoidance
Attempts to prevent exploitation of the vulnerability

Preferred approach; accomplished through countering threats, removing asset vulnerabilities, limiting asset access, and adding protective safeguards
Three common methods of risk avoidance:
Application of policy Training and education Applying technology

Transference
Control approach that attempts to shift risk to other assets, processes, or organizations If lacking, organization should hire individuals/firms that provide security management and administration expertise Organization may then transfer risk associated with management of complex systems to another organization experienced in dealing with those risks

Mitigation
Attempts to reduce impact of vulnerability exploitation through planning and preparation Approach includes three types of plans:
Incident response plan (IRP) Disaster recovery plan (DRP) Business continuity plan (BCP)

Mitigation (continued)
DRP is most common mitigation procedure The actions to take while incident is in progress is defined in IRP BCP encompasses continuation of business activities if catastrophic event occurs

Acceptance
Doing nothing to protect a vulnerability and accepting the outcome of its exploitation Valid only when the particular function, service, information, or asset does not justify cost of protection Risk appetite describes the degree to which organization is willing to accept risk as tradeoff to the expense of applying controls

Selecting a Risk Control Strategy


Level of threat and value of asset play major role in selection of strategy Rules of thumb on strategy selection can be applied:
When a vulnerability exists
When a vulnerability can be exploited When attackers cost is less than potential gain When potential loss is substantial

Figure 4- 8- Risk Handling Decision Points

Feasibility Studies
Before deciding on strategy, all information about economic/noneconomic consequences of vulnerability of information asset must be explored A number of ways exist to determine advantage of a specific control

Cost Benefit Analysis (CBA)


Most common approach for deciding on information security controls is economic feasibility of implementation CBA is begun by evaluating worth of assets to be protected and the loss in value if those assets are compromised The formal process to document this is called cost benefit analysis or economic feasibility study

Cost Benefit Analysis (CBA) (continued)


Items that affect cost of a control or safeguard include: cost of development or acquisition; training fees; implementation cost; service costs; cost of maintenance Benefit is the value an organization realizes by using controls to prevent losses associated with a vulnerability Asset valuation is process of assigning financial value or worth to each information asset; there are many components to asset valuation

Cost Benefit Analysis (CBA) (continued)


Once value of assets is estimated, potential loss from exploitation of vulnerability is studied

Process result is estimate of potential loss per risk


Expected loss per risk stated in the following equation:
Annualized loss expectancy (ALE) equals Single loss expectancy (SLE) TIMES Annualized rate of occurrence (ARO)

SLE is equal to asset value times exposure factor (EF)

The Cost Benefit Analysis (CBA) Formula


CBA determines if alternative being evaluated is worth cost incurred to control vulnerability CBA most easily calculated using ALE from earlier assessments, before implementation of proposed control: CBA = ALE(prior) ALE(post) ACS ALE(prior) is annualized loss expectancy of risk before implementation of control ALE(post) is estimated ALE based on control being in place for a period of time ACS is the annualized cost of the safeguard

Evaluation, Assessment, and Maintenance of Risk Controls


Selection and implementation of control strategy is not end of process Strategy and accompanying controls must be monitored/reevaluated on ongoing basis to determine effectiveness and to calculate more accurately the estimated residual risk

Process continues as long as organization continues to function

Quantitative versus Qualitative Risk Control Practices


Performing the previous steps using actual values or estimates is known as quantitative assessment

Possible to complete steps using evaluation process based on characteristics using nonnumerical measures; called qualitative assessment Utilizing scales rather than specific estimates relieves organization from difficulty of determining exact values

Security Governance
Security Governance is the organizational processes and relationships for managing risk
Policies, Procedures, Standards, Guidelines, Baselines Organizational Structures Roles and Responsibilities

100

Policy Mapping
Laws, Regulations, Requirements, Organizational Goals, Objectives

General Organizational Policies

Functional Policies

Procedures

Standards

Guidelines

Baselines

101

Policies
Policies are statements of management intentions and goals Senior Management support and approval is vital to success General, high-level objectives Acceptable use, internet access, logging, information security, etc

102

Procedures
Procedures are detailed steps to perform a specific task Usually required by policy Decommissioning resources, adding user accounts, deleting user accounts, change management, etc

103

Standards
Standards specify the use of specific technologies in a uniform manner Requires uniformity throughout the organization Operating systems, applications, server tools, router configurations, etc

104

Guidelines
Guidelines are recommended methods for performing a task Recommended, but not required Malware cleanup, spyware removal, data conversion, sanitization, etc

105

Baselines
Baselines are similar to standards but account for differences in technologies and versions from different vendors Operating system security baselines
FreeBSD 6.2, Mac OS X Panther, Solaris 10, Red Hat Enterprise Linux 5, Windows 2000, Windows XP, Windows Vista, etc

106

Organizational Structure
Organization of and official responsibilities for security vary
BoD, CEO, BoD Committee CFO, CIO, CSO, CISO Director, Manager

IT/IS Security Audit

107

Typical Org Chart


Board of Directors/Trustees President CIO

Security Director

Project Security Architect

Enterprise Security Architect


Security Analyst

System Auditor

108

Security-Oriented Org Chart


Board of Directors/Trustees President CIO

IT Audit Manager

Security Director

System Auditor

Enterprise Security Architect Security Analyst

Project Security Architect

109

Further Separation
Board of Directors/Trustees President Audit Committee Internal Audit CIO

IT Audit Manager

Security Director

System Auditor

Enterprise Security Analyst Security Architect

Pro Security

110

Organizational Structure
Audit should be separate from implementation and operations
Independence is not compromised

Responsibilities for security should be defined in job descriptions Senior management has ultimate responsibility for security Security officers/managers have functional responsibility
111

Roles and Responsibilities


Best Practices:
Least Privilege Mandatory Vacations Job Rotation Separation of Duties

112

Roles and Responsibilities


Owners
Determine security requirements

Custodians
Manage security based on requirements

Users
Access as allowed by security requirements

113

A Framework for Comparing Different Information Security Risk Analysis Methodologies

Overview
Introduction Information Security Risk Management Methodologies Criteria on which Framework is based The Framework for Comparison How the Framework should be used Strengths and Weakness of this proposed Framework Conclusion References

Introduction
Informationsecurityisanorganizationsapproachto maintaining confidentiality, availability, integrity, nonrepudiation,accountability, authenticity and reliability of its IT systems Currently there are numerous risk analysis methodologies available some of which are qualitative while others are quantitative in nature These methodologies have a common goal of estimating the overall risk value

Introduction
An easy-to-use framework is required to compare information security risk analysis methodologies The best way to choose between methodologies is to compare them, using objective, quantifiable criteria This is where a framework for comparison is needed If the criteria that are used are applicable to all risk analysis methodologies, the organization can compare different methodologies objectively, and decide on the best one

Alternative Frameworks
The framework proposed by Badenhorst indicates whether a methodology addresses a criterion or not It does not use scales, or trade-offs which can aid the organization in choosing a methodology which will best meet their needs This shows the need for more Comparative Frameworks

Information Security Risk Management Methodologies


The Methodologies can be broadly classified into two categories Quantitative Methodologies Qualitative Methodologies Both qualitative and quantitative methodologies were evaluated for developing the framework Different risk analysis methodologies were analyzed to determine common criteria for comparison

Qualitative Methodologies
The qualitative methodologies considered for this framework are OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) The CORAS (Construct a platform for Risk Analysis of Security Critical Systems) methodology

Quantitative Methodologies
The quantitative methodologies considered for this framework are ISRAM (Information Security Risk Analysis Method) Cost-Of-Risk Analysis (CORA) Information Systems (IS) analysis based on a business model The above methodologies were chosen because they have been well documented

OCTAVE
OCTAVE was developed at the CERT Coordination Center (CERT/CC) [Cert Coordination Center 2003] This approach concentrates on assets, threats and vulnerabilities One of the main concepts of OCTAVE is self-direction, the people inside the organization must lead the information security risk evaluation An analysis team, consisting of staff from the organization's business units as well as the IT department, is responsible for leading the evaluation and recording results

OCTAVE
The OCTAVE approach has three phases, with each broken down into processes Each process has certain activities that must be completed, and within each of these activities, different steps must be taken in order to achieve the desired outputs The final result that risk decisions can be based on is the threat profile of different assets Each threat profile contains information on which mitigation decisions can be based

CORAS
CORAS was developed under the Information Society Technologies (IST) program One of the main objectives of CORAS is to develop a framework that exploits methods for risk analysis, semiformal methods for object-oriented modeling, and computerized tools, for a precise, unambiguous, and efficient risk assessment of security critical systems The methodology is based on UML a language that uses diagrams to illustrate relationships and dependencies between users and the environment in which they work

CORAS
During an information security risk analysis, a great deal of information is brainstormed, and during workshops and discussions, different people (users, system developers, analysts, system managers), with different expertise in different fields come together, give their opinions and share information A way in which all the participants can communicate efficiently and understand each other must therefore exist and a UML profile, proposed by the CORAS project, is used to achieve this

CORAS
The framework has four main pillars, of which risk management is one. In CORAS, the final result on which decisions can be based is the UML class diagrams of each asset

ISRAM
The ISRAM methodology was developed at the National Research Institute of Electronics and Cryptology and the Gebze Institute of Technology in Turkey It is marketed as a quantitative approach to risk analysis that allows for the participation of the manager and staff of the organization and a surveybased model Two separate and independent surveys are conducted for the two attributes of risk, namely probability and consequence

ISRAM
ISRAM does not use techniques such as Single Occurrence Losses (SOL) or Annual Loss Expectancy (ALE), instead, the risk factor is a numerical value between 1 and 25 This numerical value corresponds to a qualitative, high, medium or low value, and it is this qualitative value on which risk management decisions are based

CORA
International Security Technology, Inc. (IST) developed CORA, the Cost-Of-Risk Analysis system The CORA risk model uses data collected about threats, functions and assets, and the vulnerabilities of the functions and assets to the threats to calculate the consequences, that is, the losses due to the occurrences of the threats

CORA
It is a methodology where the risk parameters are expressed quantitatively and where losses are expressed in quantitative monetary terms CORA uses a two-step process to support risk management. Parameters for threats, functions and assets are validated and refined until the best values are determined

CORA
CORA then calculates SOL and ALE for each of the threats identified It estimates a single loss value for a threat to an organization, and then multiplies this value by the frequency of the threat occurrence

IS Risk Analysis based on a Business Model


The IS Risk Analysis Based on a Business Model was developed at the Korea Advanced Institute of Science and Technology This model was developed because traditional risk analysis methodologies had some limitations Ittakesanassetsvalueandthennotonlybasesthe analysis on its replacement cost, but also measures thetangibleassetsvaluefromtheviewpointof operational continuity

IS Risk Analysis
The methodology has four stages During this methodology, the importance level of various business functions of the business model and the necessity level of various IS assets are determined Mathematical formulae are used to calculate ALE for a single threat occurrence on the organization The end result is a quantitative monetary value

Criteria for the Framework


Whether risk analysis is done on single assets or groups of assets Where in the methodology risk analysis is done The people involved in the risk analysis The main formulae used Whether the results of the methodology are relative or absolute

Criteria for the Framework


Each criterion has a scaling The scaling indicates the level of a criterion based on certain trade-offs In the end a compliance factor must be selected to indicate how relative the criterion is to a methodology

Whether Risk Analysis is done on Single Assets or Group of Assets


Criteria can either take on a value of 1 or 2, as follows: 1: if risk analysis is done on individual assets 2: if risk analysis is done on groups of assets In the case of the OCTAVE and CORAS methodology, the risk analysis is done on a single asset If the end result is a single value for a threat scenario that can affect more than one asset, the risk analysis is done on a group of assets, such as in the case of the CORA ,ISRAM and IS Business model methodology

Where in the Methodology Risk Analysis is Done


This criterion explains where in the methodology risk analysis takes place Some preparation, where values for information are estimated, must be done before risk analysis can be performed Some risk analysis methodologies may require more values for different information to be estimated than other methodologies

Where in the Methodology Risk Analysis is Done


OCTAVE needs values for impact and probability IS Risk Analysis Based on a Business Model needs values for probability, income loss, replacement cost and relative importance of business functions Methodology that needs little preparation and less information is CORA An accurate risk analysis, more preparation means more detailed results, thus ISRAM would be a better option

Scale for this Criterion


The scale for this criterion is based on a trade-off between time and accuracy. If time is most important 1: Risk analysis done after extensive preparation 2: Risk analysis done after some preparation 3: Risk analysis done after little preparation If accuracy is most important 1: Risk analysis done after little preparation 2: Risk analysis done after some preparation 3: Risk analysis done after extensive preparation

The People Involved in the Risk Analysis


The people involved in the risk analysis can either be internal or external to the organization CORA uses external risk experts to perform the risk analysis, whereas OCTAVE uses internal personnel exclusively

Scale for this Criterion


The scale for this criterion is based on a trade-off between cost and expertise If cost is most important, values are as follows: 1: Risk analysis is performed by external experts 2: Risk analysis is performed by external and internal people 3: Risk analysis is performed by internal people If expertise is most important, values are as follows: 1: Risk analysis is performed by internal people 2: Risk analysis is performed by external and internal people 3: Risk analysis is performed by external experts

The Main Formulae Used


Some methodologies use mathematical formulae while others use an expected value matrix The main formula shows the magnitude of calculations that need to be done, thus indicating the complexity of the risk analysis The scale for this criterion is based on a trade-off between simplicity and accuracy

Scale for this Criterion

If simplicity is most important, values are as follows: 1: Risk analysis involves extensive mathematical calculations 2: Risk analysis involves some but simple mathematical calculations 3: Risk analysis involves no mathematical calculations If accuracy is most important, values are as follows: 1: Risk analysis involves no mathematical calculations 2: Risk analysis involves some but simple mathematical calculations 3: Risk analysis involves extensive mathematical calculations

Whether the Results of the Methodology are Relative or Absolute


Some methodologies produce results that are relative. This means that there is no relationship between results and they cannot be compared Other methodologies produce results that are absolute and can be compared The scale for this criterion is based on a trade-off between a methodology providing merely a ranking of risks, or a methodology that can calculate how much greater one risk is over another

Scale for this Criterion


If merely ranking of risks is most important, values are as follows: 1: Results are comparable 2: Results are not comparable If the differences between risks (how much greater one is over another) are most important, values are as follows: 1: Results are not comparable 2: Results are comparable

The Framework for Comparison

The Main Formulae Used in OCTAVE


The OCTAVE methodology uses an Expected ValueMatrixtodeterminearisksexpected value. The main formula is: Loss = Impact/consequence x Probability

The Main Formulae Used in CORAS


The CORAS methodology also uses the impact and probability approach. Loss = Impact x Probability

The Main Formulae Used in ISRAM

The Main Formulae Used in CORA


ALE = Consequence x Frequency consequence=n(individualSOLs)n the number of single occurrence losses, and SOL = loss potential (worst case monetary value) x vulnerability CORA uses some, but not extensive mathematical calculations. It gets a value of 2 for both simplicity and accuracy

The Main Formulae Used

in IS

IS Risk Analysis Based on a Business Model uses the following:

How the Framework Should be Used


The use of the framework is rather simplistic, which allows for use by more organizations Firstly the organization must identify their specific needs. Then, based on the scales of each criterion as defined earlier, the organization must determine values for the specific methodologies they want to compare

Strengths
Can be applied to various risk analysis methodologies Takes the requirements of an organization into account It uses scales based on different scenarios and tradeoffs Can give an indication of which assets and people will be needed for the risk analysis as based on the requirements of the organization

Weakness
Not taking the customization of a methodology into account The OCTAVE methodology can be tailored to fit the needs of an organization Not all processes have to be performed, which can influence the place where risk analysis fits into the methodology The preparation required can therefore be reduced The risk analysis based on the requirements of an organization

Weakness
The existence of other criteria, not presented by the framework There are many other risk analysis methodologies, such as CRAMM and there are also baselines, which cover a wider variety of information security aspects, such as the ISO 17799 framework and which can be used to define other criteria

Conclusion
Numerous methodologies are currently available and many organizations are faced with the daunting task of determining which one to use The goal was to develop an easy-to-use framework that organizations can employ to compare different information security risk analysis methodologies The main benefit lies in the ability to eliminate the majority of methodologies that are unsuitable and to only further investigate the few that remain

Security Audit

What is a security audit?


Policy based Assessment of risk Examines site methodologies and practices Dynamic Communication

What kinds of Security Audits are there?


Host Firewall Networks Large networks

Security Policies & Documentation


What is a security policy? Components Who should write it? How long should it be? Dissemination It walks, it talks, it is alive.. RFC 1244 What if a written policy doesn't exist? Other documentation

Components of a Security Policy


Who can use resources Proper use of the resources Granting access & use System Administrator privileges User rights & responsibilities What to do with sensitive information Desired security configurations of systems

RFC 1244 ``Site Security Handbook''


Defines security policies & procedures Policy violations Interpretation Publicizing Identifying problems Incident response Updating

Other Documentation
Hardware/software inventory Network topology Key personnel Emergency numbers Incident logs

Why do a Security Audit?


Information is power Expectations Measure policy compliance Assessing risk & security level Assessing potential damage Change management Security incident response

When to audit?
Emergency! Before prime time Scheduled/maintenance

Audit Schedules
Individual Host 1224 months Large Networks 1224 months Network 12 months Firewall 6 months

How to do a Security Audit


Preaudit: verify your tools and environment Audit/review security policy Gather audit information Generate an audit report Take actions based on the report's findings Safeguard data & report

Verify your tools and environment


The golden rule of auditing Bootstrapping problem Audit tools The Audit platform

The Golden Rule of Auditing


Verify ALL tools used for the audit are untampered with. If the results of the auditing tools cannot be trusted, the audit is useless

The Bootstrapping Problem


If the only way to verify that your auditing tools are ok is by using auditing tools, then..

Audit Tools the Hall of Fame


SAINT/SATAN/ISS Nessus lsof /pff Nmap, tcpdump, ipsend MD5/DES/PGP COPS/Tiger Crack

Audit Tools the Hall of Fame


SAINT/SATAN/ISS Nessus lsof /pff Nmap, tcpdump, ipsend MD5/DES/PGP COPS/Tiger Crack

The Audit Platform


Should have extraordinary security Submit it to a firewall+ type of audit Physical access should be required to use No network services running

Choosing a security audit platform: Hardware


laptop computer three kilograms or less graphics display MB memory MB disk ethernet (as many connectors as possible)

Choosing a security audit platform: Software


Unix / Linux Secured OS OS source code Audit tools Development tools

Audit/review security policy


Utilize existing or use ``standard'' policy Treat the policy as a potential threat Does it have all the basic components? Are the security configs comprehensive? Examine dissemination procedures

Security policy
Treat the policy as a potential threat Bad policies are worse than none at all Good policies are very rare Look for clarity & completeness Poor grammar and spelling are not tolerated

Does it Have All the Basic Components?


Who can use resources Proper use of the resources Granting access & use System Administrator privileges User rights & responsibilities What to do with sensitive information

Are the security configs comprehensive?


Details are important! Addresses specific technical problems (COPSlike tests, network services run, etc.) Allowable trust must be clearly outlined Should specify specific tools (The TCP wrappers, S/Key, etc.) that are used Must have explicit time schedules of security audits and/or tools used Logfiles must be regularly examined!

Examine dissemination procedures


Policies are worthless unless people read and understand them Ideally it is distributed and addressed when people join org Email is useful for updates, changes Written user acknowledgment necessary

Gather audit information


Talk to/Interview people Review Documentation Technical Investigation

Talk to/Interview people


Difficult to describe, easy to do Usually ignored Users, operators, sysadmins, janitors, managers Usage & patterns Have they seen/read the security policy?

Talk to/Interview people (cont.)


What can/can't they do, in own words Could they get root/system privileges? What are systems used for? What are the critical systems? How do they view the security audit?

Review Documentation
Hardware/software inventory Network topology Key personnel Emergency numbers Incident logs

Technical Investigation
Run static tools (COPS, Crack, etc.) Check system logs Check system against known vulnerabilities (CERT, bugtraq, CIAC advisories, etc.) Follow startup execution Check static items (config files, etc.) Search for privileged programs (SUID, SGID, run as root) Examine all trust

Technical Investigation (cont.)


Check extra network services (NFS, news, httpd, etc.) Check for replacement programs (wuftpd, TCP wrappers, etc.) Code review ``home grown'' programs (CGI's, finger FIFO's, etc.) Run dynamic tools (ps, netstat, lsof, etc.) Actively test defenses (packet filters, TCP wrappers, etc.)

Run Static Tools


Nmap SAINT/SATAN/ISS Crack Nessus COPS/Tiger

Follow Startup Execution


Boot (P)ROMS init Startup programs (rc.* like files)

Check static items


Examine all config files of running processes (inetd.conf, sendmail.cf, etc.) Examine config files of programs that can start up dynamically (ftpd, etc.)

Search for privileged programs


Find all SUID/SGID programs Look at all programs executed as root Examine:
Environment Paths to execution Configuration files

Examine all Trust


rhosts, hosts.equiv NFS, NIS DNS Windowing systems User traffic and interactive flow

Check Extra Network Services


NFS/AFS/RFS NIS News WWW/httpd Proxy (telnet, ftp, etc.) Authentication (Kerberos, security tokens, special services) Management Protocols (SNMP, etc.)

Check for replacement programs


wuftpd TCP wrappers Logdaemon Xinetd GNU fingerd

Code review ``home grown''/non standard programs


Network daemons Anything SUID, SGID Programs run as system account CGI's

Safeguard Data & Report


Save for the next audit Do not keep online Use strong encryption if stored electronically Limit distribution to those who ``need to know'' Print out report, sign, and number copies

You might also like