Are your workload APIs secure?
Do you have a means to quantify residual connectivity risk for workload APIs?
Datacenter and cloud workload application APIs often implement some of the most critical business functionality within an organization. Workload applications speak to other workloads via APIs and are often the building blocks used by customer facing applications when delivering client facing services. Shockingly, most enterprises have no means to quantify the risk related to who is connecting to these workload APIs and where the connections are coming from. Making matters worse, workload APIs are now more exposed than ever due to business transformation and cloud migrations.
Current approaches to solve this problem require recoding applications to add security techniques and visibility. Enterprises also restructure how workload apps interact to include API gateways into the technical architecture. Unfortunately, these techniques may not be feasible because the applications are purchased from third parties, skills and funding gaps prevent mitigation work, potential performance issues, and risk to the availability and/or stability of the workload. In some cases, it may not even be technically feasible to apply modern techniques because of older technical stacks.
Even when API gateways and recoding are possible, modern solutions don’t solve for the unique problems that workload interactions have such as the need to lockdown interactions between known parties to limit lateral movement and control the attack blast radius.
I’ve been looking at this problem for a while and realized that the solution was staring us right in the face. Exploiting Transport Layer Security (TLS), already the most important security protocol used within an enterprise, immediately provides comprehensive protection against lateral movement and inappropriate access. So, why isn’t this being done? It’s hard to make mutual TLS easy.
Sure many server applications and API gateways support mutual TLS but they leave the coding of the client side up to the developers. Developers typically don’t have the skills, time, or access to tools necessary to implement and sustain security code.
A comprehensive solution must automatically upgrade workload applications to mutually authenticate and authorize interactions and provide the means to perform cryptographic maintenance tasks such a version upgrades, key lengths, algorithms as well as to provide a pathway to quantum safe keys.
This quest became the focus of TrustFour where we are working on the “easy button” for implementing workload API Security using mutual TLS combined with authorization. Without code changes TrustFour enables applications with all the required services plus provide single pane of glass management, visibility, crypto-agility, and vitally has the means to quantify residual connectivity risk.