Verify, but Never Trust?

Much is being written lately about so-called "Zero Trust Model" security, which prompts me to ask, "Since when did we security folk trust anyone?"  On the NIST site, you'll find a thorough report NIST commissioned from Forrester. A main theme of this report is that the old axiom of security "trust, but verify" is now obsolete. Hardened perimeters, once successfully traversed, leave infrastructures that trust the user and traffic implicitly, to their unending peril. 

What does all this mean for those of us tasked with security? Well, it's not a new concept, just a new label.  We have known for years that the notion of a perimeter in a data center is evaporating, largely due to the increasingly browser-driven nature of all apps, and threats moving up the stack to the application.  The network "perimeter" is largely intact, but with seemingly everything of importance transported via HTTP (and increasingly TLS-encrypted), our infrastructures may as well be open at the network level.

Let's consider the fundamental tenets set forth in the report linked above:

  • Zero Trust is applicable for every organization/industry.
  • Zero Trust is technology and vendor agnostic.
  • Zero Trust is scalable.
  • Zero Trust protects Civil Liberties by protecting personal/confidential data.

First, if we're in security, we should be considering how Zero Trust applies and can help improve my organization's security posture. We should be evangelizing this new way of thinking internally, in an effort to educate all aspects of the organization - networking, platform, application development, and any other team that may have a vested stake.  Since Zero Trust is vendor- and technology-agnostic, it's incumbent upon everyone to evaluate current technologies, solutions and architectures to determine whether current implementations adhere to a Zero Trust model.  No one piece of technology or one vendor will bring you to Zero Trust nirvana. 

Next, we must consider what is meant by "scalable" in this context.  F5 has long been in the business of highly-scalable solutions, whether for offloading encryption, web application security, access management, or good old fashioned load-balancing.  However, that's only part of what is meant by scalable here.  Does our implementation of a Zero Trust Model scale across the organization?  Does it apply to both internal and external users and applications? Is access to data cumbersome and overwhelmed by security controls? Does it consider all paths to sensitive data? 

On that last question, regarding paths to data, we hit upon the most important tenet above: the protection of data.  In the end, "data wants to be free" and it is up to the security measures in place to ensure that it still travels freely, but only to those individuals who are properly authorized.  This implies that web-based access paths (Internet and Intranet apps) along with other non-HTTP paths such as drive mounts or direct database access must all be considered and properly secured.  Protecting data then requires good access management, good input validation, and at-rest data encryption.  In order to be scalable, these security measures must be more or less frictionless from a UX perspective.  These are high bars, indeed.

The BIG-IP platform is uniquely instrumented to deliver business applications, and facilitate a Zero Trust model.  Whether it is providing good input validation to prevent data exfiltration via CSRF or SQL injection with Application Security Manager (ASM), or integrating diverse access management mechanisms via Access Policy Manager (APM) without need of any special clients or portals, BIG-IP has a part to play in your Zero Trust implementation.  Zero Trust is nothing new, we have been working for years to improve our application layer defenses through better coding, better frameworks, and new web technologies.  Zero Trust does provide a codified framework to measure our success in developing highly secure and scalable infrastructures.

Has your organization begun considering Zero Trust Model security? What challenges are you seeing, and how are F5 technologies factoring in (or not) along the way to overcoming those challenges?  I look forward to your comments below.

Published Mar 19, 2014
Version 1.0
application
design
http
network
perimeter
security
security model
ssl
tls
zero trust

Was this article helpful?

3 Comments

Sort By
  • amolari's avatar
    amolari
    Icon for Cirrus rankCirrus
    Mar 20, 2014
    Nice paper! I have to trust the BIGIP admins as they're root on the CLI and no way to change that (tmsh access only or appliance mode? no way). How does that fit in the zero trust model? Or is it only applying to the data path? ;-)
  • BAMcHenry's avatar
    BAMcHenry
    Ret. Employee
    Mar 20, 2014
    amolari, great comment. My article above is focusing on the data path, certainly. But the management plane is equally important consideration in a "Zero Trust Model" for security. Despite the catchy term, Zero Trust doesn't mean that no one gets trusted. It would be pretty hard to get much done if we didn't allow access to data or the systems that managed the data path. What Zero Trust really means is that we must put controls in place at every level to ensure the *appropriate* level of trust/access for each individual user. Even if you lock an F5 admin into tmsh-only (via Appliance Mode), you still are assigning an enormous amount of trust, just not quite so much as root-level access.

     

     

    Many organizations are employing stricter and well-instrumented access controls to the management plane of the IT infrastructure, just as they would and do apply to their critical customer-facing web applications.
  • amolari's avatar
    amolari
    Icon for Cirrus rankCirrus
    Mar 20, 2014
    Thanks for replying. IMHO F5 should implement a stricter access control to their management plane. Great feature set on the data plane, but the management plane has been left aside, from a security perspective. No attack... just taking the opportunity to write down my 0.2$ comment, as you're a F5 sec. architect :-)