CISSP ALL-IN-ONE-9e Cap 4.pdf

Frameworks CHAPTER 4 This chapter presents the following: Overview of frameworks Risk frameworks Infor...

Frameworks CHAPTER 4 This chapter presents the following: Overview of frameworks Risk frameworks Information security frameworks Enterprise architecture frameworks Other frameworks You can’t build a great building on a weak foundation. —Gordon B. Hinckley The previous chapters have covered a lot of material dealing with governance, risk, and compliance. By now, you may be asking yourself, “How does this all fit together into an actionable process?” This is where frameworks come to the rescue. You can think of a framework as a strong foundation on which to build whatever it is you’re trying to build, whether it’s a risk management program or security controls. A framework gives you just enough rigidity to keep your effort from collapsing under its own weight, but still gives you a lot of leeway so that you can customize the framework to your particular situation. While it is possible (though very difficult) to build successful programs all by yourself, why reinvent the wheel when you can leverage the hard-earned lessons of other experts in the field? In this chapter, we will discuss a variety of frameworks that you are likely to encounter both in your job and when taking the CISSP exam. We divide them into three groups: risk frameworks, information security frameworks, and enterprise architecture frameworks. Risk management enables any successful information security program, so we’ll tackle those two groups in that order, followed by enterprise architecture frameworks. We’ll then round out our discussion with the other frameworks and concepts that you should know. Overview of Frameworks A framework is a basic structure underlying a system, concept, or text. So the purpose of frameworks in IT and cybersecurity is to provide structure to the ways in which we man- age risks, develop enterprise architectures, and secure all our assets. Think of frameworks as the consensus of many great minds on how we should approach these issues. 171 CISSP All-in-One Exam Guide 172 As you will see in the following sections, various for-profit and nonprofit organizations have developed their own frameworks for risk management, security programs, security controls, process management, and enterprise development. We will examine their similarities and differences and illustrate where each is used within the industry. The following is a basic breakdown. Risk: NIST RMF The Risk Management Framework, developed by the National Institute of Standards and Technology, is composed of three interrelated NIST Special Publications (SPs): 800-39, 800-37, and 800-30. ISO/IEC 27005 Focused on risk treatment, this joint International Organization for Standardization/International Electrotechnical Commission framework is best used in conjunction with ISO/IEC 27000 series standards. OCTAVE The Operationally Critical Threat, Asset, and Vulnerability Evaluation framework, developed at Carnegie Mellon University, is focused on risk assessment. FAIR The FAIR Institute’s Factor Analysis of Information Risk framework focuses on more precisely measuring the probabilities of incidents and their impacts. Security Program: ISO/IEC 27000 series This is a series of international standards on how to develop and maintain an information security management system (ISMS), developed by ISO and IEC. NIST Cybersecurity Framework Driven by the need to secure government systems, NIST developed this widely used and comprehensive framework for risk-driven information security. Security Controls: NIST SP 800-53 This NIST publication provides a catalog of controls and a process for selecting them in order to protect U.S. federal systems. CIS Controls The Center for Internet Security (CIS) Controls framework is one of the simplest approaches for companies of all sizes to select and implement the right controls. COBIT 2019 This is a business framework to allow for IT enterprise management and governance that was developed by ISACA. Enterprise Architecture: Zachman Framework This is a model for the development of enterprise architectures, developed by John Zachman. TOGAF The Open Group Architecture Framework is a model and methodology for the development of enterprise architectures.  Chapter 4: Frameworks 173 DoDAF The U.S. Department of Defense Architecture Framework was developed to ensure interoperability of systems to meet military mission goals. PART I SABSA The Sherwood Applied Business Security Architecture model and methodology for the development of information security enterprise architectures was developed by the SABSA Institute. NOTE Chapter 1 already discussed the SABSA model. Risk Frameworks By combining the definition of a framework in the previous section with our definition of risk management in Chapter 2, we can define a risk management framework (RMF) as a structured process that allows an organization to identify and assess risk, reduce it to an acceptable level, and ensure that it remains at that level. In essence, an RMF is a structured approach to risk management. As you might imagine, there is no shortage of RMFs out there. What is important to you as a security professional is to ensure your organization has an RMF that works for you. That being said, there are some frameworks that have enjoyed widespread success and acceptance. You should at least be aware of these, and ideally adopt (and perhaps modify) one of them to fit your organization’s particular needs. We’ll cover the NIST RMF in more detail, mostly to familiarize you with the components of this framework, but also because it is the one you are most likely to encounter in your career. NIST RMF The NIST Risk Management Framework (RMF) is described in three core interre- lated Special Publications (there are other key publications specific to individual steps of the RMF): SP 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations SP 800-39, Managing Information Security Risk SP 800-30, Revision 1, Guide for Conducting Risk Assessments This framework incorporates the key elements of risk management that you should know as a security professional. It is important to keep in mind, however, that it is geared toward federal government entities and may have to be modified to fit your own needs. The NIST RMF outlines the seven-step process shown in Figure 4-1, each of which will be addressed in turn in the following sections. It is important to note that this is a never-ending cycle because our information systems are constantly changing. Each change needs to be analyzed to determine whether it should trigger another trip around the loop. CISSP All-in-One Exam Guide 174 Figure 4-1 The NIST Risk CATEGORIZE Management Framework process MONITOR SELECT PREPARE Process initiation AUTHORIZE IMPLEMENT ASSESS Prepare The first step is to ensure that the top executives and the senior leaders (at both the strategic and operational levels) are in sync across the organization. This includes agreeing on roles, priorities, constraints, and risk tolerance. Another key activity during the prepare step is to conduct an organizational risk assessment that provides a common point of reference for the entire team to communicate about strategic risks. One of the outcomes of this assess- ment is the identification of high-value assets, on which the entire effort will be focused. Categorize The next step is to categorize your information systems based on criticality and sensitiv- ity of the information to be processed, stored, or transmitted by those systems. The idea is to create categories for your systems based on how important they are so that you can prioritize your defensive resources. All U.S. government agencies are required to use the following NIST SP 800-60 documents for this purpose: Volume I: Guide for Mapping Types of Information and Information Systems to Security Categories and Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories. NIST SP 800-60 applies sensitivity and criticality to each security objective (confidentiality, integrity, and availability) to determine a system’s criticality. For example, suppose you have a customer relationship management (CRM) system. If its confidentiality were to be compromised, this would cause significant harm to your company, particularly if the information fell into the hands of your competitors. The system’s integrity and availability, on the other hand, would probably not be as critical to your business, so they would be classified as relatively low. The format for describing the security category (SC) of this CRM would be as follows: SCCRM = {(confidentiality, high),(integrity, low),(availability, low)} SP 800-60 uses three SCs: low impact, moderate impact, and high impact. A low- impact system is defined as an information system in which all three of the security objectives are low. A moderate-impact system is one in which at least one of the security  Chapter 4: Frameworks 175 objectives is moderate and no security objective is greater than moderate. Finally, a high-impact system is an information system in which at least one security objective PART I is high. This method of categorization is referred to as the “high water mark” because it uses the highest security objective category to determine the overall category of the system. In our example, the SC of the CRM system would be high because at least one objective (confidentiality) is rated high. Select Once you have categorized your systems, it is time to select, and quite possibly tailor, the controls you will use to protect them. The NIST RMF defines three types of security controls: common, system-specific, and hybrid. A common control is one that applies to multiple systems and exists outside of their individual boundaries. Following our CRM example, if you placed a web application firewall (WAF) in front of the CRM (and in front of all your other web applications), that would be an example of a common control. The WAF is outside the system boundary of the CRM and protects it and other systems. System-specific controls, on the other hand, are implemented within the system boundary and, obviously, protect only that specific system. The system owner, and not the broader organization, is responsible for these. An example would be a login page on the CRM that forces the use of Transport Layer Security (TLS) to encrypt the user credentials. If the authentication subsystem was an integral part of the CRM, then this would be an example of an application-specific control. Wouldn’t it be wonderful if everything was black or white, true or false? Alas, the real world is much messier than that. Oftentimes, controls blur the line between common and system-specific and become something else. A hybrid control, according to the NIST RMF, is one that is partly common and partly system-specific. Continuing our CRM example, a hybrid control could be security awareness training. There would be a common aspect to the training (e.g., don’t share your password) but also some system- specific content (e.g., don’t save your customers’ information and e-mail it to your personal account so that you can reach out to them while you’re on vacation). The specific controls required to mitigate risks to acceptable levels are documented in the NIST control catalog, NIST SP 800-53, Revision 5, Security and Privacy Controls for Information Systems and Organizations. We’ll discuss this publication later in this chapter, but for now it is worth noting that it provides a mapping between the impact categories we assigned to information systems in the categorize step of this RMF and specific controls that mitigate risks to those systems. Implement There are two key tasks in this step: implementation and documentation. The first part is very straightforward. For example, if you determined in the previous step that you need to add a rule to your WAF to filter out attacks like Structured Query Language (SQL) injection, you implement that rule. Simple. The part with which many of us struggle is the documentation of this change. The documentation is important for two obvious reasons. First, it allows everyone to understand what controls exist, where, and why. Have you ever inherited a system that is configured in a seemingly nonsensical way? You try to understand why certain parameters CISSP All-in-One Exam Guide 176 or rules exist but hesitate to change them because the system might fail. Likely, this was the result of either improper documentation or (even worse) a successful attack. The second reason why documentation is important is that it allows us to fully integrate the controls into the overall assessment and monitoring plan. Failing to do this invites having controls that quietly become obsolete and ineffective over time and result in undocumented risks. Assess The security controls we implement are useful to our overall risk management effort only insofar as we can assess them. It is absolutely essential to our organizations to have a comprehensive plan that assesses all security controls (common, hybrid, and system- specific) with regard to the risks they are meant to address. This plan must be reviewed and approved by the appropriate official(s), and it must be exercised. To execute an assessment plan, you will, ideally, identify an assessor who is both competent and independent from the team that implemented the controls. This person must act as an honest broker that not only assesses the effectiveness of the controls but also ensures the documentation is appropriate for the task. For this reason, it is important to include all necessary assessment materials in the plan. The assessment determines whether or not the controls are effective. If they are, then the results are documented in the report so that they are available as references for the next assessment. If the controls are not effective, then the report documents the results, the remediation actions that were taken to address the shortcomings, and the outcome of the reassessment. Finally, the appropriate security plans are updated to include the findings and recommendations of the assessment. NOTE An assessment of security controls is also called an audit. We discuss audits in detail in Chapter 18. Authorize As we already discussed, no system is ever 100 percent risk-free. At this stage in the RMF, we present the results of both our risk and controls assessments to the appropriate decision- maker in order to get approval to connect our information system into our broader archi- tecture and operate it. This person (or group) is legally responsible and accountable for the system while it is operating, and therefore must make a true risk-based decision to allow the system to operate. This person determines whether the risk exposure is acceptable to the organization. This normally requires a review of a plan of action that addresses how and when the organization will deal with the remaining weaknesses and deficiencies in the information system. In many organizations this authorization is given for a set period of time, which is usually specified in a plan of action and milestones (POAM or POA&M). Monitor These milestones we just mentioned are a key component of the monitoring or continu- ous improvement stage of the RMF. At a minimum, we must periodically look at all our controls and determine whether they are still effective. Has the threat changed its tactics, techniques, and procedures (TTPs)? Have new vulnerabilities been discovered? Has an  Chapter 4: Frameworks 177 undocumented or unapproved change to our configuration altered our risk equations? These are only some of the issues that we address through ongoing monitoring and con- PART I tinuous improvement. ISO/IEC 27005 ISO/IEC 27005, updated in 2018, is another widely used information security risk management framework. Similar to the NIST RMF we just discussed, ISO/IEC 27005 provides guidelines for information security risk management in an organization but does not dictate a specific approach for implementing it. In other words, the framework tells us what sorts of things we ought to do, but not how to do them. Similarly to how the NIST RMF can be paired with the security controls in NIST SP 800-53, ISO/IEC 27005 is best used in conjunction with ISO/IEC 27001, which, as we’ll see shortly, pro- vides a lot more structure to information security program development. The risk management process defined by ISO/IEC 27005 is illustrated in Figure 4-2. It all starts with establishing the context in which the risks exist. This is similar to the Figure 4-2 ISO/IEC 27005 risk management process CONTEXT ESTABLISHMENT RISK ASSESSMENT RISK ANALYSIS RISK IDENTIFICATION RISK MONITORING AND REVIEW RISK COMMUNICATION RISK ESTIMATION RISK EVALUATION RISK DECISION POINT 1 No Assessment satisfactory Yes RISK TREATMENT RISK DECISION POINT 2 No Treatment satisfactory Yes RISK ACCEPTANCE END OF FIRST OR SUBSEQUENT ITERATIONS CISSP All-in-One Exam Guide 178 business impact analysis (BIA) we discussed in Chapter 2, but it adds new elements, such as evaluation criteria for risks as well as the organizational risk appetite. The risk assessment box in the middle of the figure should look familiar, since we also discussed this process (albeit with slightly different terms) in Chapter 2. The risk treatment step is similar to the NIST RMF steps of selecting and implementing controls but is broader in scope. Rather than focusing on controls to mitigate the risks, ISO/IEC 27005 outlines four ways in which the risk can be treated: Mitigate the risk by implementing controls that bring it to acceptable levels. Accept the risk and hope it doesn’t realize, which assumes that the impact of this risk is less than the cost of treating it. Transfer the risk to another entity such as an insurance company or a business partner. Avoid the risk by not implementing the information system that brings it, or by changing business practices so the risk is no longer present or is reduced to acceptable levels. NOTE The NIST RMF also briefly touches on these treatments in the authorize step of its process. Risk acceptance in ISO/IEC 27005 is very similar to the authorize step in the NIST RMF, and the risk monitoring steps in both are very similar. A notable difference between these two RMFs, on the other hand, is that ISO/IEC 27005 explicitly identifies risk communication as an important process. This is an essential component of any risk management methodology, since we cannot enlist the help of senior executives, partners, or other stakeholders if we cannot effectively convey our message to a variety of audiences. Just because this communication is not explicitly called out in the NIST RMF or any other RMF, however, doesn’t decrease its importance. As you can see, this framework doesn’t really introduce anything new to the risk conversation we’ve been having over the last two chapters; it just rearranges things a bit. Of course, despite these high-level similarities, the two risk-based frameworks we’ve discussed differ in how they are implemented. For best results, you should combine ISO/ IEC 27005 risk management with an ISO/IEC 27001 security program. OCTAVE The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) is not really a framework per se. Rather, it is a methodology for risk assessments developed at Carnegie Mellon University. So, while it falls short of a framework, it is fairly com- monly used in the private sector. As a cybersecurity professional, you really should be aware of it and know when it might come in handy. OCTAVE is self-directed, meaning that it uses a small team of representatives of IT and the business sides of the organization to conduct the analysis. This promotes  Chapter 4: Frameworks 179 collaboration on identifying risks and facilitates communication with business leaders on those risks. It also follows the approach of focusing on the most critical assets in risk PART I analysis to prioritize areas of attention. OCTAVE follows the 80/20 Pareto principle, which states that 80 percent of the consequences come from 20 percent of the causes. This highlights one of the key benefits of this methodology, which is its focus on speed based on the fact that, for most businesses, time is money. This risk assessment methodology is divided into three phases. The first is an organizational view, in which the analysis team defines threat profiles based on assets that are critical to the business. The second phase then looks at the organization’s technology infrastructure to identify vulnerabilities that might be exploited by those threats. Finally, in the third phase, the team analyses and classifies individual risks as high, medium, or low and then develops mitigation strategies for each. This classification scheme belies one of the advantages or drawbacks (depending on your perspective) of OCTAVE: it is fundamentally a qualitative approach to assessing risks. FAIR If you want to apply a more rigorous, quantitative approach to managing risk, you may want to read up on the Factor Analysis of Information Risk (FAIR), which is a propri- etary framework for understanding, analyzing, and measuring information risk. In fact, if you want a quantitative approach, this is pretty much the only international standard framework you can use. Recall that a quantitative approach is one in which risks are reduced to numbers (typically monetary quantities), while a qualitative approach uses categories of risks such as low, medium, and high. The main premise of FAIR is that we should focus not on possible threats but on probable threats. Thus, its quantitative nature makes a lot of sense. In this framework, risk is defined as the “probable frequency and probable magnitude of future loss,” where loss can be quantified as lost productivity, costs of replacement or response, fines, or competitive advantage. Note that each of these can be reduced (perhaps with a bit of work) to monetary quantities. If this approach appeals to you, consider it in conjunction with the discussion of quantitative risk assessment in Chapter 2. Information Security Frameworks Armed with the knowledge gained from the risk management frameworks, we are now ready to properly secure our information systems. After all, our main goal is to develop cost- effective defenses that enable our organizations to thrive despite the risks they face. For this reason, most information security frameworks have an explicit tie-in to risk management. Broadly speaking, information security frameworks can be divided into two categories: those that look holistically at the entire security program, and those that are focused on controls. These are not mutually exclusive, by the way. As we will see, the NIST Cybersecurity Framework is compatible with the NIST SP 800-53 controls. Nor do information security frameworks have to be implemented in a wholesale manner. This is, after all, the beauty of frameworks: we get to pick and choose the parts that make the most sense to us and then tailor those to our specific organizational needs. CISSP All-in-One Exam Guide 180 Security Program Frameworks Let’s start at the top. A security program is made up of many components: logical, administrative, and physical protection mechanisms (i.e., controls); procedures; business processes; and people. These components all work together to provide a protection level for an environment. Each has an important place in the framework, and if one is missing or incomplete, the whole framework may be affected. The program should work in lay- ers: each layer provides support for the layer above it and protection for the layer below it. Because a security program is a framework, organizations are free to plug in different types of technologies, methods, and procedures to accomplish the necessary protection level for their environment. A security program based upon a flexible framework sounds great, but how do we build one? Before a fortress is built, the structure is laid out in blueprints by an architect. We need a detailed plan to follow to properly build our security program. Thank goodness industry standards have been developed just for this purpose. Let’s take a closer look at two of the most popular information security program frameworks: the ISO/IEC 27000 series and the NIST Cybersecurity Framework. ISO/IEC 27000 Series The International Organization for Standardization (ISO) and the International Electro- technical Commission (IEC) 27000 series serves as industry best practices for the man- agement of security controls in a holistic manner within organizations around the world. The list of standards that makes up this series grows each year. Collectively, these stan- dards describe an information security management system (ISMS), but each standard has a specific focus (such as metrics, governance, auditing, and so on). The currently published ISO/IEC 27000 series of standards (with a bunch of them omitted) include the following: ISO/IEC 27000 Overview and vocabulary ISO/IEC 27001 ISMS requirements ISO/IEC 27002 Code of practice for information security controls ISO/IEC 27003 ISMS implementation guidance ISO/IEC 27004 ISMS monitoring, measurement, analysis, and evaluation ISO/IEC 27005 Information security risk management ISO/IEC 27007 ISMS auditing guidelines ISO/IEC 27014 Information security governance ISO/IEC 27017 Security controls for cloud services ISO/IEC 27019 Security for process control in the energy industry ISO/IEC 27031 Business continuity ISO/IEC 27033 Network security ISO/IEC 27034 Application security ISO/IEC 27035 Incident management  Chapter 4: Frameworks 181 ISO/IEC 27037 Digital evidence collection and preservation ISO/IEC 27050 Electronic discovery PART I ISO/IEC 27799 Health organizations It is common for organizations to seek an ISO/IEC 27001 certification by an accredited third party. The third party assesses the organization against the ISMS requirements laid out in ISO/IEC 27001 and attests to the organization’s compliance level. Just as (ISC)2 attests to information security professionals’ knowledge once they pass the CISSP exam, the third party attests to the security practices within the boundaries of the organization it evaluates. It is useful to understand the differences between the ISO/IEC 27000 series of standards and how they relate to each other. Figure 4-3 illustrates the differences between general requirements, general guidelines, and sector-specific guidelines. EXAM TIP You don’t have to memorize the entire ISO/IEC 27000 series of standards. You just need to be aware of them. As you probably realize, ISO 27001 is the most important of these standards for most organizations. It is not enough to simply purchase the document and implement it in your environment; you actually need an external party (called a Certification Body) to audit you and certify that you are in compliance with the standard. This ISO 27001 certification is useful to demonstrate to your customers and partners that you are not a security risk to them, which in some cases can be a contractual obligation. Additionally, Figure 4-3 27001 General Requirements How ISO/IEC ISMS Requirements 27000 standards relate to each What is an ISMS? other What must it do? 27002 General Guidelines Code of Practice How should an ISMS provide information security? 27011 Sector- 27799 ISMS Guidelines for Specific Health Informatics - Telecommunications Guidelines ISMS in Health Organizations How should an ISMS How should an ISMS provide information security provide information in a telecommunications security in a health sector organization? services organization? CISSP All-in-One Exam Guide 182 this certification can help avoid regulatory fines by proving that the organization practices due diligence in protecting its information systems. The certification process can take a year or longer (depending on how mature your security program is), but for many medium and large business, it is worth the investment. NIST Cybersecurity Framework On February 12, 2013, U.S. President Barack Obama signed Executive Order 13636, call- ing for the development of a voluntary cybersecurity framework for organizations that are part of the critical infrastructure. The goal of this construct was for it to be flexible, repeat- able, and cost-effective so that it could be prioritized for better alignment with business processes and goals. A year to the day later, NIST published the “Framework for Improv- ing Critical Infrastructure Cybersecurity,” commonly called the Cybersecurity Framework, which was the result of a collaborative process with members of the government, industry, and academia. The Cybersecurity Framework is divided into three main components: Framework Core Consists of the various activities, outcomes, and references common to all organizations. These are broken down into five functions, 22 categories, and 98 subcategories. Implementation Tiers Categorize the degree of rigor and sophistication of cybersecurity practices, which can be Partial (tier 1), Risk Informed (tier 2), Repeatable (tier 3), or Adaptive (tier 4). The goal is not to force an organization to move to a higher tier, but rather to inform its decisions so that it can do so if it makes business sense. Framework Profile Describes the state of an organization with regard to the Cybersecurity Framework categories and subcategories. A Framework Profile enables decision-makers to compare the “as-is” situation to one or more “to-be” possibilities, so that they can align cybersecurity and business priorities and processes in ways that make sense to that particular organization. An organization’s Framework Profile is tailorable based on the requirements of the industry segment within which it operates and the organization’s needs. The Framework Core practices organize cybersecurity activities into five higher-level functions with which you should be familiar. Everything we do can be aligned with one of these: Identify Understand your organization’s business context, resources, and risks. Protect Develop appropriate controls to mitigate risk in ways that make sense. Detect Discover in a timely manner anything that threatens your security. Respond Quickly contain the effects of anything that threatens your security. Recover Return to a secure state that enables business activities after an incident.  Chapter 4: Frameworks 183 EXAM TIP For the exam, you should remember the five functions of the NIST Cybersecurity Framework and the fact that it is voluntary. PART I Security Control Frameworks Up to now we have reviewed the ISO/IEC 27000 series and the NIST CSF, both of which outline the necessary components of an organizational security program. Now we are going to get more focused and look at the objectives of the controls we are going to put into place to accomplish the goals outlined in our security program and enterprise architecture. This is where security control frameworks come in handy. This section pres- ents three popular frameworks: NIST SP 800-53, CIS Controls, and COBIT. NIST SP 800-53 One of the standards that NIST has been responsible for developing is SP 800-53, Secu- rity and Privacy Controls for Information Systems and Organizations, currently in its fifth revision (Rev. 5). It outlines controls that agencies need to put into place to be compli- ant with the Federal Information Processing Standards (FIPS). It is worth noting that, although this publication is aimed at federal government organizations, many other organizations have voluntarily adopted it to help them better secure their systems. Basically, SP 800-53 provides specific guidance on how to select security controls. It prescribes a four-step process for applying controls: 1. Select the appropriate security control baselines. 2. Tailor the baselines. 3. Document the security control selection process. 4. Apply the controls. The first step assumes that you have already determined the security categories (SCs) of your information systems based on criticality and sensitivity of the information to be processed, stored, or transmitted by those systems. SP 800-53 uses three SCs: low impact, moderate impact, and high impact. If this sounds familiar, that’s because we discussed this categorization earlier in this chapter when we covered the NIST RMF and SP 800-60. This exercise in categorizing your information systems is important because it enables you to prioritize your work. It also determines which of the more than 1,000 controls listed in SP 800-53 you need to apply to it. These controls are broken down into 20 families. Table 4-1 outlines the control categories that are addressed in SP 800-53, Rev. 5. Let’s circle back to the example of the customer relationship management system we used when discussing the NIST RMF. Recall that we determined that the CRM’s SC was high because the impact of a loss of confidentiality was high. We can go through the entire catalog of controls and see which of them apply to this hypothetical CRM. In the CISSP All-in-One Exam Guide 184 ID Family ID Family AC Access Control PE Physical and Environmental Protection AT Awareness and Training PL Planning AU Audit and Accountability PM Program Management CA Assessment, Authorization, and PS Personnel Security Monitoring CM Configuration Management PT PII Processing and Transparency CP Contingency Planning RA Risk Assessment IA Identification and Authentication SA System and Services Acquisition IR Incident Response SC System and Communications Protection MA Maintenance SI System and Information Integrity MP Media Protection SR Supply Chain Risk Management Table 4-1 NIST SP 800-53 Control Categories interest of brevity, we will only look at the first three controls (IR-1, IR-2, and IR-3) in the Incident Response, or IR family. You can see in Table 4-2 how these controls apply to the different SCs. Since the CRM is SC high, all three controls are required for it. You can also see that IR-2 and IR-3 have control enhancements listed. Let’s dive into the first control and see how we would use it. Chapter 3 of SP 800-53 is a catalog that describes in detail what each security control is. If we go to the description Control Baselines Control Name Control No. CONTROL ENHANCEMENT NAME Low Mod. High IR-1 Policy and Procedures X X X IR-2 Incident Response Training X X X IR-2(1) Simulated Events X IR-2(2) Automated Training Environments X IR-2(3) Breach IR-3 Incident Response Testing X X IR-3(1) Automated Testing IR-3(2) Coordination with Related Plans X X Table 4-2 Sample Mapping of Security Controls to the Three Security Categories in SP 800-53  Chapter 4: Frameworks 185 of the baseline IR-1 (Incident Response Policy and Procedures) control, we see that it requires that the organization do the following: PART I a. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]: 1. [Selection (one or more): Organization-level; Mission/business process-level; System-level] incident response policy that: (a.) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (b.) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and 2. Procedures to facilitate the implementation of the incident response policy and associated incident response controls; b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the incident response policy and procedures; and c. Review and update the current incident response: 1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and 2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]. Notice that there are assignments in square brackets in five of these requirements. These are parameters that enable an organization to tailor the baseline controls to its own unique conditions and needs. For example, in the first assignment (IR-1.a), we could specify who receives the policies and procedures; in the second (IR-1.a.1), we could specify the level(s) at which the incident response policy applies; in the third (IR-1.b), we could identify the individual (by role, not name) responsible for the policy; and in the last two assignments (IR-1.c.1 and IR-1.c.2), we could provide the frequency and triggering events for policy and procedure reviews. This is all a “fill in the blanks” approach to tailoring the controls to meet your organization’s unique conditions. EXAM TIP You do not need to memorize the controls, control enhancements, or assignments of NIST SP 800-53. We provide them here to illustrate how a framework provides structure while still allowing you room to customize it. CIS Controls The Center for Internet Security (CIS) is a nonprofit organization that, among other things, maintains a list of 20 critical security controls designed to mitigate the threat of the majority of common cyberattacks. It is another example (together with NIST SP 800-53) of a controls framework. The CIS Controls, currently in Version 7.1, are shown in Figure 4-4. CISSP All-in-One Exam Guide 186 Basic Foundational Organizational 1. Inventory and Control of 7. Email and Web Browser 12. Boundary Defense 17. Implement Security Hardware Assets Protections Awareness and Training 2. Inventory and Control of 8. Malware Defenses 13. Data Protection 18. Application Software Software Assets Security 3. Continuous Vulnerability 9. Limit and Control Network 14. Control Access Based on 19. Incident Response and Management Ports, Protocols, Services Need to Know Management 4. Controlled Use of 10. Data Recovery Capabilities 15. Wireless Access Control 20. Penetration Tests and Red Administrative Privileges Team Exercises 5. Secure Configuration of 11. Secure Configuration of 16. Account Monitoring and Hardware and Software Network Devices Control 6. Maintenance, Monitoring and Analysis of Audit Logs Figure 4-4 CIS Controls Despite CIS’s use of the word “controls,” you should really think of these like the 20 families of controls in SP 800-53. Under these 20 controls, there are a total of 171 subcontrols that have similar granularity as those established by the NIST. For example, if we look into control 13 (Data Protection), we can see the nine subcontrols listed in Table 4-3. Subcontrol Title IG1 IG2 IG3 13.1 Maintain an Inventory of Sensitive Information X X X 13.2 Remove Sensitive Data or Systems Not Regularly X X X Accessed by Organization 13.3 Monitor and Block Unauthorized Network Traffic X 13.4 Only Allow Access to Authorized Cloud Storage or X X Email Providers 13.5 Monitor and Detect Any Unauthorized Use of X Encryption 13.6 Encrypt Mobile Device Data X X X 13.7 Manage USB Devices X X 13.8 Manage System’s External Removable Media’s X Read/Write Configurations 13.9 Encrypt Data on USB Storage Devices X Table 4-3 Data Protection Subcontrols Mapped to Implementation Groups  Chapter 4: Frameworks 187 The CIS recognizes that not every organization will have the resources (or face the risks) necessary to implement all controls. For this reason, they are grouped into three PART I categories, listed next. While every organization should strive for full implementation, this approach provides a way to address the most urgent requirements first and then build on them over time. Basic These key controls should be implemented by every organization to achieve minimum essential security. Foundational These controls embody technical best practices to improve an organization’s security. Organizational These controls focus on people and processes to maintain and improve cybersecurity. A useful tool to help organizations match their implementation of controls to their resource levels are implementation groups (IGs). Version 7.1 of the CIS controls describes the following three IGs: Implementation Group 1 Small to medium-sized organizations with limited IT and cybersecurity expertise whose principal concern is to keep the business operational. The sensitivity of the data that they are trying to protect is low and principally surrounds employee and financial information. Implementation Group 2 Larger organizations with multiple departments, including one responsible for managing and protecting IT infrastructure. Small organizational units. These organizations often store and process sensitive client or company information and may have regulatory compliance burdens. A major concern is loss of public confidence if a breach occurs. Implementation Group 3 Large organizations that employ security experts with different specialty areas. Their systems and data contain sensitive information or functions that are subject to regulatory and compliance oversight. Successful attacks against these organizations can cause significant harm to the public welfare. You can see in Table 4-3 how subcontrols can be mapped to these implementation groups. This helps ensure that limited resources are focused on the most critical requirements. COBIT 2019 COBIT 2019 (the name used to be an acronym for Control Objectives for Information Technologies) is a framework for governance and management developed by ISACA (which formerly stood for the Information Systems Audit and Control Association) and the IT Governance Institute (ITGI). It helps organizations optimize the value of their IT by balancing resource utilization, risk levels, and realization of benefits. This is all done by explicitly tying stakeholder drivers to stakeholder needs to organizational goals (to meet those needs) to IT goals (to meet or support the organizational goals). It is a holistic approach based on six key principles of governance systems: 1. Provide stakeholder value 2. Holistic approach CISSP All-in-One Exam Guide 188 3. Dynamic governance system 4. Governance distinct from management 5. Tailored to enterprise needs 6. End-to-end governance system Everything in COBIT is ultimately linked to the stakeholders through a series of transforms called cascading goals. The concept is pretty simple. At any point in our IT governance or management processes, we should be able to ask the question “why are we doing this?” and be led to an IT goal that is tied to an enterprise goal, which is in turn tied to a stakeholder need. COBIT specifies 13 enterprise and 13 alignment goals that take the guesswork out of ensuring we consider all dimensions in our decision-making processes. These two sets of 13 goals are different but related. They ensure that we are aligned with the sixth principle of covering the enterprise end to end by explicitly tying enterprise and IT goals in both the governance and management dimensions, which is the fourth principle. These goals were identified by looking for commonalities (or perhaps universal features) of a large set of organizations. The purpose of this analysis is to enable a holistic approach, which is the second key principle in COBIT. The COBIT framework includes, but differentiates, enterprise governance and management. The difference between these two is that governance is a set of higher-level processes aimed at balancing the stakeholder value proposition, while management is the set of activities that achieve enterprise objectives. As a simplifying approximation, you can think of governance as the things that the C-suite leaders do and management as the things that the other organizational leaders do. Figure 4-5 illustrates how the Business Goals Requirements Information IT Goals IT Processes to in wn Audited with do Co by en nt ro d ok lle re Br d su by ea M Derived from Control Key Control Im by Activities ce Fo Outcome Objectives ple ed an rm Tests me rm rm at nte rfo fo u d Pe p er For outcome rity Audited with wi th r Fo Based on Responsibility Control Performance Outcome Maturity Control Accountability Design Indicators Measures Models Practices Chart Tests Figure 4-5 COBIT framework  Chapter 4: Frameworks 189 five governance and 35 management objectives defined by COBIT are organized into five domains. Governance objectives all fall within the Evaluate, Direct and Monitor PART I (EDM) domain. Management objectives, on the other hand, fall into four domains: Align, Plan and Organize (APO), Build, Acquire and Implement (BAI), Deliver, Service and Support (DSS), and Monitor, Evaluate and Assess (MEA). A majority of the security compliance auditing practices used today in the industry are based off of COBIT. So if you want to make your auditors happy and pass your compliance evaluations, you should learn, practice, and implement the control objectives outlined in COBIT, which are considered industry best practices. TIP Many people in the security industry mistakenly assume that COBIT is purely security focused, when in reality it deals with all aspects of information technology, security being only one component. COBIT is a set of practices that can be followed to carry out IT governance, which requires proper security practices. Enterprise Architecture Frameworks Organizations have a choice when attempting to secure their environment as a whole. They can just toss in products here and there, which are referred to as point solutions or stovepipe solutions, and hope the ad hoc approach magically works in a manner that secures the environment evenly and covers all of the organization’s vulnerabilities. Most organizations, particularly small and medium businesses, don’t start with a secure archi- tecture. Instead, they focus on their core business, get just enough security to survive, and adjust things as they grow. This organic growth model lends itself to short-term measures that result in a “constantly putting out fires” approach. It is usually easier and cheaper for senior management to approve money for a new security tool than to approve the time, money, and business disruption needed to re-architect an information system to properly secure it. The second approach to securing an organization’s environment would be to define an enterprise security architecture, allow it to be the guide when implementing solutions to ensure business needs are met, provide standard protection across the environment, and reduce the number of security surprises the organization will run into. The catch is that if a company has been following the first ad hoc approach for a while, it can be very challenging (and expensive) to rebuild its infrastructure without causing pain to a lot of people. Although implementing an enterprise security architecture does not necessarily promise pure utopia, it does tame the chaos and gets the security staff and organization into a more proactive and mature mindset when dealing with security as a whole. Developing an architecture from scratch is not an easy task. Sure, it is easy to draw a big box with smaller boxes inside of it, but what do the boxes represent? What are the relationships between the boxes? How does information flow between the boxes? Who needs to view these boxes, and what aspects of the boxes do they need for decision making? An architecture is a conceptual construct. It is a tool to help individuals understand a complex item (such as an enterprise) in digestible chunks. An example of an architecture CISSP All-in-One Exam Guide 190 is the Open Systems Interconnection (OSI) networking model, an abstract model used to illustrate the architecture of a networking stack. A networking stack within a computer is very complex because it has so many protocols, interfaces, services, and hardware specifications. But when we think about it in a modular framework (the OSI seven layers), we can better understand the network stack as a whole and the relationships between the individual components that make it up. NOTE The OSI network stack will be covered extensively in Chapter 11. An enterprise architecture encompasses the essential and unifying components of an organization. It expresses the enterprise structure (form) and behavior (function). It embodies the enterprise’s components, their relationships to each other, and their relationships to the environment. This section covers several different enterprise architecture frameworks. Each framework has its own specific focus, but they all provide guidance on how to build individual architectures so that they are useful tools to a diverse set of individuals. Notice the difference between an architecture framework and an actual architecture. You use the framework as a guideline on how to build an architecture that best fits your company’s needs. Each company’s architecture will be different because companies have different business drivers, security and regulatory requirements, cultures, and organizational structures—but if each starts with the same architecture framework, then their architectures will have similar structures and goals. It is similar to three people starting with a ranch- style house blueprint. One person chooses to have four bedrooms built because they have three children, one person chooses to have a larger living room and three bedrooms, and the other person chooses two bedrooms and two living rooms. Each person started with the same blueprint (framework) and modified it to meet their needs (architecture). When developing an architecture, first the stakeholders need to be identified, the people who will be looking at and using the architecture. Next, the views need to be developed, which is how the information that is most important to the different stakeholders will be illustrated in the most useful manner. The NIST developed a framework, illustrated in Figure 4-6, that shows that companies have several different viewpoints. Executives need to understand the company from a business point of view, business process developers need to understand what type of information needs to be collected to support business activities, application developers need to understand system requirements that maintain and process the information, data modelers need to know how to structure data elements, and the technology group needs to understand the network components required to support the layers above it. They are all looking at an architecture of the same company; it is just being presented in views that they understand and that directly relate to their responsibilities within the organization. An enterprise architecture enables you to not only understand the company from several different views, but also understand how a change that takes place at one level will affect items at other levels. For example, if there is a new business requirement, how is it going to be supported at each level of the enterprise? What type of new information must  Chapter 4: Frameworks 191 External discretionary Figure 4-6 and nondiscretionary NIST enterprise PART I standard/requirements architecture framework Business architecture Drives Enterprise Information discretionary and architecture non-discretionary Feedback standards/ Prescribes regulations Information systems architecture Identifies Data architecture Supported by Delivery systems architecture hardware, software, communications be collected and processed? Do new applications need to be purchased or current ones modified? Are new data elements required? Will new networking devices be required? An architecture enables you to understand all the things that will need to change just to support one new business function. The architecture can be used in the opposite direction also. If a company is looking to do a technology refresh, will the new systems still support all of the necessary functions in the layers above the technology level? An architecture enables you to understand an organization as one complete organism and identify how changes to one internal component can directly affect another one. Why Do We Need Enterprise Architecture Frameworks? As you have probably experienced, business people and technology people sometimes seem like totally different species. Business people use terms like “net profits,” “risk uni- verses,” “portfolio strategy,” “hedging,” “commodities,” and so on. Technology people use terms like “deep packet inspection,” “layer three devices,” “cross-site scripting,” “load balancing,” and so forth. Think about the acronyms techies like us throw around—TCP, APT, ICMP, RAID, UDP, L2TP, PPTP, IPSec, and AES. We can have complete CISSP All-in-One Exam Guide 192 conversations between ourselves without using any real words. And even though business people and technology people use some of the same words, they have totally different meanings to the individual groups. To business people, a protocol is a set of approved processes that must be followed to accomplish a task. To technical people, a protocol is a standardized manner of communication between computers or applications. Business and technical people use the term “risk,” but each group is focusing on very different risks a company can face—market share versus security breaches. And even though each group uses the term “data” the same, business people look at data only from a functional point of view and security people look at data from a risk point of view. This divide between business perspectives and technology perspectives not only can cause confusion and frustration—it commonly costs money. If the business side of the house wants to offer customers a new service, as in paying bills online, there may have to be extensive changes to the current network infrastructure, applications, web servers, software logic, cryptographic functions, authentication methods, database structures, and so on. What seems to be a small change in a business offering can cost a lot of money when it comes to adding up the new technology that needs to be purchased and implemented, programming that needs to be carried out, re-architecting of networks, and the like. It is common for business people to feel as though the IT department is more of an impediment when it comes to business evolution and growth, and in turn the IT department feels as though the business people are constantly coming up with outlandish and unrealistic demands with no supporting budgets. This type of confusion between business and technology people has caused organizations around the world to implement incorrect solutions because they did not understand the business functionality to technical specifications requirements. This results in having to repurchase new solutions, carry out rework, and waste an amazing amount of time. Not only does this cost the organization more money than it should have in the first place, business opportunities may be lost, which can reduce market share. So we need a tool that both business people and technology people can use to reduce confusion, optimize business functionality, and not waste time and money. This is where business enterprise architectures come into play. They allow both groups (business and technology) to view the same organization in ways that make sense to them. When you go to the doctor’s office, there is a poster of a skeleton system on one wall, a poster of a circulatory system on the other wall, and another poster of the organs that make up a human body. These are all different views of the same thing, the human body. This is the same functionality that enterprise architecture frameworks provide: different views of the same thing. In the medical field we have specialists (podiatrists, brain surgeons, dermatologists, oncologists, ophthalmologists, etc.). Each organization is also made up of its own specialists (HR, marketing, accounting, IT, R&D, management, etc.). But there also has to be an understanding of the entity (whether it is a human body or company) holistically, which is what an enterprise architecture attempts to accomplish. Zachman Framework One of the first enterprise architecture frameworks that was created is the Zachman Framework, created by John Zachman. This model is generic, and is well suited to frame the work we do in information systems security. A sample (though fairly simplified) rep- resentation is depicted in Table 4-4.  Interrogatives What How Where Who When Why Contextual Assets and Business Lines Business Locales Partners, Clients, Milestones and Business Strategy (Executives) Liabilities and Employees Major Events Conceptual Products Business Logistics and Workflows Master Calendar Business Plan (Business Mgrs.) Processes Communications Architectural Data Models Systems Distributed Use Cases Project Schedules Business Rule (System Architectures Systems Models Architects) Architectures Technological Data Systems Designs System Interfaces Human Interfaces Process Controls Process Outputs Perspective (Audience) (Engineers) Management Implementation Data Stores Programs Network Nodes Access Controls Network/ Security Performance (Technicians) and Links Operations Metrics Enterprise Information Functions Networks Organizations Schedules Strategies Table 4-4 Zachman Framework for Enterprise Architecture 193 Chapter 4: Frameworks PART I CISSP All-in-One Exam Guide 194 The Zachman Framework is a two-dimensional model that uses six basic communication interrogatives (What, How, Where, Who, When, and Why) intersecting with different perspectives (Executives, Business Managers, System Architects, Engineers, Technicians, and Enterprise-wide) to give a holistic understanding of the enterprise. This framework was developed in the 1980s and is based on the principles of classical business architecture that contain rules that govern an ordered set of relationships. One of these rules is that each row should describe the enterprise completely from that row’s perspective. For example, IT personnel’s jobs require them to see the organization in terms of data stores, programs, networks, access controls, operations, and metrics. Though they are (or at least should be) aware of other perspectives and items, the performance of their duties in the example organization is focused on these items. The goal of this framework is to be able to look at the same organization from different viewpoints. Different groups within a company need the same information, but presented in ways that directly relate to their responsibilities. A CEO needs financial statements, scorecards, and balance sheets. A network administrator needs network schematics, a systems engineer needs interface requirements, and the operations department needs configuration requirements. If you have ever carried out a network-based vulnerability test, you know that you cannot tell the CEO that some systems are vulnerable to time- of-check to time-of-use (TOC/TOU) attacks or that the company software allows for client-side browser injections. The CEO needs to know this information, but in a language she can understand. People at each level of the organization need information in a language and format that are most useful to them. A business enterprise architecture is used to optimize often fragmented processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the business strategy. The Zachman Framework has been around for many years and has been used by many organizations to build or better define their business environment. This framework is not security oriented, but it is a good template to work with because it offers direction on how to understand an actual enterprise in a modular fashion. The Open Group Architecture Framework Another enterprise architecture framework is The Open Group Architecture Framework (TOGAF), which has its origins in the U.S. Department of Defense. It provides an approach to design, implement, and govern an enterprise information architecture. TOGAF is a framework that can be used to develop the following architecture types: Business architecture Data architecture Applications architecture Technology architecture TOGAF can be used to create these individual architecture types through the use of its Architecture Development Method (ADM). This method is an iterative and cyclic process that allows requirements to be continuously reviewed and the individual architectures  Chapter 4: Frameworks 195 to be updated as needed. These different architectures can allow a technology architect to understand the enterprise from four different views (business, data, application, and PART I technology) so she can ensure her team develops the necessary technology to work within the environment and all the components that make up that environment and meet business requirements. The technology may need to span many different types of networks, interconnect with various software components, and work within different business units. As an analogy, when a new city is being constructed, people do not just start building houses here and there. Civil engineers lay out roads, bridges, waterways, and zones for commercial and residential development. A large organization that has a distributed and heterogeneous environment that supports many different business functions can be as complex as a city. So before a programmer starts developing code, the architecture of the software needs to be developed in the context of the organization it will work within. NOTE Many technical people have a negative visceral reaction to models like TOGAF. They feel it’s too much work, that it’s a lot of fluff, is not directly relevant, and so on. If you handed the same group of people a network schematic with firewalls, IDSs, and virtual private networks (VPNs), they would say, “Now we’re talking about security!” Security technology works within the construct of an organization, so the organization must be understood also. Military-Oriented Architecture Frameworks It is hard enough to construct enterprise-wide solutions and technologies for one orga- nization—think about an architecture that has to span many different complex govern- ment agencies to allow for interoperability and proper hierarchical communication chan- nels. This is where the Department of Defense Architecture Framework (DoDAF) comes into play. When the U.S. DoD purchases technology products and weapon systems, enterprise architecture documents must be created based upon DoDAF standards to illustrate how they will properly integrate into the current infrastructures. The focus of the architecture framework is on command, control, communications, computers, intel- ligence, surveillance, and reconnaissance systems and processes. It is not only important that these different devices communicate using the same protocol types and interoper- able software components but also that they use the same data elements. If an image is captured from a spy satellite, downloaded to a centralized data repository, and then loaded into a piece of software to direct an unmanned drone, the military personnel can- not have their operations interrupted because one piece of software cannot read another software’s data output. The DoDAF helps ensure that all systems, processes, and person- nel work in a concerted effort to accomplish its missions. NOTE While DoDAF was developed to support mainly military missions, it has been expanded upon and morphed for use in business enterprise environments. CISSP All-in-One Exam Guide 196 When attempting to figure out which architecture framework is best for your organization, you need to find out who the stakeholders are and what information they need from the architecture. The architecture needs to represent the company in the most useful manner to the people who need to understand it the best. If your company has people (stakeholders) who need to understand the company from a business process perspective, your architecture needs to provide that type of view. If there are people who need to understand the company from an application perspective, your architecture needs a view that illustrates that information. If people need to understand the enterprise from a security point of view, that needs to be illustrated in a specific view. So one main difference between the various enterprise architecture frameworks is what type of information they provide and how they provide it. Other Frameworks Along with ensuring that we have the proper controls in place, we also want to have ways to construct and improve our business, IT, and security processes in a struc- tured and controlled manner. The security controls can be considered the “things,” and processes are how we use these things. We want to use them properly, effectively, and efficiently. ITIL ITIL (formerly the Information Technology Infrastructure Library) was developed in the 1980s by the UK’s Central Computer and Telecommunications Agency (which was sub- sumed in the late 1990s by the now defunct Office of Government Commerce). ITIL is now controlled by AXELOS, which is a joint venture between the government of the UK and the private firm Capita. ITIL is the de facto standard of best practices for IT service management. ITIL was created because of the increased dependence on informa- tion technology to meet business needs. Unfortunately, as previously discussed, a natural divide exists between business people and IT people in most organizations because they use different terminology and have different focuses within the organization. The lack of a common language and understanding of each other’s domain (business versus IT) has caused many companies to ineffectively blend their business objectives and IT functions. This improper blending usually generates confusion, miscommunication, missed dead- lines, missed opportunities, increased cost in time and labor, and frustration on both the business and technical sides of the house. ITIL blends all parts of an organization using a four-dimensional model built around the concept of value for the stakeholders. The dimensions in this model, illustrated in Figure 4-7, are organizations and people, value streams and processes, information and technology, and partners and suppliers. These exist in a broader context that is influenced by factors that can be political, economic, social, technological, legal, or environmental. Effective organizations must consider all four dimensions within their broader context when planning, developing, and offering products and/or services if they are to provide value.  Chapter 4: Frameworks 197 Figure 4-7 ITIL PART I Political Economical Organizations Information and people and technology du Pro cts Environmental Social Value an d s e r vice s Partners Value streams and suppliers and processes Legal Technological Six Sigma Six Sigma is a process improvement methodology. Its goal is to improve process quality by using statistical methods of measuring operation efficiency and reducing variation, defects, and waste. Six Sigma is being used in the security assurance industry in some instances to measure the success factors of different controls and procedures. Six Sigma was developed by Motorola with the goal of identifying and removing defects in its manufac- turing processes. The maturity of a process is described by a sigma rating, which indicates the percentage of defects that the process contains. While it started in manufacturing, Six Sigma has been applied to many types of business functions, including information security and assurance. Capability Maturity Model While we know that we constantly need to make our security program better, it is not always easy to accomplish because “better” is a vague and nonquantifiable concept. The only way we can really improve is to know where we are starting from, where we need to go, and the steps we need to take in between. Every security program has a maturity level, which could range from nonexistent to highly optimized. In between these two extremes, there are different levels. An example of a Capability Maturity Model (CMM) is illustrated in Figure 4-8. Each maturity level within this model represents an evolutionary stage. Some security programs are chaotic, ad hoc, unpredictable, and usually insecure. Some security programs have documentation created, but the actual processes are not tak- ing place. Some security programs are quite evolved, streamlined, efficient, and effective. EXAM TIP The CISSP exam puts more emphasis on CMM compared to ITIL and Six Sigma because it is more heavily used in the security industry. CISSP All-in-One Exam Guide 198 Figure 4-8 Capability Maturity Model for a security program Security Program Development No organization is going to put all the previously listed items (NIST RMF, OCTAVE, FAIR, ISO/IEC 27000, NIST CSF, NIST SP 800-53, CIS Controls, COBIT 2019, Zachman Framework, ITIL, Six Sigma, CMM) into place. But it is a good toolbox of things you can pull from, and you will find some fit the organization you work in better than others. You will also find that as your organization’s security program matures, you will see more clearly where these various standards, frameworks, and management components come into play. While these items are separate and dis- tinct, there are basic things that need to be built in for any security program and its corresponding controls. This is because the basic tenets of security are universal no matter if they are being deployed in a corporation, government agency, business, school, or nonprofit organization. Each entity is made up of people, processes, data, and technology, and each of these things needs to be protected.  Chapter 4: Frameworks 199 Top-Down Approach PART I A security program should use a top-down approach, meaning that the initiation, support, and direction come from top management; work their way through middle management; and then reach staff members. In contrast, a bottom-up approach refers to a situation in which staff members (usually IT) try to develop a security program without getting proper management support and direction. A bottom- up approach is commonly less effective, not broad enough to address all security risks, and doomed to fail. A top-down approach makes sure the people actually responsible for protecting the company’s assets (senior management) are driving the program. Senior management are not only ultimately responsible for the protection of the organization but also hold the purse strings for the necessary funding, have the authority to assign needed resources, and are the only ones who can ensure true enforcement of the stated security rules and policies. Management’s support is one of the most important pieces of a security program. A simple nod and a wink will not provide the amount of support required. The crux of CMM is to develop structured steps that can be followed so an organization can evolve from one level to the next and constantly improve its processes and security posture. A security program contains a lot of elements, and it is not fair to expect every part to be properly implemented within the first year of its existence. And some components, as in forensics capabilities, really cannot be put into place until some rudimentary pieces are established, as in incident management. So if we really want our baby to be able to run, we have to lay out ways that it can first learn to walk. Putting It All Together While the cores of these various security standards and frameworks are similar, it is important to understand that a security program has a life cycle that is always continu- ing, because it should be constantly evaluated and improved upon. The life cycle of any process can be described in different ways. We will use the following steps: 1. Plan and organize 2. Implement 3. Operate and maintain 4. Monitor and evaluate Without setting up a life-cycle approach to a security program and the security management that maintains the program, an organization is doomed to treat security as merely another project. Anything treated as a project has a start and stop date, and at the stop date everyone disperses to other projects. Many organizations have had good intentions in their security program kickoffs, but do not implement the proper structure CISSP All-in-One Exam Guide 200 to ensure that security management is an ongoing and continually improving process. The result is a lot of starts and stops over the years and repetitive work that costs more than it should, with diminishing results. The main components of each phase are provided here. Plan and Organize: Establish management commitment. Establish oversight steering committee. Assess business drivers. Develop a threat profile on the organization. Carry out a risk assessment. Develop security architectures at business, data, application, and infrastructure levels. Identify solutions per architecture level. Obtain management approval to move forward. Implement: Assign roles and responsibilities. Develop and implement security policies, procedures, standards, baselines, and guidelines. Identify sensitive data at rest and in transit. Implement the following blueprints: Asset identification and management Risk management Vulnerability management Compliance Identity management and access control Change control Software development life cycle Business continuity planning Awareness and training Physical security Incident response Implement solutions (administrative,