Latest breaches highlight integration insecurity
An old maxim that posits integration is the enemy of security has never been more apparent in the wake of a series of high-profile security breaches that in recent weeks have roiled confidence in IT.
Exploits of software supply chains have led to a series of incidents that illustrate all too clearly how dependencies that exist between multiple services can have a devastating downstream impact that can all be traced back to a single breach.
Unfortunately, things are likely to get much worse before they get better. Most new software is being constructed in a more modular fashion using microservices that make it easier for organizations to build and update applications faster. Rather than having to update a single monolithic piece of software, new functionality can be added to an application by ripping and replacing microservices. That approach also makes the application more resilient because rather than crashing, requests for services are rerouted to another microservice whenever one part of the application is not available.
From a security perspective, this approach to constructing software can present many challenges. Multiple dependencies get created between all the application programming interfaces (APIs) that developed to enable microservices to communicate with one another. If one microservice is compromised a hacker can gain access to all the other software components that the compromised microservice has permission to access. Before too long malware is spreading laterally across the entire application environment.
Preventing this from occurring requires organizations to employ best DevSecOps practices when building software. As each microservice is deployed and updated it needs to be scanned for vulnerabilities. In an ideal world, developers are scanning for vulnerabilities as they write the code that makes up the microservice.
The good news is that instead of patching an entire monolithic application all that’s required now is to rip and replace the containers whenever a vulnerability is discovered. Many vulnerabilities discovered today are often not remediated simply because application developers don’t have the time needed to patch entire monolithic applications.
Moving to a microservices architecture also in effect increases the attack surface dramatically because what used to be a simple request and response from a single web server now involves dozens of requests and responses to multiple hosts. IT teams will also need to deploy firewalls and application programming interface (API) gateways to ensure microservices are truly isolated from one another. IT teams need to make sure they have implemented identity and access controls such as the OATH protocol to make sure any call made to the microservice is legitimate.
Fortunately, there are also initiatives underway that promise to give each microservice its own unique identity. The Cloud Native Computing Foundation (CNCF), for example, has embraced an open-source Secure Production Identity Framework For Everyone (SPIFFE) specification and the SPIFFE Runtime Environment (SPIRE) to authenticate software services using cryptographic identities that are platform-agnostic. At the core of the SPIFFE specification are short-lived cryptographic identity documents known as SVIDs that are invoked via an API. Workloads employ an SVID when authenticating to other workloads by establishing a TLS connection or by signing and verifying a JSON web token (JWT).
Regardless of how much cybersecurity expertise any organization has today, chances are high most organizations going into the new year are underestimating what’s required to secure application environments that will soon be made up of thousands of microservices. Unfortunately, cybercriminals working on behalf of nation-states have already shown just how well they understand how modern software is constructed, so it’s really only a matter of time before many more similar breaches are discovered.
