My first interaction with containerisation in a development lifecycle was with Docker when it was still relatively new; I was asked to learn it and identify ways it could be used within the software development company I worked for at the time. Virtualisation wasn’t a new topic by then, but the idea of having temporary boxes that came up to do a task then were killed, was bloody interesting. I loved the easy to understand documentation, and the ability to manage it all from the command line. It was fast, consistent, and at the time I felt less anxiety because the containers were very short lived, and I was able to build the golden image in a way I felt safe to use. However, notably, I was given the time to learn the tool, test it, and validate.
In a survey created by StackRox, with more than 540 IT professionals responding, it was revealed that majority of persons (94%) experienced a security incident in the last 12 months. What’s more, 69% of respondents had stated misconfigurations detected in the last 12 months. Going back to my initial experience with Docker from 2015, I found the love of this deployment starting with ability to create a golden image prior to deployment. How does this line up then?
Over the years what I have learned is, when a company is exploring a new technology the initial team asked to do this are not always aligned with the required skills. This is understandable, considering it’s often a new technology, and they’re exploring it for the first time.
The other challenge isn’t a new one – these teams are often not as robust in skills as we would hope. I am not in any way trying to say they aren’t good techs, they often are excellent, however it requires a vast array of skills and to be used in new ways than they are used it. Hiring in your own image is a known issue, which creates a skills gap and lack of diverse teams. The result? That golden image isn’t addressing all the needs, including security risks, that it should. This takes us to the situation where the fast paced environment of containerisation to almost half (44%) being delayed due to security concerns.
All too often the fast moving innovation teams of the company have to put in further investment into security review, controls, and validation because the rest of the company hasn’t caught up. That investment rarely is effectively identified – it’s hard to know what you don’t know – and ultimately things are missed.
Working with software development teams, and speaking at developer conferences on security and ethics – what I have learned is the first challenge they will run into is understanding where to start. Following a talk I had given, an audience member came to discuss their response to my talk, they thanked me for the topic and said: “my problem is two-fold. I want to get my devs aware of their role in security, to create a sense of responsibility, but also I struggle with gaining senior leadership support and their investment in training.” Another contact told me “...in college, I was never taught how to embed security into the lifecycle, just how to be agile.”
Does it take more time to do things securely?
Short answer: no. Long answer, when done properly with the appropriate persons and skills being used – security by design can be just as agile.
Yes, implementing security with unskilled persons or even skilled but too late in the life cycle can easily take longer. Just the other day a programme I was assessing said ‘ok let’s go live now, you’ve not found anything bad’ and my team had to step in and say actually, we’ve identified quite a few areas of concern. How did it happen? I’m viewing the holistic programme with a security focused eye, whereas theirs was usability focused.
Security by design and by default doesn’t have to slow you down – it only happens when the team isn’t properly supported in security training, doesn’t have the diversity in skills and points of view, along with situations where they simply isn’t aware of the risks.
To be completely clear third party automation, containerisation, cloud infrastructure – none of these are built to ease your security needs. Most offerings work under a shared responsibility model, they provide the capability to run scalable solutions, but they do not provide security protections. A great description comes from Portshift “Kubernetes is designed first and foremost for orchestration, not security. The biggest challenge in securing Kubernetes is the microservice architecture itself. Every deployed container creates a new point of entry for attackers, thereby increasing your attack surface. Since Kubernetes automates most container management tasks, this turns security into a constantly moving target that can only be effectively addressed with automation.”
As noted previously, “44% of organizations have delayed deploying apps into production due to security concerns, mitigating the greatest benefit of containerization – agility” this statement goes to the core of my concern with businesses requiring team members to quickly upskill, take up responsibilities by unskilled or minimally skilled team member (in that area), or even apply their on-premises experience within a cloud deployment. It’s unfair, and essentially setting them up to fail.
How can an organisation fully realise the benefit of containerisation/Kubernetes/microservices in a secure manner?
You have to provide training, effectively scope the programme, and do a proper skills gap analysis – in order to verify the persons architecting and deploying, along with maintaining, the solutions are qualified to do this.
Proper functional and non-functional requirements gathering. This includes what is the threat landscape, what are the risks, how is the attack surface changing? Prior to beginning a transformation programme.
Effective teams, which means skills gap analysis – and using this to build a road map for training. Create a culture where if someone isn’t confident in their ability, they can flag they need training from the start – inclusive environments are safe to say I am not sure, let’s investigate.
Having proper documentation, this includes the requirements, overall architecture, and standard operating procedures for things.
Robust validation lifecycles, including penetration testing, secure development life cycles, peer review, code review, and more.
Want to know more? This highly detailed post by StackRox, they take a focused view on how to secure your Kubernetes solution.
Agile doesn’t mean sloppy, and it doesn’t mean forgetting massive parts of what make business projects successful. Ultimately it is the deployment team’s responsibility to ensure that programme, along with any related infrastructure are effectively protected and secured. If that means, whilst out of scope the remote users require VPN access for example, then it’s up to the business to decide on if that’s worth the investment or consider alternative solutions. To effectively identify these security risks, from the start, and reliably embed security by design into Kubernetes or any solution teams must be supported, trained, and diverse.