“DevOps was a kind of revolution in IT because it focused on people and a change in culture to get things done as much as technology." - Paul Fisher, KuppingerCole Analysts, in KuppingerCole Privileged Access Management for DevOps Report.
There are naturally many reasons why DevOps has gained popularity. But maybe what Paul Fisher stated above actually is one of the key reasons why the methodology was so well-received by companies and developers: it put the people first.
And what do forward-thinking software developers appreciate? Probably:
- a high degree of automation
- minimal need for manual configurations
- reduced friction from daily operations
DevOps has also introduced other concepts like DevSecOps, the purpose of which is to methodologically think about the ways to develop software where security is built-in the application, and not something that is added later.
DevSecOps is naturally great. It covers cross-functional collaboration and product development lifecycle, including product design, development, delivery, operations, support. However, it usually doesn't cover topics like:
- secure remote access for DevOps teams
- proper secrets management in Continuous integration (CI) and continuous delivery (CD)
- Identity governance and administration (IGA)
- 3rd party risk management & mitigation
- compliance and segregation of duties (SoD)
KuppingerCole Analysts just recently published their first-of-its-kind Leadership Compass for Privileged Access Management for DevOps Report (download for free, courtesy of SSH.COM). Clearly, the company saw that access management, privilege controls and credentials management in fast-paced DevOps environments are such important topics that they deserve their own special category.
At this point, I can’t help but mention that we are extremely pleased to be ranked among leaders in the said report.
Since esteemed market analysts see DevOps access management deserving of special focus, let’s take a look beyond DevSecOps and investigate some access management related questions businesses should ask themselves if they employ the services of DevOps teams.
1) Are you in control of the digital keys to the most valuable data in your company?
Let’s start with the obvious. DevOps is full of digital keys, secrets and other pieces of access credentials that are of high value to cybercriminals. Examples include:
- usernames
- passwords
- credentials
- API tokens
- SSL certificates
- SSH keys
- runtime environments
- containers
- microservices
- etc..
Looking at that list, it is no wonder that DevOps is fast becoming a prime attack vector for bad actors. In discussions with our customers, we often find that DevOps teams don’t have uniform access tools at their disposal. Instead, there are almost as many ways to handle secrets as there are teams.
This is because DevOps engineers are often very keen on adopting new technologies that then employ different access methods. Moreover, the CI/CD pipeline consists of multiple steps, each requiring their own sets of credentials and secrets.
Secret sprawl, where credentials and secrets are all over the place, combined with weak credentials or untracked sessions increase the potential attack vector, and adds the risk of data leaks. Let me take a direct quote from Verizon Data Breach Investigation Report 2020.
"Criminals are clearly in love with credentials, and why not since they make their jobs much easier?"
Secrets management is particularly important in the Continuous Delivery part, since it automates the delivery of applications to infrastructure, especially if this happens in the production environment. Another critical part is the developer access to the code repository, like GitLab, Bitbucket, SourceForge or ProjectLocker, since this is where the company Intellectual Property Rights (IPR) is stored.
2) Can you enforce granular access control and role separation?
DevOps engineers may already be accustomed to taking shortcuts, for example, simply by granting superuser or power user access to each other or themselves regardless of the task at hand - even when a more restricted level of privilege would have been more secure.
Using always-on superuser access might be convenient but it is also risky. In DevOps, most teams work in multiple environments besides the production, including development and testing environments. But often, the same set of credentials might provide access from one environment to another or
Regulations require compliance and a proper separation of duties (SoD) meaning that DevOps engineers should not be able to self-provision access rights (often call privilege creep), have multiple roles per person or have direct access from test to production. Instead, they should have just enough access (JEA) and just the least amount of privilege (principle of least privilege, POLP) to get the job done with clearly defined roles.
Since teams are using different tools and handle different types of secrets, all sessions should be tracked and audited in a uniform and coherent fashion.
3) Are privileged credentials shared between teams?
Collaboration, sharing, and trust are key elements of successful DevOps. However, this should not apply to sharing credentials which as a practice is more common that you might think.
In fact, according to this study by Vanson Bourne, 85% of IT professionals share account credentials, even though most of them (70%) know and understand this is an issue.
"85% of IT professionals share account credentials, even though most of them (70%) know and understand this is an issue."
Sharing access secrets leads to losing visibility into who is doing what and with what rights in an environment where you host such valuable information as company IPR.
What's worse, these credentials might end up in the hands of 3rd parties. Sharing credentials- especially outside the enterprise - without being able to associate an identity to them is risky business.
4) Does access slow down the daily work of your teams?
In DevOps, multi-cloud resources are spun up down all the time. Combine this with multiple technologies available to access these targets, and you get a lot of moving parts to manage.
"71% of IT pros stated that they experience issues with cloud access management solutions that slow down their daily work."
In the already-mentioned Vanson Bourne study, 71% of IT pros stated that they experience issues with cloud access management solutions that slow down their daily work. Every minute your software engineers or even admins spend time waiting for access is time and money wasted.
Moreover, this is against the very idea of DevOps: the tools in the stack should make your work faster and more automated, not introduce obstacles.
5) Can you secure application-to-application connections?
DevOps isn’t all about interactive access, since applications transmit data automatically as well. These transmissions also often require high-level of privileges, making them an attractive target for bad actors. In some cases, containers may even have access to privileged accounts embedded in code.
The problem is that these automated connections are often not managed and maintained for proper cyber hygiene, even though fully armed privileged accounts are needed to ensure their functionality. Unfortunately, this translates into another attack vector, especially if these transmission have too broad privileges or are not up to the latest security standards.
Solution: secure access management at the scale and speed of DevOps
DevSecOps should include governance and cybersecurity aspects covering, for example, identity and access management (IAM), privileged access management (PAM), secrets management, configuration and principle of least privilege (POLP). It just makes too much sense to avoid fixing solutions or code after they have been pushed to production.
The common perception of cybersecurity is that you need to sacrifice some of your operational velocity when introducing necessary security checkpoints. We at SSH.COM don’t quite agree.
What if you could:
- centralize and unify access to all critical targets and provide a solid audit trail of activities while ensuring just enough or least privilege for each session?
- mitigate the risks of always-on privileges and rogue secrets with just-in-time access that ensures there are no leave-behind credentials and that operates without risky passwords or credentials altogether?
- vault secrets if the target systems does not support just-in-time (based on, ephemeral certificates)
- accelerate your operations with an easy-to-use single sign-on (SSO) solution that automatically discovers your cloud assets and gives your DevOps engineers an always-up-to-date list of accessible targets but restricts their access per role?
- onboard application-to-application (A2A) and machine-to-machine (M2M) secrets into a vault to increase the security of your automated data transfers?
Our PrivX, lean and scalable secure access management solution, can do that all for you and is therefore a great fit for DevOps driven IT. It is purpose-built for multi-cloud and multi-target environments and to meet the scalability and automation requirements of DevOps. It ensures that DevOps engineers can't and don't need to handle any credentials or SSH keys when accessing code repositories such as GitHub.
PrivX makes sure that your users never handle or see any secrets needed to establish the connection. and in many cases, ensures that those secrets disappear after the authorization is done. This means that no risky credentials are left behind in your critical IT infrastructure and that there is no need to manage them at all.
Also, PrivX Secrets Vault guarantees you can vault those secrets that you need to and at the same provide a path to reducing the number of secrets you manage
What’s best, the deployment time is measured in days instead of months for great Return on Investment (ROI). Learn more about a customer who deployed PrivX in just three days!
I also recommend you take a look the white paper by KuppingerCole on what type of a secure remote access solution is a good fit for agile and multi-cloud DevOps environments.
