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, polices, and regulations. (source: https://en.wikipedia.org/wiki/Regulatory_compliance)

Within many organizations, compliance is a commonly used word .Related to tools, documents or actions in general the commonly used phrase is “Be careful, it should be compliant”. But the question that should always be asked afterwards 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 become the goal and not the means to an end. Let me explain by a simple example.

Imagine there are 2 villages. Both on the other side of the river. The river is full of piranhas, 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.

rope

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 in 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 down 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 drills a hole in the

bridge and some people fall in 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, 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 in 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 a great solution as well, 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 should be able to prove that 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. Being compliant can help in asking the right questions and focusing 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 run the risk of 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 with 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: https://www.linkedin.com/pulse/cia-triad-jubran-alloghbi/]

These are basically 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 in to 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, 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 really implements all the controls. When the question:” Are we compliant?” is asked, the answer is most cases yes. But if we strip it down to the bare essentials, we should ask the question. “With 3 deployment 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 “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 in their process and pipelines.

pipeline

In terms of compliancy 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. Making sure that code is reviewed, scanning for vulnerabilities, checking 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. In order to debug a problem in production, sufficient logging is needed. In order to ensure the same version is deployed to test and production, scripts need to be in place and in order 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 end result is that the teams more or less become compliant automatically. By implementing the security and the necessary counter measures, 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 article,blogs, videos and books that describe this different view on compliancy and security which I recommend to anyone!

Advertisements

No comments yet... Be the first to leave a reply!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: