Scott E. Donaldson1 , Stanley G. Siegel2, Chris K. Williams3 and Abdul Aslam3
(1)
Falls Church, Virginia, USA
(2)
Potomac, Maryland, USA
(3)
San Diego, California, USA
Overview
This chapter describes how an enterprise’s cybersecurity program can be mapped against other cybersecurity frameworks such as the following:
(ISC)2 Common Body of Knowledge (CBK)
ISO 27001/27002 Version 2013
NIST SP800-53 Revision 4
Council on CyberSecurity 20 Critical Security Controls (CSC 20) Version 5.1
Reasons for such mapping include the following:
Many industries are regulated and must comply with regulations.
Similarly, cybersecurity programs must comply with regulatory cybersecurity requirements.
Compliance with such regulations and requirements needs to be demonstrable to independent auditors and regulators.
Enterprises need to report on the status of their cybersecurity programs against external frameworks to satisfy their own auditors or other internal business purposes.
Enterprises wish to crosswalk their cybersecurity program against an external framework to generate ideas for strengthening the enterprise’s cybersecurity posture.
Why not simply run an enterprise’s cybersecurity program according to one of these frameworks?
Frameworks are not generally designed for running a comprehensive cybersecurity program.
This study guide describes a cohesiveenterprise cybersecurity framework that integrates the following:
Architecture (a.k.a. Enterprise Cybersecurity Architecture) consisting of cybersecurity capabilities organized into functional areas that make capabilities easier to track, manage, and delegate
Cybersecuritypolicy designed to balance security needs against business priorities
Programmatics involving people, budget, and technology that are allocated to day-to-day operations and projects
IT lifecycle aligned with IT departments responsible for strategy and architecture, engineering, and operations
Cybersecurity assessments that are conducted periodically to help prevent cybersecurity program obsolescence
The enterprise cybersecurity framework is pragmatic, realistic, and designed for battling today’s cyberthreats as well as tomorrow’s next-generation cyberthreats.
It is not uncommon for an enterprise to report against two, three, or more cybersecurity frameworks.
This study guide’s enterprise cybersecurity architecture is a convenient structure for cross-walking required regulatory reporting such as the following:
Sarbanes-Oxley regulations for financial systems
Heath Insurance Portability and Accountability Act (HIPPA)
for medical systems
Payment Card Industry Data Security Standard (PCI DSS) for payment processing of credit cards
North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) regulations for energy generation systems
International Organization for Standardization (ISO) 27001 for general IT systems
Topics
Looking at Control Frameworks
Clearly Defining “Controls”
Mapping Against External Frameworks
One Audit, Many Results
Looking at Control Frameworks
A side-by-side comparison of this study guide’s enterprise cybersecurity architecture is shown below alongside some major control frameworks.
There are some commonalities: All five frameworks include access control and network or communications security; 4 of 5 frameworks include physical security; and so on.
All the frameworks more or less cover the same topics.
Unlike other frameworks, this study guide’s enterprise cybersecurity architecture is designed for running a comprehensive cybersecurity program.
Architecture organizes cybersecurity controls by enterprise cybersecurity functional areas.
Functional areas underlie and integrate an enterprise cybersecurity program that includes the following:
Policy
Programmatics
IT Life Cycle
Assessment
Functional areas provide the following:
Clear lines of delegation, responsibility, and accountability
Alignment of enterprise technologies and capabilities with people’s skill sets
Efficient engineering, deployment, operation, auditing, and reporting of enterprise security capabilities
Crosswalk to required reporting against multiple regulatory requirements
These combined features provide an easy-to-understand and practical enterprise cybersecurity architecture that adapts to the real world of evolving threat vectors.
Clearly Defining “Controls”
There is some
confusion over exactly what various cybersecurity frameworks mean by an “IT security control.”
This confusion results in considerable room for interpretation and judgment in regard to auditing against these frameworks.
Sometimes, what the frameworks call a “control,” this study guide would call a “capability.”
Other times, the frameworks talk about “requirements,” and it is up to individuals to identify what capabilities and controls would be needed to satisfy the requirements.
So, for the sake of clarity, this study guide defines a security control as follows:
“A security control consists of security capabilities or audit activities that are applied to an IT system or business process to prevent, detect, or investigate specific activities that are undesirable; an incident response is issued when those activities occur.”
The graphic depicts how
enterprise cybersecurity controls fit with security capabilities and the various audit types.
Security technologies or manual processes deliver enterprise security capabilities in terms of four types of security controls:
preventive, detective, forensic, and audit
These controls can then trigger an incident response when potentially malicious behavior occurs.
Audit activities deliver enterprise audit controls and periodic validation audits to ensure that everything is operating as designed.
For a security control to be effective, the following five elements should be present:
A specific IT system or business process must be identified that contains information where the enterprise is concerned about its confidentiality, integrity, or availability.
A specific malicious activity against an IT system or business process must be identified.
A security capability or audit control must be applied to an IT system or business process to restrict, delay, detect, or document the specific malicious activity that is of concern.
Incidentresponses must occur when malicious activities are detected.
Validation audits must occur periodically to ensure controls are effective and functioning properly.
Mapping Against External Frameworks
Context
An enterprise can use external cybersecurity frameworks in the following ways:
To help design an enterprise’s cybersecurity program to comply with specific external standards
To validate an enterprise’s cybersecurity program against those external standards
To give an enterprise ideas for cybersecurity capabilities and controls that may be of interest
The graphic below depicts how external frameworks influence the selection of security scopes and controls for Threat, Assessment, and Validation audits.
External frameworks feed into the selection of enterprise security scopes and security controls that are delivered by security capabilities, technologies, manual processes, and audit controls.
Assessment Audit and Security Scopes
Analyze how external
framework controls and requirements apply to the enterprise
Decide if the
enterprise wants a narrow scope or broad scope application of the framework
Narrow scope: Only IT systems and processes that are primarily involved in the external framework’s scope are considered to be in-scope for the assessment; supporting systems and processes that are only indirectly involved in the assessed function are considered to be out-of-scope.
Broad scope: IT systems that are primarily involved in the external framework’s scope as well as supporting IT systems that are only indirectly involved are considered in-scope; scope can result in a large number of systems to be considered in-scope.
Supporting security systems help determine security scope.
If an enterprise security program
is going to be validated by internal or external auditors, it is recommended the cybersecurity team meet with the auditors to mutually agree on whether a narrow scope or broad scope approach is necessary.
It is important
to determine which supporting security systems and process are to be considered in-scope for an assessment.
IT Systems and Security Controls
An enterprise
needs to identify the security controls appropriate to meet the external framework’s requirements.
Requirements have general guidance.
“You shall have a firewall.”
“Credit card data will be encrypted.”
For example, ISO 27001 and the HIPPA security rules provide rules to follow.
Requirements may be very specific.
“Application whitelisting technology will be used on servers.”
For example, Council on CyberSecurity 20 Critical Controls and HITECH provide rules to follow.
Mandated controls depend upon the specifics of the framework being considered and the capabilities available to implement them.
When using frameworks where there is leeway, an enterprise can take advantage of the opportunity to select controls that work well in its environment and are economical to procure, deploy, and operate.
Many cybersecurity
frameworks have been established over the past two decades and are in common use today.
Balancing Prevention with Detection and Response
Many popular
frameworks focus primarily on preventive controls that block undesirable activities and give less attention to detective, forensic, and audit control alternatives.
A prevention focus can lead to the following:
A false sense of security
Controls that are highly disruptive to legitimate business activities
When an enterprise delivers the same level of security “in the background” without disrupting people’s normal activities, it can be a significant win vs. security being a constant disruption to people doing their jobs.
Enterprises can look at security control alternatives with the “Audit First” Design Methodology.
If an enterprise opts for detective, forensic, and audit control alternatives vs. preventive controls,
some negotiation
between the cybersecurity team and auditors may be required with respect to how the enterprise protects itself; and
auditors may be thinking only of preventive controls and not give credit for other controls that are in place.
An enterprise needs to work with its auditors to consider how passive controls (detective, forensic, and audit) can provide effective protection of IT assets and data.
Security Capabilities, Technologies, and Processes
Enterprises
must identify the security capabilities, technologies, manual processes, and audit processes necessary to deliver the controls chosen.
It is often faster and cheaper to set up a manual detective control or audit process than to install a new security technology.
Where speed is of the essence, an enterprise can stand up “quick and dirty” controls until more permanent solutions can be put in place.
Enterprises shouldn’t underestimate the power of manual processes to protect on a temporary basis (months or years) until funding is available for long-term solutions.
Some controls are manual and are no less valid than automated preventive and detective controls.
Maintaining
paper or digital logs of activities
Auditing system logs to identify and investigate malicious activities
An enterprise should document manual processes.
What they are
Who should be doing them
Who is responsible for overseeing and maintaining them
If manual processes deliver the same functionality as automated technology, then an enterprise should give itself credit for having the capabilities.
Validation Audit and Reporting
With enterprise
controls in place, an enterprise should conduct validation audits of the cybersecurity program and report the results to internal and external auditors and regulators.
Note: Validation and assessment audits should be conducted in a similar fashion.
Once an enterprise’s cybersecurity program is in place, the validation audit from one time period can serve as the assessment audit for the next time period.
This audit sequence provides the enterprise with the inputs needed to make adjustments to the cybersecurity program over time.
There are two validation audit reports.
External-facing audit report
Internal-facing audit report
The external-facing auditreport presents the results to external auditors and regulators.
Lists the requirements of the framework to be audited
Explains how the cybersecurity program satisfies the requirements, any deficiencies identified during the audit, and the results of remediating those deficiencies
The internal-facing audit report is an
addendum to the external-facing report.
Contains internal-use-only recommendations for improving future security and audit results
One Audit, Many Results
Context
Enterprises are often required to report to multiple external frameworks where a number of controls are common to more than one framework.
The graphic shows an approach for auditing the controls and reporting the audit results against the separate frameworks.
Once controls are in place, validation audits can verify if the control framework was implemented. Then the results of those audits can be mapped and reported against multiple frameworks
.
The key to this reporting approach is separating the audit process from the security frameworks so the audit covers all controls and a superset of the framework requirements.
Audit Reporting Mapping
Audit results
can be reported against various frameworks.
If the enterprise’s control database includes cross-references connecting controls to the applicable framework requirements, it is straightforward to track results to various frameworks.
Using such cross-references, a single control can be referenced by multiple frameworks
or different parts of a single framework.
When the audit is complete, the enterprise follows these cross-references to build the report against the structure of each framework to be reported against.
A simple database
is able to show results against multiple frameworks across multiple audits.
Deficiency Tracking and Management
Audit deficiencies
should be tracked against the controls they apply to and cross-referenced against the external frameworks for reporting purposes.
The results, in part, provide input to substantial discussions about the materiality of deficiencies against framework compliance.
A single deficiency may be material against one external framework, but immaterial against another framework.
The key challenge is properly handling the delay between reporting the initial results of the audit and actually remediating the identified deficiencies.
Regularly scheduled audits looking at the same controls on a regular basis—for example, quarterly or annually—help to address this reporting delay challenge.
Deficiencies from the previous audit may become part of the kickoff for the next audit.
Enterprise management
can then pay particular attention to deficiencies that are not remediated between audit, or that show up as recurring problems across multiple audit cycles.
