18
June 2018
DevOps guide to Privileged Account & Credential Security
Andy Harris
If you work in DevOps, you are probably part of the team that’s responsible for the bulk of the heavy lifting needed to deliver your organisation’s business goals. Mostly, you’re not coding in a vacuum, but in that zone that combines middleware and COTS (Commercial Off the Shelf) Software.
Naturally, you’ll be dealing with the credentials needed to access data on applications, systems and devices. Depending on the size of your current project or organization, you could be dealing with a mixture of UAT (User Acceptance Test), PreProduction and Live data. This means that you have the responsibility of protecting the data and the credentials. This blog explores how you can keep your privileged accounts and credentials secure…
No credentials in code
There should be no credentials embedded in code. Firstly, it’s a security nightmare, and secondly it makes it hard to switch between Development, UAT and production environments. You should be especially careful of tests or ‘sketches’ that could get committed to GitHub (or your choice of source control).
Always assume an attacker can see your source. API Keys are a classic fail in terms of source control. Here’s some strategies for collecting credentials:
- Avoid – have your code under a privileged account. You can do this by context switching, or running as a daemon/service. You could also arrange a trust relationship between the system that runs the code and the system that hosts the application or data. This has issues of system compromise. If one system is compromised, an attack can leverage the trust relationships.
- Collect – have your code collect credentials from a password vault. This has issues in that you need to be privileged in the first place to make the acquisition, or you’ll be using an API key.
- Push – have a Privileged Access Management (PAM) product push the required credentials/API Keys to your code. This gets even better when the PAM product calls your code as part of a task. The main issue here is that your code could be maliciously modified to abuse the given credentials.
Clear as soon as possible
If you do use keys and credentials in code, clear them and the references to them as quickly as possible. Do not allow a program to end with the credentials intact.
A common attack vector is RAM scraping. Where malicious code trawls either running or recently terminated programs looking for credentials. For example:
- Acquire Credentials
- Make Connection
- Authenticate
- Handle Errors
- Credentials = None # No One can RAMScrape after this.
It’s not finished when it works, it’s finished when its secure
With so much pressure to deliver on business goals it’s so tempting to release code into production. At Osirium, we’re into secure coding practices which, whilst over the top for most DevOps environment, does yield some useful pointers. We use ‘pull requests’, which means that no code gets on a release branch without another programmer reviewing it. The reviewer takes the stance of how can I break this, how can I make it leak and how could I take advantage of this.
You should also consider which permissions your PAM or Task Automation system will give out by pushing credentials – are they more than needed to get the job done? It should be obvious that Domain Admin is not needed for every function, but it may be tempting to just give out all permissions because it makes your code ‘work’.
If you went down the daemon/service route, you should consider having a PAM product manage the credentials of service accounts.
Keep data clean – beware of logging
Are you creating islands of data? For example, does your application export data in CSV/JSON/XML to be used in another application? If it does, what is the risk to that data at rest? It could be a record of payments, or contain personally identifiable data. One could put your business at risk of leaking Payment Card Information (PCI) and the other could set you on a collision course with GDPR.
It’s good practice to keep your data as close to the source as possible. Good data sets mean accurate business decisions. Many data sets create an audit overhead. Whilst considering data sets, you should consider how your application handles logging. For example:
log.debug( ‘Logged in with {0} : {1}’ .(username, password) )
That’s extreme, but GDPR would throw up more subtle examples. You should be wary of logging, even when you consider that production systems will never run in debug mode. An attacker is very likely to run your code in debug mode just so that they can easily reason around what it does and how it runs.
Osirium has been building Privileged Access Management and Automation modules since 2008. Together, these modules provide a platform for Secure Robotic Process Automation that helps companies realise their digital transformation strategies.
If you’d like to find out more about Osirium PAM, get in touch.