Security Think Tank: Securing containers needn’t be taxing

Security by design

These assessments also need to be performed from day one of a project, which requires them to be built in at the design and requirements stage; the later in the process they are introduced, with this sometimes being at go-live or after production has started, the greater the likelihood of security flaws arising or causing unexpected business disruption.

For software being delivered by a third party, checks should focus on the developer, as part of the normal security supplier assessment process. They also need to look at the level of control that the organisation using the container will have and how this will operate; determining if the container requires full root permissions to run, or whether permissions can be controlled to restrict access to resources on the server, for example.

Zero trust policies

Treating containers like micro zero-trust environments is another viable approach to security. Restricting what they communicate with and authenticating and authorising all requests and commands reduces the amount of damage should compromised, or less than secure containers, be introduced into the organisation’s IT landscape.

Monitor and patch

Containers should be integrated with any existing monitoring processes to identify unexpected events or indicators of compromise. Ideally a baseline will be provided by a full list of expected behaviour and data flows established during development.

Because the nature of containers means it is not always possible to look at the traffic or logs within them, monitoring needs to focus on the interaction of the overall container with physical resources (such as servers and storage) and the data flows entering and exiting it.

Ensuring software is current (and therefore as secure as possible) requires containers to be included in change and patch management processes.

This is especially critical for any virtualisation software being used, as this is where criminals will often look for flaws to exploit other components running on it.

Off-the-shelf solutions

With the growth in the adoption of containers, software solutions that specifically monitor container security have also been developed. But before choosing this route, organisations need to evaluate the cost when weighed up for the volume of containers within their IT environment and critical processes, as well as take into consideration that the technology is still changing and adapting; relying solely on a single tool, even it is the most effective option now, might not meet long term goals. 

Efficiency enabled by security

Developers themselves provide the strongest defence when securing containers as they can instigate safeguards such as following well-known design practises and formulating containers with maintainability and security in mind. And in adopting security-by-design principles they can reduce the potential risk to the organisation by decreasing or eliminating the number of issues that need resolving once the container has gone live.

In addition, CISOs need to ensure proven secure software is selected for use within a container, code audits and vulnerability analysis are performed during development, and that all interfaces and data collection are mapped.

These steps will dramatically reduce the overheads required by the security function and enable the organisation to realise the full efficiency benefits offered by container technology.