It can be easy to forget how sophisticated IT security tools are today. You might take for granted that we now have tools purpose-built for securing environments like containers and serverless, while in fact these types of IT security tools are very new.
Indeed, from the introduction of the first modern IT security tools up until the very recent past, the primary focus was on building bigger and better entrance and exit points to stop any bad actors at the edge. Like castles in medieval times, we built the best moats around our IT systems and really fancy drawbridges that we could show to the executives and auditors as evidence that we were spending their money wisely.
That has now changed as organizations have shifted from a perimeter-based defense strategy to one designed for the cloud, where firm barriers don’t exist.
To appreciate just how far IT security toolsets have come, let’s survey how they have evolved over the past 10 years or so. Much of this article will be based on my personal career experiences, but I think they fairly represent prevailing trends.
IT Security Tools in 2008
In 2008, the organization I was in, like many others, was in the early stages of a full business transformation project to modernize their legacy systems to a new service-oriented architecture (SOA) built primarily using Java. Of course there were secure coding classes that only some staff attended to because it was a checklist from the auditors, but the bulk of all planning and execution for security was handled by the infrastructure teams. Even encrypted protocols like HTTPS were used sparingly and were often terminated at the edge by load balancers, and all internal traffic was unencrypted.
The n-tier deployment model was standard and proven and easily passed through all design reviews, and would go into production without much extra thought. The only place there was a lock (representing encryption) was on the load balancer, which was where TLS was terminated. The intrusion detection systems and intrusion prevention systems used in the front of the firewalls couldn’t even inspect the little bit of traffic that was over HTTPS. Within each tier of the network, access was wide open to move between servers.
We also had no concerns around the developers building on their local machines and the package that Operations deployed into production, as long as the build and deploy were handled by different teams that passed the audit requirements (which drove the security of the day).
IT Security Tools in 2013
In the Operations space, security tools have evolved and increased functionality, but the logical structure is still the same. Servers have been virtualized so there is better density. TLS has been extended based on the load balancers to the web application server tier which helps improve security, but the restricted zone still has little to no security. With servers still organized in tiers that allow full access to other servers horizontally, whether they are required or not, load balancers have been rebranded as Application Delivery Controllers (ADC), and can act as web application firewalls to inspect the traffic before sending it to the application tier and reject requests that look malicious based on rules the Operations team has defined.
The biggest improvement in the security profile of applications in this time frame was that enterprises moved towards the concept of a continuous integration pipeline. While the pipeline was not continuous at this point, it broke the direct link from the developer’s machine to the repository by forcing all builds to be repeatable and leverage a product like Jenkins. By introducing automation servers, it allowed the quality assurance and security teams to add tools into the build pipeline to help identify common bugs which lead to security flaws in the code (example tool: FindBugs, now called SpotBugs), as well as to check code style for consistency (example tool: CheckStyle), and perform static code analysis on built artifacts to find unused code and other areas to be addressed and optimized (example tool: PMD). Overall, a code pipeline did more for improving the security posture of an application than any new features that infrastructure could add to the perimeter.
IT Security Tools Today (2018)
In the last five years, several key technologies have gone mainstream, and have changed things for the better. To quote The Fresh Prince of Bel Air, “Now this is a story all about how/ My life got flipped turned upside down.”
The three key technologies that have gone mainstream are:
- Software-Defined Networks
- Cloud Computing
From an Infrastructure and Operations point of view, all the same underpinning concepts are in play, like load balancers, firewalls, and virtual networks. The difference today is that they are all based purely in software and can be applied to any asset without having to buy more physical firewalls and switches with the need to run more cables.
From an application development point of view, the code pipeline that was defined five years ago has been improved, and there is more automation, especially around testing. In addition, a new post repository stage has been added which can scan packages already built and potentially running in the environment for new vulnerabilities as they are disclosed. With this new continuous scanning capability, security and development teams can easily prioritize their efforts to know which applications need to be addressed without long nights of manually validating every application to see what version of a library is included to know if it is vulnerable.
While there are still applications being maintained and even deployed using older security technologies and models in organizations across the globe, there is a critical mass behind new technologies.
What’s also interesting is that it’s not just one group within IT organizations that is driving change. Unlike in the past, when certain groups led the way with new technologies (developers led on SOA, virtualization was I&O, and virtual networks were the security and network teams), we are now seeing a trifecta of security, development, and I&O teams that fully recognize the need for next-generation, cloud-native security solutions.
- Cloud Native
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog
CVE-2018-1002105: Critical K8s VulnerabilityRead the Blog
Advanced runc Debugging for Fun and ProfitRead the Blog
Introducing Twistlock Support for AWS Lambda LayersRead the Blog
Cloud Native Security Intelligence: Integrating with AWS Security HubRead the Blog