Originally posted to Peerlyst, 29 March 2020.
Implementing containerisation provides the sense of ease, these short-lived environments minimise possible compromise – right? Unfortunately, that’s simply not a valid argument for missing vital security hardening and validation. Whilst a containermay be short lived, the base image is being reused multiple times and could create an environment, when not regularly tested, where multiple instances are vulnerable to a variety of threats.
When I first went to university, I wanted to be a Botanist. As you may have guessed, some of these classes covered the history and classification of plants. One of these plants discussed were Bananas. Whilst over 1,000 varieties exist, the majority of banana exports are from a single variety, Cavendish. Unless discussing bananas from the 60’s, Cavendish are the ones you imagine when thinking of the bananas we eat; but have you ever noticed the lack of seeds? This is, because these bananas are genetic clones.
Just like the Cavendish banana, containers are built from a base image, and replicated upon need. Whilst we aren’t concerned with biometric diseases in our containers, we are concerned with base images being vulnerable at run time, and therefore all clones vulnerable as well.
Where is the proper place for security within an organisation’s container strategy? It’s from the conception of the idea, throughout the life cycle, and upon release into production. It’s a part of every aspect in order to ensure that by design and by default security practices are embedded.
How can organisations ensure they cover this holistic security programme?
DevSecOps is a term most often applied to programming teams. However, it could also be viewed with a larger scope, to encompass persons who are developing the environment that systems and services run within. Be this the cloud expert selecting and complementing solutions, along with the programmer who’s building the application, not to forget the data scientist who’s building the algorithms that assess the information fed in.
Throughout this lifecycle, and as a part of each team members responsibilities is validating security best practice is being followed. The variety of skills and points of view will enhance the security posture, even from those who have minimal security focused experience.
During the container’s lifecycle, the container will transition between the development, testing, and lastly, go-live into production environment. Each phase has specific reasons, restrictions, and validation processes for them:
Development – not-so-minimal instances, but still following the secure coding standard, build and functional tests to create something brill. Still applying the validation lifecycle here, even if testing phase is next. If working with Kubernetes, StackRox wrote this blog called 12 Kubernetes configuration best practices which is a great article to guide you through configuration best practices.
Testing – as close to production as possible, whilst completing unit/functional/stress testing, have a robust final review of validation, plus holistic view of # of vulns identified, level of criticality, explicit risk appetite statement and detailed guidelines on go/no-go criteria.
Production – this should be actively scanned, and testing still happens but more passive testing on highly critical systems (their mirrors are continuously tested and offensive external validation is done in the testing environment).
Active monitoring of containers within the production environment
Setting your production environment up for success is starting with a resilient base image, which has been validated throughout the entire lifecycle and build in a highly restricted manner. The final environment a container is held within is production, whilst it’s at the end, it doesn’t mean we’re done with security validation.
Organisations looking to provide a holistic security programme will continue the validation through production by:
Running internal and external vulnerability scanners,
Maintaining the documentation,
Implementing intelligence provided by the threat intelligence feeds,
Keeping risks identified within the organisation’s risk register, and noting compensating controls,
Any exceptions required should be documented and an automatic reminder should be set for expiry of exception and review required.
Not only is it important the above features are a part of the programme, however, it is also vital organisations validate the integrity of the tools and resources they use as well. Consider a few years ago, Scott Helme found government sites running a crypto miner due to compromised third party which provided these scripts.
Interested in further insight into the holistic lifecycle of containerisation security? I’d recommend you take a look these articles:
Effective Container Security Requires a Holistic View - Tony Bradley
Container Image Security: Beyond Vulnerability Scanning - Karen Bruner.
How to secure the container lifecycle - TechBeacon
Just like the Cardavish banana plants are vulnerable across the entire crop, base images are reused for each transaction, and if not designed with security by design with a holistic security programme the attack surface isn’t reduced its replicated.