Innovation and best practices can be sown throughout an organization—but only when they fall on fertile ground.

—Marcus Buckingham

Security Frameworks

A security program is a framework made up of many entities: logical, administrative, and physical protection mechanisms, procedures, business processes, and people, all working together to provide a level of protection 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 layers: one 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.

NIST

The National Institute for Standards and Technology (NIST) is an organization within the U.S. Department of Commerce that is charged with promoting innovation and industrial competitiveness. As part of this mission, the NIST develops and publishes standards and guidelines aimed at improving practices, including cybersecurity across a variety of sectors. Though it is certainly worth your time to familiarize yourself with these publications, you should be familiar with two in particular as a CySA+ candidate: NIST Special Publication 800-53 (Security and Privacy Controls for Federal Information Systems and Organizations) and the Cyber Security Framework (CSF).

SP 800-53

One of the standards that NIST has been responsible for developing is called Special Publication 800-53 (Security and Privacy Controls for Federal Information Systems and Organizations), currently on its fourth revision. it outlines controls that agencies need to put into place to be compliant with the Federal Information Processing Standards (FIPS). Basically, this publication provides specific guidance on how to select security controls as part of the Risk Management Framework described in SP 800-37. Table 11-1 outlines the control categories addressed in this publication.

Table 11-1   NIST SP 800-53 Control Categories

The control categories (families) are the management, operational, and technical controls prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. Government auditors use SP 800-53 to ensure that government agencies are compliant with government-oriented regulations. It is worth noting that, although this publication is aimed at federal government organizations, many others have voluntarily adopted it to help them better secure their systems.

Cyber Security Framework

On February 12, 2013, the President of the United States signed Executive Order 13636 calling 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, repeatable, and cost-effective so that it could be prioritized for better alignment with business processes and goals. A year to the day later, the NIST published the Cyber Security Framework (CSF), which was the result of a collaborative process with members of the government, industry, and academia. As of this writing, over 30 percent of U.S. organizations have adopted the CSF. That figure is expected to reach 50 percent by the year 2020. The CSF is divided into three main components:

•  The Framework Core consists of the various activities, outcomes, and references common to all organizations. The CSF breaks these down into five functions, 22 categories, and 98 subcategories.

•  The 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.

•  The Framework Profile describes the state of an organization with regard to the CSF categories and subcategories. It allows decision-makers to compare the “as-is” situation to one or more “to-be” possibilities, allowing them to align cybersecurity and business priorities and processes in ways that make sense to that particular organization.

The CSF Core organizes 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.

ISO

When the need to expand and globally standardize security standards was identified, this task was taken on by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). ISO is the world’s largest developer and publisher of international standards. The standards this group works on range from meteorology, food technology, and agriculture to space vehicle engineering, mining, and information technology. The IEC develops and publishes international standards for all electrical, electronic, and related technologies. These two organizations worked together to build a family of global Information Security Management System (ISMS) standards, known as the ISO/IEC 27000 series, some of which are listed here:

•  ISO/IEC 27000   Overview and vocabulary

•  ISO/IEC 27001   ISMS requirements

•  ISO/IEC 27002   Security management

•  ISO/IEC 27003   ISMS implementation

•  ISO/IEC 27004   ISMS measurement

•  ISO/IEC 27005   Risk management

•  ISO/IEC 27006   Certification requirements

•  ISO/IEC 27007   ISMS auditing

•  ISO/IEC 27008   Guidance for auditors

•  ISO/IEC 27031   Business continuity

•  ISO/IEC 27033   Network security

•  ISO/IEC 27034   Application security

•  ISO/IEC 27035   Incident management

•  ISO/IEC 27037   Digital evidence collection and preservation

This group of standards serves as industry best practices for the management of security controls in a holistic manner within organizations around the world. The list of standards that make up this series grows each year. Each standard has a specific focus (such as metrics, governance, or auditing). 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.

COBIT

The Control Objectives for Information and related Technology (COBIT) is a framework and set of control objectives developed by ISACA (formerly the Information Systems Audit and Control Association but now known only by its acronym) and the IT Governance Institute (ITGI). It defines goals for the controls that should be used to properly manage IT and to ensure that IT maps to business needs. COBIT is broken down into four domains: Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate. Each category drills down into subcategories. For example, the Acquire and Implement category contains the following subcategories:

•  Acquire and Maintain Application Software

•  Acquire and Maintain Technology Infrastructure

•  Develop and Maintain Procedures

•  Install and Accredit Systems

•  Manage Changes

So this COBIT domain provides goals and guidance to companies that they can follow when they purchase, install, test, certify, and accredit IT products. This is very powerful because many companies use an ad hoc and informal approach when making purchases and carrying out procedures. COBIT offers a “checklist” approach to IT governance by providing a list of things that must be thought through and accomplished when carrying out different IT functions.

COBIT lays out executive summaries, management guidelines, frameworks, control objectives, an implementation toolset, performance indicators, success factors, maturity models, and audit guidelines. It lays out a complete roadmap that can be followed to accomplish each of the 34 control objectives this model deals with. Figure 11-1 illustrates how the framework connects business requirements, IT resources, and IT processes.

Figure 11-1   COBIT framework

COBIT can bridge the gap between a high-level framework and the selection and implementation of effective procedures and controls. When you develop your security policies that are aligned with the ISO/IEC 27000 series, these are high-level documents that have statements like, “Unauthorized access should not be permitted.” But who is authorized? How do we authorize individuals? How are we implementing access control to ensure that unauthorized access is not taking place? How do we know our access control components are working properly? This is really where the rubber hits the road, where words within a document (policy) come to life in real-world practical implementations. COBIT provides the objective that the real-world implementations (controls) you chose to put into place need to meet. For example, COBIT outlines the following control practices for user account management:

•  Using unique user IDs so that users can be held accountable for their actions

•  Checking that the user has authorization from the system owner for the use of the information system or service, and the level of access granted is appropriate to the business purpose and consistent with the organizational security policy

•  Implementing a procedure to require users to understand and acknowledge their access rights and the conditions of such access

•  Ensuring that internal and external service providers do not provide access until authorization procedures have been completed

•  Maintaining a formal record, including access levels, of all persons registered to use the service

•  Conducting a timely and regular review of user IDs and access rights

An organization should make sure it is meeting at least these goals when it comes to user account management; in turn, this is what an auditor is going to go by to ensure the organization is practicing security properly. Many of today’s practices for auditing security compliance are based on COBIT because they are considered industry best practices.

SABSA

The Sherwood Applied Business Security Architecture (SABSA), shown in Table 11-2, is a layered model in which the first layer defines business requirements from a security perspective. Each layer of the model decreases in abstraction and increases in detail so that it builds upon the others and moves from policy to practical implementation of technology and solutions. The idea is to provide a chain of traceability through the strategic, conceptual, design, implementation, and metric and auditing levels.

Table 11-2   SABSA Architectural Framework

The following outlines the questions that are to be asked and answered at each level of the framework:

•  What are you trying to do at this layer?   The assets to be protected by your security architecture

•  Why are you doing it?   The motivation for wanting to apply security, expressed in the terms of this layer

•  How are you trying to do it?   The functions needed to achieve security at this layer

•  Who is involved?   The people and organizational aspects of security at this layer

•  Where are you doing it?   The locations where you apply your security, relevant to this layer

•  When are you doing it?   The time-related aspects of security relevant to this layer

SABSA is a framework and methodology for enterprise security architecture and service management. Because it is a framework, it provides a structure for individual architectures to be built from. Because it is also a methodology, it provides the processes to follow to build and maintain this architecture. SABSA provides a lifecycle model so that the architecture can be constantly monitored and improved upon over time.

TOGAF

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 for designing, implementing, and governing an enterprise information architecture that can be used to develop the following architecture types:

•  Business architecture

•  Data architecture

•  Applications architecture

•  Technology architecture

This framework can be used to create individual architectures 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 updated as needed. These different architectures can allow a technology architect to understand the enterprise from four different views (business, data, application, and 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 network types, 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 commercial and housing zoned areas. 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.

ITIL

The Information Technology Infrastructure Library (ITIL) is the de facto standard of best practices for IT service management. ITIL was created because of the increased dependence on information technology to meet business needs. Unfortunately, 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 deadlines, missed opportunities, increased cost in time and labor, and frustration on both the business and technical sides of the house. ITIL is a customizable framework that provides the goals, the general activities necessary to achieve these goals, and the input and output values for each process required to meet these determined goals. Although ITIL has a component that deals with security, its focus is more toward internal service level agreements (SLAs) between the IT department and the “customers” it serves. The customers are usually internal departments. The main components that make up ITIL are illustrated in Figure 11-2.

Figure 11-2   ITIL

Policies and Procedures

For a company’s security plan to be successful, it must start at the top level and be useful and functional at every single level within the organization. Senior management needs to define the scope of security and identify and decide what must be protected and to what extent. Management must understand the regulations, laws, and liability issues it is responsible for complying with regarding security and ensure that the company as a whole fulfills its obligations. Senior management also must determine what is expected from employees and what the consequences of noncompliance will be. These decisions should be made by the individuals who will be held ultimately responsible if something goes wrong. But it is a common practice to bring in the expertise of the security officers to collaborate in ensuring that sufficient policies and controls are being implemented to achieve the goals being set and determined by senior management.

A security program contains all the pieces necessary to provide overall protection to a organization and lays out a long-term security strategy. A security program’s documentation should include security policies and procedures. The more detailed the rules are, the easier it is to know when one has been violated. However, overly detailed documentation and rules can prove to be more burdensome than helpful. The business type, its culture, and its goals must be evaluated to make sure the proper language is used when writing security documentation.

Security Policies

A security policy is an overall general statement produced by senior management (or a selected policy board or committee) that dictates what role security plays within the organization. A security policy can be an organizational policy, an issue-specific policy, or a system-specific policy. These documents must include a process for dealing with those who choose not to comply with them. This establishes a process that others can understand and thus recognize not only what is expected of them, but also what they can expect as a response to their noncompliance.

Policies are written in broad terms to cover many subjects in a general fashion. Much more granularity is needed to actually support the policy, and this happens with the use of procedures and controls, which we discuss in a later section. The policy provides the foundation. The procedures provide the security framework, and the necessary security controls (administrative, technical, and physical) are used to fill in the framework to provide a full security program.

Data Classification

One of the most common and important security policies deals with the classification of organizational data, which is a topic introduced in Chapter 5. The rationale behind assigning classification levels to different types of data is that it enables an organization to gauge the amount of funds and other resources that should go toward protecting each. A typical organization has a lot of information that is created and maintained, but not all of it has the same value. A key reason to have a data classification policy is to organize it according to its sensitivity to loss, alteration, disclosure, or unavailability. Many people mistakenly consider only the confidentiality aspects of data protection, but we need to make sure our data is not modified in an unauthorized manner and that it is available when needed. Once data is segmented according to its sensitivity level, the organization can decide what processes and security controls are necessary to protect it.

Data Ownership

Data ownership policies are typically combined with data classification ones because it is difficult to separate the two issues. The main reason is that the data is classified by the person who “owns” it. Data ownership policies establish the roles and responsibilities of data owners within the organization. The data owner (information owner) is usually a member of management who is in charge of a specific business unit, and who is ultimately responsible for the protection and use of a specific subset of information. The data owner has due care responsibilities and thus will be held responsible for any negligent act that results in the corruption or disclosure of the data. Data owners decide the classification of the data for which they are responsible and alter classifications if business needs arise. These individuals are also responsible for ensuring that the necessary security controls are in place, defining security requirements per classification and backup requirements, approving any disclosure activities, ensuring that proper access rights are being used, and defining user-access criteria. The data owners approve access requests or may choose to delegate this function to business unit managers. Also, data owners will deal with security violations pertaining to the data they are responsible for protecting.

A key issue to address in a data ownership policy is who owns the personal data that an employee brings into an organizational information system. For example, if employees are allowed to check e-mail or social media sites from work, their personal data will traverse and be stored, albeit temporarily, on corporate information systems. Does it now belong to the company? Are there expectations of privacy? What about personal e-mail received by employees at their work accounts? These issues should be formally addressed in a data ownership policy.

Data Retention

There is no universal agreement on how long you should retain data that you own. Legal and regulatory requirements (where they exist) vary among countries and sectors. What is universal is the need to ensure your organization has and follows a documented data retention policy. Doing otherwise is flirting with disaster, particularly when dealing with pending or ongoing litigation. It is not enough, of course, to simply have a policy; you must ensure it is being followed and you must document this through regular audits.

A very straightforward and perhaps tempting approach would be to look at the lengthiest legal or regulatory retention requirement on your organization and then apply that timeframe to all your data retention. The problem with this is that it will probably make your retained data set orders of magnitude greater than it needs to be. Not only does this impose additional storage costs, but it also makes it more difficult to comply with electronic discovery (e-discovery) orders. When you receive an e-discovery order from a court, you are typically required to produce a specific amount of data (usually pretty large) within a given timeframe (usually very short). Obviously, the more data you retain, the more difficult and expensive this process will be.

A better approach is to find the specific data sets that have mandated retention requirements and handle those accordingly. Everything else has a retention period that minimally satisfies the business requirements. You probably will find that different business units within medium and large organizations will have different retention requirements. For instance, you may want to keep data from your research and development (R&D) division for a much longer period than you would keep data from the customer service division. R&D projects that are not particularly helpful today may be so at a later date, but audio recordings of customer service calls probably don’t have to hang around for a few years.

Passwords

The password policy is perhaps the most visible of security policies because every user will have to deal with its effects on a daily basis. A good password policy should motivate users to manage their passwords securely, describe to them how this should be accomplished, and prescribe the consequences of failing to comply. The three main elements in most password policies relate to generation, duration, and use.

When creating passwords, users should be informed of the requirements of an acceptable one. Commonly, these standards include some or all of the following:

•  Minimum length (for example, eight characters or greater)

•  Requirement for specific types of characters (such as uppercase, lowercase, numbers, and special characters)

•  Prohibition against reuse (for example, cannot be any of the last four passwords)

•  Minimum age (to prevent flipping in order to reuse an old password)

•  Maximum age (for example, 90 days)

•  Prohibition against certain words (such as user’s name or company name)

The policy should also cover the use of different passwords. For example, users should not use the same password for multiple systems, so that a compromise of one does not automatically lead to the compromise of all user accounts. Admittedly, this is a difficult provision to enforce, particularly when it comes to the reuse of passwords for personal and organizational use. Still, it may be worth including for educational purposes as well as to potentially mitigate some liability for the organization.

Acceptable Use

The acceptable use policy (AUP) specifies what the organization considers an acceptable use of the information systems that are made available to the employee. Using a workplace computer to view pornography, send hate e-mail, or hack other computers is almost always forbidden. On the other hand, many organizations allow their employees limited personal use, such as checking personal e-mail and surfing the Web during breaks. The AUP is a useful first line of defense, because it documents when each user was made aware of what is and is not acceptable use of computers (and other resources) at work. This makes it more difficult for a user to claim ignorance if he or she subsequently violates the AUP.

Account Management

A preferred technique of attackers is to become “normal” privileged users of the systems they’re compromising as soon as possible. They can accomplish this in at least three ways: compromise an existing privileged account, create a new privileged account, and elevate the privileges of a regular user account. The first approach can be mitigated through the use of strong authentication (for example, strong passwords and two-factor authentication) and by having administrators only use privileged accounts for specific tasks and only from jump boxes. The second and third approaches can be mitigated by paying close attention to the creation, modification, or misuse of user accounts. These controls all fall within the scope of an account management policy.

When new employees arrive, they should follow a well-defined process that is aimed at ensuring not only that they understand their duties and responsibilities, but also that they are assigned the required company assets and that these are properly configured, protected, and accounted for. Among these assets is a user account that grants them access to the information systems and authorization to create, read, modify, execute, or delete resources (for example, files) within it. The policy should dictate the default expiration date of accounts, the password policy (unless it is a separate document), and the information to which a user should have access. This last part becomes difficult because the information needs of the users will typically vary over time.

Adding, removing, or modifying the permissions that a user has should be a carefully controlled and documented process. When is the new permission(s) effective? Why is it needed? Who authorized it? Organizations that are mature in their security processes will have a change-control process in place to address user privileges. While many auditors will focus on who has administrative privileges in the organization, there are many custom sets of permissions that approach the level of an admin account. It is important, then, to have and test the processes by which elevated privileges are issued.

Another important practice in account management is the suspension of accounts that are no longer needed. Every large organization eventually stumbles across one or more accounts that belong to users who are no longer part of the organization. In some extreme cases, these users left several months ago and had privileged accounts. The unfettered presence of these accounts on our networks gives our adversaries a powerful means to become a seemingly legitimate user, which makes our job of detecting and repulsing them that much more difficult.

Procedures

Procedures are detailed, step-by-step tasks that should be performed to achieve a certain goal. The steps can apply to users, IT staff, operations staff, security members, and others who may need to carry out specific tasks. Many organizations have written procedures on how to install operating systems, configure security mechanisms, implement access control lists, set up new user accounts, assign computer privileges, audit activities, destroy material, report incidents, and much more.

Procedures spell out how the policies, standards, and guidelines will actually be implemented in an operating environment. If a policy states that all individuals who access confidential information must be properly authenticated, the supporting procedures will explain the steps for this to happen by defining the access criteria for authorization, how access-control mechanisms are implemented and configured, and how access activities are audited. If a standard states that backups should be performed, then the procedures will define the detailed steps necessary to perform the backup, the timelines of backups, the storage of backup media, and so on. Procedures should be detailed enough to be both understandable and useful to a diverse group of individuals. In the next few sections, we discuss some issues you should consider with regard to specific common procedures.

Continuous Monitoring Procedures

In Special Publication 800-137, the NIST defines information security continuous monitoring as “maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions.” A continuous-monitoring procedure, therefore, would describe the process by which an organization collects and analyzes information in order to maintain awareness of threats, vulnerabilities, compliance, and the effectiveness of security controls. Obviously, this is a complex and very broadly scoped effort that requires coordination across multiple business units and tight coupling with the organization’s risk management processes.

When continuous monitoring reveals actionable intelligence (for example, a new threat or vulnerability), there should be a pre-established process in place to deal with this situation. The remediation plan describes the steps that an organization takes whenever its security posture worsens. This plan will likely have references to multiple procedures, some of which we discuss in this chapter. For example, if the issue is a newly discovered vulnerability in an application, the remediation plan would point the security team to the patching procedure discussed later in this chapter. If, on the other hand, the change is due to an awareness that a security control is not as effective as it was thought to have been, the team would have to consider whether the control-testing procedure was effective or should be updated.

Evidence Production Procedures

When parties go to court, the manner in which evidence is introduced is almost as important as the evidence itself, which is the reason why having a well-documented (and enforced) procedure can be the difference between prevailing or losing. Evidence production is a legal request for documents, files, or any other tangible items that may have bearing on a legal procedure. This oftentimes happens during the early (discovery) portion of a legal action, which is why the term evidence production is sometimes used interchangeably with electronic discovery, or e-discovery. It is important to note, however, that e-discovery is a subset of evidence production, because the latter includes seizure (discussed in Chapter 9), which the former doesn’t. Because we’ve discussed actions at the scene of an incident or crime already, it is worthwhile to consider e-discovery procedures here.

The discovery of electronically stored information (ESI) is called e-discovery, which is the process of producing for a court or external attorney all ESI pertinent to a legal proceeding. For example, if your company is being sued for damages resulting from a faulty product, the plaintiff’s attorney could get an e-discovery order compelling you to produce all e-mail between the QA team and senior executives in which the product’s faults are discussed. If your data retention policy and evidence production procedures are adequate, e-discovery should not require excessive efforts. If, on the other hand, you have been slack about retention, such an order could cripple the organization.

The Electronic Discovery Reference Model (EDRM) identifies the following eight steps, though they are not necessarily all required, nor are they performed in a linear manner:

•  Identification of data required under the order

•  Preservation of this data to ensure it is not accidentally or routinely destroyed while the order is being complied with

•  Collection of the data from the various stores in which it may be housed

•  Processing to ensure the correct format is used for both the data and its metadata

•  Review of the data to ensure it is relevant

•  Analysis of the data for proper context

•  Production of the final data set to those requesting it

•  Presentation of the data to external audiences to prove or disprove a claim

The evidence production procedure should specify how these steps are to be performed in your organization. Clearly, this should be carefully coordinated with your data retention policy to ensure you don’t destroy information prematurely or have to wade through excessively large volumes of data in order to comply with court orders.

Patching Procedures

Security patch management is the process by which fixes to software vulnerabilities are identified, tested, applied, validated, and documented. These five functions should be codified in a formal procedure within every organization. The identification function requires having complete, accurate, and updated software inventories. Only when you know exactly what software is running on your systems can you identify the need for (and sources of) patches. Once you determine the need for a patch and acquire it from a trusted source, you have to test it in order to determine what effects it may have on your business processes. It is not unusual for security patches to break something, which requires the IT and security staff to look for these unintended effects. The organization’s leaders would then have to decide whether to apply the patch anyway, implement other controls, or do nothing and assume the risk. The process by which this determination is made should be described in the standard patching procedure.

Once the decision is made to push out the patch onto production systems, this should not be done all at once. Different organizations will have procedures that prioritize patching of systems that are high risk (for example, outward-facing systems), noncritical (that is, if they break because of the patch, it won’t hurt the company much), or whose work unit leaders offer to be guinea pigs for the rest of the organization. There is no universal right answer for this sequencing, but the approach should be formally documented.

After the patches are installed, they have to be documented and validated. Documentation of patching means that you update your software inventory to reflect the fact that a specific installation of the software is now patched (or not). Every unpatched system should require a formal waiver that includes how (if at all) the risk of not being patched is being mitigated. Finally, the patches should be validated to ensure they serve the intended purpose. This usually entails adding plug-ins to vulnerability scanners and perhaps even running a special scan.

Compensation Control Development Procedures

As we discussed in the preceding section, sometimes leaders will knowingly choose to take actions that leave vulnerabilities in their information systems. This usually happens either because the fix is too costly (for example, a patch would break a critical business process) or because there is no feasible way to fix the vulnerability directly (for example, an older X-ray machine at a hospital). Compensation controls are security controls that are not directly applied to a vulnerable system but that compensate for the lack of a direct control. For example, if you have a vulnerable system that is no longer supported by its vendor, you may put it in its own VLAN and create ACLs that allow it to communicate with only one other host, which has been hardened against attacks. You may also want to deploy additional sensors to monitor traffic on that VLAN and activity on the hardened host. The process by which these decisions are made and the compensation controls developed should be codified in its own separate procedure, or included in another related procedure.

Control-Testing Procedures

Security controls may fail to protect information systems against threats for a variety of reasons. If the control is improperly installed or configured, or if you chose the wrong control to begin with, then the asset will remain vulnerable. (You just won’t know it.) For this reason, you should have a formal procedure that describes the steps by which your organization’s security staff will verify and validate the controls they use. Verification is the process of ensuring that the control was implemented correctly. Validation ensures that the (correctly installed) control actually mitigates the intended threat.

Exception Management Procedures

There will be times when an organization will choose to violate its own policies or procedures. We already saw some of this when we introduced compensation control development earlier in this chapter. Whatever the reason for this decision, it is critical that it be made by the right people, with access to the right information, and with proper documentation. These are the essential elements of an exception management procedure.

The first step should always be to involve the right people in the conversation. The exception will typically have effects (real or potential) on multiple parts of the organization. Once these business units are identified, their leaders should designate a decision-maker who will represent their interests in the conversation. Each of these stakeholders will have specific responsibilities and authorities with regard to the exception, which will inform the process by which the decision will ultimately be made. For example, if the decision predominantly affects one unit, then that stakeholder should have a significant say on whether or not it is accepted. After the stakeholders and their roles in the process are established, the group should be presented with the full set of known facts and assumptions about the situation, the proposed exception, and its possible effects. The exception management procedure should spell out how they will reach a decision on whether or not to grant the exception to policy. It should also describe the process by which the duration of the exception is determined as well as what to do if there are irreconcilable differences during the decision-making process.

Controls

Controls are put into place to reduce the risk an organization faces, and they come in three main flavors: administrative, technical, and physical. Administrative controls are commonly referred to as “soft controls” because they are more management oriented. Examples of administrative controls are security documentation, risk management, personnel security, and training. Logical controls (also called technical controls) are software or hardware components, as in firewalls, IDS, encryption, identification, and authentication mechanisms. Finally, physical controls are items put into place to protect facility, personnel, and resources. Examples of physical controls are security guards, locks, fencing, and lighting.

Physical Controls

Physical controls are safeguards that deter, delay, prevent, detect, or respond to threats against physical property. It is important to understand certain physical controls must support and work with administrative and logical (technical) controls to provide appropriate security. Examples of physical controls include having a security guard verify individuals’ identities prior to entering a facility, erecting fences around the exterior of the facility, making sure server rooms and wiring closets are locked and protected from environmental elements (humidity, heat, and cold), and allowing only certain individuals to access work areas that contain confidential information.

Logical Controls

Logical controls (sometimes called technical controls) are the software tools used to restrict subjects’ access to objects. A subject can be a user or a process, whereas an object is any system resource. These controls are core components of operating systems, add-on security packages, applications, network hardware devices, protocols, encryption mechanisms, and access control matrices. They work at different layers within a network or system and need to maintain a synergistic relationship to ensure there is no unauthorized access to resources and that the resources’ availability, integrity, and confidentiality are guaranteed. Technical controls protect the integrity and availability of resources by limiting the number of subjects that can access them and protecting the confidentiality of resources by preventing disclosure to unauthorized subjects.

Administrative Controls

Administrative controls are security mechanisms implemented by management primarily through policies and procedures. An example of this is personnel controls, which indicate how employees are expected to interact with security mechanisms and address noncompliance issues pertaining to these expectations. These controls indicate what security actions should be taken when an employee is hired, terminated, suspended, moved into another department, or promoted. Specific procedures must be developed for each situation, and many times the human resources and legal departments are involved with making these decisions.

Control Selection

A good way to reduce the likelihood of incidents and disasters is to ensure your security plan includes the right set of tools. These controls need to be carefully considered in the context of your own conditions in order to decide which are effective and which aren’t. The first step is to understand the risks. The core concept here is that you can’t ever eliminate all risks and should therefore devote your scarce resources to taking the most likely or dangerous risks and mitigating them to a point where their likelihood is acceptable to the senior leaders.

Once you are fixed on the right set of risks, you can more easily identify the controls that will appropriately mitigate them. The relationships between risks and controls is many to many, because a given risk can have multiple controls assigned to it just like a given control can be mitigating multiple risks. In fact, having multiple controls mitigating one risk, though it may be less efficient, may provide resiliency in protecting a particularly valuable asset. The selection of controls is driven by your organizational parameters and your selection criteria.

Organizationally Defined Parameters

Unsurprisingly, organizational policies play a large role in control selection and determine the values of key parameters in the process. An organizationally defined parameter is a variable that defines selected portions of the controls to support specific organizational requirements or objectives. In some cases, the minimum and maximum values of these parameters are dictated by laws or government regulations. Most frequently, however, these values (or range of values) correspond to the organization’s risk appetite. Examples of these organizationally defined parameters are the frequency with which system backups must be conducted, the time before a data breach must be disclosed, and the maximum number of people who can have access to particularly sensitive information.

Selection Criteria

The selection of security controls should always be driven by a risk assessment. Risk to the confidentiality, integrity, or availability of information resources, combined with the organization’s risk appetite, will determine the baseline security levels for each system. The baseline security level is the minimally acceptable set of protections for a given resource. Of course, there may be additional requirements that are driven by factors such as recommendations from the board or from external advisors or preferences from senior leaders. The set of security control selection criteria consists of the baseline security levels for each system combined with any additional requirements imposed by laws, regulations, or policies. This last source is usually captured in the organizationally defined parameters described in the previous section.

Once security controls are selected, they should be validated. This means that we compare three sets of values: the base risk exposure of the asset, the predicted risk exposure after applying the control, and the actual exposure after applying the control. A validated security control will always reduce the risk to the asset by at least the predicted amount.

Regulatory Compliance

Some organizations are subject to governmental statutes and regulations that may impose threshold requirements on securing information systems. Typically, being noncompliant with applicable regulations can lead to fines, penalties, and even criminal charges. While describing all aspects of regulatory compliance is beyond the scope of this book (and the CySA+ exam), you should be familiar with the more common laws and regulations, highlighted here:

•  Sarbanes-Oxley Act (SOX)   This law, enacted in 2002 after the Enron and WorldCom financial crises, is intended to protect investors and the public against fraudulent and misleading activities by publicly traded companies. Its effect on information security controls is mostly in the area of integrity protections. SOX-regulated organizations have a higher bar when it comes to ensuring that digital records are not improperly altered.

•  Payment Card Industry Data Security Standard (PCI DSS)   This industry standard applies to any organization that handles credit or debit card data. We already discussed it in Chapter 5, but it bears repeating that its main impact on security controls is focused on vulnerability scanning.

•  The Gramm-Leach-Bliley Act (GLBA)   This 1999 law applies to financial institutions and is intended to protect consumers’ personal financial information. Notably, it includes what is known as the Safeguards Rule, which requires financial institutions to maintain safeguards to protect the confidentiality and integrity of personal consumer information.

•  Federal Information Security Management Act (FISMA)   Enacted in 2002, FISMA applies to information systems belonging to or operated by federal agencies or contractors working on their behalf. Among its key provisions are requirements on the minimum frequency of risk assessments, security awareness training, incident response, and continuity of operations.

•  Health Insurance Portability and Accountability Act (HIPAA)   This law mostly deals with improving the healthcare system, but it has important elements that impact information security policies and procedures. Significantly, it includes the Security and Privacy Rules, which place specific requirements on protecting the confidentiality, integrity, availability, and privacy of patient data.

Verification and Quality Control

There is an old Russian proverb that says “trust, but verify.” It is not uncommon for organizations to put significant amounts of effort into developing frameworks, policies, procedures. and controls only to discover (sometimes years later) that their security posture is not what they thought. Every implementation should be followed with verification and quality controls to ensure it was done properly. Just as importantly, there should be an ongoing periodic effort to ensure that the safeguards are still being done right and that they are still effective in the face of ever-changing threats.

Verification, in the context of information security, is the process of ensuring that policies and procedures are being followed. Quality control is the process of sampling our controls and ensuring they provide a certain baseline of security, which is to say they are effective against previously identified risks. As a CySA+, you should be aware of some of the main ways in which organizations conduct verification and quality control, which we highlight in the next sections.

Audits

An audit is a systematic inspection by an independent third party, oftentimes driven by regulatory compliance requirements. Though it is certainly possible for an organization to call in auditors to assess information security or other aspects of the business, the costs associated with this sort of activity make it prohibitive in most cases. That being said, a growing number of organizations conduct nonregulatory requirements when they want to be sure that some aspect of their security is up to a specific set of standards.

Assessments

An assessment is any process that gathers information and makes determinations based on it. This rather general term encompasses audits and a host of other evaluations, such as vulnerability scans and penetration tests. More important than remembering its definition is understanding the importance of continuous assessments to ensure that the security of your systems remains adequate to mitigate the risks in your environment. Among the more popular assessments are the following:

•  Vulnerability assessment

•  Penetration test

•  Red team assessment

•  Risk assessment

•  Threat modeling

•  Tabletop exercises

Every organization should have a formal assessment program that specifies how, when, where, why, and with whom the different aspects of its security will be evaluated. This is a key component that drives organizations toward continuous improvement and optimization. This program is also an insurance policy against the threat of obsolescence caused by an ever-changing environment.

Certification

Certification is the comprehensive technical evaluation of the security components of a system and their compliance with applicable regulations. A certification process may use safeguard evaluation, risk analysis, verification, testing, and auditing techniques to assess the appropriateness of a specific system. The goal of a certification process is to ensure that a system, product, or network satisfies all security requirements. This process is usually applied whenever a new component (for example, a server or sensor) is being introduced into an existing system, or whenever new systems are provisioned for the organization.

Some organizations have a second step called accreditation before introducing the new capability. Accreditation is the formal acceptance of the adequacy of a system’s overall security and functionality by management. The certification information is presented to management, or the responsible body, and it is up to management to ask questions, review the reports and findings, and decide whether to accept the product and whether any corrective action needs to take place. Once satisfied with the system’s overall security as presented, management makes a formal accreditation statement. By doing this, management is stating that it understands the level of protection the system will provide in its current environment and understands the security risks associated with installing and maintaining this system.

Maturity Models

The maturity of an organization with regard to cybersecurity is a measure of how introspective its security processes are. In other words, if there is no real awareness of processes and security is managed through crises, we can conclude the organization is very immature. On the other hand, if there are formal, documented processes that are periodically examined for the purpose of continuous improvement, we can conclude that the organization is very mature. There are a number of maturity models, but perhaps the most useful is the one developed by Carnegie Mellon University’s Software Engineering Institute, known as the CMMI.

Capability Maturity Model Integration (CMMI) is a comprehensive, integrated set of guidelines for developing products and software. It can be used to evaluate security engineering practices and identify ways to improve them. The model describes procedures, principles, and practices that underlie process maturity. This model was developed to help software vendors improve their development processes by providing an evolutionary path from an ad hoc “fly by the seat of your pants” approach to a more disciplined and repeatable method that improves quality, reduces the lifecycle of development, provides better project management capabilities, allows for milestones to be created and met in a timely manner, and takes a more proactive approach than the less effective reactive approach. It provides best practices to allow an organization to develop standardized approaches that can be used across many different groups. The goal is to continue to review and improve upon the processes to optimize output, increase capabilities, and provide higher-quality products and services at a lower cost through the implementation of continuous improvement steps.

The five maturity levels of the CMMI model are depicted in Figure 11-3 and described in the following list.

Figure 11-3   Capability Maturity Model Integration

1.  Initial   The development process is ad hoc or even chaotic. The company does not use effective management procedures and plans. There is no assurance of consistency, and quality is unpredictable. Success is usually the result of individual heroics.

2.  Repeatable   A formal management structure, change control, and quality assurance are in place. The company can properly repeat processes throughout each project. The company does not have formal process models defined.

3.  Defined   Formal procedures are in place that outline and define processes carried out in each project. The organization has a way to allow for quantitative process improvement.

4.  Managed   The company has formal processes in place to collect and analyze quantitative data, and metrics are defined and fed into the process-improvement program.

5.  Defined   Optimizing The company has budgeted and integrated plans for continuous process improvement.

Chapter Review

This chapter is a bit longer (and perhaps drier) than others in this book, but it is packed with important information that will allow you to understand security frameworks, policies, procedures, and controls. While you will probably see a handful of specific questions on these topics in the CySA+ exam, you will definitely see their influence not only on most exam questions, but in your real-world organization. Though many of us prefer to spend our time fighting our cyber foes or improving our technical defenses, it is just as important to develop the formal documents that will ensure that the entire organization is pulling in the right direction. Without the appropriate policies and procedures in place, our efforts may very well ultimately be doomed to fail at securing our systems.

Questions

1.  Which of the following is not a category for access controls and their implementation?

A.  Administrative

B.  Physical

C.  Virtual

D.  Logical

2.  Which is the NIST publication that outlines various security controls for government agencies and information systems?

A.  Special Publication 800-53

B.  Special Publication 800-37

C.  ISO/IEC 27000

D.  ISO/IEC 27001

3.  Which of the following standards, composed of five core volumes, is widely accepted for service management of information technology assets?

A.  Information Security Management System (ISMS)

B.  Cyber Security Framework (CSF)

C.  The Open Group Architecture Framework (TOGAF)

D.  Information Technology Infrastructure Library (ITIL)

4.  Which of the following NIST publications describes a voluntary cybersecurity structure for organizations that are part of the critical infrastructure?

A.  Cyber Security Framework (CSF)

B.  International Organization for Standardization (ISO)

C.  Information Security Management System (ISMS)

D.  Control Objectives for Information and related Technology (COBIT)

5.  The ISO/IEC 27000 series describes which of the following?

A.  Control Objectives for Information and related Technology (COBIT)

B.  Information Security Management System (ISMS)

C.  Architecture Development Method (ADM)

D.  International Electrotechnical Commission (IEC)

6.  Who is responsible for ensuring that data security controls are in place, defining classification requirements, and approving disclosure?

A.  Systems administrators

B.  Chief Security Officer

C.  Data owners

D.  Chief Information Officer

7.  What device is part of a formal process to improve a cybersecurity posture by developing comprehensive and repeatable security processes unique to the organization?

A.  Verification

B.  Maturity model

C.  Quality control

D.  Regulatory compliance

8.  Which component of the Cyber Security Framework describes the degree of sophistication of cybersecurity practices?

A.  Framework Core

B.  Implementation Tiers

C.  NIST SP 800-53 control categories

D.  ITIL processes

9.  Which are the key functions of the Framework Core of the Cyber Security Framework (CSF)?

A.  Identify, Protect, Detect, Respond, Recover

B.  Identify, Process, Detect, Respond, Recover

C.  Identify, Process, Detect, Relay, Recover

D.  Identify, Protect, Detect, Relay, Recover

10.  The directives that originate from senior management and govern the role of security practices in an organization are referred to by which term?

A.  Administrative policy

B.  Technical policy

C.  Security policy

D.  Physical policy

Answers

1.  C. Access controls are the mechanisms put into place to protect the confidentiality, integrity, and availability of systems, and are categorized as administrative, logical, or physical.

2.  A. The NIST released Special Publication 800-53 (Security and Privacy Controls for Federal Information Systems and Organizations), which aims to establish a unified information security framework for the federal government and related organizations.

3.  D. The Information Technology Infrastructure Library (ITIL) is the de facto standard of best practices for IT service management. It provides the goals, the general activities necessary to achieve these goals, and the input and output values for each process required to meet these determined goals in a common language.

4.  A. The CSF focuses on aligning cybersecurity activities with business processes and including cybersecurity risks as part of the organization’s risk management processes. The Framework consists of three parts: the Framework Core, the Framework Profile, and the Framework Implementation Tiers.

5.  B. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) 27000-series, also known as the “ISMS Family of Standards,” provides best practice recommendations on information security management.

6.  C. Data owners classify data and are ultimately responsible for its protection, use, and disclosure.

7.  B. Maturity models are used to create processes that are unique to the operating environment and help improve operational performance and the security posture.

8.  B. CSF 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).

9.  A. The Framework Core consists of five functions that can provide a high-level view of an organization’s management of cybersecurity risk: Identify, Protect, Detect, Respond, Recover.

10.  C. A security policy is guidance produced by the senior management, policy board, or committee that dictates what role security plays within the organization.