• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
*αí*ß
 

*αí*ß

on

  • 733 views

 

Statistics

Views

Total Views
733
Views on SlideShare
733
Embed Views
0

Actions

Likes
1
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    *αí*ß *αí*ß Presentation Transcript

    • Why requirements ?
      • Feeling of:
        • Trust
        • Reliability
        • Confidence
        • Predictability
        • Stability
      • Guarantee for everything is all right
    • Høj Middel Lav Høj Middel Lav Trusselvurdering Trusselniveau Konsekcens Sandsynlighed 1 2 3 4 5 6 7 8 A B C D Høj Middel Lav Lav Middel Høj Risikovurdering Risikoniveau Trusselniveau Kontrolmiljø 1 2 3 4 5 6 7 8 A B C D Requirement: move risk items out of the red area
    • Requirements Controls Høj Middel Lav Lav Middel Høj Risikovurdering Risikoniveau Trusselniveau Kontrolmiljø 1 2 3 4 5 6 7 8 A B C D
    • 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:
      • Security Policy
      • Security Organization
      • Asset Classification and Control
      • Personnel Security
      • Physical and Environmental Security
      • Computer and Network Management
      • System Access Control
      • System Development and Maintenance
      • Business Continuity and Disaster Recovery Planning
      • 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 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.
    • 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)
    • 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
        • A security policy is a document that sets the rules and principles, which affects the way an organization approaches problems.
        • 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.
        • 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.
        • 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.
        • 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.
        • 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 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
      • 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, &quot;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.&quot;
      • Kadam feels it isn't right to involve only technical people when formulating the policy. &quot;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.&quot;
      • Another malpractice is having a lengthy and complex policy that few understand.
      • &quot;Hitherto, organizations typically developed a security policy that was a voluminous document that few read, hence it wasn't fully implemented ,&quot; says Himanshu Khanna, Head-Technology, iServ India. &quot;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.&quot;
      • 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.
      • &quot;All business users who access information should be involved,&quot; says Kadam. &quot;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.&quot;
      • 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.
      • &quot;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,&quot; says Desai.
      • 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
    • 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
      • Choose one guideline from ISF
        • Example CN23
        • Just follow ”The One and only”
      • Choose three guidelines from ISF
        • Example CN23+CB53+SM54
        • ” Shake up” the three guidelines an create your own
        • Make the new guideline more specific
      • Do something different ?
    • Security gap Central IT-Security policy and guidelinies Factory Business unit Local
    • Level of requirement (Terminology)
      • Must
      • Should (Shall)
      • Ought
      • Could
      • In reading or in writing?
    • In the ”real” world
      • Documentation is used for
          • Quality assurance
          • Homogeneity in the way of doing things
      • Priority
          • Written guidelines (Easy to see what the staff do)
          • Verbal guidelines to follow (Praxis should be in accordance with what the staff tell you)
          • 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-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
    • 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-Audit Policy IT-Audit Guideline # 1 IT-Audit Guideline # 2 IT-Audit test Audit (Internal – External) IT-Security department 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 Requirements
      • Protection requirements
      • Safeguards
        • Controls
          • Preventive (before)
          • Detective (during)
          • Corrective (after)
      • 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.
    •  
    • Key Controls
      • Process
        • Change management
        • Incident management