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…
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:
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:
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.
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.