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 Authority

Public-Key Certificates

certificates allow key exchange without real-

time 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 Public- Key or Certificate Authority (CA)

can be verified by anyone who knows the

public-key authorities public-key

Public-Key Certificates

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:

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): x A < q compute their public key: y A = a x A mod q

each user makes public that key y A

Diffie-Hellman Key Exchange

shared session key for users A & B is K AB :

K AB = a x A. x B mod q

= y A x B mod q

= y B x A mod q

(which B can compute) (which A can compute)

K AB 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 x A =97,

B chooses x B =233

compute respective public keys:

y A =3 97 mod 353 = 40

y B =3 233 mod 353 = 248 (Bob)

(Alice)

compute shared session key as:

K AB = y B x A mod 353 = 248 97 = 160

(Alice)

K AB = y A x B mod 353 = 40 233 = 160

(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-the- Middle Attack

authentication of the keys is needed

Security Management Practices
Security Management
Practices

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 
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
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),
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,
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.
Access devices:
Desktop computers
Laptops, ultra-mobile laptops and PDAs
Thin client computing.
Digital cameras, Printers, Scanners, Photocopier etc.

INFORMATION SECURITY

1. Protects information from a range of threats

2. Ensures business continuity

3. Minimizes financial loss

4. Optimizes return on investments

5. 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/3 rd 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.

Change control & management

Hardware

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, don’t burn your software bridges

Data classification

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

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 isn’t 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 isn’t automatically cleared to see all information at that level. This support the concept of need to know

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

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 applicant’s

integrity.

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

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

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

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

Employment agreement

Non-compete

Non-disclosure

Restrictions on dissemination of corporate

information, i.e., press, analysts, law

enforcement

Hiring & termination

Policies and procedures should come down from HR

Should address:

how to handle employee’s departure

shutting down accounts

forwarding e-mail and voice-mail

lock and combination changes

system password changes

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

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

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 haven’t got a security policy, you haven’t got a firewall. Instead, you’ve got a thing that’s sort of doing something, but you don’t know what it’s 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

Information security policies

Benefits:

Ensure systems are utilized in the manner intended for

Ensure users understand their roles &

responsibilities

Control legal liability

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

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 didn’t apply to me” should never be heard.

Risk Management

Introduction

Risk management: process of identifying and controlling risks facing an organization

Risk identification: process of examining an organization’s current information technology

security situation

Risk control: applying controls to reduce risks to an organization’s 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 organization’s assets and identifying threats/vulnerabilities

Risk identification begins with identifying

organization’s assets and assessing their

value

Asset Identification, Valuation, and Prioritization

Iterative process; begins with

identification of assets, including all

elements of an organization’s system (people, procedures, data and

information, software, hardware,

networking)

Assets are then classified and categorized

Table 4-1 - Categorizing Components

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 organization’s 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

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

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 organization’s 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 task-

based

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 risk- rating 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 trade- off 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 attacker’s cost is less than potential gain

When potential loss is substantial

Figure 4- 8- Risk Handling Decision Points

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

Goals, Objectives General Organizational Policies Functional Policies Standards Guidelines Procedures Baselines 101

Standards

Guidelines

Procedures

Baselines

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

Enterprise

Security Architect

Project

Security Architect

System Auditor

Security Analyst

108

Security-Oriented Org Chart

Board of Directors/Trustees

President

CIO

IT Audit Manager

Security Director

Enterprise Security Architect
Enterprise
Security Architect

Project Security Architect

System Auditor

Security Analyst

109

Further Separation

Board of Directors/Trustees President Audit Committee Internal Audit CIO IT Audit Manager Security Director
Board of Directors/Trustees
President
Audit Committee
Internal Audit
CIO
IT Audit Manager
Security Director
Enterprise
Security Security Architect Analyst
Pro
System Auditor
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

• Information‏security‏is‏an‏organization’s‏approach‏to‏

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, semi- formal 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 survey-

based 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

• It‏takes‏an‏asset’s‏value‏and‏then‏not‏only‏bases‏the‏ analysis on its replacement cost, but also measures the‏tangible‏asset’s‏value‏from‏the‏viewpoint‏of‏

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 Framework for Comparison

The Main Formulae Used

in OCTAVE

The OCTAVE methodology uses an Expected

Value‏Matrix‏to‏determine‏a‏risk’s‏expected‏

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 ISRAM

The Main Formulae Used

in CORA

ALE = Consequence x Frequency

• consequence‏=‏Σn(individual‏SOL’s)‏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:

The Main Formulae Used in IS • IS Risk Analysis Based on a Business Model uses

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 trade- offs

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