IT and cybersecurity leaders have come to agree that the purpose and intent of DevSecOps is to create a mindset that “everyone is responsible for security,” while also incorporating application and infrastructure security directly into the software development and delivery process. DevSecOps has proven to be a critical ideology for cybersecurity, yet is littered with false starts and failures. Many of those failures can be attributed to a basic misunderstanding, wherein IT management has come to use the terms DevSecOps and DevOps interchangeably, because of the false belief that security is already part of the DevOps process.
A recent CyberArk DevOps Survey polled respondents to determine if DevOps and security teams were integrated, less than half of the respondents said yes. Whatโs more, almost three-quarters said they had no privileged account security strategy for DevOps and some 99% failed to identify all of the different places privileged accounts or secrets could exist in a DevOps environment. The survey demonstrates that common and well-established security practices have not been adopted by DevOps teams. Clearly, DevOps and DevSecOps are not synonymous.
A clear vision of what DevSecOps should be about can lead to DevOps teams releasing vulnerable software and exposing enterprises to unnecessary riskโa problem that has been manifesting itself in the rush to embrace digital transformation and re-engineer legacy apps into cloud-based equivalents. Expediency combined with a lack of understanding increases risk, which should cause alarm.
For the most part, breaches occur because of a lack of privilege management, In other words, proper security practices dictate the who, how and when of access, along with the permissions associated with that access. It is a concept that has given birth to platforms that manage privileges, also known as privileged access management (PAM) solutions. For DevSecOps to succeed, the concept of privilege must be embraced. However there is more to security than just privilege management; namely, the context of privilege must be incorporated, such as the โwhy,โ โwhen,โ and โwhereโ of access.
Simply put, administrators and managers often forget to revoke the rights of temporary workers, contractors and other non-employees when a project is complete. It’s an issue that plagues many DevOps teams that rely on freelancers to help move the processes forward. The lesson here is one of instituting better controls and policies, which ultimately can be adopted throughout the enterprise to bring better cybersecurity to fruition.
JIT PAM to the DevSecOps Rescue?
Better control over privileges has created a new acronym, JIT (just in time), that takes residence in front of the PAM acronym. The concept of JIT PAM, which is being promoted by security vendors such as Beyond Trust, is one of controlling access based upon a number of different policies that are further enhanced with behavioral data.
At the recent Beyond Trust partner summit, cybersecurity expert Derek Smith noted, โPrivileged credentials exist everywhere and 100% of all advanced attacks rely on exploits of privileged credentials.โ That’s a sobering thought for those in charge of cybersecurity and those who are part of the DevSecOps process. Smith said some of the best practices around PAM include, โTrack and secure, govern and control, and record and audit,โ exemplifying the need for a platform approach. For Beyond Trust, that means creating a platform that defines a new paradigm of trust, one that builds policy around the who,what,why,where,when of access.
The concept offers valuable lessons to DevSecOps team members, lessons that entail incorporating the proper security elements into the application and infrastructure layers of service delivery. For the short term, those capabilities may be beyond those in the DevOps arena, meaning that they may have to turn to third-party platforms to bring forth better security. On the plus side, JIT PAM can also be used to secure legacy applications, giving DevSecOps teams more breathing room to define and re-engineer those legacy applications as they transition to the cloud.
โ Frank Ohlhorst
