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.
 100vw, 284px”><figcaption>Brian Trzupek is SVP of Emerging Markets at DigiCert</figcaption></figure>
</div>
<p>IoT devices do none of these things. A device is typically manufactured and provisioned an identity that will generally last for the entire duration of that device. However, the software on that device may change quickly and frequently throughout the lifetime of the device. Another key difference between IoT and enterprise identity and authentication is that, in IoT environments, devices may be only rarely connected to the network. That means they may not be able to get updates, or, in some cases, may not even be able to support standard revocation models. These key differences mean you need a way to ensure every device’s authenticity and integrity.</p>
<h2>What’s needed for effective IoT security?</h2>
<p>A few fundamentals are needed to secure IoT environments.</p>
<h3>Robust device security</h3>
<p>First, you need a cryptographically strong device identity. This is commonly called the device “birth certificate.” A device certificate creates an identity for each “thing” in an IoT ecosystem, making sure each device authenticates as it connects, and protects communication between devices.</p>
<h3>IoT supply chain security</h3>
<p>Manufacturers need a way to track and ensure their devices’ content to respond effectively to future vulnerabilities or compromises. Not knowing what is on your devices, such as libraries, software, chips, open-source, is the easiest way to get compromised.</p>
<h3>Ability to disable a device</h3>
<p>If the device is connected to the network and using Public Key Infrastructure (PKI), revocation of the certificate is a very effective way to disable its ability to bad things. However, if you do not have a means of using revocation with a device, but it is communicating back to a service the manufacturer controls, then the device identity can be used to gate access to backend services and have the effect of quarantining and identifying a troublesome device. If you are not the manufacturer and have a compromised device, then network segmentation and egress monitoring allow you to control the device.</p>
<h3>Ability to update a device</h3>
<p>However, many devices are connected in a way that they can be updated. It’s essential to ensure that a secure update mechanism is designed in from the start—and that the integrity of the update can be confirmed before the update takes place.</p>
<p>It’s also important to be able to build in the ability to respond to unauthenticated access and recovery. Some organizations create update procedures that coordinate closely with routine device maintenance, or any other occasion that a certified employee visits the device. In these cases, using cryptographically secure authentication to the device through PKI will allow the qualified worker to gain proper access and perform necessary duties. This needs to be designed in from the start. It is also important to remember that in some cases, a device may not be updatable, and will require its own specific deployment policies and practices.</p>
<h3>Service side authentication</h3>
<p>IoT devices should all use strong authentication when communicating with their services. Unauthorized devices should be identified and dealt with per your policy.</p>
<h3>Remediation plan</h3>
<p>Despite your best efforts, you may need to respond to breaches. Consider how you will identify compromised devices or spot vulnerabilities in the software used in your device. Once you have developed a plan to discover these issues, you can determine how you will respond to correct the issue or quarantine the device. Developing a well thought out remediation plan in advance will greatly help you when the time comes to respond to an issue.</p>
<h2>PKI delivers for IoT security</h2>
<p>PKI is uniquely positioned to deliver on essential, distinct security needs of the IoT. It’s market-ready, widely adopted, and provides the flexibility and interoperability organizations need to support a wide range of IoT applications.</p>
<p>According to the Institute of Electrical and Electronics Engineers, “When you’re looking at authenticating devices, the only real standards at the moment that offer any real interoperability tend to be Public Key Infrastructure (PKI).”</p>
<p>It’s clear that PKI delivers the essential authentication and encryption components needed by the IoT for data security, making it a proven solution and market-ready platform for IoT device security today. With a strong PKI platform from a leading global provider, modern PKI that fits the large scale and flexible deployment models of the IoT is effective and ready to use.<a name=){kind=spacer}