Course Introduction and Security Basics
Governance, Compliance and Risk
The course is part of this learning path
In the last decade, the nature and complexity of security attacks have increased tremendously. From simple attacks, which focused on hacking exposed web pages, we have evolved to stealthy attacks, which focus on the hacker staying hidden for years on end inside the victim’s network with the sole purpose of stealing data.
To make matters worse, more and more companies have started to store their data in the cloud, thereby transferring part of the responsibility of securing that data to the cloud service provider. Therefore these days the cloud service is entrusted with the task of providing adequate security to the data and services that it provides to customers. While making a decision to move to the cloud, the two main metrics that enterprises look at tend to be cost and security risk. This course takes a deep dive into cloud security and how to mitigate the risks facing cloud-based infrastructure.
If you have any feedback relating to this course, feel free to reach out to us at firstname.lastname@example.org.
- Understand the basics of cloud security
- Learn about security techniques such as asset management, access control, physical security, and operations security
- Understand how to manage the vulnerability of your systems and applications
- Learn how to monitor and respond to events and security incidents
- Solutions architects
- Data engineers
- Security engineers
- Anyone who wants to learn how to secure their cloud infrastructure
To get the most out of this course, you should already a good understanding of cloud infrastructure and operations. Basic knowledge of IT security would also be beneficial.
The first step in customizing an existing framework to suit your enterprise is to perform a risk assessment. A risk assessment is made up of several steps as shown in the slide. Let's look at them one at a time. The first step is identification of assets. Many organizations fail at the first step because they do not maintain a periodically updated asset inventory. This is very critical to any form of security governance and is in fact, the basis for the next steps. If you do not know what you have to protect, then how are you going to protect them? Assuming we now have an accumulated and updated asset inventory the next step is to carefully list out all the relevant threats that face these assets. It is possible to get a list of threats from numerous repositories on the internet, or we could use our experiences and common sense in listing them out. BSI Threat Catalog, NIST 800-30, ISO 27005, and Microsoft Threat models are good references.
Let's take a look at the example of mapping assets to threats. Let's say you have a server that is internet facing. Possible threats that could be facing the server are threats of being hacked by a hacker, the data on it being manipulated by a disgruntled employee, or the server becoming inoperable due to a fire that may occur in the data center where it is housed. We need to do this with each and every information asset that we possess. Once we have this we need to see how many controls we already have in place that might mitigate the effect of these threats. For example, we may have a hot site that is ready to go in case fire destroys the asset. So, we go through the list of assets one by one, to map out the controls we already have in place.
Now do an analysis to see if the controls are sufficient to protect the assets from the threats enumerated above. This will give us an idea of how many of the threats listed out above have already been taken care of. Once we have done this, we next need to map the vulnerabilities that these assets are exposed to. For example, we may not have an effective patch management system in place, and hence, this might expose the server to being hacked by a hacker. There may not be an effective fire prevention system in the data center that might expose the server to the risk of fire. Once we list out the vulnerabilities, we then can go through the NIST National Vulnerability Database also to make sure that we haven't missed anything. So now we have a list with the assets and the vulnerabilities that it is exposed to.
The next step is to identify and assess the consequences of these vulnerabilities. Let's take an example of a server exposed to the internet. We have already ascertained that the server is not patched regularly, and hence is vulnerable to being compromised by a hacker. One of the consequences of this attack, let us for the sake of this example, say that the server contains data crucial to the functioning of the website and hence, if it is compromised there could not only be a loss of data, but also the hacker could decide to change the data, or he could shut down the server. The impact to the website, and hence the enterprise, is catastrophic. This consequence analysis is done for every pair of threat vulnerability. Once we have the list of all the consequences, we need to quantify it.
As we already discussed security is about confidentiality, integrity and availability. So, what we do now is to create a five point scale and assign a score as to the impact on CIA, that is confidentiality, integrity and availability, the vulnerability might have. Let's go back to our example of the server. We have ascertained that the hacker can take control of the server, and hence steal the information stored in it. This is a loss of confidentiality, and hence, the score will be five out of five. Next we look at integrity. We said that in the attack the hacker has modified the data. This impacts the integrity of the data, and so, we say that the score is five out of five.
Next we see that the hacker can shut down the server and bring the website down. So once again, we give it a score of five out of five. So, we have a score of five for the impact on confidentiality, integrity and availability. Having calculated the risk impact using the impact on confidentiality, integrity and availability, here we see that the server has been hacked, the data stolen and modified, and shut down. It gets the highest number in terms of risk impact. We then look at the risk evaluation are putting a number against this risk impact. This is called risk evaluation. In order to do this, we need to assign a number called risk likelihood to the situation above. Risk likelihood is the probability that an incident will occur. In our case of the internet facing server, which has not been patched, this has a very high likelihood of being hacked. And as I say this number is 95%. This now is called a likelihood that the server will be hacked. We take this number and we multiply it with the risk impact co-calculator above.
So, we have five plus five plus five and 2.95. This is the value of the risk to the server. This process is called risk evaluation. Having come this far, we now have an idea of the risk which is quantifiable. We calculate this number for each and every asset we have and order it in terms of value. So, the asset that comes at the top of the list is the most risky, and as we go down this list, the asset gets less and less riskier. We now have to decide what we are going to do about this risk, and this process is called risk treatment, once we have evaluated the risk's core of an asset, we have a couple of options open to us on how we want to proceed forward. We could mitigate the risk, we could transfer the risk, we could avoid the risk, and finally, we could accept the risk. Risk mitigation is the most frequently used way to handle risk. Here the company puts in place controls to reduce the impact of the risk to the assets.
In our example of the internet server, which does not have a good patching process in place, the company might decide to mitigate the risk by putting an effective patching process in place. It could put the server behind a well-configured firewall, or put a network intrusion prevention system in place. These are all mitigation controls. The enterprise could also decide to insure the asset in question. This is a process of transferring the risk to the insurer. This is called risk transference. This is another way to handle the risk. Outsourcing the data center to an outside firm is another way of risk transference. The third way to handle risk is to avoid it all together. Say, if a company feels setting up a data center in the Bay Area is too risky, because of the eminent threat of earthquakes, and moves to a safer state, then we say this company is avoiding the risk of earthquakes.
A company that decides to set up a data center in the Bay Area after fully understanding that there is a risk of earthquakes is an example of a company that has accepted the risk of earthquakes and still decides to carry out its business out of California. This is called risk acceptance. So, we see here that there are four ways we can respond to or treat the risk that face our assets. Once we have decided what we are going to do with each of the risks that are facing our assets, we go ahead and treat each of the risks in the manner we have decided, namely to either mitigate, transfer, avoid or accept.
Vish Chidambaram is an Award-winning Enterprise Security Leader with 18+ years of experience skilled in areas spanning Automation, Security Operation Analytics and Reporting, Threat Management Life cycle, Agile/DevOps environments, SaaS/Cloud security, Business Development/Consulting, Program Management and more. Most Recently Vish was the CISO at Rubicon Project, which is a SaaS based ad marketplace where he was responsible for securing a high performance SaaS platform with 40billion transactiions per day. He pioneered the integration of security in DevOps, by using automation, orchestration and machine learning tools He is passionate about teaching security and believes staying current is particularly relevant in the security industry. He also mentors security professionals and advises them thru career transitions. and details can be found at datacoreacademy.com or writing to email@example.com His linked in page is https://www.linkedin.com/in/vish-chidambaram/