Strategic Technology: Security, Digital Transformation & Cloud Native

TL; DR – Security will be the most significant vector for enterprise sales of Cloud Native technologies in the medium term. Widespread adoption of Cloud Native will remain driven by developers.

Over the last eighteen months most of the technology industries focus in the cloud native space has been around the orchestration layer. From Kubernetes offerings, such as Tectonic from CoreOS to OpenShift from Red Hat, to Docker Swarm, to various Cloud Foundry offerings, to Hashicorp’s product suite and more – much has been written about various orchestration approaches, their merits and de-merits and so forth.

Orchestration is extremely interesting to practitioners and early adopters. However, from the perspective of the business owner of an application or suite of applications orchestration is an implementation detail that carries a relatively low degree of risk.

For all the efficiencies and optimizations that we may make on the technology front, given a sufficiently large operating budget orchestration and scaling are essentially solved problems in almost every circumstance. That is not to say that orchestration and scaling are not important, and difficult, problems – they absolutely are – but they are, at their core, technology problems that are almost exclusively under the remit of an organisations technology teams.

At the same time, we have seen a growing awareness of security among board and C-Level executives. Cyber security is now (some might say finally) seen as a board level item in the risk registries of a significant number of large companies, although as Groysberg and Chen (2017) note the overall percentage is still quite low, and many boards still do not view security as a strategic threat. This does not change the fact that improving security is an operational imperative, and data breaches which break compliance requirements are fast becoming an existential risk for many companies.

As companies flesh out their digital transformation strategies they are focused on bringing more and more developers in-house and allowing them to focus on developing strategic, high value, applications. Historically developers of all hues, be they in-house or working at a major software vendor, have viewed security as – at best – an after thought and more commonly as a hindrance to shipping product.

While every developer should think about security, anyone who has ever spent significant time around a software project has seen a shortcut taken, a hardcoded password saved, or an api-key or worse getting committed to the version control system. In part, such lapses are due to a reluctance to ensure basic security best practices. But they are also a factor of time constraints teams often find themselves under, a lack of education in approaches to security and a, generally historic, lack of concern with the implications – breaches have been the responsibility of the operations and security teams, not the developers.

However, as we move into a new era of applications, security is, finally, a factor that is to the forefront of people’s minds.  This then takes several forms, among which are the choices on a technology level, alongside the wider systemic changes which need to take place. Kaplan et al (2015) at McKinsey use the phrase “Digital Resilience” to describe the change in approach required – moving from cybersecurity being the responsibility of a small number of people in the technology organisation and moving to something which is integrated into business processes and the broader technology environment. Essentially a set of processes and technology that ensure security best practices, among other factors, are always in place – but also allow developers to focus on creating applications which deliver value to their business.

It is important to state that this “digital resilience” approach is not necessarily a PaaS, or anything even resembling a PaaS. Rather it is a testing, validation, packaging and deployment approach that includes security in a manner that gets out of the way of the developer, but allows operations teams to feel confident that applications, and even more importantly data, are treated in a secure manner. PaaS is just one packaging mechanism for such an approach.

The Cloud Native Security Landscape

Bringing all of this back to cloud native we need to look at several interlinked concepts – with immutable infrastructure, infrastructure as code, vulnerability scanning approaches, container registries, secrets management, network management and scanning, and source code provenance being among the most important.

It is also important to realise that containers play an absolutely key role in all things related to cloud native security. As my colleague, Stephen O’Grady, noted in the past, the atomic unit of computing has shifted  – and while serverless and the associated FaaS moniker is a logical conclusion for a significant number of workloads, containers are the de-facto new unit for most organisations.

Immutable Infrastructure

Immutable infrastructure is an idea that has gained a lot of attention over the last few years, with the concept really coming into focus with Martin Fowlers discussion on Phoenix Servers back in 2012, and Chad Fowlers discussion of Immutable Infrastructure in 2013. As people build on these concepts, we have observed several different approaches, but they all essentially boil down to the idea of a rapidly replacing infrastructure beneath, and up to and including, your applications.

All the configuration is done during the build process, and when you need to replace a component you rebuild and deploy, rather than patch and update. It is the pace of change and the control points that vary across the approaches.

Vendors operating explicitly in this space include CoreOS with both Container Linux and Tectonic, which, when configured to do so, will automatically update with security updates, general revisions etc. and Hashicorps suite of tools (eg Packer, Terraform and so forth). In the public cloud, we frequently see the vendors mentioned above being used in conjunction with cloud specific tooling offered by Amazon and Microsoft.

Pivotal have also been talking about a similar concept at the infrastructure layer for Pivotal CF, although with a focus on continuously “repaving” the underlying infrastructure to consistently change the footprint available for attack vectors – it is well worth watching Justin Smiths talk from last summer’s SpringOne Conference to learn more about this approach.

Infrastructure as Code

The idea of having your infrastructure under version control is one that is gaining widespread traction, and from our point of view this can only be a good thing. While auditing and compliance are outside of the scope of this article – we do envision auditors gaining interest in the idea of infrastructure as code.

The entry points here vary, in part depending on preferences within various organisations – but Terraform from Hashicorp comes up consistently among both early adopters and established enterprises, and we hear of CloudSoft and the associated Apache Brooklyn project in specific sectors such as financial services. The cloud provider specific offerings are also frequently mentioned, with a notable uptick for AWS CloudFormation since they introduced YAML template support.

Vulnerability Scanning

Vulnerability scanning touches upon a multitude of different areas, but for our purposes we will limit our scope to basic analysis (e.g. CVE scanning) and advanced analysis – with a focus on CI/CD integration and runtime monitoring. We touch on source code provenance separately.

Basic Analysis

Much of the initial focus of container security has been around image scanning and validation. In general, this boils down to CVE scanning and providing a list of vulnerabilities that need to be addressed. This ability to report on widely known vulnerabilities is, at best, table stakes at this point.

Advanced Analysis, Runtime Monitoring & CI/CD

There are a variety of techniques which come up in our discussions – these can be summarised, at a very high level, as hardening the initial container images during development and then monitoring and updating them in production via integration with a CI/CD pipeline.

Perhaps the most interesting aspect of the various advanced analysis approaches is around moving past a simple CVE baseline. For example, there are a number of extremely widely used open source tools, such as various frameworks for Java, JavaScript or Ruby that do not have any CVE data. There are sources for this information, and we see a set of security focused vendors actively engaging with the core developers of high profile projects to create additional curated sources of security information.

Vendors that regularly come up in conversations in this area include Anchore, Aqua, CoreOS, Docker, Synk and Twistlock. Of these Snyk is particularly interesting as they are focused on the runtimes across a variety of environments rather than being focused explicitly on containers. As organisations consider options such as serverless technologies this will become more important.  It should also be noted that several companies, such as Twistlock and jFrog, build part of their offerings on curated data compiled by Snyk.

Container Registries

In any technology wave vendors look for a control point, and containers have proved to be no different. The initial control point for most has been around the container registry. Be it as a distribution channel for official images to build upon or as a mechanism to add value via image scanning and other tooling.

However, once enterprises move past their initial experimentation with containers, they tend to want much higher levels of control over the contents of their images for compliance and security reasons. Invariably this leads to private container registries of some form, with variations on the approach to building images.

From our conversations one area of concern we have, in the medium term, is the number of organisations bundling large chunks of an operating system into an image, essentially replicating the VMs that were used previously. This is an educational challenge more so than anything else, but we frequently hear of teams being told to use a complete corporate mandated and approved Linux distribution.

The main vendors we hear mentioned in this area are Docker, CoreOS (Quay), Rancher, Red Hat and jFrog, alongside the hosted registries offered by the Amazon, Microsoft and Google.

Secrets Management

For many companies, more used to operating with the hard perimeter, soft shell approach to deployments, thinking about how to manage secrets, such as passwords, credentials, ssh keys, encryption certifications and so forth is very much an afterthought.

As people move cloud native apps into production there is a growing awareness that the entire area of “secrets” needs to be managed in a manner consistent with cloud native approaches. The first solution that both grabbed developer’s attention and really began to address this problem in a manner that enterprises could consume was Hashicorps Vault.

We consistently hear stories of Vault being used in various production environments, in some very interesting and innovative ways, and are now starting to hear of Dockers Secrets Management functionality being used, although it is still very early days for this feature.

Network Management and Visibility

Interlinked with vulnerability scanning is the area of network management and visibility. The management side is well understood, and invariably comes down to some form of network based segregation of individual microservices, and a set of policies to allow network traffic between sets of microservices. The key differentiation, versus historic network management approaches, is ensuring all this activity is both dynamic and available in a self-service manner. For cloud native applications this is only possible with a software defined network.

On the visibility side, detecting anomalies in the network, and actively looking for data leakage issues (e.g. sensitive customer data such as credit card details or internal data such as api keys being passed in plain text) are the two most common use cases we hear being discussed.

A variety of vendors get mentioned in our conversations in this area, including Cohesive Networks, WeaveWorks and VMWare.

Source Code Provence

The phrase “Source Code Provenance” has come, somewhat, into vogue in recent times. At its core “source code provenance” is about understanding where the code in your system has come from at any given time, including the ability to recreate any given combination of components if needed to investigate an issue or vulnerability.

There are two major aspects too this, firstly the provenance of code created within your enterprise, and secondly the provenance of the code contained in other components you may be using. For the code delivered internally in organisations, identity management is essential, and there is an assumption that vendor provided tools will support LDAP and SAML.

There are no vendors exclusively working in this area, rather we hear a combination of SCM, CI/CD and deployment tools and vendors coming up in conversations. Signing technologies are also mentioned, but, as of now, we have not heard of many production instances using fully signed stacks. We do, however, expect the use of signing and verification techniques to grow significantly as awareness grows of the offerings from Google, Docker, CoreOS and others

Conclusion

The gamut of tools and vendors across the cloud native security space is quite large, but in the short to medium term most enterprise sales deals of cloud native offerings will be built, to a significant degree, with security considerations at their core.

We do anticipate some significant consolidation in this space over the medium term, and a growing maturity around solution offerings.

Disclaimers: Docker, Pivotal, Google, Red Hat, IBM, CoreOS, Amazon, Microsoft, Anchore, Cohesive Networks and CloudSoft are current RedMonk clients.

References

• Groysberg, B. and Cheng, J., (2017), Harvard Business Review, February, [Online], Available: https://hbr.org/2017/02/why-boards-arent-dealing-with-cyberthreats [ 8 March 2017 ]
• Kaplan, J., Bailey, T. and Rezek C., (2015), McKinsey, July, [Online], Available: http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/repelling-the-cyberattackers [ 8 March 2017 ]

Credits

Save Haven image : Copyright Pauline E and licensed for reuse under this Creative Commons Licence