If you work within the security industry, compliance is seen almost as a dirty word. You have likely run into situations like that which @Nemesis09 describes below. Here, we see it’s all too common for organizations to treat testing compliance as a checkbox exercise and to thereby view compliance in a way that goes against its entire purpose.
There are challenges when it comes to compliance, for sure. Organizations need to figure out whether to shape their efforts to the letter of an existing law or to base their activities in the spirit of a “law” that best suits their security needs—even if that law doesn’t exists. There’s also the assumption that a company can acquire ‘good enough’ security by implementing a checkbox exercise, never mind the confusion explained by @Nemesis09.
Podcast Episode 141: Massive Data Breaches Just Keep Happening. We Talk about Why.
However, there is truth behind why security compliance continues forward. It’s a bloody good way to focus efforts in the complex world of security. Compliance requirements are also using terms that senior leadership understand with risk-based validation of which cyber security teams can make use.
Security is ever-changing. One day, you have everything patched and ready. The next, a major security vulnerability is publicized, and you rush to implement the appropriate updates. It’s only then that you realise that those fixes break something else in your environment.
Opinion: The Perils and Promise of the Data Decade
Containers Challenge Compliance
Knowing where to begin your compliance efforts and where to focus investment in order to mature your compliance program is stressful and hard to do. Now, add to that the speed and complexity of container-isation and three compliance challenges come to mind:
- Short life spans – Containers tend to not last too long. They spin up and down over days, hours, even minutes. (By comparison, traditional IT assets like servers and laptops usually remain live for months or years.) Such dynamism makes container visibility constantly evolving and hard to pinpoint. The environment might be in flux, but organizations need to make sure that it always aligns with its compliance requirements regardless of what’s live at the moment.
- Testing records – The last thing organizations want to do is walk into an audit without any evidence of the testing they’ve implemented on their container environments. These tests provide crucial evidence into the controls that organizations have incorporated into their container compliance strategies. With documented tests, organizations can help their audits to run more smoothly without needing to try to remember what they did weeks or months ago.
- Integrity of containers– Consider the speed of a container’s lifecycle, as discussed above. You need to carefully monitor your containers and practice highly restricted deployment. Otherwise, you won’t be able to tell if an unauthorized or unexpected action occurred in your environment. Such unanticipated occurrences could be warning signs of a security incident.
Building a Container Security Program
One of the most popular certifications I deal with is ISO/IEC 27001, in which security is broken down into areas within the Information Security Management System. This logical separation allows for different areas of the business to address their security requirements while maintaining a holistic lens.
Let’s look at the first challenge identified above: short container life spans. Organizations can address this obstacle by building their environments in a standardized way: hardening it with appropriate measures and continuously validating it through build-time and (importantly) run-time. This means having systems in place to actively monitor actions that these containers make, interactions between systems and running services along with alerts that are in place for unexpected transactions.
Now for the second challenge above. In order to have resilient containers in production, an organisation has to have a proper validation/testing phase done prior to launch. In almost every program I have been a part of, when rolling out new features or services, there is always a guide on “Go/No Go” requirements. This includes things like which tests can fail gracefully, which types of errors are allowed and which tests are considered a “no go” because they can cause an incident or the transaction cannot be completed. In a container-ised environment, such requirements could take the form of bandwidth or latency requirements within your network. These elements, among others, could shape the conditions for when and to what extent your organization is capable of running a test.
In addressing the third challenge, the integrity of containers, we face a major compliance issue. Your organization therefore needs to ask itself the following questions?
- Have we ever conducted a stress test of our containers’ integrity before?
- Has our environment ever had a table-top exercise done with the scenario of a container gone rouge?
- Has a red team exercise ever been launched with the sole purpose of distrusting or attacking the integrity of said containers?
Understand the Value of Compliance
In this article, the author discusses the best practices and known risks associated with Docker. It covers the expected foundations that you must align with in order to reduce the likelihood of a configuration causing an incident within your containerized infrastructure.
No environment is perfect, and no solution is 100% secure. That being said, the value of compliance when it comes to container-isation security programs is to validate that these processes so that they can help to reduce the likelihood of an incident, quickly identify the occurrence of events and minimize the potential impact to the overall environment.
Whilst compliance is often seen as a dirty word, it can be leveraged to enhance to overall program through a holistic lens, becoming something richer and attractive to all parties.