George Wainblat

George Wainblat

George Wainblat joined Unbound in June 2017 as Director of Product Management. George brings a wealth of experience in leading multi-disciplinary product, engineering and business units at global hi-tech companies as well as startups.

Cloud-Native Secrets Management: Part I

This is the first part in a three-part blog series titled “Introduction to Cloud-Native Secrets Management”.

Cloud-Native

Over the last several years, a massive transition from on-premises to the cloud is taking place, resulting in a significant increase in the adoption of Cloud-Native practices and technologies by many enterprises across various market verticals.

The cloud-native eco-system encompasses domains such as scheduling & orchestration (i.e. Kubernetes, Docker Swarm and Mesos), coordination & service discovery (i.e. etcd, Consul), host management (i.e. Chef, Puppet), security images (i.e. Aqua, Twistlock) and vaults (i.e. Hashicorp and Conjur).

Cloud-Native methodologies such as DevSecOps, continuous delivery, containers and micro-services are widely adopted and pushed by developers globally, as they are an essential building block in the digital business revolution – enterprises to deliver applications rapidly in response to customer needs, with Cloud-Native solutions fueling a new engine of business growth.

The usage of cloud-native technologies requires the use of various secrets – but it’s not the TOP SECRET classification you are probably familiar from federal documents.

What is a secret?

There are several types of secrets in existence:

  • Sensitive Security Information (SSI) – confidential business information such as revenue, profit & EBITDA figures of a private company, vulnerability assessment reports and cyber threat information
  • Personally Identifiable Information (PII) – like full name, home address, email, ID number, license plate number and phone number of a certain individual
  • IT Systems Security Information – encryption keys (private and symmetric), certificates, cloud service access credentials (e.g. AWS IAM), access credentials such as username/password, DB credentials, API tokens, etc.

Or just anything, that if exposed would harm business reputation, like in the recent HBO hack revealing unaired Game of Thrones episodes.

Existing Challenges

While cloud-native methodologies are highly advantageous and are instrumental to the digitalization of industries, they also pose significant security challenges for secrets management that we just cannot overlook, such as:

First, there is a secrets proliferation – as mentioned above we have a wide range of secret types located in various locations (on-premises, in the cloud and hybrid). Secrets are decentralized and located in various places, while being managed by different administrators. Moreover, there is no single secrets control – no unified control plane for the plurality of various secret repositories, making the management a practical nightmare. This causes segmented visibility into secrets usage – due to lack of unified control, the secrets’ local administrator cannot see the secrets usage by the different applications. For instance, the DBA has no control over the applications that use the DB after they have received connection strings.

To make things even more difficult, while large enterprises want to be happy campers in the cloud, some of their infrastructure is classic IT, and now there is a challenge of managing secrets in both legacy IT and Cloud-Native environments. This creates both a duplication issue (e.g. in an organization that already has existing key/secret management solution, having another one that is cloud-native specific is undesired) and a security issue – how can cloud-native systems securely access resources that are external to the cloud-native environment.

Security in a software-defined environment – a cloud-native environment is software-defined by nature, and on top of that it is typically detached from a specific infrastructure such as a private/public cloud service provider or a specific on premise location, raising questions about security, ownership and control of secrets, and cryptographic keys in particular.

High level of trust requires relying on hardware – the root elements used in today’s security infrastructure such as secrets, identities, cryptographic keys and certificates directly derive their trust level based on hardware based protection, physical segregation and control. The structural problem is that in pure cloud-native environments being by definition software-defined, physical solutions like HSMs (Hardware Security Module) and TPMs (Trusted Platform Module) have no architectural fit.

With the transition to cloud and specifically cloud-native technologies there are specific challenges that one needs to be aware of – orders of magnitude scale increase in the number of secrets, the interconnectivity required for them to be used / accessible during the setup and runtime in a very dynamic environment.

And last but definitely not least there is an issue of secrets revocation – if your vault has legitimately provided a private key to an application, which later was hacked, there is no way to get this very sensitive information back, from the second it was released. The best practice to protect the private key would be immediately revoking the associated certificate, upon the breach detection, preventing any future misuse.

Business Implications

After establishing the mutual understanding that secrets management in a cloud-native environment poses some serious challenges, lets understand the real implications of these potential issues for businesses.

Due to lack of proper security of the associated secrets, a hack or secrets leakage can potentially lead to a cyber-attack such as:

  • Sensitive Data Breach – a security incident in which sensitive, protected or confidential data (e.g. credit card or bank details, personal health information, trade secrets or intellectual property) is stolen, due to insufficient protection of the encryption keys at rest.
  • Man-in-the-Middle Attacks – if the attacker can gain access to the symmetric encryption key of the communication protocol (e.g. AES 256 bit), he can secretly relay and possibly alter the communication between two parties who believe they are directly and securely communicating with each other.
  • Certificates Theft – after infecting the system for instance with a back door Trojan, the attacker can gain full access to the compromised computer and steal both the private key and the digital certificate, allowing the hackers to digitally sign malware as legitimate software, or issue a certificate to a phishing site disguised as a real online business.
  • Credentials Theft – this can lead to compromised data, compromised systems, and people using your accounts without your knowledge, if the credentials allowing access to a system (e.g. username/password, access token, private key) have been compromised.
  • Spoofing of Applications and Users – a situation in which one person or program successfully masquerades as another by falsifying data fooling the underlying authentication mechanism, thereby gaining an illegitimate advantage. For instance, in ARP spoofing a malicious actor sends falsified ARP (Address Resolution Protocol) messages over a local area network, linking of an attacker’s MAC address with the IP address of a legitimate computer or server on the network, intercepting any data that is intended for that IP address

As cloud-native methodologies are adopted by more and more leading enterprises globally, this has tremendous enterprise-wide business implications, from inhibiting production deployment of cloud-native applications due to insufficient security controls or lack of regulatory compliance, to potential cyber-attacks resulting in major losses. In the next posts of this series, we’ll dive deeper into these issues and shed light on potential approaches for resolving them.

Subscribe to BLOG

shares