Skip to main content
Erschienen in:
Buchtitelbild

Open Access 2020 | OriginalPaper | Buchkapitel

6. Establish a Control Baseline

verfasst von : Dan Blum

Erschienen in: Rational Cybersecurity for Business

Verlag: Apress

Aktivieren Sie unsere intelligente Suche um passende Fachinhalte oder Patente zu finden.

search-config
loading …

Abstract

All security programs depend on having some basic controls, called a control baseline, in place. After all, one would not deem a house or an office “secure” without locks on the doors to control entry.
All security programs depend on having some basic controls, called a control baseline, in place. After all, one would not deem a house or an office “secure” without locks on the doors to control entry.
There are many technical and nontechnical controls that a business could implement, but few businesses have the time, money, or inclination to implement them all. Some guidance is needed to determine which controls are most needed, and to that end the industry provides various standard control frameworks.
Some control frameworks – such as the International Organization for Standardization (ISO) International Standard 27001 and the National Institute of Standards and Technology (NIST) Special Publication 800-53 – contain many granular controls. Others such as the Center for Internet Security’s Top 20 Critical Security Controls provide a more minimalistic list.
This chapter provides a Rational Cybersecurity take on the minimum viable control baseline by identifying core control domains and guidance for choosing granular controls based on the business’s unique needs. It also focuses on specific requirements for alignment with IT or business groups to implement or operate each type of control effectively.
Security leaders can use the information in this chapter to establish a control baseline by
  • Selecting a list of controls scaled for a business of their type and size
  • Developing an architectural model and road map for implementing the controls across the business or prioritized environments
  • Prioritizing deployment phasing across various IT environments using risk management
  • Sharing responsibility for control operation with third parties, such as cloud service providers (CSPs)
  • Aligning control operation with appropriate IT, development, corporate administration, and line of business (LOB) groups

6.1 Understand Control Baselines and Control Frameworks

Businesses require a written policy that states how they will address security. Organizations have a legal obligation to adhere to their own policies, and in some jurisdictions or industries, policies are required to address specific security objectives such as safety or privacy. A complete security policy encompasses multiple documents, including formal definitions of the controls the business will implement.
Security leaders understand controls. Still, the terms “control framework” and “control baseline” – which are different terms for a “list of controls” – get tossed around and used in different ways.
What Is a Control Framework?
A control framework is a list of control objectives, or security requirements, such as “Physical devices and systems within the organizations must be inventoried.” Notice this example says what the organization is supposed to do, but not how. Usually, subordinate policy or procedure documents detail control activities.
The security industry is replete with helpful standards for security control frameworks. Some of the most important ones are
  • NIST SP 800-53 rev 41 (controls for US Federal information systems and organizations)
  • ISO 270012 (management system and reference controls) and 270023 (code of practice and implementation guidance)
  • ISACA COBIT4 framework for enterprise IT governance and management
  • Cloud Security Alliance (CSA) Cloud Controls Matrix,5 which provides a useful cross-reference to many of the other frameworks
Some compliance regulations define their own control frameworks, others reference one or more general-purpose control framework standards. For example, US Federal Government regulations such as National Institute of Standards and Technology (NIST) Special Publication (SP) 800-1716 reference both NIST and International Organization for Standardization (ISO) control frameworks, but map more specifically to NIST’s own control frameworks. A control baseline for a contractor covered by NIST 800-171 would need to reference the NIST control frameworks.
https://static-content.springer.com/image/chp%3A10.1007%2F978-1-4842-5952-8_6/MediaObjects/495216_1_En_6_Figa_HTML.jpg
6-1
Work with the legal team(s) and lines of business to list compliance regulations that apply to the business. Use this list to determine which standard control frameworks the control baseline should reference and which objectives or activities it should comply with.
When compliance requires a specific control, such as data-at-rest encryption, it may be necessary to implement it. Beware, however, of falling for the following myth. Always look beyond compliance to assess the top risks to the business and the controls they imply.
https://static-content.springer.com/image/chp%3A10.1007%2F978-1-4842-5952-8_6/MediaObjects/495216_1_En_6_Figb_HTML.jpg
6
Compliance to a regulation or a checklist of controls equals (or guarantees) security.
What Is a Control Baseline?
The work of security is never done. Nonetheless, the security leadership should be focused on a “minimum viable product” for the outcomes it delivers. What we mean by a “control baseline” is the minimum set of security controls specified for a business IT environment and applicability guidelines to where they apply. For example, some controls might apply to systems with confidential data but not to systems with public data. Other controls might only be implemented for newer versions of applications or operating systems that the organization considers “strategic” and not for capabilities that are being phased out.
What Do We Mean by Establishing a Control Baseline?
Establishing the control baseline is the process of implementing it for actual IT systems. The organization must not only specify a minimum viable set, it must prioritize which business units, regions, or systems implement which controls. Once implemented, it must verify the controls are operating correctly and sustain them.

6.2 Address Common Challenges

The industry is mature in understanding what security controls could be implemented, but immature about prioritizing them in a risk-informed way, organizing them in a coherent architecture, and engaging business stakeholders in the work of implementing controls. The following issues continue to challenge businesses:
  • Too many controls? Seeing the forest through the trees
  • Difficulty risk informing controls
  • Controls without a unifying architecture
  • Lack of structure for sharing responsibility with third parties
  • Controls out of line with business culture

6.2.1 Too Many Controls?

The standard control frameworks each contain hundreds of control objectives and many additional guidelines or requirements for control activities. We are inundated with an abundance of information, often conflicting terminology, oversight requirements, and products which can be overwhelming for smaller organizations and anyone just getting started. Even larger organizations and experts struggle to see the forest for the trees. Recognizing this challenge:
  • The Center for Internet Security (CIS) maintains a list of the “top 20” security controls7 curated through a community of IT experts. Its stated goal is to help practitioners see through the “fog of more” and identify a set of prioritized actions based on best practices for defense in depth.
  • NIST publishes a Cybersecurity Framework8 as a higher-level, more business-accessible list of controls that also provides pointers to the granular NIST 800-53, ISO 27001, COBIT, and the CIS top 20 controls.
Despite the NIST and CIS efforts, I’m not convinced they have produced a minimal viable control baseline. Although NIST CSF provides a very useful way of looking at controls, there are over 100 of them. Enumerating all the subcontrols that detail the CIS makes its baseline much more numerous than 20. And although the CIS 20 covers cybersecurity technology well, it doesn’t cover the people and process behind it with the same rigor. The idea of an industry control baseline is something of a myth.
https://static-content.springer.com/image/chp%3A10.1007%2F978-1-4842-5952-8_6/MediaObjects/495216_1_En_6_Figc_HTML.jpg
7
There exists one control baseline that is suitable for every business.
Readers might be wondering, if that’s the way I feel about control baselines, why this chapter? My answer is that although no one control baseline can fit every business or IT environment perfectly, businesses should still develop an overarching control baseline as part of the high-level security policy and use it as a yardstick in selecting controls for each of its IT environments.
To help that effort, I’ve identified 20 control domains (or groups of controls) later in this chapter and provided guidelines for selecting granular controls within them.

6.2.2 Difficulty Risk Informing Controls

Many think risk management is something you do after the security program becomes sufficiently mature rather than a vital component that helps get the program off the ground and guide the program while it matures. Another challenge is the industry’s relatively low level of risk management maturity. Practitioners still struggle because
  • Selecting controls based on risk scenarios is currently more of an art than a science.
  • Operationalizing risk management throughout the enterprise also requires mature, risk-informed asset and vulnerability management, third-party management, and other processes.
  • It is sometimes difficult to determine which controls are reducing risk less than others and should be decommissioned during a budget cut or reallocation process

6.2.3 Controls Without a Unifying Architecture

Today’s digital businesses must implement controls in a hybrid multicloud environment and address a burgeoning crop of regulatory requirements across the international market landscape. Larger enterprises face additional complexity from multiple generations of IT infrastructure and applications.
One can make all the right moves by identifying the greatest risks and the controls to treat them, but without architectural alignment, controls may not be effective. Many organizations have acquired a lot of security tools needed to implement controls. But because they haven’t planned how to integrate those tools with other tools and processes, they get little value.
How should businesses develop the control architecture? Like the NIST CSF, I recommend starting with a basic cybersecurity and risk assessment. In the section “Develop an Architectural Model and Plans for Control Implementation,” we cover this critical step to align the control baseline with the operational security environment.

6.2.4 Lack of Structure for Sharing Responsibility with Third Parties

When a business relies on a third party to operate its systems, some of the controls may be operated by the third party and some by the business, and they must coordinate their efforts. To be effective, the business control baseline must be aligned with the third-party controls through shared responsibility models.
Shared responsibility has proven difficult for the industry to address through existing control frameworks. To solve shared responsibility, we need to focus on what the business is doing with a system provided with the aid of a third party (the “use case”), what controls it can operate for itself, and what controls the third party operates. The section “Apply a Shared Responsibility Model to the Control Baseline” provides guidance on how to analyze and define shared responsibilities.

6.2.5 Controls Out of Line with Business Culture

Risk and regulatory considerations incline security departments toward implementing restrictive controls on users, but one must be careful not to get in the way of business growth and agility. Digital business requires exploiting technology in innovative ways. It’s all too easy for security teams and business staff to work at cross-purposes, as in
  • Security policy writers create control standards and requirements without engaging the business to learn whether the requirements are practical or provide guidance on how the business can best meet the requirements.
  • IT or LOB executives turn a blind eye to some security policies and don’t tell security teams in advance about all their digital innovation or procurement plans.
  • Developers use “port agility” to get traffic through the firewall even as the network security team tries to block it.
  • IT administrators kill the security team’s privileged access management (PAM) initiative with passive-aggressive or uncooperative behavior.
Control objectives, or principles, such as least privilege (i.e., designing systems and processes to minimize privilege grants to users or administrators) are well enough in theory but often difficult in practice. Overly restrictive controls at the user level can create negative staff perceptions about security, potentially leading staff to withhold cooperation and make the controls less effective. Impeding business efforts to innovate in pursuit of business objectives can reduce business leader buy-in for the security program and tends to prove futile as the business wins many – if not most – arguments with security.
Security leaders should discover and confirm how controls can align with the business as a check on the initial control baseline and for implementation guidance. See section “Align Control Deployment and Business Functions” further on in this chapter.

6.3 Select a Control Baseline from the Essential Control Domains

Creating a control baseline is a useful exercise for security professionals regardless of whether you’re starting with a blank slate in a new position or trying to validate an existing control baseline. Take the control domains in Table 6-1 coupled with the guidance in this section as a starting point for creating a control baseline that fits your business.
Table 6-1
Rational Cybersecurity Control Domains
Control Domain
Summary Description
Security governance
Govern security roles, responsibilities, decisions, and strategy.
Risk management
Create a taxonomy framework and processes to identify, assess, treat, monitor, and communicate risks.
Security policies and awareness
Document security requirements for people and systems. Publicize them and motivate or empower users to follow them through user awareness training.
Asset inventory
Discover IT assets, profile their risk, and identify all critical assets as well as asset owners.
Third-party management
Discover third parties, profile their risks, and manage shared responsibilities for security.
Network security and zoning
Protect network security, arrange IT assets in physical network segments or logical compartments (i.e., “zones”), and provide perimeter protections to the zones.
Authentication, user account management
Manage employee, contractor, and other users’ accounts; authenticate access to those accounts.
Access management and authorization
Enable asset owners to ensure that authenticated users can only access resources as prescribed by business policies.
Security configuration and change management
Configure IT systems and applications in a secure manner and control changes to policies, configurations, documents, and code.
Data protection
Classify and discover sensitive information. Apply encryption, tokenization, or data leakage protection (DLP) on data in motion, at rest, and in use.
Secure software development and application security
Follow secure software development lifecycle (SDLC) and/or DevSecOps standards and practices in development projects.
Vulnerability management
Scan IT systems and applications for software, hardware, or configuration vulnerabilities; prioritize and remediate vulnerabilities.
Physical security
Monitor and protect the business’s physical facilities to safeguard the users and assets within the facilities as well as the facilities themselves.
Secure HR practices
Perform background checks and ensure that people-related security practices (e.g., background checks) comply with laws and good practices.
Real-time threat detection
Detect hacking, malware, and abuse against IT systems and devices; generate alerts to security monitoring systems; and triage alerts for effective response.
Logging and log review
Generate and collect event logs of security-relevant information in keeping with security standards; review logs to detect threats or compromises of IT systems.
User account monitoring
Monitor both standard user accounts and privileged user accounts for unauthorized, unusual, or suspicious activity.
Incident response
Identify and investigate all types of incidents, contain threats, eradicate malware or damaged configuration, recover, and learn from incidents.
Backup and data recovery
Back up data, configuration, and code of IT assets in a secure manner and test the ability to perform data recovery.
Business continuity
Identify critical assets, create procedures and facilities to recover their functionality within a specified time in the event of outage, and test recovery.
The remainder of this section aligns the Rational Cybersecurity control domains with the NIST CSF and provides guidance for readers to use in selecting at least a minimal set of controls from most or all domains to form their business’s control baseline. For each control domain, the text identifies
  • Definition: Brief definition of the control domain.
  • Description: Describes requirements for the control domain broadly aimed at attaining the Level 3, or “Defined” maturity level. Recall from Chapter 1’s section “Maturity,” Figure 1-6, that attaining the Defined maturity level requires that security roles, responsibilities, and policies be defined and established in at least some areas, but only requires manual means of verification.
  • Business dependencies: Identify the business functions that tend to be involved with the control domain deployment, for example, IT and development managers for security configuration and change management and HR for secure HR practices. Table 6-3 in section “Align Control Deployment and Business Functions” summarizes a master table of control domains and business interdependencies.

6.3.1 Serve Up a Balanced Diet of Controls

As shown in Figure 6-1, the NIST CSF structures controls into the five primary defensive security categories.
I’ve noted where each Rational Cybersecurity control domain falls around the NIST CSF “wheel.” It’s not an exact mapping; some control domains like network security zones and physical security have both “protect” and “detect” properties. But it should give readers an idea of how the control domains complement each other to complete the security posture.
Although NIST CSF isn’t the only way we could categorize controls, it provides value in understanding and promoting a holistic security posture:
  • Identify (ID): Know what you have and what you need to protect.
  • Protect (PR): Endeavor to prevent harm to your IT assets or security objectives.
  • Detect (DE): When protection fails – and it will eventually – at least detect the problem.
  • Respond (RS): Upon detecting an attack, incident, or serious vulnerability, act to stop or contain it.
  • Recover (RC): Once the breach has been closed, fix the damage.
All five types of controls are required for a balanced security posture in today’s target-rich digital environment. Even if an organization does a great job in the Identify and Protect areas, threats will sometimes prevail. Attacks or incidents must be detected and mitigated quickly, and the damage repaired, if only to report a near miss to the regulators, save the business from fines, and preserve its good reputation.
Although some control domains may be more important than others depending on the type of business, basic security hygiene usually requires at least some effort into each of them. Later sections on how to risk-inform and how to scale the control baseline provide guidance on when Level 3 “Defined” maturity would be too much or not enough.
Select the NIST CSF controls cited by the references in the following tables that are applicable for your IT environment and risk profile. Each table contains my description of the control domain and its Level 3 maturity criteria, business functions or roles it depends on for deployment, and the NIST CSF controls related to the control domain. Readers can also use the NIST CSF’s mappings from CSF’s own relatively high-level controls to the more granular NIST 800-53, COBIT, and ISO 27001 controls when more specific direction is required.

6.3.2 Identify All Aspects of Situational Awareness

More than one of security leaders I interviewed for the book described asset discovery and inventory as the most critical control that’s often overlooked. But “identify” should be seen in a much broader context; we need to identify accountabilities, strategic risks, and more.
“If you know the enemy and know yourself you need not fear the result of a hundred battles.”
Sun Tzu, The Art of War
Security Governance Control Domain
Definition: Governs security roles, responsibilities, decisions, and strategies through a set of processes and capabilities operated jointly by business and security leaders
Description: Puts a CISO or other top security leaders in place. Defines the lines of authority, accountability, and responsibility for cybersecurity. Aligns cybersecurity risk, security policy, and resource allocation with business strategies. Reports security and risk status and progress to executives and stakeholders in business terms.
Business dependencies: Executive stakeholders, LOB, and IT management.
References: Chapters 2, 3
NIST CSF references:
ID.GV: All four controls
Risk Management Control Domain
Definition: Creates a taxonomy and process to identify, assess, treat, monitor, and communicate risk.
Description: Discovers and communicates business leaders’ risk appetite and desired risk treatment strategies, that is, accept, avoid, mitigate, or transfer different kinds of risks. Puts a standard control framework in place and determines control selection and prioritization. Maintains and communicates risk register to management. Aligns with regulatory requirements, compliance, and audit functions.
Business dependencies: Enterprise risk management, executive stakeholders, LOB executives, and compliance teams for basic program. Potentially any other business stakeholders depending upon the content of specific risk assessments.
References: Chapter 5
NIST CSF references:
ID.BE: Business environment
ID.RA: Risk assessment
ID.RM: Risk management
ID.SC: Supply chain risk
Security Policies and Awareness Control Domain
Definition: Documents security requirements for people and systems in the business and publicizes them through user awareness training.
Description: Establishes a lifecycle management process for high-level policy and subordinate standard, guideline, and procedure document hierarchies. Seeks to promote secure behavior and a healthy security culture. Covers security governance, risk management, acceptable use of IT and information assets, data classification, access management, incident response, and other policies. Puts an awareness and training program in place. Refer to Chapter 3 for guidance on policy management and Chapter 4 for advancing awareness and the supporting security culture.
Business dependencies: Executive stakeholders, LOB, IT, development leadership, and project management office (PMO) as well as awareness team and/or internal marketing team.
References: Chapters 3, 4
NIST CSF references:
ID.GV-1: Organizational policy
PR.AT: All five controls
Asset Inventory Control Domain
Definition: Discovers IT assets, profiles their risks, and identifies all critical assets as well as asset owners.
Description: Maintains asset inventory databases, directory services, and other registries with information on the assets. Using asset risk profiles, identifies the organization’s most valuable, critical, or high-risk assets (aka “crown jewels”). Refer to Chapter 7 for consideration of “knowing what you have” as part of rationalizing IT and to Chapter 5 for more information on asset risk profiling.
Business dependencies: Asset inventory functions are generally led by IT, development, and LOB managers.
References: Chapters 5, 7
NIST CSF:
ID.AM: All six controls
ID.RA-1: Identify asset vulnerabilities
PR.DS-3: Assets managed
A STORY OF UNIDENTIFIED ASSET RISK
“When I was the CISO of a global corporation, we had a comprehensive global outsourcing contract. Worryingly, when asked, they couldn’t tell us how many devices we had on the network. I need visibility! The outsourcer eventually estimated we had 88,000 devices, but I knew that was too low because my rule of thumb was 1.5 devices per person. When we implemented Qualys [asset discovery and vulnerability scanning] it found 138,000 devices. That in turn gave us the visibility to understand which devices the outsourcer should manage and hold their feet to the fire requiring: ‘Fix all critical vulnerabilities on a device in a timely manner.’”
Paul Simmonds, CISO
Third-Party Management Control Domain
Definition: Manages vendors, suppliers, and other third parties, profiles their risks, and manages shared responsibilities for security.
Description: Provides security input on business decisions to use new third parties or make major changes to existing use cases. Sets standards for security controls or conduct by third parties. Conducts audits of third parties in the highest risk tiers.
Business dependencies: Third-party management generally led by procurement or vendor management. IT management, LOB leadership, and other stakeholders initiate third-party relationships.
References: Chapter 5
NIST CSF references:
ID.SC: Supply chain risk

6.3.3 Protect Information Systems and Assets

Businesses should apply a defense-in-depth strategy using network boundaries, hardening and securely configuring systems, managing digital identity and logical access control, encrypting or obfuscating data in transit or storage to prevent unauthorized access, and providing physical security and personnel controls. Some of these controls can be implemented using commercial off-the-shelf (COTS) products, cloud-based or cloud-native security services, or even open source tools. When the organization develops its own applications, it also needs to ensure the software is written securely.
Network Security and Zoning Control Domain
Definition: Arranges IT assets in logical compartments or physical network segments (i.e., “zones”) and provides perimeter protections to the zones. Uses network firewalls, microsegmentation in data centers, virtual LANs (VLANs), and other solutions to enforce communications policies. Controls remote access to protected or restricted via virtual private networks (VPNs), jump hosts, or reverse proxies.
Description: Protects network routing and control devices. Separates assets of different levels of criticality, or with different compliance or communications needs, using zones. Provides zone perimeter enforcement using network firewalls, host-based firewalls, virtual machine firewalls, or identity-based access controls to form physical or logical boundaries.
Business dependencies: EA, IT, and development leaders and architects as well as compliance and audit, networking, network management, and endpoint security teams.
References:
NIST CSF references:
PR.AC-3: Remote access
PR.AC-5: Network segregation
PR.AC-7: Device authentication
PR-PT-4: Protect control networks
Security zoning has been a consistently difficult topic since at least the 1990s when private business networks began connecting to the Internet. Hackers began to ply their trade, security teams put up firewalls, and end users and developers found ways to get traffic around or through the firewalls. By the late 1990s and early 2000s, the concept of a “virtual enterprise” doing business with customers, suppliers, partners, and telecommuting employees was in vogue, and security architects began to speak of deperimeterization. In the early 2020s, COVID-19 dramatically increased the need for telecommuting, remote access, and zero trust architectures9 that require strong authentication or other security measures for all access, regardless of originating location.
Businesses continue struggling with how much security zoning is necessary and how to implement it. Too little, and the business’s IT resources may be overly exposed to cyberattackers. Too much, and the IT architecture may become inflexible and impede business agility.
Authentication and User Account Management Control Domain
Definition: Manages employee, contractor, and other users’ accounts; authenticates access to those accounts.
Description: Manages user accounts in directory services and other authentication systems for all employees and third-party contractors or partners and authenticates access to resources by people, machines, or services on the network. Depending on the criticality of the accounts, supports passwords, biometric sign-on, or stronger authentication capabilities such as one-time password (OTP) token generators and contextual authentication services. Protects secret authentication credentials such as passwords from disclosure. For consumer accounts in some jurisdictions, includes core privacy features such as consent management. Uses special techniques, such as password vaulting, for privileged user accounts.
Business dependencies: IT and development managers. Compliance and audit.
References: Chapter 8
NIST CSF references:
PR.AC-1: Manage IDs, credentials
PR.AC-6: Identity proofing
PR.AC-7: User authentication
Access Management and Authorization Control Domain
Definition: Enables asset owners to ensure that authenticated users can only access resources as prescribed by business policies.
Description: Enforces access control at multiple layers, such as network perimeters, access proxies, systems, databases or repositories, and applications. Controls fine-grained access permissions at the application level using security groups, roles, or attributes. Provides access management processes and workflows to request or review access. Provides access provisioning (and deprovisioning).
Business dependencies: EA, IT managers, development managers, and any other stakeholder relying on shared IAM services or controlling a system affected by shared access control policies. Compliance and audit.
References: Chapter 8
NIST CSF references:
PR.AC-2: Physical access control
PR.AC-3: Remote access
PR.AC-4: Authorization
PR.AC-5: Network access
PR.PT-3: Least functionality
Security Configuration and Change Management Control Domain
Definition: Configures IT systems, network devices, and applications in a secure manner and controls changes to policies, configurations, documents, and code.
Description: Securely configures systems to reduce attack surface by applying least privilege and least functionality principles. Applies vendor or service provider secure configuration baselines. Supports change management to minimize “drift” from the baselines and uses automated tools to check operating system instances, workloads, and deployed application configuration settings against baselines for managed assets.
Business dependencies: IT managers, development managers, and any other stakeholder controlling a system affected by shared security configuration and change control policies. Compliance and audit.
References:
NIST CSF
PR.IP-1: Secure baseline configuration
PR.IP-3: Change control
Data Protection
Definition: Classifies and discovers sensitive information and applies core data security and privacy controls such as encryption or data leakage protection (DLP) on data in motion, at rest, and in use.
Description: Encrypts data on the wire using Transport Layer Security (TLS) and similar protocols and encrypts data at rest on mobile devices. Databases and other critical repositories where large amounts of structured or unstructured sensitive data are stored may leverage secure configuration, access control, restrictive security zoning, and database audit and protection tools rather than encryption to avoid degrading functionality. Defines data classification policies and data owners and discovers or keeps an inventory of sensitive data in the IT environment. Chapter 8 discusses data governance which affects data protection as well as access control.
Business dependencies: EA, IT managers, development managers, and any other stakeholder holding confidential or restricted data (especially when using shared data protection services). Compliance and audit.
References: Chapter 8
NIST CSF
ID.AM-5: Resource classification
PR.DS-1: Data-at-rest protected
PR.DS-2: Data in transit protected
PR.DS-4: Adequate capacity
PR.DS-5: Data leak protection
Secure Software Development and Application Security Control Domain
Definition: Follows secure software development lifecycle (SDLC) and/or DevSecOps standards and practices in development projects.
Description: Sets standards, training, practices, and tools enabling developers to create more secure systems and applications. Performs threat modeling and security reviews during the design phase or at intervals during agile development processes. Provides tools for static and dynamic software testing as well as vulnerability assessment to add assurance during the quality control process, at least for critical applications. Provides basic web application firewall (WAF) functionality.
Business dependencies: Chief Technology Officer (CTO) and development leaders
References: Chapter 7 (DevSecOps)
NIST CSF references:
PR.AC-4: Access control (for applications)
PR.AT-1, 2: User awareness, training
PR.DS-7: Separate development from production
PR.IP-2: Implement secure SDLC
PR.IP-12: Vulnerability management plan
Vulnerability Management Control Domain
Definition: Scans IT systems and applications for software, hardware, or configuration vulnerabilities; prioritizes and remediates vulnerabilities.
Description: Provides processes and tools for periodic automated vulnerability scanning and vulnerability remediation through patching or applying compensating controls. Patching processes take software updates from multiple vendors and/or a third-party vulnerability management tool. Prioritizes vulnerability remediation. For critical assets, tests patches before applying them to reduce chance of impact on users or disruption to production systems.
Business dependencies: IT and development leaders, compliance and audit
References: Chapter 5 (triage, prioritization)
NIST CSF references:
PR.IP-12: Vulnerability management plan
PR.IP-1: Secure baseline configuration
DE.CM-8: Vulnerability scans
RS.MI-3: Vulnerability mitigation
PR.MA-2: Remote maintenance
PR.PT-3: Least functionality
PR.DS-6: Integrity checking
Physical Security
Definition: Monitors and protects the business’s physical facilities to safeguard the users and assets within the facilities as well as the facilities themselves.
Description: Protects business facilities, such as office buildings, data centers, and servers. Provides physical access control systems, such as locks, alarms, and physical identity badge readers. Uses cameras and motion sensors to monitor facilities. Protects against natural threats such as earthquakes, fires, and floods.
Business dependencies: Facilities management (physical security, executive protection, badging), IAM teams.
References:
NIST CSF references:
PR.AC-2: Physical access control
PR.IP-5: Physical security policy compliance
DE.CM-2: Monitoring systems (a detect control)
Secure HR Practice Control Domain
Definition: Performs background checks and ensures that people-related security practices (e.g., awareness training, policy enforcement) comply with laws and good practices.
Description: Maintains and follows HR and/or security policies and procedures for background checks, hiring, contracting, awareness programs, terminations, incident investigations, and disciplinary actions as they relate to security. Provides input on any policy or procedure, such as monitoring staff emails and communications for leakage, or controls on personally owned mobile devices.
Business dependencies: HR, security operations and monitoring, IAM, and international legal teams.
References:
NIST CSF:
PR.IP-11: Cybersecurity included in HR practices

6.3.4 Win the Race to Detect

In recent years, this saying emerged: “There are only two kinds of organizations: Those that have discovered a breach, and those that have been breached and don’t know it.” Cyberattackers can penetrate a business quickly; the 2019 Crowdstrike Global Threat Report10 found the progression from initial compromise to acting on the cyberattacker’s target often unfolds in minutes or hours. Against that, as we’ll describe in Chapter 9, the average time businesses take to detect intrusion may be measured in months.
One slip, and the business could experience a ransomware infestation during which attackers encrypt their data and throw away the key. Or, compromised end user devices and credentials could be used to steal sensitive data. Rapid detection of threats in the IT environment is critical.
Real-Time Threat Detection Control Domain
Definition: Detects hacking, malware, and abuse against IT systems, generates alerts to security monitoring systems, and triages alerts to enable effective response.
Description: Provides multiple layers of defense to detect and prevent hacking and malware threats to the IT environment. Deploys intrusion detection systems as well as endpoint and server-level malware scanning and removal. Combines technical, procedural, and educational controls against phishing, which is the most common malware delivery method for targeted cyberattacks. Interfaces to incident response capabilities to quarantine, contain, or block any malware found on endpoints. Provides enough skilled staff to configure and tune the products, perform investigations, and orchestrate responses, such as cleaning infected systems or temporarily quarantining compromised network segments. Operates security information and event management (SIEM) capabilities, or makes use of cloud-enabled ones, to correlate security events and apply machine learning (ML) to detect anomalies.
Business dependencies: IT teams, legal.
References: Chapter 9
NIST CSF references:
DE.CM-1, 4, 5, 7: Detect malware, unauthorized mobile code, suspicious network activity
DE.AE-4,5: Understand, process alerts
DE.DP: Detection processes (all controls)
DE.CM-6: Monitor external services
Logging and Log Review Control Domain
Definition: Generates and collects event logs of security-relevant information in keeping with security standards; reviews logs to detect threats or compromises of IT systems.
Description: Operates on endpoints, servers, applications, infrastructure systems, network devices, and security services themselves. Creates processes and acquires tools to monitor and review the log information. Provides skilled technical security staff to analyze logs using basic log management and collection tools to identify indicators of compromise from the mass of normal activity. May begin to operate a SIEM or other advanced tools to supplement real-time threat detection with log-based detection as well as to produce security reports for audit or trend analysis.
Business dependencies: IT and development teams, HR, legal, compliance.
References: Chapter 9
NIST CSF
PR.PT-1: Logging and log review
DE.AE-1, 2: Analyze logs to baseline normal activity and attacks
DE.AE-3: Collect and correlate log data from multiple sources
User Account Monitoring Control Domain
Definition: Monitors both standard user accounts and privileged user accounts for unauthorized, unusual, or suspicious activity.
Description: Monitors for common types of unusual user activity, such as multiple failed authentication attempts followed by access from an unexpected location. Complies with legal protections or work rules while performing the necessary monitoring, especially for privileged accounts, by combining technical, procedural, and educational controls.
Business dependencies: IAM, HR, legal, audit, compliance teams.
References: Chapters 7, 8
NIST CSF:
PR.AC 1, 4, 6, 7: Capture user and access management events
PR.PT-1: Audit logs collected per policy
DE.AE-1: Baseline normal account activity
DE.AE-3: Collect and correlate log data
DE.CM-1, 3, 7: Monitor networks, devices, personnel activity

6.3.5 Respond Effectively and Appropriately

Businesses must have the ability to take corrective action in response to detected attacks, vulnerabilities, and incidents. Effective response capabilities are the other side of the “detect” coin; they can often mitigate most of the damage from cyberattacks.
Incident Response Control Domain
Definition: Identifies and investigates all types of incidents, contains threats, eradicates malware or damaged configuration, recovers, and learns from the incidents.
Description: Provides a program to respond to incidents before breaches or other emergencies materialize. Enacts a set of response policies, plans, and processes that define what constitutes an incident, how each type of incident will be handled, and who is responsible for which activities. Provides technical capabilities and procedures to contain, investigate, and escalate incidents to executives and report them to external stakeholders such as customers, partners, regulators, law enforcement, and the general public.
Business dependencies: Executive stakeholders, IT, development and LOB leaders, HR, legal, compliance, vendor management, public relations teams, and any other stakeholders affected by incidents.
References: Chapter 9
NIST CSF
RS.RP-1: Response planning
RS.CO (communication): All controls
RS.AN (analysis): All controls
RS.MI (mitigation): All controls
RS.IM (improvement): All controls

6.3.6 Recover from Outages or Breaches

Businesses must be able to recover from outages to IT systems caused by operational errors, physical failures, or cyberattacks. In addition, serious data breaches or ransomware incidents require long-term recovery efforts to restore reputation, market position, or operational capabilities even after a hacking or malware threat has been contained and eradicated.
Backup and Data Recovery Control Domain
Definition: Backs up data, configuration, and code of IT assets in a secure manner and tests the ability to perform data recovery.
Description: Prepares for the loss of IT systems or data by taking data backups, designating warm or cold standby systems for use in the event of an outage. Tests recovery of user data, configuration, and entire systems. May arrange relationships with outsourced providers of redundant compute, storage, and network resources.
Business dependencies: Business continuity team, IT, development and LOB leaders, vendor management, and any other stakeholders affected by outages or data loss.
References: Chapter 9
NIST CSF:
PR.IP-4: Backups
RC.RP-1: Recovery plan executed
Business Continuity Control Domain
Definition: Identifies critical assets, creates procedures and facilities to recover their functionality within a specified time in the event of outage, and tests recovery.
Description: Provides basic business continuity processes to recover critical assets identified during a Business Impact Assessment (BIA). Prepares for the loss of IT systems or data by taking data backups, designating warm or cold standby systems for use in the event of an outage. Creates contingency plans and performs failover tests or other tests. Manages recovery from regulatory, legal, and reputational damage in the event of a breach of sensitive data. May arrange cyber-insurance and relationships with outsourced providers of redundant compute, storage, and network resources.
Business dependencies: Business continuity team, IT, development and LOB leaders, legal, vendor management, compliance teams, and any other stakeholders affected by outages or breaches.
References: Chapter 9
NIST CSF:
RC.RP-1: Recovery plan executed
RC.MI-1, 2: Recovery plan improvement

6.4 Develop Architectural Models and Plans for Control Implementation

For most organizations, the control baseline is a work in progress. Security leaders rarely have the luxury of starting over. Nor is the work ever done: New types of systems and applications constantly join and leave the IT environment, and many controls must be continuously improved or changed over time.
Establishing the control baseline across all control domains requires people and process as well as technology. Businesses must put governance structures in place to ensure that the controls get implemented correctly and to verify they’re operating correctly. They must also address shared responsibility models for controls operated across their own and third-party (e.g., cloud provider) environments.

6.4.1 Maintain Assessments, Target Architectures, and Implementation Road Maps

Businesses must create a road map for implementation and prioritize controls based on risk. Road maps, or implementation plans and schedules, should be guided by a target architecture.
If you don’t know where you’re going, any road will get you there.
Target architecture(s) can be developed for the entire control baseline, for individual control domains, or for crosscuts of the control domains. The architecture specifies the technical components and interfaces that implement control objectives. It must also identify people’s roles (such as users and administrators) in providing controls and the need for any processes or procedures covering the control activities (such as log review).
To produce a target architecture, security leaders should have a current security assessment. The security assessment should provide a control gap assessment aligned to a list of top information risks. Use the risk assessment and applicable regulatory requirements to identify control gaps. Use the control gap assessment to prioritize and inform the target architecture and more detailed design or requirements documents.
Using risk-informed target architecture recommendations, develop a road map for implementation. Periodically update risk and control gap assessments and maintain target architectures and road maps as living documents.

6.4.2 Use a Two or Three Lines of Defense Model for Control Assurance

To ensure controls are effective, security organizations must concern themselves not only with the strength of the controls but also the quality of implementation and rigor of operation. To provide assurance, most financial services and many businesses in other industries use a “three lines of defense” metamodel (combining architecture and governance) to verify and confirm controls as follows:
  • First line (implementation and operations): IT and development business process or system owners perform most day-to-day implementation and operations work. For example, business staff use on-premise SAP systems or cloud-based Salesforce services with support from IT operations and development.
  • Second line (security administration, monitoring, and assurance): Security staff can back up IT operations staff to provide assurance by defining, validating, or checking IT’s security procedures. Security staff also often operate security tools such as cloud access security brokers (CASBs) and key management services that exist solely for assurance. Security staff perform security monitoring, security design reviews, and penetration testing from the second line as well.
  • Third line (audit): Audit can provide an independent check on the implementation, operations, and assurance processes in the first and second lines. Often a combination of internal auditors and external auditors operates according to an annual or semiannual schedule. Internal audit should report outside of IT, often directly to a Board of Directors’ Audit Committee. External audit reports (such as an American Institute of Certified Public Accountants (AICPA) Service Organization Control 2 (SOC 2)11 report or a Payment Card Industry Data Security Standard (PCI DSS)12 report) are also reported to compliance stakeholders.
https://static-content.springer.com/image/chp%3A10.1007%2F978-1-4842-5952-8_6/MediaObjects/495216_1_En_6_Figd_HTML.jpg
6-2
Internal audit or compliance functions should sample security assurance (second line) as well as IT operations (first line) functions for deficiencies in meeting the business security policies. The security organization should assist internal audit in maximizing insight and efficiency in its process and partner with internal audit on executive reporting to help make audit findings actionable for stakeholders.

6.4.3 Apply a Shared Responsibility Model to the Control Baseline

As security leaders or architects select baseline controls, they must eventually bring the discussion down from the abstract control framework level to the individual services provided for different IT environments or use cases. When IT or security environments are operated by third parties, it’s helpful to have a shared responsibility framework that defines security requirements and evaluation criteria for different types of third parties, or third-party use cases, to improve control assurance.
Businesses increasingly depend on cloud service providers (CSPs) and other third parties to deliver IT capabilities. For example, if a customer hosts credit card processing on servers in the cloud and requires PCI DSS certification for them, the CSP must also be certified.
In general, there’s a common misconception that service providers will take care of customers’ security needs by default. After all, CSPs do offer user account management, logging, and other controls. Unfortunately for the customer, however, it can only outsource some of the responsibility for security to a CSP and little if any of the liability or accountability for breaches.
Security leaders and staff broadly recognize the need for a shared responsibility model (e.g., the Workday SaaS tool provides logging, but the customer must configure the logs, collect them, and review them). But to develop such a model, we can’t rely on control frameworks alone. We need to focus on what the business is doing with a third-party provided system (the “use case”) and then ask the following questions covering four perspectives on shared responsibility:
1.
What controls must the customer operate to secure the use case?
 
2.
What controls (or capabilities) should the third-party provide to the customer?
 
3.
How should the customer evaluate the general security posture of the third party to know whether to trust it?
 
4.
What controls that the third party is solely responsible for should customers most rigorously evaluate?
 
The shared responsibility arrangements are different depending on the type of third party. Table 6-2 identifies six types of third party use cases, customer dependencies for each one, and critical criteria to evaluate.
Table 6-2
Types of Third Parties
Type of Third Party
Inter-dependencies and Evaluation Criteria
Generic vendor, partner, or third party
The following third party evaluation criteria flow down the table, applying to all vendors or third parties. All vendors or third parties should be viable businesses, offer or agree to acceptable contractual terms, and provide a security program with their own controls that are commensurate to the risks of the use case. In general, every third party should provide secure HR services, security policy and awareness, incident response, and other controls for itself.
Commercial off-the-shelf (COTS) product vendor
Businesses deploy software or hardware products and rely on the vendor for secure software (or system) development, vulnerability management support, and training for the product.
Full-time contractor staffing providers
Some onshore or offshore professional services companies provide contractors for staff augmentation, and some engagements last months or years. These staff may be treated similarly to the customers’ own employees. As the staffing provider’s customer, the organization will be depending on the provider’s secure HR practices and user account management to validate staff are employees in good standing at the contractor organization. However, the customer organization must also provide user account management and authentication for the individual contractors’ use within the customer’s IT environments.
Software-as-a-service (SaaS) provider
SaaS CSPs provide turnkey applications on demand, such as Salesforce or Workday. Customers need the vendor to provide security for the full IT stack, but enable customer control of user account management for the customer’s staff, log review, and other application security features.
Platform-as-a-service (PaaS) provider
PaaS CSPs provide an application development and application platform environment on which customers can build, host, and run COTS or custom applications. Customer PaaS requirements are similar to the SaaS ones; however, the customer needs more control over application and data security features in the service.
Infrastructure-as-a-service (IaaS) provider
IaaS CSPs provide a compute virtualization and cloud storage environment on which customers can build, host, and run compute infrastructure and applications. Customers are responsible for all host-level security features in the guest OS.
Requirements and evaluation criteria for third parties also vary with the use cases and characteristics of partners or suppliers. For example, many products or services require vendors to connect into the customer network and troubleshoot problems or perform maintenance. Customers depend on the vendor to provide secure device configuration for vendor’s devices and identity and access management for the users. However, customers must provide remote access controls and perform their own real-time threat detection for the access.
Risk should also inform third-party management and the shared responsibility model. For example, a product or service designed to update real-time market prices and margin requirements for a financial services company needs more monitoring and control than a supplier of network cables and printers. Some organizations perform a quick risk assessment of the technology or service use case for a supplier and place it in a higher or lower tier with more or less controls and assurance requirements for it.
Shared responsibility means that some security controls must be operated solely by the third party and are out of the customer’s hands. Where risk warrants, customers need a way to verify that the third party has the controls. In some cases, customers send staff or consultants into third-party facilities to do a complete audit of their security posture against NIST, ISO, or other control frameworks. However, many suppliers (such as CSPs) tend to be unwilling to submit to site visits or any security oversight. Fortunately, standard audits such as SOC 2 exist for service providers that can make it unnecessary for customers to audit CSPs themselves. Instead, customers can obtain evidence of the CSP’s SOC 2 certification.
Although SOC 2 provides a defensible and pragmatic way to confirm a third party’s basic security hygiene, customers should look deeper under the covers when sharing responsibility with a third party for protecting critical business systems. If customers can’t perform third-party audits themselves, they should request and sign a nondisclosure agreement (NDA) for the detailed copy of the third party’s independent audit report. It may validate some of the third party’s security claims and/or provide findings where improvement or compensating controls are required.
For more information on managing third party CSP security, see the Chapter 7 Section “Manage Cloud Risk Through the Third-Party Management Program.” Readers can also obtain detailed CSP control frameworks, questionnaires, and other information from the Cloud Security Alliance’s Security Trust Assurance and Risk (STAR) program.13

6.4.4 Tune Controls to Security and Business Needs

The following guidance from Malcolm Harkins’ Managing Risk and Information Security14 is helpful in evaluating and implementing controls: “For a few years…I thought of information risk and security as a balancing act…But as my responsibilities grew…I realized that a balancing act was the wrong analogy. We could not start from a position of making trade-offs between risks and enablement, or between security and privacy. So I began using a different model…of optimizing what is really a multivariate equation of risk dynamic and business objectives in order to create solutions that are ‘tuned to target.’” The variables in Harkins’ control tuning model are
  • Risk and compliance
  • Cost and maintenance
  • Productivity and user experience
  • Market objectives
  • Customer needs
Security leaders can tune controls using the variables in this model. Given a risk scenario, security leaders may have a choice of mitigation strategies and controls to deal with it. Once controls are selected, they can be tuned to the desired deployment style by planning who, what, and how to implement and operate them while considering the variables in the control tuning model.
https://static-content.springer.com/image/chp%3A10.1007%2F978-1-4842-5952-8_6/MediaObjects/495216_1_En_6_Fige_HTML.jpg
6-3
Engage business and IT stakeholders who have a security-related role maintaining controls, are the business owners for assets protected by the controls, or whose operations or business objectives could be impacted by the controls. Tune control deployment style to their business needs and risks.
Finally, many controls must be changed or improved over time because neither the use case requirements nor the threats are static. For example, the growth in telecommuting and cloud computing over the years (and in 2020, with COVID-19) necessitated increased use of remote access. Also, more stringent privacy requirements and potential for abuse of facial recognition and other machine learning (ML)–enabled technologies have created the need for new privacy-enhancing controls and changed requirements for deploying existing controls.
In general, the massive volume of security events and the speed with which threats can compromise an IT environment put a premium on fully automated exploit blocking or ML-enabled detection controls that can keep up with the pace of threats at scale in many environments. Over time, security teams must evolve from “manual detect” to “automated protect” styles of control deployment. This will be required to keep up with adversaries while also minimizing “control friction” vis-à-vis the legitimate users of the protected technology and the controls themselves.

6.5 Scale and Align the Control Baseline

Different types of businesses need different controls scaled to the business culture and deployed at appropriate maturity levels. For any business, control implementation must be aligned to the business functions supporting security for the control.

6.5.1 Scale to Business Size, Type, and Industry

For a small business, the implementation of many controls will be less complex than for a large enterprise. There will be fewer business units, groups, roles, duplications of functions, required integrations, more simplified processes, and (in some jurisdictions) reduced regulatory requirements. However, the small business security team has fewer resources to deploy security controls and tends to require easier-to-use or deploy solutions than a larger business.
For example, small and medium-sized organizations under low security pressure could modify the control domains’ maturity requirements as follows:
  • Governance: Combine the security steering committee function with an IT steering committee or even a single executive staff meeting for all administrative decisions.
  • Security policies and awareness: A single security policy document might suffice. However, detailed technical procedures should still be in separate documents.
  • Access management: Smaller organizations may not require formal access request, access review, and access revocation processes.
  • Only use two lines of defense (omit internal audit)
  • Prefer simplified cloud-based solutions for
    • Real-time threat detection
    • Logging and log review
    • User account monitoring
    • Backup and data recovery
    • And other controls
On the other hand, a large decentralized business such as a multinational corporation with multiple subsidiaries requires added maturity in many areas and may even need more than one control baseline due to major divergences between multiple lines of business and regions. See Chapter 3’s section “Matrix Models.”
Also, medium or large organizations under high or very high security pressure should generally meet the maturity criteria in most or all control domains and in some cases exceed them. As mentioned in the “Address Common Challenges” section, high maturity procedural controls and/or privileged access management tools are a common requirement.
Small, medium, and large organizations with a relatively low level of complexity may be able to deploy controls universally to cover all assets. Organizations with high complexity and low maturity may need to compromise, applying many controls only to critical business assets at first.
Organizations with high levels of complexity and security pressure should prioritize efforts to reduce complexity. However, if the organization cannot further reduce complexity, deploying advanced automated assessment and detection solutions may be useful. Emphasize automated configuration and compliance assessment tools, third-party management services, security analytics and machine learning for real-time threat detection, and so on. Have processes that support, motivate, or require LOBs and IT teams to remedy deficiencies detected against the control baseline in their areas.
Other special vertical industry considerations apply. Application program interface (API) security is everything to high technology companies or CSPs with many exposed services. Software vendors and SaaS companies must put a higher emphasis on secure software development practices. Online retail companies with no brick-and-mortar stores could deemphasize physical security. High technology manufacturing companies, utilities, and transportation companies must improve their ability to provide security controls to IT/OT (operational technology) environments.

6.5.2 Align Control Deployment and Business Functions

Security programs, and even a minimum viable control baseline, have many points of alignment with the business. I went through the 20 control domains in the previous section and cross-referenced all the core business interdependencies to create Table 6-3. The table maps the business functions (other than those in the core security organization itself) to each control domain. Security leaders can use this information to identify which business functions they should engage with in the process of specifying control baseline requirements for each control domain.
Table 6-3
Master Table for Aligning Business Functions to Control Domains
Business Function
Control Domain Inter-Dependencies
Executive stakeholders
Security governance, risk management, security policy and awareness, incident response
LOB executives, leaders
Security governance, risk management, security policy and awareness, asset inventory, third-party management, incident response, backup and data recovery, and business continuity. Many other control domains also tend to have inter-dependencies on LOBs in organizations with decentralized security governance.
IT leaders or teams
Security governance, security policy and awareness, asset inventory, security zoning, authentication and user account management, access management and authorization, SCCM, data protection, vulnerability management, logging and log review, incident response, backup and data recovery, business continuity
CTO and/or development leaders or teams
Security governance, security policy and awareness, asset inventory, security zoning, authentication and user account management, access management and authorization, SCCM, data protection, SDLC, vulnerability management, logging and log review, incident response, backup and data recovery, business continuity
Business continuity team
Backup and data recovery, business continuity
Compliance and audit
Risk management, security zoning, authentication and user account management, access management, SCCM, data protection, vulnerability management, logging and log review, incident response, business continuity
Endpoint or mobile device management team
Security zoning, real-time threat detection
Enterprise risk management
Risk management
Facilities management
Physical security, business continuity
Human resources
Secure HR practices, user account monitoring, incident response
Internal marketing team
Security policy and awareness
IT asset management
Asset inventory
Legal team
Secure HR practices, logging and log review, user account monitoring, incident response, business continuity
Network management team
Security zoning
Procurement and/or vendor management
Third-party management, security zoning, access management and authorization, data protection, incident response, backup and data recovery
Public relations
Incident response
UAT team
Security policy and awareness
Security leaders shouldn’t be daunted by the size of the table; they will not need to implement all the controls and manage all the alignments at once. What is necessary is knowing which business leaders hold the leading roles for which business functions, to get to know those leaders and to include aligning with them in control implementation project plans as these come up for action in the security architecture road map.
https://static-content.springer.com/image/chp%3A10.1007%2F978-1-4842-5952-8_6/MediaObjects/495216_1_En_6_Figf_HTML.jpg 6-4
Identify the leaders for the various business functions as well as business or IT owners of critical assets. Assign informal relationship managers to them. For business functions with multiple control domain alignments, establish formal coordination forums or projects as the work content merits.

6.6 Call to Action

The core recommendation for security leaders from this chapter is to establish the control baseline as follows:
  • Select which control frameworks to reference based on your business’s industry and compliance requirements.
  • Put a minimum viable control baseline in place.
  • Select granular controls from the 20 major control domains and the NIST CSF model control categories.
  • Prioritize the granular controls based on risk.
  • Build two or three lines of defense into the control architecture.
  • Work with the business’s third-party management organization to apply shared responsibility models or concepts to third-party relationships.
  • Tune control deployment style to the business’s risk, risk appetite, culture, and functional requirements for the protected assets.
  • Seek to achieve a “Defined” maturity level or better in each control domain.
  • Align control deployment with the leaders of the business functions involved with the controls as well as with owners of critical assets.
  • Scale control deployment to the business’s type, size, and compliance requirements.
Action – Make a quick assessment of the organization’s control baseline
Ask yourself the following short set of questions and score the answers in the Success Plan Worksheet’s15 Section 3, Table 3. Base your score on whether you would answer most of the questions with a strong “no” (1), a strong “yes” (5), or something in between.
1.
Does the business have a “control framework” and/or a “control baseline” document that lists the control objectives for IT and the business?
 
2.
Does the security organization have published guidance mapping the control objectives to the required control activities for different levels of risk or different situations (e.g., data classifications, use of third-party services)?
 
3.
Is the control baseline mapped to requirements documents and solution architectures for critical operational systems in IT and security environments?
 
4.
Is the control baseline updated and followed?
 
5.
Do IT, security, or third-party management groups have a shared responsibility framework to aid in evaluating third-party services?
 
6.
Does an architecture document specify how the controls should be deployed?
 
7.
Does the business have an assurance or an audit function to verify controls are operating?
 
Action – Define 1–3 improvement objectives for the control baseline
Note improvement objectives in Section 4, Table 7, of the worksheet. The following are guidelines and examples of control baseline improvement objectives:
  • Evaluate the current control baseline document(s) to see if they can be used as is or as a draft starting point.
If the business requires a new or rewritten control baseline:
  • Create an initial detailed outline for a new control baseline using a spreadsheet or a governance, risk, and compliance (GRC) tool. Populate the draft using information from the 20 security control domains.
If a current and credible security assessment is not available:
  • Perform a rapid enterprise risk assessment16 based on the methodology from Chapter 5, section “Perform Enterprise Risk Assessments to Identity Top Risk Scenarios,” using available data to identify at least a rough list of top information risks.
  • Perform a control gap assessment against the control baseline and the list of top information risks. Depending on the size of the business, rapid or deep security assessments17 can be performed within a 30-, 60-, or 90-day period.
Don’t limit yourself to these examples. Also consider other improvement objectives that fit the gaps and priorities you’ve identified for your business.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Fußnoten
1
“NIST Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations,” NIST, April 16, 2018. Accessed at https://doi.org/10.6028/NIST.SP.800-53r4, April 2013
 
2
International Standard ISO/IEC 27001:2013 — Information technology — Security techniques — Information security management systems — Requirements (second edition), ISO/IEC, 2013
 
3
International Standard ISO/IEC 27002:2013 — Information technology — Security
techniques — Code of practice for information security controls, ISO/IEC, 2013
 
4
COBIT 5: A Business Framework for the Governance and Management of Enterprise IT, ISACA, 2012. Accessed at www.isaca.org/cobit/Pages/CobitFramework.aspx
 
5
CSA Cloud Controls Matrix v3.0.1, March 2019. Accessed at https://cloudsecurityalliance.org/research/cloud-controls-matrix/
 
6
“NIST Special Publication 800-171 Revision 1: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations,” NIST, December 2016, accessed at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r1.pdf
 
7
“CIS Controls V7,” Center for Internet Security, March 19, 2018. Accessed at www.cisecurity.org/controls/
 
8
“Framework for Improving Critical Infrastructure Cybersecurity Version 1.1,” National Institute of Standards and Technology, April 16, 2018. Accessed at www.nist.gov/cyberframework
 
9
“Zero Trust Networks,” Doug Barth, Evan Gilman, O’Reilly Media, Inc., July 2017, accessed at www.oreilly.com/library/view/zero-trust-networks/9781491962183/
 
10
“2019 Crowdstrike Global Threat Report: Adversary Tradecraft and the Importance of Speed,” Crowdstrike, March 2019, accessed at www.crowdstrike.com/resources/crowdcasts/2019-global-threat-report-crowdcast/
 
11
“SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy,” AICPA, March 2018, accessed at www.aicpastore.com/SOC/reporting-on-controls-at-a-service-organization-re/PRDOVR~PC-0128210/PC-0128210.jsp
 
12
“Payment Card Industry (PCI) Data Security Standard version 3.2.1,” PCI Standards Security Council, May 2018, accessed at www.pcisecuritystandards.org/document_library
 
13
“Cloud Security Alliance Security Trust Assurance and Risk (STAR),” Cloud Security Alliance, Accessed At: https://cloudsecurityalliance.org/star/
 
14
Managing Risk and Information Security: Protect to Enable, 2nd Edition, Malcolm Harkins, Apress Open, 2016
 
15
“Rational Cybersecurity Success Plan Worksheet,” Dan Blum, Security Architects LLC, May 2020, accessed at https://security-architect.com/SuccessPlanWorksheet
 
16
“Rapid Enterprise Risk Assessment,” Dan Blum, Security Architects LLC, January 2020, accessed at: https://security-architect.com/RiskManagementResources
 
17
“Security Assessments,” Dan Blum, Security Architects LLC, January 2020, accessed at: https://security-architect.com/SecurityAssessmentResources
 
Metadaten
Titel
Establish a Control Baseline
verfasst von
Dan Blum
Copyright-Jahr
2020
Verlag
Apress
DOI
https://doi.org/10.1007/978-1-4842-5952-8_6