Many businesses are still transitioning to a development operations (DevOps) style of service development injecting security into the process from the beginning will save heartache later, a security expert has advised as a new study finds most companies aren’t implementing even basic security protections within their DevOps processes.
Fully 75 percent of the firms involved in CyberArk’s Global Advanced Threat Landscape Survey 2018 said they had not implemented a tool for managing privileged accounts during the DevOps process.
Twice as many said they had implemented privileged-account practices for cloud platforms, while 61 percent had done so for laptops and PCs. This disparity highlighted the relative lack of priority for DevOps security: “DevOps personnel may not be thinking about security because they – perhaps rightly – don’t consider it their ultimate responsibility,” the report’s authors noted. “Unfortunately, threat actors do make these connections.”
Many of those implementing security practices had developed ad-hoc methods for security, with 37 percent adopting an open-source option and 22 percent saying they had built their own.
Processes and procedures around security were equally erratic, with just 46 percent saying they integrated security teams and processes throughout the application development process. By contrast, 43 percent said security teams were always brought in at the end of each development cycle, and 10 percent said the security team is “mostly” brought in at the end of each development cycle.
Bringing in security teams late in the development cycle exacerbates the divide between DevOps and security, ultimately compromising the shift towards SecDevOps. And this, APJ senior director of solution engineering Jeffrey Kok told CSO Australia, is one of the key areas that companies should focus on to improve – by making SecDevOps more user-friendly.
“There is a common misconception that the moment the security person comes into the room, everything stops or slows down,” Kok explains. “The security person is always seen as the inhibitor who wants to disrupt everybody – but it doesn’t have to be so. If you can have proper education within the team – and have people understand how security can play a better part – you’re going to have a better security experience by bringing the security person into the conversation right at the beginning.”
The move towards better SecDevOps practices is likely to have implications not only on the security of internal software, but as a tool for demonstrating security compliance to business partners. This will become increasingly critical as organisations look to shore up the protections at third-party suppliers just as they do internally – a concern echoed within NAVEX Global’s 2017 Ethics & Compliance Third-Party Risk Management Benchmark Report, which found that cyber security was more concerning in evaluating third-party risk – named by 49 percent of respondents – than bribery and corruption (42 percent), conflicts of interest (34 percent), and fraud (31 percent).
“Cyber security and the risk of losing critical customer, financial and other private company data is a legitimate top concern,” the report notes, “perhaps exacerbated by recent headlines that showed secure organisational cyber defences hacked and defeated through security holes at trusted third parties.”
If those security holes emerge as the result of inadequate security within DevOps practices, the implications could be significant – particularly in the context of onerous new Notifiable Data Breach (NDB) and EU General Data Protection Regulation (GDPR) regulations set to come into effect next year.
Such regulations, as well as the greater overall recognition of cybersecurity risk, are helping drive an “awakening” amongst businesses, CyberArk’s Kok said. “Most of the time it is a matter of awareness, and a lot of them stumble into an a-ha moment because they didn’t know a better way to do it. But now they’re recognising that they need to seriously think about how to handle security within DevOps.”
As well as improving the experience of interacting with security specialists, Kok recommends that companies undertake three broad measures to foster tighter integration of security discipline within DevOps.
These include using ephemeral secrets so that passwords, digital certificates, personally identifiable information or business ‘secrets’ aren’t embedded within code; ensuring there are no security ‘islands’ by using too many tools or inconsistent platforms that don’t extend across the landscape; and adopting a philosophy of having security as code.
“The moment you adopt security as code – just like you adopt a philosophy of infrastructure as code in DevOps – you have a security environment that leaves with the application,” Kok said. “And wherever that application goes, you can apply the control through revisions and multiple deployments. We already do that for infrastructure – but we just aren’t doing that for infrastructure today.”
A number of vendors have moved to help plug the SecDevOps gap with tools that support efforts to inculcate security into the DevOps process. Startup ShiftLeft, for one, recently debuted a tool that evaluates new code for vulnerabilities and injects tailored protection to minimise exposure. And Demisto recently partnered with tCell to link their security orchestration framework to the security of Web applications as they are developed. This approach – which emerges in the wake of recent findings that security staff were struggling to get out of ‘firefighting mode’ – provides better visibility into attacks as they happen, with the intention of allowing SecDevOps teams to more quickly identify and remediate security issues in newly developed code.
Upcoming Events:
Nov 28th @11am | CSO Live Webinar: You may have security under control - but is your business still at risk? -- Register Today
Nov 30th @11am | CSO Live Webinar: It's easy to protect yourself from ransomware - if you plan ahead- Register Today