Overview
- This chapter describes how to implement an enterprise cybersecurity program by
- organizing personnel;
- integrating cybersecurity into the IT system life cycle;
- defining security policies and scopes;
- selecting security controls and technologies; and
- considering overall security effectiveness.
- Procedural and technological capabilities
- Deliver the security controls needed to mitigate risks
- Can be organized into enterprise cybersecurity functional areas
- The graphic delineates the necessary elements needed for an effective enterprise cybersecurity program.
- Not only do these elements need to be well coordinated, but they also need to be integrated and work well together.
Topics
- IT Organization
- IT System Life Cycle
- Defining Security Policies
- Defining Security Scopes
- Identifying Security Scopes
- Selecting Security Controls
- Selecting Security Capabilities
- Selecting Security Technologies
- Considering Security Effectiveness
IT Organization
Context
- Organizing people is the first step in protecting an enterprise from cyberattacks.
- Organization has significant impacts that provide valuable information:
- What is easy to accomplish
- What is hard to accomplish
- Where the functions and disjunctions exist in an organization
- IT management frameworks suggest three major IT functions that often report to the Chief Information Officer (CIO):
- IT Architecture
- IT Engineering
- IT Operations
- Security sub-functions generally report to the Chief Information Security Officer (CISO).
- Risk Management
- Security Operations Center
- Cyber Incident Response Team
- Compliance
- The graphic depicts these functions and sub-functions (also known as teams or departments) in a notional organization chart.
Many Possible Reporting Relationships
- The CIO and CISO’s reporting relationship is a complex question with no one “correct” answer.
- In some organizations, the CIO and CISO are peers and both report to senior leadership.
- In other organizations, the CISO reports to the CIO.
- In yet other organizations, the CIO reports to the CISO.
- Each reporting arrangement has trade-offs in regard to how cybersecurity conflicts get escalated and at what level business decisions are made to accept cybersecurity risks or mitigate them in some manner.
Chief Information Officer (CIO)
- The CIO is the ultimate enterprise authority for IT and has authority over other IT functions.
- Sometimes, one or more of the subordinate functions is in a separate organization.
- There may be multiple CIO levels where each CIO has some authority over an organizational component.
- Multiple CIOs often have dotted-line relationships to an enterprise CIO with overall authority.
- IT Architecture
- Guides IT architecture and strategy
- Coordinates with other departments to align technology with the business
- Conducts multi-year planning
- Manages strategic vendor and technology relationships
- IT Engineering
- Designs, deploys, maintains, and retires enterprise technologies
- Is often separate from IT Operations to reduce costs and ensure accountability
- Introduces challenges in regard to staff agility and career progression with separation
- IT Operations
- Operates IT technologies cost-effectively using Service Level Agreements (SLAs)
- Frequently separated from engineering
- Does not provide agility to “design solutions on the fly” or respond quickly to changing situations
- Works well for managing operation costs, formalizing operational process, and achieving high levels of system reliability and stability
Chief Information Security Officer (CISO)
- The CISO is the ultimate enterprise authority for cybersecurity.
- Directs cybersecurity policy
- Oversees cybersecurity policy compliance
- Has a role throughout the IT system life cycle
- Has its own strategy, engineering, and operations activities
- Risk Management
- Evaluates assets, vulnerabilities, threats, and risks
- Defines policies to manage risks
- Engages with IT projects to identify and manage risks due to enterprise changes
- Security Operations Center (SOC)
- Involves operating security controls and services on an ongoing basis
- Maintains the security for the enterprise
- Identifies cyber incidents when they occur
- Cyber Incident Response Team
- Responds to cybersecurity incidents and supervises their investigation and remediation
- May employ outside experts for specialized skill sets
- Compliance
- Collects security infrastructure and operations artifacts that provide evidence the security controls and policies are operating as intended
- “Maps” the artifacts to external compliance requirements and regulatory standards to demonstrate enterprise compliance
IT System Life Cycle
- The graphic illustrates a notional IT life cycle.
- Adapted from Information Technology Infrastructure Library (ITIL)
- Indicates IT departments responsible for the stages
- Starts with Architecture and transitions to Design, Deploy, and so on.
- The IT system life cycle spans the stages systems go through during their lifetime.
- The Architect Stage involves
- selecting preferred vendors and applicable technological standards;
- developing long-term technology roadmaps and high-level system architectures;
- engaging the engineering department to ensure available technologies can work within the architectural guidelines; and
- staying engaged throughout the life cycle to monitor significant architectural changes that might impact technology roadmaps.
- The Design Stage involves
- turning the defined system architecture into a functional system design;
- defining business and technical requirements;
- working with vendors to get bids, evaluate proposals, and test technologies;
- determining the best balance of project cost, schedule, and performance;
- working with the security department to identify security requirements;
- conducting risk analysis for the new system or service; and
- specifying a “detailed design.”
- The Deploy Stage involves
- transforming the detailed design into a functioning system and deploying the system into an IT environment;
- issuing purchase orders to procure components or services;
- installing servers and software (if required);
- configuring components and services;
- creating “as-built” documentation, operating procedures, and manuals to get ready for operational use; and
- ensuring security configurations meet security requirements.
- The Operate Stage involves
- shaking out procedures and ensuring the system or service is performing as expected;
- meeting service-level agreements;
- managing and reducing operational costs over time;
- collecting extensive metrics to document the system or service costs and operations; and
- identifying opportunities for fine-tuning and streamlining over time.
- The Maintain Stage involves
- keeping the system or service operating at a steady-state level on an ongoing basis;
- making minor system or service changes, also known as enhancements; and
- patching, implementing routine upgrades, refreshing hardware, and updating vendor services.
- The Support Stage involves
- providing “warranty” service to address defects identified during system or service standup;
- supporting the system or service on an ongoing basis by addressing “problems” identified and formally documented by operations;
- analyzing problems, performing business analysis, and determining best engineering/business alternatives; and
- deferring or accepting alternatives given the enterprise priorities.
- The Retire Stage involves
- retiring the system or service at the end of its useful life because it is
- no longer needed;
- superseded by another capability;
- no longer cost-effective to operate; and
- no longer secure enough to meet organizational standards.
- consulting with all interested parties on the decision to retire system or service via a formal process; and
- updating enterprise records so that the retired system or service is “off the books.”
Defining Security Policies
- Security policies identify the assets to be protected and the protection afforded those assets:
- What is protected
- Who is responsible for the protection
- How well the protection is to be performed
- What the consequences are for protection failure
- Policies should be unambiguous, well-organized, well-maintained, and balanced between security and business needs.
- The graphic depicts the security documentation pyramid.
- Policy is a high-level statement of principle or course of action governing enterprise information security.
- Standards are documents specifying measures for behavior, processes, configurations, or technologies to be used for enterprise cybersecurity.
- Guidelines are documents providing non-authoritative guidance on policy and standards for use by subordinate organizations.
- Procedures are a set of documents describing step-by-step or detailed instructions for implementing or maintaining security controls.
- Baselines are specific configurations for technologies and systems designed to provide easy compliance with the established policy, standards, guidelines, and procedures.
Defining Security Scopes
Context
- NIST provides detailed guidance on performin g risk-management activities within the NIST Risk Management Framework (RMF ).
- The remainder of this chapter focuses on Step 1: CATEGORIZE Information Systems.
- According to NIST,“Conducting initial risk assessments brings together the available information on threat sources, threat events, vulnerabilities, and predisposing conditions—thus enabling organizations to use such information to categorize information and information systems based on known and potential threats to and vulnerabilities in organizational information systems and environments in which those systems operate. (NIST 800-30 rev 1)”
- The NIST risk management framework security life cycle provides a process for implementing an enterprise cybersecurity program.
- Practitioners interpret NIST’s guidance as applying to a single server or computer system.
- However, NIST’s guida nce can be applied at a higher level of abstraction where a single set of analysis is applied to entire sets of computers and their networks.
- This study guide refers to such a grouping of systems and networks as a security scope.
- Groups together assets and security controls around a common business impact caused by a common set of threats
- Is a collection of IT systems where the systems have similar risk profiles and share a common business impact due to a security incident
- IT defines a security scope by analyzing the security impact of a compromise or failure in regard to threats. IT also examines the corresponding business impact.
- Compromise of enterprise administrative systems might be in one security scope.
- Compromise of transaction processing systems might be in a different scope.
The Eight Types of Security Scopes
- The business impact is t he dominating factor when identifying security scopes.
- 1.A non-critical security scope is where none of the three security factors is critical and there is tolerance for failures of all three factors (for example, business administrative systems).
- 2.A confidentiality critical scope is where data needs to be protected from breach or disclosure, but integrity and availability are not major concerns (such as employee data).
- 3.An integrity critical scope is where data integrity is of concern, but confidentiality and availability are not major concerns (for instance, internal financial systems).
- 4.An availability critical scope is where systems need to be highly available, and confidentiality and integrity are not major concerns (such as public-facing web sites).
- 5.A confidentiality non-critical scope is where availability and integrity are critical, but confidentiality is not (for example, an enterprise directory).
- 6.An integrity non-critical scope is where confidentiality and availability are critical, but integrity is not (security scope is rarely used).
- 7.An availability non-critical scope is where confidentiality and integrity are critical, but availability is not (for example, customer account data where data must be carefully protected, but temporary outages are acceptable).
- 8.An all-factors critical scope is where CIA are all critical and there is little tolerance for failures (for example, online transaction processing systems such as Amazon.com).
- 1.
Considerations in Selecting Security Scopes
- Selecting security scopes is an approximate process.
- Factors other than confidentiality, integrity, and availability (CIA) factor into the process.
- Differing needs for CIA of systems and their data
- The business impact of a failure or breach
- Distinct patterns with regard to vulnerabilities, threats that exploit those vulnerabilities, and the probabilities and impacts of exploitations
- Production vs. non-production environments
- Most of these factors considered during NIST’s assessment process
- One of the most important considerations when conducting this analysis is to keep the analytical process at a high level and not too detailed.
- An enterprise of 1,000 servers shouldn’t have 1,000 security scopes; the enterprise should have between three and five scopes.
Identifying Security Scopes
Context
- Identifying security scop es establishes enterprise boundaries and compartments that are logical points for managing security.
- The general process for selecting security scopes can be reduced to the four steps shown in the graphic.
- This simplified process provides an enterprise with business statements that characterize the consequences of a breach, compromise, or failure.
- If these systems fail, our business will be unable to generate revenue.
- In the event of a breach, our customer data will be compromised and our entire business placed in jeopardy.
- In the event of a failure, our business support operations will be disrupted, driving up costs and making us less efficient.
- In the event of a failure, our security systems will be ineffective and unable to protect any of the rest of IT.
- As the enterprise considers these statements,
- it intuitively identifies systems with shared security postures that are commonly affected by a CIA breach; and
- it discerns how systems depend on each other, creating webs of interconnected systems that need to be treated similarly.
- The identification process is imperfect, the results will not be clear-cut, and the overall security design needs to address exceptions and gaps.
Security Scopes for the Typical Enterprise
- Many enterprises have approximately five security scopes to consider that cover their server, user, and security infrastructure environments.
- The graphic shows five typical security scopes that can be used as a starting point when identifying security scopes.
- Security and Systems Administration
- If an attacker gets control of an enterprise’s authentication, network security, system management, or other security infrastructure, the defense of the enterprise will experience “game over.”
- These systems are often shared across the entire enterprise and all systems to include customer-facing systems.
- This security scope needs to be secured at the same or higher level as all security scopes depending upon it.
- Business Support
- This scope contains systems supporting the business operation that do not directly generate revenue, such as e-mail, financial, and payroll systems.
- Consider a payroll system and a credit card processing system. What are the business impacts of systems going down?
- Payroll = people don’t get paid
- Credit card = enterprise cannot generate revenue
- These systems have different business impacts if they fail and consequently, may have different risk profiles and security scopes.
- Customer-Facing
- These systems are used to run the business.
- Without these systems the business is unable to generate revenue.
- In an e-commerce business, these systems can be the majority of IT.
- In a manual business, there may be only a few or even none of these systems.
- It is important to consider which IT systems result in an immediate loss of revenue and group them together into a security scope, if practical.
- Test and Non-Production
- These systems are the supporting systems that are critical in the long run, but non-critical in the short run.
- An enterprise looks at how these systems interact with production systems and weighs the benefits of simply putting them in the production security scope with its more stringent security vs. the benefits of having them in a lower-security environment.
- Enterprise needs to watch out for the “gotchas” that occur when non-production systems are part of the path-to-production or when they are handling copies of production data.
- Employee Computing
- If an enterprise allows its employees to surf the web from enterprise computers and receive e-mail from the Internet, then it is strongly recommended giving the employee computing its own security scope.
- The enterprise simply is not able to protect Internet-connected employees as well as the rest of the enterprise.
- If the enterprise allows those employees to interact with the other security scopes (for example, systems administration) from these computers, then the enterprise needs to engineer protections to ensure employee breaches cannot be exploited.
- Based on the enterprise analyses, enterprises can add or remove security scopes as appropriate.
Considerations in Selecting Security Scopes
- It is important to identify t he number of security scopes that is “just right.”
- Having few security scopes simplifies an enterprise’s security policy and engineering.
- Having more security scopes gives the enterprise fine-grained control over its security policies and their application to different parts of the enterprise.
- Some general guidance on balancing these factors and selecting scopes include the following:
- Systems must be well matched with the policy of the security scope in regard to confidentiality, integrity, and availability protections.
- It is OK for the scope’s security level to exceed the needs of a particular system in scope, but it is not acceptable for the system’s needs to exceed the security of the scope.
- Security policies are applied to all computers in a security scope at an approximately equal level.
- It must be practical and acceptable to apply the security policy to all systems in the scope, and available technology must make it possible to implement that policy today.
- The operational trade-offs of the security policy must be acceptable to most of the computers in the scope.
- If there are a lot of operational requirements for greater agility, less configuration control, or lower cost operation and the security trade-offs are acceptable, consider segmenting those systems off into a separate security scope with a more relaxed policy.
- Interfaces between scopes become logical points for segmentation within the enterprise, and such interfaces are both logical choke points for policy enforcement and also pote ntial attack vectors.
- Enterprise IT supporting computer systems bridge security scopes, and it is difficult to identify which scope such systems should reside in.
- Scopes have dependencies and connections where deliberate attacks can gain footholds in less-secure scopes and use these scopes to target more-secure scopes.
- Path-to-production systems are a common example of this phenomenon, especially when they host copies of production data.
- Security architecture nee ds to account for compensating controls to protect against these potential attack vectors.
- It is important to recognize the process is imperfect.
Selecting Security Controls
- Once the enterp rise selects its security scopes, the next step is to identify the controls needed in those scopes.
- Start by re-visiting enterprise assets and threats, and the attack sequence against those assets from the threats.
- The graphic shows the selected controls (forensic, audit, detective, preventive) disrupting the attack sequence.
- The selected controls enable the enterprise to investigate, document, detect, and block attacks while they are in progress.
- To select the best controls, the enterprise considers the attack sequence.
- A security controls completes a sentence that goes something like this:“When an attacker …, we respond by … ”
- When an attacker sends a user a malicious e-mail message, we respond by intercepting that message and preventing it from getting to our users.
- When an attacker attempts to steal administrator credentials, we respond by thwarting the theft by requiring two-factor authentication.
- When an attacker installs malware on a server, we respond by blocking unauthorized software using whitelisting.
- When an attacker attempts to control compromised internal resources, we respond by intercepting and blocking the malicious command and control network traffic.
- When an attacker follows the attack sequence, we respond by having detective controls that detect attack patterns and alert us to their presence so we can engage and defeat them.
- Security controls are designed in sequence so attacks
- leave a forensic trail;
- can be picked up by an audit;
- cause alerts that can be detected; and
- are blocked, where possible.
- Business analysis is used to help determine the level of control protection as not all attack activities warrant blocking.
- As much as possible, selected controls should generate a forensic log to be examined during an investigation.
- The enterprise’s goal is to give itself multiple opportunities to catch attackers and ensure any attack leaves a robust audit trail.
- Most important—if the enterprise blocks the attack with a preventive control, the enterprise wants to ensure it detects the attack first.
- Detection alerts the operation department that an attack is underway so the attack can be repelled before the attack is successful.
- Enterprises need to understand security is an “arms race.”
- Every control that detects or blocks an attack can possibly be circumvented or defeated.
- The overall goal is to have multiple opportunities to catch the attack so that individual controls do not have to be 100% successful to be effective.
Selecting Security Capabilities
- After building a libra ry of security controls, the next step is to select the capabilities the enterprise needs to implement those controls.
- Building a controls library and selecting capabilities is an iterative process.
- As capabilities are identified, new controls may also be identified.
- The goal is to capture and record the high-level relationships among the most important components, without getting buried in minutia.
- The graphic illustrates how the controls connect to the cybersecurity functional areas.
- As the enterprise identifies controls needed to disrupt the attack sequence, it should organize the supporting capabilities by functional areas.
- Functional areas
- help to manage and operate the controls and corresponding capabilities in a coherent manner; and
- should be approximately equal in importance in regard to the controls and capabilities contained in them, and their cybersecurity effectiveness.
- If the enterprise control design results in one or more functional areas being largely ignored, then there are probably controls missing that should be considered.
- Security capabilities should be examined in the following terms:
- Their deployment
- Their operating costs
- The potential impact the capabilities have on enterprise IT operations and productivity
- Some capabilities can supp ort multiple controls.
- Anti-virus capabilities can block malicious software and also alert when malicious software has been detected.
- It can be beneficial to consider forensic, audit, and detective controls before simply deploying preventive controls since detecting and investigating a targeted attack can be just as important as disrupting it.
- Security controls can be achieved through technological means or through procedural means.
- In many ways, the cheapest way to achieve a control on short notice is through a manual process that is consistently followed, not a sophisticated technology.
- Manual processes have issues, but they should not be discounted prematurel y.
Selecting Security Technologies
- Once an enterprise selects its security capabilities, the next step is to decide if the controls are achieved through procedural or technological means.
- Whether to use procedural or technological means to achieve security capabilities is a business decision.
- The graphic shows security controls and capabilities can potentially be achieved by technological or procedural means.
- If technological means are chosen, then the corresponding technologies need to be selected.
- Security practitioners tend to prefer technological capabilities.
- At the business level, the technology is largely irrelevant.
- It changes very quickly.
- All technology can be bypassed or defeated.
- Technological success hinges not so much on choosing the best technology as on choosing technology that is “good enough,” and then integrating it with other controls to compensate for when it fails or is defeated.
- Technology that is 99% effective
- is only marginally better than technology that is 90% effective if the enterprise has a way of catching the attackers who can defeat the technology; and
- is just as ineffective as technology that is 90% effective if an attacker figures out how to defeat it.
- Success is all about using combinations of capabilities and technologies to catch and defeat 100% of intrusions when they occur, not 90% or even 99%.
- Achieving this degree of success requires more than a single technology by itself.
- To achieve 100% success, it is important not to discount the power of procedural capabilities.
- People
- are still better than computers at recognizing malicious patterns when their occur; and
- are capable of having conversations with other people to figure things out.
- Even the best machine-learning technologies eventually rely on people to look at the pattern to determine if it is malicious or not.
- Do not discount the power of people to provide detection, investigation, and response.
Considering Security Effectiveness
- To determine security architecture eff ectiveness, the enterprise considers the overall attack domain and cyberattack threats against the enterprise security scopes.
- First attack
- Is not blocked by preventive controls or caught by detective controls
- Leaves a forensic trail
- Second attack
- Is not blocked by preventive controls or caught by detective controls
- Found during periodic security audits
- Includes many insider attacks
- Third attack
- Is not blocked by preventive controls
- Generates alerts on detective controls
- Needs defense to be a robust and timely incident response capability
- Fourth attack
- Is blocked by preventive controls and alerts on detective controls
- Generates forensic logs picked up during audits
- Requires defenses to be at their strongest because defenses not only block the attack but also alert defenders to what is going on
- Fifth attack
- Is blocked by preventive controls
- Does not alert on detective controls
- Generates forensic logs picked up during audits
- Is dangerous because attackers are blocked, but defenders are not alerted
- Gives attackers time to find ways around preventive controls before audits reveal them
- Sixth attack
- Is blocked by preventive controls and generates forensic logs
- Not detected by detective controls
- Not picked up in security audits
- Is dangerous because attackers are blocked, but defenders are not alerted
- Seventh attack
- Is blocked by preventive controls, but is otherwise not detected
- Includes many attacks against Internet-facing firewalls due to the sheer volume of firewall logs generated and the challenges in retaining those logs
- Is vital to ensure these types of attacks, when they get past preventive controls, are blocked and detected by other controls further inside the defensive perimeter
- Eighth attack
- Is not blocked and is not detected
- Is most dangerous since attackers succeed without leaving a trace
- Is important that defenses are designed with redundancy so this attack’s success is not fatal to the enterprise
- These attack scenarios show that the overall security posture comes down to how much of the potential attack domain falls into each of these eight scenarios.
- A weak defense allows many attacks to succeed, while a good defense thwarts many attacks.
- An important objective of an enterprise’s defense is to maximize the number of attack scenarios that are blocked, detected, audited, and logged while reducing the number of successful attack scenarios that are not stopped or detected.
- Less effective security covers a smaller portion of the potential attack domain with preventive, detective, audit, and forensic controls.
- More effective security covers a larger portion of the potential attack domain.
- The enterprise can use this risk analysis process to drive the control design process.
- The enterprise can try to envision attack scenarios where attackers defeat its preventive controls without being detected.
- Often such attacks are insider attacks and credential abuse.
- Enterprise defense architectures often assume credentialed users on internal network are legitimate users and not attackers.
- Experience has shown internal attacks are the most difficult type of attacks to detect and defeat.