Getting Started with Zero Trust Security

From IC Insider HashiCorp

As IC and DoD organizations embark on their IT modernization strategies, they will face various hybrid-cloud challenges, which includes an exponential increase in complexity to deliver applications. Organization’s government and contractor workforce developed skills and know-how around AWS capabilities.  With multiple Cloud Service Providers now available, it will take time for the workforce to adopt and develop skills to manage new cloud technologies, and there will be resistance to migrate to technologies outside of their “comfort zone.”

Many public sector organizations, such as Department of Defense and intelligence agencies, innovate with HashiCorp Federal. HashiCorp’s products are cloud-agnostic tools that offer organizations a methodology to seamlessly optimize their existing workflows and facilitate their hybrid-cloud strategy by making it easier to deploy applications across on-prem and multiple cloud platforms at scale.

The White House Executive Order (14028), “Improving the Nation’s Cybersecurity,” requires a strong focus on the concepts of Zero Trust, and a mandate to begin implementing Zero Trust principles into an organization’s respective architecture. The issue is that many organizations don’t completely understand Zero Trust principles, and most importantly, organizations don’t know where to start.

Enabling Zero Trust Security in the Public Sector

The migration to cloud means teams and organizations must rethink how to secure their applications and infrastructure. Security in the cloud is being recast from static and IP-based – defined by a perimeter – to dynamic and identity-based – with no clear perimeter. Nowhere is this more true than in the public sector, where organizations are not just protecting their own data, but that of the people and constituents they are sworn to serve. This idea is known as Zero Trust Security.  Read more in our Zero Trust Security in the Public Sector whitepaper.

The recent Executive Order on Improving the Nation’s Cybersecurity, from May 12, 2021 states that “The Federal Government must adopt security best practices; advance toward Zero Trust Architecture; accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS); centralize and streamline access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks; and invest in both technology and personnel to match these modernization goals.”

In accordance with this executive order, the Cybersecurity & Infrastructure Security Agency (CISA) has published the following definition of critical software that it deems as needing to conform to these larger zero trust security considerations and is thus subject to the further requirements of the executive order (EO).

EO-critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:

• Is designed to run with elevated privilege or manage privileges;
• Has direct or privileged access to networking or computing resources;
• Is designed to control access to data or operational technology;
• Performs a function critical to trust; or,
• Operates outside of normal trust boundaries with privileged access.

As a result, agencies that are mandated to leverage EO-critical software and systems need to fully understand and embrace zero trust security, then plan and execute an implementation strategy.

How to Implement a Zero Trust Security Posture

HashiCorp has outlined six steps organizations in the public sector should take to increase their zero trust security posture and reduce risk due to an attack or breach.

Step 1: Centrally Store and Protect Secrets/Credentials

A key challenge to organization security posture is secret sprawl. Secret sprawl is when you have key credentials, tokens, passwords, etc. littered all over your infrastructure.

Many traditional IT departments have a database username and password that’s hard-coded into the source code of an application. It’s in plain text in the configuration file. It’s in plain text in config management. It’s in plain text in version control. It’s in a Dropbox and it’s in a Wiki. It’s sprawled all over your infrastructure in different places and easily accessible to anyone who has access to any level of your systems.

Removing plain text secrets stored in source code or saved on computers is a start. In order to be secure, organizations must secure, store, tightly control, and monitor access to tokens, passwords, certificates, and encryption keys for protecting secrets and other sensitive data.

Step 2: Leverage Dynamic Credentials

As companies move out of private datacenters, they’re faced with new operational and security issues across their applications and infrastructure. As previously discussed, secrets such as passwords, tokens, certificates, and encryption keys previously stored in on-premises systems now create vulnerabilities in source code as systems are moved into public repositories and cloud instances.

In addition to centrally storing, controlling, and monitoring access to tokens, passwords, certificates, API keys, and encryption keys that protect systems and sensitive data, organizations also need to leverage dynamic credentials to further increase their security. Oftentimes vulnerabilities occur due to weak or non-rotated secrets, allowing attackers to access protected data, often for long periods of time. By tightly coupling trusted identities with access, you can maintain a tighter security posture — rotating, updating, and revoking access through the use of dynamic secrets.

Dynamic secrets eliminate the ability for attackers to steal credentials, as they don’t exist until they are read. In addition, they can be automatically revoked immediately after use, minimizing the amount of potential damage by reducing the window of opportunity to use stolen secrets.

Step 3: Replace Perimeter-Based Security with Identity-Based Security

The transition from traditional on-premises datacenters and environments to dynamic, cloud infrastructure is complex and introduces new challenges for organizations’ security. There are more systems to manage, more endpoints to monitor, more networks to connect, and more people that need access. This greatly increases the potential for breaches, requiring action to secure your infrastructure.

To solve this requires the introduction of identity-based security that focuses on access to digital information or services based on the authenticated identity of an individual or service. Such solutions tie access to a single identity, which, once verified, determines what networks, solutions, and data one is entitled to, ensuring they are accessing only what they should be able to. In addition, it becomes much easier to see who has access to what and then to adjust or revoke privileges as needed.

Step 4: Encrypt Everything

Organizations are used to encrypting full volumes of data, such as disks. But oftentimes breaches or a system being compromised is due to someone with access. Encrypting data in transit and at rest helps ensure that if a system is compromised, the encoded data remains safe.

Left Figure: Unencrypted in Transit. Right Figure: Encrypted in Transit

Prevention should always be the primary goal of any security solution, but prevention is often the last step companies take. Protecting and securing sensitive data as if you knew someone was already on the network creates a scenario where even if a breach were to occur, your most sensitive data or information is still safe.

Step 5: Authenticate and Authorize all Network Traffic

As we have already discussed, the move to the cloud leads to the measures previously taken to secure private datacenters start to disappear. Due to IP-based perimeters and access being replaced by ephemeral IP addresses, managing access and IPs at scale becomes brittle and complex. Securing infrastructure, data, and access becomes increasingly difficult across clouds and on-premises datacenters, requiring lots of overhead and expertise.

This shift requires a different trust model that trusts nothing and authenticates and authorizes everything. Machine-to-machine access is a core element of a cloud-first organization. Machine-to-machine access must enforce authentication between applications and ensure that only the right machines are talking to each other. This can be implemented through the use of a service mesh that creates a consistent platform for modern application networking and security with identity-based authorization, Layer 7 (L7) traffic management, and service-to-service encryption.

Machine-to-Machine Access

Step 6: Multi-Factor Authentication (MFA)

Protecting user accounts is vital to an organization’s security strategy. Cyber criminals use legitimate credentials that have been compromised to gain a foothold in a network, avoiding detection for an average of 228 days in 2020 according to IBM. More than 60% of hacking-related breaches involved weak or compromised passwords, according to Verizon’s ​​2021 Data Breach Investigations Report. Microsoft Security reports that enabling multi-factor.

Multi-Cloud Security in a “Zero Trust” World

By following these steps and leveraging the HashiCorp security product stack to help standardize your security posture, public sector organizations will be in a strong position to protect themselves and comply with the security requirements that are quickly becoming mandatory.

About HashiCorp

HashiCorp provides infrastructure automation software for multi-cloud environments, enabling enterprises to unlock a common cloud operating model to provision, secure, connect, and run any application on any infrastructure. HashiCorp tools allow organizations to deliver applications faster by helping enterprises transition from manual processes and ITIL practices to self-service automation and DevOps practices. For more information, visit hashicorp.com.