With digital transformation pushing organizations to rapidly deploy new apps and services, too often, development teams can be so focused on getting the next set of features out to customers that security becomes an afterthought. So, with the widespread adoption of DevOps methodologies, how do security teams engage with developers?
One approach security teams are taking is to establish strong, effective partnerships with developers and DevOps teams, but, as with digital transformation, establishing such a partnership is a journey with multiple steps and initiatives. For example, security teams can provide developers with security solutions that make it easier for them to do the right thing. In many cases, this means providing developers with easily consumable security capabilities that can be incorporated into their automated processes.
Some security capabilities are more easily consumable than others. For example, code scanning tools can be added relatively easily to the build processes, preventing code with known viruses or other issues from being incorporated into the build. Some security testing can be automated, so that the build automatically rejects artifacts that fail. These security checks can simply be incorporated as part of the CI/CD process and, except for when a problem is detected, they’ll have minimal impact on the individual developers writing their code.
The area of secrets management is a little more challenging and possibly disruptive, as it potentially impacts each developer when they code or update apps to access databases and other sensitive resources. In this case, the developer needs to ensure each app securely accesses the resource using privileged credentials.
So, typically at run time, the app needs to be able to authenticate to the digital vault and fetch the privileged credential necessary to access the resource. A newly written application, for example, will need to be coded to get the credentials from the secrets management solution, which will need to know to authenticate to the application.
One approach we’ve seen security teams adopt is to provide developers with a self-service solution, so developers can more easily give the apps they are writing secure access to databases and other resources.
Why Self-Service Solutions for Secrets Management?
It might seem simpler to have security work directly with the developers and update the secrets management solution themselves, making sure that each newly created app can use the secrets management solution to get the credentials it needs. While this can work in a small team, an enterprise will have too many apps and likely many more developers writing and updating apps than a security team can handle manually. In that case, self-service becomes a necessity.
One enterprise customer in the retail space needed to rapidly and cost-effectively deploy new customer applications to compete with online retailers. The security team wanted to ensure applications securely accessed databases by deploying a secrets management solution that would be able to secure the core application functions used by the business (such as, inventory, procurement, stores and in store pickup) – which consisted of thousands of Pivotal microservices.
Their developers were great at writing apps; however, with over a thousand developers and only a small security team, security was concerned that they would get overwhelmed and become a roadblock, negatively impacting the deployment of apps. So, the retailer implemented a self-service solution.
They used a Jenkins CI/CD pipeline to automatically update the secrets manager’s policies. Then, with the updated policies in place, the secrets manager only allowed approved apps to securely access databases. Once it was set up, the solution could handle developers’ requests to approve apps to securely access databases and only route exceptions to the security team.
In another example, the security team at a financial services customer with a large number of applications running on Red Hat OpenShift, wanted the developers and application teams to have their applications request secrets based on policy. However, security did not want to force the development teams to write security policies. So, this company opted for a self-service solution to automate the approval process, and now when the developer’s request is approved, the security policy is automatically updated.
Typically, credentials are managed centrally by the CyberArk Privileged Access Security Solution and provided to the applications by The CyberArk Application Access Manager’s Dynamic Access Provider and either CyberArk’s certified Red Hat OpenShift, Pivotal Tile integration or as Kubernetes Secrets.
Why Self-Service Approaches Matter
Developers don’t want to work with any solution that takes up unnecessary time – meaning that a secrets management solution won’t be adopted if they’re going to be dependent on security to update the access policies or if they’re forced to write the policies themselves.
If not done correctly, organizations can experience significant developer pushback, poor adoption and either delays in app deployment or deploy apps that don’t securely access resources. The self-service approach avoids all of this by facilitating developer productivity rather than inhibiting it, becoming a win-win for developers and for security.
Self-service approaches to secrets management not only help security teams build a partnership with developers, but also enables organizations to more rapidly and efficiently ensure the security of their applications. Given these benefits, as enterprises – especially those with large portfolios – make their digital transformational journey, they will likely increasingly turn to self-service approaches that provide developers with an automated way to give applications secure access to sensitive resources.
Discover more strategies for aligning DevOps and security teams and learn about the CyberArk Application Access Manager secrets management solution for enterprises and CyberArk’s open source secrets management solution, Conjur Open Source.
