Oct 18, 2019 Not so much “Zero Trust” as “Trust, but Verify”
In the wake of out most recent round of cloud and cybersecurity research, I’ve been thinking about the slow evolution of application security and the evocative, if misleading, concept of “zero trust.”
Trust and Application Security, v. 1.0
I am (to my occasional astonishment) old enough to remember the earliest days of application security. It consisted of having an account (on a mainframe or mini computer) with permission to access the application executable. If you could reach it, you could use it, and the application did not have any kind of account or identity system of its own. In that sense, we trusted the OS to protect it, and (with the account system) we protected access to the applications. I didn’t give it any thought until one of the first hackers I knew (hey, Adlai!) showed me how the system I thought so impenetrable has a whole alternate login system that provided access to a sort of sub-OS…and that had not been properly locked down when the system was configured. (This was hacking v 1.0 as well, so after he’d had some fun seeing how far in he could get, Adlai told the sysadmins about the side door into the system.)
Wheels Within Wheels
Generations of steadily more complicated security milieus involving overlays of system, application, database, and sometimes other permissions, with network security overlaid via segmentation of the network. But application security tended still to be user-identity-based, coarse grain, laid on as an afterthought, and wrapped around the outside of the application (which made a lot of sense when they were single monolithic components, but less and less as they began to fragment and then atomize..
Zero Trust as Concept
It would be more accurate to say “zero implicit trust.” It’s not that there is no trust in a ZT environment, but rather that trust relationships are fine-grain and explicit. Any entity receiving a packet will check to see if it is allowed to communicate with the requestor, and drop the packet if it is not. Receiving a request for its services, it will check to see that the requested service is allowed to that specific requestor, and reject it if it is not. The only trust is between the entities in the environment and the authentication and authorization systems that define what is allowed.
In such an environment, a network element can consult the same authorities and block or allow network packets accordingly, reducing the security-driven processing load of the applications. But, the application does not trust the network or the environment to protect it, and if a network element is misconfigured or overloaded or subverted, the application’s security is still intact.
Application Security as Central Design Principle and Practice
The best thing to happen in the age of zero trust thinking is its infusion into agile development practice. The idea that even the different pieces of an application should not implicitly trust each other but instead verify the identity and access rights of anything trying to utilize them represents the last phase of application security evolution. It becomes even more powerful when coupled with the practice of weaving automated security testing into the build process, to ensure that every code release at the very least replicates the security of previous releases (if not improving on it).
The end result should be, over the next few years, the creation of a level of security unprecedented in the Internet era. There will be lots of kinks to iron out along the way, especially in the deployment of efficient security policy authorities within enterprise environments. And, the division of labor among different components in the environment needs to be worked out. (Again, it won’t involve not limiting applications etc. to trusting the network, for example, but will mean using the network to handle much of the load of security filtering.) But the results should be a huge improvement over the vast tangle of today’s security environment.