From agile to fragile: Is DevOps the weak link in your cloud security strategy?

If organisations are not careful, pressures imposed on DevOps teams can compromise application and data security in cloud environments, writes Haim Zelikovsky

In the next three years, public, private and hybrid cloud adoption will drive roughly 25 percent of the growth in the software as a service ‘SaaS’ market. Without the cloud, SaaS can’t mature – and without SaaS, companies won’t reap the rewards that the cloud offers. But as the variety of SaaS apps in organisations’ cloud footprints rises, they need to be aware of the risks.

Securing SaaS

Data and application security is one of the most commonly cited concerns when it comes to cloud deployment, to the extent that three in every five c-level execs say they are concerned about vulnerabilities in their cloud environment. A third report applications being attacked on a daily or even hourly basis.

SaaS-based web, mobile, or custom-made apps all work on different platforms, making frameworks difficult to secure. It’s hard managing all the APIs needed to automate and sync tools, which is of course where the risk comes from. The greater the number of apps, the broader the attack surface and, therefore, the more vulnerable organisations become.

And as we know from the constant stream of phone updates we receive from service providers, applications are always changing. Keeping up to date with evolving security policies is never easy, but is especially hard in a large cloud environment. Yet, failure to adopt changes puts the organisation and customers at further risk.

DevOps

It’s not just technology that complicates cloud security. Two thirds of execs say the reason they are facing so many security risks is because of sloppy credentials management in DevOps environments.

According to recent Radware research, the most common cause of unauthorised access to cloud assets is when employees neglect credentials in public development forums. Employees also often leave the door open to hackers, due to configuration errors or by granting access to employees who practice low security hygiene.

Agile or fragile?

We’ve arrived at a situation where cloud environments make it very easy to grant access permissions yet very difficult to keep track of who has them.

Much of this has to do with the demands of business, and in particular satisfying customer demand, maintaining loyalty and retaining and growing market share. With customer demands constantly changing and expectations always growing, so development teams are continually under pressure to quickly roll out new enhancements.

Probably most concerning is that bad practice creeps in over time. The gap between the permissions that users have and the permissions that they actually need (and use) start to separate and it becomes a significant crack in the organisation’s security posture.

This promiscuous distribution and management of permissions leaves workloads vulnerable to data theft and resource exploitation. Should any users who have access permissions become compromised, you have a major incident on your hands. As a result, misconfiguration of access permissions, that is, giving permissions to too many people and/or granting permissions that are overly generous, becomes the most urgent security threat that organisations need to address in public cloud environments.

It’s not something that CIOs will have considered when they first developed their cloud environment and the migration to it. And really why would they? They will have been preoccupied with saving money, helping the company become a digital pioneer, and improving operational efficiency. How permissions were managed will have been way down on the list of priorities.

Wake up call

But as time has moved on so too have priorities changed. Until now many of the ‘textbooks’ on managing security in cloud environments will have focused on four things:

1. The new external threat of bots that are scraping sites for user data, pricing info, product data and to skew marketing metrics.
2. Securing APIs associated to the role out IoT devices across the network
3. Maintaining the effort on Denial of Service. It just won’t go away
4. And what I’ll refer to as continuous security, that is ensuring agility isn’t done at the expense of security.

But now we must add a fifth to underpin the notion of continuous security. We’re not talking about machine learning and AI alone. Now we are talking about managing human error, managing and reviewing permissions, and managing the process for their use.

This really has to be a process of optimising security in real-time. The arguments for doing it are strong. It costs hard cash when you suffer a breach. In fact, on average a breach costs £4.6mn. But more worryingly it costs $100,000 to win back a customer, and it’s likely you’ll suffer a customer churn rate of 30 percent. There’s no room for that sort of loss in today’s economy.

C-change

But there is good news for anyone responsible for addressing the security problems affecting DevOps. Namely, the board is now actively talking security. In fact, execs now say they spend half their time thinking about security. It almost always brought up at board meetings.

And such is the appreciation of the risks, that security has become a marketing message. Approximately half of companies are now offering dedicated security products and services to their customers, and around 40 percent are offering security features as add-ons.

That has to be a sign that measures you take to close the security gaps will be supported, and your case for investment and reviews will be listened to. And frankly it has to be, as the more IoT we adopt, and the more applications we add to the cloud, the more notions of secure banking or shopping are undermined.