Several recent events have made Zero Trust security a mandate for companies, governments, and non-profits. The US Government has taken a decisive leadership in this area as depicted by the following initiatives.
Furthermore, The Office of Management and Budget (OMB) and the Cybersecurity and Infrastructure Security Agency (CISA)  have produced technical guidance documents in its endeavor to help the U.S. government towards a Zero Trust architecture.
Despite the immense benefits of ZeroTrust Security solutions, they have been hard to implement and deploy “at scale”. This, and related issues were discussed at the ZeroTrust DevSecOps NIST Conference . The following article summarizes key concepts that were discussed at this conference and outlines areas where AccuKnox solutions alleviates critical challenges with current technologies.
John Kindervag coined the term Zero Trust in 2010 while he was at Forrester Research. However, it was not an entirely new concept. Jerome Saltzer and Michael Schroeder in their 1975 article “The Protection of Information in Computer Systems” introduced the concept pf Least Privilege. Ken Thompson’s paper “Reflections on Trusting Trust”  opened up key questions and served as the foundation of later work in this area. Paul Simmonds, CISO, ICI, U.K introduced the notion of “deperimeterization” at 2004 Blackhat Conference. This was followed by John Kindervag coining the term ZeroTrust. Google’s BeyondCorp framework brought this concept to mainstream industry and academia. Albert Einstein said “Everything should be made as simple as possible, but no simpler.” John Kindervag’s Zero Trust definition met this test and hence has survived. It outlined the following tenets:
1. The network is always assumed to be hostile
2. Assume threat actors are already inside your network
3. Network locality (segmentation) is not sufficient for deciding trust in a network
4. Every device, user and network flow is authenticated and authorized
5. Policies must be dynamic and calculated from as many sources of data as possible
6. The device is no longer the border. A user/service’ identity is the net border
7. Containers, serverless and cloud are the new disruptors of traditional security architecture
What is DevSecOps?
Short for development, security, and operations, this model automates the integration of security at every phase of the software development lifecycle, from initial design through integration, testing, deployment, and software delivery.
Why is DevSecOps important?
Developers are focused at delivering functionality to meet the goals of the business. Delivering functionality at the agility and velocity of the business requires a CI / CD (Continuous Development / Continuous Integration) approach and does not allow for issues to be detected at late stages in the development cycle. Often, security departments discover issues precisely at this late stage, placing developers at loggerheads with the security goals of an organization, an un-tenable proposition and un-sustainable position. Hence, it is imperative that a durable solution is found.
Developers worry about delivering, in Steve Jobs’ words “insanely great” products:
· Great user experience
· Great APIs that can be consumed by other developers, etc.
However, in order for this to be deployable, maintainable, monitorable and secure, the following key questions need to be addressed:
· What are the rate limiting parameters
· Does it have guardrails against Denial of Service attacks?
· Does it meet corporate authentication standards?
· How is it secured?
· What compliance, governance frameworks does it need to meet, Etc.
While it is always a shared responsibility, it is imperative that Security Products and Tools do not burden the developer with implementing security, security policies; and endeavor to provide tools, harnesses to make it easy for developers to ensure that their software is secure by default. While this might seem like a tall and possibly even an un-achievable goal, we have an “existence proof”: SSL libraries helped web/browser communications secure by design, default. DevSecOps aims to do the same at a larger scale for Enterprise Applications by baking in security as default, removing the burden of security away from developers.
NIST Guidelines for Zero Trust Microservices Security
As it pertains to micro-services, NIST IR 8313 offers the following guidelines for ZeroTrust:
· Ability to authenticate application user credentials
· An authenticatable runtime identity for services
· Encryption of “in transit” communication between services
· A Policy Enforcement Point (PEP) separately deployable and controllable from the application
· Logs and metrics for monitoring policy enforcement
ZeroTrust delivered in a DevSecOps model
AccuKnox enables DevSecOps for the Microservices by providing tools, frameworks, integrations at every stage. This is illustrated below:
It is further elaborated in the table below:
Immense thanks to Karthik Prabhakar for providing valuable inputs for this article.
Our connected eco-system increases the attack surface to millions, billions, trillions. While the connected world has done marvels for society, the recent SolarWinds attack and the cascade effect that ensued demonstrated the shared risk we face and the fact that we are only as strong as the weakest system in our connected eco-system. While we can never 100% prevent the initial attack, early detection and blast radius containment are very reasonable and achievable goals. ZeroTrust solutions make it easy for organizations to achieve this. Further innovations by AccuKnox and others facilitate deploying ZeroTrust solutions in a DevSecOps fashion, thereby making it easier for developers to embrace it and organizations to adopt it. Zero Trust is more about Resilience than Protection and hence the following, derived from President Ronald Reagan’s famous quip “Trust but verify” is apt for the Zero Trust world we are entering.
 Ken Thompson — Reflections on Trusting Trust