Burn your API keys!
Burn your API keys!
Looking at API keys as a threat to your companies existence opens up the idea of using application identities and create temporary credentials based on "zero-trust" tech.
Long-lived access credentials and API keys are a threat to your company and a treat to attackers. Many of them are difficult to keep secret, hard to rotate and must be kept in an inventory so you know what you have.
Most data breaches happen because of accidentally leaked or stolen credentials, such as API keys or passwords.
According to IBM, the average cost per breach is over 4 million dollars
This can ruin a business in the blink of an eye.
One of the most recent data breaches:
Okta Data Breach (October 19, 2023): A service account stored within the system allowed unauthorized access to Okta’s customer support system.
The solution to this? Do not use long-lived access credentials. This applies to humans and machines.
I am running an experiment offering anyone 30 minutes of free security consultation. Just sign up for a spot or share with a friend.
For humans make sure sensitive actions or logins have a short-lived session time or require re-entering passwords and second-factor authentication.
Machines use short-lived access tokens or, even better, a form of zero trust based on machine identity.
On a k8s cluster, you can use ServiceAccount tokens to identify your workloads. On most cloud providers, your systems can have an identity tied to your chosen role.
You can use systems like OIDC to establish trust between service providers and various SaaS.
In a past project, we combined Kubernetes Service Accounts and AWS Roles to get to almost zero long-lived access credentials. (Luckily, this application did not have a lot of external third parties)
In the end, we integrated:
GitHub
GitLab
AWS access to internal components
HashiCorp Vault as Credentials proxy/ temporary credentials
Ultimately, this reduced the inventory of secrets that needed to be maintained tremendously, allowing us to rotate these more efficiently and regularly.
Developers were also happy with it, as they didn't need to request secrets be stored for them in production vaults and could fully own their code.
Interesting Links
Runs check against your EKS clusters to ensure they follow the EKS best practices.
Open-Source Security Automation
Security orchestration, automation, and response (SOAR) allows you to react to detected security events and automate much of the response. Similar to Zappier or IFTT, it is a no-code/low-code environment that enables security teams to do more automation and less manual work.
The Business of Protecting Individuals
This article takes a deep dive into why building a successful consumer-focused security company is challenging. In the end, it boils down to awareness, perceived threat, and the likelihood of actually being attacked or hacked.
Working Together?
Thank you for reading along. If you have feedback or questions, message me anytime at andy@occamslabs.com. If you want to be featured in the next issue or have some suggestions send them my way.