Because one bad apple doesn't have to spoil the bunch.
Image: One Bad Apple, BobbyBoggs182
The data center is being driven by digital transformation to change. Cloud, containers, and catastrophic breaches are forcing the focus on change to come sooner rather than later. Much of the focus is on the impact of continuous delivery and per-app deployments, which can wreak havoc on traditional deployment schedules. Attempting to coordinate traditional and modern schedules are sure to cause even mathematicians comfortable with solving Josephus-like counting problems to throw up their hands and swear off the attempt.
If the benefit to implementing a per-app architectural approach to application services and infrastructure with respect to continuous deployment isn’t enough to move you in that direction, consider that there are also significant security advantages to doing so.
If you can imagine the data center and its security perimeter like a barrel, and then fill it with apples (each representing one of the hundreds of apps you have deployed) you’ll note that one apple touches many others. Not all of them, but some of them. And if one of those apples goes bad, it spreads to those that are touching it. Which are touching others, which are touching others, and so on and so forth until the entire barrel is rotten.
If only the process were as slow in a data center when one apple (app) goes bad. But thanks to digital speed, the spoilage spreads through the network to other apps much quicker than the apples in the adage that warn us of the risk.
This is one of the best security reasons to adopt a per-app architecture – even if you aren’t (or won’t be) embracing per-app deployment schedules.
Adopting a per-app architecture is like individually wrapping each apple before you toss it in the barrel. Even if it goes bad, it’s isolated from the others it’s touching and keeps them from becoming infected too. While we certainly would enjoy a world in which there was zero-risk, most of us don’t live in a land of rainbows and unicorns and recognize that there’s always risk in a connected world and our goal is to minimize it as much as possible.
By employing a per-app architecture we can reach that goal by restricting the blast radius of a given application to itself for as many threats as we can.
A per-app approach in the data center enables deployment of a variety of application-specific security services designed to mitigate the risk from bots, credential theft, credential stuffing, application-layer DDoS attacks (like GET, PUSH, and POST floods), and the familiar OWASP Top Ten vulnerabilities.
Alert Logic calls this “application-level segmentation” and notes that it is quickly becoming a best-practice in the cloud:
This approach works just as well in the data center and is just as critical (perhaps more so) to securing apps against lateral movement in the event of a successful breach.
It may seem ironic that a per-app architecture isn’t just as much about protecting all the other apps you’ve got deployed as it is any given individual app. But taking this approach forces a focus on securing each individual app with the awareness that it is a potential entry point and with the understanding that every other app (inside) could be an attacker.
A per-app approach works even better with cloud-ready application services that can be deployed both in the cloud (or multiple clouds) and at home in the data center. Standardization on an application services solution means policy parity that ensures the consistent security desired as organizations colonize public clouds as part of their digital transformation efforts.
Whether you’re in the cloud (or many clouds) or staying home in the data center, a per-app architecture is a security win-win approach that can reduce risk to individual apps at the same time it protects the entire barrel and keeps the business competitive in the digital economy.