Policy Overview

A policy starts with an overview. An overview can explain the history of the policy or situation prior to the policy being established, the scope of the policy—how and to whom or what it applies, when the policy applies, the intended audience that is expected to review the policy, and prerequisites or other details needed to comprehend the policy’s meaning. Some of these items can be omitted if other sections of the policy cover the topic, such as a section dedicated to describing the history of the document. However, a concept may be stated more than once in a policy—the overview may include items that are repeated later in the policy because the overview is intended to be an introduction to the policy topic, which might require the reader to understand certain details before proceeding to any other topics within the policy. There is a lot of flexibility for developing an overview, but keep in mind that as the first part of the policy, the overview sets the tone for the rest of the document. Also keep in mind that the overview may be the only part of the policy that some people review.

Policy Purpose

The purpose of a policy explains why the policy exists. Sometimes, a policy exists to meet a mandatory requirement. Some examples could be a policy enforcing HIPAA requirements to protect user privacy, meeting business goals such as reducing operational costs, or even meeting another policy requirement. Other times a policy’s purpose is to reduce risk, meaning that conforming to the policy will reduce the chance of some unwanted action(s) from occurring. An example is banning the use of USB drives in order to prevent the release of confidential data of the company, its partners, and customers. The policy purpose is critical because it answers questions regarding why this policy must be met.

Policy Scope

A policy’s scope defines what is and what is not included in coverage of the policy. The scope can include types of people, technology, and behavior as well as what is associated with each of these items. An example is listing employees and those that interact with employees. For this example scope statement, coverage would not include guests unless the guests have interacted with an employee but it would include employees and contractors. A scope should be developed in a whitelist format, meaning the policy must specify only what is covered and assume anything else is not covered. Using a blacklist approach such as “all nonemployee assets” would not be recommended because a nonemployee asset could be almost anything. It is better to specify more specific categories whenever possible, such as “nonemployee mobile devices, tablets, or IT equipment.”

Policy Statement

The policy statement is where the details (the meat and potatoes) of the policy are explained. Policy statements are written in a high-level format and can reference other sources, such as procedures, as a way to explain what is required to properly meet the goals of the policy. A policy can state multiple items and group content based on similar concepts. For example, all topics that cover protecting information could fall under a section titled “Security and Proprietary Information.” Grouping concepts within a policy works well; however, recommended practice dictates that you split up a policy into more-focused policies if too many categories are needed to properly cover the policy concept.

Policy Compliance

The policy compliance section states how the policy will be validated, what are the potential exceptions to the policy and the possible outcomes if someone fails to comply with the policy. This section is important not only to explain the validation process of a policy, but also to identify who is responsible for validating compliance and where to seek requests for exceptions. Will the InfoSec team enforce validation of the policy using detection tools, monitoring techniques, etc., or is it up to the user? Will a specific group have the authority to grant an exception to the policy? This section should answer these questions, though it shouldn’t specify individuals who are enforcing the policy or how to contact them. Those details can change often and thus should be included in a procedure that can be referenced by the policy. An example resource could be “IT Security” or “The Security Operations Center,” which both are generic enough to accommodate change within those groups. If a specific contact must be included, it is best to use a generic contact method, such as [email protected], that is tied to the current team within the IT security team.

Policy compliance must also state what will occur if the policy is not met. An example of good use of language for noncompliant behavior could be “Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.” This example provides the opportunity for the policy violator’s manager and/or human resources to determine the specific outcome if a policy is not met.

Related Standards, Policies, Guidelines, and Processes

This section is ideal for referencing other sources related to the policy. Sources can include other policies that align with this policy’s goals, sources that are referenced within this policy such as another larger policy, related procedures that would define in more detail what would be required to enforce this policy, related disciplinary and legal details, or anything else that would make sense to associate with this policy.

Definitions and Terms

For the definitions and terms section, include any definitions and references that will help the reader understand the policy. For example, if the topic of phishing is covered within the policy, a reference to the definition of phishing should be included in this section, not only to explain what phishing is, but also to explain how the term is used within this policy. Some concepts can be interpreted in different ways, and this section can help clarify which definition is being referenced. For example, if the policy covers a denial-of-service (DoS) concept, it might be appropriate to explain in this section if the denial-of-service example leverages a large volume of systems (known as a volumetric DoS attack) or exploits a vulnerability within a protocol to cause the system to become unavailable, which is a different type of DoS attack. Best practice is to consider the audience of a policy and include definitions for any terms that a reader might be unfamiliar with or terms that would need more clarity to understand how they are being used. A reference symbol such as * could be placed next to any term in the policy that the reader could seek out in this section for more clarification.

History

This section lists when the document was created and when any updates have been made. It is ideal to include the date of the change, who made the change, and a summary of the change. All three of these pieces of information are important to help validate how often changes are made and who to question about any changes. Recommended practice dictates changing the version of the policy and tracking version updates within this section, including the changes that were made to the new version.

Steps for Launching a New Policy

Launching a new policy should include the following three general steps to inform the organization about the changes associated with the new policy:

1. Distribute the policy. For a policy to be legally enforceable in relation to employees, the employer must bring it to the attention of all employees. Each employee that is impacted by the policy should be provided a copy of the policy, either in electronic form, hard copy, or both. Employees need to have easy access to any policy that impacts them, again either electronically, such as an intranet resource, or in hard copy, such as in a department policy manual.

2. Obtain acknowledgment of receipt. It is important to have each impacted employee sign and date an acknowledgment stating they received, read, and understood the policy and were afforded an opportunity to ask questions about it. File a copy of the acknowledgment in the employee’s personnel file in the event you require it at a future date. There will always be a handful of employees who don’t (or won’t) sign such acknowledgments; in those cases, two management members can themselves sign an acknowledgment stating that they gave “the person” a copy of the policy but “the person” refused to sign the acknowledgment.

3. Provide advance notice. If the new or changed policy significantly affects or changes any employment rights or benefits, such as vacation rights, you need to give employees advance notice of the policy implementation and a grace period for the change to take effect. Otherwise, the change can amount to “constructive dismissal.” Constructive dismissal occurs when the employer unilaterally changes a fundamental term(s) or condition(s) of employment, effectively breaching the employment contract. The employee can either accept the change, essentially agreeing to the new contract, or refuse to accept the change, accept the employer’s termination of the contract, and sue the employer for wrongful dismissal. Just what amounts to a fundamental change and the length of the required advance notice depends on the circumstances. In general, however, the more significant the change, or the longer the employee’s service, the longer the advance notice of the change that’s required.

How each of these three actions is carried out will depend on the impact the policy has on the associated parties. Minor policy changes or new policies with minor impact require far less advanced notice than a major policy change or a new policy with major impact. I find it common for the distribution of electronic or physical documentation for minor policy changes or new policies with minor impact to occur during an annual policy reminder session, training, or notification that includes the combination of various minor changes, rather than bothering employees with documentation for every minor policy change or new policy with minor impact. Acknowledgment of receipt can be a required action item following the policy reminder session, training, or notification, allowing for the acceptance of all policy changes at once as well as any new policies.

Certification and Accreditation

A formal way to enforce policies is through a certification and accreditation process. The certifier is the party responsible for assessing if policy elements are being met. This practice is common for meeting formal certification programs such as PCI DSS (discussed later in the chapter), but can also be part of the process to enforce organization-driven policies. For certification programs, organizations will use a third-party certifier to validate that the processes, systems, products, events, or skills meet some existing standard. For general polices, an organization can authorize one or more people within the organization to certify if a policy is or is not met. This team is typically part of the compliance team.

Accreditation means a formal declaration by the certifier that what the certifier was reviewing meets all requirements. If an organization is looking to meet a formal certification program, once the organization passes all checks by the certifier, the organization can be accredited as being compliant. The entity that declares accreditation not only is confirming that the organization has met all requirements, but also is owning all responsibilities for everything that it has accredited. If a violation is found post accreditation, the accreditor might be liable, depending on the situation. The same concept applies to an accreditation given by the compliance team within an organization.

Regarding general policies, somebody with authority needs to be able to declare an accreditation when polices are met. For example, if there are minimal security requirements that must be put in place before a server is allowed to connect to the network, somebody needs to know how to validate that those security controls are in place, representing the certifier, and somebody needs to formally approve the system is ready to go live, representing the accreditor. Without these two processes, polices will not be enforced because no one will know how to validate against a policy and no one will be concerned about breaking a policy because no formal validation is put in place.

When it comes to the success of a policy, determining how the policy is executed by the organization is critical. Procedures fill in the missing details for policies. This brings us to the topic of procedures.

Procedure Document

The format of a procedure document can vary as long as the required steps are included to properly execute all required tasks. Topics included in a procedure document should cover the purpose of the procedure, what is required to perform the desired tasks, when tasks should be performed, who is responsible for the tasks, and any other required steps that must be performed to properly execute the procedure. Let’s look at an example procedure document for registering a website.

This example procedure document lists the specific details regarding what is required to register a website within the company. All details are required to be sent to [email protected], which will respond with status updates as the request is being processed. Responsibilities for both the requestor and organization are listed, including expectations for notification of the website expiring as well as who should renew the website. The steps provided in this document are clear enough that any employee who wants to register a website within the organization can follow the procedure to properly submit a request. Other procedure sections would likely be included with this example procedure section, including a section covering procedures for deploying content on the website, securing the website, and performing other website-related tasks. These topics could all be grouped under one large procedure document for deploying websites at the company, or each topic could be a separate procedure document that references other documents as users need to request, stand up, and maintain a website at the company. Also, all of these procedures could fall under one or more policies, such as a policy for “deploying websites at <COMPANY>.”

One theme I have continued to emphasize is that there isn’t a set rule for developing policies and procedures. While this flexibility is great for accommodating creativity and the many dynamics found within an organization, having an open-ended format for building process documentation can cause confusion when an organization attempts to build and validate well-thought-out policies and procedures. I find that many organizations don’t know how to validate their new or existing policies and procedures or identify gaps and are therefore unsure if their policies and procedures are effective. One recommended approach to testing an organization’s policies and procedures is to perform a tabletop exercise. In the next section I will walk you through developing and executing a successful tabletop exercise. This will allow you to validate and improve your processes.

Tabletop Exercise Options

There are different approaches to executing a tabletop exercise. One approach is to run the same scenario for different groups within the organization, which means performing multiple smaller tabletop exercises. For the ransomware example, the organization could first work with desktop support to capture how they would respond to a ransomware situation. Next, the organization could meet with the network security team and run the same ransomware scenario, but with a focus on their impact on the overall incident response. Using this smaller-group approach is ideal for keeping the exercise focused with fewer people involved and possibly reducing concern that other teams would influence or impact how a specific team would respond during the tabletop exercise.

Another approach to delivering a tabletop exercise is to include managers from each department and obtain input from all departments during the same meeting. This approach allows each department to contribute while the scenario is being covered, rather than requiring the team delivering the tabletop exercise to combine the responses of all the individual group exercises into a single tabletop exercise results document. This also allows for real-time debate as current and potential future responses based on changes occurring post table top exercise are analyzed. Some concerns when including all teams within an organization are the size of the meeting, the time required to hear feedback from all included members within the tabletop exercise, and the potential for conflict between departments. Limiting the tabletop exercise to only department managers can mitigate these and other problems; however, department managers might not know the details required to answer a question during the tabletop exercise. For example, a manager might not know the specific technology that would be used, but would know which member of his or her team would be able to answer such questions. Using the manager-led tabletop exercise format would require managers to take any unanswered questions back to their team and later provide a response.

Tabletop Exercise Execution

The best format for a tabletop exercise typically depends on the scenario that is being tested. However, the following tips apply generally to executing a successful tabletop exercise, paraphrased from the CSO article, “6 Tips for Effective Security Tabletop Testing” by Bob Violino:

• Take time to prepare for the exercise: Invest time in developing the objectives and the scope and selecting the proper participants. Planning is often the most time-consuming phase but will pay off regarding the success of the exercise. Having the wrong people involved or a scope that is too narrow or too broad will not only produce poor results but also cause those involved to believe their time was wasted, leading to a lack of support for any recommended adjustments following the tabletop exercise.

• Involve multiple parties from different departments: Security is the responsibility of every person in an organization. That means the response to an incident will impact many different departments. The best tabletop exercise results come from involving all parties that would be impacted and could provide value or cause complications during the incident response.

• Establish the ground rules up-front: A tabletop exercise represents walking through stressful situations. Some people might want to speak openly regardless of whether the topic is positive or negative, while others might not want to participate unless called upon. Not addressing the different personalities in the room will lead to frustration and loss in support for the results of the exercise. Make sure to set expectations up-front for required participation, what is and is not permitted to be discussed during the exercise, what can and cannot be talked about after the meeting, and any other ground rules to ensure a successful use of everybody’s time.

• Leverage external resources if available: Tabletop exercise services have been used by many organizations, and best practice documentation is available. Hiring a consultant that provides tabletop exercise services can be valuable because the consultant offers an external, unbiased voice and has experience executing successful tabletop exercises. If your team has never delivered a tabletop exercise, it is recommended to seek external support and learn from the best practices of others before performing your own internal exercises.

• Broader is likely better: Discussion of some tabletop exercise topics can either go very deep into details or remain broad. Keeping the discussion broad likely is better unless the team involved in the tabletop exercise believes the topic being covered requires specific details. For most tabletop exercises, details can be captured by the expert after the tabletop exercise, allowing for all topics to remain broad and for all team members to be engaged (versus the risk of only hearing from specific experts). Keeping conversations broad also shortens the duration of the tabletop exercise because details are not addressed until after the meeting.

• Use realistic scenarios: The purpose of a tabletop exercise is to evaluate the response to a potential future situation. All scenarios need to be as realistic as possible in order to produce a realistic result.

Tabletop Exercise Format

It is recommended to include certain topics within the tabletop exercise document that is used during and referenced after the exercise is performed. First, an introduction should explain the purpose of the exercise. A goals section should be included (or goals should also be listed in the introduction section) so that the expected outcome is clear. All details about the meeting need to be documented, including the date, facilitator, and all participants. All processes that are evaluated should also be listed, including desired policies and procedures that might not exist but are planned to be developed, with the current status noted. The tabletop exercise scribes need to document each scenario, including its target capabilities being tested, objectives for the exercise, and details regarding how the organization would respond if the situation occurred. Documentation of recommended remediation may or may not be included depending on whether the purpose of the tabletop exercise is to just evaluate processes or to also include corrective actions. All of this needs to be included in the tabletop exercise post event documentation.

I am often asked which tabletop scenarios are best for an organization to run through. Again, my answer is it depends on your business, as no single threat list fits all organizations. The tabletop exercise scenario list for an organization that runs an online business will be very different than one for a school. If you need a general guideline for scenarios, I highly suggest considering using playbook templates. Chapter 8, “Threat Hunting and Incident Response,” and Chapter 10, “Data Orchestration,” both provide a deep look at playbooks. In both chapters, I will run through different playbook examples provided by the Incident Response Consortium (IRC) at https://www.incidentresponse.com/playbooks/. Figure 6-1 shows the gallery of free playbooks available from IRC, which include recommended steps for different parts of responding to specific threats. Playbook templates are a great resource for building a template for your tabletop exercise, but I highly recommend prioritizing the threats you expect to impact your organization versus running through random playbook templates.

Tabletop Exercise Template Example

This section presents an example of a tabletop exercise template. If you decide to use a playbook template to develop your tabletop exercise template, you can use this example as a way to structure what questions you will ask based on the steps recommended in the playbook template. For example, if a malware outbreak playbook suggests informing IT about the situation, you would include a question such as “Who would be informed when a malware outbreak event is identified?” The same process would apply as you evaluate your SOC service playbooks against a tabletop exercise. Playbooks will be covered in more detail in Chapters 8 and 10.

The following is a sample tabletop exercise template for disaster planning featuring many of these suggested sections.

Another approach to validating policies and procedures outside of performing a tabletop exercise is to compare what would be performed by an organization against what is considered industry best practice. This leads us to the topic of standards, guidelines, and frameworks, all of which can be reference points for what should be included in your organization’s policies and procedures. Standards, guidelines, and frameworks are also useful for referencing what steps should be taken during a tabletop exercise so that existing policy and procedures can be compared against what the industry would recommend should be done when addressing a scenario.

NIST Cybersecurity Framework

Introduced in Chapter 1, the NIST Cybersecurity Framework (CSF) is one of the most popular frameworks consisting of standards, guidelines, and best practices for dealing with cybersecurity-related risk. Chapter 1 also introduced the NIST Framework Core and five framework Functions, as shown in Figure 6-2.

As a refresher from Chapter 1, each of the five functions of the NIST Framework Core has a high-level view on one aspect of security. Anything under the Identify function would represent steps used to manage risk to systems, people, assets, data, and capabilities. The Protect function would cover topics that develop and implement people, process, and technology to reduce risk proactively and ensure delivery of critical services. Reactive risk recovery topics would fall under the Recover function since they cover actions that follow an incident, including topics covering how to restore and resist future compromise. Detect and Respond functions cover topics that involve how an organization identifies and responds to incidents.

ISO/IEC 27005

The International Organization for Standardization (ISO) creates documents that provide requirements, specifications, guidelines, or characteristics that can be used consistently to ensure that materials, products, processes, and services are fit for their purpose. Part of ISO’s value is its family of standards that provide best practices for various cybersecurity concepts.

One popular publication is ISO/IEC 27005, Information technology – Security techniques – Information security risk management, which offers guidelines for information security risk management. As shown in Figure 6-3, the ISO/IEC 27005 steps for managing information security risk include establishing context; conducting a risk assessment by identifying, analyzing, and evaluating risk; and then treating the risk. Ongoing activities during these steps include communication, consultation, monitoring, and review. Any organization can use the details provided in ISO/IEC 27005 to help improve how it handles information security risk management through auditing against ISO recommendations or performing a tabletop exercise and using ISO recommendations as the source against which to compare existing practices.

An example use case from the ISO/IEC 27005 publication is section 7.2 under “Context establishment,” which focuses on a suggested information security risk management approach. ISO recommends using the appropriate risk management approach that addresses basic criteria such as risk evaluation criteria, impact criteria, and risk acceptance criteria. Additionally, ISO recommends that resources should be able to perform risk assessments as well as establish risk treatment plans, define and implement policies and procedures, monitor controls, and monitor the information security risk management process. Section 7.2 remains high level, making it an ideal resource for developing a risk management policy. Other sections of ISO/IEC 27005 provide more details that can help organizations develop supporting procedures for new or existing policies; however, procedures should always contain specific details that relate to your organization.

There are many other information security topics covered by ISO guidelines. For example, ISO/IEC 27034 provides guidance on information security to those specifying, designing, and programming or procuring, implementing, and using application systems. An application system normally consists of a user interface, business logic, and a database of some sort. ISO/IEC 27002 is extremely popular and an internationally recognized standard code of practice for information security controls. ISO offers hundreds of papers covering various IT topics, which you can search through at https://www.iso.org.

CIS Controls

The Center for Internet Security (CIS) provides best practice solutions for cyber defense and builds and leads industry groups to enable an environment of trust within the cyber community. One CIS resource that is extremely popular is the CIS Controls, security best practices that provide specific and actionable ways to reduce the risk of exploitation. The CIS Controls are derived from the most common attack patterns highlighted in leading threat reports and vetted across a broad community of industry security professionals. Members associated with vetting the CIS Controls include the NSA Red and Blue Teams, U.S. Department of Energy Nuclear Energy Labs, and various law enforcement agencies, which all give creditability to this resource.

The CIS Controls are broken down into the following three categories, depicted in Figure 6-4 (based on CIS Controls Version 7.1, the current version at the time of writing):

• Basic CIS Controls: Anything basic should be considered security table stakes, meaning all organizations should have some form of the recommendations in the basic category applied to their processes. Example basic recommendation categories include identifying what’s on the network and dealing with vulnerabilities.

• Foundational CIS Controls: Defenses against threat categories such as malware defense or protecting an organization’s DMZ or network boundary.

• Organizational CIS Controls: Controls that impact the entire organization, such as incident response.

CIS takes into consideration the type of organization that would use its recommendations based on the organization’s size and expected funding. For example, a small restaurant would likely not be able to invest in an expensive vulnerability management tool to evaluate a few endpoints used within its business. CIS uses a three-tier grouping system to identify which type of organization should consider the recommendations being offered. Figure 6-5 shows how CIS defines its system for grouping the different types of organizations expected to use the CIS Controls resource.

A sample use of the CIS Controls is referencing CIS Sub-Control 2.2, which states “Ensure Software is Supported by Vendor.” This recommendation is classified as an “identify” security function and applies to all three organization groups, which means any size organization should follow this recommendation. The explanation section of this Sub-Control further defines this recommendation as only using authorized software according to the vendor and listing any unauthorized software as unsupported and a potential risk.

Any size organization can benefit from referencing the CIS Controls. They are short, tactical, and well-vetted by industry experts.

ISACA COBIT 2019

ISACA is an independent, nonprofit, global association that develops guidelines for information system best practices. One of its most popular offerings is the COBIT 2019 Business Framework for Governance and Management of Enterprise IT. COBIT 2019 offers detailed enabler guides that focus on governance and management best practices. COBIT 2019 also has professional guides targeting implementation, information security best practices, guidance on assurance, risk management, and other security topics. COBIT 2019 is available only to members, for a small fee. Learn more about COBIT 2019 and other ISACA offerings at https://www.isaca.org.

FIRST CSIRT Services Framework

The Forum of Incident Response and Security Teams (FIRST) is the global forum of incident response and security teams. FIRST offers various standards, publications, and best practice guides that are designed to provide best practices for various cybersecurity concepts. One popular offering from FIRST is the Computer Security Incident Response Team (CSIRT) Services Framework. The CSIRT Services Framework is a high-level document describing a collection of cybersecurity services and associated functions other security teams can learn from. The CSIRT Services Framework is essentially a guideline for best practices for incident response.

The CSIRT Services Framework Version 2.1 is composed of four elements: service areas, services, functions, and sub-functions: The five service areas are Information Security Event Management, Information Security Incident Management, Vulnerability Management, Situational Awareness, and Knowledge Transfer. Each service area has services, which in turn have different functions and sub-functions. For example, the Information Security Incident Management service area has a service named Artifact and forensic evidence analysis, which contains four functions: media or surface analysis, reverse engineering, runtime and/or dynamic analysis, and comparative analysis. Each service, function, and sub-function has a section describing what it is, a section describing its purpose, and a section describing its outcome (measurable results of implementing it). Each function also has a list of sub-functions, if applicable. For example, function 6.3.2, reverse engineering, has four sub-functions, which are static analysis, code reverse engineering, potential behavior analysis and description, and potential signature design.

The CSIRT Services Framework Version 2.1 can provide value by enabling you to review your policies and procedures against what is listed as best practice for every service area and its associated topics. You can download the latest version of the framework from https://www.first.org/standards/frameworks/.

Exceeding Compliance

It is common practice to use any of the standards, guidelines, and frameworks previously discussed (and others) as reference points for developing and testing your people, process, and technology and as templates for building policies and procedures. Using resources such as a tabletop exercise or leveraging standards, guidelines, and frameworks is great but might not provide enough details to help you generate specific areas of improvement or best understand your specific needs.

As stated at the beginning of the chapter, it is important to understand that compliance is something you either meet or do not meet. It is also important to understand that compliance does not consider all aspects of security, meaning any risk that falls outside of compliance is not taken into account in an audit for compliance. This is why you must establish a baseline for security that exceeds what is required for meeting compliance. To do this, you first need to meet compliance using a formal testing process known as an audit. Once your organization passes an audit, you identify where it may still have risk outside of compliance by using assessments and penetration testing. Next, let’s look at how to meet compliance by using audits.

Audit Example

You should leverage any document that lists requirements to meet what is being audited, such as the targeted policy, and evaluate if capabilities are met. In some cases, it might make sense to use a pass/fail approach, while other cases might require more detailed information. The following is an example template that could be used for auditing a firewall.

The previous audit example shows a checklist approach to auditing a firewall. Each question provides answer options for the auditor to select to determine the appropriate response. Another approach to formatting the responses for this document would be to provide an open response section for each question, allowing the auditor to provide a much more detailed response about his or her findings, in addition to choosing from a predefined selection of choices. Another approach for this document would be to use a scoring system, where each question is worth a value, and then the auditor would add up all the values to generate a score. Any of these approaches work as long as the results successfully establish a repeatable evaluation of the people, process, and technology being audited.

Internal Audits

It is common practice to use audits to validate if specific policies or recommended standards, guidelines, or frameworks are being met within the organization. Audits are also used to validate if required industry regulations such as PCI DSS or HIPAA are being met, as described later in this chapter. The team responsible for performing an audit could be part of the SOC, part of a dedicated compliance team, or a partnership between one or more groups. Many organizations have a dedicated group that performs audits and is led by the chief compliance officer (CCO), who is responsible for overseeing compliance within an organization as well as ensuring compliance with laws, regulatory requirements, policies, and procedures. The CCO is considered the subject matter expert and has the responsibility of establishing standards and implementing procedures to ensure compliance programs are effective in identifying, detecting, and correcting noncompliance with laws and regulations as they apply to the organization. Because the CCO sits on the board, he or she must provide assurance to other senior management that compliance is met as well as develop strategies and responses for any compliance-related complications. This is accomplished by using a combination of audit services and other assessment tools.

External Auditors

Most required industry compliance will have an external team that represents either the government or industry service that mandates the compliance and is responsible for validating if your organization falls within compliance. External auditors might charge a fee and require periodic auditing in order for your organization to be authorized to use a service or certain type of data. You can recruit your own external auditors to validate your current capabilities prior to the scheduled external audit or use internal services for audit preparation. For example, if your organization accepts credit cards as a form of payment, then your organization must comply with PCI DSS. There are companies that can assist with helping you prepare for the official PCI DSS audit and it is highly recommended that you use only external auditors that are approved by the PCI Security Standards Council to ensure a quality service when auditing for PCI DSS. The same concept would apply regarding seeking auditing services for any other type of compliance. You want to ensure the service provider is an authorized auditor for the subject you want to have evaluated.

When you consider external audit services, the following are some general questions you should ask when evaluating a potential audit service provider:

• How does your service validate that it meets the latest version of the topic(s) being audited?

• What guarantees does your service provide if a topic considered compliant is found by another auditor to be noncompliant?

• What are the scope and costs for your services?

• What technology and steps are included within your services?

• What resources and access permissions are required for your service to be performed?

• What risk is associated with using your service?

• How long should the organization wait until performing another audit?

• Do you provide recommendations or remediation services for items that fail the audit?

Audit Tools

Another option you can use to audit for various types of compliance is to leverage cloud or on-premises auditing tools. Auditing tools can provide a template of questions your internal auditors can use to perform auditing services or provide some scanning capacities to gather and assess targets for compliance. An example is using LogicGate’s risk management tools that offer compliance audit capabilities, including assessing for PCI DSS. Some network and security tools might also offer a compliance widget or report to help assist with gathering data for compliance; for example, a firewall might include compliance reports for NIST standards. You can also ask your trusted technology vendors if they offer mappings to popular standards, guidelines, and frameworks. Figure 6-6 shows an example of mapping the Cisco security products to the NIST Cybersecurity Framework. As with auditing services, recommended practice dictates that you validate the tool as an acceptable source for auditing the topic of interest to avoid having inaccurate results. Some vendors might claim to meet audit requirements but would actually only partially meet or outright fail if audited by an authorized service provider.

Audits focus only on specific subtopics found within the topic being evaluated. You need to consider evaluating the entire organization for vulnerabilities regardless of whether the potential vulnerability is related to your organization’s compliance requirements. This is how you exceed compliance: addressing risk beyond what is required to be compliant. The process you can use to evaluate for all vulnerabilities and risk is to perform an assessment and penetration test. First, let’s review the concept of assessments.

Assessment Types

Different types of assessments can be performed. A threat assessment looks at anything that could contribute to a disruption of normal services and operations. The following is a sample format for a threat assessment report.

A vulnerability assessment focuses on identifying, quantifying, and rating weaknesses or gaps within your systems. The following is an example format for a vulnerability assessment report.

A risk assessment is focused on measuring the probability of a security breach occurring and the magnitude of the risk. This approach can provide results in a qualitative view (high, medium, low) or a quantitative view such as on a scale of 1 to 5. The following is an example format for a risk assessment report.

An impact assessment identifies how and the extent to which your business will be affected by a security breach. The following is an example format for an impact assessment report.

It is recommended to use all four assessment methods to evaluate your people, process, and technology. Assessment reports can break up data into sections that focus on these four assessment types or include different columns that cover results from each assessment method. The previous examples could be combined into one large report or be part of a spreadsheet that covers all related topics.

It is common for the scope of an assessment to be much broader than an audit and for assessments to be performed more frequently than audits. Assessments can include various types of people, process, and technology, and performing assessments is commonly one of the services offered by a SOC. Chapter 3, “SOC Services,” covered different types of SOC services, including performing assessments.

Assessment Results

The results of an assessment are used to develop a vulnerability report that includes a list of potential vulnerabilities and details about each. A commonly included detail is the estimated risk associated with the potential vulnerability, to help the organization prioritize which risk to address first. The most common method used in vulnerability reports to help organizations rank the associated risk with an identified vulnerability is the Common Vulnerability Scoring System (CVSS) from FIRST. Essentially, a CVSS score provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. The CVSS is widely accepted in the security industry, and popular security assessment solution providers such as Rapid7, Core Security, and Tenable offer the same CVSS scoring references within their products. You can calculate the associated risk of a vulnerability manually by referencing the CVSS; however, most security solutions will do the calculations for you and rank the vulnerabilities with a scoring or color-coding system. Table 6-1 provides a sample vulnerability report featuring the results from assessing a website, USB devices, and a server. Chapter 9, “Vulnerability Management,” covers the CVSS in much more detail.

Assessment Template

Different assessments will vary regarding the focus of what the outcome report will contain. A vulnerability assessment report will focus on the different vulnerabilities found and their associated severity, such as shown in Table 6-1. A risk assessment report can include vulnerability data, but the report will be more focused on general risk, including quantitative and qualitative computations. A threat assessment report can contain both risk and vulnerability data, but the focus will be on specific types of threats and how they could potentially impact the organization. An impact assessment report will be focused on your organization’s assets and business and explain what to expect if certain types of events were to occur. There are many specific details that could be included depending on the desired outcome for the assessment service. My recommendation is to reference industry guidelines regarding what should be included in the type of assessment report you are looking to perform. An example of a guideline is the MITRE Threat Assessment and Remediation Analysis (TARA), found at https://www.mitre.org/sites/default/files/pdf/pr-11-4982-tara-methodology-description-version-1.pdf, which is a great reference point for a threat-focused assessment.

In addition to the specifics to the type of assessment being delivered, a final assessment report should include general topics, including an executive summary, purpose, list of technologies used, list of who was involved, and a summary of what was found. The next section is an example template for a risk-focused assessment. Many of the sections are common across all assessment reports regardless of the focus. Use this template as a reference for developing your assessment reports. I have left each section blank regarding example input and instead included descriptions about how to fill out each section.

Vulnerability Scanners

One of the most common tools used for assessing vulnerabilities is a vulnerability scanner. Vulnerabilities will be included in all assessment report types since vulnerabilities represent potential attack vectors. You will need to include vulnerability scanning as part of your assessment process. Vulnerability scanners can be automated to perform periodic or on-demand assessments, depending on how they are used. The quality of the results will depend on many factors, including the data seen by the scanner and how the scanner evaluates a target. For example, a credential-based vulnerability scanner would be able to log into an endpoint device and assess the device without its results being impacted by the endpoint device’s enabled security tools such as a host firewall. A non-credential-based scanner would not be able to log into the endpoint, limiting its results to what can be seen and not blocked by enabled security tools such as the host firewall. Chapter 9 covers vulnerability management best practices in more details, including how to use vulnerability scanners to address risk and how to understand the data the scanners produce. Use the steps from Chapter 9 to leverage a vulnerability scanner as part of your assessment process.

Assessment Program Weaknesses

One important concept regarding assessments is that they lack validation of the results. They show “potential” risk rather than actual validated risk. The results being considered potential risk can occur based on how the assessment is performed. Many times, the tools used for an assessment capture data and compare it against a list of known vulnerabilities rather than actually attempting to exploit the vulnerability. This approach can lead to false negatives due to other elements that are not evaluated but are essential to truly understanding the nature of the potential vulnerability. For example, a vulnerability scan may find that a server has many vulnerabilities; however, the server might exist within a contained lab environment and not be a real threat to the organization, or the vulnerabilities that were found might be based on limited data captured by the assessment tool due to the server’s existing enabled security that limits what can be evaluated by the assessment tool. The best way to test any potential vulnerability to ensure that it is really a risk is to attempt to exploit it. Exploiting potential vulnerabilities is part of a penetration testing service.

NIST Special Publication 800-115

NIST SP 800-115, introduced in Chapter 3, identifies four phases of a penetration test: planning, discovery, attack, and reporting. The following is a summary of those phases.

Phase 2: Discovery

The discovery phase is made up of two parts. First, all network ports and services that fall within scope are identified to develop a list of potential targets. Other techniques might be used, such as dumpster diving, with the goal of gathering information and building a potential target list. These data collection steps fall under the category target reconnaissance and are the most time consuming but also the most valuable work. The more quality data that is discovered and collected about a target, the better the capability to identify potential targets to exploit. Some example tools you can use to conduct target reconnaissance are NMAP and masscan to perform port scanning; Shodan to research web-facing resources such as websites, web cameras, and network-enabled IoT devices; and searching social media sources such as LinkedIn and Facebook for details on people that work within the target network.

The second part of the discovery phase is analyzing the potential targets for vulnerabilities. Vulnerability analysis is commonly performed by comparing the services, applications, and operating systems for potential targets against a vulnerability database or using a tester’s own knowledge of vulnerabilities. Tools such as Metasploit from Rapid7 provide a database of known exploits, where you simply type in an identified vulnerability and find various weaponized exploits tied to the weakness. Figure 6-7 shows an example of searching for Apache Struts vulnerabilities within Metasploit. Notice how the number of available exploits expands beyond what can be displayed on the screen!

Phase 3: Attack

Once targets are confirmed, the actual exploitation occurs during the attack phase. Remember that exploitation does not necessarily mean something bad has already occurred. Exploitation can open the path for malicious actions such as pushing a remote-access tool (RAT), ransomware, or other forms of malware to the system. An example of exploitation could be running an Armitage/Metasploit weaponized attack against a system that is vulnerable to an exploitation of Struts, as shown in Figure 6-8. The example shows a system has an open shell, meaning the attacker has full access to the compromised system. From this point, the attacker can perform a number of actions, including using this compromised system as a gateway into the network to perform a new attack against internal systems. In the example, the attacker showcases his or her level of access by running the whoami command.

In other cases, the action of exploitation causes negative results, such as exploitation of a website to take it offline, known as a denial-of-service attack. Another example could be overloading the memory of a switch to cause it to fall back into a hub-like state, allowing an attacker to view all traffic within that device. From a penetration testing viewpoint, using the Cyber Kill Chain is a good way to view the steps that would be involved with exploiting a target and delivering something, which are the same steps penetration testers and real attackers would use against a target. As a refresher from Chapter 1, Figure 6-9 depicts the Cyber Kill Chain. The attack phase of the NIST penetration testing process corresponds to the Delivery, Exploitation, Installation, and Command and Control phases of the Cyber Kill Chain.

Note

Kali Linux and BackBox are great free penetration operating system builds you can download and use for penetration testing efforts. Metasploit is a great resource you can test your attacks against in a free and legal manner.

Phase 4: Reporting

The results of the attack phase are documented in the final phase, the reporting phase. Reporting should also include steps from the other phases so the entire penetration testing process is documented. The language used in a report is extremely important, meaning you must know your target audience and consider the impact that will result based on who reviews the report. I have seen people lose their jobs based on negative feedback about their work or how they were blamed for the results of the penetration testing exercise. I recommend at a minimum that your penetration testing report contain the following information:

• Vulnerabilities: What was found during the penetration test? List all vulnerabilities along with details about what they are.

• Impact: What is the potential negative impact that could occur if a real attacker were to take advantage of a vulnerability found during the penetration testing exercise?

• Likelihood: How hard is it to exploit an identified vulnerability? Do you need root access or connectivity to the internal network, or can anybody from anywhere access and exploit the vulnerability?

• Risk evaluation: How do the identified vulnerabilities impact the overall business?

• Recommendation: What is recommended to reduce the risk of the identified vulnerabilities?

• References: Who was involved in the penetration testing exercise?

• Additional details: Make sure to include any appendices, glossary items, tools used, and other details that would help the reader follow the penetration test report.

Note

SANS offers great resources for templates for penetration testing reports, at https://pen-testing.sans.org/resources/downloads.

Figure 6-10 shows a diagram of the NIST SP 800-115 four-stage penetration testing methodology, which is a high-level view of performing a penetration testing exercise.

Additional NIST SP 800-115 Guidance

NIST SP 800-115 provides much more detail as you read further into the document. For example, the attack stage of the NIST four-stage penetration testing methodology is further broken down into four steps, as shown in Figure 6-11. The first step is to gain access to the target, also known as establishing a foothold. It is possible that the current privilege level will be limited based on how the access was accomplished, so the next step would be to attempt to escalate privileges to a higher level, such as administrator-level access. Once the highest level of system access is achieved, the third step is to browse the system to discover mechanisms to gain access to other systems. The final step represents the results of the exploit, which might be installing a backdoor, removing data (or documenting the potential to do so), or repeating the process against other internal systems. This cycle is repeated until enough results are generated that can be recorded during the reporting stage of the NIST penetration testing methodology.

Penetration Testing Types

Different types of penetration testing services are available and are differentiated based on the agreed-upon scope of the testing. It is common practice to scope a penetration test in a known environment, unknown environment, or partially known environment (prehistorically called white, black, or gray format). The following are definitions of each approach:

• Known Enviroment: All information about the target is provided to the penetration tester. This includes its IP address, what software is running, who accesses the system, and other relevant information. A white-scoped penetration test is commonly performed by system owners responsible for the security of their systems.

• Unknown Enviroment: No information about the target is provided to the penetration tester. It is up to the penetration tester to research anything within scope and discover any potential target as well as attack the target using any method within scope of the service.

• Partially Known Enviroment: Some information about the target is provided to the penetration tester while other details are not. It is common to provide details that an attacker would find if they performed reconnaissance of a target, to reduce the time and cost of the penetration test. It is close to impossible to prevent adversaries from gathering intelligence about your organization using certain sources for their reconnaissance efforts, so some data exposure should be expected.

I recommend leveraging gray penetration testing services whenever using an external paid resource. You can assume and expect that adversaries are capable of researching your organization. Paying the penetration testing service to research your organization during a black-scoped penetration test can quickly increase the cost of the service while providing limited value.

Penetration Testing Planning

Beyond considering the type of penetration test to conduct, penetration testing planning includes other aspects to consider. The following list provides questions that need to be answered as you plan to perform a penetration test or request external penetration testing services. These questions would also need to be answered within any statement of work for a penetration testing service.

• What is the scope of the penetration test?

• What are the priorities for the penetration test?

• Who is authorized to conduct the penetration test?

• What are the data handling requirements?

• What are the penetration test’s logistics?

• Will the penetration test be internal or external?

• How should sensitive data be handled?

• What should occur in the event of an incident?

My recommendation is to develop the requirements for your penetration test and identify potential service providers or develop an internal team to provide the service. To ensure the service will meet your scope, you need to have a scoping meeting, where you meet with the penetration testing team and review the scope of work to ensure all parties understand what needs to be done and what is considered a successful service engagement.

The most important aspect of the service is what is delivered, commonly referred to as the penetration testing report. To ensure that the final penetration testing report contains everything you desire from the service provider, you need to specify everything that needs to be included in your scope of work. The scope of work is essential for identifying what is expected from the penetration testing team.

Compliance Requirements

There are a handful of government-enforced laws and industry requirements that your organization will need to be aware of depending on your line of business. It is also good to know when other organizations must meet an industry compliance requirement as well. Looking back at the PCI DSS example, I once received my credit card receipt at a restaurant and saw that my entire credit card number was printed on it, a violation of PCI DSS. I could’ve reported the violation to my credit card company, but I chose to inform the manager about the issue. According to PCI DSS, the restaurant should have printed only the last four digits of my credit card number on the receipt, sufficient to enable me to confirm the credit card number charged is the one I used; however, the remaining data is protected. I recommend including considerations of who you do business with based on if they meet required industry compliance.

The following are some of the most commonly required industry compliance standards and laws that your organization, or organizations you do business with, may be required to follow:

• PCI: The PCI Data Security Standards help protect the safety of that data. They set the operational and technical requirements for organizations accepting or processing payment transactions, and for software developers and manufacturers of applications and devices used in those transactions.

  Note

  Learn more about PCI at https://www.pcisecuritystandards.org/pci_security/maintaining_payment_security.

• HIPAA: The Health Insurance Portability and Accountability Act of 1996 developed regulations for protecting the privacy and security of health information. This rule applies to health plans, health care clearinghouses, and any health care provider who transmits health information in electronic form, including business associates. The HIPAA Security Rule is broken down into safeguard categories. Technical safeguards evaluate technology that is in contact with HIPAA-protected data. HIPAA also references other guidelines within its technical safeguards, such as what can be found within various NIST standards for what it considers acceptable encryption standards. Physical safeguards target risk to physically accessing HIPAA-protected data and systems with HIPAA data. Topics include inventory of hardware and physical security concepts. Administrative safeguards address policies and procedures and bring privacy rules and security rules together. For example, conducting risk assessments allows an organization to address vulnerabilities in both physical and technical systems. Other administrative topics include developing policies and procedures according to industry-recommended best practices.

  The U.S. Department of Health and Human Services offers various checklists at HHS.gov that you can use to audit your organization for HIPAA compliance. It is up to your organization to validate and meet HIPAA compliance requirements to avoid fines and other negative outcomes.

  Note

  You can download HHS’s summary of the HIPAA Privacy Rule at https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/understanding/summary/privacysummary.pdf.

• SOX: Sarbanes-Oxley Act of 2002, better known as SOX, focuses on corporate fraud by requiring all publicly held companies to enact internal checks and balances and procedures for financial reporting. CEOs and CFOs are directly responsible for the accuracy, documentation, and submission of all financial reports and can be penalized for failure to comply regardless of whether it is intentional or not. SOX also has data security requirements, including use of SOX-compliant software. It is up to your organization to identify if you have SOX obligations and, if so, to meet compliance requirements.

• FISMA: The Federal Information Security Modernization Act of 2014 protects U.S. government data and compliance with it is mandatory for all U.S. federal agencies as well as contractors that wish to do business with a U.S. federal agency. To comply with FISMA, organizations must follow FIPS 199, FIPS 200, and the NIST 800 series guidelines. The top areas of focus that must be met are as follows: maintain an information system inventory; categorization of systems based on risk; develop and maintain a security plan; adhere to NIST SP 800-53 security controls; conduct risk assessments according to NIST SP 800-30; and have annual certification and accreditation of systems. Penalties for failing compliance can include censure by Congress, a reduction in federal funding, and reputational damage. If you work for the U.S. government or plan to do business with a U.S. government entity, you must follow FISMA compliance requirements.

  Note

  Learn more about FISMA at https://www.dhs.gov/cisa/federal-information-security-modernization-act.

• FedRAMP: The Federal Risk and Authorization Management Program is another U.S. government-wide program and compliance with it is required for any government agency leveraging cloud technology. FedRAMP provides steps for performing security assessments, authorization, and continuous monitoring of cloud products and services. FedRAMP, like FISMA, uses the NIST SP 800-53 security controls for its blueprint. Cloud services must have their security assessed and be granted an Agency Authority to Operate (ATO) or Provisional Authority to Operate (P-ATO) in order to be accepted by a government agency, unless a special exception is granted. If you work for a U.S. government agency or plan to do business with a government agency using cloud-based technology, you need to follow FedRAMP requirements.

  Note

  You can learn more about FedRAMP at https://www.fedramp.gov/faqs/.

• Data sovereignty laws: Data sovereignty is a country-specific requirement mandating that data is subject to the laws of the country in which it is collected or processed as well as must remain within its borders. Many countries have had data sovereignty laws for decades; however, new privacy laws are making data sovereignty requirements more public. Countries such as Russia, China, Germany, France, Indonesia, and Vietnam require that their citizens’ data must be stored on physical services within the country’s borders, meaning data can’t exist in a cloud service outside the physical country. The reason for these laws is that countries are concerned about data being misused when it leaves their borders because, technically, they are no longer legally able to protect such data. An example where data sovereignty will come into play is cloud services that have data warehouses located around the world. Organizations that must meet their government’s data sovereignty requirements will need evidence that their data will be stored only within data warehouses residing within their country or they will not be permitted to use the cloud service. It is up to the organization to identify and adhere to any data sovereignty requirements, which will vary from country to country.

• Industry-specific compliance requirements: Your organization might be required to comply with one or more requirements specific to its industry. As an example of a compliance requirement specific to the energy industry, I’ll briefly mention NERC CIP. The North American Electric Reliability Corporation (NERC) has been in charge of maintaining the operations and functions of bulk power systems, more commonly called the electric grid, since the early 1960s. In 2008, NERC developed the Critical Infrastructure Protection (CIP) compliance framework, made up of 11 control families, to mitigate cybersecurity attacks on the electric grid. There are useful general recommendations as well as those that are very specific to the security of bulk power systems. The framework can be found at https://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx.

  Note

  I included NERC CIP as an example of a very specific industry compliance requirement. Industries such as manufacturing, education, and government also have industry-specific certifications. PCI DSS is a specific service requirement, meaning you only need to follow PCI DSS if you are involved with credit card services. I recommend consulting with a compliance specialist if you are unaware of all compliance requirements your organization is obligated to follow.