Introduction to Zero Trust Networks
Zero trust (ZT) is a “never-trust-always-verify” framework used by IT organizations to increase defenses against external attack to steal sensitive data, private information and resources. IT and enterprise architects use zero trust architecture (ZTA) based on zero trust principles to design and implement robust and resilient infrastructure. When zero trust is applied to protect data-in-transit by securing a network and communication, it is called a zero trust network (ZTN).
The idea of zero trust in networks has become famous among enterprises after 2020 because of the following drivers:
- Increase remote users and workforce with BYOD connected over the network
- Rise in cloud-based assets located outside the enterprise’s network boundary
- De-globalization and cyber threats across the world
- Strict focus on compliance and regulations to secure network
- Adoption of Kubernetes container orchestration platform for scale
ZTN can be achieved by removing or reducing trust on users and applications on assets or resources irrespective of the network location. With the growing presence of microservices in hybrid cloud, it can be a very daunting task to choose various applications to implement. The best approach to achieve ZTN is using service mesh, like Istio or Linkerd.
As per SP 800-207, laid out by the US governmental organizations the National Institute of Standards and Technology (NIST) and the National Cybersecurity Center of Excellence (NCCoE), and our decades of expertise with respect to implementing zero trust at large enterprises, we propose 10 pillars security and compliance IT managers should consider to achieve a zero trust network (ZTN).
1. Identity Using Authn/Authz
Identity means validating the digital identity of a user over their usage of resources such as web applications, APIs, platforms, devices, or databases. A user can be a human — customer, employee, consultant member, participant, or a machine — an application, an API call, hardware devices, etc. Identity of a user along with their permissions to use resources, can be verified and validated using the authentication and authorization (Authn/AuthZ) mechanisms. Apart from identity management, the security requirements of organizations to deal with multiple microservices would involve granular controls for user and applications, compliance standards, RBAC, etc. In real life, IAM can be really complicated to achieve.
2. Secure Channel Using mTLS Based Communication
Mutual Transport Layer Security (mTLS) is a method for authentication between two parties connected over a network. mTLS based communication is highly secured between two parties (say client and server) as each application authenticates itself first using X.509 certificates and the communication happens based on private keys which also rotate in regular period. mTLS is considered as the successor of Secure Socket Layer (SSL).
3. Certification Management
Securing connection between the two parties is one part, while certificate management and rotation is an ongoing maintenance part. In cases of regular upgrades of security policies, or security breaches, the old certificate will not be valid. Cloud architects and platform engineers should think of an effective way for administrators and Ops teams to easily rotate SSL or SAML certificates, generate private keys and distribute among all the microservices.
4. RBAC, Multitenancy, and Isolation
It is an ongoing task to allow or deny users to read/write/delete permission to various resources. Necessary controls should be in place to implement granular policies for role-based access controls (RBAC). Large organizations typically would need to create a dedicated workspace for various projects or platform teams, and there should be provisions to practice multi-tenancy as part of security measures.
5. Whitelisting Trusted Sources
Perhaps the simplest “cybersecurity measures” practiced by security engineers, whitelisting involves giving administrator-approved IPs and application access to a system. This is particularly very helpful in recent scenarios of BYOD, where certain applications are allowed to login resources in the VPN.
6. FIPS and SOC-2 Compliance (for US-Based Companies)
The US-based agencies such as NIST and American Institute of Certified Public Accountants (AICPA) provide guidance and FIPS and SOC regulations for every IT organization. As per the NIST regulation, all the non-military, government agencies and vendors must comply with Federal Information Processing Standards (FIPS) standard. Similarly, System and Organization Controls (SOC) standards specify the way service organizations should handle customer data; it covers 5 major aspects — security, availability, processing integrity, confidentiality, and privacy of customer data. So for any company operating out of North America, complying to compliance such as FIPS and SOC-2 are important.
7. Web Application Firewall
Web application firewall (WAF) helps protect web application from attacks such as DOS attack, SQL injection attack, cross-forgery, etc. WAF is a L7 protocol which acts as a shield for web-applications, and network engineers can create various rules and policies such as traffic filtration to protect against vulnerabilities in the application.
8. Data Loss Prevention
Data loss prevention (DLP) is the practice of detecting and preventing data breaches, exfiltration, or unwanted destruction of private information. DLP is also a part of SOC-2 compliance. The primary aim of the DLP act is to prevent illegal transfer of data outside organizational boundaries. Network team and cloud engineers should focus on building a system which is robust to threats from malicious insiders or external ransomware.
9. Secrets Management
In Kubernetes, many services inside or outside the cluster talk to each other using secrets. Developers should practice proper secrets management — a practice of storing sensitive data such as passwords, keys, and tokens in a secure environment such as Vault with strict access controls.
10. Multicluster Visibility
IT organizations using cloud and containers profusely should have a central plane for multicluster visibility. They should be able to see workloads, resources, and infrastructure such as ingress and load balancers along with the health and performance status across all the namespace and cluster. SREs should be empowered with real-time logs and metrics aggregation and analysis to reach any situation faster with quick diagnosis.