1. Why requirements ? Feeling of: –Trust –Reliability –Confidence –Predictability –Stability Guarantee for everything is all right

2. Høj Middel Lav Høj Middel Lav Trusselvurdering Trusselniveau Konsekcens Sandsynlighed 1 2 34 5 6 7 8 A B CD Høj Middel Lav Middel Høj Risikovurdering Risikoniveau Trusselniveau Kontrolmiljø 1 2 3 4 5 6 7 8 A B CD Requirement: move risk items out of the red area

3. Requirements Høj Middel Lav Middel Høj Risikovurdering Risikoniveau Trusselniveau Kontrolmiljø 1 2 3 4 5 6 7 8 A B CD Controls

4. 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?

6. 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

7. IT Security requirements Law (invariable) –National and International Regulation Rules Standard Policy Guidance - Guidelines Procedure Instruction (Manual operation)

11. Guidance on the departmental order - new Act

13. Standard/RegulationIndustryComments/URLs ISO/IEC 17799International - Baseline"The International Organization for Standardization" www.iso-17799.comwww.iso-17799.com BS 7799 Part 1British GovernmentBritish Standard. Predecessor to ISO 17799 standard AS4444/NZS4444Australian GovernmentAustralian Standard/New Zealand Standard. Replaced by ISO 17799 standard HIPAAHealth CareHealth Insurance Portability And Accountability Act of 1996. CIS BenchmarksWorldwide ConsortiumThe Center for Internet Security Solaris Benchmark Gramm-Leach-Bliley Act (GLBA)US Financial Services LawUS Legislation passed Nov. 1999. SANS/FBI Top 20 ListGeneral SecuritySystem Administration, Networking and Security/Federal Bureau of Investigation CVEGeneral SecurityMITRE's Common Vulnerabilities and Exposures VISABankingVisa International and Visa USA ISO 15408 (Common Criteria)International Security Program - SystemsMay be replacing NSA's Red Book and Orange Book CASPRGNU Best PracticesCommonly Accepted Security Practices & Recommendations OCCBankingOffice of the Comptroller of the Currency FDICBankingFederal Deposit Insurance Corporation SysTrustAICPAAmerican Institute of Certified Public Accountants FISCAMGAO (Federal Govt.), Financial SystemsFederal Information Systems Control Audit Manual CobiTISACAControl Objectives for Information and Related Technology IETF Security HandbooksInternet CommunityThe Internet Engineering Task Force SECBrokerageU.S. Securities and Exchange Commission Rainbow Series (Orange Book)Military commands and contractorsBeing replaced by Common Criteria FDAPharmaceuticalFood and Drug Administration NPG 2810 (NASA)Facilities and ContractorsNASA Policy Guideline 1974 Privacy Act and AmendmentsUS Companieswww.usdoj.gov/04foia/privstat.htm ISO 13335(Parts 1,2,3,4,5)International - EducationalA five-part technical report giving guidance on security management. SAS70AuditingStatement on Auditing Standards GASSPOlder than CASPRGenerally Accepted Systems Security Principles DITSCAP/NIACAPDepartment of Defense (DOD)DoD Information Technology Security Certification and AccreditationProcess AS/NZS 4360:1999Australian/New Zealand GovernmentAustralian Standard / New Zealand Standard FCCUS GovernmentFederal Communications Commission

14. 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

15. 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.Control Objectives for Information and related TechnologyInformation Systems Audit and Control Association 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.International Organization for Standardization 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.Information Technology Infrastructure Library

16. 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

17. 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)

18. 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

19. 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

20. Section 6 - Computer & Network Management Objectives: 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 Control Objectives: 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 Maintenance Objectives: 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 Planning Objectives: To counteract interruptions to business activities To critical business processes from the effects of major failures or disasters. Section 10 - Compliance Objectives: 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.

21. IT-Security Policy IT-Security Guideline # 1 IT-Security Guideline # 2 IT-Security Guideline # 3 IT-Security Guideline # 3 (local) IT-Security Standard Implementation Standards (Service Providers) Interpretation Guides (Users and Managers)

22. 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

23. 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

24. An approach for formulating a Security Policy Security 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

25. APPROACH IS 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."

26. 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.

27. FORMING A POLICY With 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

28. 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

29. 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

33. 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 ?

34. Security gap Central IT-Security policy and guidelinies Factory Business unit Local

35. Level of requirement (Terminology) 1.Must 2.Should (Shall) 3.Ought 4.Could In reading or in writing?

36. In the ”real” world Documentation is used for Quality assurance Homogeneity in the way of doing things Priority 1.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

37. IT-Security Policy IT-Security Guideline # 1 IT-Security Guideline # 2 IT-Security Guideline # 3 IT-Security Guideline # 3 (local) IT-Security Standard IT-Security Policy IT-Security Standard

38. 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?

39. RequirementsControls IT-SecurityIT-Audit

40. IT-Security Policy IT-Security Guideline # 1 IT-Security Guideline # 2 IT-Security Guideline # 3 IT-Security Guideline # 3 (local) IT-Security Standard IT-Audit Policy IT-Audit Guideline # 1 IT-Audit Guideline # 2 IT-Audit test Audit (Internal – External) IT-Security department

41. IT Security Requirements Protection requirements Safeguards –Controls 1.Preventive (before) 2.Detective (during) 3.Corrective (after)

42. THREATS These 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). CONTROLS These 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.

44. Key Controls Process –Change management –Incident management