Why requirements ?

• Feeling of:– Trust– Reliability– Confidence– Predictability– Stability

• Guarantee for everything is all right

Høj

Middel

Lav

HøjMiddelLav

Trusselvurdering

Trusselniveau

Kon

sekc

ens

Sandsynlighed

12

34

56

7

8

AB

CD

Høj

Middel

Lav

LavMiddelHøj

Risikovurdering

RisikoniveauT

russ

elni

veau

Kontrolmiljø

1

23

4 5

67

8

A B

CD

Requirement: move risk items out of the red area

Requirements

Høj

Middel

Lav

LavMiddelHøj

Risikovurdering

Risikoniveau

Tru

ssel

nive

au

Kontrolmiljø

1

2

3

4

5

6

7

8

A

B

CD

Controls

Why IT-Security requirements ? Case: The Laptop computer

• Using a company laptop computer– Allowed to install downloads from the Internet and run software?

– Alowed to save private related information on the disk?

– Allowed to connect to a private ADSL connection?

– Who gave you the permission for local administrator privilege?

– Allowed to install vmware+linux+nessus on the mashine?

– Who has the right to allow an exception?

Who specifies the IT Security Requirements ?

(Invariable demand or not …)

• External (Requirement from outside)– Law (Legal aspect, Legislation) - ”Breaking the rule is punishable”– Departmental order– Requirements from business partners

• Certification

– Agreements with business partners

• Internal– More or less related to Standards

• ISO/IEC 17799, ISF, DS-484 (Danish Norm) - Instans

– Management Team / business needs– Risk Assessment– IT Security Policy– IT Security Guidelines (hierarchy)

• Informal– Ethics– Code of ethics– Valuable property

IT Security requirements

• Law (invariable)– National and International

• Regulation• Rules• Standard• Policy• Guidance - Guidelines• Procedure• Instruction (Manual operation)

Guidance on the departmental order - new Act

Standard/Regulation Industry Comments/URLs

ISO/IEC 17799 International - Baseline "The International Organization for Standardization" www.iso-17799.com

BS 7799 Part 1 British Government British Standard. Predecessor to ISO 17799 standard

AS4444/NZS4444 Australian Government Australian Standard/New Zealand Standard. Replaced by ISO 17799 standard

HIPAA Health Care Health Insurance Portability And Accountability Act of 1996.

CIS Benchmarks Worldwide Consortium The Center for Internet Security Solaris Benchmark

Gramm-Leach-Bliley Act (GLBA) US Financial Services Law US Legislation passed Nov. 1999.

SANS/FBI Top 20 List General Security System Administration, Networking and Security/Federal Bureau of Investigation

CVE General Security MITRE's Common Vulnerabilities and Exposures

VISA Banking Visa International and Visa USA

ISO 15408 (Common Criteria) International Security Program - Systems May be replacing NSA's Red Book and Orange Book

CASPR GNU Best Practices Commonly Accepted Security Practices & Recommendations

OCC Banking Office of the Comptroller of the Currency

FDIC Banking Federal Deposit Insurance Corporation

SysTrust AICPA American Institute of Certified Public Accountants

FISCAM GAO (Federal Govt.), Financial Systems Federal Information Systems Control Audit Manual

CobiT ISACA Control Objectives for Information and Related Technology

IETF Security Handbooks Internet Community The Internet Engineering Task Force

SEC Brokerage U.S. Securities and Exchange Commission

Rainbow Series (Orange Book) Military commands and contractors Being replaced by Common Criteria

FDA Pharmaceutical Food and Drug Administration

NPG 2810 (NASA) Facilities and Contractors NASA Policy Guideline

1974 Privacy Act and Amendments US Companies www.usdoj.gov/04foia/privstat.htm

ISO 13335(Parts 1,2,3,4,5) International - Educational A five-part technical report giving guidance on security management.

SAS70 Auditing Statement on Auditing Standards

GASSP Older than CASPR Generally Accepted Systems Security Principles

DITSCAP/NIACAP Department of Defense (DOD) DoD Information Technology Security Certification and AccreditationProcess

AS/NZS 4360:1999 Australian/New Zealand Government Australian Standard / New Zealand Standard

FCC US Government Federal Communications Commission

Informative References

1. BS 7799-1: 1999 British Standards Institute (BSI), Information security management - Code of practice for information security management, 1999

2. BS 7799-2: 1999 British Standards Institute (BSI), Information security management - Specification for information security management systems,

1999 3. ISACA COBIT

Information Systems Audit and Control Association (ISACA), Control Objectives for Information and related Technologies (CobiT) 4. ISF SOGP

Information Security Forum (ISF), Standard of Good Practice for Information Security, 1998 5. ISO 7498-1:1994

Information processing systems - Open systems interconnection - The basic model, 1994 (E) 6. ISO/IEC 10181-1:1996

Information technology - Open systems interconnection - Security frameworks for open systems: Overview, 1996 7. ISO/IEC 17799:2000

ISO/IEC 17799 Information technology - Code of practice for information security management, 2000 8. ISO/IEC TR 13335

ISO/IEC TR 13335 Information technology - Guidelines for the management of IT security 9. MENEZES

Alfred J. Menezes, Paul C. Van Oorschot, Scott A Vanstone, "Handbook of Applied Cryptography", CRC Press, 1996 10. PARKER

Donn B. Parker, "Fighting Computer Crime: A New Framework for Protecting Information", John Wiley and Sons, Inc, 1998

Three Primary IT Standards • To be clear, "ad hoc" refers to frameworks developed within an organization based on the best practice

experience found within an organization. In contrast, there are evolving international standards that are maintained by governing bodies that reflect the experience of hundreds of organizations. Now, if we focus on IT standards, there exist three that seem to be at the forefront today. They are:

• COBIT -- The Control Objectives for Information and related Technology (COBIT) standard is now in its third revision and is published by the Information Systems Audit and Control Association (ISACA) and was originally released in 1996. The COBIT framework is comprised of 34 high-level control objectives and 318 detailed control objectives that have been designed to help businesses maintain effective control over IT. The standard is very well done and the entire COBIT documentation set is available online including the executive summary, framework, control objectives, audit guidelines, management guidelines and an implementation guide. Currently, the ISACA is finalizing a special version of COBIT called "QuickStart" for small and medium-sized businesses. It will contain a subset of the COBIT standard and focus on elements that are viewed as most critical for organizations that lack the resources to pursue the full standard.

• ISO 17799 -- The International Organization for Standardization's ISO 17799, titled "Information Technology - Code of Practice for Information Security Management," was first released by the ISO in December 2000. However, it is based on the British Standard 7799 that has quite a lineage, but solidified under the BS 7799 identifier beginning in 1995 and finalized in 1999. The intent of the standard is to focus on security and aid an organization in the creation of an effective IT security plan. The standard has the following high-level groupings: security policy, organizational security, asset classification and control, personnel security, physical and environmental security, communications and operations management, access control, systems development and maintenance, business continuity management and compliance. The standard is very well-done and covers a great deal of material in a concise manner.

• ITIL -- The Information Technology Infrastructure Library (ITIL) is maintained by the United Kingdom's Office of Government Commerce (OGC) and was developed with the input of many organizations beginning in the late 1980s. Interestingly, it is not well-known in all countries, but definitely has a growing number of subscribers. The "library" currently consists of seven books: service support, service delivery, security management, application management, ICT infrastructure management, the business perspective and planning to implement service management. ITIL is very much aimed at identifying best practices in regards to managing IT service levels and a number of organizations, including the U.S. Navy and Procter and Gamble, have adopted ITIL and enjoyed substantial benefits.

IT Security ”Catalogue” of Controls Suitable (reasonable) set of Security Requirements

• Standard– ISO/IEC 17799 (BS 7799-1)

• International Standard

• ”De Facto” standard– ISF (Information Security Forum)

• Standard of Good Practice (Information Security)

• Guidelines– ISO/IEC TR 13335, 1-5

• International Technical Reports

• Certification (a possibility)– BS 7799 – 2

• Specifies a necessary minimum of Security Requirements

IT Security level

• How to specify the objective ?– Choose a satisfactory level of IT Security (trust?)

• A Company can choose to be in accordance with– Guidance

• ISO/IEC 17799-1• ISF• DS 484-1

– Certification requirements• BS 7799-2• DS 484-2

• Result– ISF - ”the solution” < Some point to be addressed (goal for the auditor)– ISF - ”the solution” = Satisfactory– ISF - ”the solution” > Better than ISF (maybe the company decision)

ISO 17799 has ten assessment sections:

1. Security Policy 2. Security Organization 3. Asset Classification and Control 4. Personnel Security 5. Physical and Environmental Security 6. Computer and Network Management 7. System Access Control 8. System Development and Maintenance 9. Business Continuity and Disaster Recovery Planning 10.Compliance

Section 1 - Security Policy

Objectives:•To provide management direction for information security •To provide support for information security

 Section 2 - Security Organization

Objectives: •To manage information security within the Company•To maintain the security of organizational information processing facilities and information assets accessed by third parties•To maintain the security of information when the responsibility for information processing has been outsourced to another organization

Section 3 - Asset Classification and Control

Objectives: •To maintain appropriate protection of corporate assets •To ensure that information assets receive an appropriate level of protection.

Section 4 - Personnel Security

Objectives:•To reduce risks of human error, theft, fraud or misuse of facilities •To ensure that users are aware of information security threats and concerns, and are equipped to support the corporate security policy in the course of their normal work •To minimize the damage from security incidents and malfunctions and learn from such incidents

Section 5 - Physical and Environmental Security

Objectives: •To reduce risks of human error, theft, fraud or misuse of facilities •To ensure that users are aware of information security threats and concerns, and are equipped to support the corporate security policy in the course of their normal work •To minimize the damage from security incidents and malfunctions and learn from such incidents

Section 6 - Computer & Network ManagementObjectives:

•To ensure the correct and secure operation of information processing facilities •To minimize the risk of systems failures •To protect the integrity of software and information •To maintain the integrity and availability of information processing and communication •To ensure the safeguarding of information in networks and the protection of the supporting infrastructure •To prevent damage to assets and interruptions to business activities •To prevent loss, modification or misuse of information exchanged between organizations

Section 7 - System Access ControlObjectives:

•To control access to information •To prevent unauthorized access to information systems •To ensure the protection of networked services •To prevent unauthorized computer access •To detect unauthorized activities •To ensure information security when using mobile computing and tele-networking facilities

  Section 8 - System Development and MaintenanceObjectives:

•To ensure security is built into operational systems •To prevent loss, modification or misuse of user data in application systems •To protect the confidentiality, authenticity and integrity of information •To ensure IT projects and support activities are conducted in a secure manner •To maintain the security of application system software and data

Section 9 - Business Continuity and Disaster Recovery PlanningObjectives:

•To counteract interruptions to business activities •To critical business processes from the effects of major failures or disasters.

Section 10 - ComplianceObjectives:

•To avoid breaches of any criminal or civil law, statutory, regulatory or contractual obligations and of any security requirements •To ensure compliance of systems with organizational security policies and standards •To maximize the effectiveness of and to minimize interference to/from the system audit process.

IT-SecurityPolicy

IT-SecurityGuideline

# 1

IT-SecurityGuideline

# 2

IT-SecurityGuideline

# 3

IT-SecurityGuideline

# 3(local)

IT-SecurityStandard

ImplementationStandards(Service

Providers)

InterpretationGuides

(Users and Managers)

IT Security Policy

• Needed– Signal to business partners and employees

• Responsible (Create, update, create awareness)– IT Security Manager

• Approved– Board of directors

• Relation to– Businesss Strategy

• Characteristics– High abstract language, non technical and max 2 pages

• Content– We shall …. Example follows ISF Standard of Good Practice

• Apply to– IT Security Guidelines

• Type of document– Official (should be) but can be kept secret from the public

Why you need to have a Security Policy

1.A security policy is a document that sets the rules and principles, which affects the way an organization

approaches problems. 2.Furthermore, a security policy is a document that leads to the specification of the agreed conditions of use of an organization's resources for users and other clients. It also sets the rights that they can expect

with that use. 3.Ultimately, a security policy is a document that exists to prevent the loss of an asset or its value. A security breach can easily lead to such a loss, regardless of whether the security breach occurred as a result of any natural disaster or hardware or software error, or malicious action internal or external to the

organization. 4.An organization should make decisions with regard to other policies. It is not uncommon for a policy on a particular matter to refer to other policies. For instance, a security policy may refer to a policy on Copyright or to a policy dealing with the Press. Similarly, other policies may need to refer to specific

sections of the security policy. This obviously is not possible if a security policy is nonexistent. 5.The policy helps in making purchasing decisions. A security policy offers guidelines for standards of protection required on particular classes of computer systems. If a software or hardware component under consideration for purchase could be used to (or will actually) compromise these standards, then

this may have an influence on whether the component is purchased. 6.A security policy forms a framework for deciding what action to take in particular circumstances. In the event of a security breach, a security policy may contain guidelines of what authority particular people have to take and the actions to minimize the impact of that breach. Furthermore, after the breach, the policy will provide guidelines regarding the course of action to take in order to prevent further or repeated breaches, and also regarding the identification and discipline of the people responsible (in whatever capacity) for the breach. This removes the scope for independent reasoning at inappropriate

times. Courtesy: Global E-Secure

An approach for formulating a Security PolicySecurity Solutions Providers (SSPs) will have their own unique approaches to formulating the security policy. Here is the methodology adopted by iServe India. This SSP claims its approach is comprehensive, practical and implementable.

•The methodology followed is: •Understanding of the business process and the way IT is deployed in the organization. •Identification of the critical IT resources, their availability requirements, and locations. •Identification of threats to these resources. Threats could be:

•External •Internal

Threats could also be: •IT related like hacking, denial of service attacks, removal of a resource. •Non-IT related: These threats include physical threats or any action that would somehow make an

IT resource unavailable. •Definition of routine processes that needs to be followed to protect the IT assets. •Definition of incident handling processes. Processes are defined for different kinds of incidents like

hacking attempts, denial of service attacks etc. •Definition of an organization structure for implementation of the security policies. The organization structure clearly identifies the key personnel in the implementation of the plan and delineates their roles

and responsibilities. •Awareness plan: This plan focuses on a plan that would make aware each and every member of the

organization of the security policies and their implementation. •Development of an implementation road map.

Courtesy: iServ India

APPROACHIS security has always been associated with the IT department and thought to be a very technical issue. And that's the fundamental problem.

• Says Santosh Desai, Senior VP, eSecurity, eServices Division, RoltaNet, "People are looking at technology first, and this is wrong. This is because (evolving) technology is forcing companies to upgrade its IT infrastructure. So no one looks at security from a business angle. It becomes an end-to-end security solution only if you look at it from a business angle and then address your security needs."

• Kadam feels it isn't right to involve only technical people when formulating the policy. "Technical people may formulate excellent technical policies that might not be practical to implement. They do not know the business issues and people-related issues. That's why their policies do not match actual requirement, and this is where the policy implementation fails."

• Another malpractice is having a lengthy and complex policy that few understand.

• "Hitherto, organizations typically developed a security policy that was a voluminous document that few read, hence it wasn't fully implemented," says Himanshu Khanna, Head-Technology, iServ India. "This is not the correct approach. A security policy needs to be short and crisp, with clear threat identification, processes for countering these threats and an organization structure supporting these counter measures. We believe that for high efficacy of implementation, an organization should follow a phased approach—high potential threats countered first and others countered in subsequent phases."

WHO SHOULD BE INVOLVED?The effectiveness of the policy and the motivation to adopt it depends on the people involved in formulating it. The traditional practice of involving only the IT manager and IS department should be discarded. Rather, companies should take the top down approach and the initiative should come from top management.

• The CEO can define a broad policy in consultation with the IT manager. Once that happens, security awareness percolates down to all levels within the organization.

• Besides the CEO and CIO/CTO there are others who should be involved.• "All business users who access information should be involved," says Kadam.

"Procedures and implementation could be done by the CIO/CTO. But the policy cannot be created only by the CIO/CTO. He may not be aware of all the business processes."

• Take the Internet/e-mail usage policy for instance. This cannot be decided only by the CIO. For this the CIO will have to consult HR, business users, and top management. They will decide how much flexibility is to be given depending on job function. The CIO will only address the technical aspects.

• Some organizations assign the responsibility of forming the security policy to a steering committee or task force. This team comprises of consultants and security advisors who may be from within the organization or from outside. This team is given privileged access to talk to top management, the business development teams, the implementers (IT and IS managers), head of HR and other departments, and also end users.

• "This team should be headed by a security consultant who has to ensure that the policies defined by the top management are understood at a lower level. This reduces the gap between assumed policies and existing policies," says Desai.

FORMING A POLICYWith commitment from top management, the team can begin work on the security policy. It may conduct a series of interviews with people at all levels in the organization (and with various departments) to check their expectations from the policy. The task of creating a policy involves various procedures that can broadly be grouped in the following phases:

• Risk Assessment In the first phase, one identifies all risks and vulnerabilities that could disrupt business. The procedures/methods to counter the threats are also devised. It is important to understand the business objectives and expectations from IT while doing risk assessment.

• Design and Write The results of the interviews conducted in the first phase are analyzed. Also, all the procedures for countering threats are considered when designing the policy. A draft policy is written which goes to the management. Certain statements may be modified and the new changes are incorporated. This may be repetitive until the policy is fine-tuned and specific to the business processes and in line with business objectives. The policy is documented and copies may be distributed to all in the organization. The documentation also includes penalties for not adhering to the policy.

• Implement and Monitor Once the policy is implemented, the team observes its acceptance and makes notes. Certain sections might come out to be too rigid or too flexible. These will be modified later when the policy is reviewed.

• Audit Besides monitoring the acceptability of the policy, the team will also conduct audit trials to check for weaknesses or new vulnerabilities. The policy will be revised accordingly

IT Security Guidelines

• Use for– Directions of employees

• Responsible (Create, update, create awareness)– IT Security Manager in co-operation with the people who need the guideline

• Approved– Executive management

• Relation to– IT Security Policy

• Characteristics– More concrete language in use for users or technical part

• Content– We shall for network dial-up solutions ….

• Allways use strong authentication with one-time-password generator

• Apply to– IT Instruction or procedure

• Type of document– Keep secret for public

Network Security Policy (Guideline)

• Use for– Keep the focus on security in the network

• Responsible (Create, update, create awareness)– IT Security Manager in co-operation with the network team

• Approved– Executive management / IT management

• Relation to– IT Security Policy

• Characteristics– More concrete language use for technical part

• Content– We shall protect our Intranet as if it is the Internet– We shall allways use Switch-to-the-desktop on the LANs

• Apply to– Network instruction or procedure

• Type of document– Keep secret for public

Creating IT Security Guideline

1. Choose one guideline from ISF– Example CN23

– Just follow ”The One and only”

2. Choose three guidelines from ISF– Example CN23+CB53+SM54

– ”Shake up” the three guidelines an create your own

– Make the new guideline more specific

3. Do something different ?

Security gap

Central IT-Security policy and guidelinies

Factory

Business unit

Local

Level of requirement (Terminology)

1. Must

2. Should (Shall)

3. Ought

4. Could

• In reading or in writing?

In the ”real” world

• Documentation is used for• Quality assurance• Homogeneity in the way of doing things

• Priority1. Written guidelines (Easy to see what the staff do)2. Verbal guidelines to follow (Praxis should be in accordance with what the staff tell

you)3. Nothing (A problem)

• State • Guidelines• Reality (the guidelines ”wont” be used ?)• Be granted an exemption from the IT Security department

• Important to find a balance between what you create of paperworks, documentation and what will be used in the future

IT-SecurityPolicy

IT-SecurityGuideline

# 1

IT-SecurityGuideline

# 2

IT-SecurityGuideline

# 3

IT-SecurityGuideline

# 3(local)

IT-SecurityStandard

IT-SecurityPolicy

IT-SecurityStandard

Evolution (obsoleted and new)

• Who should take care?– Standards

• BS7799 will soon be available in a new version

– IT Security Policy

• How to handle the relation to IT Security Guidelines?

Requirements Controls

IT-Security IT-Audit

IT-SecurityPolicy

IT-SecurityGuideline

# 1

IT-SecurityGuideline

# 2

IT-SecurityGuideline

# 3

IT-SecurityGuideline

# 3(local)

IT-SecurityStandard

IT-AuditPolicy

IT-AuditGuideline

# 1

IT-AuditGuideline

# 2

IT-Audittest

Audit (Internal – External)IT-Security department

IT Security Requirements

• Protection requirements• Safeguards

– Controls1. Preventive (before)

2. Detective (during)

3. Corrective (after)

THREATSThese are things that can go wrong or that can 'attack' the system. Examples might include fire or fraud. Threats are ever present for every system.

 VULNERABILITIES These make a system more prone to attack by a threat or make an attack more likely to have some success or impact. For example, for fire a vulnerability would be the presence of inflammable materials (e.g. paper).

 CONTROLSThese are the countermeasures for vulnerabilities. There are four types: 

•Deterrent controls reduce the likelihood of a deliberate attack •Preventative controls protect vulnerabilities and make an attack unsuccessful or reduce its impact •Corrective controls reduce the effect of an attack •Detective controls discover attacks and trigger preventative or corrective controls.

Key Controls

• Process– Change management– Incident management