Understanding Secrets ManagementBy Adrian Lane
If you’ve worked in IT or development you have seen it before: user names and passwords sitting in a file. When your database starts up, or when you run an automation script, it grabs the credentials it needs to function. The problem is obvious: admins and attackers alike know this common practice, and they both know where to look for easy access to applications and services.
With growing use of automation and orchestration, largely in response to Continuous Integration build processes and fully programable cloud infrastructure, we are automating many traditional IT task to speed up processes. Together they have compounded this problem.
From the paper:
>Developers have automated software build and testing, and IT automates provisioning, but both camps still believe security slows them down. Continuous Integration, Continuous Deployment, and DevOps practices all improve agility, but also introduce security risks — including storing secrets in source code repositories and leaving credentials sitting around. This bad habit leaves every piece of software that goes into production is at risk! All software needs credentials to access other resources; to communicate with databases, to obtain encryption keys, and access other services. But these access privileges must be carefully protected lest they be abused by attackers! The problem is the intersection of knowing what rights to provision, what format the software can accept, and then securely provision access rights when a human is not — or cannot — be directly involved. Developers do integrate with sources for identity — such as directory services — but are usually unaware technologies exist that helps them distribute credentials to their intended destinations.
Content licensed by CyberArk.
The full paper is here: Securosis_Secrets_Management_JAN2018_FINAL.pdf