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