The following is an excerpt from the book Collaboration with Cloud Computing written by Ric Messier and published...
by Syngress. This section from chapter 10 talks about the basic principles to provide a framework for analyzing risk management in the cloud.
We are hardwired as a species to perform risk management and we aren't the only ones. As a result, you might think that it's just something we are natively capable of and shouldn't require a lot of introduction for everyone to be good at it. After all, we do risk management without thinking about it in our own lives. Whether to push through a yellow light at the very last second, whether to drink the milk that is just a bit past the sell by date and has been in the refrigerator for more than a week. There are a lot of little decisions that we make all day long that are based on understanding risk, even if it's not a full-out risk assessment leading to those decisions. However, when it comes to making decisions related to your business data and resources and how best to manage them, you can take a seat of your pants, gut-based decision, but it probably makes more sense to follow a better documented approach to make decisions based on provable data.
One of the challenges associated with risk is that perception plays a big role and perception isn't always accurate. I remember after the events on 9/11/2001, several people I knew became worried about flying on a plane. The reality is that the risk of such attacks had always been there, it's just that suddenly these people became aware of the risk. The idea of planes being hijacked had never occurred to them. The reality, in fact, is that flying shortly after 9/11 probably was much less risky than before because of the heightened awareness and increased security but also because the people who were mostly likely to attack had just launched an enormous planned attack and it was unlikely they had another one planned so quickly afterward and that sort of attack took a lot of time and planning to pull off so it wasn't a spur of the moment thing.
Risk management is such a large topic that there are entire courses built around it, not to mention entire books written about it. As a result, this will really just be skimming the surface of risk management, but it's worth talking about some basic principles to provide a framework for analyzing your own situation. This is really helpful if your business is entering into unfamiliar territory. You need to be able to analyze the risk associated with a move to a cloud-computing infrastructure before you hand over critical or sensitive data to something outside of your control. There can be a lot of advantages to it and it may actually end up improving your risk position, but you need to go through the exercise of evaluating where you are so you can make that determination.
There are a number of ways to approach risk management and, as with many other things, there are advantages and disadvantages to the different approaches. One of the biggest challenges you'll run into is a difficulty in assigning actual numbers to some of the factors we put into our analysis. I want to cover that right up front. We'll be talking about probability and value and some other factors and sometimes those are really difficult to assign actual values to. What is the probability of an attack taking down your whole site? How many of those can you expect to see annually? Unless your site has been attacked several times over a period of years, it can be difficult to come up with real numbers there. However, even in the face of solid and accurate numbers, you still need to put something together to be able to make decisions from.
How do you go about making those decisions? There are a number of data points that you can use that require a little bit of math. Before we get into the math, though, it's worth talking about a little bit of vocabulary that you should understand so we can talk about the math formulas and have them make some sense. The first thing we need to talk about is an asset. An asset is a resource that has some value associated with it. It doesn't matter what the resource is or even what the value is. If you can assign any value to a particular object, whether it's a system or a piece of data, or intellectual property, you have an asset. We will be talking about assets as they are one of the fundamentals of risk management. Your risk management strategy will be all about protecting your assets, no matter what they are. It's also worth noting that risk management is a process and it's not one that stops after a single iteration. You will constantly go through iteration after iteration. New threats arise on a regular basis. You may introduce new systems. There are a number of ways that the risk to your organization may change. This is certainly true if you are planning to make a move from traditional IT systems to cloud based. You have to periodically review threats and what it may take to mitigate those threats so you can make some determinations as to whether it's worth taking the steps necessary to protect yourself. It's probably worth repeating but risk management, like any good security program, is a process and one that should constantly be revisited for changes.
Figure 10.1 is a diagram of one risk management process. There isn't one and only one risk management process. You can do a quick search of the Web and turn up a few, but the one that is presented here is a pretty common one and it's also pretty straightforward. We'll revisit various aspects of this process through the rest of the chapter, but it's worth discussing the general framework now.
- Identify the risk -- The first thing you need to do is to identify the risk. When it comes to information technology, there are a large number of risks. When it comes to making use of a cloud service provider, there may be a number of risks that need to be investigated, including the risk of placing sensitive business information with a third-party provider.
- Assess and analyze -- Assessing and analyzing means taking into account stakeholders, identifying all positives and negatives, and performing a quantitative analysis using strategies like cost–benefit analysis (CBA).
- Determine action -- Once you have performed the analysis, you can determine what you want to do. You might choose to limit the risk, remove it or just accept it. You can make this determination based on the analysis performed in the step above.
- Implement and monitor -- Once you have an action, you can implement it. In the process of implementing, you will want to monitor the implementation to ensure that it was done correctly and that it did what it was supposed to do. Monitoring is an important part of this process.
- Measure and control -- This requires that you know enough about the risk to be able to determine what could be measured and monitored in order to further evaluate the continued risk. Once you have determined what you need to be watching out for, you can implement controls to measure and contain the risk.
- Start process all over again -- Containing the risk may well be a temporary process. Let's say, for example, that you have some concerns about the Web server you have installed. You can install firewalls to help protect your system but in the end, the Web server is always going to be vulnerable through port 80 which has to be open for content to be served up through it. The firewall will protect the other ports from being exploited but that one port will always be exposed. You may install an intrusion detection system as a monitoring control but that doesn't remove the risk. It just helps you keep an eye on it. While you may have updated the Web server software shutting down a current vulnerability, there may well be more vulnerabilities to come. This is why you need to constantly evaluate the risks that your business is exposed to, which involves the whole process and constantly iterating through it.
We've been talking about risk management but we should also be clear about what a risk is. We also need to talk about threats and vulnerabilities since all of these words are tied up together. A vulnerability is any weakness you may have in a system, whether that system is physical like a piece of hardware or whether that system is a process that involves people. A vulnerability is any weakness in any system. If I can take advantage of that weakness and compromise your system, I have exploited the vulnerability. An exploit is an action that takes advantage of a vulnerability. You will see a lot of talk about vulnerabilities and exploits, particularly with all of the transparency around fixes and system updates. Just because you have a vulnerability, by the way, is not a guarantee that it can or will be exploited. Even if there is a known exploit for a vulnerability doesn't mean that the exploit is guaranteed to work. There are a lot of factors that go into that and we will talk about some of those factors later on.
I have my asset that has a value. I have the potential for something bad to happen to that asset through vulnerabilities and exploits. Where does risk fit into all of this? Risk is an exposure to a potential for loss or an adverse situation. If there is a possibility of something bad happening, you have a risk. One of the big components to this, though, is the probability or chance of something happening that would cause loss. While you may be able to calculate the probability of being hit when you cross the street in front of your house and compare it to the probability of getting hit if you step off the curb on 7th Avenue and 42nd Street in New York City against the light, it can be a lot harder to calculate the probability of your system being compromised or attacked.
While there are a lot of attacks taking place all over the Internet all the time, there may not be attacks against every server on the Internet all the time. Most attacks are more targeted than that. It depends a lot on who you are, what you may have, and most importantly what services you have exposed to the Internet. You may have done a lot of work hardening up your operating system, shutting off all ports and introducing a firewall out in front of your systems to ensure that only traffic destined for the ports you want is allowed into your network. When you do this, you are mitigating the risk to your systems. When you mitigate risk, you are trying to lessen it so it isn't as great. Ideally, you take the risk as close to zero as you can though that's not always possible.
Once you have done what work you can mitigating the risk, you are left with what is called residual risk. You have some options when it comes to the residual risk that are pretty similar to the options available to you before you mitigate the risk. The first choice you have is to simply accept the risk. This requires full understanding what the risk actually is and deciding that doing anything else about the risk would cost more than it would save. You may also simply say that you don't believe the risk is real, meaning that you don't believe it would ever manifest so there wouldn't be any value in doing anything to remove the risk. If the service under evaluation is simply mission critical and/or core to your business, you may simply have to accept a lot of risk associated with it. As you can see, there may be a number of reasons you would just accept risk.
Accepting risk is actually something we do on a regular basis so it may not be as wild an idea as it may seem when simply written boldly, as above. When you board a plane to see your family on the other side of the country, you accept the risk that the plane may experience a problem in the air, forcing it to the ground. In reality, though, there is far more risk in getting behind the wheel of your car each day. You may not be aware of the risk that's associated with driving on public roadways or you may be aware and recognize that in order to get around, say from home to supermarket or home to work, you have to just deal with the risk.
Others may not agree with this, but I don't believe you can accept a risk without being fully aware of it. In the case of driving, you may not be aware of it. In a business sense, you may not be aware or you may not have been given the complete story with respect to the potential impact a risk may involve. If there is money associated with the deployment of a system that has risk associated, the impact or probability may be downplayed. Based on a less than complete picture of the risk, it's hard to say you have accepted the risk since what you may have accepted isn't the actual risk but some subset of the risk.
Collaboration with Cloud Computing
Author: Ric Messier
Learn more about Collaboration with Cloud Computing from publisher Syngress
At checkout, use discount code PBTY14 for 25% off
What you may choose to do is mitigate the risk. Even if you have mitigated the risk already, you may choose to continue to mitigate it. After all, until it's completely gone, you can always mitigate further. There may be a number of reasons not to further mitigate your risk, including the cost. Going back to our driving example, when you drive you presumably put your seat belt on and that act can help mitigate the risk associated with being out on a busy road with a lot of other drivers with varying degrees of attention and experience. You may further mitigate your driving risk by ensuring the car you drive has air bags. Of course, this may help and protect you but it won't do much to help your car survive an accident. You could mitigate that risk and the costs associated with it by investing in a car that is more rugged and built to be sturdier, of stronger materials.
This brings up some interesting things to talk about and they are really important to analyze and assess step. The first is something we've touched on previously and that's the asset -- the thing you are trying to protect. In this case, primarily it's you. However, there are also costs associated with keeping you alive and healthy but causing damage to the car. First, there are out of pocket costs associated with repairing or replacing a damaged or totaled vehicle. However, there is another cost to consider that's harder to put a dollar value on and this is something that you will run into a lot when you do a risk analysis. There is cost associated with the annoyance of being without a vehicle. If you have to replace your car, there is time associated with going car shopping. Your time costs money and you can factor into that cost other things you aren't doing because you are having to shop for a car or run around to repair shops getting yours repaired. Your auto insurance may pay for a rental, but there is also the time associated with getting your rental and returning it, not to mention the associated challenges of what you may be allowed to do with the rental, based on the cost your insurance company might be willing to pay. Given the cost, you may be limited in the number of miles you can drive. In many cases this may not be a problem but if you have a long commute, that can be a challenge.
In short, there is more to costs than just the monetary value of the particular asset you are talking about. There can be a lot of soft costs as well that may get overlooked and are sometimes hard to quantify. We talked about the costs of rentals and there are certainly costs associated with replacing your totaled car, but there are also the costs associated with your time to run around and get estimates. When it comes to some of the calculations associated with risk, it's helpful to consider the bigger picture and think about what might go into repairing or restoration of an asset if something bad were to happen.
There is a good reason for that and not just because it's a good idea to know what value your assets and resources have. When you want to apply a quantitative analysis of your risk, you need accurate numbers. There are a handful of calculations that go into a quantitative analysis. One of them is the annualized loss expectancy. The annualized loss expectancy requires not only an understanding of how much an asset is valued at but also a probability calculation around whether something is going to happen or not and how frequently it happens. When you calculate the annualized loss expectancy by taking the single loss expectancy, which is the value it would cost if a risk were to actually materialize against the asset, and multiplying it by the annual rate of occurrence which is effectively a number based in probability. As mentioned earlier, if you have a long track record in business, you may have a good idea how often events are likely to happen.
As an example, when you own a retail business, you can probably predict how much you are going to lose in theft or damage after you've owned the business for a while. While there are statistics across retail as a whole, it takes an understanding of your particular store which includes what you sell as well as where you are located since some areas are more prone to crime and theft in particular than others are. Other businesses are harder to predict the occurrence of loss for. That's really what you are doing, though, when you calculate the annual rate of recurrence. You are placing a number on an expectation of an event happening and how often it is likely to happen. Maybe you expect a risk to materialize once every 3 years and the asset is worth $60,000 when you total everything in. In order to get the annualized loss expectancy, you would multiple 3 times $60,000 and you can expect to lose $20,000 from that asset each year.
You may be wondering why we would go through this particular mathematical exercise. The reason is so you can quantify values of your assets that are exposed to risk. Once you have done that, you can make informed decisions about which assets are most at risk, not based on a perceived level of risk but based on the cost to come back from a risk if it was realized against that asset or resource. You can order the assets and risks based on how much you expect to lose if a risk were to be realized.
Return on investment
As part of this exercise, you may want to consider thinking about a return on investment. Just because one asset might be very costly to recover if it is damaged as part of an attack or incident. A return on investment calculation can make generating an ordered list of projects geared toward protecting assets much easier. However, it may not be the easiest calculation considering that what we are probably talking about in light of the subject matter of this book is information technology infrastructure and a return on investment suggests that there will be a monetary gain to come from the investment. If, for example, you were a farmer in my home state of Vermont. You would produce milk more than likely because Vermont has a lot of milk farmers. Growing much in the way of other crops is challenging because of the terrain and the large quantity of rock.
When you buy a cow, you might expect that cow to product something over 2500 gallons of milk per year. The farmer gets paid something around $1.50 for each gallon of milk the cow produces. Let's imagine Speedwell Farms is looking to increase its herd and let's say a cow costs $1500. Without factoring in any other costs like feed and the cost of upkeep on the farm -- equipment, electricity, maintenance, any help that may be required to sustain the farm -- we can do a quick calculation on the return on investment. In 1 year, an average cow might generate $3750 in milk. If you figure the cow cost $1500, you could say that the farmer had generated $2250 in profit on that cow on a cost of $1500. The return on investment could be calculated as 2250/1500. That gives me 1.5. If I multiply that by 100, I will get a percentage of 150%. The farmer's return on investment is 150% in just that first year, right?
The problem with that calculation is it doesn't take into account any of the costs associated with keeping the cows. Return on investment is typically calculated as a net gain and not the gross gain that we calculated above. Some of the costs, though, might be difficult to calculate or put a number to. For example, the farmer may actually own a lot of land that he hays in order to get food for his cows. If he owes a bank for that land, he may factor the cost of his mortgage into the overall cost to operate his farm. If his land is paid for, the cost of haying is the maintenance costs of the tractors and other equipment necessary to hay and bundle as well as any fertilizer or irrigation costs if there are any. However, this doesn't take into account the time of the farmer and haying can be a very time-consuming operation. How does the farmer, who doesn't get a salary, calculate his time to factor into the cost of maintaining his cows?
We run into the same sorts of challenges in the information technology world. Yes, we can calculate the equipment cost, not to mention the electricity and Heating, Ventilation and Air Conditioning (HVAC) costs. What is the cost of a system being down, though, as a result of an incident? You may be able to calculate the cost of the man-hours it takes to restore the service, but these are people you are already paying so the costs there are a little squishy. It may simply be easiest to do the man-hour calculation because if you start factoring in costs of other projects being delayed and not completed on time as a result of people being pulled off to work on the restoral, calculations start to get far more difficult.
In order to calculate the return on investment of many IT-related projects and certainly security projects, you have to calculate how much you are going to save by implementing the project as opposed to how much you are going to make since IT and security projects don't actually make money. They can help the money making process by automating sales or even providing a mechanism for customers to purchase goods and services online, but in general, it's not nearly as direct a correlation between these sorts of projects and, say, buying a cow.
Social return on investment
One factor that often comes into play, particularly in recent years, is the cost from a social or reputation perspective. When you have an outage resulting from an attack or an incident, your customers are impacted. Overall, you may not end up losing any money directly, depending on the severity or the duration of the incident because customers may try again later as opposed to simply giving up. If, as an example, I wanted a book or some other product from Amazon and I found myself unable to get to Amazon's Web site, I would likely try again later rather than just not buying it or trying to find another source for the book or other product I was looking to buy.
However, if the duration is long enough, I may start to wonder whether the company I was looking to do business with was stable enough that I would want to keep doing business with them. Rather than picking on Amazon any longer, especially considering their infrastructure and track record, let's talk about an attack that did actually happen. Sony's PlayStation Network and Qriocity services experienced an extended outage over the course of 24 days in 2011. In addition to this, roughly 77 million user accounts were compromised. While this may not have had a direct impact from a revenue standpoint, since these were customers who had already paid for the service, it may have impacted new subscribers.
In most cases, an outage of 24 days would have had a significant consequence on a business' reputation that may have prevented customers from either continuing with the service or adding any new members. In Sony's case, they were fortunate to have a more or less captive audience. Anyone with a PlayStation had to use the PlayStation Network in order to interact with other users from their PlayStation. There were no competing services or networks for PlayStation users. Some users may have gone looking for another gaming console, though that seems unlikely in the majority of cases because people get attached to their consoles if only because they have a set of games that only work on that one console and not any others.
However, Sony did put together a "Welcome Back" package providing users with incentives for returning to the PlayStation Network when it came back online. They offered free games and other incentives to users in order to restore goodwill for the service and get users back with their subscriptions. In addition to the identity theft program they introduced in the wake of the breach, the cost of the "Welcome Back" package and all the other costs of the recovery totaled $171 million according to their year-end financial statements. It's hard to say what the cost to Sony in terms of reputation was.
In recent years, a new measurement has been used to calculate some of the softer costs associated with reputation and other social factors that could impact the bottom line of a business. Social return on investment (SROI) is an attempt to put numbers to a number of factors that don't traditionally have monetary values associated with them. While the SROI is intended to factor in things like environmental and social impacts in a positive way, the strategies associated with it could easily be used to take into consideration the negative social impact of not protecting systems, assets, and resources and having those systems, assets, and resources become impacted by an incident. If the negative cost to consumers and reputation had been factored in while making decisions about protecting Sony's network and systems, would any decisions have changed? Perhaps not, but it's worth considering the potential threat to your business if something were to happen to your assets that are used to service customers.
At the end of the day, what we are really talking about is all of the numbers that you would take into consideration when performing a CBA. A CBA is a facts and numbers-based strategy for making business decisions. It can be very well defined and systematic and can help the decision-making process. Businesses have limited financial resources and have to find ways of deciding where to place their investment dollars. A CBA can help with that. A CBA really has two purposes that will be helpful to us. The first is to help make good business decisions based on a defensible justification. The second is perhaps more important and that's to provide a basis for comparing multiple projects.
Ultimately, when you are going through a risk management exercise, you need to do a risk assessment as discussed above but when it comes time to jump into project work, you want a prioritized ordering of projects. After all, once you know how much each project is going to cost you and what you will get out of it, you can make objective decisions. You'll be comparing apples to apples, so to speak, because the advantage of a CBA is getting everything into the same language by putting costs to things and ensuring that there is a time value associated. There is a timing consideration, of course. Costs accrue over a period of time, particularly when you are talking about projects and associated business operations, and values of resources change over time as well. The timing of all of this has to be factored in when you come up with your final figures.
In the process of performing a CBA, you need to identify the stakeholders. This would be anyone who would be affected by a change in the resource in question, whether a positive or negative change. This can be an extremely beneficial task in itself, actually. Sometimes you don't know who is likely to be most impacted by the loss of an asset or resource until that asset or resource is actually gone. In the case of a customer-facing resource like the systems in a Web application, you can't very well have the customers themselves involved in the process but you would have the line of business to represent the users and their needs. The line of business should be one of the stakeholders representing your customers. You may also consider executive management, information technology workers, as well as financial management, who would be able to provide information about associated costs. Operations staff are also important to take into consideration since they are the ones who have to manage either the systems or the customers or maybe both.
Financial professionals will also be important to bring to the table for a couple of other reasons. The first is because you may need help coming up with a common currency to define everything in. You need to assign dollar values to damage, hours and various other elements that you will need to factor into your CBA. Without that common currency, you will have a lot of numbers that can't be compared because they don't mean anything in relationship to one another. Another reason why financial professionals are important is because they will understand the calculation of things like depreciation, as an example. You can't simply apply the value you purchased an asset at when you start calculating value over time. Assets generally are worth less over time so you have to apply a reasonable rate of depreciation to them. This needs to be calculated into the cost and the benefit to get a true picture of what has been lost, if the risk were to materialize.
Once you have applied all of the numbers to all of your options, you can then compare them. One thing you don't take into consideration as easily with a CBA is the criticality of one resource over another. If you are deciding to move forward with project A because you get better bang for your buck than with project B without taking into consideration how important the resources involved with project B are, you may end up not fixing a more significant problem. While this should have been factored into all of the costs and benefits, there are challenges at times when it comes to determining critical or sensitive resources and assets.
Quantitative assessments are based on facts and associated data. As mentioned above, it may not take into consideration the real sensitivity of one of your systems. Or when it comes down to ensuring that the criticality is factored into your calculations, it might be difficult. This is where a qualitative assessment comes in. A qualitative assessment takes into consideration less tangible factors and is based more on gut reaction than on hard facts and data. This isn't to say that your gut reaction can't be based on numbers you are aware of, but if there are factors that are difficult to quantify, you may rely on a feeling or instinct that will help you make a decision as to where you want to apply your limited resources to better protect the enterprise.
When it comes to making decisions about what projects you take on, you may at the end of the day make your decision based on intangibles rather than on something you could easily put your fingers on. As an example, let's say you had a Web application that your customers make use of. It's based on some open source content management system. You have a certain amount of sensitive information in the database that the Web application uses for persistent storage. Your IT people are recommending an expensive Web application firewall installation along with load balancers. You have a limited budget for projects and you are weighing that one against replacing an aging payroll system that is running on an older operating system because of the support requirements. While there is a good case for protecting your customer-facing infrastructure, it somehow feels right to make sure your payroll system keeps running so spending the money to upgrade there may make more sense.
Obviously, when it comes to a qualitative assessment process, there are no rules. It comes down to your instincts and preferences for risk. There may be some areas you just feel more comfortable accepting risk in than others, regardless of what the numbers say. Another thing to keep in mind is that when it comes to quantitative assessments, some of the numbers are going to be based on qualitative assessments anyway, especially when it comes to the probability side. When it comes to things like hardware failures, you can use the statistics that are available for each piece of hardware and be reasonably comfortable with the number of failures you are going to see. When it comes to security incidents, it gets to be harder. It can also be hard to put actual numbers on the cost of an incident, especially when you have never had one at your business.
Some businesses are more natural targets than others, but that doesn't mean that you won't be a target just because you aren't in a high value market -- you don't have a lot of intellectual property or information. There are also targets of opportunity and you could easily be used as a launching pad for other attacks if you are exposed enough. You should always factor being complicit in other attacks into your decisions and not just on what you want to protect. Saying you don't have anything of value may be fine for you but it could make finding the real attacker harder in a compromise at another site.
A security policy is a statement from the management of an organization as to what is important to them and how they expect people to behave when it comes to information systems. They will involve a lot of definitions in order to be very clear what the expectation is. A policy is also specific to a particular area and your organization will likely have a number of security policies including an Acceptable Use policy outlining appropriate uses of a computer system or network. You may also have an Ethics policy, a Remote Access policy as well as a Wireless policy, a Mobile Device policy, and maybe a Bluetooth policy. Each of those would cover the specific requirements for that area of computing usage.
Once you have a set of policies, those will cascade down to the creation of standards that are a bit more specific than a policy in that they may be based on specific systems. As an example, you may have a Bluetooth policy that would then have standards that were geared toward the implementation of the policy on Windows, Mac OS, and maybe Linux if you had those operating systems within your organization. A standard is something that has to be followed and may have specific procedures for how you would comply with a policy. If you were looking at the standard for Windows that talked about implementing the Bluetooth policy, you may have a specific set of procedures for disabling Bluetooth on your system. On a Windows system, for instance, your standard may indicate that you should disable the Bluetooth service as indicated in Figure 10.2.
In addition to policies and standards, you may have guidelines. While guidelines have system-specific information and procedures, they differ from standards in that they are not required. They are strongly recommended but they are not requirements. They are a set of details that may outline a best practice. If they were required, though, they would have been outlined in a standard, rather than a guideline. This doesn't mean, though, that you wouldn't hope that guidelines were followed as well.
As far as policies go, though, your policy should have a purpose and a scope to start off with. This outlines the expectations of the outcomes from the document. It sets the parameters for what will be covered in the policy. The meat of the document, though, is set out in a series of requirements. As an example, an information sensitivity policy would include the different data classifications as well as the requirements for each classification. Additionally, the information sensitivity policy would detail how you would handle the documents -- where they could be stored, who could access them, how they might be transmitted, and so on.
Finally, the policy should also include a section on enforcement. The policy not only outlines the expectations but also what could happen if someone violates the requirements outlined in the policy. This may often just indicate that someone found to be in violation would be subject to disciplinary action. Depending on the policy and the importance of it, that disciplinary action may go all the way to termination.
Legal and regulatory requirements
In addition to the requirements of your own organization, you will have to take into account any legal and regulatory requirements that your business may be required. There are a number of requirements that you may have to incorporate into your security policies, including the Payment Card Industry Data Security Standard (PCI-DSS), the Health Insurance Portability and Accountability Act (HIPAA), and the Federal Information Security Management Act (FISMA). Some states may also have breach notification laws where you would have to provide public notice if your business has been breached. Different states will have different thresholds before those laws kick in.
In addition to US laws and regulations, different countries also have their own laws and you may fall under those laws if you do business in those countries. Additionally, when you are considering cloud services, if your cloud provider has facilities in other countries, they would fall under those laws and regulations as well. It's worth knowing where your data is actually being stored and what sort of laws are regulating the storage and handling of it. As an example, Germany passed a law in 2007 that made illegal the disabling or circumventing by an unauthorized user any measure that is put into place to provide computer security. This also includes the manufacture or installation of any software whose primary purpose is to disable or circumvent computer security.
On the surface, this sounds like a fine idea. The problem with it is that many businesses make use of such software to ferret out any holes in their own security infrastructure. Any vulnerability scanner like Nessus or exploit framework like Metasploit couldn't be used in Germany or on any system in Germany or it would be a violation of this law. This could have an impact to the safety and security of any data that is stored with a German company since the law has made it much more difficult to ensure that the security programs they have in place are adequate for protecting their systems and any information stored on them.
Policies themselves are only pieces of paper and no matter how many threats about termination of employment may be mentioned in those policies, all you have to do is drive down any street to see how good people are at following rules, even when there is a stiff penalty attached. As a result, just as with traffic laws, you want to make sure you have some enforcement in place. This is what we call controls. When it comes to policy enforcement, you need a way of monitoring and measuring whether they are being followed. For example, you have a policy of only using authorized and approved wireless networks and access points. This helps to keep down the use of unauthorized systems on the network as well as cutting down the risk of access to your internal network from outside the building. You need a way of determining whether anyone in the building is running a rogue access point.
This is not necessarily a difficult problem. Periodically, you scan your physical location for any wireless networks. This can be done easily using any computer and, often, just the wireless network drivers installed with your wireless interface. The operating system will generally very happily locate all security set identifiers (SSIDs) in the area. If you want something more than that, there is a lot of software that will provide a lot of detail on the strength of the signal and the details of the access point that is broadcasting. When you write down a procedure for doing these periodic scans and then taking action as a result of the findings, you have created a control.
If you struggle with coming up with a set of controls to go with your policies, you could look at a control framework. Fortunately, there are a number of places that have frameworks in place where you can go and get a start on your security policies, standards, and controls. The National Institute of Standards and Technology (NIST) has special publication SP 800-53 that outlines 18 areas for security policies. The Department of Defense (DoD) has specified 8 Information Assurance areas and controls in DoD Instruction 8500.2.
ISO27001 is an information security standard defined by the International Organization for Standardization (ISO). ISO27001 was updated in 2013 and includes specifications for 114 controls in 14 groups. The 14 groups that the controls are organized into are as follows:
- Information security policies
- How information security is organized
- Human resources security
- Asset management
- Access controls and managing user access
- Cryptographic technology
- Physical security
- Operational security
- Secure communications and data transfer
- Secure acquisition
- Security for suppliers and third parties
- Incident management
- Business continuity/disaster recovery
The 2013 update includes more controls than the previous version. In 2005, the last version of the standard had 11 groups and 133 controls. While the number of controls has decreased, the number of groups has increased. The changes were made to have ISO27001 fit better alongside standards like ISO9000 and ISO20000. The newest standard also includes sections to cover the reality that a lot of organizations outsource some of their IT functions.
The fact that standard frameworks come with a large number of areas where policies and controls fit in might be an indicator just how important it is to have your paperwork in place. Paperwork, meaning policies, isn't enough, of course, but pulling your policies together will provide you a way to organize your thoughts and priorities when it comes to your security strategy. Risk management and security policies go hand in hand. In part because risk management will inform your security policy and a security policy may mandate what a risk management process will look like.
The most important thing to keep in mind is that no matter what road you take from a risk management perspective, whether it's quantitative or qualitative or somewhere in between, it's a cyclical thing. You will be constantly going through the process of assessing your risk and then deciding what to do about it, whether it's accepting it or remediating it or simply removing it.
Some key points to take away from this chapter are:
- Risk management is a process that you will keep going through.
- CBA is a way to put some structure around your analysis using a consistent currency in order to compare projects head to head.
- Quantitative analysis takes facts and data into consideration.
- Qualitative analysis is sometimes necessary in order to make decisions where you can't use facts and data or where facts and data are not sufficient.
- Controls are used to monitor and measure your environment to determine violations of security policy.
Here are some ideas to come away from this chapter with:
- Risk management is a process and one that should never end.
- Different people may handle risk in different ways.
- Quantitative assessments use data to help make decisions about risk and projects.
- Qualitative assessments use subjective information to help make decision about risk and projects.
- There is an SROI that could be taken into account -- this could be goodwill or word of mouth.
- Understanding how to perform a CBA is an important part of doing a risk assessment.
- There are a lot of legal and regulatory requirements to take into consideration that may help guide decisions when it comes to risk analysis.
About the author:
Ric Messier GSEC, CEH, CISSP, WasHere Consulting, Instructor Graduate Professional Studies Brandeis University and Champlain College Division of Information Technology & Sciences.
Read SearchCloudSecurity's mini learning guide on cloud computing risk management for more information
View a webcast on the changing face of cloud risk management and security