By Marc-André Léger DESS, MASc, PHD(candidate)

By Marc-André Léger DESS, MASc, PHD(candidate)
Incident Management By Marc-André Léger DESS, 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

Contact information Contact: Website:

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.

Basics of computer incident and incident Handling
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. Source: Incident Response: Computer Forensics Toolkit, Douglas Schweitzer, (John Wiley, 2003)‏

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 in Incident 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.
CMU/SEI-2003-HB-002

Saint Lawrence Sawmill
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: $ Wiring and infrastructure: $ Service Contracts: $ per year Software: $ + license fee 15 000$ per year Configuration and conversion: $ Training: $ Consulting services: $ Installation: $ Contingencies (10%): $

Layout

End of this session

Computer security policies
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
[PPT] Security Policies, Standards & Procedures Format de fichier: Microsoft Powerpoint - Version HTML Writing style. Reflect organisational culture & industry; Clear, ... Development not done in isolation; Effective Information Security Policy

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

Standard‏s Definition: Development
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 * Oxford Dictionary of Current English, 1998

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… Bring cow into barn Tell cow to stand still Fetch bucket and stool Sit on stool next to cow Squirt milk into bucket

Procedures Definition(s)‏ OR Development Way of performing a task
Series of actions conducted in a certain manner Development Individuals responsible for daily tasks * Oxford Dictionary of Current English, 1998

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 Audit requirements Good practice Risk management
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 ARCHIVE 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

Approach    DEVELOPMENT PHASE INITIALISATION FINALISATION
& APPROVAL KEY ACTIVITIES Confirm Policy Framework Define Policy / Standard Management Processes Confirm Document Format Research topic Prepare draft Workshop content Revisit content (Review cycle)‏ Finalise Policies / Standards for Approval Present Policies / Standards for KEY DELIVERABLES Policy Framework Policy / Standard Management Processes Document Template Draft for discussion Final Draft Final Policies / Standards

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 Formatting
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 & Reporting
Owner – 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

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 Introduction Executive Management Commitment
Compliance Statement Policy Principles Roles & Responsibilities 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 Approval of Policy (Signature)‏
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 ISO ISF’s Standard of Good Practice

Information security policy
Based on ISO/IEC 27002(2005) Section 5.1

ISO Control Objective To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations. ISO/IEC 27002(2005)

Information security policy document
ISO/IEC 27002(2005) Control 5.1.1 ISO/IEC 27002(2005)

ISO Control An information security policy document should be approved by management, and published and communicated to all employees and relevant external parties. ISO/IEC 27002(2005)

Implementation guidance
The information security policy document should state management commitment and set out the organization’s approach to managing information security. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

Review of the information security policy
ISO/IEC 27002(2005) Control 5.1.2 ISO/IEC 27002(2005)

ISO Control The information security policy should be reviewed at planned intervals or if significant changes occur to ensure its continuing suitability, adequacy, and effectiveness. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

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 and ); 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

Change management Information security policy implementation
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 This chapter focuses on information security policy: what it is, how to write it, how to implement it, and how to maintain it. Policy is the essential foundation of an 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. You, the policy maker, set the tone and the emphasis on how important a role information security will have within your agency. Your primary responsibility is 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.”

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. Introduction This chapter focuses on information security policy: what it is, how to write it, how to implement it, and how to maintain it. Policy is the essential foundation of an 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. You, the policy maker, set the tone and the emphasis on how important a role information security will have within your agency. Your primary responsibility is 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 Why Policy? A quality information security program begins and ends with policy. Properly developed and implemented policies enable the information security program to function almost seamlessly within the workplace. Although information security policies are the least expensive means of control to execute, they are often the most difficult to implement. Some basic rules must be followed when shaping a policy: Policy should never conflict with law Policy must be able to stand up in court, if challenged Policy must be properly supported and administered “All policies must contribute to the success of the organization. Management must ensure the adequate sharing of responsibility for proper use of information systems. End users of information systems should be involved in the steps of policy formulation.”

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 Policy Centric Decision Making Bulls-eye model layers: Policies—the outer layer in the bull’s-eye diagram Networks—where threats from public networks meet the organization’s networking infrastructure Systems—includes computers used as servers, desktop computers, and systems used for process control and manufacturing systems Applications—includes all applications systems “…policies are important reference documents for internal audits and for the resolution of legal disputes about management's due diligence [and] 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 Policy, Standards, and Practices Policy is “a plan or course of action, as of a government, political party, or business, intended to influence and determine decisions, actions, and other matters”. A standard is a 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 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

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 Policy, Standards, and Practices Policy is “a plan or course of action, as of a government, political party, or business, intended to influence and determine decisions, actions, and other matters”. A standard is a 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 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 Enterprise Information Security Policy (EISP) …sets the strategic direction, scope, and tone for all of an organization’s security efforts. … assigns responsibilities for the various areas of information security. … guides the development, implementation, and management requirements of the 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 EISP Elements … most EISP documents should provide : An overview of the corporate philosophy on security Information on the structure of the information security organization and individuals that fulfill the information security role Fully articulated responsibilities for security that are shared by all members of the organization Fully articulated responsibilities for security that are 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 Components of the EISP Statement of Purpose - Answers the question “What is this policy for?” Provides a framework for the helps the reader to understand the intent of the document. Information Technology Security Elements - Defines information security. Need for Information Technology Security - Provides information on the importance of information security in the organization and the obligation (legal and ethical) to protect critical information whether regarding customers, employees, or markets. Information Technology Security Responsibilities and Roles - Defines the organizational structure designed to support information security within the organization. Reference to Other Information Technology Standards And Guidelines - Outlines lists of other standards that influence and are influenced by this policy document.

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) A sound issue-specific security policy provides detailed, targeted guidance to instruct all members of the organization in the use of technology based systems. The ISSP should begin with an introduction of the fundamental technological philosophy of the organization. This serves to protect both the employee and the organization from inefficiency and ambiguity. An effective ISSP: Articulates the organization’s expectations about how the technology-based system in question should be used Documents how the technology-based system is controlled and identifies the processes and authorities that provide this control Serves to indemnify the organization against liability for an employee’s inappropriate or illegal system use 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: Electronic mail Use of the Internet and the 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

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: , 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 Issue-Specific Security Policy (ISSP) A sound issue-specific security policy provides detailed, targeted guidance to instruct all members of the organization in the use of technology based systems. The ISSP should begin with an introduction of the fundamental technological philosophy of the organization. This serves to protect both the employee and the organization from inefficiency and ambiguity. An effective ISSP: Articulates the organization’s expectations about how the technology-based system in question should be used Documents how the technology-based system is controlled and identifies the processes and authorities that provide this control Serves to indemnify the organization against liability for an employee’s inappropriate or illegal system use 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: Electronic mail Use of the Internet and the 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 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 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

Components of the ISSP Systems Management Violations of Policy
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 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 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 Implementing ISSP Common approaches for creating and managing ISSPs include: Create a number of independent ISSP documents, each tailored to a specific issue Create a single comprehensive ISSP document that aims to cover all issues Create a modular ISSP document that unifies policy creation and administration, while maintaining each specific issue’s requirements. The recommended approach is the 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 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 two general groups, management guidance and technical specifications, or they may be written like the example noted above to combine these two types of SysSP content into 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 Management Guidance SysSPs Created by management to guide the implementation and configuration of technology as well as address the behavior of people in the organization in ways that support the security of information. Any technology that affects the confidentiality, integrity or availability of information must be assessed to evaluate the tradeoff between improved security and restrictions. Before management can craft a policy informing users what they can do with the technology and how they may do it, it might be necessary for system administrators to configure and operate the system.

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 Technical Specifications SysSPs While a manager may work with a systems administrator to create managerial policy as specified above, the system administrator may need to create a different type of policy to implement the managerial policy. Each type of equipment has its own type of policies, which are used to translate the management intent for the technical control into an enforceable technical approach. There are two general methods of implementing such technical controls, access control lists, and 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 Access Control Lists Access control lists (ACLs) include the user access lists, matrices, and capability tables that govern the rights and privileges of users. ACLs can control access to file storage systems, object brokers or other network communications devices. A similar method that specifies which subjects and objects users or groups can access is called a capability table that clearly identifies which privileges are to granted to each user or group of users. These specifications are frequently complex matrices, rather than simple lists or tables. The level of detail and specificity (often called granularity) may vary from system to system, but in general 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 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. Administrators set user privileges, such as: Read Write Create Modify Delete Compare Copy In some systems, capability tables are called user profiles or user policies.

ACLs (Continued) Administrators set user privileges, such as: Read
Write Create Modify Delete Compare Copy 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. Administrators set user privileges, such as: Read Write Create Modify Delete Compare Copy In some systems, capability tables are called user profiles or user policies.

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 Configuration Rules Configuration rules are the specific configuration codes entered into security systems to guide the execution of the system when information is passing through it. Rule policies are more specific to the operation of a system than ACLs, and may or may not deal with users directly. Many security systems require specific configuration scripts telling the systems what actions to perform on each set of information they process.

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 Combination SysSPs It is not uncommon for an organization to create a single document that combines elements of both the Management Guidance and the Technical Specifications SysSPs. While this can be somewhat confusing to those who will use the policies, it is very practical to have the guidance from both perspectives in a single place. Care should be taken to articulate the required actions carefully as the 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 Guidelines for Policy Development It is often useful to view policy development as a two-part project. The first project designs and develops the policy (or redesigns and rewrites an outdated policy), and the second establishes management processes to perpetuate the policy within the 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 The Policy Project Like any IT project, a policy development or re-development project should be well planned, properly funded, and aggressively managed to ensure that it is completed 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 Investigation Phase During the Investigation phase the policy development team should complete the following activities: Obtain support from senior management Support and active involvement of IT management, specifically the CIO. The clear articulation of goals The participation of the correct individuals from the communities of interest affected by the recommended policies. The team must include representatives from Legal, Human Resources and end-users of the various IT systems covered by the policies. The team will need a project champion with sufficient stature and prestige to accomplish the goals of the project. The team will also need a capable project manager to see the project through to completion. A detailed outline of the scope of the policy development project, 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 Analysis Phase The Analysis phase should include the following activities: A new or recent risk assessment or IT audit documenting the current information security needs of the organization. The gathering of many key reference materials—including any existing policies—in addition to the items noted above.

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 Design Phase The Design phase should include the following activities: A design and plan for how the policies will be distributed and how verification of the distribution to members of the organization will be accomplished. Specifications for any automated tool used for the creation and management of policy documents. Revisions to feasibility analysis reports based on improved costs and benefits as the 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 Implementation Phase In the Implementation phase the policy development team will see to the writing the policies. Resources available include: The Web Government sites Professional literature. Several authors Peer networks. Professional consultants. Make certain the policies are enforceable. Policy distribution is not always as straightforward as you might think. Effective policy is written at a reasonable reading level, and 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 Maintenance Phase During the maintenance phase, the policy development team monitors, maintains, and modifies the policy as needed to ensure that it remains effective as a tool to meet changing threats. The policy should have a built-in mechanism via which users can report problems with the policy, preferably anonymously.

SP 800-18: Guide for Developing Security Plans
NIST Special Publication 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 : Guide for Developing Security Plans The NIST Special Publication offers another approach to policy management. Because policies are living documents that constantly change and grow. These documents must be properly disseminated (distributed, read, understood and agreed to), and managed. Good management practices for policy development and maintenance make for a more resilient organization. In order to remain current and viable, policies must have: an individual responsible for reviews, a schedule of reviews, a method for making recommendations for reviews, and an indication of policy and revision date.

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 SP : Guide for Developing Security Plans The NIST Special Publication offers another approach to policy management. Because policies are living documents that constantly change and grow. These documents must be properly disseminated (distributed, read, understood and agreed to), and managed. Good management practices for policy development and maintenance make for a more resilient organization. In order to remain current and viable, policies must have: an individual responsible for reviews, a schedule of reviews, a method for making recommendations for reviews, and an 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 A Final Note on Policy 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. This is an effort to improve employee productivity, and prevent potentially embarrassing situations. If the organization could not verify that the employee was in fact properly educated on the policy, as described earlier in the chapter, the employee could sue the organization for wrongful termination. Lawsuits cost money, and the organization could be so financially devastated that it had to go out of business. Other employees lose their livelihood, and no one wins.

End of this session

Writing a security policy for St-Lawrence Saw Mill
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)
Introduction Executive Management Commitment Compliance Statement Policy Principles Roles & Responsibilities 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 Investigation Phase During the Investigation phase the policy development team should complete the following activities: Obtain support from senior management Support and active involvement of IT management, specifically the CIO. The clear articulation of goals The participation of the correct individuals from the communities of interest affected by the recommended policies. The team must include representatives from Legal, Human Resources and end-users of the various IT systems covered by the policies. The team will need a project champion with sufficient stature and prestige to accomplish the goals of the project. The team will also need a capable project manager to see the project through to completion. A detailed outline of the scope of the policy development project, 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 Analysis Phase The Analysis phase should include the following activities: A new or recent risk assessment or IT audit documenting the current information security needs of the organization. The gathering of many key reference materials—including any existing policies—in addition to the items noted above.

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 Design Phase The Design phase should include the following activities: A design and plan for how the policies will be distributed and how verification of the distribution to members of the organization will be accomplished. Specifications for any automated tool used for the creation and management of policy documents. Revisions to feasibility analysis reports based on improved costs and benefits as the 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 Implementation Phase In the Implementation phase the policy development team will see to the writing the policies. Resources available include: The Web Government sites Professional literature. Several authors Peer networks. Professional consultants. Make certain the policies are enforceable. Policy distribution is not always as straightforward as you might think. Effective policy is written at a reasonable reading level, and 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 Maintenance Phase During the maintenance phase, the policy development team monitors, maintains, and modifies the policy as needed to ensure that it remains effective as a tool to meet changing threats. The policy should have a built-in mechanism via which users can report problems with the policy, preferably anonymously.

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.

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.

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.

Focuses on the delivered service: Business applications: CRM, order processing, dispatch, billing etc. Internal applications: pay roll, HR etc. Communications: , 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 Summary
Productivity Loss Number of Fully Burdened Employee impacted Lost Revenue Direct Loss Compensatory Payments Lost Future Revenues Investment Loss Interruptions COSTS Total Outage Costs Delayed Collections Billing Losses Missed Discounts Extra Expense Cost to Recover Overtime Expense Increased Fraud Risk Increased Error Rate Travel Expenses Temporary Employees Damaged Reputation Customer, Suppliers, Partners, Banks, Financial Markets Credit Ratings 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
Vulnerability Impact ($) Impact (Other) Value Total:

Lab: using a TRA methodology

End of this session

Incident management Session 6
Presentation by Mr Marc-André Fortier, Consultant Student presentations Investigation practices Legal and ethical aspects The chain of evidence.

Part 1: Expert presentation
Mr 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

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.

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)‏

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.

Executable for MD5 algorithm can be downloaded from 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.

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.

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.

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 and handling of evidence

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: Federal Rules of Evidence:

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)‏ Suppose a crime was committed by a perpetrator using a computer. For a log of the logins on the system to provide complete evidence, you not only show that the perpetrator did login and commit it, but also provide exculpatory evidence that no one else that was logged in at the time of the crime committed it.

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

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

Some tools: Linux dd ( SnapBack DatArrest (

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 NIST Internet Time Service

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

Tools and best practices CA Net Forensics
Session 7 Tools and best practices CA Net Forensics

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 ThumbsPlus Erase/Unerase tools: Diskscrub/Norton utilities)‏ CD-R, DVR utilities Text search utilities (dtsearch 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 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 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 )‏

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 ( Hex Workshop ( and Norton Disk Edit (

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, 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)‏

Protocol Layering – Routing
11/19/07 Host A Host B Application Layer Application Layer Message Transport Layer Transport Layer Packet Router Network Layer Network Layer Network Layer Datagram Datagram (Source: Link Layer Link Layer Link Layer Frame Frame Physical Network Physical Network 286

Protocols 11/19/07 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 Hi TCP Connection Response Hi Get (Source: Got the Time? 8:50 Index.html 287

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 ( 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

Business continuity planning
Sessions 8 and 9 Business continuity planning

What the experts are saying
"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.” Gartner (Roberta Witty, Donna Scott)‏ Disaster Recovery Plans and Systems Are Essential 12 September 2001

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.

Type of Disaster Scenario
Frequency of Downtime Frequency Data Corruption User Error H/W Failure Power Outage Natural Disaster Political Events DR and BC – DR supports BC, but gives more protection sooner and provides greater bang for buck in short run. Companies should start with technology first. Chart above shows type of disaster vs. freq. A proper DR plan will address high frequency issues, while allowing protection for the less frequent, but equally catastrophic situations. Type of Disaster Scenario

BC Components Crisis Management
Strategic Planning Assumption: By 2004, more than 60 percent of large enterprises will have invested in BCP for e-business processes, compared to fewer than 25 percent (of non-e-business processes) today (0.8 probability). Disaster Recovery Business Recovery Business Resumption Contingency Planning Mission-critical applications Mission-critical business processing (workspace) Business process workarounds External event Objective Site or component outage (external) Site outage (external) Application outage (internal) External behavior forcing change to internal Focus 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 Conclusion: An increase in e-commerce-related risk broadens the scope of business continuity planning. The shift from disaster recovery to business continuity is because most (if not all) stages of the business life cycle totally depend on IT services. Along with dispersed ownership and management (internally and externally) of IT services, providing for BCP is a top-level concern for enterprises and is vital to maintaining financial confidence and the reputation of the business. E-commerce does not change the five components of BCP. It places more importance on the enterprise’s contingency and crisis management plans, due to the public nature of outages and the increasing reliance on outside service providers (OSPs) for processing. The potential range of e-commerce failures must be determined from an organizational perspective and all interdependencies must be appropriately planned for. Each component of the business process must have a recovery plan. If the link to the credit checking service (an OSP) is not available from your Web site, then alternate plans must be in place to immediately handle the purchase in progress. Action Item: An end-to-end analysis of the information flow through internal and external processing environments is required to successfully provide for recovery options for all potential scenarios. Crisis Management

Creating Business Continuity Plans
Strategic Planning Assumption: By 2004, the majority of spending on e-commerce recovery will become part of the production budget rather than a discrete business-continuity expenditure (0.8 probability). PROCESS Ongoing Process Change Management Education Testing Review Testing Group Plans and Procedures Risk Reduction Implement Standby Facilities Project Create Planning Organization Recovery Strategy Risk Analysis Conclusion: An increase in e-commerce-related risk broadens the scope of business continuity planning. The foundation of BCP success is senior management sponsorship and participation. The business impact analysis (BIA) is the most critical step, as it identifies what and how much the enterprise has at risk, as well as which business processes are most critical, thereby prioritizing risk management and recovery investments. Direct financial impact will arise via lost sales, increased costs of working, material losses or other loss exposure. Indirect financial impacts, e.g. reduction in future earnings, may arise in the longer term via loss of customer confidence or competitive advantage or damage to the brand value. Skipping the BIA because it involves senior management participation often results at the end of the planning phase in only the costs of risk mitigation being presented, with no convincing indication of what is being protected. Risk analysis identifies the vulnerability of the enterprise to different categories of risk and its probability. The recovery strategy outlines in broad terms the approaches to risk mitigation, incident management and recovery from the incident. Detailed plans and procedures are then created by those responsible for the daily operation of the processes. The recovery process must be tested. Last, and NOT least, a process is established to keep the plan up to date. Business continuity plans should become part of the life cycle of every new project. Action Item: Use a formal BIA and risk analysis as the basis for building business continuity plans. In addition, integrate BCP into the enterprise project life-cycle to ensure that recovery needs are identified in the initial phases of new projects, including “project creep” and major upgrades. Business Impact Analysis Policy Organization Resources Scope Business Continuity Planning Initiation

Disaster Recovery Planning Cycle

The Business Challenge
Increasing cost of information unavailability More business online More applications & data The Widening Gap Ability to deliver through traditional recovery planning More complex systems Less window to recover Requires continuous information availability – BY DESIGN KPMG

The Challenge of Recovery
Recovery Point Objective (RPO)‏ “How fresh does your data need to be ?” Recovery Time Objective (RTO)‏ “What is your downtime tolerance ?” Secs Mins Hrs Days Wks Recovery Time Recovery Point File and Print Web Server eBusiness

Disaster Recovery Technologies
Secs Mins Hrs Days Wks Recovery Point Recovery Time Tape Backup Async. Replication Sync. Replication Clustering Remote Replication Online Restore Tape Restore When you have a site outage, there’s two key factors to consider: Recovery Point (data loss) and Recovery Time (downtime). Organizations should have a Recovery Point Objective (per application) that must be satisfied as well as a Recovery Time Objective that must be met. These are respectively called RPO and RTO by industry analysts. Most people tend to focus on the RTO or how much downtime is acceptable. However, just as important is to look at how much data loss an organization can tolerate. Make it a point to look at both. Data is important and data loss (even it just a few minutes, hours or days) can have far reaching negative business impacts. Many customers in the banking and financial arenas are actually bound legally to ensure that ZERO data is lost. They therefore opt for synchronous replication for many applications. Most companies even today rely primarily on tape backup and restore as the center of their DR plan. This usually means at least a day of lost data and a few days of downtime after a disaster. This is fine if it meets the business needs, but most organizations will at least have some applications that will require a more aggressive RPO and RTO. Again, the cloud represents business impact or business damage (direct and indirect costs). So let’s look at how different applications may have different needs within the organization (next slide). Closer you get to the disaster on each side, the more money you’re going to spend.

Recovery Process in a Virtualized Environment
Example recovery process comparison 40+ hrs P-P Configure hardware Install OS Configure OS Install backup agent Start “Single-step automatic recovery” Restore VM Power on VM This slides illustrates more specifically how virtualization simplifies DR and provides for faster recovery. Comparing the steps necessary to recover from a disaster in the physical to physical and physical to virtual scenarios illustrates the dramatic difference that virtual infrastructure makes in simplifying and shortening the recovery process. With a physical recovery target, time to recovery is much longer—40+ hours in one customer example. In the same customer example, time to recovery using a virtual target has been reduced to 3+ hours and several fewer steps. Since the hardware is now virtualized, we no longer need to spend time finding and setting up hardware that is identical to the primary—any hardware is a potential recovery target. Using the P2V (physical to virtual) tool we create a virtual machine equivalent to the physical primary machine. After booting this virtual machine on the target ESX server, we initiate the recovery step just as we would with physical systems. V-V < 4+ hrs RTO of minutes to a few hours, not days to weeks!

Storage Management Costs
“An Enterprise Spends $3 Managing Storage For Every $1 Spent On Storage Hardware” Labor Software Hardware Gartner, Nov 2001

Applying High Availability to Disaster Recovery
Tactical Guideline: Recovery strategies must match e-business requirements and risk scenarios. Assumes mirroring or shadowing plus a complete application environment Hot Standby or Load-Balanced Database and/or file and/or object replication Mirroring Log/journal transfer (continuous or periodic) Shadowing net $$$+ host $$$+ disk $$$$+ appl. $+ Cost Database and/or file and/or object backup Electronic Journaling Elec. Vaulting Standard Recovery net $$$+ host $$+ disk $$$$+ net $-$$+ host $$+ disk $$$$+ net $ host $ disk $ tape $ net $ tape $ Traditional BC plans provide 24- to 72-hour application and business process recoverability. With technology more intrinsic to business processes and costs of outages escalating, many enterprises are seeking shorter recovery times for critical applications. Use of high-availability techniques is escalating — especially for enterprise resource planning (ERP) and e-business applications, enabling enterprises to achieve recovery time objectives (RTOs) and recovery point objectives (RPOs) in a matter of minutes rather than days. With e-business, hot standby (an idle standby application environment that waits to be turned on in the event of a disaster affecting the primary physical site) often is not good enough, and many design applications architectures cross two or more active physical sites. This way, even if one physical data center experiences an outage, the others continue processing the requests. Load balancing across two or more physical sites is especially common for nontransactional applications. Often, transactional applications are located in a single physical site, with hot standby at another site. This configuration reduces the complexity and chances for conflict resolution. For hot standby and load-balanced sites, data is replicated between physical sites, typically via mirroring or shadowing (at the transaction level or the data level). Shadowing builds a replica of databases or file systems by continuously capturing changes and applying them at the recovery site. Mirroring builds a replica of databases or file systems by applying changes at the alternate location in lock step with the primary site. Action Item: Evaluate Web site and all integrated content/application availability and recovery strategies to ensure that they meet business requirements. 72 hours 48 hours 24 hours 12 hrs. Minutes Disaster Recovery Times

Information security aspects of business continuity management
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 business processes 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 of the 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 Including information security in the business continuity management process

ISO Control 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 ); 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 information processing 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 ); i) regular testing and updating of the plans and processes put in place (see ); 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).

Business continuity and risk assessment
ISO/IEC 27002(2005) Control Business continuity and risk assessment

ISO Control 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.

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.

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.

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 Developing and implementing continuity plans including information security

ISO Control 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.

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 operations and 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.

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 It should be noted that crisis management plans and activities (see ISO/IEC 27002(2005) f) may be different from business continuity management; i.e. a crisis may occur that can be accommodated by normal management procedures.

Business continuity planning framework
ISO/IEC 27002(2005) Control Business continuity planning framework

ISO Control 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.

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. ISO/IEC 27002(2005)

Considerations 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 business activities 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.

Testing, maintaining and re-assessing business continuity plans
ISO/IEC 27002(2005) Control Testing, maintaining and re-assessing business continuity plans ISO/IEC 27002(2005)

ISO Control Business continuity plans should be tested and updated regularly to ensure that they are up to date and effective. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

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 Accessibility
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

Strategies

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. Incremental - Instead of copying all files that have changed since the last full backup, an incremental backup copies only files changed since the last full or incremental backup was conducted. Incremental Backup Restoration To restore a system using this type of backup method requires more work. Go back to the last full backup and reload the system with this data. Then update the system with every incremental backup. The advantage of this type of backup is that it requires less storage and time to accomplish. The restoration process is more involved. Incremental backup relies on occasional full backups. After that, only those files that have changed since the last backup need to be backed up. Delta - The advantage of this is that only the information within files that has changed will be backed up. The disadvantage — restoration is a complex process since it requires more than just loading a file. It requires that application software be run to update the records in the files that have been changed.

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. This can be thought of as backup insurance—the cost of an insurance policy that may never be used but that an organization is willing to pay, just in case.

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

Disaster recovery planning
Session 12 Disaster recovery planning

Disaster recovery planning
ISO/IEC FDIS 24762:2007(E)

ISO 24762 approach to BCP Conduct of Business Impact Analysis Review,
Assessment of Risks, then based on these results - Establishment of Business Recovery Priorities, Timescales & Requirements Business continuity plan testing Business continuity strategy formulation Business continuity strategy formulation ISO 24762 Business continuity awareness Business continuity plan production On-going Business continuity plan maintenance

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 and telecommunications, 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 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. 5.3.3

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
Image source:

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. For risk communication to be effective, factual information must be heard, understood, remembered, and serve as a basis for appropriate action and behavior. It’s a visual aid that provides a glance at your key messages and related information.

Message Mapping Identify and prioritize stakeholders
Identify and prioritize stakeholders’ questions and concerns The first step is to identify and prioritize stakeholders. Stakeholders are individuals or groups that are affected by an issue, interested in an issue, or influential in determining the outcome of an issue. In a crisis situation, stakeholders can include victims, families of victims, emergency, law, and health personnel, and government agencies. The second step in message mapping is to identify and prioritize stakeholder questions and concerns. This is usually done through media content analysis, reviews of historical documents such as public or legislative transcripts, facilitated discussions, focus groups, and surveys. Research shows that 90 to 95% of questions that will be raised in any type of crisis can be anticipated in advance!

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? Repeat facts of the event, describe data collection effort, describe treatment from fact sheets Don’t speculate Don’t answer what if questions Set limits on updates and stick to the agreement with media—twice a day or every two hours—what the situation demands

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 The third step in message map construction is to analyze the questions and concerns from step 2 to identify a common set of underlying concerns. Case studies have shown that most public health issues are associated with 10 to 20 primary underlying concerns. These include things like health issues, safety issues, ecosystem issues, economic issues, quality of life issues, cultural issues, legal issues, etc. 4. The fourth step in message map construction is to develop key messages that address stakeholder concerns. Key messages are typically developed through brainstorming sessions with a message mapping team that consists of a subject matter expert, a communication specialist, a policy expert, and a facilitator. The goal of the brainstorming session is to produce a message narrative – usually in the form of complete sentences – which are entered as key messages into the message map. As we talked about earlier, key messages should be based on what the target audience 1. Most needs to know 2. Most wants to know Key message development is based in part on principles derived from one of the main theories of risk communication that we talked about earlier – mental noise theory. Remember, this theory states that when people are upset, they can have a hard time hearing, understanding, and remembering information. So, the challenges for risk communicators are: First, to overcome the barriers that mental noise creates Second, to produce accurate messages for diverse audiences, and Third, to achieve maximum effectiveness within the constraints posed by mental noise.

Message Mapping Develop key messages. Develop supporting materials.
Limited in number (3) Brief Understandable Develop supporting materials. Conduct message testing if you can! Deliver messages So, knowing that that’s what we have to do. . .how do we get there? Solutions to mental noise that guide key message development include - Developing a limited number of key messages; ideally, 3 key messages or 1 key message with 3 parts/ - Keeping individual key messages brief; ideally less than 3 seconds or less than 9 words for each. Clarity, brevity. - Develop messages that are clearly understandable by the target audience. We’ll talk a bit more about this later.

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

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 2. Public Health Workbook to Define, Locate and Reach Special, Vulnerable and At-Risk Populations in an Emergency ( 3. Samsha . Substance Abuse and Mental Health Adminstration Communication in crisis: risk communication guidelines for public officials. 4. Terrorism and Other Public Health Emergencies: A Field Guide for the Media

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 Reporting information security events Reporting security weaknesses 13.2 MANAGEMENT OF INFORMATION SECURITY INCIDENTS AND IMPROVEMENTS Responsibilities and procedures Learning from information security incidents Collection of evidence

Reporting information security events and weaknesses
ISO/IEC 27002(2005) Section 13.1 Reporting information security events and weaknesses ISO/IEC 27002(2005)

Objective To ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

Reporting information security events
ISO/IEC 27002(2005) Control ISO/IEC 27002(2005)

ISO Control Information security events should be reported through appropriate management channels as quickly as possible. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

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 ). 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 ISO/IEC 27002(2005)

Reporting security weaknesses

ISO 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. ISO/IEC 27002(2005)

All employees, contractors and third party users should report these matters either to their management or directly to their service provider as quickly as possible in order to prevent information security 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 suspected weakness. ISO/IEC 27002(2005)

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)

Management of information security incidents and improvements
ISO/IEC 27002(2005) Section 13.2 Management of information security incidents and improvements ISO/IEC 27002(2005)

Objective To ensure a consistent and effective approach is applied to the management of information security incidents. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

Where evidence is required, it should be collected to ensure compliance with legal requirements.
ISO/IEC 27002(2005)

Responsibilities and procedures

Iso Control Management responsibilities and procedures should be established to ensure a quick, effective, and orderly response to information security incidents. ISO/IEC 27002(2005)

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 ) should be used to detect information security incidents. ISO/IEC 27002(2005)

Guidelines The following guidelines for information security incident management procedures should be considered: ISO/IEC 27002(2005)

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 ); 3) denial of service; 4) errors resulting from incomplete or inaccurate business data; 5) breaches of confidentiality and integrity; 6) misuse of information systems; ISO/IEC 27002(2005)

Contingency plans b) in addition to normal contingency plans (see ), the procedures should also cover (see also ): 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; ISO/IEC 27002(2005)

Audit trails c) audit trails and similar evidence should be collected (see ) 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; ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

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 understand the organization’s priorities for handling information security incidents. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

Learning from information security incidents

ISO Control There should be mechanisms in place to enable the types, volumes, and costs of information security incidents to be quantified and monitored. ISO/IEC 27002(2005)

The information gained from the evaluation of information security incidents should be used to identify recurring or high impact incidents. ISO/IEC 27002(2005)

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 ISO/IEC 27002(2005)

Collection of evidence

ISO 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). ISO/IEC 27002(2005)

Internal procedures should be developed and followed when collecting and presenting evidence for the purposes of disciplinary action handled within an organization. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

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 be kept 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. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

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. ISO/IEC 27002(2005)

End of this session

Sessions 15 and 16 Simulation

Recall from sessions 8 and 9