You are on page 1of 137

Certified Information Systems Auditor [CISA] Examination Preparation

(Domain 4 : Information Systems Operations and Business Resilience )


Presented by

Hasan- Al- Monsur (Rajib)


• Cyber Security Specialist ,CISA , CEH , ISO27001 LA, CPISI & Director-Membership, ISACA Dhaka Chapter
 ISACA Membership No: 886319
 IEB Membership No: M/32774 (Life Time)
 Member of The Institute of Internal Auditors (IIA) Bangladesh ; IIA Membership No: 2124863
 Bangladesh Computer Society (BCS) Membership No : M/1919 (Life Time)
 Masters In Information Security (Cyber Security ,1st Batch In BD) MISS (BUP) ,MBA (Finance& Marketing) ,B.Sc.
Engineering in ETE
Certified Payment-Card Industry Security Implementer (CPISI) ; Certificate No : 014865
 RHCSA,RHCE ITIL(F),PRINCE2(F) ,VSP,VTSP,MCT,MCP,MCTS,MS,MCSA (2008 ,2012 &SQL Server 2012),MCITP(Enterprise
Administrator),MCSE 2012 (Server Infrastructure ,Private Cloud)
Symantec Technical Specialist(STS) In Netbackup, SSP, SSE,SSE+ .
• Trainer on CISA exam preparation courses at AT COMPUTERS ( Athorized ISACA Exam center)
• Trainer on Certified Information Systems Auditor (CISA ) courses at ISACA Dhaka Chapter ,
• Guest trainer on cyber security course at Bangladesh Computer Society
• Guest trainer on Cyber Security, Ethical hacking courses at New Horizons CLC of Bangladesh
• Guest trainer on Cyber Security, CISA , Banking Security courses at TMSS ICT And many training Organizations.
Domain 4

• Information Systems Operations and


• Business Resilience
Domain 4

Provide assurance that the processes for information


systems operations, and Business Resilience meet
the organization’s strategies and objectives.
Domain 4

• The focus of Domain 4 is on providing assurance that


IT service level expectations are derived from the
business objectives of the enterprise.
Overview Of Domain 4

• Information systems operations and business resilience are


important to provide assurance to users and management that the
expected level of service will be delivered. Service level
expectations are derived from the organization’s business
objectives. Information technology (IT) service delivery includes
information systems (IS) operations, IT services and management
of IS and the groups responsible for supporting them.
Disruptions are also an often-unavoidable factor of doing business.
Preparation is key to being able to continue business operations
while protecting people, assets and reputation. Employing business
resiliency tactics helps organizations address these issues and limit
the impact.
Domain 4—
Information Systems Operations and Business Resilience
.

DOMAIN 4 EXAM CONTENT OUTLINE


Part A: Information Systems Operations
1. Common Technology Components
2. IT Asset Management
3. Job Scheduling and Production Process Automation
4. System Interfaces
5. End-User Computing
6. Data Governance
7. Systems Performance Management
8. Problem and Incident Management
9. Change, Configuration, Release, and Patch Management
10. IT Service Level Management
11. Database Management
Part B. Information System Implementation
1. Business Impact Analysis (BIA)
2. System Resiliency
3. Data Backup, Storage, and Restoration
4. Business Continuity Plan (BCP)
5. Disaster Recovery Plans (DRPs)
On the CISA Exam

• Domain 4 represents 23 percent of the CISA


examination (approximately 34 questions).

• Domain 4 incorporates 11 tasks related to the to


information systems operations, maintenance and
Business Resilience.
LEARNING OBJECTIVES/TASK
STATEMENTS for domain 4
Within this domain 4, the IS auditor should be able to:

• Evaluate the organization’s ability to continue business operations.


(T13)
• Evaluate whether IT service management practices align with
business requirements. (T20)
• Conduct periodic review of information systems and enterprise
architecture. (T21)
• Evaluate IT operations to determine whether they are controlled
effectively and continue to support the organization’s objectives.
(T22)
• Evaluate IT maintenance practices to determine whether they are
controlled effectively and continue to support the organization’s
objectives. (T23)
LEARNING OBJECTIVES/TASK
STATEMENTS for domain 4
Within domain 4 , the IS auditor should be able to (Cont. ):

• Evaluâtes database management practices. (T24)


• Evaluate data governance policies and practices. (T25)
• Evaluate problem and incident management policies and
practices. (T26)
• Evaluate change, configuration, release, and patch
management policies and practices. (T27)
• Evaluate end-user computing to determine whether the
processes are effectively controlled. (T28)
• Evaluate policies and practices related to asset life cycle
management. (T33)
SELF-ASSESSMENT QUESTIONS
for Domain 4

• CISA self-assessment questions support the content in this


presentations and provide an understanding of the type
and structure of questions that typically appear on the
exam. Often, a question will require the candidate to
choose the MOST likely or BEST answer among the options
provided. Please note that these questions are not actual
or retired exam items.
Q: 4-1
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-1 ( C )
Q: 4-2

• 4-2 For mission critical systems with a low tolerance to


interruption and a high cost of recovery, the IS auditor, in
principle, recommends the use of which of the following
recovery options?
• A. Mobile site
• B. Warm site
• C. Cold site
• D. Hot site
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-2 ( D )
Q: 4-3
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-3 ( A)
4-3 A. When testing change management, the IS auditor should always
start with system-generated information, containing the date and time a
module was last updated, and trace from there to the documentation
authorizing the change.
B. Focusing exclusively on the accuracy of the documentation examined
does not ensure that all changes were, in fact, documented.
C. To trace in the opposite direction would run the risk of not detecting
undocumented changes.
D. Focusing exclusively on the completeness of the documentation
examined does not ensure that all changes were, in fact, documented.
Q: 4-4
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-4 (A )
Q: 4-5
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-5 (A )
Q: 4-6
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-6 ( A)
• 4-6 A. System utilities may enable unauthorized changes
to be made to data on the client-server database. In an
audit of database security, the controls over such utilities
would be the primary concern of the IS auditor.
• B. Application program generators are an intrinsic part of
client server technology, and the IS auditor would evaluate
the controls over the generators access rights to the
database rather than their availability.
• C. Security documentation should be restricted to
authorized security staff, but this is not a primary concern.
• D. Access to stored procedures is not a primary concern.
Q: 4-7
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-7 ( C)
Q: 4-8
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-8 (A )
4-8 A. The IS auditor should always be present when disaster recovery
plans are tested to ensure that the tested recovery procedures meet the
required targets for restoration, that recovery procedures are effective
and efficient, and to report on the results, as appropriate.
B. IS auditors may be involved in overseeing plan development, but they
are unlikely to be involved in the actual development process.
C. Similarly, an audit of plan maintenance procedures may be conducted,
but the IS auditor normally would not have any responsibility for the
actual maintenance.
D. An IS auditor may be asked to comment upon various elements of a
supplier contract, but, again, this is not always the case.
Q: 4-9
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-9 (A )
Q: 4-10

4-10 Which of the following components of a business


continuity plan is PRIMARILY the responsibility of an
organization’s IS department?

A. Developing the business continuity plan


B. Selecting and approving the recovery strategies used in the
business continuity plan
C. Declaring a disaster
D. Restoring the IT systems and data after a disaster
ANSWERS TO SELF-ASSESSMENT
QUESTIONS : 4-10 (D )
PART A: INFORMATION SYSTEMS OPERATIONS

• 4.0 INTRODUCTION
• IT service management practices are important to
provide assurance to users and to management that the
expected level of service will be delivered.

• Service level expectations are derived from the


organization’s business objectives. IT service delivery
includes IS operations, IT services, and management of
IS and the groups responsible for supporting them.
• IT services are built on service management
frameworks.
Key Terms

Key Term Definition


IT service The day-to-day provision to customers of IT infrastructure
and applications, and support for their use—e.g., service
desk, equipment supply and moves, and security
authorizations (COBIT 5 perspective)

Service level An agreement, preferably documented, between a service


agreement (SLA) provider and customer/user defining minimum
performance targets for a service and how they will be
measured
4.1 COMMON TECHNOLOGY COMPONENTS

 This section introduces:


• Technology components
• Hardware platforms
• Basic concepts of, and history behind, the different types of
computers
• Advances in IT
 Also discussed are the key audit considerations, such as
capacity management, system monitoring, maintenance of
hardware and typical steps in the acquisition of new hardware.
4.1.1 COMPUTER HARDWARE
COMPONENTS AND ARCHITECTURES
 Processing Components
• The central component of a computer is the central processing unit (CPU).
Computers may:
• Have the CPU on a single chip (microprocessors)
• Have more than one CPU (multi-processor)
• Contain multiple CPUs on a single chip (multi-core processors)
 Other key components of a computer include:
• Motherboard
• Random access memory (RAM)
• Read-only memory (ROM)
• Permanent storage devices (hard disk drive or solid-state drive [SSD])
• A power supply unity
 Input/Output Components
Types of Computers

• Computers can be categorized according to several criteria—


mainly their processing power, size and architecture. These
categories are shown in figure 4.1.
Types of Computers
• Computers can be categorized according to several criteria—mainly their
processing power, size and architecture. These categories are shown in figure
4.1.
4.1.2 COMMON ENTERPRISE BACK-END
DEVICES
• Following are some of the most common devices encountered:
4.1.3 UNIVERSAL SERIAL BUS

 The universal serial bus (USB) is a


serial bus standard that interfaces
devices with a host.
Risk Related to USBs : Security Controls Related to
• Risk related to the use of USBs:
USBs includes the following: • The following controls can be used to
help reduce risk associated with the use
of USB devices:
• Viruses and other malicious software
• Encryption
• Data theft
• Granular control
• Data and media loss
• Security personnel education
• Corruption of data
• The lock desktop policy enforcement
• Loss of confidentiality • Antivirus policy
• Use of secure devices only
• Inclusion of return information
4.1.4 RADIO FREQUENCY
IDENTIFICATION
• Radio frequency identification (RFID) uses radio waves to identify tagged objects
within a limited radius. A tag consists of a microchip and an antenna.The
microchip stores information along with an ID to identify a product, while the
antenna transmits the information to an RFID reader.
 Applications of RFID
Application of RFID include the following:
• Asset management
• Tracking
• Authenticity verification
•Matching
•Process control
• Access control
• Supply chain management (SCM)
4.1.4 RADIO FREQUENCY
IDENTIFICATION (Cont.)
4.1.5 HARDWARE MAINTENANCE PROGRAM

Information typically maintained by this program includes:


• Reputable service company information for each hardware resource
requiring routine maintenance
• Maintenance schedule information
• Maintenance cost information
• Maintenance performance history information, such as planned
versus unplanned, executed and exceptional.
• IS management should monitor, identify and document any
deviations from vendor maintenance specifications and provide
supporting arguments for this deviation.
4.1.5 HARDWARE MAINTENANCE PROGRAM

When performing an audit of this area, the IS auditor should:

• Ensure that a formal maintenance plan has been developed and


approved by management and is being followed.

• Identify maintenance costs that exceed budget or are excessive.


These overages may be an indication of a lack of adherence to
maintenance procedures or of upcoming changes to hardware. Proper
inquiry and follow-up procedures should be performed.
4.1.5 HARDWARE MAINTENANCE PROGRAM

Hardware Monitoring Procedures :


4.1.6 HARDWARE REVIEWS
When auditing infrastructure and operations, hardware reviews
should include the areas shown in figure 4.2.
4.2 IT ASSET MANAGEMENT

• An asset is something of either tangible or intangible


value that is worth protecting and includes people,
information, infrastructure, finances and reputation.
However, an asset cannot be effectively protected or
managed if it is not identified. Likewise, it makes it more
difficult to protect an asset if its location is unknown or
no owner is assigned.
4.2 IT ASSET MANAGEMENT
4.2 IT ASSET MANAGEMENT (Cont.)
4.3 JOB SCHEDULING AND PRODUCTION PROCESS
AUTOMATION

• 4.3.1 JOB SCHEDULING SOFTWARE


The advantages of using job scheduling software include:
• Job information is set up only once, reducing the probability of an
error.
• Job dependencies are defined so that if a job fails, subsequent jobs
relying on its output will not be processed.
• Records are maintained of all job successes and failures.
• Security over access to production data can be provided.
• Reliance on operators is reduced.
4.3 JOB SCHEDULING AND PRODUCTION PROCESS AUTOMATION

4.3.2 SCHEDULING REVIEWS : Figure 4.3 describes an audit approach to be


considered when reviewing workload job scheduling and personnel scheduling.
4.3 JOB SCHEDULING AND PRODUCTION PROCESS AUTOMATION

4.3.2 SCHEDULING REVIEWS : Figure 4.3 describes an audit approach to be


considered when reviewing workload job scheduling and personnel scheduling.
4.4 SYSTEM INTERFACES

• 4.4.2 SECURITY ISSUES IN SYSTEM INTERFACES


• The primary objective of maintaining security of data being
transferred through system interfaces is to ensure that the data
intended to be extracted from the originating system are the same as
the data that were downloaded and recorded in the recipient system.
The data need to be protected and secured throughout the transfer
process. The secondary objective is to prevent unauthorized access
to the data via interception, malicious activity, error or other means.
Unavailability of system interfaces can also affect the reliability of
data.
4.4 SYSTEM INTERFACES
4.4.3 CONTROLS ASSOCIATED WITH SYSTEM INTERFACES :

 The IS auditor should ensure that the organization has a program that tracks and manages
all system interfaces and data transfers, whether internal or external, in line with the
business needs and goals.
IS auditors should ensure that the program is able to:
• Manage multiple file transfer mechanisms.
• Use multiple protocols.
• Automatically encrypt, decrypt and electronically sign data files.
• Compress/decompress data files.
• Connect to common database servers.
• Send and retrieve files via email and secure email.
• Automatically schedule regular data transfers.
• Analyze, track and report any attributes of the data being transferred.
• Ensure compliance with appropriate regulatory laws and mandates.
• Offer a checkpoint or restart capability for interruptions.
• Integrate with back-office applications to automate data transfers as much as feasible.
4.5 END-USER COMPUTING

• End-user computing (EUC) refers to the ability of end users to


design and implement their own information system using
computer software products.
• EUC allows users to quickly build and deploy applications but
brings the risk that applications may not be independently
reviewed and created using a formal development
methodology.
4.5 End-User Computing (cont’d)

• Applications created through EUC may have the following


issues:
• They may contain errors and give incorrect results.
• They are not subject to change management or release
management, creating version control challenges.
• They are not secured or backed up.

• The IS auditor should ensure that the policies for use of EUC
exist.
• An inventory of all such applications should be in place.
• Those deemed critical enough should be subject to the same
controls of any other application.
4.5 END-USER COMPUTING(cont’d)
• Lack of IT department involvement in EUC also brings associated risk, because the applications may not be
subject to an independent review and, frequently, are not created in the context of a formal development
methodology.
4.6 DATA GOVERNANCE

 Data governance ensures that:


• Stakeholder needs, conditions and options are evaluated to determine balanced, mutually
agreed enterprise objectives to be achieved through the acquisition and management of
data/information resources.
• Direction is set for data/information management capabilities through prioritization and
decision making.
• Performance and compliance of data/information resources are monitored and evaluated
relative to mutually agreed-upon (by all stakeholders) direction and objectives.
• Data governance reflects the practice of evaluating requirements and bringing direction
and control over data and information so that users have access to that data and can trust
and rely on it.
• Data governance also involves monitoring the performance of IT operations, specifically
those areas that relate to data and its availability, integrity and confidentiality.
4.6.1 DATA MANAGEMENT
Data Life Cycle

Build/ Use/
Plan Design Monitor Dispose
Acquire Operate

Adapted from: ISACA, COBIT 5: Enabling Information, USA, 2013, figure 23


4.6.1 DATA MANAGEMENT
Data Quality Criteria
• Data quality is key to data management, and the IS auditor should
ensure that data is of sufficient quality to allow the organization to
meet its strategic objectives.
• Questions such as the following can aid in this determination:
• Are the data being captured and processed to required
standards?
• Are the configurations of the organization’s applications and
database management systems aligned with organizational
objectives?
• Are data being archived, retained or destroyed in line with a
data retention policy?
4.7 SYSTEMS PERFORMANCE
MANAGEMENT
• Systems performance refers to the study of an entire system,
including physical hardware and components and software, and how
it operates.
• Enterprises want to ensure that systems are performing as expected
and issues are identified and addressed in a timely fashion. It is
important to understand the features of the IS architecture and
associated software to aid in the systems performance management
process.
4.7 SYSTEMS PERFORMANCE
MANAGEMENT
4.7.2 OPERATING SYSTEMS
Software Control Features or Parameters
• Various OS software products provide parameters and options for the
tailoring of the system and activation of features such as activity
logging. Parameters are important in determining how a system runs
because they allow a standard piece of software to be customized to
diverse environments.
Software control parameters deal with:
• Data management
• Resource management
• Job management
• Priority setting
4.7 SYSTEMS PERFORMANCE
MANAGEMENT
4.7.2 OPERATING SYSTEMS
Software Integrity Issues
OS integrity is a very important requirement and ability of the OS and involves using
specific hardware and software features to:
• Protect itself from deliberate and inadvertent modification
• Ensure that privileged programs cannot be interfered with by user programs
• Provide for effective process isolation to ensure that:
– Multiple processes running concurrently will not interfere by accident or by design
with each other and are protected from writing into each other’s memory (e.g.,
changing instructions, sharing resources, etc.)
– Enforcement of least privilege where processes have no more privilege than needed
to perform functions and modules call on more privileged routines only if, and for as
long as, needed.
4.7 SYSTEMS PERFORMANCE
MANAGEMENT
4.7.2 OPERATING SYSTEMS
Operating System Reviews
4.7 SYSTEMS PERFORMANCE MANAGEMENT
Operating System Reviews
4.7 SYSTEMS PERFORMANCE MANAGEMENT
Operating System Reviews
4.7 SYSTEMS PERFORMANCE MANAGEMENT

4.7.6 SOFTWARE LICENSING ISSUES


 A software licensing agreement is a contract that establishes the terms and conditions under
which a piece of software is being licensed (i.e., made legally available for use) from the
software developer (owner) to the user.
There are two different software licensing types: free and paid.
4.7 SYSTEMS PERFORMANCE MANAGEMENT

4.7.6 SOFTWARE LICENSING ISSUES (paid software licensing )


4.7.6 To detect software licensing violations, the
IS auditor should:
4.7.7 SOURCE CODE MANAGEMENT

• Source code is the language in which a program is written. It is translated into object code
by assemblers and compilers and tells the computer what to do . By its very
nature, source code may contain intellectual property and should be protected, and access
should be restricted.
• The actual source code should be managed using a version control system (VCS), often
called revision control software (RCS). A VCS provides the ability to synchronize source
changes with changes from other developers, including conflict resolution when changes
have been made to the same section of source.
4.7.8 CAPACITY MANAGEMENT
Capacity planning and monitoring includes the elements listed in figure 4.8.
4.8 PROBLEM AND INCIDENT MANAGEMENT

4.8.1 PROBLEM MANAGEMENT

Problem management aims to resolve issues through the investigation and in


depth analysis of a major incident or several incidents that are similar in nature
to identify the root cause. Standard methodologies for root cause analysis
include the development of fishbone/Ishikawa cause-and-effect diagrams,
brainstorming and the use of the 5 Whys—an iterative question asking
technique used to explore the cause-and-effect relationships underlying a
problem.
• Problem management and incident management are related but have different
methods and objectives.
• Problem management’s objective is to reduce the number and/or severity of
incidents, while incident management’s objective is to return the affected
business process back to its normal state as quickly as possible, minimizing
the impact on the business.
Problem Management
Objective

• Reduce the number and/or severity of incidents.


Problem
Management • Improve the quality of service of an IS
organization.

• React to issues as they arise.


Incident • Return the affected process back to normal
Management service quickly.
• Minimize business impacts of incidents.

71 © Copyright 2016 ISACA. All rights reserved.


4.8 PROBLEM AND INCIDENT MANAGEMENT
4.8.3 DETECTION, DOCUMENTATION, CONTROL, RESOLUTION AND
REPORTING OF ABNORMAL CONDITIONS
4.8 PROBLEM AND INCIDENT MANAGEMENT

• 4.8.4 SUPPORT/HELP DESK


Procedures covering the tasks to be performed by the technical support personnel
must be established in accordance with an organization’s overall strategies and
policies. Figure 4.11 illustrates common support functions.
4.8 PROBLEM AND INCIDENT MANAGEMENT

• 4.8.5 NETWORK MANAGEMENT TOOLS


• In an organization’s modern inter-networking environment, all the
tasks can be accomplished by a set of tools generically called
network management tools.

• Response time reports


• Downtime reports
• Help desk reports
• Online monitors
• Network monitors
• Simple Network Management Protocol (SNMP)
4.8 PROBLEM AND INCIDENT MANAGEMENT
4.8.6 PROBLEM MANAGEMENT REPORTING REVIEWS
4.9 CHANGE, CONFIGURATION, RELEASE AND PATCH
MANAGEMENT
Change Management

• The change management process is implemented when:


• Hardware is changed.
• Software is installed or upgraded.
• Network devices are configured.
• Change control is part of the broader change management
process.
• It is designed to control the movement of application changes from
the test environment through QA and into the production
environment.
Change Management (cont’d)

• The change management process ensures that:


• Relevant personnel are aware of the change and its timing.
• Documentation is complete and in compliance.
• Job preparation, scheduling and operating instructions have been
established.
• System and program results have been reviewed and approved by
both project management and the end user.
• Data file and system conversions have been completed accurately
and completely.
• All aspects of jobs turned over have been tested, reviewed and
approved by control/operations personnel.
• Legal and compliance issues have been addressed.
• Risk associated with the change has been planned for, and a rollback
plan has been developed to back out the changes should that
become necessary.
Change Requests

• Formalized and documented change processes incorporate


the following elements:
• Change request
• Authorization
• Testing
• Implementation
• Communication to end users
Change Requests (cont’d)

• Procedures associated with these may vary according to the


type of change request, including:
• Emergency changes
• Major changes
• Minor changes
4.9.1 PATCH MANAGEMENT

 Patch management is an area of systems management that involves acquiring,


testing and installing multiple patches (code changes) to an administered
computer system to maintain up-to-date software and often to address security
risk.

Patch management tasks include the following:


• Maintain current knowledge of available patches.
• Decide what patches are appropriate for particular systems.
• Ensure that patches are installed properly; testing systems after installation.
• Document all associated procedures, such as specific configurations required.
4.9.2 RELEASE MANAGEMENT
Software release management is the process through which software is made
available to users. The term release is used to describe a collection of authorized
changes. The release will typically consist of several problem fixes and
enhancements to the service.
4.9.3 IS OPERATIONS
• IS operations are processes and activities that support and manage the entire IS
infrastructure, systems, applications and data, focusing on day-to-day activities.
4.10 IT SERVICE LEVEL MANAGEMENT
Key Terms

Key Term Definition


IT service The day-to-day provision to customers of IT infrastructure and
applications, and support for their use—e.g., service desk,
equipment supply and moves, and security authorizations
(COBIT 5 perspective)
Service level An agreement, preferably documented, between a service
agreement (SLA) provider and customer/user defining minimum performance
targets for a service and how they will be measured
4.10 IT SERVICE LEVEL
MANAGEMENT
• IT service management (ITSM) supports business needs
through the implementation and management of IT services.
• People, processes, and information technology are each a
part of IT services.
• A service management framework provides support for the
implementation of ITSM.
ITSM Frameworks

• Two primary frameworks guide ITSM:


• The IT Infrastructure Library (ITIL)
• The ITIL is a reference for service delivery good practice. These
should be adapted to the needs of the specific organization.
• ISO 20000-1:2011 Information technology – Service management –
Part 1: Service management system requirements
• ISO 20000 is primarily used as a demonstration of compliance to
accepted good practice. It requires service providers to implement
the plan-do-check-act (PDCA) methodology (Deming’s quality circle)
and apply it to their service management processes.
The ITSM Premise

• The bases of ITSM are:


• IT can be managed through a series of discrete processes.
• These processes provide “service” to the business and are
interdependent.
• Service level agreements (SLA) detail service expectations.
• To ensure high levels of service, ITSM metrics are compared
against the SLA expectations.
SLA Tools

• Several reporting tools aid in determining whether service


expectations are being met. These include:
• Exception reports
• System and application logs
• Operator problem reports
• Operator work schedules
SLA Tools (cont’d)

• When there is a contractual relationship between the IT


department and the end user or customer, SLA service level
definition is particularly important.
• The IS auditor should be aware of these defined
expectations, ensuring that they are comprehensive.
• These should include measures to address:
• Risk, security and control
• Efficiency and effectiveness
4.11 DATABASE MANAGEMENT
• DBMS software aids in organizing, controlling and using the data needed by
application programs. A DBMS provides the facility to create and maintain a well-
organized database. Primary functions include reduced data redundancy,
decreased access time and basic security over sensitive data.
4.11.2 DATABASE STRUCTURE
4.11.3 DATABASE CONTROLS
PART B: BUSINESS RESILIENCE

• Business resilience describes an organization’s ability to adapt to


disruptions and incidents in order to maintain continuous operations
and to protect the organization’s assets. Most organizations have some
degree of DRPs in place for the recovery of IT infrastructure, critical
systems and associated data.
However, many organizations have not taken the next step and developed
plans for how key business units will function during a period of IT
disruption. CISA candidates should be aware of the components of
disaster recovery and business continuity plans, the importance of
aligning one with the other, and aligning DRPs and business continuity
plans (BCPs) with the organization’s goals and risk tolerance.
Also of importance are data backup, storage and retention and
restoration.
Key Terms
Key Term Definition
Business continuity Preventing, mitigating and recovering from disruption. The
terms “business resumption planning,” “disaster recovery
planning” and “contingency planning” also may be used in
this context. They focus on recovery aspects of continuity,
and for that reason the “resilience” aspect should also be
taken into account.
Business continuity A plan used by an enterprise to respond to disruption of
plan (BCP) critical business processes; depends on the contingency plan
for restoration of critical systems.
Disaster recovery plan A set of human, physical, technical and procedural resources
(DRP) to recover, within a defined time and cost, an activity
interrupted by an emergency or disaster.
4.12 BUSINESS IMPACT ANALYSIS
• Business impact analysis (BIA) is a critical step in developing the business continuity
strategy and the subsequent implementation of the risk countermeasures and the
BCP in particular.
• BIA is used to evaluate the critical processes (and IT components supporting them)
and to determine time frames, priorities, resources and interdependencies. Even if an
extensive risk assessment was done prior to BIA, and the criticality and risk are input
into BIA, the rule of thumb is to double-check. Often, the BIA uncovers some less
visible, but nonetheless vital, component that supports the critical business process.
Where IT activities have been outsourced to third-party service providers, the
contractual commitments (in a BCP context) should also be considered.
• To perform this phase successfully, one should obtain an understanding of the
organization, key business processes and IT resources used by the organization to
support the key business processes. Often, this may be obtained from the risk
assessment results. BIA requires a high level of senior management
support/sponsorship and extensive involvement of IT and end user personnel.
4.12.1 CLASSIFICATION OF OPERATIONS AND
CRITICALITY ANALYSIS
• A system’s risk ranking involves a determination of risk that is based on the impact
derived from the critical recovery time period and the likelihood that an adverse
disruption will occur.
4.13 System Resiliency
4.13.1 APPLICATION RESILIENCY AND DISASTER RECOVERY METHODS

• System resilience is the ability of a system to


withstand a major disruption within set
metrics and recovery times. This can include
the ability to maintain capability during the
disruption.
Key Terms

Key Term Definition


Continuity Preventing, mitigating and recovering from disruption. The
terms "business resumption planning," "disaster recovery
planning" and "contingency planning" also may be used in this
context; they all concentrate on the recovery aspects of
continuity.
Resilience The ability of a system or network to resist failure or to recover
quickly from any disruption, usually with minimal recognizable
effect.
Application Resiliency

• The ability to protect an application against a disaster


depends on providing a way to restore it as quickly as
possible.
• A cluster is a type of software installed on every server in
which an application runs. It includes management software
that permits control of and tuning of the cluster behavior.
Application Resiliency (cont’d)

• Clustering protects against single points of failure in which


the loss of a resource would result in the loss of service or
production.
• There are two major types of application clusters, active-
passive and active-active.
Data Storage Resiliency

• The data protection method known as RAID, or Redundant


Array of Independent (or Inexpensive) Disks, is the most
common and basic method used to protect data against loss
at a single point of failure.
• Such storage arrays provide data replication features,
ensuring that the data saved to a disk on one site appears on
the other site.
Data Storage Resiliency (cont’d)

• Data replication may be:


• Synchronous—Local disk write is confirmed upon data
replication at other site.
• Asynchronous—Data are replicated on a scheduled basis.
• Adaptive—Switching between synchronous and
asynchronous depending on network load.
Telecommunications Resiliency

• The DRP should also contain the organization’s telecommunication


networks.
• These are susceptible to the same interruptions as data centers
and several other issues, for example:
• Central switching office disasters
• Cable cuts
• Security breaches
• To provide for the maintenance of critical business processes,
telecommunications capabilities must be identified for various
thresholds of outage.
Network Protection

Diverse
Redundancy Alternative routing
routing

Last-mile
Long-haul network Voice
circuit
diversity recovery
protection

103 © Copyright 2016 ISACA. All rights reserved.


TELECOMMUNICATION
NETWORKS RESILIENCY
AND DISASTER RECOVERY
METHODS:
4.14 Data Backup, Storage and
Restoration
• Because data are key assets to any organization,
data backup, storage and potential restoration are
key considerations for the enterprise. Laws and
regulations may impact how an enterprise can
handle this data and should be considered in
developing methods for data handling.
4.14.2 BACKUP AND RESTORATION
Frequency of Rotation
4.14.2 BACKUP AND RESTORATION
Types of Backup Devices and Media
4.14.3 BACKUP SCHEMES
4.14.3 BACKUP SCHEMES
4.15 Business Continuity Plan

• In the event of a disruption of normal business operations,


BCP and DRP can allow critical processes to carry on.
• Responsibility for the BCP rests with senior management, but
its execution usually lies with business and supporting units.
• The plan should address all functions and assets that will be
required to continue as a viable operation immediately after
encountering an interruption and while recovery is taking
place.
The BCP and DRP

• The DRP is a part of the BCP.


• It outlines the restoration plan that will be used to return
operations to a normal state.
• In general, a single integrated plan is recommended to
ensure that:
• Coordination between various plan components supports
response and recovery.
• Resources are used in the most effective way.
• Reasonable confidence can be maintained that the
enterprise will survive a disruption.
IT BCP

• IT service continuity is often critical to the organization,


and developing and testing an information system
BCP/DRP is a major component of enterprise-wide
continuity planning.
• Points of vulnerability are identified and considered
during the risk assessment process.
• The potential for harm from these can be quantified
through a BIA.
BCP Process
The BCP process can be divided into life cycle phases, as shown here.
Business Continuity Planning Life Cycle
Project Planning BC Plan Monitoring, BC
(BC Policy, Project Maintenance and Plan
Scope) Updating Testing

BC
Awareness
Training
Risk Assessment
and Analysis

BC
Plan
Development
Business
BC Strategy
Impact
Development Strategy
Analysis
Execution (Risk
Countermeasures
Implementation)

113 © Copyright 2016 ISACA. All rights reserved.


Disasters and Disruptions

• Disasters are likely to require recovery efforts to restore the


operational status of information resources.
• Categories of disasters include:
• Natural calamities
• Pandemics, epidemics or other infectious outbreaks
• Utility disruptions
• Actions by humans, whether intentionally harmful or
through error
• Hardware or software malfunctions
• Incidents causing damage to image, reputation or brand
• Some events are unforeseeable. These are referred to as “black
swan” events.
Business Continuity Policy

• A business continuity policy should be proactive, delivering


the message that all possible controls to both detect and
prevent disruptions should be used.
• The policy is a document approved by top management; it
serves several purposes:
• It carries a message to internal stakeholders that the
organization is committed to business continuity.
• As a statement to the organization, it empowers those
who are responsible for business continuity.
• It communicates to external stakeholders that obligations,
such as service delivery and compliance, are being taken
seriously.
Incident Mitigation

Incident and Impact Relationship Diagram


Reduce the Likelihood Mitigate the Consequences

Infrastructure
Monitoring
Backup and
Capacity Detective Recovery
Management Controls
Incident
Management (Help BCP or IT
Desk) DRP
Controls (Risk Corrective
Countermeasure) Controls Special Clauses
Spare Processing in
Site Vendor/Supplier
Contracts
Risk Preventive
Management Controls UPS or Power
Generator
Configuration
Management

116 © Copyright 2016 ISACA. All rights reserved.


BCP Incident Management

• By their nature, incidents and crises often unfold dynamically and


rapidly in unforeseeable directions.
• Management of such situations requires a proactive approach and
supporting documentation.
• All incidents should be classified at one of the following levels:
• Negligible — causing no perceptible damage
• Minor — producing no negative financial or material impact
• Major — causing a negative material impact on business
processes; possible effects on other systems, departments or
outside stakeholders
• Crisis — resulting in serious material impact on the continued
functioning of the enterprise and its stakeholders
• Note that the classification of an incident can change as events
proceed.
BCP Plan Components
• The BCP should include:

Continuity of Disaster recovery Business


operations plan plan resumption plan

• It may also include:


Crisis
IT contingency Incident Transportation
communications
plan response plan plan
plan

Occupant Emergency
Evacuation plan
emergency plan relocation plan
Plan Testing

• The critical components of a BCP should be tested under


simulated conditions to accomplish objectives such as these:
• Verify the accuracy of the BCP.
• Evaluate the performance of involved personnel.
• Evaluate coordination among response team members
and external parties.
• Measure the ability and capacity of any backup site to
perform as expected.
• Assessing the results and value of the BCP tests is an
important responsibility for the IS auditor.
Auditing Business Continuity

• When auditing business continuity, the IS auditor must


complete a number of tasks, for example:
• Understanding the connections between BCP and
business objectives
• Evaluating the BCP and determining its adequacy and
currency
• Verifying BCP effectiveness through a review of plan
testing
• Evaluating cloud-based mechanisms and offsite storage
• Assessing the ability of personnel to respond effectively in
the event of an incident
BCP Audit Review

1. Review the BCP document.

2. Review the applications covered by the


BCP.

3. Review the business continuity teams.

4. Test the plan.

121 © Copyright 2016 ISACA. All rights reserved.


BCP Audit Evaluation

Evaluate offsite
Evaluate key
Evaluate prior test storage facilities,
personnel through
results including security
interviews
controls

Evaluate the
alternative Evaluate insurance
processing coverage
contract

122 © Copyright 2016 ISACA. All rights reserved.


4.16 Disaster Recovery Plans
Disaster Management
• An IT DRP is a structured collection of processes and
procedures designed to speed response and ensure business
continuity in the event of a disaster.
• Various roles and responsibilities for teams are defined in the
DRP.
• The IS auditor should have knowledge of team
responsibilities, which are likely to vary from organization to
organization.
Disaster Recovery Planning

• Planning for disasters is an important part of the risk


management and BCP processes.
• The purpose of this continuous planning process is to ensure
that cost-effective controls are in place to prevent possible IT
disruptions and to recover the IT capacity of the organization
in the event of a disruption.
DRP Compliance Requirements

• DRP may be subject to compliance requirements depending on:


• Geographic location
• Nature of the business
• The legal and regulatory framework
• Most compliance requirements focus on ensuring continuity of
service with human safety as the most essential objective.
• Organizations may engage third parties to perform
DRP-related activities on their behalf; these third parties are also
subject to compliance.
Disaster Recovery Testing

• The IS auditor should ensure that all plans are regularly tested and
be aware of the testing schedule and tests to be conducted for all
critical functions.
• Test documentation should be reviewed by the IS auditor to
confirm that tests are fully documented with pre-test, test and
post-test reports.
• It is also important that information security is validated to
ensure that it is not compromised during testing.
RPO and RTO Defined

Recovery point objective (RPO) Recovery time objective (RTO)

• Determined based on the acceptable • The amount of time allowed for the
data loss in case of a disruption of recovery of a business function or
operations. It indicates the earliest resource after a disaster occurs.
point in time that is acceptable to
recover the data.
• The RPO effectively quantifies the
permissible amount of data loss in
case of interruption.

127 © Copyright 2016 ISACA. All rights reserved.


RPO and RTO Responses
• Both RPO and RTO are based on time parameters. The nearer the time
requirements are to the center, the more costly the recovery strategy. Note
the strategies employed at each time mark in the graphic below.

Recovery Point Objective Recovery Time Objective

4-24 hrs 1-4 hrs 0-1 hr 0-1 hr 1-4 hrs 4-24 hrs
• Tape backups • Disk-based • Mirroring • Active-active • Active-passive • Cold standby
• Log shipping backups • Real-time clustering clustering
• Snapshots replication • Hot standby
• Delayed
replication
• Log shipping

128 © Copyright 2016 ISACA. All rights reserved.


Additional Parameters

• The following parameters are also important in defining recovery


strategies:
• Interruption window—The maximum period of time an organization
can wait from point of failure to critical services restoration, after
which progressive losses from the interruption cannot be afforded.
• Service delivery objective (SDO)—Directly related to business needs,
this defines the level of services that must be reached during the
alternate processing period.
• Maximum tolerable outages—The amount of time the organization
can support processing in the alternate mode, after which new
problems can arise from lower than usual SDO, and the accumulation
of information pending update becomes unmanageable.
Recovery Strategies

• Documented recovery procedures ensure a return to normal


system operations in the event of an interruption.
• These are based on recovery strategies, which should be:
• Recommended to and selected by senior management
• Used to further develop the business continuity plan
(BCP)
Recovery Strategies (cont’d)

• The selection of a recovery strategy depends on the criticality of


the business process and its associated applications, cost, security
and time to recover.
• In general, each IT platform running an application that supports a
critical business function will need a recovery strategy.
• Appropriate strategies are those in which the cost of recovery
within a specific time frame is balanced by the impact and
likelihood of an occurrence.
• The cost of recovery includes both the fixed costs of providing
redundant or alternate resources and the variable costs of putting
these into use should a disruption occur.
Recovery Alternatives

Hot sites

• A facility with all of the IT and communications equipment required to


support critical applications, along with office accommodations for
personnel.

132 © Copyright 2016 ISACA. All rights reserved.


Recovery Alternatives (cont’d)

Warm sites
• A complete infrastructure, partially configured for IT, usually with
network connections and essential peripheral equipment. Current
versions of programs and data would likely need to be installed before
operations could resume at the recovery site.

Cold sites

• A facility with the space and basic infrastructure to support the


resumption of operation but lacking any IT or communications
equipment, programs, data or office support.

Source: ISACA, CISA Review Manual 26th Edition, figure 4.34

133 © Copyright 2016 ISACA. All rights reserved.


Recovery Alternatives (cont’d)

Mirrored sites
• A fully redundant site with real-time data replication from the production
site.

Mobile sites

• Modular processing facilities mounted on transportable vehicles, ready to


be delivered and set up on an as-needed basis.

Source: ISACA, CISA Review Manual 26th Edition, figure 4.34

134 © Copyright 2016 ISACA. All rights reserved.


Recovery Alternatives (cont’d)

Reciprocal arrangements

• Agreements between separate, but similar, companies to temporarily


share their IT facilities in the event that a partner to the agreement loses
processing capability.

Reciprocal arrangements with other organizations

• Agreements between two or more organizations with unique equipment


or applications. Participants promise to assist each other during an
emergency.

Source: ISACA, CISA Review Manual 26th Edition, figure 4.34

135 © Copyright 2016 ISACA. All rights reserved.


Domain 4 Summary

• Evaluate IT service management framework and practices.


• Evaluate IT operations (e.g., job scheduling, configuration
management, capacity and performance management).
• Evaluate IT maintenance (patches, upgrades).
• Evaluate database management practices.
Domain 4 Summary (cont’d)

• Evaluate data quality and life cycle management.


• Evaluate problem and incident management practices.
• Evaluate change and release management practices.
• Evaluate end-user computing.
• Evaluate IT continuity and resilience (backups/restores,
disaster recovery plan [DRP]).

You might also like