When the term DevOps was first introduced in 2009, many agree that it led to a major shift in the way we looked at the software development lifecycle. Of course, in many ways, DevOps was just a label for something that had already existed i.e. teams had worked together productively for many decades prior to this new categorisation and didn’t need a fancy name for any new workplace methodology. But the wider impact of this new concept was (and still is) undeniable.
Being slightly more introspective and thinking about where the notion of DevOps came from, we know that major enterprise IT vendors (IBM being the prime example) had long been championing systematic software development with a view to avoiding any the ‘application gets thrown over the wall’ to operations scenarios that have long dogged teams who wanted to work more effectively. Perhaps all it really needed was a new name.
Portmanteau-powered
Regardless then, DevOps was lauded as the new portmanteau-powered means of unifying developer (Dev) and operations (Ops) teams… and the rest is history. Or is it?
Ryan Sheldrake, field CTO at data-driven cloud-native application protection platform (CNAPP) company Lacework reminds us that DevOps encouraged cross-pollination of skill sets. Teams started deploying software and innovating faster than ever before. However, he suggests, amidst all the excitement, a critical aspect was overlooked: security… so could the answer be a further and more intelligent cross-pollination?
Security wasn’t a topic of conversation until it became a much more substantial problem several years after the initial idea of DevOps. Part of the problem may have come down to the fact that the teams developing infrastructure and moving quickly didn’t have the time to think about securing everything they built.
“Some people say that you never truly master security — and I agree,” enthused Sheldrake. “Keeping up with security while also trying to deliver software and infrastructure quickly is like servicing an aircraft while it’s flying. It’s difficult, risky and just a single mistake can have major consequences. So how do DevOps teams balance building quickly and securely? Do businesses need to hire platform engineers who are also security experts? Can they turn to IaC automation tools for help?”
Cross-pollination & collaboration
Speaking from experience drawn from its own customer base, the Lacework team suggest that the real answer (for many organisations) might be to re-evaluate the way we think about this whole situation. To find and keep people with the right skill sets, businesses need to change what they’re looking for. Very few pan-skillset super-professionals who are amazing at everything actually exist. The advice here is that firms should decide which three or four skills are most important for the individual to have and then the organisation needs to invest in collaboration cross-pollination.
“For example, one of the organisation’s security professionals could train a platform engineer and teach them security best practices, or a platform engineer could explain the essential development concepts and processes security teams need to know. It’s impossible to be an expert at everything and even if you are skilled in multiple areas, people learn and work in different ways. It’s all about learning from each other – investing in knowledge sharing and training each other within your organisation is the best solution to maximise your time and investments,” advised Sheldrake.
So is it all that simple? Well, we can still say that Infrastruture-as-Code (IaC) checking will remain a challenge because of how rapidly infrastructure can move and change. Every single commit can be either a minor or major infrastructure change and tracking those can be challenging.
“If you’re building 400 servers, that’s a lot of things to go and check. Avoiding mistakes isn’t just difficult, it’s nearly impossible. It’s never quite as beautiful as you designed it, because people make mistakes. Think about an architect — you want to check for mistakes as you’re building, but you also want to check on the final product that went live,” said Sheldrake.
He reminds us that monitoring the ongoing runtime environment is also essential to avoid increasing business risk. The scale and pace is massive. Third-party services give you a vastly bigger coverage area with quicker time to value. It’s not impossible for an in-house security expert to do it, but managing IaC is much easier with automation and tools.
Embrace multi-cloud
So then with all of the security tools available today, how do you know which one will best suit your needs?
“Most importantly, a business needs a platform that has maximum coverage across clouds. There are many nuances between Google Cloud, AWS, Microsoft Azure [other cloud service provider hyperscalers are also available, well, kind of] — and you want to have the ability to switch from cloud-to-cloud while also being protected. Using a platform that is multi-cloud is key,” said Sheldrake.
It’s clear that businesses also need a flexible solution. Customisable policies are essential because there is a certain context about any one cloud environment that a platform doesn’t know on its own. Basically this means high levels of compliance and security, with low levels of noise.
“Security needs to be incorporated in everything we do, but it doesn’t need to slow you down. This means changing our mindset and expectations, fostering an environment of skill cross-pollination and embracing the power of IaC automation. While no one can be an expert at everything, diverse teams and automation tools can help teams manage security while still moving quickly. The right IaC automation platform offers multi-cloud coverage, customisation and provides high compliance with low noise,” advised Sheldrake.
It is perhaps no surprise to a cloud-native application protection platform specialist advocating a more secure approach to cloud-native application protection in DevOps environments, at the platform level no less. But even so, the focus on DevOps overall is arguably more aligned towards productivity, deployment and doing rather than the need to establish firm foundations, even if security is not actually eschewed in any way.
Free image use (above) Wikimedia Commons.
1 day ago
