Embed Size (px)
Citation preview
Incident Management
By Marc-André LégerDESS, MASc, PHD(candidate) Winter 2008
Save the forest
• If you really need to print…• Please do not print out more than one module at a
time as it may evolve…
Course information
• Course Title: Security Incident Management
• Course Duration: 75 hours
• Course Number: 420-
• Course Credits: 2.00
• Course Weighting: 4-1-4
The teacher
• Marc-André Léger
• DESS in Healthcare Informatics
• MASc in Management Information Systems
• PHD candidate in Clinical Sciences – Risk Management in Healthcare
• 25+ years IT experience– Qc, NB, Ontario, USA, France
• 20+ years security
Course Description
• This course leads students through the step-by-step process of dealing with a security incident.
• Encompassing:– incident response handling– Forensics– business continuity– disaster recovery
Course Objectives
Enable student to:• Explain the incident report handling process• Describe and define and apply basic concepts
of computer forensics• Explain the procedure of computer security
auditing• Define and explain organizational policies as
they pertain to computer security• Explain Business Continuity and Disaster
Recovery Planning and describe their application
Course evaluation
• A home assignments : 20%
• An in-class presentations : 10%
• A mid-term exam : 15%
• A final paper : 20%
• A final exam : 35%
1: Information Security Policy
• Individual
• Students will write a Security Policy
• For St-Lawrence Sawmill
• Following the model proposed in the Class.
2: In-class presentation
• Individual presentation
• Presentation to the board of directors
• The board will evaluate your proposal using an evaluation template
• Students may elect to present their term paper to the class rather than the Security Policy.
3: Term Project
• Student will select a topic
• Write a term paper on the subject. Topics must be related to the course.
• Term paper must be 7 to 10 pages and include a table of contents and a bibliography.
Session 1
Basics of computer incident and incident Handling
Basics of computer incident
Definitions
• During the semester we will build a definitions page…
Actions based on severity
• Incident response is often based on the evaluation of the severity of an event– Low impact incidents require a more moderate
response effort than a high impact incident.
• The evaluation of severity is subjective and often determined by user perception.
Incident handling based on severity
• LOW– Loss of passwords, – unauthorised sharing of passwords,– successful/unsuccessful scans/probes, – hardware misuse
Incident handling based on severity
• MEDIUM– Property destruction, – illegal download of music/files or unauthorised
software,– unauthorised use of system for personal data, – acts by disgruntled employees, – illegal hardware access/tress pass, – theft (minor)
Incidents handling based on severity
• HIGH– Child pornography, – pornography, – personal theft, – property destruction, – break-in, – illegal software download, – malicious code ( viruses, worms, trojan horses,
malicious scripts,…), – changes to system hardware, software, or
firmware, – violation of law.
Types of incidents
• 3 basic types:– End user detected incidents– Application detected incidents– System detected incidents
End user detected incidents
• Unavailability of web pages
• Download of file containing virus/worm
• Abnormal behavior of web site
• Spam
• Distribution of pornography
• Unusual request of personal information (ebay, Nigerian scams)
Application detected incidents
• Abnormal behavior of an application
• Inappropriate use of application (eg., unauthorised access)
• Unauthorised change of data (eg., defacement of web pages, alteration of data,…)
System detected incidents
• Detected by intrusion detection systems
• Detected by analysis of firewall logs
• Viruses/worms detected by servers
• Unavailability of servers (DoS attacks)
• Lack of remote availability of the system
• Detection of abnormal changes by monitoring software (eg., tripwire)
• Unauthorised access of servers,…
Reporting of incidents
• Users: In their interest to report the incident, usually to the “help desk”
• System administrators: Report to Computer Security Incident Response Team in the Company.
Typical sequence of events inIncident Response
Step 0: Abnormal behavior detected– Preparation– Detection– Containment– Eradication– Recovery– Follow-Up
Step 1: Identification of the incident– Is it real? (False alarms)– Determine the scope of the incident– Assess damage
Step 2: Notification of incident– Whom to notify– what to document– choice of language
Step 3: Protection of evidence– Audit records– Time-tagged actions taken in the investigation– Details of all external conversations– Collecting evidence
Step 4: Containment– Decision whether to shut down the system– How to shut down the system without losing or
corrupting the evidence
Step 5: Eradication– Collect all evidence before this step– Removal of the vulnerability
that caused the incident
Step 6 : Recovery from clean backups
Step 7: Follow up
• Post mortem of the incident
Incident Life Cycle• The CERT/CC incident handling life-cycle process.
Business Case
Saint Lawrence Sawmill
Business case
• Available online: www.leger.ca
• Sawmill producing lumber wood
• In La Tuque, Mauricie region
• 800 relatively unskilled workers
• Operates uninterrupted 24x7 (3 shifts of 8h)
• Part of a great industrial group, Bois St-Laurent
• HQ in Montreal
• In May 2006 it was purchased by SWP (Svirge Wood Products)
Current technological environment
• Minicomputer (IBM AS400)
• Custom built information system created by an external consultant
• Five workstations (PC) for administration used for the integration of data into the information system
• Printer for reports
• Oracle
Project name: SIGES
• Corporate management information system
• Connected to the corporate management system (ERP or entreprise ressource planning), SAP, located in Sweden
Proposed architecture
• Server: SUN Microsystems Sun Fire E20K
• Storage: Sun Storage Teak 9900
• 100 pc's for factory (adapted for use in factory)
• 10 workstations for management
• printers for reports
• Local area network 100-baseT commuted (switched) for the management network
• Wireless LAN in factory
• Wireless LAN access for conference rooms
• Virtual private network (VPN) with Sweden
Budget of the project of change
• Equipment: 500 000$
• Wiring and infrastructure: 100 000$
• Service Contracts: 50 000$ per year
• Software: 150 000$ + license fee – 15 000$ per year
• Configuration and conversion: 150 000$
• Training: 50 000$
• Consulting services: 350 000$
• Installation: 200 000$
• Contingencies (10%): 150 000$
Layout
End of this session
Session 2
Computer security policies
Security policy
Who Should Be Concerned• Managers• System designers• Users: what are the policy’s impacts on their
actions, and what are the ramifications of not following policy
• System administrators, support personnel who manage enforcement technologies and processes
• Company lawyers: they may have to use the written policies in support of actions taken against employees in violation
Policy Hierarchy
Multiple Levels
• Multiple levels of a policy may be in a single document, but the development of the complete policy is “top down”
• This refinement process level policies may be integrated into the system design process– For example, you cannot define a firewall policy
until you know your system will use a firewall as enforcement mechanism for a higher level policy
Policy Hierarchy
Policy
Standard 1 Standard 2 Standard 3
Procedure 1.1 Procedure 1.3 Procedure 1.3
Example of Hierarchical Policies
• High level:“company proprietary information shall be protected from release to unauthorized personnel”
Mid level procedural policy• All proprietary information shall have a
committee responsible for its control
• A member of that committee must authorize any distribution of that material
• Enforcement: training, audit
Mid level technology policy• Proprietary information may only be stored on
protected systems, accessible only to those with authorized access to the proprietary information
• There shall be no externally initiated, automated means to retrieve information from the protected systems– Low level; e. g., a firewall rule blocking incoming
traffic on ports 20 (ftp data), 21 (ftp control), and 69 (tftp)
– The firewall is the enforcement mechanism
Policy• Sets boundaries
Policy
• Greek– Politeia: citizenship– Polis: city
• Focused on creating sense of organisational citizenship amongst staff
• Compliance with policy – good citizen of organisational city; entitled to benefits of city
Policy
• Definition: Course of action adopted by a business, etc.*
• Development– Core team – business representatives– Reviewed & approved by governing body
* Oxford Dictionary of Current English, 1998
Policy• Communication mechanism
– Executive level + Employees– Defines how discipline is viewed – Provides direction
• Explains what organisational behaviour is supported– Specific actions prepared to take related to
discipline – Actions to be taken when directives not followed
• Not there to undermine way people work– Should educate employees, not scare them
3P model
• Prevent: provide proactive measures and awareness training
• Protect: provide baseline processes to implement technology and controls
• Punish: provide an incremental punitive process so you can enforce it at the appropriate time (cohersion)
Using standard
• Standards can be usefull to help define what is allowed within the organisational boundary
Standards
• Definition:– Object, quality or measure serving as basis to
which others conform or should conform or by which others are judged
– Level of excellence or quality required or specified
• Development– Core team – subject matter experts
Standards
• Standards are agreement between parties
• Specific set of rules to operate more uniformly & effectively
• Sets level of expectation
• Ensures consistent operations – Minimise risk– Increase efficiency
Procedures• How we act within the
organisational boundary
• How we achieve rules set out in standards
How to milk a cow…
1. Bring cow into barn2. Tell cow to stand still3. Fetch bucket and stool4. Sit on stool next to cow5. Squirt milk into bucket
Procedures
• Definition(s)– Way of performing a task
• OR– Series of actions conducted in a certain manner
• Development– Individuals responsible for daily tasks
Procedures
• Operational communication mechanism
• Plans / steps addressing specifics of how to go about particular action
• Transfer of knowledge between individuals who perform same job
• Reflect best practices / repetitive actions followed
Procedures• Provide detail to enable performance of
function without having to ask:– What
– Where
– Who
Examples
• Policy Statement– All users will be authenticated with passwords that
are changed on a periodic basis before being allowed access to the organisation’s information resources.
Examples
• Standard Statements– All passwords will be a minimum length of seven
characters and contain alphabetical, numeric and special characters.
– User passwords will be changed every thirty days.– The last ten passwords will be stored to prevent
re-utilisation thereof.
Examples
• Procedure Statement– To assign a password to a new user id, select the
User ID in the User Manager and right-click to view its properties.
– Select the password field and enter a password that conforms to the organisation’s password standards.
Drivers
• Compliance– Laws & regulations
• Audit requirements– Against which audit can be conducted
• Good practice– Industry standards
• Risk management– Manage risks related to employee behaviour
Policy Lifecycle
Policy Lifecycle
DEVELOP /AMEND
COMMUNICATE
MONITOR
REPORT
REMEDIATE
ARCHIVE
Policy Lifecycle
• Develop / Amend– Acquire senior level sponsorship & sign-off– Involve stakeholders in formulation– Ensure consistency with other policies
Policy Lifecycle
• Communicate– Use existing channels– Avoid jargon– Include third parties
Policy Lifecycle
• Monitor– Gather data related to compliance with policy– Aggregate data– Analyse data
Policy Lifecycle
• Report– Provide organisational wide view of policy
compliance– Identify breaches for investigation– Report to executive stakeholders
Policy Lifecycle
• Remediate– Understand problematic areas– Revise policy on periodic basis– Address policies that are impractical
Policy Lifecycle
• Archive– Adopt strict version control– Archive in case of legal or employment-related
action– Process as official records
Common Problems
• Fail to impact users ‘on the ground’
• Difficult to reflect organisation’s vision & mission
• Difficult to entrench in daily operations – nuisance factor
• Users ignorant of policy’s existence
• Users do not fully understand document
• Too long or too technical
Effective Policies
• Understandable
• Meaningful & practical
• Implementable, enforceable & realistic
• Inviting document
• Addresses users directly
• Convincing
Effective Policies
• Incorporates:– Nature of organisation– Organisational risk appetite– Organisational culture
Policy Development
DEVELOPMENT
PHASE
INITIALISATION
PHASE
FINALISATION & APPROVAL
PHASE
KEY ACTIVITIES Confirm Policy Framework Define Policy / Standard
Management Processes Confirm Document Format
KEY ACTIVITIES Research topic Prepare draft Workshop content Revisit content (Review cycle)
KEY ACTIVITIES Finalise Policies / Standards for Approval Present Policies / Standards for Approval
KEY DELIVERABLES Policy Framework Policy / Standard Management Processes Document Template
KEY DELIVERABLES Draft for discussion Final Draft
KEY DELIVERABLES Final Policies / Standards
Approach
Approach
• Content Development– No ‘cut & paste’– Developed in conjunction with stakeholder
representation – not only technical staff– Wording of principle statements very important
Key Success Factors
• Styling– Consistent with overall communication style– Fit in with organisational culture– User-friendly & clear – no ‘thou shallt nots’
• Formatting– Short, easy to read (1 - 5 pages)– Visual impact
Key Success Factors
• Writing style– Reflect organisational culture & industry– Clear, comprehensive – no ambiguity– Avoid specific references to technology
Key Success Factors
• Presentation– Fun & attractive– Short, concise, to the point– Main document – brief, interesting cartoons,
dialogue– Supplementary policies, standards & guidelines to
support & detail specific topics– Quality deliverable - underlines importance
Key Success Factors
• Commitment– Buy-in from top management vital – people live by
example– Change of attitude & behaviour starts at top– Truly effective policy has support from all levels in
organisation
Key Success Factors
• Governance Processes– Content Review
• All stakeholders
– Quality Assurance
Policy Communication
Communication
• Dissemination– Users need to know about policy– Various methods
• Paper-based or electronic copies• Published on internal communication sites• Summarised policy on colourful brochures• Awareness sessions
– Creativity very important – marketing-drive
Policy Monitoring & Reporting
Monitoring & Reporting
• Monitoring / Auditing– Internal / External Audits– Employee Surveys / Competitions– Key Performance Indicators (KPIs)
• Disciplinary Action
Monitoring & ReportingOwner – Person responsible for KPI Definition of Key Performance Indicator
-Type, i.e. Strategic, Tactical or Operational-Title, i.e. descriptive name for KPI-Description, i.e. short description of KPI
Calculation – Brief description of metrics and actual calculation needed to successfully measure KPI
Unit – Measurement
Frequency – How often the KPI is measured
Value (RAG) – Value ranges for each category
Policy Remediation
Remediation
• Maintenance– Living document– Grow & develop with organisation– Advantages of regular updates
• In touch with organisational developments• Ensures document does not become static & outdated
– Change Management
Information Security & Acceptable Usage Policy
Background
INFORMATIONSECURITY POLICY
Acceptable UsagePolicy
(PERSONNEL SECURITY)
Third PartyAccess
ASSETCLASSIFICATION
& CONTROL
PHYSICAL &ENVIRONMENTAL
SECURITY
Protection againstMalicious Software
LogicalAccess
SYSTEMSDEVELOPMENT
& MAINTENANCE
BUSINESSCONTINUITY
MANAGEMENT
Outsourcing
Network Security
ElectronicCommunications
RemoteAccess
ORGANISATIONALSECURITY
COMMUNICATIONS& OPERATIONSMANAGEMENT
…...
…...
ACCESSCONTROL
COMPLIANCE- Disciplinary Action
- Monitoring
Background
• Importance of Information Security Policy– Explains need for information security to all role
players– Explains information security concepts & methods– Outlines roles & responsibilities of information
security organisation– Guides selection, use & management of
appropriate controls• Tools & Technology• Processes
Background
• Importance of Acceptable Usage Policy– Explains information security rules & boundaries
to everyday users– Guides behaviour, use & management of
information– Explains what may / may not be done with
organisation’s information– Outlines roles & responsibilities users– Supports Information Security Policy
Structure
1. Introduction
2. Executive Management Commitment
3. Compliance Statement
4. Policy Principles
5. Roles & Responsibilities
6. Appendices
Content
• Introduction– Need for Information Security
• Brief, introductory, emphasises organisation’s dependence on information
– Objectives & Benefits of Information Security• Linked to overall business strategy, goals, objectives,
nature of business
– Definition of Information Security• Brief, understandable, uniform understanding
Content
• Management Commitment – Demonstrates intention of succeeding with
Information Security
• Approval of Policy (Signature)– Prominent placing, highest signatory in
organisation
Content
• Sample
Content
• Compliance Statement– Ensures action can be taken if policy is not
adhered to
Content
• Policy Principles– General rules, correct behaviour– Based on areas of ISO17799
Content
• Roles & Responsibilities– Expected behaviour from all role players
Content
• Appendices– User Declaration – Abridged version of policy– Glossary– Cross-references to other policies, standards,
procedures
Content
• General Elements– Reference Number– Release Date– Version– Policy Review Statement
• Forces continuous improvement to implementation of policy
– Statement of Applicability
Development Guidance
• International Information Security Standards & Code of Practices– BS7799 / ISO17799 / ISO27001– BSI IT Baseline Protection Manual– COBIT– ISO13335-1– ISF’s Standard of Good Practice
Information security policy
Based on ISO/IEC 27002(2005)Section 5.1
ISO 27002 Control Objective
• To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.
Information security policy document
ISO/IEC 27002(2005)Control 5.1.1
ISO 27002 Control
• An information security policy document should be approved by management, and published and communicated to all employees and relevant external parties.
Implementation guidance
• The information security policy document should state management commitment and set out the organization’s approach to managing information security.
Other information
• The information security policy might be a part of a general policy document.
• If the information security policy is distributed outside the organisation, care should be taken not to disclose sensitive information.
Review of the information security policy
ISO/IEC 27002(2005)Control 5.1.2
ISO 27002 Control
• The information security policy should be reviewed at planned intervals or if significant changes occur to ensure its continuing suitability, adequacy, and effectiveness.
Implementation guidance• The information security policy should have an
owner who has approved management responsibility for the development, review, and evaluation of the security policy.
• The review should include assessing opportunities for improvement of the organization’s information security policy and approach to managing information security in response to changes to the organizational environment, business circumstances, legal conditions, or technical environment.The review of the information security policy should take account of the results of management reviews.
• There should be defined management review procedures, including a schedule or period of the review.
Input• The input to the management review should include
information on:a) feedback from interested parties;b) results of independent reviews (see 6.1.8);c) status of preventive and corrective actions (see 6.1.8 and 15.2.1);d) results of previous management reviews;e) process performance and information security policy compliance;f) changes that could affect the organization’s approach to managing
information security, including changes to the organizational environment, business circumstances, resource availability, contractual, regulatory, and legal conditions, or to the technical environment;
g) trends related to threats and vulnerabilities;h) reported information security incidents (see 13.1);i) recommendations provided by relevant authorities (see 6.1.6).
Output• The output from the management review should
include any decisions and actions related to:a) improvement of the organization’s approach to managing
information security and its processes;
b) improvement of control objectives and controls;
c) improvement in the allocation of resources and/or responsibilities.
• A record of the management review should be maintained.
• Management approval for the revised policy should be obtained.
End of this session
Session 3
Change management
Information security policy implementation
Change management
Information security policy implementation
Introduction
• information security policy:
– What it is
– How to write it
– How to implement it
– How to maintain it
Introduction• Policy: essential foundation of effective information security
program:• The success of an information resources protection program
depends on the policy generated, and on the attitude of management toward securing information on automated systems.
• The policy maker, set the tone and the emphasis on how important a role information security will have within an organisation.
• Your likely responsibility will be to set the information resource security policy for the organization with the objectives of reduced risk, compliance with laws and regulations and assurance of operational continuity, information integrity, and confidentiality.
Why Policy?
• A quality information security program begins and ends with policy
• Policies are least expensive means of control and often the most difficult to implement
Some basic rules must be followed when shaping a policy:
• Never conflict with law
• Stand up in court
• Properly supported and administered
• Contribute to the success of the organization
• Involve end users of information systems
The Bulls-eye Model
Policy Centric Decision Making
• Bulls-eye model layers:– Policies: first layer of defense– Networks: threats first meet organization’s
network– Systems: computers and manufacturing systems– Applications: all applications systems
• Policies are important reference documents for internal audits and for resolution of legal disputes about management's due diligence – Policy documents can act as a clear statement of
management's intent
Policies, Standards, & Practices
Policy, Standards, and Practices
• Policy: plan or course of action that influences and determines decisions
• Standards: more detailed statement of what must be done to comply with policy
• Practices, procedures and guidelines: explain how employees will comply with policy
For policies to be effective, they must be:
– Properly disseminated– Read– Understood– Agreed-to
Policy, Standards, and Practices
• Policies require constant modification and maintenance
• In order to produce a complete information security policy, management must define three types of information security policy:– Enterprise information security program policy– Issue-specific information security policies– Systems-specific information security policies
Enterprise Information Security Policy (EISP)
• Sets strategic direction, scope, and tone for organization’s security efforts
• Assigns responsibilities for various areas of information security
• Guides development, implementation, and management requirements of information security program
EISP Elements
• EISP documents should provide :– An overview of corporate philosophy on security– Information about information security
organization and information security roles• Responsibilities for security shared by all members of
the organization• Responsibilities for security unique to each role within
the organization
Components of the EISP
• Statement of Purpose: What the policy is for
• Information Technology Security Elements: Defines information security
• Need for Information Technology Security: justifies importance of information security in the organization
• Information Technology Security Responsibilities and Roles: Defines organizational structure
• References Information Technology standards and guidelines
Issue-Specific Security Policy (ISSP)
• Provides detailed, targeted guidance to instruct organization in secure use of technology systems
• Begins with introduction to fundamental technological philosophy of organization
• Serves to protect employee and organization from inefficiency/ambiguity
• Documents how technology-based system is controlled – Identifies processes and authorities that provide this
control
• Serves to indemnify organization against liability for inappropriate or illegal system use
Issue-Specific Security Policy (ISSP)
• Every organization’s ISSP should:– Address specific technology-based systems– Require frequent updates– Contain an issue statement on the organization’s
position on an issue
• ISSP topics could include:– E-mail, use of Internet and World Wide Web, specific
minimum configurations of computers to defend against worms and viruses, prohibitions against hacking or testing organization security controls, home use of company-owned computer equipment, use of personal equipment on company networks, use of telecommunications technologies, use of photocopy equipment
Components of the ISSP• Statement of Purpose
– Scope and Applicability– Definition of Technology Addressed– Responsibilities
• Authorized Access and Usage of Equipment– User Access– Fair and Responsible Use– Protection of Privacy
• Prohibited Usage of Equipment– Disruptive Use or Misuse– Criminal Use– Offensive or Harassing Materials– Copyrighted, Licensed or other Intellectual Property– Other Restrictions
Components of the ISSP• Systems Management
– Management of Stored Materials– Employer Monitoring– Virus Protection – Physical Security– Encryption
• Violations of Policy– Procedures for Reporting Violations– Penalties for Violations
• Policy Review and Modification– Scheduled Review of Policy and Procedures for
Modification• Limitations of Liability
– Statements of Liability or Disclaimers
Implementing ISSP
• Common approaches:– Number of independent ISSP documents– Single comprehensive ISSP document– Modular ISSP document that unifies policy
creation and administration
• Recommended approach is modular policy, which provides a balance between issue orientation and policy management
Systems-Specific Policy (SysSP)
• Systems-Specific Policies (SysSPs) frequently do not look like other types of policy
• They may often be created to function as standards or procedures to be used when configuring or maintaining systems
• SysSPs can be separated into:– Management guidance– Technical specifications– Combined in a single policy document
Password SysSP
Management Guidance SysSPs
• Created by management to guide the implementation and configuration of technology
• Applies to any technology that affects the confidentiality, integrity or availability of information
• Informs technologists of management intent
Technical Specifications SysSPs
• System administrators directions on implementing managerial policy
• Each type of equipment has its own type of policies
• Two general methods of implementing such technical controls:– Access control lists– Configuration rules
Access Control Lists• Include user access lists, matrices, and capability
tables that govern rights and privileges• Can control access to file storage systems, object
brokers or other network communications devices• Capability Table: similar method that specifies which
subjects and objects users or groups can access • Specifications are frequently complex matrices,
rather than simple lists or tables• Level of detail and specificity (often called
granularity) may vary from system to system– ACLs enable administrations to restrict access according
to user, computer, time, duration, or even a particular file
ACLs
• In general ACLs regulate:– Who can use the system– What authorized users can access– When authorized users can access the system– Where authorized users can access the system
from– How authorized users can access the system– Restricting what users can access, e.g. printers,
files, communications, and applications
ACLs (Continued)
• Administrators set user privileges, such as:– Read– Write– Create– Modify– Delete– Compare– Copy
Configuration Rules
• Configuration rules are specific configuration codes entered into security systems to guide execution of system when information is passing through it
• Rule policies are more specific to system operation than ACLs and may or may not deal with users directly
• Many security systems require specific configuration scripts telling systems what actions to perform on each set of information processed
Firewall Configuration Rules
Combination SysSPs
• Often organizations create a single document combining elements of both Management Guidance and Technical Specifications SysSPs
• While this can be confusing, it is very practical
• Care should be taken to articulate required actions carefully as procedures are presented
Guidelines for Policy Development
• Often useful to view policy development as a two-part project– Design and develop policy (or redesign and
rewrite outdated policy)– Establish management processes to perpetuate
policy within organization
• The former is an exercise in project management, while the latter requires adherence to good business practices
The Policy Project
• Policy development or re-development projects should be well planned, properly funded, and aggressively managed to ensure completion on time and within budget
• When a policy development project is undertaken, the project can be guided by the SecSDLC process
Investigation Phase• The policy development team should:
– Obtain support from senior management, and active involvement of IT management, specifically CIO
– Clearly articulate goals of policy project– Gain participation of correct individuals affected by
recommended policies– Be composed from Legal, Human Resources and end-
users – Assign project champion with sufficient stature and
prestige– Acquire a capable project manager– Develop detailed outline of and sound estimates for the
cost and scheduling of the project
Analysis Phase
• Analysis phase should include the following activities:– New or recent risk assessment or IT audit
documenting the current information security needs of the organization
– Key reference materials—including any existing policies
Design Phase
• Design phase should include:– How policies will be distributed– How verification of distribution will be
accomplished– Specifications for any automated tools – Revisions to feasibility analysis reports based on
improved costs and benefits as design is clarified
Implementation Phase
• Implementation Phase: writing the policies
• Make certain policies are enforceable as written
• Policy distribution is not always as straightforward
• Effective policy – Is written at a reasonable reading level– Attempts to minimize technical jargon and
management terminology
Maintenance Phase
• Maintain and modify policy as needed to ensure that it remains effective as a tool to meet changing threats
• Policy should have a built-in mechanism via which users can report problems with the policy, preferably anonymously
• Periodic review should be built in to the process
SP 800-18: Guide for Developing Security Plans
• NIST Special Publication 800-18 offers another approach to policy management
• Policies:– Living documents that constantly change and
grow– Must be properly disseminated (distributed, read,
understood and agreed to) and managed
SP 800-18: Guide for Developing Security Plans
• Good management practices for policy development and maintenance make for a more resilient organization
• In order to remain current and viable, policies must have:– Individual responsible for reviews – Schedule of reviews– Method for making recommendations for reviews– Indication of policy and revision date
Final Notes
• Lest you believe that the only reason to have policies is to avoid litigation, it is important to emphasize the preventative nature of policy
• Policies exist first, and foremost, to inform employees of what is and is not acceptable behavior in the organization
• Policy seeks to improve employee productivity, and prevent potentially embarrassing situations
End of this session
Session 4
Writing a security policy for St-Lawrence Saw Mill
Policy (from session 2)• Communication mechanism
– Executive level + Employees– Defines how discipline is viewed – Provides direction
• Explains what organisational behaviour is supported– Specific actions prepared to take related to
discipline – Actions to be taken when directives not followed
• Not there to undermine way people work– Should educate employees, not scare them
3P model (from session 2)
• Prevent: provide proactive measures and awareness training
• Protect: provide baseline processes to implement technology and controls
• Punish: provide an incremental punitive process so you can enforce it at the appropriate time (cohersion)
Drivers (from session 2)
• Compliance– Laws & regulations
• Audit requirements– Against which audit can be conducted
• Good practice– Industry standards
• Risk management– Manage risks related to employee behaviour
Policy Lifecycle (from session 2)
DEVELOP /AMEND
COMMUNICATE
MONITOR
REPORT
REMEDIATE
ARCHIVE
Structure (from session 2)
1. Introduction
2. Executive Management Commitment
3. Compliance Statement
4. Policy Principles
5. Roles & Responsibilities
6. Appendices
Investigation Phase (from session 3)
• The policy development team should:– Obtain support from senior management, and active
involvement of IT management, specifically CIO– Clearly articulate goals of policy project– Gain participation of correct individuals affected by
recommended policies– Be composed from Legal, Human Resources and end-
users – Assign project champion with sufficient stature and
prestige– Acquire a capable project manager– Develop detailed outline of and sound estimates for the
cost and scheduling of the project
Analysis Phase (from session 3)
• Analysis phase should include the following activities:– New or recent risk assessment or IT audit
documenting the current information security needs of the organization
– Key reference materials—including any existing policies
Design Phase (from session 3)
• Design phase should include:– How policies will be distributed– How verification of distribution will be
accomplished– Specifications for any automated tools – Revisions to feasibility analysis reports based on
improved costs and benefits as design is clarified
Implementation Phase (from session 3)
• Implementation Phase: writing the policies
• Make certain policies are enforceable as written
• Policy distribution is not always as straightforward
• Effective policy – Is written at a reasonable reading level– Attempts to minimize technical jargon and
management terminology
Maintenance Phase (from session 3)
• Maintain and modify policy as needed to ensure that it remains effective as a tool to meet changing threats
• Policy should have a built-in mechanism via which users can report problems with the policy, preferably anonymously
• Periodic review should be built in to the process
So let’s write a policy…
End of this session
Session 5
Business Impact Analysis
Threat and Risk Assessments
Lab: using a TRA methodology
Business Impact Analysis
What is Business Impact Analysis?
• A technique for identifying both tangible and intangible impacts on a business process, function or department usually over time, based on given criticalities.
• It provides senior management with the information to devise a recovery strategy and recovery prioritization.
• Provides supporting data to define an appropriate DR program budget.
Business Impact Analysis
• Identifies who and what are vital to the business’s survival.– Internal – suppliers, customers, shareholders, IT
systems, manufacturing processes.– External – government departments, regulators,
trade bodies, competitors, pressure groups.
• Evaluates recover priorities and time scales.– Criticality of each function to business survival.
• Assesses the potential cost of disaster.– Direct and indirect costs of loss of service
capability.
Business Impact Analysis
• Identifies the high risk areas of the existing infrastructure– Single points of failure– Recovery time limitations
• For IT systems in particular:– Identifies the business critical applications and the
systems they run on.– Identifies the areas of vulnerability within the
environment.
Business Impact Analysis
• Focuses on the delivered service:– Business applications: CRM, order processing,
dispatch, billing etc.– Internal applications: pay roll, HR etc.– Communications: e-mail, web sites etc.
• IT may have become the business.
• How does not having the capability affect the business?– Is the application critical to the business?– Is the function duplicated elsewhere– What viable alternatives exist?
Costs of a Disaster• Loss of vital records• Fee collection• License issuance• Welfare delivery• Child protection• Police protection• Brand image recovery• Loss of share value • Loss of interest on
overnight balances; cost of interest on lost cash flow
• Delays in customer accounting, accounts receivable and billing/invoicing
• Loss of control over debtors
• Loss of credit control and increased bad debt.
• Delayed achievement of benefits of profits from new projects or products
• Cost of replacement of buildings and plant
Costs of a Disaster (cont’d)• Loss of revenue for service
contracts from failure to provide service or meet service levels
• Lost ability to respond to contract opportunities
• Penalties from failure to produce annual accounts or produce timely tax payments
• Where company share value underpins loan facilities, share prices could drop and loans be called in or be re-rated at higher interest levels.
• Cost of replacing equipment• Cost of replacing software• Salaries paid to staff unable
to undertake billable work• Salaries paid to staff to
recover work backlog and maintain deadlines
• Cost of re-creation and recovery of lost data
• Loss of cash flow• Interest value on deferred
billings
Costs of a Disaster (cont’d)• Penalty clauses invoked
for late delivery and failure to meet Service Levels
• Loss of customers (lifetime value of each) and market share
• Loss of profits• Additional cost of credit
through reduced credit rating
• Recruitment costs for new staff on staff turnover
• Training / retraining costs for staff
• Fines and penalties for non-compliance
• Liability claims• Additional cost of
advertising, PR and marketing to reassure customers and prospects to retain market share
• Additional cost of working; administrative costs; travel and subsistence etc.
Disaster Costs SummaryLost Revenue• Direct Loss
• Compensatory Payments
• Lost Future Revenues
• Investment Loss
Productivity Loss• Number of Fully Burdened
Employee impacted
Damaged Reputation • Customer, Suppliers,
Partners, Banks, Financial Markets
• Credit Ratings
Delayed Collections• Billing Losses
• Missed Discounts
Extra Expense• Cost to Recover
• Overtime Expense
• Increased Fraud Risk
• Increased Error Rate
• Travel Expenses
• Temporary Employees
Penalties • Contractual
• Regulatory
• Legal
DRI International
Disaster Recovery Benefits
• Reducing legal liability
• Minimizing potential economic loss
• Decreasing potential exposure
• Reducing the probability of a disaster occurrence
• Reducing disruption to normal operations
• Ensuring organizational stability
• Ensuring orderly recovery
Disaster Recovery Benefits
• Minimizing insurance premiums
• Reducing reliance on key personnel
• Increasing asset protection
• Ensuring safety of personnel and customers
• Complying with legal, statutory, and regulatory requirements
Business Impact Analysis Benefits
• Helps business and IT identify and prioritize critical systems and applications as they support business functions.
• Helps identify and define recovery priorities.
• Determines the cost of downtime which will help define a reasonable DR budget.
• Provides hard data to present to management to justify the DR budget.
What about my Y2K plans?
• It’s 3 years old now.
• Your business priorities have changed.
• Your environment has changed.– More systems, more data, more sites, more
critical applications, more services to provide.– Fewer people who generally have less time to
take systems down for maintenance and system administration.
– Your support environment may have well changed too.
What about my Y2K plans?
• Y2K plans generally did not address cost issues of an outage.
• Y2K plans do not provide the necessary prioritized cost justification data (that a Business Impact Analysis would) in order for senior management to make informed decisions on implementing disaster recovery technologies.
Impact of having no BIA
• “CIOs who fail to conduct a business impact analysis risk over-committing or under-investing resources in disaster prevention and contingent recovery operations. ”
META Group
Bottom Line
• “Savvy CIOs address disaster recovery requirements by leading with a business impact analysis to balance risks with the cost of disaster prevention/mitigation controls and contingent solutions.”
META Group
Threat and Risk Assessments
Threat Vulnerability
Impact ($)
Impact (Other)
Value
Total:
Lab: using a TRA methodology
End of this session
Incident managementSession 6
Student presentationsInvestigation practices
Legal and ethical aspects The chain of evidence.
Presentation byMr Marc-André Fortier, Consultant
Student presentations
Security policy
Investigation practices
The Investigative Process
• Acceptance: Process has wide acceptance
• Reliability: Methods used can be trusted to support findings
• Repeatability: Process can be replicated
• Integrity: Trust that the evidence has not been altered
• Cause & Effect: Logical relationship between suspects, events, evidence
• Documentation: Recording of evidence
Computer Forensics
• How to handle evidence?– What to search/seize?– What kind of evidence to gather? How?– Documenting the evidence gathered– How to maintain the authenticity of evidence?
What kind of evidence to gather?
• Secure the scene with yellow tape barriers to prevent bystanders from entering or interfering with investigation.
• The computer is just one of a number of types of evidence to be gathered
• DNA evidence from keyboard
• Fingerprint evidence (AFIS: Automated Fingerprint Identification System)
• Fingerprints of all people who had access to the crime scene
What kind of evidence to gather?• No one to examine the computer before the
bit stream image of the hard drive has been captured
• Follow the standards outlined in DOJ Manual• Keep journal on all significant activities,
people encountered.• Good idea to carry a tape recorder, and a still
pictures camera• Usually not a good idea to video tape the
scene. The defendant’s attorney may have access to it during trial.
What kind of evidence to gather?
• If the computer is on, – capture information on the processes, save data
on all current applications, photograph all screens.
– After saving all active files (preferably on external media, but if necessary to save on seized computer, save with a new name to avoid confusion), you can shut down the system.
• If the computer is off, you can acquire the evidence on hard drives (you will have lost the data in volatile memory)
What kind of evidence to gather?
• Tagging and bagging evidence (including software/hardware documentation)
• Precautions:– Grounding wristbands, static electricity resistant
floor mats– Mark location of collected evidence– Carry response kit (laptop, flashlight, digital
camera, IDE 40-to-44 pin adapters, computer toolkit, dictation recorder, evidence bags, labels, tags, tape, marking pens, floppy disks, evidence log forms,…)
Documenting the evidence
• Maintain either single or multiple evidence forms to document evidence gathered
• The forms should include: Case number/name, Nature of the case, for each item its description (model/serial numbers, manufacturer), case investigator, investigator recovering the evidence, location of original evidence,
Maintain authenticity of the evidence
• Maintaining authenticity provides assurance to the jury that the evidence is reliable and has not been tampered with.
• Authenticity is provided by cryptographic checksums (message digests or fingerprints).
• MD5 and SHA are two common hash algorithms used. They provide a fingerprint of the evidence gathered.
Maintain authenticity of the evidence
• Executable for MD5 algorithm can be downloaded from http://www.etree.org/software.html for various operating systems.– Example: In unix systems, if you want the MD5
digest of the files /etc/passwd and /etc/services files, you would
• Cat /etc/passwd and /etc/services >file• Md5sum file > file.md5
• Such algorithms are subject to cryptographic attack. Therefore it is important to provide some redundancy.
Maintain authenticity of the evidence
• Some software such as Tripwire compute hash values using multiple algorithms so that even if one algorithm becomes susceptible to attack, authenticity can be proven using other algorithms
• Whenever a copy of the evidence is to be produced, the authenticity of the copy can be shown by re-computing the hash value and comparing with the original
Legal and ethical aspects of evidence gathering
Evidence
Evidence is property that has significance as a means of determining the truth as an alleged matter of fact.
The chain of custody.
The chain of custody is necessary in order to establish the legal sufficiency of evidence once it has come into the custody of the police agency. That is to say that the evidence has not been lost, that no tampering of the evidence has occurred, and the evidence has not been contaminated, either by other evidence stored nearby, or the container in which the evidence is stored.
Chain of Custody
Maintaining the Chain of Custody
The number of persons handling evidence from the time it is secured should be limited.
Individuals who handle the evidence should affix their names and badge numbers on the seals
to the package containing the evidence and the chain of custody
sign in and out form/log.
BOOKING PROPERTY
• Policies and Procedures
• Packaging
• Evidence Seals
• Securing Evidence
• Documentation
Legal Requirements
• The property control system must meet all legal requirements. These include federal, state, and local laws and ordinances. These statutes and ordinances very often dictate the methods and procedures for handling, storage and disposal of property.
Packaging Packaging andand
handling of handling of evidenceevidence
– A. EVIDENCE ASSOCIATED WITH ANY CRIME CAN BE SO VARIED IN TYPE, PHYSICAL STRUCTURE, ETC, AND IT IS SO SUSCEPTIBLE TO CHANGE THAT NO SET OF STANDARD RULES OR PROCEDURES CAN ADEQUATELY DESCRIBE HOW EACH AND EVERY ITEM SHOULD BE PACKAGED AND SUBMITTED.
• B. FAILURE TO COLLECT AND PROPERLY PACKAGE OR PRESERVE YOUR EVIDENCE CAN SOMETIMES AFFECT THE OUTCOME OF YOUR CASE.
• C. EVIDENCE MATERIAL SHOULD BE PACKAGED, STORED AND PRESERVED IN THE SAME CONDITION IN WHICH IT IS FOUND IN ORDER TO MAINTAIN ITS EVIDENTIARY PROPERTIES.
• D. EVIDENCE MUST BE PACKAGED AND TREATED IN A MANNER THAT WILL REDUCE TO A MINIMUM ANY INFLUENCE WHICH THREATENS ITS EVIDENTIAL VALUE.
• E. WHEN SELECTING CONTAINERS FOR PACKAGING, CERTAIN FACTORS SHOULD BE CONSIDERED
• CLEANLINESS OF YOUR CONTAINERS• CONTAINERS OF A SUFFICIENT SIZE FOR
THE EVIDENCE. • THE CORRECT CONTAINER FOR THE
EVIDENCE,E.G, PLASTIC, PAPER, ETC.• STORAGE OF LIQUID SAMPLES SHOULD
BE SUBMITTED IN A PLASTIC BOTTLE ENCLOSED IN A PLASTIC BAG, SEALED IN AN EVIDENCE ENVELOPE/ BAG.
• EACH EVIDENCE PACKAGE SHOULD BE PROPERLY LABELED FOR IDENTIFICATION.
VI. PROPERTY TAG
• A. PROPERTY TOO LARGE FOR AN EVIDENCE ENVELOPE MUST HAVE AN ATTACHED PROPERTY TAG.
• B. THE SAME PERTINENT INFORMATION THAT IS ON THE PROPERTY REPORT MUST ALSO BE FILLED OUT ON THE ATTACHED PROPERTY TAG.
• C. THE EVIDENCE ENVELOPES, PROPERTY TAGS AND THE PROPERTY REPORT FORMS ARE THE SOURCE DOCUMENTS FOR ALL PROPERTY HELD BY THE PROPERTY SECTION.
How computers work: A Forensic perspective?
– Boot Sequence– How data is stored and how can it be viewed?
How Computers Work?
• Computer Components
• What happens when you turn the computer on?
• What is a File System?
• How is data stored on disks?
• How data is represented in computers and how it can be looked at?
• How is data in windows 2000 encrypted?
Digital Evidence
• Sources of evidence on the internet?– Evidence can reside on the computers, network
equipment (routers, for example), and on servers– Various tools are available to extract evidence
from these sources
Evidence on workstations & Servers• Locations (Disks)
– Disk partitions, inter-partition gaps (not all partitions may have file systems. For example, swap space in unix systems do not have file systems)
– Master Boot Record (contains partition table)– Boot sector (has file system information)– File Allocation Tables (FAT)– Volume slack (space between end of file system and end
of the partition)– File slack (space allocated for files but not used)– RAM slack (in case of pre windows 95a, space between
end-of-file and end-of-sector)– Unallocated space (space not yet allocated to files. Also
includes recently deleted files, some of which might have been partially overwritten)
Evidence on workstations, Servers
• Locations (Memory or RAM)– Registers & Cache (usually not possible to
capture. Cache can be captured as part of system memory image)
– RAM– Swap space (on disk)
Evidence on Servers & Network Equipment
• Router systems logs
• Firewall logs of successful and unsuccessful attempts
• Syslogs in /var/logs for unix systems
• wmtp logs (accessed with last command) in unix systems
Evidence on Workstations, Servers, Network: Important Points• It is possible to hide partitions
• It is possible to hide data in files using streams so they are not visible. You can know of their existence only by analyzing the Master File Table
• It is possible to hide data in inter-partition gaps, volume slack
• It is possible to hide data at the end of the drive by declaring drive size smaller than its actual size.
Types of Evidence
• Physical evidence (computers, network equipment, storage devices,…)
• Testimonial evidence
• Circumstantial evidence
• Admissible evidence (evidence that a court accepts as legitimate)
• Hearsay evidence
Hearsay Evidence: Exception (USA)• “A memorandum, report, record, or data compilation, in any
form, of acts, events, conditions, opinions, or diagnoses, made at or near the time by, or from information transmitted by, a person with knowledge, if kept in the course of a regularly conducted business activity, and if it was the regular practice of that business activity to make the memorandum, report, record or data compilation, all as shown by the testimony of the custodian or other qualified witness, or by certification that complies with Rule 902(11), Rule 902(12), or a statute permitting certification, unless the source of information or the method or circumstances of preparation indicate lack of trustworthiness.”
• Source: Federal Rules of Evidence:http://www.law.cornell.edu/rules/fre/rules.htm
Characteristics of Evidence• Authenticity (unaltered from the original)• Relevance (relates crime, victim and
perpetrator)• Traceability (audit trail from the evidence
presented back to the original)• Complete (presents total perspective on the
crime. Ideally, should include exculpatory evidence)*
• Reliable (one should not be able to doubt the authenticity and traceability of the evidence collection and chain of custody)
Characteristics of Evidence
• Believable (jury should be able to understand the evidence)
Evidence Collection Principles
• Maintain chain of custody of the evidence
• Acquire evidence from volatile as well as non-volatile memory without altering or damaging original evidence
• Maintain the authenticity and reliability of evidence gathered
• No modification of data while analyzing it
Maintaining Chain of Custody
• Movement of evidence from place to place must be documented
• Changing of hands in custody of the evidence must be documented
• There must be no gaps in the custody of the evidence
Volatile & Non-volatile memory
• Places where evidence may reside– Memory
– Hard drives• File systems• Parts of disk with no file system loaded
Memory– In MS-Windows 2000,
• setting up the Registry to enable capturing memory.dmp manually
• Using Dumpchk.exe to generate memory dump
– In unix systems, using /etc/sysdump to generate a live dump of /dev/mem, and using /etc/crash to analyze the dump
Volatile & Non-volatile memory
• Hard Drives– Imaging: Non-destructive Sector-by-Sector copy
of the drive that does not require the machine to be booted
NIST requirements for imaging tools:
• Tool make Bit-stream copy or image of the disk or partition if there are no access errors
• No altering of the disk by the tool• Tool must access both IDE and SCSI• Tool must verify integrity of the image file• Tool must log I/O errors, and create a qualified bit-
stream duplicate identifying the areas of bit-stream in error
• Tool’s documentation must be correct• Notify user if source disk is larger than destination disk
Volatile & Non-volatile memory
• Some tools:– Linux dd (www.redhat.com)– SnapBack DatArrest (www.snapback.com)
Authenticity & Reliability of evidence gathered
• Time Synchronization problems in networks– If the times on various machines are not
synchronized, the evidence collected may not have strength
– Network Time Protocol (NTP) supported on Unix, Linux, but not supported in Windows. However there are third-party tools such as those found at
• www.oneguycoding.com/automachron• NIST Internet Time Service
www.nist.gov/timefreq/service/its.htm• www.pawprint.net/wt
Authenticity & Reliability of evidence gathered
– Time Stamping• Once the system is compromised, the perpetrator will
alter the logs to confuse the investigator• Digital time stamping service can be used
– www.datum.com– www.evertrust.com
• Use of Tripwire Monitoring & Reporting Software to monitor changes
How to obtain admissible evidence?
• The Forensic Investigation Process– Incident alert or accusation: violation of policy or
report of crime– Assessment of worth/damage: To set priorities– Incident/Crime scene protocols: Actions taken at
the scene– Identification and seizure of evidence:
Recognition of evidence and its proper packaging (protection)
– Preservation of evidence: Preserve the integrity of the evidence obtained
The Forensic Investigation Process– Recovery of evidence: recovery of hidden and
deleted information, recovery of evidence from damaged equipment
– Harvesting: Obtaining data about data– Data reduction: Eliminate/filter evidence– Organization and search: Focus on arguments– Analysis: Analysis of evidence to support
positions– Reporting: Record of the investigation– Persuasion and testimony: In the courts– (Source: Digital Evidence & Computer Crime,
Eoghan Casey, Elsevier, 2004)
End of this session
Session 7
Tools and best practices
CA Net Forensics
Tools
Incident handling toolkits
• Hardware:– Large capacity IDE & SCSI Hard drives, CD-R,
DVR drives– Large memory (1-2GB RAM)– Hubs, CAT5 and other cables and connectors– Legacy hardware (8088s, Amiga, …) specially for
law enforcement forensics– Laptop forensic workstations
Incident handling toolkits• Software
– Viewers (QVP http://www.avantstar.com/,ThumbsPlus http://www.thumbsplus.de/)
– Erase/Unerase tools: Diskscrub/Norton utilities)– CD-R, DVR utilities– Text search utilities (dtsearch http://
www.dtsearch.com/)– Drive imaging utilities (Ghost, Snapback, Safeback,
…)– Forensic toolkits
• Unix/Linux: TCT The Coroners Toolkit/ForensiX
• Windows: Forensic Toolkit
Forensic Boot Floppies
• Disk editors (Winhex,…)
• Operating systems
• Forensic acquisition tools (DriveSpy, EnCase, Safeback, SnapCopy,…)
• Write-blocking tools (FastBloc http://www.guidancesoftware.com) to protect evidence.
Policies
• Who can add or delete users?
• Who can access machines remotely
• Who has root level access to what resources (SetUID and sudo privileges)
• Control over pirated software
• Who can use security related software (network scanning/snorting, password cracking, etc.)
• Policy on internet usage
System backups
• Systems backups help investigation by providing benchmarks so that changes can be studied
• Unix:– dump: dump selected parts of an object file– cpio: copy files in and out of cpio archives– tar: create tape archives and add or extract files– dd: Convert and copy a file
System backups
• Windows:– Programs | Accessories | System Tools | Backup– NTBACKUP: Part of NT Resource kit– Backup : From disk to disk
What actions to take at the scene?
• Pull the plug? – Turnoff the machine? – Live forensics?
• What to search/seize?– What kind of evidence to gather?
• How to gather the evidence?
• How to maintain authenticity of the evidence?
Pull the plug?
• By pulling the plug you lose all volatile data. In unix system, you may be able to recover the data in swap space
• Perpetrator may have predicted the investigation, and so altered system binaries
• You can not use the utilities on the live system to investigate. They may have been compromised by the perpetrator
What to search/seize?
• Public investigations (criminal, usually by law enforcement agencies) vs. Corporate investigations.
• Public investigations, with search warrants, can seize all computers & peripherals, but fourth amendment provides protection
• Corporate investigators may not have the authority to seize computers, but may only allow one to make bit-stream copies of drives
Gathering evidence
Components of computers
• Central Processing Unit (CPU)
• Basic Input and Output System (BIOS)
• Memory
• Peripherals (disks, printers, scanners, etc)
Boot Sequence
• What happens when you turn the computer on?– CPU reset: when turned on, CPU is reset and
BIOS is activated– Power-On Self Test (POST) performed by BIOS:
• Verify integrity of CPU and POST• Verify that all components functioning properly• Report if there is a problem (beeps)• Instruct CPU to start boot sequence
– (System configuration & data/time information is stored in CMOS when the computer if off. POST results compared with CMOS to report problems)
Boot Sequence– Disk boot: Loading of the operating system from
disk into memory. The bootstrap is in Read-Only-Memory.
Important Points
• CMOS chip contains important evidence on the configuration. If the battery powering CMOS is down, important evidence may be lost (Moussaoui case, 2003)– If the computer is rebooted, the data on the hard
disk may be altered (for example the time stamps on files).
– Hence the importance of booting from a floppy and accessing the CMOS setup during the boot up.
Important Points– It is a good idea to obtain BIOS password from
user. Resetting CMOS password can change system settings and hence alter evidence. For example, you can change the boot sequence so that the computer accesses drive A first.
Important Points – It is possible to overwrite BIOS passwords using
services such as www.nortek.on.ca. However, one should use it as a last resort
Important Points – It may be necessary to physically remove the hard
disk to retrieve data
The File System
• File system is like a database that tells the operating system where is what data on the disks or other storage devices.– FAT in MS-DOS is a flat table that provides links
to their location on disks. But Microsoft’s NTFS is similar to unix file systems.
– In unix systems, it consists of a (inode) table providing pointers from file identifiers to the blocks where they are stored, and a directory.
The File System– Mounting a file system is the process of making the
operating system aware of its existence. When mounted, the operating system copies the file tables into kernel memory
– The first sector in a hard disk contains the master boot record which contains a partition table. The partition table tells the operating system how the disk is divided
– Partitions can be created and viewed using fdisk. Each partition contains the boot sector, primary and secondary file allocation tables (FAT), the root directory, and unallocated space for storing files.
– Formatting a partition (using format in windows or mkfs in unix) “prepares” it for recognition by the operating system as a file system.
Important Points
• Formatting a hard drive does not erase data, and therefore the data can be recovered
Important Points
• Low-level formatting does erase data. However, special vendor software is needed to low-level format hard disks
Disk Storage
• Data is stored on the disk over concentric circles called tracks (heads). When the disks are stacked, the set of tracks with identical radius collectively are called a cylinder. The disk is also divided into wedge-shaped areas called sectors.
• Disk capacity is given by the product of number of cylinders, tracks, and sectors. Each sector usually stores 512 bytes.
Disk Storage
• Zoned Bit Recording (ZBR) is used by disk manufacturers to ensure that all tracks are all the same size. Otherwise the inner tracks will hold less data than the outer tracks.
Disk Storage• The tracks on disks may be one of
– Boot track (containing partition and boot information)
– Tracks containing files– Slack space (unused parts of blocks/clusters)– Unused partition (if the disk is partitioned)– Unallocated blocks (usually containing data that
has been “deleted”)– (When the program execution is complete, the
allocated memory reverts to the operating systems. Such unallocated memory is not physically erased, just the pointers to it is deleted)
Important Points
• Hard drives are difficult to erase completely. Traces of magnetism can remain. This is often an advantage, since evidence may not have been erased completely by the perpetrator. Such evidence can be recovered using one of the data recovery services (such as www.ontrack.com, www.datarecovery.net, www.actionfront.com, www.ibas.net )
Important Points
• Files “deleted” may be partially recovered since their fragments may still be in unallocated blocks
Important Points
• Traces of information can remain on storage media such as disks even after deletion. This is called remanence. With sophisticated laboratory equipment, it is often possible to reconstruct the information. Therefore, it is important to preserve evidence after an incident.
Important Points
• A perpetrator can hide data in the inter-partition gaps (space between partitions that are specified while partitioning the disk) and then use disk editing utilities to edit the disk partition table to hide them.
Important Points
• The perpetrator can hide data in NT Streams, and such streams can contain executables. They are NOT visible through windows explorer and can not be seen through any GUI based editors (This week’s assignment)
Important points• The perpetrator can declare smaller than
actual drive size while partitioning and then save information at the end of the drive.
Important points• Many of the above can be uncovered by
using disk editors such as winhex, Hex Workshop, or Norton Disk Editor if the disks are formatted for one of the Microsoft operating systems.
Important Points
• For linux systems, LDE (Linux Disk Editor at lde.sourceforge.net) is a similar utility available under Gnu license.
Important Points
• Main Lesson: Do not depend on directories or windows explorer. Get to the physical data stored on the disk drives. Do not look only at the partitioned disk. Incriminating data may be lurking elsewhere on the disk.
Data Representation
• While all data is represented ultimately in binary form (ones and zeroes), use of editors that provide hexadecimal or ascii format display of data are valuable in forensics. They allow you to see features that are otherwise not visible.
• Popular tools for viewing such files include Winhex (www.winhex.com), Hex Workshop (www.hexworkshop.com), and Norton Disk Edit (www.symantec.com)
Important point
• One should be careful in using such editors, since data can be destroyed inadvertently.
Computer Networks
• How are internet communications organised?
• How the internet protocols work?
• What are some of the vulnerabilities caused by the internet protocols?
Networking • The Internet Model:
– Application Layer (http, telnet, email client,…)– Transport Layer: Responsible for ensuring data delivery.
(Port-to-Port) (Protocols: TCP and UDP) (Envelope name: segment)
– Network Layer: Responsible for communicating between the host and the network, and delivery of data between two nodes on network. (Machine-to-Machine) (Protocol: IP) (Envelope name: datagram) (Equipment: Router)
– Data Link Layer: Responsible for transporting packets across each single hop of the network (Node-to-Node) (Protocol: ethernet) (Envelope name: Frame) (Equipment: Hub)
– Physical Layer: Physical media (Repeater-to-repeater) (Equipment: Repeater)
Application Layer
Transport Layer
Network Layer
Link Layer
Physical Network
Application Layer
Transport Layer
Network Layer
Link Layer
Message
Packet
Frame Frame
Datagram Datagram
Network Layer
Link Layer
Physical Network
Host BHost A
Router
Protocol Layering – Routing
Protocols
A protocol defines the format and the order of messages exchanged between two of more communicating entities as well as the actions taken on the transmission and/or receipt of a
message or other event.
TCP Connection Request
TCP Connection Response
Get http://www.ibm.com/index.html
Index.html
Hi
Hi
Got the Time?
8:50
Some Protocol Vulnerabilities
• TCP Connection Oriented Service (Establish connection prior to data exchange, coupled with reliable data transfer, flow control, congestion control etc.)– Port scanning using netstat (unix/windows) or N-
map (http://www.insecure.org/nmap/)– Attacker can mask port usage using kernel level
Rootkits (which can lie about backdoor listeners on the ports)
– Attacker can violate 3-way handshake, by sending a RESET packet as soon as SYN-ACK packet is received
Some Protocol Vulnerabilities
• UDP Connectionless Service (No handshake prior to data exchange, No acknowledgement of data received, no flow/congestion control)– Lack of a 3-way handshake– Lack of control bits hinders control– Lack of packet sequence numbers hinders control– Scanning UDP ports is also harder, since there
are no code bits (SYN, ACK, RESET). False positives are common since the target systems may not send reliable “port unreachable” messages
End of this session
Sessions 8 and 9
Business continuity planning
What the experts are saying
Gartner (Roberta Witty, Donna Scott)Disaster Recovery Plans and Systems Are Essential
12 September 2001
"Two out of five enterprises that experience a disaster go out of business within five
years. Business continuity plans and disaster recovery services ensure
continuing viability.”
What Are We Doing About It ?
• 72% Of All Businesses Have Either…– No Business Continuity Plan– Never Tested Their Plan– Their Plan Failed When They Tested It
• Only 18% Of End User Data Is Protected*
*VERITAS Disaster Recovery Survey 2002.
Frequency of Downtime
Fre
qu
ency
Type of Disaster Scenario
Natu
ral Disas
ter
Po
litical Even
ts
User E
rror
Po
wer O
utag
e
Data C
orru
ptio
n
H/W
Failu
re
Disaster Recovery
Business Recovery
Business Resumption
Contingency Planning
Objective
Mission-critical applications
Mission-critical business processing (workspace)
Business process workarounds
External event
FocusSite or component outage (external)
Site outage (external)
Application outage (internal)
External behavior forcing change to internal
Deliverable Disaster recovery plan
Business recovery plan
Alternate processing plan
Business contingency plan
Sample Event(s)
Fire at the data center; critical server failure
Electrical outage in the building
Credit authorization system down
Main supplier cannot ship due to its own problem
Sample Solution
Recovery site in a different location
Recovery site in a different power grid
Manual procedure 25% backup of vital products; backup supplier
Crisis Management
BC Components
Creating Business Continuity Plans
Business Impact Analysis
Risk Analysis
Recovery Strategy
Group Plans and Procedures
Business Continuity Planning Initiation
Risk Reduction
ImplementStandby Facilities
Create Planning Organization
Testing
PROCESS
Change Management Education Testing Review
Policy ScopeResourcesOrganization
Ongoing Process
Project
Disaster Recovery Planning Cycle
The Business Challenge
TheTheWideningWideningGapGap
Requires continuous information availability – BY DESIGNRequires continuous information availability – BY DESIGN
Increasing cost of information unavailability
More business onlineMore applications & data
Ability to deliver through traditional recovery planning
More complex systemsLess window to recover
KPMG
The Challenge of Recovery
File and Print
Web Server
eBusiness
SecsMinsHrsDays Wks Secs Mins Hrs Days Wks
Recovery TimeRecovery TimeRecovery Recovery PointPoint
Recovery Point Objective (RPO)
“How fresh does your data need to be ?”
Recovery Time Objective (RTO)
“What is your downtime tolerance ?”
Disaster Recovery Technologies
Sync.Replication
Async.Replication
Tape Backup
Tape Restore
Clustering
OnlineRestore
Remote Replication
SecsMinsHrsDays Wks Secs Mins Hrs Days Wks
Recovery PointRecovery Point Recovery TimeRecovery Time
Recovery Process in a Virtualized Environment
RTO of minutes to a few hours, not days to weeks! RTO of minutes to a few hours, not days to weeks!
Configure hardware
Install OS
Configure OS
Install backup agent
Start “Single-step automatic recovery”
RestoreVM
Poweron VM
Example recovery process comparison
P-P
V-V
40+ hrs
< 4+ hrs
Storage Management Costs
• “An Enterprise Spends $3 Managing Storage For Every $1 Spent On Storage Hardware”
0%
20%
40%
60%
80%
100%
Time
IT B
udge
t
Hardware
Software
Labor
Gartner, Nov 2001
Cost
Disaster Recovery Times24
hours48
hours72
hoursMinutes12 hrs.
StandardRecovery
Elec.Vaulting
ElectronicJournaling
Shadowing
Mirroring
Database and/or fileand/or object backup
Log/journal transfer(continuous or periodic)
Database and/or file and/or object replication
Assumes mirroring or shadowing plusa complete application environment
net $host $disk $tape $
net $tape $
net $-$$+host $$+disk $$$$+
net $$$+host $$+disk $$$$+
net $$$+host $$$+disk $$$$+appl. $+
Hot Standby orLoad-Balanced
Applying High Availability to Disaster Recovery
ISO/IEC 27002(2005) Section14.1
Information security aspects of business continuity management
Objective of section 14.1• To counteract interruptions to business activities and to protect critical business
processes from the effects of major failures of information systems or disasters and to ensure their timely resumption.
• A business continuity management process should be implemented to minimize the impact on the organization and recover from loss of information assets (which may be the result of, for example, natural disasters, accidents, equipment failures, and deliberate actions) to an acceptable level through a combination of preventive and recovery controls.
• This process should identify the critical businessprocesses and integrate the information security management requirements of business continuity with other continuity requirements relating to such aspects as operations, staffing, materials, transport and facilities.
• The consequences of disasters, security failures, loss of service, and service availability should be subject to a business impact analysis. Business continuity plans should be developed and implemented to ensure timely resumption of essential operations. Information security should be an integral part ofthe overall business continuity process, and other management processes within the organization.
• Business continuity management should include controls to identify and reduce risks, in addition to the general risks assessment process, limit the consequences of damaging incidents, and ensure that information required for business processes is readily available.
ISO/IEC 27002(2005)Control 14.1.1
Including information security in the business continuity management process
ISO 27002 Control 14.1.1
• A managed process should be developed and maintained for business continuity throughout the organization that addresses the information security requirements needed for the organization’s business continuity.
Implementation guidance 14.1.1• The process should bring together the following key elements of business continuity
management:– a) understanding the risks the organization is facing in terms of likelihood and impact in time,
including an identification and prioritisation of critical business processes (see 14.1.2);– b) identifying all the assets involved in critical business processes (see 7.1.1);– c) understanding the impact which interruptions caused by information security incidents are likely to
have on the business (it is important that solutions are found that will handle incidents causing smaller impact, as well as serious incidents that could threaten the viability of the organization), and establishing the business objectives of informationprocessing facilities;
– d) considering the purchase of suitable insurance which may form part of the overall business continuity process, as well as being part of operational risk management;
– e) identifying and considering the implementation of additional preventive and mitigating controls;– f) identifying sufficient financial, organizational, technical, and environmental resources to
address the identified information security requirements;– g) ensuring the safety of personnel and the protection of information processing facilities
and organizational property;– h) formulating and documenting business continuity plans addressing information security
requirements in line with the agreed business continuity strategy (see 14.1.3);– i) regular testing and updating of the plans and processes put in place (see 14.1.5);– j) ensuring that the management of business continuity is incorporated in the organization’s
processes and structure; responsibility for the business continuity management process should be assigned at an appropriate level within the organization (see 6.1.1).
ISO/IEC 27002(2005)Control 14.1.2
Business continuity and risk assessment
ISO 27002 Control 14.1.2
• Events that can cause interruptions to business processes should be identified, along with the probability and impact of such interruptions and their consequences for information security.
Implementation guidance 14.1.2
• Information security aspects of business continuity should be based on identifying events (or sequence of events) that can cause interruptions to the organizations business processes, e.g. equipment failure, human errors, theft, fire, natural disasters and acts of terrorism. This should be followed by a risk assessment to determine the probability and impact of such interruptions, in terms of time, damage scale and recovery period.
Implementation guidance 14.1.2
• Business continuity risk assessments should be carried out with full involvement from owners of business resources and processes. This assessment should consider all business processes and should not be limited to the information processing facilities, but should include the results specific to information security. It is important to link the different risk aspects together, to obtain a complete picture of the business continuity requirements of the organization.
Implementation guidance 14.1.2• The assessment should identify, quantify, and
prioritise risks against criteria and objectives relevant to the organization, including critical resources, impacts of disruptions, allowable outage times, and recovery priorities.
• Depending on the results of the risk assessment, a business continuity strategy should be developed to determine the overall approach to business continuity.
• Once this strategy has been created, endorsement should be provided by management, and a plan created and endorsed to implement this strategy.
ISO/IEC 27002(2005)Control 14.1.3
Developing and implementing continuity plans including
information security
ISO 27002 Control 14.1.3
• Plans should be developed and implemented to maintain or restore operations and ensure availability of information at the required level and in the required time scales following interruption to, or failure of, critical business processes.
Implementation guidance 14.1.3• The business continuity planning process should consider the following:
– a) identification and agreement of all responsibilities and business continuity procedures;
– b) identification of the acceptable loss of information and services;– c) implementation of the procedures to allow recovery and restoration of business
operationsand availability of information in required time-scales; particular attention needs to be given to the assessment of internal and external business dependencies and the contracts in place;
– d) operational procedures to follow pending completion of recovery and restoration;– e) documentation of agreed procedures and processes;– f) appropriate education of staff in the agreed procedures and processes, including
crisis management;– g) testing and updating of the plans.
• The planning process should focus on the required business objectives, e.g. restoring of specific communication services to customers in an acceptable amount of time.
• The services and resources facilitating this should be identified, including staffing, non-information processing resources, as well as fallback arrangements for information processing facilities.
• Such fallback arrangements may include arrangements with third parties in the form of reciprocal agreements, or commercial subscription services.
Implementation guidance 14.1.3• Business continuity plans should address organizational
vulnerabilities and therefore may contain sensitive information that needs to be appropriately protected.
• Copies of business continuity plans should be stored in a remote location, at a sufficient distance to escape any damage from a disaster at the main site.
• Management should ensure copies of the business continuity plans are up-to-date and protected with the same level of security as applied at the main site.
• Other material necessary to execute the continuity plans should also be stored at the remote location.
• If alternative temporary locations are used, the level of implemented security controls at these locations should be equivalent to the main site.
Other information 14.1.3
• It should be noted that crisis management plans and activities (see ISO/IEC 27002(2005) 14.1.3 f) may be different frombusiness continuity management;
• i.e. a crisis may occur that can be accommodated by normal management procedures.
ISO/IEC 27002(2005)Control 14.1.4
Business continuityplanning framework
ISO 27002 Control 14.1.4
• A single framework of business continuity plans should be maintained to ensure all plans areconsistent, to consistently address information security requirements, and to identify priorities for testing and maintenance.
Implementation guidance 14.1.4• Each business continuity plan should describe the approach for
continuity, for example the approach to ensure information or information system availability and security.
• Each plan should also specify the escalation plan and the conditions for its activation, as well as the individuals responsible for executing each component of the plan. When new requirements are identified, any existing emergency procedures, e.g. evacuation plans or fallback arrangements, should be amended as appropriate.
• Procedures should be included within the organization’s change management programme to ensure that business continuity matters are always addressed appropriately.
• Each plan should have a specific owner. • Emergency procedures, manual fallback plans, and resumption plans
should be within the responsibility of the owners of the appropriate business resources or processes involved.
• Fallback arrangements for alternative technical services, such as information processing and communications facilities, should usually be the responsibility of the service providers.
Considerations 14.1.4• A business continuity planning framework should address the identified
information security requirements and consider the following:– a) the conditions for activating the plans which describe the process to be followed (e.g.
how to assess the situation, who is to be involved) before each plan is activated;– b) emergency procedures, which describe the actions to be taken following an incident,
which jeopardizes business operations;– c) fallback procedures which describe the actions to be taken to move essential
businessactivities or support services to alternative temporary locations, and to bring business processes back into operation in the required time-scales;
– d) temporary operational procedures to follow pending completion of recovery and restoration;
– e) resumption procedures which describe the actions to be taken to return to normal business operations;
– f) a maintenance schedule which specifies how and when the plan will be tested, and the process for maintaining the plan;
– g) awareness, education, and training activities which are designed to create understanding of the business continuity processes and ensure that the processes continue to be effective;
– h) the responsibilities of the individuals, describing who is responsible for executing which component of the plan. Alternatives should be nominated as required;
– i) the critical assets and resources needed to be able to perform the emergency, fallback and resumption procedures.
ISO/IEC 27002(2005)Control 14.1.5
Testing, maintaining and re-assessing business continuity
plans
ISO 27002 Control 14.1.5
• Business continuity plans should be tested and updated regularly to ensure that they are up to date and effective.
Implementation guidance 14.1.5
• Business continuity plan tests should ensure that all members of the recovery team and other relevant staff are aware of the plans and their responsibility for business continuity and information security and know their role when a plan is invoked.
• The test schedule for business continuity plan(s) should indicate how and when each element of the plan should be tested.
• Each element of the plan(s) should be tested frequently.
Business continuity planning
BCP Guidelines• Creating a BCP: Initiation
• Workgroup or team membership & objectives• Roles & responsibilities for planning, plan approval, &
quality assurance• List of business services & activities confirmed as vital• Business continuity planning processes
– Strategy & schedule for planning, progress reporting, plan review & approval, issue resolution process, communication & coordination strategy
• Affirmation of executive support• Assessment of current BCP, disaster recovery or
emergency preparedness plans
BCP Guidelines
• Business Impact Analysis (Risks)• Minimum Acceptable Levels of Business
Services & Activities• Failure Scenarios (potential risks) for vital
business services & activities• Impact of each failure scenario with likelihood
of occurrence• Business Continuity Items for which continuity
plans will be developed
BCP Guidelines• Detailed Continuity Plans
(for each continuity item)• Continuity plan objectives & scope• Continuity plan triggers• Roles & responsibilities for continuity preparation &
deployment (including contact information)• Status reporting processes• Instructions to carry out continuity plan• Coordination strategy with other groups (if applicable)• Required resources & estimated costs• Agreements & assumptions with suppliers on whom
continuity plans are dependant• Communications strategy
BCP Guidelines
• Business continuity/resumption strategy– Criteria for business continuity/resumption– Priorities, processes and resources
• Validation/testing strategy– Which continuity items will be tested– Members of the test team(s)
• Validation/testing plans– Objectives and approach– Required resources– Assessment of BCP documentation to the current organization– Assessment of the validity of the BCP and its assumptions
BCP Guidelines
• Review of the infrastructure the BCP utilizes & any procedures for continuing/resuming business processes & information systems with that infrastructure
Simulation exercise
• Simulation Exercise planning includes:
• Schedules and locations
• Procedures
• Expected results
• Acceptance criteria
BCP Guidelines
• Validation/testing results• Adequacy to support business continuity item• Capacity to manage, record and track business
continuity activities• Adequacy of business continuity processes• Adequacy of resource availability to implement
& sustain the continuity plan• Adequacy of overall business continuity
activities
BCP Guidelines• Keep it simple
– Pages & pages of documentation will not be used or will be difficult to use when the plan needs to be invoked
• Accessibility– Make sure the BCP, particularly the detailed
business continuity plans, are safely accessible outside of your organization
– Relying completely on electronic medium is not recommended
BCM Maturity Model• Allows you to objectively measure the maturity of a
company’s business continuity program
• Program Basics– Commitment of Senior Management to drive and fund the
BCM initiative– Availability of professional business continuity personnel– Application of prudent & practical business continuity
governance supported by an implemented infrastructure• Policies, performance measurements, skills competency
baselines, competency development program, communication vehicles
BCM Maturity Model Milestones• All departments across the enterprise have been
included in the BCM initiative– All the program basics are in place– Every critical business function is covered by a business
continuity plan
• The participants have gained expertise with & confidence in BCM principals
– Able to develop and test more complex plans– Risk assessment, business impact analysis and mitigation activities have
become familiar exercises– Critical multi-departmental aspects of the business now being integrated into
the business protection strategy
• The BCM program encompasses the full scope of the business & keeps pace with change
– Enterprise business processes are protected through structured cross-functional recovery plans & risk mitigation programs
– Creative new continuity strategies are ongoing
BCM Maturity Model
BCM Maturity Model• Level 1: Self-Governed
– BCM is not recognized as strategically important by senior management
– No enterprise governance or support– If BCM policy exists it is not enforced– Individual business units & departments are “on their own”
to organize, implement, & self-govern business continuity efforts
– State of preparedness is low across the enterprise
BCM Maturity Model• Level 2: Supported Self-Governed
– At least one business unit or corporate function has recognized strategic need for BCM & has begun efforts to increase executive and enterprise wide awareness
– At least one BCM professional is available– State of preparedness remains relatively low across the
majority of the organization– Senior management may recognize value but still unwilling
to make it a priority at this time
BCM Maturity Model• Level 3: Centrally Governed
– Participating business units have instituted a rudimentary governance program, mandating at least limited compliance to standardized BCM policy, practices & processes to which they have commonly agreed
– A BCM program office or department is in place and operational and the enterprise is at best moderately prepared
– Senior management have not yet committed the enterprise to a BCM program although they may be assessing the business case for it
BCM Maturity Model• Level 4: Enterprise Awakening
– Senior management is committed to the strategic importance of an effective BCM program
– BCM policy, practices & processes are being standardized across the enterprise with support through the central BCM program office/department
– All critical business functions have been identified and continuity plans for their protection have been developed across the enterprise, tested & are updated routinely
BCM Maturity Model• Level 5: Planned Growth
– All business units have completed tests on all elements of their business continuity plans & their plan update methods have proven to be effective
– Senior management have participated in crisis management exercises
– Business continuity plans & tests incorporate multi-departmental considerations of critical enterprise business processes
– A plan has been adopted to continuously “raise the bar” for planning & enterprise wide preparedness
BCM Maturity Model• Level 6: Synergistic
– All business units have a measurably high degree of business continuity planning competency
– Complex business protection strategies are formulated & tested successfully
– Cross-functional coordination has led participants to develop & successfully test upstream & downstream integration of their business continuity plans
– Integration to change control processes & continuous process improvement initiatives keeps the organization at a high state of preparedness
Backups
• Backups are key to BCP or DRP -
Hardware and storage media failure
leading to corruption of critical data is a
source of disaster.
Backup Strategy
– The strategy should consider• How frequently should backups be conducted?
• How extensive do the backups need to be?
• What is the process for conducting backups?
• Who is responsible for ensuring that backups are created?
• Where will the backups be stored?
• How long will backups be kept?
• Depending on the type of organization, there may be legal requirements for
conducting backups that will affect the factors mentioned previously.
What Needs to Be Backed Up
• A good backup plan will consider more than just the data. It will include:
• Application programs needed to process the data.• The operating system and utilities that the hardware
platform requires to run the applications.
• The DRP should also address other items related to backups such as:
• Personnel• Equipment• Electrical power
Types of Backups
• There are four basic types of backups
• Full backup
– An occasional full backup must be conducted.
– Later, when a delta backup is conducted at specific intervals, only the portions of the files
that have been changed will be stored.
• Differential backup
– Only the files and software that have changed since the last full backup
• An incremental backup
– Any file that has changed since the last backup (full or partial).
• The type selected will greatly affect the overall backup strategy, plans, and processes.
• How frequently should backups be performed?
– You should consider how long an organization can survive without current data.
Backup Rule of Three• Multiple backups should be maintained.
• There are several strategies or approaches to backup retention and a common
and easy to remember is the “rule of three.”
– This entails simply keeping the three most recent backups. When a new backup is
created, the oldest copy is overwritten.
– In certain environments, regulatory issues may prescribe a specific frequency and
retention period.
– It is important to know an organization and its requirements when determining how often
a backup will be created and how long will it be kept.
• If you are not in an environment where regulatory issues dictate the frequency and
retention, your goal will be to optimize the frequency.
Backup Rule of Three• To determine the optimal backup frequency, consider:
– The cost of the backup strategy chosen.
– The cost of recovery if the backup strategy is not implemented (meaning if there were
no backups created).
– the probability that the backup will be needed on any given day.
• The two figures to consider then are:
– (probability the backup is needed AND cost of restoring with no backup)
• This figure is the probable loss that can be expected by an organization if there is
no backup conducted.
– (probability the backup isn't needed AND cost of the backup strategy)
• This figure is the price an organization is willing to pay (lose) to ensure that you can
restore, should a problem occur.
• To optimize backup strategy, the correct balance between these two figures needs to be
determined.
– When working with these two calculations, it Is is a cost-avoidance exercise.
Backup Rule of Three• When calculating the cost of the backup
strategy, consider:
– The cost of the backup media required for a single
backup
– The storage costs for the backup media and the
retention policy
– The labor costs associated with performing a
single backup
– The frequency with which backups are created
Backup Rule of Three
• The best strategy is to keep copies of
backups in separate locations.
– The most recent copy could be stored locally, as it
is the most likely to be needed.
– Other copies can be kept at other locations.
Alternate Sites• Offsite Storage
• A recent advance is online backup services.
– A number of third-party companies offer high-speed connections for storing data on a frequent
basis.
• Where should restoration services be conducted?
– If an organization has suffered physical damage to a facility, having offsite storage of data is only
part of the solution.
– Data needs to be processed somewhere.
• Hot site - A fully configured environment similar to the normal operating environment.
• Warm - Partially configured, usually having the peripherals and software but perhaps not the
more expensive main processing computer.
• Cold site - Basic environmental controls needed to operate. Has few computing components
needed.
• Mobile backup- Trailers with the required computers and electrical power that can be driven
to a location within hours of a disaster and set up to commence processing immediately.
Alternate Sites
• A less expensive alternative is a mutual aid agreement.
– Similar organizations agree to assume the processing for the other party
with the following assumptions
• both organizations will not be hit by the same disaster.
• both have similar processing environments.
– Such an arrangement may not be legally enforceable, even if it is in writing.
Long-Term Storage of Backups
• Depending on the media: – Magnetic media degrade over time (measured in
years).• Tapes can be used a limited number of times before
the surface begins to flake off. • Storage of media in a steel safe or file cabinet may
accelerate the process. Other considerations
– Software applications also evolve, and the media may not be compatible with current versions of the software.
– If the file you stored is encrypted, then passwords are needed to decrypt the file to restore the data..
Utilities - Power
• Emergency power must be planned for in case of disruption
• For short-term interruptions a UPS may suffice.
• Beyond a few minutes, another source of power is required.
– Backup generators are not a simple, maintenance-free
solution.
• Generators should be tested on a regular basis.
• They can become strained if they power too much
equipment, therefore, ensure the reserve capacity is
beyond the anticipated load.
• They take time to start up. A UPS should be used to
for a smooth transition to backup power.
– Generators are expensive and require fuel – they
should be kept in a place where they can be fueled.
Utilities - Environmental• Environmental conditions.
– Air conditioning.
– Mobile backup sites use trailers and rely on generators for their
power but also factor in the requirement for environmental controls.
– Depending on the disaster, telephone and Internet communication
may be lost.
– Wireless services may also not be available.
• Planning redundant communication can help with most
outages.
– Backup plans should include the option to continue operations from a
different location while waiting for communications to be restored.
Secure Recovery• In the event an organization’s operations are
disrupted, several companies offer recovery services that can remotely provide restoration services for critical files and data. These may include:– Power– Communications – Technical support
• For the physical sites and the remote service—security is an important element and must be ensured.
• Confidentiality• Integrity• Availability
High Availability and Fault Tolerance
• High availability refers to the ability to maintain data and operational processing despite any disruption. – It requires redundant systems for both power and
processing.
• Fault tolerance refers to availability and is accomplished by the mirroring of data and systems. – Should a “fault” occur that disrupts a device such as
a disk controller, the mirrored system provides the requested data with no interruption in service.
Computer Incident Response Teams
• A plan should include establishing a Computer Incident Response Team
(CIRT) or a Computer Emergency Response Team (CERT).
– The team should be created and team members notified before an incident
occurs.
– The team includes technical and non-technical individuals who provide
guidance on ways to handle media attention, legal issues, management issues.
– The team consists of permanent and ad hoc members.
• The CIRT conducts investigations of the incident and makes
recommendations about how to proceed.
– Policies and procedures for investigation should also be worked out in advance.
– It is also advisable to have the team periodically meet to review these
procedures.
Test, Exercise, and Rehearse
• The BCP, DRP, backup procedures, or method to address computer incidents and other plans should be tested.– all parties should practice the established
procedures. – As many recovery functions as possible should be
performed– Care should be taken not to impact actual
operations.
Rehearse
• Rehearsal of portions of the recovery plan should include:– Items that are disruptive to actual operations.– Items identified as needing more frequent
activation due to either the importance or the need for continual practice
End of this session
Session 11
Mid-term exam
Mid-term exam
Session 12
Disaster recovery planning
Disaster recovery planning
ISO/IEC FDIS 24762:2007(E)
ISO 24762 approach to BCP
Conduct of Business ImpactAnalysis Review,
Assessment of Risks, thenbased on these results -
Establishment of BusinessRecovery Priorities,
Timescales & Requirements
Business continuity strategy formulation
Business continuity plan production
Business continuity plan testing
Business continuity awareness
On-going Business continuity plan maintenance
Business continuity strategy formulation
Environmental stability• Environmental stability is important for the direct
operation of a recovery center as well as personnel travel, safety and welfare.
• The utilities required for the operation of a recovery center, such as power supply andtelecommunications, can be affected by environmental instability.
• Personnel travel and safety to/from a recovery center can be affected by disruption to the transportation system.
• Personnel welfare and social activities after work can also be limited by an unsafe external environment.
Identifying instability• The frequent occurrence on a large scale of the
following type of activities would indicate underlying environmental instability:– strikes;– demonstrations;– riots;– violent crimes;– natural disasters;– pandemics;– deliberate attacks.
Asset management• Service providers should ensure that assets placed
in their ICT DR premises are capable of being uniquely identified, located and retrieved in a timely manner when required by organizations.
• In addition to computing and related equipment, assets include: – application software, – vital records stored on media (magnetic or otherwise), and– necessary operational documentation placed in service
providers’ operational premises to facilitate recovery from disasters and failures.
Organization ownership rights and privileges
– Service providers should explicitly document and maintain the listing of assets that are in their ICT DR
– premises. In the case of outsourced service providers, the asset list should be included in service contracts
– with appropriate clauses inserted to identify their ownership rights and privileges.
Asset protection• For all assets located in their ICT DR premises,
service providers should ensure that:– a) a list of the assets is maintained (this could be through
use of a configuration management “system” and associated processes that maintain details of current versions of documentation, software, and all other assets (ISO/IEC 20000 provides guidance on establishing configuration management);
– b) all assets are tagged/marked in a manner that uniquely identifies ownership;
– c) in the case of outsourced ICT DR service provision, organizations and outsourced service providers do not display explicit organization names in the asset tagging/marking to ensure that security is not compromised. For example, equipment mounted on shared racks should not have explicit organization names as part of the tag/mark.
Service providers should establish systems
• 1) to protect, maintain, locate, retrieve and return all organization tagged/marked assets located at their premises, and ensure that organization ICT DR assets are:– a) located and kept in safe environments;– b) maintained in good operating conditions, with
the installation of appropriate environmental controls;
– c) not used or redeployed for other than contracted purposes; and that the location of organizations’ ICT DR assets is accurately tracked for retrieval.
In Outsourcnig
• In the case of outsourced ICT DR service provision, outsourced service providers should ensure that:– a) organizations are informed when their assets
are being relocated;– b) organizations’ assets are retrieved and
returned within a predetermined and agreed timeframe when requested by organizations;
– c) organizations are forewarned and their assets returned to them according to appropriate established and agreed procedures before the onset of any seizure or stoppages.
National boundaries– Organizations should consider the implications of
disaster recovery data and other assets being stored across national boundaries, and ensure that compliance is maintained with all relevant legal and regulatory requirements.
Availability of documentation
• Service providers (if required by their SLAs) and organizations should maintain duplicate copies of plans, disaster/failure procedures and other essential information for managing disasters and failures, including details of how to contact staff and of access points for emergency services.
• Such duplicate plans, procedures and other essential information should be kept off site at easily accessible locations.
Proximity of site
• DR sites should be in geographic areas that are unlikely to be affected by the same disaster/failure events as organizations’ primary sites.
• The issue of site proximity and associated risks should be taken into consideration when ICT DR service providers contract and agree SLAs with organizations.
Disaster communication
Defining topic
• Risk communication: Information exchange about health risks caused by environmental, industrial, or agricultural, processes, policies, or products among individuals, groups, and institutions.
• Crisis risk communication: Accurate and effective communication to diverse audiences in emergency situations including natural disasters, industrial accidents, disease outbreaks, or bioterrorism events.
Common elements that shape crisis risk communications (CERC)
• Uncertain outcomes
• Scenarios that provoke fear or dread
• Conflict and controversy as regards causes, solutions, consequences
• Trust and distrust of communicators
• Technical information
• Multiple stakeholders
The role of the media in CERC• Pre event :
• Educate public /
• Have disaster response materials/ plans in place/
• During event :
• Bring people up to speed with events
• Fill in gaps in knowledge
• Report emergency and disaster preparedness response efforts
• Work with essential agencies to disseminate information
• Post event :
• Report Rescue and relief efforts
• Re-assure public
Risk communication goals– Save lives– Reduce service utilization – Facilitate relief or hazard mitigation efforts– Reduce anxiety
Message Mapping (Covello, 2001)
• "Message maps" are risk communication tools used to help organize complex information and make it easier to express current knowledge.
• Objective : to distill information into easily understood messages written at a 6th grade reading level.
• Messages are presented in short sentences that convey key messages.
• The approach is based on surveys showing that lead or front page media and broadcast stories usually convey only three key messages usually in less than 9 seconds for broadcast media or 27 words for print.
Message Mapping
• Identify and prioritize stakeholders
• Identify and prioritize stakeholders’ questions and concerns
Prepare to answer these types of questions
• Risk and survival
• How are those who are ill getting help?
• Is this thing being contained?
• What can we expect?
• Meaning
• Why did this happen?
• Why wasn’t this prevented?
• What does this information/results mean?
Reassurance • Who is doing something
about this? • What are you doing to alert
people / fix this ? Trust/credibility • What else can go wrong?• When were you notified
about this?• What bad things aren’t you
telling us?
Message Mapping
• 3. Analyze the questions and concerns to identify commonalities.
• Develop key messages.– Overcome mental noise barriers– Produce accurate messages for diverse
audiences– Achieve maximum communication effectiveness
within mental noise constraints
Message Mapping
• Develop key messages.– Limited in number (3)– Brief– Understandable
• Develop supporting materials.
• Conduct message testing . . . if you can!
• Deliver messages
Tools for Communicating Pre event
• Factsheets/FAQ /newsletters/message maps• Website/internet materials/ training materials• Video/audio materials (b-roll/podcasts)• Prototype press releases/ radio live reads/ media
alerts • Prototype materials for special populations • Training materials for volunteer organizations• Media Resource lists • Resources -Communicating in the First Hours :Initial
Communication With the Public During a Potential Terrorism Event http://www.bt.cdc.gov/firsthours/
Tools for Communicating with media and public during a crisis
• Are created/ disseminated during event
• Actual News releases/Statements
• Media advisories
• Media briefings/Press conferences
• Hotlines/ Information lines
• Community meetings
• Print materials dissemination through partnering organizations
Working with media and community agencies
• Proactively- – Have things ready (materials, fact sheets,
protocols ) – Have a more prepared public (campaigns, stories
in the news)– Set up partnerships before a crisis (have lists of
reporters/contacts in community organizations/ other gov’t organizations)
Working with media and community agencies
• During a crisis• Contact media and agencies • Adapt materials ( press statements, fact sheets
, FAQs and Q & A’s ) • Develop / distribute press releases and media
advisories • Conduct a press conference• Track media calls• Respond to media errors ( media monitoring )• Work with the media to say it right ( public
relations)
Positive Outcomes in a crisis
• In a crisis gets news out fast and efficiently
• Can reach the hard to reach
• Resources made known
Five things that boost CERC success ( fr. Stratton )
• Express empathy early
• Be the first source for information
• Show competence and expertise
• Have a solid communication plan
• Remain honest and open
Five CERC Failures that kill Operational success
• Mixed messages from multiple experts
• Information released late
• Paternalistic attitudes
• Not countering rumors and myths in real time
• Public power struggles and confusion
What the public needs
• Public must feel empowered – reduce fear and victimization
• Mental preparation reduces anxiety
• Taking action reduces anxiety
• Uncertainty must be addressed
Decision making in a crisis is different
• People simplify
• Cling to current beliefs
• Remember what they see and hear first ( first messages carry more weight )
• People limit intake of new information ( 3 – 7 bits )
Emergency risk communications must haves
• Spokespersons who are credible, articulate and compassionate
• Messages that are clear, consistent, and culturally competent
• Messages that provide specific information on exposure to the hazard or agent, symptoms, treatment, long- and short-term consequences, preventive and curative actions, and emergency response resources.
• .
Emergency risk communications must haves
• Communications with the news primary
• Messages should be replicated on websites, blogs, podcasts, and video news releases, given that most people turn to the Internet as well as broadcast media during an emergency,
• For hard-to-reach or more isolated populations, health departments must be prepared to work with community partners to get vital information disseminated.
Evaluating CERC outcomes– Know how information has been disseminated to
the public (web hits/ hot line logs / track postings / track print media)
– Know what the media is saying (media monitoring- monitor blogs)
– Know who in the media is saying it (track calls) – Know what the public is thinking (opinion surveys) – Know if the public has responded appropriately
(follow up surveys – compliance, physical and psychological wellbeing, continued disaster preparation, health care)
Problems in risk communications• Message problems – scientific complexity, large
data sets full of uncertainties
• Source problems – lack of trust / experts disagree/ use of technical , bureaucratic language
• Channel problems – selective and biased reporting / media sensationalizes
• Receiver problems - inaccurate perceptions of risk , lack of interest , overconfidence in ability to avoid harm, unrealistic demands for scientific certainty, reluctance to make tradeoffs
• These issues are not unique to risk communication but plague all health communication.
Links• Crisis and risk communication guidebooks• 1. Crisis + Emergency Risk Communication • http://www.orau.gov/cdcynergy/erc/content/activeinformation/
resources/CERC_course_materials.htm• 2. Public Health Workbook to Define, Locate and Reach
Special, Vulnerable and At-Risk Populations in an Emergency (www.bt.cdc.gov/workbook)
• 3. Samsha . Substance Abuse and Mental Health Adminstration 2002. Communication in crisis: risk communication guidelines for public officials.
• http://www.riskcommunication.samhsa.gov/index.htm • 4. Terrorism and Other Public Health Emergencies: A Field
Guide for the Media http://www.hhs.gov/emergency/mediaguide/field/
End of this session
Sessions 13 and 14
Incident management
ITIL Incident Management• There should be a close Interface between the
Incident Management Process and the Problem Management and Change Management processes as well as the function of the Service Desk.
• If not properly controlled, Changes may introduce new Incidents. A way of tracking back is required. It is therefore recommended that the Incident records should be held on the same CMDB as the Problem, Known Error and Change records, or at least linked without the need for re-keying, to improve the interfaces and ease interrogation and reporting.
• Incident priorities and escalation procedures need to be agreed as part of the Service Level Management process and documented in the SLAs.
INFORMATION SECURITY INCIDENT MANAGEMENT
ISO/IEC 27002(2005)Chapter 13
ISO/IEC 27002(2005) Sections
• 13.1 REPORTING INFORMATION SECURITY EVENTS AND WEAKNESSES– 13.1.1 Reporting information security events– 13.1.2 Reporting security weaknesses
• 13.2 MANAGEMENT OF INFORMATION SECURITY INCIDENTS AND IMPROVEMENTS– 13.2.1 Responsibilities and procedures– 13.2.2 Learning from information security
incidents – 13.2.3 Collection of evidence
ISO/IEC 27002(2005)Section 13.1
Reporting information security events and weaknesses
Objective
• To ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken.
• Formal event reporting and escalation procedures should be in place.
• All employees, contractors and third party users should be made aware of the procedures for reporting the different types of event and weakness that might have an impact on the security of organizational assets.
• They should be required to report any information security events and weaknesses as quickly as possible to the designated point of contact.
Reporting information security events
ISO/IEC 27002(2005)Control 13.1.1
ISO 27002 Control
• Information security events should be reported through appropriate management channels as quickly as possible.
Implementation guidance• A formal information security event reporting
procedure should be established, together with an incident response and escalation procedure, setting out the action to be taken on receipt of a report of an information security event. A point of contact should be established for the reporting of information security events. It should be ensured that this point of contact is known throughout the organization, is always available and is able to provide adequate and timely response.
• All employees, contractors and third party users should be made aware of their responsibility to report any information security events as quickly as possible. They should also be aware of the procedure for reporting information security events and the point of contact.
Procedure• The reporting procedures should include:
– a) suitable feedback processes to ensure that those reporting information security events are notified of results after the issue has been dealt with and closed;
– b) information security event reporting forms to support the reporting action, and to help the person reporting to remember all necessary actions in case of an information security event;
– c) the correct behaviour to be undertaken in case of an information security event, i.e.
• 1) noting all important details (e.g. type of non-compliance or breach, occurring malfunction, messages on the screen, strange behaviour) immediately;
• 2) not carrying out any own action, but immediately reporting to the point of contact;
– d) reference to an established formal disciplinary process for dealing with employees, contractors or third party users who commit security breaches.
Alarms
• In high-risk environments, a duress alarm may be provided whereby a person under duress can indicate such problems. The procedures for responding to duress alarms should reflect the high risk situation such alarms are indicating.
Other Information• Examples of information security events and incidents are:
– a) loss of service, equipment or facilities,– b) system malfunctions or overloads,– c) human errors,– d) non-compliances with policies or guidelines,– e) breaches of physical security arrangements,– f) uncontrolled system changes,– g) malfunctions of software or hardware,– h) access violations.
• With due care of confidentiality aspects, information security incidents can be used in user awareness training (see 8.2.2) as examples of what could happen, how to respond to such incidents, and how to avoid them in the future. To be able to address information security events and incidents properly it might be necessary to collect evidence as soon as possible after the occurrence (see 13.2.3).
• Malfunctions or other anomalous system behavior may be an indicator of a security attack or actual security breach and should therefore always be reported as information security event.
• More information about reporting of information security events and management of information security incidents can be found in ISO/IEC TR 18044.
Reporting security weaknesses
ISO/IEC 27002(2005)Control 13.1.2
ISO 27002 Control
• All employees, contractors and third party users of information systems and services should be required to note and report any observed or suspected security weaknesses in systems or services.
Implementation guidance• All employees, contractors and third party users
should report these matters either to theirmanagement or directly to their service provider as quickly as possible in order to prevent informationsecurity incidents.
• The reporting mechanism should be as easy, accessible, and available as possible.
• They should be informed that they should not, in any circumstances, attempt to prove a suspectedweakness.
Other Information
• Employees, contractors and third party users should be advised not to attempt to prove suspected security weaknesses.
• Testing weaknesses might be interpreted as a potential misuse of the system and could also cause damage to the information system or service and result in legal liability for the individual performing the testing.
ISO/IEC 27002(2005)Section 13.2
Management of information security incidents and
improvements
Objective
• To ensure a consistent and effective approach is applied to the management of information security incidents.
• Responsibilities and procedures should be in place to handle information security events and weaknesses effectively once they have been reported.
• A process of continual improvement should be applied to the response to, monitoring, evaluating, and overall management of information security incidents.
• Where evidence is required, it should be collected to ensure compliance with legal requirements.
Responsibilities and procedures
ISO/IEC 27002(2005)Control 13.2.1
Iso 27002 Control
• Management responsibilities and procedures should be established to ensure a quick, effective, and orderly response to information security incidents.
Implementation guidance
• In addition to reporting of information security events and weaknesses (see also ISO/IEC 27002(2005) section13.1), the monitoring of systems, alerts, and vulnerabilities (ISO/IEC 27002(2005) control 10.10.2) should be used to detect information security incidents.
Guidelines
The following guidelines for information security incident management
procedures should be considered:
Procedures
a) procedures should be established to handle different types of information security incident, including:
• 1) information system failures and loss of service;• 2) malicious code (see 10.4.1);• 3) denial of service;• 4) errors resulting from incomplete or inaccurate
business data;• 5) breaches of confidentiality and integrity;• 6) misuse of information systems;
Contingency plans
b) in addition to normal contingency plans (see 14.1.3), the procedures should also cover (see also 13.2.2):
• 1) analysis and identification of the cause of the incident;
• 2) containment;• 3) planning and implementation of corrective action to
prevent recurrence, if necessary;• 4) communication with those affected by or involved
with recovery from the incident;• 5) reporting the action to the appropriate authority;
Audit trails
c) audit trails and similar evidence should be collected (see 13.2.3) and secured, as appropriate, for:
• 1) internal problem analysis;• 2) use as forensic evidence in relation to a potential
breach of contract or regulatory requirement or in the event of civil or criminal proceedings, e.g. under computer misuse or data protection legislation;
• 3) negotiating for compensation from software and service suppliers;
Recovery actions
d) action to recover from security breaches and correct system failures should be carefully and formally controlled; the procedures should ensure that:
• 1) only clearly identified and authorized personnel are allowed access to live systems and data (see also 6.2 for external access);
• 2) all emergency actions taken are documented in detail;
• 3) emergency action is reported to management and reviewed in an orderly manner;
• 4) the integrity of business systems and controls is confirmed with minimal delay.
Management’s role
• The objectives for information security incident management should be agreed with management, and it should be ensured that those responsible for information security incident management understandthe organization’s priorities for handling information security incidents.
Other information
• Information security incidents might transcend organizational and national boundaries.
• To respond to such incidents there is an increasing need to coordinate response and share information about these incidents with external organizations as appropriate.
Learning from information security incidents
ISO/IEC 27002(2005)Control 13.2.2
ISO 27002 Control
• There should be mechanisms in place to enable the types, volumes, and costs of information security incidents to be quantified and monitored.
Implementation guidance
• The information gained from the evaluation of information security incidents should be used to identify recurring or high impact incidents.
Other Information
• The evaluation of information security incidents may indicate the need for enhanced or additional controls to limit the frequency, damage, and cost of future occurrences, or to be taken into account in the security policy review process.
• see ISO/IEC 27002(2005) control 5.1.2
Collection of evidence
ISO/IEC 27002(2005)Control 13.2.3
ISO 27002 Control
• Where a follow-up action against a person or organization after an information security incident involves legal action (either civil or criminal), evidence should be collected, retained, and presented to conform to the rules for evidence laid down in the relevant jurisdiction(s).
Implementation guidance
• Internal procedures should be developed and followed when collecting and presenting evidence for the purposes of disciplinary action handled within an organization.
General rules
• In general, the rules for evidence cover:– a) admissibility of evidence: whether or not the
evidence can be used in court;– b) weight of evidence: the quality and
completeness of the evidence.
Admissibility• To achieve admissibility of the evidence, the
organization should ensure that their information systems comply with any published standard or code of practice for the production of admissible evidence.
• The weight of evidence provided should comply with any applicable requirements.
• To achieve weight of evidence, the quality and completeness of the controls used to correctly and consistently protect the evidence (i.e. process control evidence) throughout the period that the evidence to be recovered was stored and processed should be demonstrated by a strong evidence trail.
Conditions• In general, such a strong trail can be established
under the following conditions:– a) for paper documents: the original is kept securely with a
record of the individual who found the document, where the document was found, when the document was found and who witnessed the discovery; any investigation should ensure that originals are not tampered with;
– b) for information on computer media: mirror images or copies (depending on applicable requirements) of any removable media, information on hard disks or in memory should be taken to ensure availability; the log of all actions during the copying process should bekept and the process should be witnessed; the original media and the log (if this is not possible, at least one mirror image or copy) should be kept securely and untouched.
Work on copies
• Any forensics work should only be performed on copies of the evidential material.
• The integrity of all evidential material should be protected.
• Copying of evidential material should be supervised by trustworthy personnel and information on when and where the copying process was executed, who performed the copying activities and which tools and programs have been utilized should be logged.
Other information• When an information security event is first detected, it may
not be obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized.
• It is advisable to involve a lawyer or the police early in any contemplated legal action and take advice on the evidence required.
• Evidence may transcend organizational and/or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as evidence.
• The requirements of different jurisdictions should also be considered to maximize chances of admission across the relevant jurisdictions.
End of this session
Sessions 15 and 16
Simulation
Recall from sessions 8 and 9
Disaster Recovery
Business Recovery
Business Resumption
Contingency Planning
Objective
Mission-critical applications
Mission-critical business processing (workspace)
Business process workarounds
External event
FocusSite or component outage (external)
Site outage (external)
Application outage (internal)
External behavior forcing change to internal
Deliverable Disaster recovery plan
Business recovery plan
Alternate processing plan
Business contingency plan
Sample Event(s)
Fire at the data center; critical server failure
Electrical outage in the building
Credit authorization system down
Main supplier cannot ship due to its own problem
Sample Solution
Recovery site in a different location
Recovery site in a different power grid
Manual procedure 25% backup of vital products; backup supplier
Crisis Management
BC Components
Disaster Recovery Planning Cycle
ISO 27002 Control 14.1.3
• Plans should be developed and implemented to maintain or restore operations and ensure availability of information at the required level and in the required time scales following interruption to, or failure of, critical business processes.
Implementation guidance 14.1.3• The business continuity planning process should consider the following:
– a) identification and agreement of all responsibilities and business continuity procedures;
– b) identification of the acceptable loss of information and services;– c) implementation of the procedures to allow recovery and restoration of business
operationsand availability of information in required time-scales; particular attention needs to be given to the assessment of internal and external business dependencies and the contracts in place;
– d) operational procedures to follow pending completion of recovery and restoration;– e) documentation of agreed procedures and processes;– f) appropriate education of staff in the agreed procedures and processes, including
crisis management;– g) testing and updating of the plans.
• The planning process should focus on the required business objectives, e.g. restoring of specific communication services to customers in an acceptable amount of time.
• The services and resources facilitating this should be identified, including staffing, non-information processing resources, as well as fallback arrangements for information processing facilities.
• Such fallback arrangements may include arrangements with third parties in the form of reciprocal agreements, or commercial subscription services.
Implementation guidance 14.1.3• Business continuity plans should address organizational
vulnerabilities and therefore may contain sensitive information that needs to be appropriately protected.
• Copies of business continuity plans should be stored in a remote location, at a sufficient distance to escape any damage from a disaster at the main site.
• Management should ensure copies of the business continuity plans are up-to-date and protected with the same level of security as applied at the main site.
• Other material necessary to execute the continuity plans should also be stored at the remote location.
• If alternative temporary locations are used, the level of implemented security controls at these locations should be equivalent to the main site.
ISO 27002 Control 14.1.4
• A single framework of business continuity plans should be maintained to ensure all plans areconsistent, to consistently address information security requirements, and to identify priorities for testing and maintenance.
Implementation guidance 14.1.4• Each business continuity plan should describe the approach for
continuity, for example the approach to ensure information or information system availability and security.
• Each plan should also specify the escalation plan and the conditions for its activation, as well as the individuals responsible for executing each component of the plan. When new requirements are identified, any existing emergency procedures, e.g. evacuation plans or fallback arrangements, should be amended as appropriate.
• Procedures should be included within the organization’s change management programme to ensure that business continuity matters are always addressed appropriately.
• Each plan should have a specific owner. • Emergency procedures, manual fallback plans, and resumption plans
should be within the responsibility of the owners of the appropriate business resources or processes involved.
• Fallback arrangements for alternative technical services, such as information processing and communications facilities, should usually be the responsibility of the service providers.
Considerations 14.1.4• A business continuity planning framework should address the identified
information security requirements and consider the following:– a) the conditions for activating the plans which describe the process to be followed (e.g.
how to assess the situation, who is to be involved) before each plan is activated;– b) emergency procedures, which describe the actions to be taken following an incident,
which jeopardizes business operations;– c) fallback procedures which describe the actions to be taken to move essential
businessactivities or support services to alternative temporary locations, and to bring business processes back into operation in the required time-scales;
– d) temporary operational procedures to follow pending completion of recovery and restoration;
– e) resumption procedures which describe the actions to be taken to return to normal business operations;
– f) a maintenance schedule which specifies how and when the plan will be tested, and the process for maintaining the plan;
– g) awareness, education, and training activities which are designed to create understanding of the business continuity processes and ensure that the processes continue to be effective;
– h) the responsibilities of the individuals, describing who is responsible for executing which component of the plan. Alternatives should be nominated as required;
– i) the critical assets and resources needed to be able to perform the emergency, fallback and resumption procedures.
ISO 27002 Control 14.1.5
• Business continuity plans should be tested and updated regularly to ensure that they are up to date and effective.
Implementation guidance 14.1.5
• Business continuity plan tests should ensure that all members of the recovery team and other relevant staff are aware of the plans and their responsibility for business continuity and information security and know their role when a plan is invoked.
• The test schedule for business continuity plan(s) should indicate how and when each element of the plan should be tested.
• Each element of the plan(s) should be tested frequently.
Business continuity planning
BCP Guidelines• Creating a BCP: Initiation
• Workgroup or team membership & objectives• Roles & responsibilities for planning, plan approval, &
quality assurance• List of business services & activities confirmed as vital• Business continuity planning processes
– Strategy & schedule for planning, progress reporting, plan review & approval, issue resolution process, communication & coordination strategy
• Affirmation of executive support• Assessment of current BCP, disaster recovery or
emergency preparedness plans
BCP Guidelines• Detailed Continuity Plans
(for each continuity item)• Continuity plan objectives & scope• Continuity plan triggers• Roles & responsibilities for continuity preparation &
deployment (including contact information)• Status reporting processes• Instructions to carry out continuity plan• Coordination strategy with other groups (if applicable)• Required resources & estimated costs• Agreements & assumptions with suppliers on whom
continuity plans are dependant• Communications strategy
Simulation exercise
• Simulation Exercise planning includes:
• Schedules and locations
• Procedures
• Expected results
• Acceptance criteria
BCP Guidelines
• Validation/testing results• Adequacy to support business continuity item• Capacity to manage, record and track business
continuity activities• Adequacy of business continuity processes• Adequacy of resource availability to implement
& sustain the continuity plan• Adequacy of overall business continuity
activities
Step 1: planning the simulation
Detailed Continuity Plans
• For each continuity item in our simulation– Factory floor– Office (General management) – Office (Human ressources and payroll)
Continuity plan objectives & scope
• Objectives– Ensure continuity in the event of a major
disruption, such as a fire or flood– Ensure that the employees will continue to receive
their paychecks to minimize the impact on our small community
• Scope– Factory and workers– Management (to coordinate resumption of
operations and repairs that are required, communications with the media)
– Human ressources (Payroll and employee support)
Continuity plan triggers
• The main trigger for our simulation is a minor fire in the exit end of one of the sawmill machines (there are 3)
• Other potential triggers could be:– Sprinklers starting– Toxic fumes or smoke detected– High dust contents– Water level in river rising past a critical mark (2M)
Roles & responsibilitiesRole Assigned to Duties
Big Boss and CIO MA Leger Sits arounds and looks important
CISO Mahmoud Leads all BCP activities and oversees all corporate security aspects for the factory
Project Manager Jorge Is in charge of the BCP project and tests
Business Unit Manager SWEE Is the client for the BCP and for the test, has final signing authority to approve resumption
Factory workers and system testers
AdaMarcello
Report to Swee in the business units and actuall perform the system approval, during setup implement the WiFi bridge
IT Staff (Windows) Svet Handles all Windows systems
IT Staff (Unix) Faisal Handles the Ubuntu servers
Firewall manager Boujeema Implements the Firewall , Honeypot and IDS
Network Manager Mustapha With ADA and Marcello, sets up the LAN and the WiFi bridge
Status reporting processes
CIO
CISO Project Manager BU Manager
Factory Worker 1 Factory Worker 1
IT Manager
Network Manager FW Manager IT Staff 1 IT Staff 2
Windows support
Unix support
Step 2: planning the activities
Instructions to carry out continuity plan
1. Arrival 9h00am
2. Group discussion on activities
3. Getting started: the incident
4. Execution
5. Lunch at 12h30
6. Debriefing 13h30 to 14h30
7. Putting the stuff away
Coordination strategy
• We won’t do it in this exercise.
Required resources & estimated costs
• We won’t do it in this exercise.
Agreements & assumptions with suppliers
• Not included in this simulation…
Communications strategy
• CISO will prepare a press release for the local paper to inform them of the production stoppage, every hour.
• The BU Manager will prepare a Memo to inform the employees of the situation and when activities are expected to resume every 2 hours.
• The PM will prepare a status report every 30 minutes in the morning untill the Network is ready and every hour thereafter untill the BU Manager has given approval.
Step 3: the simulation
Arrival 9h00am
• Arrival 9h00am
• Group discussion on activities
• Getting started: the incident
• Execution
• Lunch at 12h30
• Debriefing 13h30 to 14h30
• Putting the stuff away
Group discussion on activities
Roles & responsibilitiesRole Assigned to Duties
Big Boss and CIO MA Leger Sits arounds and looks important
CISO Mahmoud Leads all BCP activities and oversees all corporate security aspects for the factory
Project Manager Jorge Is in charge of the BCP project and tests
Business Unit Manager SWEE Is the client for the BCP and for the test, has final signing authority to approve resumption
Factory workers and system testers
AdaMarcello
Report to Swee in the business units and actuall perform the system approval, during setup implement the WiFi bridge
IT Staff (Windows) Svet Handles all Windows systems
IT Staff (Unix) Faisal Handles the Ubuntu servers
Firewall manager Boujeema Implements the Firewall , Honeypot and IDS
Network Manager Mustapha With ADA and Marcello, sets up the LAN and the WiFi bridge
Status reporting processes
CIO
CISO Project Manager BU Manager
Factory Worker 1 Factory Worker 1
IT Manager
Network Manager FW Manager IT Staff 1 IT Staff 2
Windows support
Unix support
Getting started: the incident
Trigger of plan• The fire alarm sets off
the initiation of the plan• The CISO alerts the PM
to get into action• All participants meet
and get started
Execution
• Priority 1: PC for project manager
• Priority 2: PC for CISO
• Priority 3: Network + bridge
• Priority 4: FW, servers and applications
• Priority 5: Testing and BU signoff
• Priority 6: getting ready to resume normal operations
Lunch at 12h30
Debriefing 13h30 to 14h30
• Validation/testing results• Adequacy to support business continuity item• Capacity to manage, record and track business
continuity activities• Adequacy of business continuity processes• Adequacy of resource availability to implement
& sustain the continuity plan• Adequacy of overall business continuity
activities
Putting the stuff away
End of this session
Session 17IT security auditing
Principles of auditing
• The principles that should apply to auditors– Ethical Conduct– Fair presentation– Due professional care– Auditor independence– Evidence-based approach
Defining IT Security Audit
• IT Audit– Independent review and examination of records
and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend changes in controls, policies, or procedures - DL 1.1.9
• Good Amount of Vagueness
• Ultimately defined by where you work
Who is an IT Auditor
• Accountant Raised to a CS Major– CPA, CISA, CISM, Networking, Hardware,
Software, Information Assurance, Cryptography– Some one who knows everything an accountant
does plus everything a BS/MS does about CS and Computer Security - Not likely to exist
• IT Audits Are Done in Teams– Accountant + Computer Geek = IT Audit Team– Scope to large– Needed expertise varies
Steps of An IT Audit
• 1. Planning Phase
• 2. Testing Phase
• 3. Reporting Phase
Ideally it’s a continuous cycleBut not always the case
Planning Phase
• Entry Meeting
• Define Scope
• Learn Controls
• Historical Incidents
• Past Audits
• Site Survey
• Review Current Policies
• Questionnaires
• Define Objectives
• Develop Audit Plan / Checklist
Defining Objectives US
• Some Points to Keep in Mind– Banking Regulations– SEC (Securities and Exchange Commission) – HIPPA – US Health Care– Sarbanes Oxley - Financial Reports, Document
Retention– Gramm-Leach Bliley - Consumer Financial
Information
Canada
Example Checklist
• “An Auditor’s Checklist for Performing a Perimeter Audit of on IBM ISERIES (AS/400) System” - Craig Reise– Scope of the audit does not include the Operating
System– Physical security– Services running
Testing Phase
• Meet With Site Managers– What data will be collected– How/when will it be collected– Site employee involvement– Answer questions
Testing Phase
• Data Collection– Based on scope/objectives
• Types of Data– Physical security– Interview staff– Vulnerability assessments– Access Control assessments
Reporting Phase
• Exit Meeting - Short Report– Immediate problems– Questions & answer for site managers– Preliminary findings– NOT able to give in depth information
Reporting Phase
• Long Report After Going Through Data– Intro defining objectives/scope– How data was collected– Summary of problems
• Table format• Historical data (if available)• Ratings• Fixes• Page # where in depth description is
Reporting Phase– In depth description of problem
• How problem was discovered• Fix (In detail)• Industry standards (if available)
– Glossary of terms– References
• Note: The Above Varies Depending on Where You Work
Preparing To Be Audited
• This Is NOT a Confrontation
• Make Your Self Available
• Know What The Scope/Objectives Are
• Know What Type of Data Will be Collected
• Know What Data Shouldn’t be Collected
Example - Auditing User & Groups
Application Audit
• An assessment Whose Scope Focuses on a Narrow but Business Critical Processes or Application– Excel spreadsheet with embedded macros used
to analyze data– Payroll process that may span across several
different servers, databases, operating systems, applications, etc.
– The level of controls is dependent on the degree of risk involved in the incorrect or unauthorized processing of data
Application Audit
1. Administration
2. Inputs, Processing, Outputs
3. Logical Security
4. Disaster Recovery Plan
5. Change Management
6. User Support
7. Third Party Services
8. General Controls
Administration
• Probably the most important area of the audit, because this area focuses on the overall ownership and accountability of the application– Roles & Responsibilities - development, change
approval, access authorization– Legal or regulatory compliance issues
Inputs, Processing, Outputs
• Looking for evidence of data preparation procedures, reconciliation processes, handling requirements, etc.– Run test transactions against the application– Includes who can enter input and see output– Retention of output and its destruction
Logical Security
• Looking at user creation and authorization as governed by the application its self– User ID linked to a real person– Number of allowable unsuccessful log-on
attempts– Minimum password length– Password expiration– Password Re-use ability
Disaster Recovery Plan
• Looking for an adequate and performable disaster recovery plan that will allow the application to be recovered in a reasonable amount of time after a disaster– Backup guidelines, process documentation, offsite
storage guidelines, SLA’s with offsite storage vendors, etc.
Change Management
• Examines the process changes to an application go through– Process is documented, adequate and followed– Who is allowed to make a request a change,
approve a change and make the change– Change is tested and doesn’t break compliance
(determined in Administration) before being placed in to production
User Support
• One of the most overlooked aspects of an application– User documentation (manuals, online help, etc.) -
available & up to date– User training - productivity, proper use, security– Process for user improvement requests
Third Party Services
• Look at the controls around any 3rd party services that are required to meet business objectives for the application or system– Liaison to 3rd party vendor– Review contract agreement– SAS (Statement on Auditing Standards) N0. 70 -
Service organizations disclose their control activities and processes to their customers and their customers’ auditors in a uniform reporting format
General Controls
• Examining the environment the application exists within that affect the application– System administration / operations– Organizational logical security– Physical security– Organizational disaster recovery plans– Organizational change control process– License control processes– Virus control procedures
End of this session
Session 18
Auditing for conformity and certification (SAS70, 5900, SOX, ISO, COBIT)
Performing an evaluation of ISO 27001 conformity
Preparing for an audit
Auditing for conformity and certification
What kind of conformity ?
• SAS70
• 5900
• SOX
• COBIT
• ISO 27001 ISMS
SAS 70 Overview• Statement on Auditing Standards (SAS) No. 70, Service
Organizations, is a widely recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA).
• A service auditor's examination performed in accordance with SAS No. 70 ("SAS 70 Audit") is widely recognized, because it represents that a service organization has been through an in-depth audit of their control objectives and control activities, which often include controls over information technology and related processes.
• In today's global economy, service organizations or service providers must demonstrate that they have adequate controls and safeguards when they host or process data belonging to their customers.
• In addition, the requirements of Section 404 of the Sarbanes-Oxley Act of 2002 make SAS 70 audit reports even more important to the process of reporting on the effectiveness of internal control over financial reporting.
5900 audit
• The Canadian Institute of Chartered Accountants (CICA) addresses service auditors' engagements in the CICA Handbook - Assurance Section 5900, "Opinions on Control Procedures at a Service Organization."
• Section 5900 would provide guidance to a Canadian chartered accountant who wants to perform an audit of a service organization's controls.
SOX Section 404 Assessment
• The most contentious aspect of SOX is Section 404, which requires management and the external auditor to report on the adequacy of the company's internal control over financial reporting (ICFR).
• This is the most costly aspect of the legislation for companies to implement, as documenting and testing important financial manual and automated controls requires enormous effort.
SOX Internal control report• Under Section 404 of the Act, management is
required to produce an “internal control report” as part of each annual Exchange Act report.
• See 15 U.S.C. § 7262. The report must affirm “the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting.”
• 15 U.S.C. § 7262(a). The report must also “contain an assessment, as of the end of the most recent fiscal year of the Company, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.”
• To do this, managers are generally adopting an internal control framework such as that described in COSO.
SOX Risk assessment
• Both management and the external auditor are responsible for performing their assessment in the context of a top-down risk assessment, which requires management to base both the scope of its assessment and evidence gathered on risk.
• Both the PCAOB and SEC recently issued guidance on this topic to help alleviate the significant costs of compliance and better focus the assessment on the most critical risk areas.
SOX PCAOB requirements• Auditing Standard No. 5[17] of the Public Company Accounting Oversight
Board (PCAOB), which superseded Auditing Standard No 2., has the following key requirements for the external auditor:
• Assess both the design and operating effectiveness of selected internal controls related to significant accounts and relevant assertions, in the context of material misstatement risks;
• Understand the flow of transactions, including IT aspects, sufficiently to identify points at which a misstatement could arise;
• Evaluate company-level (entity-level) controls, which correspond to the components of the COSO framework;
• Perform a fraud risk assessment; • Evaluate controls designed to prevent or detect fraud, including management
override of controls; • Evaluate controls over the period-end financial reporting process; • Scale the assessment based on the size and complexity of the company; • Rely on management's work based on factors such as competency, objectivity, and
risk; • Evaluate controls over the safeguarding of assets; and • Conclude on the adequacy of internal control over financial reporting. • The recently released SEC guidance [18] is generally consistent with the PCAOB's
guidance above, only intended for management.• After the release of this guidance, the SEC required smaller public
companies to comply with SOX Section 404, companies with year ends after December 15, 2007.
COBIT• The IT Governance Institute® (ITGI) has published version
COBIT® 4.1. • COBIT is an IT governance framework and supporting toolset
that allows managers to bridge the gap between control requirements, technical issues and business risks.
• COBIT enables clear policy development and good practice for IT control throughout organizations.
• COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from IT, enables alignment and simplifies implementation of the COBIT framework.
• COBIT 4.1 can be used to enhance work already done based upon earlier versions; it does not invalidate that previous work.
• When major activities are planned for IT governance initiatives, or when an overhaul of the enterprise control framework is anticipated, it is recommended to start fresh with the most recent version of COBIT.
Classic questions for management
Three dimensions of COBIT maturity
COBIT Cube
Overall COBIT
framework
Performing an evaluation of ISO 27001 conformity
• Based on ISO 19011: Management system audit
• Section 5: Managing an audit program
• Section 6: Audit activities
• Section 7: Competence and evaluation of auditors
Managing an audit programme
ISO 19011 section 5
General considerations• An audit programme may include one or more
audits, depending upon the size, nature and complexity of the organization to be audited.
• These audits may have a variety of objectives and may also include joint or combined audits.
• An audit programme also includes all activities necessary for planning and organizing the types and number of audits, and for providing resources to conduct them effectively and efficiently within the specified time frames.
• An organization may establish more than one audit programme.
• The organization’s top management should grant the authority for managing the audit programme.
Management responsabilities
• Those assigned the responsibility for managing the audit programme should:
a) establish, implement, monitor, review and improve the audit programme, and
b) identify the necessary resources and ensure they are provided.
Process flow for the management of an audit programme
Examples of audit programmes• Examples of audit programmes include the
following:a) a series of internal audits covering an organization-wide
quality management system for the current year;b) second-party management system audits of potential
suppliers of critical products to be conducted within 6 months;
c) certification/registration and surveillance audits conducted by a third-party certification/registration body on an environmental management system within a time period agreed contractually between the certification bodyand the client.
• An audit programme also includes appropriate planning, the provision of resources and the establishment of procedures to conduct audits within the programme.
Audit programme objectives
ISO 19011 section 5.2
Objectives of an audit programme
• Objectives should be established to direct the planning and conduct of audits.
• These objectives can be based on consideration of:
a) management priorities,
b) commercial intentions,
c) management system requirements,
d) statutory, regulatory and contractual requirements,
e) need for supplier evaluation,
f) customer requirements,
g) needs of other interested parties, and
h) risks to the organization.
Examples of objectives
• Examples include the following:a) to meet requirements for certification to a
management system standard;
b) to verify conformance with contractual requirements;
c) to obtain and maintain confidence in the capability of a supplier;
d) to contribute to the improvement of the management system.
Extent of an audit programme• The extent can vary and will be influenced by the
size, nature and complexity of the organization to be audited, as well as by the following:
a) the scope, objective and duration of each audit to be conducted;
b) the frequency of audits to be conducted;
c) the number, importance, complexity, similarity and locations of the activities to be audited;
d) standards, statutory, regulatory and contractual requirements and other audit criteria;
e) the need for accreditation or registration/certification;
f) conclusions of previous audits or results of a previous audit programme review;
g) any language, cultural and social issues;
h) the concerns of interested parties;
i) significant changes to an organization or its operations.
Audit programme responsibilities, resources and procedures
ISO 19011 section 5.3
Audit programme responsibilities• The responsibility for managing an audit
programme should be assigned to one or more individuals with a general understanding of audit principles, of the competence of auditors and the application of audit techniques.
• They should have management skills as well as technical and business understanding relevant to the activities to be audited.
• Those assigned the responsibility for managing the audit programme should
a) establish the objectives and extent of the audit programme,b) establish the responsibilities and procedures, and ensure
resources are provided,c) ensure the implementation of the audit programme,d) ensure that appropriate audit programme records are maintained,
ande) monitor, review and improve the audit programme.
Audit programme resources
• When identifying resources consideration should be given to:
a) financial resources necessary to develop, implement, manage and improve audit activities,
b) audit techniques,
c) processes to achieve and maintain the competence of auditors, and to improve auditor performance,
d) the availability of auditors and technical experts having competence appropriate to the particular auditprogramme objectives,
e) the extent of the audit programme, and
f) travelling time, accommodation and other auditing needs.
Audit programme procedures• Audit programme procedures should address the
following:a) planning and scheduling audits;
b) assuring the competence of auditors and audit team leaders;
c) selecting appropriate audit teams and assigning their roles and responsibilities;
d) conducting audits;
e) conducting audit follow-up, if applicable;
f) maintaining audit programme records;
g) monitoring the performance and effectiveness of the audit programme;
h) reporting to top management on the overall achievements of the audit programme.
• For smaller organizations, the activities above can be addressed in a single procedure.
Audit programme implementation• The implementation of an audit programme should
address the following:a) communicating the audit programme to relevant parties;b) coordinating and scheduling audits and other activities relevant to
the audit programme;c) establishing and maintaining a process for the evaluation of the
auditors and their continual professionaldevelopment, in accordance with respectively 7.6 and 7.5;
d) ensuring the selection of audit teams;e) providing necessary resources to the audit teams;f) ensuring the conduct of audits according to the audit programme;g) ensuring the control of records of the audit activities;h) ensuring review and approval of audit reports, and ensuring their
distribution to the audit client and otherspecified parties;
i) ensuring audit follow-up, if applicable.
Audit programme records• Records should be maintained to demonstrate the
implementation of the audit programme and should include the following:
a) records related to individual audits, such as– audit plans,– audit reports,– nonconformity reports,– corrective and preventive action reports, and– audit follow-up reports, if applicable;
b) results of audit programme review;c) records related to audit personnel covering subjects such as
– auditor competence and performance evaluation,– audit team selection, and– maintenance and improvement of competence.
• Records should be retained and suitably safeguarded.
Monitoring and reviewing• The implementation of the audit programme should
be monitored and, at appropriate intervals, reviewed to assess whether its objectives have been met and to identify opportunities for improvement. The results should be reported to top management.
• Performance indicators should be used to monitor characteristics such as– the ability of the audit teams to implement the audit plan,– conformity with audit programmes and schedules, and– feedback from audit clients, auditees and auditors.
The audit programme review should consider:
a) results and trends from monitoring,b) conformity with procedures,c) evolving needs and expectations of interested
parties,d) audit programme records,e) alternative or new auditing practices, andf) consistency in performance between audit teams
in similar situations.
• Results of audit programme reviews can lead to corrective and preventive actions and the improvement of the auditprogramme.
Audit activities
ISO 19011 section 6
General
• This clause contains guidance on planning and conducting audit activities as part of an audit programme.
• Figure (next slide) provides an overview of typical audit activities.
• The extent to which the provisions of this clause are applicable depends on the scope and complexity of the specific audit and the intended use of the audit conclusions.
Overview of typical audit activities
Initiating the audit
Appointing the audit team leader
• Those assigned the responsibility for managing the audit programme should appoint the audit team leader for the specific audit.
• Where a joint audit is conducted, it is important to reach agreement among the auditing organizations before the audit commences on the specific responsibilities of each organization, particularly with regard to the authority of the team leader appointed for the audit.
Defining audit objectives, scope and criteria
• Within the overall objectives of an audit programme, an individual audit should be based on documented objectives, scope and criteria.
Objectives
• The audit objectives define what is to be accomplished by the audit and may include the following:
a) determination of the extent of conformity of the auditee's management system, or parts of it, with audit criteria;
b) evaluation of the capability of the management system to ensure compliance with statutory, regulatory and
contractual requirements;
c) evaluatation of the effectiveness of the management system in meeting its specified objectives;
d) identification of areas for potential improvement of the management system.
Scope
• The audit scope describes the extent and boundaries of the audit, such as physical locations, organizational units, activities and processes to be audited, as well as the time period covered by the audit.
Criteria
• The audit criteria are used as a reference against which conformity is determined and may include:– applicable policies, – procedures, – standards, – laws and regulations, – management system requirements, – contractual requirements– industry/business sector codes of conduct.
Who determines them• The objectives should be defined by the audit client.• The audit scope and criteria should be defined
between the audit client and the audit team leader in accordance with audit programme procedures.
• Any changes to the audit objectives, scope or criteria should be agreed to by the same parties.
• Where a combined audit is to be conducted, it is important that the audit team leader ensures that the audit objectives, scope and criteria are appropriate to the nature of the combined audit.
Determining the feasibility of the audit
• The feasibility of the audit should be determined, taking into consideration such factors as the availability of– sufficient and appropriate information for planning
the audit,– adequate cooperation from the auditee, and– adequate time and resources.
• Where the audit is not feasible, an alternative should be proposed to the audit client, in consultation with the auditee.
Selecting the audit team• When the audit has been declared feasible, an audit team should be
selected, taking into account the competence needed to achieve the objectives of the audit. If there is only one auditor, the auditor should perform all applicable duties of an audit team leader.
• ISO 19011 Clause 7 contains guidance on determining the competence needed and describes processes for evaluating auditors.
• In deciding the size and composition of the audit team, consideration should be given to the following:
a) audit objectives, scope, criteria and estimated duration of the audit;b) whether the audit is a combined or joint audit;c) the overall competence of the audit team needed to achieve the objectives of the
audit;d) statutory, regulatory, contractual and accreditation/certification requirements, as
applicable;e) the need to ensure the independence of the audit team from the activities to be
audited and to avoid conflict ofinterest;f) the ability of the audit team members to interact effectively with the auditee and to
work together;g) the language of the audit, and an understanding of the auditee’s particular social
and cultural characteristics;• These issues may be addressed either by the auditor's own skills or
through the support of a technical expert.
Assuring competence• The process of assuring the overall competence of
the audit team should include the following steps:– identification of the knowledge and skills needed to
achieve the objectives of the audit;– selection of the audit team members such that all of the
necessary knowledge and skills are present in the audit team.
• If not fully covered by the auditors in the audit team, the necessary knowledge and skills may be satisfied by including technical experts.
• Technical experts should operate under the direction of an auditor.
• Auditors-in-training may be included in the audit team, but should not audit without direction or guidance.
Replacing an auditor• Both the audit client and the auditee can request the
replacement of particular audit team members on reasonable grounds based on the principles of auditing described in clause 4.
• Examples of reasonable grounds include conflict of interest situations (such as an audit team member having been a former employee of the auditee or having provided consultancy services to the auditee) and previous unethical behaviour.
• Such grounds should be communicated to the audit team leader and to those assigned responsibility for managing the audit programme, who should resolve the issue with the audit client and auditee before making any decisions on replacing audit team members.
Establishing initial contact• The initial contact for the audit with the auditee may
be informal or formal, but should be made by those assigned responsibility for managing the audit programme or the audit team leader.
• The purpose of the initial contact isa) to establish communication channels with the auditee’s
representative,b) to confirm the authority to conduct the audit,c) to provide information on the proposed timing and audit team
composition,d) to request access to relevant documents, including records,e) to determine applicable site safety rules,f) to make arrangements for the audit, andg) to agree on the attendance of observers and the need for guides
for the audit team.
Conducting document review• Prior to the on-site audit activities the auditee’s documentation should be
reviewed to determine the conformity of the system, as documented, with audit criteria.
• The documentation may include relevant management system documents and records, and previous audit reports.
• The review should take into account the size, nature and complexity of the organization, and the objectives and scope of the audit. In some situations, this review may be deferred until the on-site activities commence, if this is not detrimental to the effectiveness of the conduct of the audit.
• In other situations, a preliminary site visit may be conducted to obtain a suitable overview of available information.
• If the documentation is found to be inadequate, the audit team leader should inform the audit client, those assigned responsibility for managing the audit programme, and the auditee.
• A decision should be made as to whether the audit should be continued or suspended until documentation concerns are resolved.
Preparing for the on-site audit activities
ISO 19011 section 6.4
Preparing the audit plan• The audit team leader should prepare an audit plan
to provide the basis for the agreement among the audit client, audit team and the auditee regarding the conduct of the audit.
• The plan should facilitate scheduling and coordination of the audit activities.
• The amount of detail provided in the audit plan should reflect the scope and complexity of the audit.
• The details may differ, for example, between initial and subsequent audits and also between internal and external audits.
• The audit plan should be sufficiently flexible to permit changes, such as changes in the audit scope, which can become necessary as the on-site audit activities progress.
The audit plan should cover:a) the audit objectives;b) the audit criteria and any reference documents;c) the audit scope, including identification of the
organizational and functional units and processes to be audited;
d) the dates and places where the on-site audit activities are to be conducted;
e) the expected time and duration of on-site audit activities, including meetings with the auditee’s management and audit team meetings;
f) the roles and responsibilities of the audit team members and accompanying persons;
g) the allocation of appropriate resources to critical areas of the audit.
The plan should also cover the following, as appropriate:
h) identification of the auditee’s representative for the audit;
i) the working and reporting language of the audit where this is different from the language of the auditor and/or the auditee;
j) the audit report topics;
k) logistic arrangements (travel);
l) matters related to confidentiality;
m) any audit follow-up actions.
Plan acceptance
• The plan should be reviewed and accepted by the audit client, and presented to the auditee, before the on-site audit activities begin.
• Any objections by the auditee should be resolved between the audit team leader, the auditee and the audit client.
• Any revised audit plan should be agreed among the parties concerned before continuing the audit.
Assigning work to the audit team• The audit team leader, in consultation with the audit
team, should assign to each team member responsibility for auditing specific processes, functions, sites, areas or activities.
• Such assignments should take into account the need for the independence and competence of auditors and the effective use of resources, as well as different roles and responsibilities of auditors, auditors-in-training and technical experts.
• Changes to the work assignments may be made as the audit progresses to ensure the achievement of the audit objectives.
Preparing work documents• The audit team members should review the information
relevant to their audit assignments and prepare work documents as necessary for reference and for recording audit proceedings.
• Such work documents may include– checklists and audit sampling plans, and– forms for recording information, such as supporting evidence, audit
findings and records of meetings.• The use of checklists and forms should not restrict the extent
of audit activities, which can change as a result of information collected during the audit.
• Work documents, including records resulting from their use, should be retained at least until audit completion.
• Retention of documents after audit completion.• Those documents involving confidential or proprietary
information should be suitably safeguarded at all times by the audit team members.
Conducting on-site audit activities
ISO 19011 Section 6.5
Conducting the opening meeting
• An opening meeting should be held with the auditee’s management or, where appropriate, those responsible for the functions or processes to be audited.
• The purpose of an opening meeting isa) to confirm the audit plan,
b) to provide a short summary of how the audit activities will be undertaken,
c) to confirm communication channels, and to provide an opportunity for the auditee to ask questions.
Practical help — Opening the meeting• In many instances, for example internal audits in a small organization, the opening
meeting may simply consist of communicating that an audit is being conducted and explaining the nature of the audit.
• For other audit situations, the meeting should be formal and records of the attendance should be kept.
• The meeting should be chaired by the audit team leader, and the following items should be considered, as appropriate:
a) introduction of the participants, including an outline of their roles;b) confirmation of the audit objectives, scope and criteria;c) confirmation of the audit timetable and other relevant arrangements with the auditee, such as
the date and time for the closing meeting, any interim meetings between the audit team and the auditee's management, and any late changes;
d) methods and procedures to be used to conduct the audit, including advising the auditee that the audit evidence will only be based on a sample of the information available and that therefore there is an element of uncertainty in auditing;
e) confirmation of formal communication channels between the audit team and the auditee;f) confirmation of the language to be used during the audit;g) confirmation that, during the audit, the auditee will be kept informed of audit progress;h) confirmation that the resources and facilities needed by the audit team are available;i) confirmation of matters relating to confidentiality;j) confirmation of relevant work safety, emergency and security procedures for the audit team;k) confirmation of the availability, roles and identities of any guides;l) the method of reporting, including any grading of nonconformities;m) information about conditions under which the audit may be terminated;n) information about any appeal system on the conduct or conclusions of the audit.
Communication during the audit• Depending upon the scope and complexity of the audit, it can be necessary to
make formal arrangements for communication within the audit team and with the auditee during the audit.
• The audit team should confer periodically to exchange information, assess audit progress, and to reassign work between the audit team members as needed.
• During the audit, the audit team leader should periodically communicate the progress of the audit and any concerns to the auditee and audit client, as appropriate.
• Evidence collected during the audit that suggests an immediate and significant risk (e.g. safety, environmental or quality) should be reported without delay to the auditee and, as appropriate, to the audit client.
• Any concern about an issue outside the audit scope should be noted and reported to the audit team leader, for possible communication to the audit client and auditee.
• Where the available audit evidence indicates that the audit objectives are unattainable, the audit team leader should report the reasons to the audit client and the auditee to determine appropriate action. Such action may include reconfirmation or modification of the audit plan, changes to the audit objectives or audit scope, or termination of the audit.
• Any need for changes to the audit scope which can become apparent as on-site auditing activities progress should be reviewed with and approved by the audit client and, as appropriate, the auditee.
Roles and responsibilities of observers
• Guides and observers may accompany the audit team but are not a part of it.
• They should not influence or interfere with the conduct of the audit.
• When guides are appointed by the auditee, they should assist the audit team and act on the request of the audit team leader.
• Their responsibilities may include the following:a) establishing contacts and timing for interviews;b) arranging visits to specific parts of the site or organization;c) ensuring that rules concerning site safety and security procedures
are known and respected by the audit team members;d) witnessing the audit on behalf of the auditee;e) providing clarification or assisting in collecting information.
Collecting and verifying information• During the audit, information relevant to the audit
objectives, scope and criteria, including information relating to interfaces between functions, activities and processes, should be collected by appropriate sampling and should be verified. Only information that is verifiable may be audit evidence. Audit evidence should be recorded.
• The audit evidence is based on samples of the available information. Therefore there is an element of uncertainty in auditing, and those acting upon the audit conclusions should be aware of this uncertainty.
Overview of the process from collecting to reaching conclusions
Methods to collect information include
• interviews,
• observation of activities, and
• review of documents.
Practical help — Sources of information
• The sources of information chosen may vary according to the scope and complexity of the audit and may include the following:
a) interviews with employees and other persons;b) observations of activities and the surrounding work environment
and conditions;c) documents, such as policy, objectives, plans, procedures,
standards, instructions, licences and permits, specifications, drawings, contracts and orders;
d) records, such as inspection records, minutes of meetings, audit reports, records of monitoring programmes and the results of measurements;
e) data summaries, analyses and performance indicators;f) information on the auditee’s sampling programmes and on
procedures for the control of sampling and measurement processes;
g) reports from other sources, for example, customer feedback, other relevant information from external parties and supplier ratings;
h) computerized databases and web sites.
Practical help — Conducting interviews
• Interviews are one of the important means of collecting information and should be carried out in a manner adapted to the situation and the person interviewed.
• The auditor should consider the following:a) interviews should be held with persons from appropriate levels and
functions performing activities or taskswithin the scope of the audit;b) interviews should be conducted during the normal working hours and,
where practical, at the normal workplaceof the person being interviewed;c) every attempt should be made to put the person being interviewed at ease
prior to and during the interview;d) the reason for the interview and any note taking should be explained;e) interviews can be initiated by asking the persons to describe their work;f) questions that bias the answers (i.e. leading questions) should be avoided;g) the results from the interview should be summarized and reviewed with
the interviewed person;h) the interviewed persons should be thanked for their participation and
cooperation.
Generating audit findings• Audit evidence should be evaluated against the audit criteria to generate
the audit findings. • Audit findings can indicate either conformity or nonconformity with audit
criteria. When specified by the audit objectives, audit findings can identify an opportunity for improvement.
• The audit team should meet as needed to review the audit findings at appropriate stages during the audit.
• Conformity with audit criteria should be summarized to indicate locations, functions or processes that were audited.
• If included in the audit plan, individual audit findings of conformity and their supporting evidence should also be recorded.
• Nonconformities and their supporting audit evidence should be recorded. • Nonconformities may be graded. • They should be reviewed with the auditee to obtain acknowledgement
that the audit evidence is accurate, and that the nonconformities are understood.
• Every attempt should be made to resolve any diverging opinions concerning the audit evidence and/or findings, and unresolved points should be recorded.
Preparing audit conclusions
• The audit team should confer prior to the closing meetinga) to review the audit findings, and any other
appropriate information collected during the audit, against the audit objectives,
b) to agree on the audit conclusions, taking into account the uncertainty inherent in the audit process,
c) to prepare recommendations, if specified by the audit objectives, and
d) to discuss audit follow-up, if included in the audit plan.
Practical help — Audit conclusions
• Audit conclusions can address issues such asa) the extent of conformity of the management system with the audit
criteria,
b) the effective implementation, maintenance and improvement of the management system, and
c) the capability of the management review process to ensure the continuing suitability, adequacy, effectiveness and improvement of the management system.
• If specified by the audit objectives, audit conclusions can lead to recommendations regarding improvements, business relationships, certification/registration or future auditing activities.
Conducting the closing meeting• A closing meeting, chaired by the audit team leader, should be held to
present the audit findings and conclusions in such a manner that they are understood and acknowledged by the auditee, and to agree, if appropriate, on the timeframe for the auditee to present a corrective and preventive action plan. Participants in the closing meeting should include the auditee, and may also include the audit client and other parties.
• If necessary, the audit team leader should advise the auditee of situations encountered during the audit that may decrease the reliance that can be placed on the audit conclusions.
• In many instances, for example internal audits in a small organization, the closing meeting may consist of just communicating the audit findings and conclusions.
• For other audit situations, the meeting should be formal and minutes, including records of attendance, should be kept.
• Any diverging opinions regarding the audit findings and/or conclusions between the audit team and the auditee should be discussed and if possible resolved. If not resolved, all opinions should be recorded.
• If specified by the audit objectives, recommendations for improvements should be presented.
• It should be emphasized that recommendations are not binding.
Preparing, approving and distributing the audit report
ISO 19011 Section 6.6
Preparing the audit report• The audit team leader should be responsible for the preparation and contents of the audit report.• The audit report should provide a complete, accurate, concise and clear record of the audit, and should include or• refer to the following:• a) the audit objectives;• b) the audit scope, particularly identification of the organizational and functional units or processes audited and• the time period covered;• c) identification of the audit client;• d) identification of audit team leader and members;• e) the dates and places where the on-site audit activities were conducted;• f) the audit criteria;• g) the audit findings;• h) the audit conclusions.• The audit report may also include or refer to the following, as appropriate:• i) the audit plan;• j) a list of auditee representatives;• k) a summary of the audit process, including the uncertainty and/or any obstacles encountered that could• decrease the reliability of the audit conclusions;• l) confirmation that the audit objectives have been accomplished within the audit scope in accordance with the• audit plan;• m) any areas not covered, although within the audit scope;• n) any unresolved diverging opinions between the audit team and the auditee;• o) recommendations for improvement, if specified in the audit objectives;• p) agreed follow-up action plans, if any;• q) a statement of the confidential nature of the contents;• r) the distribution list for the audit report.
Approving and distributing the report• The audit report should be issued within the agreed time
period. If this is not possible, the reasons for the delay• should be communicated to the audit client and a new issue
date should be agreed.• The audit report should be dated, reviewed and approved in
accordance with audit programme procedures.• The approved audit report should then be distributed to
recipients designated by the audit client.•
• The audit report is the property of the audit client. The audit team members and all report recipients should respect
• and maintain the confidentiality of the report.
Completing the audit• The audit is completed when all activities described in the
audit plan have been carried out and the approved audit report has been distributed.
• Documents pertaining to the audit should be retained or destroyed by agreement between the participating parties
• and in accordance with audit programme procedures and applicable statutory, regulatory and contractual requirements.
• Unless required by law, the audit team and those responsible for managing the audit programme should not disclose the contents of documents, any other information obtained during the audit, or the audit report, to any other party without the explicit approval of the audit client and, where appropriate, the approval of the auditee.
• If disclosure of the contents of an audit document is required, the audit client and auditee should be informed as soon as possible.
Conducting follow-up• The conclusions of the audit may indicate the need
for corrective, preventive or improvement actions, as applicable. Such actions are usually decided and undertaken by the auditee within an agreed timeframe and are not considered to be part of the audit. The auditee should keep the audit client informed of the status of these actions.
• The completion and effectiveness of corrective action should be verified. This verification may be part of a subsequent audit.
• The audit programme may specify follow-up by members of the audit team, which adds value by using their expertise. In such cases, care should be taken to maintain independence in subsequent audit activities.
Certification
The example of ISO 27001
The Certification Audit:Accredited Certification
Authorises
Accredits
Certificates
Certification Schemes
• Certification schemes established in many parts of world
• Various National Accreditation Bodies around the world operate on "mutual recognition": certificates awarded in one country are accepted by Accreditation Body of another
• To be awarded a recognised certificate, your ISMS will be audited by a UKAS Accredited Certification Body.
• Assessor cannot be a consultant.
• Assessor will work for a Certification Body
Certification for ISO27001
• ISO27001 certification provides evidence and assurance an organisation has complied with the control objectives set out in the standards documentation.
• Certification outlines scope of an organisations ISMS, and any exclusions to the control objectives (SoA).
• Verified by independent assessor who performs audit in accordance with controls set out in ISO27001:2005
Should one Certificate?• Decision is subjective. Certification requires
company: – Defined the scope of the ISMS– Documented and implemented the ISMS in accordance
with the control objectives set out in Annex A of ISO27001– Provided justification if required of any exclusions
• Requires audit of implemented ISMS by assessor • Certification:
– Arduous and continuous process; should be considered carefully
– Once certification achieved needs maintenance– Periodic reviews, site visits every 6 months– Re-certification every 3 year
What is Required for Certification?
• Conformance to ISO27001
• Certification process requires external review by assessor
• Assessor works for accredited certification body
• Assessor audits your organization’s ISMS to ISO27001
• Successful audit results in certificate; details scope of ISMS and reference statement of applicability.
Benefits of Certification
• In addition to the benefits obtained through compliance, certification also offers the following additional benefits: – Credibility and confidence– Compliance: with relevant laws and regulations– Shows that you have taken all the necessary
precautions required to minimise the risks to your business.
– Notably fulfilling your fiduciary responsibilities as an organisation in the protection of your company’s assets.
Summary of benefits
• Recognized certification– Assurance to customers; their data is safe with you– Assurance to employees, partners and suppliers; their
data is safe with you
• Information security policy fits business needs– Reduced outages, stoppages and other information
security frustrations– Aligned with business goals– Security spend proportionate to value at risk– Everyone responsible, not just IT department– Formalisation of policies and procedures
already in place
Accredited Certification Bodies
• Government recognised– BNQ, QMI
• Select and treat as any other supplier– Quotes– Interview– Confidentiality agreement(s)– Terminology– Process– Cultural fit– Value add? (integrated audits?)
Pre-Audit
• Pre-certification assessment workbook “Are You Ready for an ISMS Audit Based on ISO/IEC 27001?”:– Assess and record extent of compliance with
ISO27001 control requirements and aid preparations for certification audit.
• Completed workbook/checklist could serve as a Gap Analysis.
• Purchase thru’ www.itgovernance.co.uk
Documentation Assessment• On site or desk audit• Examines ISMS framework for compliance with
ISO27001 clause 4.3• Looks at policy, scope, risk assessment, risk
management selection of controls, and statement of applicability
• Unlikely to look at specific procedures in depth• Expect adequate references to standards,
procedures and work instructions• Documentation assessment constitutes a significant
part of the assessment process
Conformance Assessment• Examine nonconformities from Documentation
Assessment• Audit sample to verify implementation and operation
of ISMS– Similar approach to ISO 9001 audit– More focused– Drill down
• Major/Minor non-conformances • Assessment Team Leader makes recommendation
(not final decision)• Must take corrective action within 3 months if
nonconformities are documented during the assessment
Audit Objectives
• Determine conformity or nonconformity of the management system elements with specified requirements
• Determine the effectiveness of the implemented management system in meeting specified objectives
• Provide the auditee with an opportunity to improve the management system
• As seen in ISO19011
Certification
• Certification Body will award the certificate.
• The certificate will document the scope of your ISMS and other relevant details, such as the Statement of Applicability.
Common problems: Risk Assessment
• Incomplete asset register
• Staff risk not included
• Method too complicated
• No team approach
• Not approved by top management
Common problems: Risk Treatment
• Measure of effectiveness: has control been successful?
• Control selection: exclusions justified?
• Statement of Applicability under document control
Miscellaneous common problems
• Server room location
• Server room not secure
• BCP not tested
• Incidents not reported by all staff
• Insufficient evidence to demonstrate improvement
• Equipment taken off site is not cleared of sensitive data/lack of authorization
Management (Check)
• Possible CHECK activities– Intrusion detection– Incident handling– Routine checks– Self-policing procedures– Learning from others– Internal ISMS audit– External Audits– Measures of Efffectiveness
Myths Exploded
• ISO27001 is an IT project
• Have you been paying attention?
Myths Exploded
• ISO27001 project is just another ISO9001 certification with a slightly different focus
• Scope cannot reduce workload by limiting departments/geographical sites
• A business change project
• 3rd Party accredited certification audit takes up to 3 times of ISO9001 equivalent
Myths Exploded
• Senior management commitment to certification means an ISMS will work
• Ideally senior managers will be committed to the benefits of an ISMS, not just certification
• Reality is this:– Initially senior management want commercial
benefits = certification, not ISMS;– If ISMS is approached correctly soon start to
appreciate value of it– The ISMS (& culture) are valued and have
support and commitment (system matures)
Myths Exploded
• All security attacks require preventive action• ISMS accepts some security events• Consider risk criteria• Should reflect 'impact' & 'likelihood' estimates in latest risk assessment.
(CHECK!)
If they do• Act
– Take corrective action (NOT preventive!) (Plan & Do)
– Flag them in incident analysis
If they do not:• Act
– Take corrective action• Plan
– Review risk assessment for threat in light of informed (new) position
– Select controls• Do
– Implement preventive controls• Check
– Monitor controls are achieving objective(s)
• Act– As result of 'normal' PDCA cycle
Myths Exploded
• ISMS stops evolving in preparation for audit
• Assessments should become second nature; no special preparation should be necessary
• Reality is this:– Never happens for initial assessment;– Seldom happens for continuous assessment– Where it does the ISMS (& culture) are
approaching high maturity
Myths Exploded
• Continuous improvement of an ISMS equates to raising the level of security
• Continuous improvement of an ISMS:– Ensures ISMS evolves in light of developing
technology, threats, new assets and vulnerabilities.
– Improves efficiency of ISMS and controls in meeting security objectives; and
– Improves effectiveness of ISMS and controls in meeting security objectives
Myths Exploded
Continuous improvement should peak prior to an audit
Excellence
Audit TimeC A VE ff o rt
End of this session
Session 19
Student presentations: term project
Review and preparation for the final exam
Student presentations
Term project
Review for the final exam
Using selected slidesfrom the course
End of this session
Session 20Final exam
Please note
• These slides are produced as presentation material for a technical college course, all references, sources and bibliographical information is available in the commentaries section of the PowerPoint presentation and may not be visible to viewers of PDF versions.
• The course instructor has no pretensions to be the original author of any of the material.
End of this course
