Maksim Kabakou - Fotolia
Until relatively recently, security appliances were provided by their suppliers in physical blades that were installed on an organisation’s system. Today, this software is increasingly likely to be provided in containers.
At their core, containers are isolated collections of software, gathered together into a working package that can be configured and managed independently, both of other containers and the hardware on which they run. As well as being easily deployed on any virtual or physical server, the segregated nature of containers allows rapid development and ongoing maintenance because they can be moved from server to server dynamically without their operation being disrupted or software compatibility being an issue.
As with any emerging technology, containerisation introduces substantial opportunities for organisations to enhance the effectiveness and efficiency of their processes and activities.
At the same time, it doesn't come with “best practice” ways of ensuring it is secure, and as the technology itself and methods used to deploy it continue to evolve, the challenge is to determine the new risks it introduces and the resulting mitigation strategies that need to be implemented to ensure that the security posture of the enterprise is not compromised.
This is exacerbated by the “black box” nature of containers, in which only inputs and outputs are visible.
Despite the container concept being relatively new, some standard security practices are effective in managing the risks. As containers are only as secure as the software on which they are running, security assurance processes need to be engaged at the start of the development life cycle of the container and continued throughout. This includes assessments to ensure that none of the software libraries used house any known vulnerabilities and checks that access permissions within the container are appropriate and not running at elevated levels.
However, while it is relatively straightforward to use vulnerability management tools to assess whether a piece of software is secure, containers often consist of multiple technology stacks (from web servers, virtual machines and databases), and interconnected software installations. Rather than viewing security assessments on a container as a single vulnerability test, these need to be performed as they would on a new application so that all software components are checked.
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.
Read more from the Security Think Tank
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.
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.