Compliance is NOT Security

The Problem with Security and Compliance Mixture

When talking to customers or colleagues, I often see two distinct topics being conflated: Compliance and (IT-) Security. Some customers have requirements they say MUST be fulfilled. When asked what their goal with this requirement is, they cannot elaborate the intention. They often fall back into saying that they need this requirement to be enforced. 

To make it more relatable, I talked to a customer who required to have our solution integrated with a vulnerability scanner. I asked what information they wanted to gather, since it would not be useful to them if the integration would only cover parts they are not interested in. But they were unable to provide any additional context. Thus we ended up by saying that we would have ways to do the integration – but that it would only be useful if they knew what to do with the generated data.

This is a perfect example of a compliance requirement which does not increase security at all. It is also a perfect example of why security is sometimes not taken seriously. This may be due to lack of communication, skills or alignment. This may also be caused by lost context due to the necessary breakdown of complex requirements into checkable items. Security teams sometimes are also disconnected from the “real world”, because they don’t implement security measures but only create/govern the rules. For the other teams applying their rules does not become a task of increasing security, but of being compliant to their rules. Because security teams often have the power of NO. And just doing things to be compliant and not to ensure security makes the measures useless and burdensome in the eyes of people who have to comply with them. Security is seen as a burden and not as something that helps to reach the goals of service, platform or application teams.

So let’s take a step back and look into the basics.

What is Compliance

Compliance is an easy one. The Oxford Learner’s Dictionary defines it as “the practice of obeying rules or requests made by people in authority” (https://www.oxfordlearnersdictionaries.com/definition/english/compliance) .

While the word itself is quite easy to understand, it is much harder to be compliant. There are often a lot of laws (like GDPR [General Data Protection Regulation], copyright laws), frameworks (NIST, BSI Grundschutz, …) or internal rules (i.e. related to ethics, or company culture) which have to be included. All these frameworks provide a lot of rules, and some of the reasoning is not straightforward.

But compliance is also often associated with punishment. If you don’t follow the rules, there will be a punishment. If you fail to apply GDPR rules, a company can be forced to pay 4% of its yearly turnover or 20 Million Euro – whatever is higher (GDPR Art. 86 (4)).

In the reality of companies you are always subject to more than one regulation, which makes it challenging to know which requirements apply and also how to follow them, without professionals who do this as part of their job. Also these regulations may or may not affect IT. There are for example rules against tax evasion, which do not touch IT – if you don’t work in a bank. So compliance addresses a broader audience than just IT.

In the context of open source projects you might think: You don’t (necessarily) make money with this, and you are not a corporation and not subject to some (or all) of the mentioned regulations – and you might be right. On the contrary, you should think about who uses your project or how it can be usable for your community. Maybe some features (like being able to delete log files, remove data from log files) might be helpful for some of them. Or some usage data which you want to collect to improve your project might cause some problems for users of your software – or is subject to the GDPR. When searching for issues with the term “GDPR” on GitHub, you get 29.1k results (at the time of writing), which shows how many projects have to deal with this regulation.

Open source projects sometimes have additional rules they choose to follow. Like a Code of Conduct, or style guides which enable a higher readability of code. These are additional compliance rules, which they create themself to be successful as a community.

To make it clear: It’s a good thing to be compliant. And most if not all regulations have a good intent. It’s just that the reasoning to implement them is often: “otherwise I’ll get punished” and the original intent or motivation is lost, which might lead to implementations which do not support the original intent, but they might still have a positive impact.

What is IT Security

There are multiple definitions of IT Security. And essays on what IT Security is and what it is not. 

There are three most common underlying goals in IT Security (along with others like non-disputability). This is also known as the “CIA triad”.

1. Confidentiality (Don’t let information be accessed by entities which should not know this)
2. Integrity (Don’t let information be altered in uncontrolled ways)
3. Availability (Make information accessible to authorized parties when required)

The many goals defined by IT Security Teams mostly boil down to ensuring these three overarching goals. This is a differentiator to compliance, where the goals of a regulation might be completely different (like preventing tax evasion).

A well-known essay in this respect is Bruce Schneier, “The Process of Security”, in which he states that “Security is a process, not a product.” This shows another aspect on HOW to reach the CIA goals. You can’t sprinkle some HyperNextGenCloudAI2.0-Magic over your IT organizations infrastructure and be magically secure. You need to do a little bit more. To really increase security you have to evaluate which tools you use, how you use them and, most importantly, what your processes are around them.

A common good practice in IT Security is to reduce your attack surface and to reduce your trusted computing base. Some people say that this is the only possibility to even get more secure. 

Reducing your trusted computing base seems to be a weird statement if you are living in the cloud era. Because going to the cloud means increasing your trusted computing base with all of the cloud environment, over which you do not have real control. Often you do it, because you trust the cloud provider to be more competent and efficient in providing and securing that infrastructure. In the world of IT Security, you are still increasing your trusted computing base and thus offer a greater target than before – even if these risks might be better mitigated than before.

Reducing the attack surface means multiple things. First don’t expose ports (or services) to the outside that are not needed there. For example, you don’t want to expose the SSH service of your company servers on the internet. Secondly, use specialized software which only offers the functionality you need. When serving a static webpage, a static web server (SWS) (https://github.com/static-web-server/static-web-server, 6196 lines of code) might be just enough and nginx (https://github.com/nginx/nginx,  231218 lines of code) might be more than you need.

Lines of code (LoC) is a horrible metric, but for the sake of the argument, let’s just assume that both products are written with the same ratio of exploitable security bugs per LoC, just to make the point that under this assumption, for this use case (serving static websites) SWS would be the option with the lesser attack surface. There is more to reduce the attack surface, like ensuring proper roles and permissions by means of RBAC, configuring the software to a secure state, disabling unnecessary features, and so on.

As you can see from these examples, there are a lot of possibilities and choices to make if you want to do things securely and also different interests you have to keep in mind. That’s why you normally use something called risk.

What is Risk

You can describe risk in a qualitative way and in a quantitative way. When defining it qualitatively, risk analysts assess a solution, product or infrastructure and afterwards describe their judgment or perception.

If you want to use quantitative risk, often the formula used is THREAT x IMPACT x LIKELIHOOD. As you can see from the formula, if any of these factors decreases, the risk decreases. If they increase, the risk increases. The problem with these factors is that you have to quantify them before, and for this you have to make assumptions. But this shouldn’t be relevant for us here.

A THREAT is an action which can cause harm. This can be something an adversary does, but also something that you don’t do. The IMPACT describes what the negative result would be for you. This might be profit loss by a company, or downtime, reputation harm or other things. The LIKELIHOOD is the probability that such events will occur. As a handy example, if there is a remote exploitable bug, and it is not publicly known, the likelihood is lower – until it is publicized or exploits are discovered in the wild which will massively increase the likelihood.

Risk helps you focus on stuff that is important and helps you identify the actions which reduce your risk. And it helps you sort out where you do not want to invest your time. Because in a world full of threats, threat actors and regulation, you need something which helps you prioritize. Because you can never be 100% secure. But you should know how high the risk is that you bear. 

By the way: the high fines of GDPR result in a high IMPACT score in the quantitative risk assessment. This causes GDPR to be more strictly enforced, since the resulting risk score makes it a high priority.

A better way to do IT Security?

In my opinion, a solution to address the gap which results in security being conflated with compliance, and the lack of  understanding from each participant (either security or development/operation) is providing context. If ITSec defines a rule, it must be bundled with the rationale of why this is important and what they are trying to achieve. When development or operation teams understand that rationale, they might have better implementation ideas in order to achieve this goal. And this might help ITSec widen their understanding of the tools which are used and how to secure them. This requires talking to each other, trying to understand each other’s viewpoints, be open minded, and use risk as a guidance.

Conclusion

In this blog post I have provided you with an introduction to compliance, IT security and how they differ from each other. I have  also conveyed some information about qualitative and quantitative risks and why risk is a good method to manage your efforts in getting compliant and/or secure.