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