Wednesday, November 6, 2019

Clean up!


I recently visited the Risk and Resilience Festival at the University of Twente. One of the keynote speakers was Maarten van Aalst, Director of the international Red Cross Red Crescent Climate Centre, and professor at the University of Twente. He told a story about Bangladesh and how the frequent flooding lead to increasing numbers of casualties. It was too simple, he said, to blame climate change. A much bigger impact was the increasing population. The more people there are living in the Ganges Delta, the bigger the exposure. It reminded me of the fact that exposure is often something we can influence.

A common approach in IT risk management is to carry out a Threat and Vulnerability assessment (TVA). In cyber security, a threat is a possible danger that might exploit a vulnerability to breach security and therefore cause possible harm. A threat can be either "intentional" (i.e. hacking: an individual or a criminal organization) or "accidental" (e.g. the possibility of a computer malfunctioning, or the possibility of a natural disaster such as an earthquake, a fire, or a tornado) or otherwise a circumstance, capability, action, or event. A vulnerability is a weakness which can be exploited by a threatening actor, such as an attacker, to perform unauthorized actions within a computer system.

Exposure

To exploit a vulnerability, an attacker must have at least one applicable tool or technique that can connect to a system weakness. In this frame, vulnerability is also known as the attack surface or exposure. However, in most cases TVA exposure does not get much attention. When evaluated, exposure is usually estimated in a high-mid-low manner and then combined with ‘severity’ in a heatmap. The recommended way to minimize exposure is often to either patch a system to remove the vulnerability or move a vulnerable system into a separate network to hide it from an attacker.

While the increasing human casualties in Bangladesh is mainly due to the rising population, the increasing number of hacks is (also) due to the increasing amount of assets. Assets, in this context, can be hardware, applications, platforms and data. The more you have, the higher your exposure.

Although it is common to believe that ‘what you don’t own you don’t have to protect’, organizations do not seem to prioritize the inventory of assets. When performing a very basic assessment of the security status of an organization, I prefer to use the CIS security controls as a baseline. The CIS identifies 6 basic controls. The top three are:

  1. Inventory and Control of Hardware Assets
  2. Inventory and Control of Software Assets
  3. Continuous Vulnerability Management

The top two are about being aware of what you own, including software and hardware. In my experience, most of the organizations have no complete overview. In fact, it is often far from complete. Basic questions regarding purpose and function remain unanswered. The common reason being that the organizations find it ‘impossible’ to keep track of so many different assets. If that is the case, the organizations can’t manage the vulnerabilities in the various assets - and it’s safe to assume there are many vulnerabilities present. A high number of vulnerabilities and a large exposure equate a big risk.

One way to mitigate this risk is to try and manage the vulnerabilities. Organizations implement a vulnerability scanner. This will automate the inventory of vulnerabilities, but fixing the detected vulnerabilities requires manual effort. It is not uncommon to find multiple vulnerabilities on one server, and when scanning only a few hundred IP-addresses you can easily end up with an excessively lengthy report. The scanner is not able to detect and repot old or uncommon assets, monitoring network traffic is difficult. Of course, it is possible to sniff the network, but if you rely on artificial intelligence to discern genuine traffic from malicious traffic, it will be quite a naïve mistake.

It may not be feasible in Bangladesh to diminish the exposure by moving people out of the Ganges Delta, but in IT we can. If we want to decrease the risk, the best way is to remove of as many assets from the hypothetical risk scenario. This will decrease the exposure and decrease the effort needed to perform vulnerability management. The best security investment you can make might be to get rid of your legacy applications.

How to convince your environment?

I know from experience removing legacy is not a sexy subject. Of course no-one will really object against cleaning up. Who wants to be against that? However, removing legacy usually requires replacing one or more old applications with a new up-to-date one. This can be very costly and it may have impact on the way of working employees are used to. When faced with the decision to either implement a new application or a project to clean up legacy, the latter will be second choice.

One way to create some urgency is to make the risk visible. A breach in a legacy application may lead to severe damage. We recommend that organizations perform a quantitative risk analysis on the legacy systems and then calculate the risk. It is important to remember that this initiative will likely save significant capital in the long-term.

Monday, July 1, 2019

Quantitative Risk Analysis



IT security essentially reduces information related risk to an acceptable ratio of risk to cost. For this reason, the process begins with an extensive risk assessment – a tried and tested process that can be improved. I am inspired by the work of Douglas Hubbard on this topic. Here’s why.

Traditional risk analysis starts by creating a list of things that could go wrong. We estimate the maximum impact as well as probability and we multiply these figures to “calculate” the risk.

In some cases, this works reasonably well. The (financial) risk of a laptop being stolen from a parked car can be estimated like this. When a company owns a few thousand laptops it will happen several times per year. After a few years the number becomes predictable. The value of a laptop is harder to estimate. During presentations, when I ask the value of a laptop I’m holding up, the response of the audience is usually in the range of the list price of the laptop. After I tell them it holds the only copy of a research project someone has been working on for six weeks, the estimates inevitably rise. The estimates might increase further once we know that the laptop has shareholder information or a customer database saved on its hard drive.

Not all laptops will contain this kind of valuable information. However, these variables are often not adequately addressed in traditional IT risk management. The standard risk calculation is as follows: estimation laptop is stolen is 2% (per year), estimation laptops containing valuable information is 50%, probability of risk is 2% x 50%=1% (per year).

Even for such a simple risk calculation, the analysis is elusively complex. Risks with a very high impact and a low probability are even more elusive. What if your company is put on some blacklist and your cloud-based system, including all your data, becomes unavailable because the provider is not allowed to do business with you anymore? Not a very likely scenario, I admit, but what if this provider was hacked or goes bankrupt? This scenario is perhaps more probably. Worst case you lose all your data, but again this is not very likely. In traditional risk analyses the risk will be calculated using maximum impact:

risk = (almost zero) x (ridiculous amount of money) = nonsense.

Reality is not black and white. The impact of an unwanted event is not zero or maximum damage. Fire in the datacentre is usually very local, because of a failing power supply. A datacentre burning down to the ground is not very common. The damage in any incident will most likely be in the range of tens of thousands of euro’s, the maximum damage will be a number of millions. The fact that damage is probably a lot lower in most cases is completely ignored with this method.

One may argue, for absolute values the traditional methods are not ideal, but at least it’s one strategy to use when prioritizing risk.

In traditional risk analysis risks are categorized in levels of impact (Negligible, minor, moderate, …) and levels of likelihood (improbable, seldom, occasional, …). A matrix is created where all the identified risks are plotted. Usually it is color-coded to categorize high impact and high probability (red), low impact and low probability (green) and everything in between (gradients). It’s often called a heatmap.

Graph source: https://www.sketchbubble.com/en/presentation-risk-heatmap.html 
Hubbard gives a few examples in his book. For this example, the category “seldom” is defined as >1%-25% and category “catastrophic” as >10 Million like in the heatmap example above. Let’s assume we identified two risks:

risk A: likelihood is 2%, impact in 10 Million
risk B: likelihood is 20%, impact is 100 Million

When we calculate the risk as likelihood x impact, risk B is 100 times risk A. They would however be plotted in the same cell of the matrix. In the same way you could end up with risks which are very similar but end up in different cells.

A way to address the fact that there is variance in the impact of any event is to assume that the probability of any amount of damage will follow a normal distribution. A normal distribution is shown in the diagram below. The mean value will have the highest probability, very low and very high values will have a low probability, meaning that the bandwidth will vary. In the diagram below the blue line the mean value for blue, red and yellow lines is zero. The probability we are between -0.5 and 0.5 is much higher with the blue line than with the yellow line.

Graph source: https://en.wikipedia.org/wiki/Normal_distribution#/media/File:Normal_Distribution_PDF.svg
Applied to the stolen laptop example the risk can now be defined as:

Risk = (2% chance per year a laptop is stolen) x 
(90% probability the impact is between 1000 and 25000 euro)

A giant data leak may occur resulting in millions of damages when a single laptop is stolen, the probability however is very low (less than 5%, probably lower).

Note we now define the risk as a change or probability of damage instead of an absolute amount of money. In my opinion, this models the real world, where we can predict the course of the impact of events happening, but we cannot predict the impact of individual events. People who play the lottery will “win” about half of the money they pay for their tickets, but the chance of someone winning the jackpot is miniscule.

Tuesday, March 26, 2019

Yes!


The Chief Information Security Officer is often seen as the spoil sport who always says that the music is turned up too loud. That is unfortunate, mostly because it’s not even up to the CISO to decide on the volume.

Security controls are one way of reducing risks. This is notion that is rarely, if ever, negated. People will understand the necessity of taking measures to reduce their risk. People will look left and right before crossing the street without complaint. However, when it comes to information there are often debates about identifying and defining risks. My risks, might not be your risk and vice versa. Taking measures for someone else’s risks is perceived as annoying. To be a successful CISO one needs to help the people involved to help them understand their risk. 

First example: Shared network
Within one department of an organization the priority may be keeping the network as secure as possible; within another department where changes are quickly implemented, the priority may lie in keeping the network as flexible as possible. These are opposing interests because network changes can lead to greater risk of critical mistakes being made and downtime occurring. 

In this scenario, it isn’t the CISO deciding who must make concessions – it’s management. The CISO facilitates the decision -making process by ensuring that everyone understands the consequences, but it is not the CISO’s responsibility to go with option A or option B. 

Second example: project details in the cloud
A group within the organization asks if project management can use a cloud application. The standard application that the organization normally uses is not appropriate for the current project because it cannot be shared with third parties. The CISO receives the question after the application has already been purchased, which results in disagreement between the head of IT who opposes the use of “shadow IT”. 

In this scenario, the CISO will not be the individual making the choice about the proposed use of a cloud application. Rather, a decision will be made depending upon the project being carried out, which will need to be legally compliant (think of privacy) and appropriate in relation to other organizational departments. 

Additionally, project management must be aware that they are responsible for keeping all information that is placed on the cloud secure. The CISO provides advice and poses questions such as: Who has access and who manages that access? What happens if the cloud provider faces financial liquidation? If there is a risk that all information can be lost, but the project management recognizes and accepts that risk, then the decision should not be contested by the CISO.  

A third example: Can I take my laptop with me to China? 
An employee travels to China on a business trip. Due to the threat of espionage and confidential company information being leaked, the company policy dictates that special laptops (without vulnerable information saved on them) must be used during international travel. But at the moment this employee needs to travel, there are no such laptops available for use. The employee wants to solve this impasse by using his personal laptop. The question is whether or not the CISO will allow it. 

Again, the CISO will not make the ultimate decision about this. Project management is responsible for protecting the data confidentiality of all employees. Therefore, the CISO will ask questions like: What kind of data have you worked with on this laptop? How sensitive are they? The CISO will also explain the limits of the laptop security: the disk is encrypted, but if a national agency takes possession of the laptop, it will still be possible to extract information and even read erased files. Everything is allowed by the CISO, as long as the organization understands the consequences. In the end, this employee decided not to take the laptop with him.

Based on these three examples, it seems that the following conclusions can be made: 1) the CISO must know the organization well, and therefore know what the most pressing risks are 2) a Security Organization capable of assessing the risks and making decisions must be established. The Directors are responsible for ensuring that these conditions are met. The ISO 27001 ‘Information technology, security techniques, management system for information security Requirements' describes this in section 5.1b: Top management  must ensure that the requirements of the information security management system are integrated into the processes of the organization. Security is a matter for the directors, management, and everyone in between. 

The CISO simply advises.