Secure or Compliant? That is the question!

Compliance means conforming to a rule, such as a specification, policy, standard, or law. Regulatory compliance describes the goal that organizations aspire to achieve in their efforts to ensure that they are aware of and take steps to comply with relevant laws, policies, and regulations. (source: Regulatory compliance)

Within many organizations, compliance is a commonly used word. The commonly used phrase related to tools, documents, or actions, in general, is “Be careful; it should be compliant.” But the question that should always be asked afterward is, “Why? What rule do we want to adhere to?”

As stated above, there is a definition for compliance, and that is quite clear, but there is a big risk where the implementation of controls to be compliant becomes the goal and not the means to an end. Let me explain by a simple example.

Imagine there are 2 villages. Both are on the other side of the river. The river is full of piranhas, and crocodiles, and people cannot swim and do not have boats. The city council writes up a rule that trade is allowed, but only if people are not harmed by doing so.

A few wise men come together and come up with a plan. They will create a simple bridge. They pull up a long pole on both sides of the river and span 2 ropes between them. People can cross over, by walking the rope. This goes well for a while, but then, an unfortunate accident happened. The rope breaks, and a person falls into the river. After a long meeting, the decision is made to build a safer wooden bridge. 1 year later, a big storm hits the village. A tree falls on the bridge, and the bridge breaks. The bridge was assumed to be firm enough to withstand these things. A stone bridge is created to make sure this never happens again. After many months of hard labor and some big investments, the bridge is ready, and everyone is happy and feels safe. Unfortunately, this feeling is short-lived. Within the same year, a disturbed individual drilled a hole in the bridge, and some people fell into the river, not noticing the gap. After this incident, full-time security is established on the bridge to prevent criminals from entering the bridge. At the same time, a council is formed to think about how this bridge can be made even better. Are the right materials used, can it hold more people, and can we secure it better against criminals?

A few years go by. A merchant comes into town. He wants to cross the bridge to trade. He is not allowed to do so because he is not on the list of people that are allowed to enter the bridge. To get on the list, he needs to supply information to make sure he’s not too heavy, carries illegal tools, or has bad intentions. The visitor is amazed and frustrated. He walks down the river, inflates his rubber boat, and peddles across. A member of the council awaits the visitor at the river bank. He insists that the visitor turns around because the bridge must be used when crossing the river when you want to trade.

What does this story tell us? First, the goal was lost out of sight. The goal was to trade with another village across the river. The bridge was merely an implementation to achieve this goal. But when the rope bridge broke down, a new and improved bridge was created. The same happened with the stone bridge and the security. A secure bridge became the goal. And other solutions to achieve the goal were not seen. The boat is also a great solution, but nobody thought about a boat. Except for someone who was blocked by the rules. So that tells us a second thing. No matter the controls you create, there is always a way around the controls. But if you look at the goals and the compliance rule, “No people should be harmed while trading with the other side,” the boat is perfectly fine.

Compliance within organizations is usually part of the same area as security and risk. There are quite many risks that should be covered. Organizations should be in control of these risks and be able to prove they are in control. That is compliance. But being compliant is not the goal. Being secure is. You don’t want to be in the news because you got hacked, employees ran away with millions, or personal client data got leaked. Compliance can help ask the right questions and focus on the right areas. But I truly believe that being compliant does not make you (more) secure. I even think that when an organization focuses too much on compliance, they risk getting less secure because the documents and procedures distract from the real implementation and only give a “secure feeling.” Both compliance and security are important. So how can we be compliant and secure at the same time?

Strip down to the bare minimum

As illustrated in the story, the biggest pitfall is that solutions and controls for a compliance rule, become the standard and the end goal. You can recognize this by questions like; How did you implement xyz? Or, is there a document describing abc? You should always know what you are covering. And sure, there are best practices and reusable components, but you should always answer “the why question” and reconsider the chosen solution.

When looking at the main concern or risks we have to deal with, it comes down to the CIA Triad. And this is exactly where most of the Information Security Controls are targeted at [source: The CIA Triad]

These are the things that need to be covered. Auditors will check for gaps and holes to ensure you can prove that the measures you took are indeed covering the gaps. But auditors will only check this 1 or 2 times a year and will most probably not be equipped to dive into the bits and bytes. In many cases, there will be a stack of documents describing the procedures and controls that have been implemented to cover the risks from the triad

In real life, this means, that when an audit is announced, all documents are checked, information is gathered, and systems are validated, so the state of the system is “secure,” but at any other moment in time, there is no proof at all that the system implements all the controls. When the question” Are we compliant?” is asked, the answer is yes in most cases. But if we strip it down to the bare essentials, we should ask the question. “With 3 deployments per week, are all risks covered, and are we in control when something happens now or at any given time?” The first question is about being compliant, the second is about being secure. The answer to the first question is, in many cases, Yes; the answer to the second question is “No,” “Sometimes,” or “I don’t know.”

DevSecOps – using DevOps to be secure and compliant

With the move to DevOps and Continuous Delivery, where deployments happen multiple times per day, it is even more important to be in control of the process. When InfoSec is outnumbered without automation and integrating information security into the daily work of Dev and Ops, InfoSec can only do compliance checking, which is the opposite of security engineering (source: The DevOps Handbook – Gene Kim – page 313).

With this in mind, it is important to make an effort to enable teams to integrate security into their process and pipelines.

Afbeelding3-1200x153

In terms of compliance, it all boils down to being able to show that code that has been produced is traceable (audit trail), reviewed (4-eyes), and that the artifact that has been published to production is unchanged from the code it originated from. (integrity). Does this make the code secure? Maybe, but not all aspects are covered. To do that, you need to implement other things.

If we keep in mind that we want to write and deploy secure software, we should enable teams to do that. Ensure that code is reviewed, scan for vulnerabilities, check code for common errors, create immutable artifacts, use standard approved libraries, test your code and applications, monitor for anomalies, etc. It is all needed to create secure and reliable software.

By focusing on security within the development and deployment process, the need for information shifts from the auditor to the teams themselves. To debug a problem in production, sufficient logging is needed. To ensure the same version is deployed to test and production, scripts need to be in place, and to get a notification when a problem occurs, sufficient monitoring need to be implemented. When the need is within the team itself, the is a different prioritization, and the result is that the teams more or less become compliant automatically. By implementing the security and the necessary countermeasures, the required controls to be compliant will be automatically fulfilled. And the best part, if it is that it is verified continuously by an automated pipeline, and evidence can be pulled from the system at any time.

So, in short. Focus on secure systems instead of compliant systems. If you are secure, you most probably are compliant as well.

Reading List

There are a lot of very interesting articles,blogs, videos, and books that describe this different view on compliance and security, which I recommend to anyone!

Secure or Compliant? That is the question!

Strip down to the bare minimum

DevSecOps – using DevOps to be secure and compliant

Reading List

Explore more articles