CompTIA CASP+ CAS-004 – Chapter 01 – Understanding Risk Management Part 6
- Vulnerabilities and Threat Identification
When we’re determining vulnerabilities and threats to an asset, considering the threat agent first is often the easiest. There are essentially six categories of threat agents. So we have human, which can be both malicious and no malicious internal and external threats natural threat agents, of course floods, fires, hurricanes, et cetera. Technical, which is going to include hardware and software failure malicious code as well as new technologies.
Then you have physical, which includes perimeter measures that are failed biometric failures, et cetera. Environmental, which is power and other utility failures like traffic issues even. And then finally operational, which is any process or procedure that can affect CIA. Now, these should be used along with or these categories I should say should be used along with threat actors that are identified or that we talked about earlier because they help an organization develop the most comprehensive list of threats that are possible.
- Additional Factors
There are a number of additional factors that we need to keep in mind. The first is exemption. While most organizations should complete a thorough risk analysis and take measures to protect against all risk, some organizations are going to have exemptions from certain type of risk, and that’s going to be based on the nature of the business and government standards. Deterrence is the use of the threat of punishment that can deter people from committing certain actions.
Of course, many government agencies would employ this risk management method because they’re going to post legal statements in which unauthorized users are threatened with fines or imprisonment if they gain access to the network or systems. Inherent risk is a risk that has no mitigation factors or treatments applied to it because it’s essentially impossible to avoid. All right, so like, for instance, an attacker who’s determined and has the skills to physically access an organization’s facility.
You might have controls, guards, fencing, locks, et cetera, but an organization can’t truly ensure that this risk will never occur if the attacker has the level of skill that is necessary. In this case, it’s extremely important to properly identify these types of inherent risk. Then we have residual the level of risk that remains after the safeguard has been put in place. Because really, no matter how careful you are, it’s impossible to totally eliminate risk. And so what you’re left with is that residual risk.
- Topic D: Business Continuity Planning
In this topic, we’re going to look at business continuity planning, which deals with identifying the impact of any disaster and ensuring that we have a viable recovery plan for every function and that we’ve actually implemented this system. The primary focus is going to be to carry out organizational functions when a disruption occurs.
- Continuity Planning
So a business continuity plan is going to consider all aspects that are affected by a disaster. This includes functions, systems, personnel, facilities. We’re going to list out and prioritize the services that we need, particularly the telecommunications and It functions.
- BCP Components
So BCP is really vital to ensuring that an organization can recover from a disaster or a disruptive event. There are a number of different groups that have established standards and best practices for business continuity. These include a lot of different components that are common to one another as well as steps. So let’s talk first about personnel components.
Senior Management are the most important personnel in the development of the continuity plan because they support business continuity and disaster recovery, and that drives the overall organizational view of the process. If we don’t have Senior Management support, as we’ve mentioned before, the process will fail. They set the overall goals of business Continuity and Disaster Recovery. Then you have the Business Continuity Coordinator, and that individual is one that is named by Senior Management and should lead the BCP committee.
The committee then develops and implements and tests the BCP as well as the DRP or Disaster Recovery Plan. That committee really should include at least one representative from each business unit. At least one member of Senior Management should be part of that committee as well. And then in addition to that, the organization really should ensure that the It Department, legal Department, Security Department, they’re all represented because they all have vital roles to play during and after a disaster.
Then, in order to ensure the development of the BCP and that it’s successful, you need to define a scope. Or rather, Senior Management would define that scope. Because if you have a BCP that has unlimited scope, it can often become way too large for the committee to handle correctly. In those cases, it might be necessary to split the project into smaller, more manageable pieces.
- BCP Steps
A lot of organizations have developed standards and guidelines for doing business continuity and disaster recovery planning. One of the most popular is NIST 834 revision one. It’s summarized in these steps developing a Contingency Planning policy, conducting business Impact analysis, identifying preventative controls, creating contingency strategies, then developing an information system, contingency plan, testing and training, and maintaining the plan.
Of course, you can go get more detailed information on each of those, but that’s essentially the gist. Let’s talk briefly about them. The Contingency Planning Policy Statement defines the overall contingency objectives of the organization, and it establishes the framework and the responsibilities that are going to be used for this type of planning. Most likely, the CIO is the senior management that is involved in this and supports it. The policy is going to include roles and responsibilities, the scope as it applies to different platform types and organization functions, resource requirements, training requirements, schedules, and the like.
The purpose of the Business Impact Analysis is to correlate the system with critical mission and business processes as well as the services that are provided by them. The development of the BCP depends most on the development of a Business Impact Analysis, and that includes four main steps of identifying critical processes and resources, identifying outage impacts and estimate downtime resource requirements, and then finally, recovery priorities. So this is going to be very important and it relies heavily on any vulnerability assessment and risk assessment that has been completed. And then when we identify the preventative controls that we’re going to use, that’s going to be based on that impact analysis as well. When we talk about creating contingency strategies, we’re going to be looking at adequately mitigating the risk arising from the use of information and the use of information systems. Planning, testing, training, and maintaining some of those go, probably without any further explanation. But these are all extremely important parts of the BCP process.
- Additional Plans
In addition to the plans that we’ve talked about, there are a number of other types of plans that, according to NIST 834 release, one really should be included as a part of the Contingency Planning. The first is the Continuity of Operations plan. This focuses on restoring anything that’s missing, called mission essential functions, and doing so at an alternate site and with Continuity of Operations.
It’s expected that you can operate in that alternate site for up to 30 days before returning to normal operations. At least that’s the norm. Crisis Communication Plan is a document that has standard procedures for internal and external communications in the event of a disruption using the steps in this plan. There are also various formats for communications that are appropriate to each individual incident.
Then you have the Critical Infrastructure Plan or CIP Plan. There should be a set of policies and procedures that serves to protect and recover different assets, mitigate risk vulnerabilities. Of course, DRP is just designed to restore the operability of the target system, the application, the computer facility infrastructure, and to do so at an alternate site in the case of emergency. If necessary.
We have the Information System Contingency Plan, which provides established procedures for the assessment and recovery of the system following disruption, and then the Occupant Emergency Exam, which is first response procedures for the occupants of a facility in the event of a threat or incident. That where their health or safety of these individuals is potentially compromised.
- Conducting Business Impact Analysis
Business impact analysis is also something that’s going to be very important. The purpose of Bia is just to correlate the system with the critical mission and business processes and the service provided, and based on that information, then to characterize the actual consequences of a disruption. The development of the Business Continuity Plan really depends most on business impact analysis because it helps me understand what impact a disruptive event is going to have on the organization and it helps me to understand the priority of particular assets. It’s a management level analysis that identifies the impact of losing particular resources.
Now, the four main steps for the Bia are to identify critical processes and resources, identify outage impacts, and estimate the amount of downtime, identify resource requirements, and identify recovery priorities. Bia also relies very heavily on vulnerability analysis and risk assessment that’s already been completed that may have been performed by the Continuity Planning Committee. It could be performed by a separate risk assessment team as well. So it’s kind of dig into these different steps for Bia analysis, starting with identifying critical processes and resources.
Now, it’s probably fairly self explanatory, but the first step is that we need to identify all the business units or functional areas within the organization. After those have been identified, then we have to identify individuals who will be responsible for gathering all the necessary data as well as figuring out how to obtain that data. Those individuals will go gather the data. They can use a variety of techniques like questionnaires, interviews, surveys, et cetera.
They might also perform vulnerability analysis and risk assessment, or they might just use the results of these tests as input for the Bia, the next one would be identifying outage impacts and estimating downtime. After we’ve determined processes, functions, resources, et cetera, then we’re trying to get the critical nature of a particular asset. And in order to do that, we have to understand certain terms. The first is MTD or Maximum tolerable downtime, which is simply the maximum amount of time that we can tolerate a particular resource or function being down, it’s sometimes referred to as MT or maximum time of disruption.
Meantime, to repair MTTR, the average time to repair a particular resource or function when there’s a disaster. Meantime, between failures is the amount of time that a device should operate before a failure occurs. That’s typically something that is developed by the vendor RTO’s recovery time objective is the period of time in which we must restore a resource or function because if we don’t restore it within that period of time, then we can have some unacceptable consequences and the RPO is related to that. That’s the point in time to which we have to restore this resource or function.
Work recovery time is the difference between the RTO and the MTD, the remaining time that’s left over after the RTO, but before reaching that maximum tolerable now every organization is going to have their own documented critical levels. Many of them will include critical, urgent, important, normal, nonessential, et cetera. Obviously, critical resources are resources that are the most vital to an organization’s operation. They need to be restored very quickly. Minutes, hours of the disaster, typically urgent, it’s up to 24 hours. Important, maybe up to, you know, 72 hours, nonessential, 30 days. So, I mean, you’re, you’re developing those lengths of time within the organization. After you’ve identified outage impacts and estimate downtime, then we want to look at resource requirements.
You need to determine what’s required for each function or resource. And the reason that we must document this is because if these items, these elements need to be restored when a disruptive event occurs, then we’ve got to know how to do it and we’ve got to know the particular performance requirements of that resource. And then finally identifying recovery priorities. We need to take into consideration critical processes, outage impacts tolerable downtime system resources. After all that’s put together, the result that comes out of that is a priority hierarchy, a priority for recovery. And typically there will have priorities of high, medium, low. And then we will determine exactly how we are going to treat those various priorities. So this is a very, very critical step to the overall business continuity plan.
- Chapter 01 Review
In this chapter we looked at understanding risk management. We started by talking about business and industry influences, things like new technologies that affect security planning, acquisitions and mergers, demergers and divestitures, and some of the considerations that went along with that. We discussed policies and procedures and how they’re an integral part to planning security for your organization. The policies is define overall goals and the organization’s posture towards security, whereas the procedures outline the individual steps that will be taken in order to meet those policy goals. Then we looked at risk mitigation and control, how to identify vulnerabilities and threats, to utilize that information to calculate risk, and then to determine if we are going to mitigate the risk, control the risk, avoid it, transfer it, various options there and then finally business Continuity planning. We need these systems to be available and so we discuss the various components that make up the BCP.