So now that we've come up with the answers to those questions and we've rated things, decided on high, medium, low risk, high, medium and low impact, we have to come up with the overall strategy, the actual approach that we're going to take to mitigate a specific type of risk or threat. So let's begin with risk avoidance. 

Risk avoidance is a way of not taking on the characteristics that give rise to the risk in the first place. For example, if for example you run a business that produces very high precision instruments and your manufacturing process is in some way very delicate to produce these very high precision instruments, seismic activity of the area where you're considering building your plant might be a very important factor. On the other hand, you might be in a business where that doesn't matter at all. But there may be environmental conditions that may make one area of building more attractive than another. So by making a proper selection based on the right information, you avoid the risk of having seismic activity trouble your manufacturing process so you avoid the risk of one area and you take on the equivalent risk of a different kind in a different area that won't have the same very adverse, very damaging impact. Now risk avoidance also means that you don't employ certain other kinds of measures, systems, procedures and so forth that will give rise to risks that you then have to mitigate by some secondary means. 

We have our more common form of doing risk mitigation, actively opposing the risk in some way, changing the conditions, changing the asset, adding controls and so on. Risk mitigation is therefore a very common way of proceeding to try to manage the risk. We can do risk transfer. This of course involves getting an outsource who will assume responsibility performing conditions where they may be more adept at doing something and therefore they're taking on the particular task you want them to reduces the risk that the adverse events will occur. Now as a side note, a very important side note, the risk transfer to this other party does not transfer accountability. The risk is yours. You're transferring it on the basis usually in a contractual relationship, but the transferring of the risk does not transfer the accountability. That remains with you. Ultimately, after you have done everything that you cost effectively can do, comes the question of risk acceptance. Now the practice of accepting risk is based on the business decision where the cost to mitigate is more expensive than the cost to accept. But bear in mind that risk acceptance does not mean doing literally nothing. It is not doing nothing to put in place a form of continuous monitoring, because by having monitoring and setting triggers, you become aware of a situation that has changed, possibly giving rise to your ability to now actively mitigate or in some way deal with the risk. But doing nothing is, as you see here, by ignoring the risk or rejecting the risk this could be presumed to be a form of negligence. So we have to avoid choosing that except in cases where there is nothing effective that we can do. 

We have risk assignment. Now ultimately, risk assignment means that we're going to buy insurance and cybersecurity insurance, which is becoming a more commonly aware product that we can buy, is typically the way that we do this. We assign the risk, that becomes the basis for the underriding devaluation of a cybersecurity insurance policy and this becomes a way to complete the cycle of effectively doing all that we reasonably can to address the risks that we've identified. Senior management, however, may rely on a business unit or owners or custodians to assist in identification of risks so that they can effectively underwrite and thus buy a policy. It can be done through a purchased policy from a provider or it can be done by self insurance, so there are a number of ways that risk assignment can effectively be accomplished. Now the Enterprise Risk Management guidelines can come from a bunch of different sources. COSO is one source. The ISO 27000 series has the 27005 volume that talks about risk mitigation. We have an example from Australia and New Zealand called the 31000. The ISO Guide 73 from 2009. Our NIST Publications 800-37 and 39. And then the ISACA Risk IT Framework of 2009. And all of these provide guidance that if you were to read each one, would read in a somewhat similar manner, showing that the principles of risk management tend to be rather universal. 

So in moving to the question of countermeasure selection, we have to look at various attributes of the things that we select to ensure that we can establish these characteristics. We have accountability, that is someone is assigned responsibility for overseeing the control and ensuring that it's operated effectively and performs as desired. All controls must be auditable in some way. We have to develop proof that the controls do in fact do the job that we've selected them to do. We must determine that they come from a trusted source. We've already established that they must be cost-effective. The countermeasure itself must be secure. In other words, we need to do all that we reasonably can do to ensure that the countermeasure itself is not subject to compromise or if it is subject to compromise, that it's extremely difficult to do so. We have to be sure that it provides the proper protections for confidentiality, integrity and availability of the assets it's there to protect. We need to look at the countermeasures to ensure that they don't create additional issues during operation, and those would be things like administrative burdensomeness, additional risks, complications, technological fragility, and a host of other characteristics. And making sure that they do not leave any residual data from their function, that they in essence clean up after themselves. That is to say they leave no evidence of how they operate that itself might be exploited. Questions that need to be asked along these lines for security architects would include what frameworks would you use? A very important question, what business issues do you need to address in the course of doing this project? Because these are business issues and business assets and they must reflect the importance that they have to the business and that should be brought into the risk assessment process itself. We always need to know who our stakeholders are. That again reflects the importance the business places on this. One question that often arises is why am I addressing one thing and not another? The answer to this is simple, business places priorities on some things at a greater level than it places on others. You can't do two things at once truly and achieve optimal results in both. You typically have to make a decision about what you're going to emphasize first, and then second, and third. And as long as you're emphasizing the priorities that the business places, you're going to be close to right most of the time. A question that an architect must also answer on a more practical level is how you're going to integrate the new selections that you're making based on the analysis that we've talked about. 

How are you going to integrate those things into the existing system? You must be sure that you've assessed them for single points of failure, and have taken the precaution to ensure that, to the extent possible, you have eliminated these and that none exist or will exist in the final product. The security practitioner, the people who are more involved in day-to-day operations, have a similar set of questions that they need to answer. What tools will they need to use to properly operate these? Who are the end users going to be? In other words, who is the affected population and how will I interact with them? The question of why you're only being given x amount of time to get it done. You'll never have enough time, resources or personnel to get every job you need to get done, done perfectly. But this is a cycle where it's constantly ongoing, constantly changing. You have to achieve a point of operational effectiveness and you have a limited time to do that. This is something simply to accept and work within. Again, the question of integration. And then where will you manage this from? This could be a very critical question because the vast majority of these controls should not be managed remotely. They should be managed from in-house. So addressing that question and getting a proper answer will be a very important question. Now from the security professionals standpoint, we have to change our approach a little bit. The security professional, like CISSP, will have to address the question of what metrics do I need so that I will be able to manage this and ensure continued effectiveness? Who do you have to partner with to ensure successful operation of the system? How will you be able to communicate the appropriate level of information regarding the system to each of your user audiences? That goes to the question of who your stakeholders are and what message they each need to receive so that they know the program is achieving the desired results. Why are you not addressing this or that concern? Once again, this is a business problem that we're addressing. This being a business problem that we're addressing, they will determine what the priorities are because security does not exist in isolation from all this. 

Security must be an enabling activity to make sure that the business can do its business, just do it more securely. But the priority still must come from the business. And where will you find the time to be able to do this? This is the question that plagues us forever. We don't have enough time or resource or manpower to get everything we need to get done today. So we have to plan this out very carefully to emphasize the priorities and get everything accomplished as best we can. Now in looking at the security actors, what we want to do is do what we do so that others can do the job that they need to do, enable them, again, to do their jobs more securely than before. We have to be sure that the communication to each of these security actors is clear, that their responsibilities, duties, actions, responses are all made very clear and that the lines of communication are made equally clear. And we need to evaluate the actions that are going to be taken in anticipation of them so that we know that they actually do contribute positively to enablement and improvement of the security performance. Now the keys to successful implementation include documenting and effectively communicating all of the efforts being done by the platform. This is to make sure that the message is clear and that management is kept informed of things that are actually being done. This is making sure that they know that the program is effective by keeping them up-to-date and producing a real inventory. One of the common complaints has been that security tells a somewhat mythical story. The real inventory is things that we are actually accomplishing, having a material and positive impact on the security posture of the organization. Like all areas of the business, it needs to be shown clearly and in a justified, substantial way that it's making a positive contribution to the overall business performance. It adds credibility and it adds trust to the security effort to do so. 

Now looking at our controls, we're looking at the three or four primary categories from which our controls will come. We have the administrative or managerial. This is our governance documentation and there you see policies, procedures and so on that will capture the administrative or managerial controls in a documented way. We have our technical or logical. These are our methods, techniques and instrumentalities of the actual implementation, and this is your hardware, software, firmware, things that you do in the network and so on. Supporting this is the physical or operational. Locks, lighting, guards, other methods, business, building methods and so on that augment the effectiveness of these other things, or act in a way that the technical or the administrative cannot. And then we have the programmatic elements, which are management of documentation and management of the controls, reporting and so on, so that management always knows how things are going. And within those categories, we have actual control functions. We have the directive, which is our governance documentation. We have preventive, which as its name indicates, stops an action from taking place. And these include deterrent, which are only discouragements but they can be strong to weak discouragements. We have the detective, which provides the alert function. We have recovery, which enables the recovery of system failures or attack results, and then corrective. Now the difference between recovery and corrective is the difference between macro, which would be recovery of an entire system, and micro, the corrective of a misconfiguration. So it's a matter of scale that you'd use to differentiate between recovery and corrective. And then we have compensating. This category will actually provide a great many controls because we may have a primary need and we may have a primary control option but that primary control option may have a secondary effect that is intolerable for some reason. So a blended alternative of other kinds of controls, say a physical and a procedural, instead of some technological solution that though it sounds good actually is technologically fragile and thus insufficient to the need, those are the kinds of compensations we may have to make in many cases. But they can be very effective if they're properly built and implemented. 

So for our administrative controls we have these kinds of examples, policies and procedures, access management, security policies, monitoring, privilege management, and so on. As the name indicates, these are the kinds of controls that guide us in how we are going to do things. They set policy to ensure consistent definition and enforcement, and we follow these to make sure that the controls are actively performed, monitored, measured and reported on as we work through our system. The logical or technical controls are oftentimes implementations extracted from the administrative policy or procedure. And they will include things that we do in the hardware, software, network, firmware and other technical aspects of our systems to ensure that we achieve the goals stated in our policy. And these are just some examples, such as network access, malware control, cryptography, remote access and many other types of controls. And then we have our physical controls, which are also implementations extracted from our policies and other administrative control types. And here you have six samples of what that might include. These might be as comprehensive as building design and various features that we want added to the building design, or location that we select, they could be the employment of a security guardforce or environmental controls such as fire suppression systems. Window types, based on the business we are, a certain kind of window might be required at ground level to prevent breaking and entering. But those are physical controls that can add significant value to the overall security program.