Chapter 13: Applying Appropriate Risk Strategies

Enterprise risk is a major consideration for organizations and can have a significant impact on them. Risks must be understood at a strategic level to ensure long-term goals are achieved and must also be addressed for more short-term or tactical business goals. An enterprise should employ security professionals who have expertise in conducting appropriate risk assessments or engage qualified assessors to assist the enterprise. Once risks are identified, the business must have a strategy for responding to risks; these responses may be dictated by regulatory compliance or business drivers. Risk is a constant threat to a business and must be managed on a continuous cycle. In order to understand if we have deployed effective controls, we need to have monitoring and reporting in place to ensure we are operating within the enterprise's targets, for risk tolerance.

A strong security posture will provide a strong foundation for managing risk within the enterprise. This can be achieved with cybersecurity policies and practices, in order to ensure day-to-day operations are handled securely.

Supply chains add additional complexity to an enterprise's overall security footprint; lack of visibility of who is handling enterprise data or processing enterprise data can add to risk. Vendor management and assessments must be addressed by risk management teams. In this chapter, we will learn about the following topics:

• Understanding risk assessments
• Implementing risk-handling techniques
• Understanding the risk management life cycle
• Understanding risk tracking
• Managing risk with policies and security practices
• Explaining the importance of managing and mitigating vendor risk

Understanding risk assessments

When assessing risk, there are typically two approaches; one approach involves qualitative techniques. The metrics used within this approach will include likelihood and impact and may include other metrics such as speed of onset. This is considered a basic form of risk assessment and will include background knowledge from the assessor. It is often considered a subjective method, meaning two different risk assessors may not agree exactly when delivering a qualitative risk assessment. A common approach to risk management is to break the process down into steps or phases. Figure 13.1 shows a five-step approach:

Figure 13.1 – Risk management steps

To understand risk, we must be able to quantify a level of risk as a measurement. In all cases, we will have assets that must be protected, so we then need to calculate the level of risk using likelihood and impact.

One of the accepted approaches to risk assessments is to use a qualitative method. We will now take a look at this type of assessment.

Qualitative risk assessments

In order to perform a qualitative assessment, we must adopt a step-by-step approach using likelihood versus impact. This can be a fairly simple risk matrix, as illustrated here:

Figure 13.2 – Qualitative risk assessment matrix

It is important to highlight the greatest risks in order to prioritize risk responses.

There are more specific qualitative risk assessments when we are assessing risks against particular assets. When there is a requirement to host different data types on a shared information system, (often requiring different classification labels), then we can use the Canadian Institute of Actuaries (CIA) aggregate matrix. Figure 13.3 shows an example of the CIA aggregate method of risk assessment:

Figure 13.3 – CIA aggregate scoring

This approach is used to ensure we identify the greatest risks for the overall system and use this as a baseline to apply the controls. When calculating the aggregate values, we track the high-water mark in each column (this is a simplistic description where we look for the highest single value in each column). In the preceding screenshot, the impact value for admin information is LOW. We must, however, ensure that the potential impact for supervisory control and data acquisition (SCADA) alert data is mitigated with the appropriate control. As this is a shared information system, we may choose to implement a high availability (HA) failover solution.

One of the benefits of using a qualitative method is the fact that it can be easier to perform. However, it does not produce outputs that convey the level of risk from a financial perspective. To present risks to decision-makers, it may be necessary to use a quantitative approach in order to present monetary values. We will now take a look at this type of assessment.

Quantitative risk assessments

When risks must be conveyed to company leadership, it is important that risks are presented in a way that is easy to understand. To present risks to decision-makers, it is useful to illustrate the monetary impacts of risks. This can be achieved by using quantitative risk assessments.

Asset value (AV)

When using a quantitative approach, it is important to understand the value of an asset. This could be the purchase price of a commodity or, perhaps, the invested costs associated with creating a customer marketing database.

Exposure factor (EF)

When assessing risks, it is uncommon when an event occurs that there will be a total 100% loss in monetary terms. If my building is flooded, then it is likely the costs to repair the damage will not be equal to the total original cost of the building. This value is normally presented as a percentage figure.

Single-loss expectancy (SLE)

The amount of loss during a single event is calculated using the Asset Value (AV) x Exposure Factor (EF).

Annualized loss expectancy (ALE)

If there are multiple incidents, then we need to understand how many events will occur in a single year.

Annualized rate of occurrence (ARO)

The total loss during the year is calculated using SLE x ARO.

We will take a look at a simplistic example of quantitative risk.

The enterprise has a production facility, and the risk management team must assess all risks that could cause a loss to the business. The plant has a nominal value of United States dollars (USD) $10,000,000, and historical data—as well as studies in climate change (projected into the future)— is used to give a realistic likelihood value. The data calculates those floods will occur twice in 100 years, so, the ARO=.02 or 2%. It is expected that damage will result in a cost of $2,000,000 or 20% of the total value. The calculation of SLE x ARO (2,000,000 x .02) will result in a loss of $40,000, which is the ALE. Figure 13.4 illustrates the process to determine the ALE:

Figure 13.4 – Quantitative risk assessment

As this is a low likelihood, the enterprise may choose to accept the risk. Alternatively, they may consider flood insurance if the annual cost is no greater than $40,000.

Gap analysis

A gap analysis is undertaken in order to understand where there may be missing controls. In order to perform this analysis, we must be able to assess the current state of controls and compare this to where we want the organization to be (the desired state). Figure 13.5 shows the steps required to perform a gap analysis:

Figure 13.5 – Gap analysis

The results can be shared with senior management in order to facilitate a response.

Total cost of ownership (TCO)

When assessing solutions to control or mitigate risks, it is important to factor in all costs, not just the initial purchase price. Many solutions may require maintenance, software licensing, additional staff, or other costs that will need to be calculated over the lifetime of the solution.

Return on investment (ROI)

An ROI is an important metric as it can be used to highlight the benefits of a proposed control in monetary terms. When presenting recommendations to senior management, a positive ROI for a proposed risk mitigation solution is an effective way to get your point across.

It is normal to present an ROI as a purely monetary value, although it can also be presented as a percentage figure.

An example would be ALE based upon ransomware attacks of $100,000. So, we purchase endpoint detection and response (EDR) solution and network-attached storage (NAS) for backing up important data. The cost is $10,000 and will save the company $100,000, so the ROI is $90,000. Figure 13.6 shows this formula used to calculate ROI:

Figure 13.6 – ROI calculation

We could use another example of phishing attacks, costing the company $100,000 annually. In this case, we invest $10,000 in EDR and security awareness training. We expect this control to be 90% effective in preventing this type of attack. So, the reduction in risk will be $90,000 - $10,000 (cost of control) = $80,000 ROI. If we wanted to present the benefits as a percentage figure, we would use the following calculation:

Figure 13.7 – ROI calculation displays a percentage value

In the example using the phishing attack, the ROI would be $80,000/$10,000 = 800%.

Mean time to recovery (MTTR)

When security professionals are assessing more than one proposed solution, it is important to research the performance of the proposed solutions. MTTR could be an important metric when choosing a mitigation solution. We could use the example of the NAS to protect our data from ransomware attacks. To restore backed-up data from the NAS to a server may take 2 hours, whereas a restore from tape-based media could take 4 hours. A lower value is the desired outcome with this metric.

For systems that cannot be recovered, we would use the mean time to fail (MTTF) metric.

Mean time between failure (MTBF)

The reliability of a system can be calculated by using the MTBF metric; this is the average amount of time between each event. A higher value is desired. So, if my server is hit by crypto-malware (ransomware) on two occasions during a 24-hour period requiring data restoration from the NAS, the server will have 4 hours of downtime—20 hours' worth of uptime divided by 2 = 10 hours. So, the MTBF would be 10 hours.

Once we have identified suitable metrics to assess the risks, we can take a look at approaches to control these risks.

Implementing risk-handling techniques

Once we have identified risks, it is important to formulate a response. Approaches will differ, depending on a number of factors, including the organization's risk appetite and regulatory requirements. There are four main types of risk response, as shown in Figure 13.8:

Figure 13.8 – Risk response types

An enterprise should consider the following risk response approaches.

Transfer

When an organization wants to control or mitigate risk but does not have the resources (personnel or finances) to implement a response, then transference may be an appropriate strategy. If the organization cannot afford to rebuild the warehouse in case of fire, then they should consider fire insurance. If the organization does not have the personnel or infrastructure to support secure card payments, they may consider engaging a third party to process these payments.

Accept

When a risk is accepted, it is normally because the risk is considered to be acceptable to the organization based upon the risk tolerance/appetite. An example of risk acceptance would be a low likelihood event, such as earthquakes or floods in an arid location with no prior history of earthquakes or floods.

Avoid

To avoid an identified risk, the organization should cease the activity that is identified to be outside of the acceptable risk tolerance. If the risk is deemed to be extreme, such as loss of life, then the risk avoidance will be justified.

Mitigate

In many cases, the response to risk will be to mitigate risks with controls. These controls may be managerial, technical, or physical. Mitigation will not avoid risks completely but should bring the risks down to an acceptable level. Mitigation could involve an acceptable use policy (AUP) for use of mobile equipment; in addition, mobile device management (MDM) would allow the organization to encrypt company data.

As well as formulating effective risk responses, it is important to recognize risks that will have to be absorbed in some way.

Risk types

When performing risk assessments, it is important to understand that risk cannot be completely eliminated, unless we choose risk avoidance. Certain risk types will always be present.

Inherent risk

This is the risk that exists prior to any controls being applied. An example could be a financial institution that employs staff with no background checks or formal interviews. At the same time, there are no locks or barriers safeguarding the bank vault. Some organizations will have to accept a much higher level of inherent risk when choosing a particular area of operation or business sector. There is an inherent risk when considering operating in a hostile geographic region, both from an environmental and political nature.

Residual risk

This is the risk that remains after controls have been applied. There will always be some remaining risk, but it will be reduced to a level that falls within the corporation's risk tolerance. For banks, a solution might be background checks for employees, biometric locks, and closed-circuit television (CCTV) for the vault.

Risk exceptions

An exception is where a corporation cannot comply with regulatory requirements of corporate policy. There may be circumstances beyond the control of the organization, or perhaps a technical constraint that requires a risk exemption. A common requirement for a risk exemption may be legacy equipment or applications. Exemptions should be formally documented and signed off by the appropriate business owners or stakeholders.

Managing risk is a continuous process, so frameworks, controls, and effective management are important for an enterprise.

Understanding the risk management life cycle

The risk management process is cyclical, and risks need to be identified on an ongoing/constant basis. Business practices may change and regulatory compliance may place fresh demands on security professionals. These changing practices will mean the organization must constantly assess the security posture to ensure controls and best practices are put into place. Figure 13.9 shows the stages of the risk management life cycle:

Figure 13.9 – Risk management life cycle

Within the risk management life cycle, an enterprise will perform the following activities:

• Identify—The business process, people, technology, and intellectual property (IP) are just some items that may constitute enterprise risk.
• Assess—In this phase, we must identify potential threats, vulnerabilities, and the level of risk that they pose to the enterprise.
• Control—During this phase, we identify controls that will meet the enterprise requirements, as far as the levels that they are willing to accept.
• Review—In this phase, we must understand that there will be changes within the industry, regulatory changes, and changes to the threat landscape. When there are changes, then the enterprise must assess these new risks. Are the controls still adequate within this changing threat landscape?

There are many frameworks adopted by organizations, and depending on the business sector or operational requirements, a particular model usually gains widespread acceptance. We'll now take a look at some risk management frameworks.

Department of Defense Risk Management Framework

The US Department of Defense (DoD) has adopted the DoD Risk Management Framework (RMF). This is based upon a six-stage model. Each stage can be accomplished using guidance and documentation published by the National Institute of Science and Technology (NIST). The exact details for this framework can be seen in DoDI 8510.01, available at the following link: https://tinyurl.com/DoDRMF.

See Figure 13.10 for steps in the DoD RMF model:

Figure 13.10 – DoD RMF

In the preceding example, we have linked each step to corresponding NIST guidance that can be used as a reference for each step.

NIST Cybersecurity Framework (CSF)

This was created in order to provide organizations with guidance on how to prevent, detect, and respond to cyberattacks. It is intended as general cybersecurity guidance for various business sectors. Figure 13.11 shows a typical five-stage life cycle:

Figure 13.11 – Risk management life cycle

To understand in more detail how an enterprise can implement this framework, see the downloadable document at https://tinyurl.com/NISTCyberSecFramework. The stages are documented next.

Identify

In this stage, the organization must identify all assets that may be subject to cybersecurity risk. Assets may well include people, systems, data, and business operational capabilities—in other words, any element of risk. Without this identification stage, we cannot effectively focus efforts on the critical parts of the business.

Protect

Once we have identified all critical assets, we can move on to the next stage, which is to protect. We will mitigate and minimize the potential for damage arising from a cybersecurity incident.

Detect

It is important that the organization is able to detect when a cybersecurity incident is taking place. To be successful within this phase, we will need a combination of security professionals, well-trained personnel, and automated detection.

Respond

It is important to have appropriate plans in place to respond to cybersecurity incidents. We must be able to contain cybersecurity incidents while maintaining business operations. It is important to focus on response planning, communication, and tools and techniques to perform analysis, mitigation, and continuous improvements.

Recover

In the recovery phase, an enterprise should maintain plans that enable the organization to recover from significant events (business continuity (BC); incident response plans). It is important to focus on resiliency at this stage.

Understanding risk controls

There are many challenges when we consider all the potential risks that need to be managed by an enterprise. It is a fine balancing act, where we have employees, business processes, and technology that are all interwoven. Figure 13.12 shows the relationship between people, processes, and technology:

Figure 13.12 – Risk control relationship

It is important for all these elements to be considered to ensure they will work well together.

People

The controls that we choose must be effective and accepted by our staff. If they are overly complex or poorly implemented, then they may try to work around the obstruction. Imposing strict password policies on users may result in workarounds such as password reuse or writing complex passwords down.

Processes

It is important to formalize processes that will be used within the enterprise. A business process should ensure that goals are achieved in a safe and secure way. The standards and policies that the organization adopts will help to ensure that processes are performed in an efficient but secure manner. Single points of failure (SPOFs) should be identified and eliminated, and processes that have the potential for fraudulent activities should also be changed.

Technology

Technology can be useful when considering risk controls. Innovation can be an important business driver in many ways. Automation can help solve or speed up complex processing problems. Artificial intelligence (AI) and machine learning (ML) are helping to protect our information systems from ever-increasing sophisticated threats. We must, however, harness this technology to ensure it makes the right decisions; many systems still require humans in the loop.

In order to understand if the controls are effective, we must monitor risk activities. We will now look at techniques used to track risks.

Understanding risk tracking

It is important for enterprise risk to be understood and managed by the appropriate stakeholders within the organization. All risks should be documented, along with actions taken and the business owner impacted by the risk. This should be documented in a risk register. Figure 13.13 shows a typical risk register:

Figure 13.13 – Sample risk register

To ensure the organization is able to comply with regulatory requirements, we must have an effective method to monitor risk. By monitoring risk, we can see reports on potential risks and understand where the business may be unduly exposed.

In order to monitor and respond to risks, we must have effective metrics that allow an enterprise to track performance regarding risk.

Key performance indicators

A key performance indicator (KPI) is a measurable value, allowing the business to identify important activities in the company that contribute to a positive security posture. KPIs can be used to log the performance of activities, such as the percentage of endpoints patched to date, the number of unresolved security incidents, MTTR from a security event, or the percentage of staff having completed security awareness training.

Key risk indicators

Key risk indicators (KRIs) are directly related to KPIs. They are developed together in order to identify the processes that contribute to strategic objectives. If we can identify key business processes that can contribute to risk, we need a way to measure the performance, and then we can set thresholds that indicate the activity is now creating a risk to the enterprise. With proper reporting, KRIs should give early warnings to ensure the risk does not get out of hand and exceed our risk tolerance. If the business has identified a KPI, then there needs to be agreement about when this measurement quantifies a risk to the business. If we consider patching of workstations to be important, then a KPI reporting the number currently patched to be less than 90% could indicate a significant risk to the business. Ransomware is one of the biggest cybersecurity risks, targeting vulnerable unpatched systems.

Risk appetite

Risk appetite defines the amount of risk that an organization is prepared to accept when pursuing business objectives. This will differ between different business sectors and industries and will also be very dependent on company culture, competitors, objectives, and the financial wellbeing of the company. It is difficult to define an exact value when describing risk appetite. Risk appetite is usually expressed as low, medium, or high. There is usually a sweet spot that is acceptable in many industries. An energy provider with a large customer base may be content to operate gas-fired power stations. It is a well-proven technology, and if the technology is mature and relatively safe, they do not want to change the model or target new customers. Their appetite for risk is low.

Risk tolerance

This is the deviation that the enterprise will accept in relation to the risk appetite. This metric can be expressed as a number or percentage value. The energy supplier negotiates for future deliveries of gas from global suppliers. If reserves of gas, for unexpected cold weather, drop to less than 5% then we must act, as the company has set this as its risk tolerance.

Trade-off analysis

When considering enterprise risk for a large organization, there may be many risks and response strategies that should be evaluated. There may be differing views based on stakeholder priorities, and the strategic goals of the enterprise may need to be considered. If an organization decides that customer satisfaction is the main priority, they may decide to commit more resources into customer-facing support teams, taking personnel away from the sales team. This may mean fewer sales in the short term, but the long-term strategy may mean more customers.

Managing risk with policies and security practices

In order to mitigate risk, there are many approaches. Policies are one effective way to meet corporate goals. While they do not guarantee all security goals are met, they are an important layer when we implement defense in depth (DiD). Implementing more layers of security means that if one control fails, we have compensating controls.

Separation of duties (SoD)

When an employee has privileges that enable them to make high-level decisions without needing the consent of another employee, then we are missing essential checks and balances. Consider a chief financial officer (CFO) who approves new suppliers, approves supplier invoices for services, and signs paychecks. This example would allow for fraudulent activities and would be mitigated by establishing accounts receivable and accounts payable business functions.

Job rotation

When employees are in the same job role for a significant amount of time, there is the likelihood that they become complacent and burnt out. A change in job role means the enterprise has redundancy in skill sets and motivated employees. Another benefit is the fact that fraudulent activity will be less likely, as employees do not have the option to establish long-term hidden practices, and the new job holder may uncover fraudulent activities.

Mandatory vacation

In certain industries, it is common practice for the staff to be away from their job for a period of time on an annual basis. The duration may vary; in finance, the recommended mandatory vacation is 2 weeks. This period of vacation ensures that their position can be audited while they are on vacation. Another benefit is that mandatory vacation serves as a deterrent. An unauthorized activity may be difficult to hide from the company if the employee is not around to fix potential problems.

Least privilege

This is a good practice that involves identifying business functions and having robust account management policies to ensure the user has the privileges they need for their job. It may seem obvious, but it can be easy to overlook this basic control. It is common practice to add an employee to a role group that has privileges far in excess of the actual privileges they need. Take the example of the administrator group on a Windows server; this role allows the user to perform any administrative function on the server. A technician may need certain privileges to install software and hardware drivers; if they are added to the administrator group, they would gain privileges beyond their requirements.

Employment and termination procedures

Many risks may be overlooked without the adoption of policies for new employees and employees who leave the organization. New employees should be vetted and background checks should be performed. New employees should be onboarded, which involves mandatory security training, assignment of credentials and equipment (including sign-off), signing of an AUP, and, where applicable, non-disclosure agreements (NDAs).

When the employee leaves the company, they should be offboarded. Offboarding involves exit interviews, which will allow the organization to understand why an employee may be leaving and help with future employee retention. Exit interviews may encourage whistleblowers; the employee may be leaving because of poor attitudes and practices of their work colleagues. During offboarding, it is important to recover all company assets and disable user account credentials.

Training and awareness for users

Security awareness training is an important process, as the users are the most important asset within an organization. Users can also be considered the weakest link; over 50% of data breaches are caused by insider threats. Poorly trained users can be one of the biggest factors to consider when dealing with data breaches. Baseline security training should be implemented for all staff, with more specialized training for job roles.

Auditing requirements and frequency

It is important for the enterprise to perform regular audits to ensure the enterprise meets regulatory requirements and mitigates risks of fraudulent or malicious actions. The Federal Information Security Management Act (FISMA) requires government agencies and suppliers to be audited on an annual basis. To be FISMA-compliant, the following steps need to be taken:

• Maintain an information system inventory
• Categorize information systems (Federal Information Processing Standard Publication (FIPS) 199)
• Maintain a system security plan
• Utilize security controls (NIST SP800-53)
• Conduct risk assessments (NIST SP800-30)
• Certification and accreditation (NIST SP800-37)
• Continuous monitoring

Once all the controls are in place, it is important that compliance is constantly monitored. There are vendors offering solutions to monitor, report, and alert when systems deviate from the baseline.

As an enterprise will rely on third-party vendors to perform essential business functions on its behalf, it is important that there are controls in place to assess and mitigate risks. We will now explain these techniques.

Explaining the importance of managing and mitigating vendor risk

An enterprise will need to assess risk whenever significant business changes are undertaken. There are many activities that will require an enterprise risk to be evaluated. A large enterprise may be engaged in outsourcing services to third-party vendors, often cloud-based. Maybe the enterprise will consider a merger or acquisition with a company operating within a different regulated industry.

There are many examples of attacks that have been launched, exploiting supply chains, often relying on a lack of visibility on the part of the enterprise. It is important to assess all risks that may be present when we work with third parties. When performing vendor assessments, we need to ensure they meet the expected levels of compliance required by the enterprise. To ensure a vendor meets the expectations of the business, we may audit the vendor or use third-party assessments. The following topics should be considered during an assessment.

Vendor lock-in

It is important to assess all available options when bringing in external providers or technology solutions. Cloud service providers (CSPs) would be a good example of potential lock-in, where the provider can impose strict financial penalties if the customer decides to switch CSP before the end of a specific contracted period. If the service is not adequate and cannot be improved due to a lack of defined service-level agreements (SLAs), then the customer may have to accept an inferior service. Technology may also be a contributor to lock-in, when bleeding-edge technology may be adopted. Later, the customer realizes the solution locks them into an incompatible database format. This could result in a solution that would be very difficult to migrate to another platform. Vendor lock-out could also be considered; this is when the vendor makes it difficult to work with third parties as their service may be incompatible.

Vendor viability

It is important to choose SPs that have a provable track record in delivering services that the enterprise would like to adopt. A sound financial analysis should also be conducted, as a major provider of services would present a large risk to BC if they went out of business.

Merger or acquisition risk

When an enterprise is considering a merger or acquisition, it is important to consider all risks that may transpire. Merging with a company in another geographical region may introduce practical problems such as language barriers, cultural differences, and different working practices. When considering mergers, it is important to assess the risks of co-joining networks, as there may be different regulatory requirements. When moving into a new industry or business sector, regulatory compliance or legal requirements should be considered. Data may need to be segmented and classified to ensure correct data handling is observed. When considering demergers, it is also imperative to plan for correct handling and access of business data.

Meeting client requirements

The enterprise may have very strict requirements when engaging with third-party vendors. The enterprise may have strict legal requirements that must be addressed. Major changes that may impact the customer should be agreed upon in advance using an effective change management process. If there are any significant changes in staffing levels that may impact the business, then there should be a clear communication channel for this event. When the vendor supplies staff directly to the business, then it is important that any staff changes are communicated to the business. Staff changes will require an onboarding and offboarding process. The client may also have very strict requirements concerning technology and the security configuration of information systems.

Support availability

It is important to agree upon levels of service; these agreements must be realistic and will be negotiated between both parties. Clear reporting metrics and agreed response times must be set. There should be a legally binding document generated; this is known as an SLA.

Geographical considerations

Data sovereignty is an important consideration for many organizations, including government agencies, critical infrastructure, and regulated industries. There is a legal requirement in some areas of operations that may require strict adherence to the storage and transmission of certain data types. It is important that the vendor service is compatible with these requirements.

Supply chain visibility

When working with third-party vendors, it is important to identify all potential risks that may be within the supply chain. Regulatory authorities have strict rules concerning data processors (General Data Protection Regulation (GDPR) is a good example). A data processor is any entity that would handle customer records or other sensitive data on behalf of the data controller (the company that is responsible for the data). A data processor can expose an enterprise to additional risks. This is often referred to as downstream liability.

Incident reporting requirements

If the vendor suffers an incident such as a data breach, then we must be informed in a timely manner. As the business will be the data controller, then the business is liable for subsequent actions. A large company such as a bank, may work with a vendor to offer additional services to its customers (maybe insurance). If the vendor processes the customer records/data then any breach, whilst they process the data will impact the bank.

Source code escrows

When external development teams are engaged to write applications for the business, it is important to address risks associated with the potential failure of that external supplier. If time and money are invested in the development of tools and systems, it is imperative that the source code can be retrieved by the customer. In normal circumstances, source code would remain the property of the external developer; the customer may have paid for the development of functioning code only. Future bug fixes and security patches will be difficult without future-proofing the availability of the original uncompiled source code. A third party would hold a copy of the source code, only releasing it to the customer in the event of the developers going out of business.

Ongoing vendor assessment tools

When a third-party vendor is offering services to government agencies or commercial customers, then it is important that they meet the legal and regulatory requirements of their intended customer. Common examples of third-party assessments are discussed next.

US government FEDRAMP program

Cloud providers offering services to the US government must be accredited through the Federal Risk and Authorization Management (FedRAMP) program before they can be given the authority to operate (ATO). More information can be found at the following link: https://www.fedramp.gov/.

Cloud Security Alliance

To prove compliance to commercial customers, organizations can be audited to meet the CSA Cloud Controls Matrix (CCM). This is a cybersecurity control framework for cloud computing, covering 197 measured controls. Vendors who meet these standards can offer their services through the Cloud Security Alliance (CSA). More information can be found at the following links:

• https://tinyurl.com/cloudCSA
• https://tinyurl.com/cloudccmatrix

International Organization for Standardization

There are various security standards defined by International Organization for Standardization (ISO). Standards of most interest to vendors looking to assure clients of their adherence to security would include the ones detailed next.

ISO/IEC 27000:2018

This is a series of standards published by both ISO and the International Electrotechnical Commission (IEC). The standard is broad in scope, covering the main security controls for information management systems. It is a framework intended to secure IP, customer records, third-party information, employee details, and financial information.

ISO/IEC 27001:2013

This standard focuses on information security; it allows an organization to adopt a framework and prove to its customers that it has a strong security posture. Third-party assessments will ensure that an organization has adopted all the necessary controls. The standard focuses on the confidentiality, integrity, and availability of information systems. ISO/IEC 27001 is a certifiable standard, meaning the organization and staff can be certified.

ISO/IEC 27002:2013

This standard covers all the key controls that should be included to ensure secure operations when hosting information systems. This standard is for guidance only and does not allow an organization to be accredited or certified. It allows an organization to follow guidelines, leading to the adoption of 27001 compliance.

More information can be found at the following link: https://tinyurl.com/27000iso.

Technical testing

It is important that the vendor provides the necessary technology to fulfill the customers' requirements. The vendor may be a manufacturing subcontractor where quality assurance (QA) is of the utmost importance, requiring regular on-site inspections.

Network segmentation

It is a common requirement that networks be segregated in order for the business to be compliant with regulatory bodies. Therefore, the vendor should also follow these requirements. When considering operational technology (OT), industrial control systems (ICS), and SCADA, then these types of networks should not be connected to the same network as the business users. Segmentation for some sectors may require airgaps, while in other situations virtual local area networks (VLANs) should be adequate.

Transmission control

When data must be sent between the customer and the vendor, all efforts must be made to ensure confidentiality is maintained. Confidentiality is also important where the vendor will act on behalf of the customer and exchange data with outside entities. The vendor may be providing monitoring and support for the customer's SCADA network. In this case. they should use Internet Protocol security (IPsec) tunnels and consider the deployments of jump servers (for jump servers, see Chapter 1, Designing a Secure Network Architecture).

Shared credentials

The use of shared credentials should be avoided, as it is difficult to have an effective audit trail if we do not have individual accounts. Default credentials, such as the administrator account on Windows or the root account in Linux, allow a user to obtain all privileges for a system. It is standard practice to assign a user privilege by adding them to a role group; then, we can have a proper audit trail.

Summary

In this chapter, we have been able to understand that enterprise risk is a major consideration for an organization and will have a significant impact on the organization. We have gained an understanding that an enterprise should employ security professionals who have expertise in conducting appropriate risk assessments or engage qualified assessors to assist the enterprise. We have taken a look at strategies for responding to risks.

We were able to understand why we should deploy effective controls, and the need to have monitoring and reporting. We were able to understand why an enterprise must have targets, for risk tolerance.

Supply chains add additional complexity to an enterprise. We have addressed the need for visibility of who is handling enterprise data or processing enterprise data.

An understanding of vendor management and assessments is a key takeaway in this chapter, as well as the importance of risk management teams.

We have gained an understanding of appropriate risk assessment methods, and we have been able to implement risk-handling techniques.

We have gained an understanding of the risk management life cycle and now understand risk tracking.

During the chapter, we have gained knowledge of how to manage risk with policy and security practices and managing and mitigating vendor risk.

These skills will be useful in the next chapter, where we look at regulatory compliance and legal compliance for enterprise activities. We will also take a look at managing enterprise risks through BC planning.

Questions

Answer the following questions to test your knowledge of this chapter:

1. What type of risk assessment would use likelihood and impact to produce a numerical risk rating?
   1. Qualitative assessment
   2. Gap assessment
   3. Quantitative risk assessment
   4. Impact assessment
2. What type of risk assessment would use metrics including asset value, monetary loss during an event, and a value that could be expected to be lost during the course of a year?
   1. Qualitative assessment
   2. Gap assessment
   3. Quantitative risk assessment
   4. Impact assessment
3. What is the metric that is used to calculate the loss during a single event?
   1. Efficiency factor (EF)
   2. ALE
   3. SLE
   4. ARO
4. If my database is worth $100,000 and a competitor steals 10% of the records during a breach of the network and this happens twice in a year, what is the SLE?
   1. $100,000
   2. $1,000
   3. $20,000
   4. $10,000
5. If my database is worth $100,000 and a competitor steals 10% of the records during a breach of the network and this happens twice in a year, what is the ALE?
   1. $200,000
   2. $1,000
   3. $20,000
   4. $10,000
6. A company currently loses $20,000 each year due to IP breaches. A managed security service provider (MSSP) guarantees to provide 100% protection for the database over a 5-year contract at an annual cost of $15,000 per annum. What is the ROI in $?
   1. $75,000
   2. $25,000
   3. $125,000
   4. $2,500
7. If my risk management team need to understand where the business may be lacking security controls, what should they perform?
   1. Qualitative assessment
   2. Gap assessment
   3. Quantitative risk assessment
   4. Impact assessment
8. What type of risk response would purchasing cyber liability insurance be classed as?
   1. Transfer
   2. Accept
   3. Avoid
   4. Mitigate
9. What would be considered both a deterrent and useful security practice to ensure employees' job performance can be audited when they are not present?
   1. Job rotation
   2. Mandatory vacation
   3. Least privilege
   4. Auditing
10. What is the term for risk that is present within an industry, prior to any controls?
    1. Remaining
    2. Residual
    3. Inherent
    4. Acceptance
11. What is the term for risk that remains within an industry, after the deployment of security controls?
    1. Remaining
    2. Residual
    3. Inherent
    4. Acceptance
12. What is the metric that an organization can use to measure the amount of time that was taken to restore services?
    1. MTTR
    2. MTBF
    3. ALE
    4. ARO
13. What is the metric that an organization can use to measure the reliability of a service?
    1. MTTR
    2. MTBF
    3. ALE
    4. ARO
14. What type of risk response may be considered by a financial start-up company with a high-risk appetite if the potential rewards are significant and the risk is minimal?
    1. Transfer
    2. Accept
    3. Avoid
    4. Reject
15. What is a good practice when assigning users privileges to reduce the risk of overprivileged accounts?
    1. SoD
    2. Job rotation
    3. Mandatory vacation
    4. Least privilege
16. What is an organizational policy that would make it less likely that a user will insert a Universal Serial Bus (USB) storage device that they received at an exposition?
    1. Training and awareness
    2. Auditing
    3. DLP controls
    4. AUP
17. What will an enterprise use to track activities that may lead to enterprise risk?
    1. Key risk indicators
    2. Risk appetite
    3. Risk tolerance
    4. Trade-off analysis
18. What is the term that is used to describe the situation where a vendor has proprietary technology that makes it difficult for a customer to switch vendor?
    1. Vendor risk
    2. Vendor lock-in
    3. Third-party liability
    4. Vendor management plan
19. If a customer is concerned that a third-party development team may go bust during an engagement, what can they use to ensure they will have access to the source code?
    1. Change management
    2. Staff turnover
    3. Peer code review
    4. Source code escrow
20. What is the metric that an organization should use to calculate the total loss during a year?
    1. MTTR
    2. MTBF
    3. ALE
    4. ARO

Answers

1. A
2. C
3. C
4. D
5. C
6. B
7. B
8. A
9. B
10. C
11. B
12. A
13. B
14. B
15. D
16. A
17. A
18. B
19. D
20. D