Sunday 6 November 2016

Cloud Security

One way in which cloud security differs from previous generations of security efforts, such as software security and website security, is that in the past, both software and website security were almost business disablers. The more features and the more security people added, the less attractive the product became. There are very few applications and websites that make the client need more security to do more business, which results in the best return on investment.

What’s interesting about cloud security is that it might be one of the occasions where security is a business requirement, because a lack of security would slow down the adoption rate and prevent people from moving into the cloud. Accordingly, people care about cloud security, and they invest in it.

While thinking about this I realized that the problem with security vulnerabilities in the cloud is that any compromise doesn’t just affect one company, it affects all the companies hosted in the cloud. It’s a much bigger problem than the traditional scenario, where security incidents resulted in one company being affected, and the people in that company worked to resolve the problem. When an incident happens in the cloud, the companies or assets affected are not under the control of their owners. The people hosting them must now manage all these external parties, who don’t have any control over their data, but who can’t work because their service is down or compromised. The problem is horizontal; a Company A-driven attack will affect Companies B, C, D, E, F, all the way to X, Y, Z. As a result, it’s a much tougher problem to solve.

While catastrophic failures are tolerated in normal websites and applications, cloud-based worlds are much less tolerant. A catastrophic failure, where everything fails or all the data is compromised or removed, means the potential loss of that business. That hasn’t happened yet, but doubtless it will happen. Cloud service companies will then have to show that they care more about security than the people who own the data.

Cloud providers care more than you

One of the concepts that Bruce Schneier talked about at the OWASP IBWAS conference in Spain is that a cloud service cares more about the security of their customers than the customer does. This makes sense since their risk is enormous.

In the future, cloud companies will be required to demonstrate this important concept. They should be able to say, “Look, I have better systems in place than you, so you can trust me with your data. I can manage more data for you than you can”. This will be akin to the regulatory compliance that handles data in the outside world.

One way to do this is with publishing of RISK data and dashboards (see OWASP Security Labelling System Project).

You can imagine a credit card company wanting or needing to demonstrate this. But you can also see the value of it to the medical industry, or any kind of industry that holds personal information. If a company can't provide this type of service it must outsource the service, but to be able to do that the security industry must become more transparent. We need a lot more maturity in our industry, because companies need to show that they have adequate security controls. It is not sufficient to be declared compliant by somebody who goes for the lowest common denominator, gets paid, and tells the company it's compliant.

Genuinely enhanced visibility of what’s going on will allow people to measure what’s happening, and then make decisions based on that information. The proof of the pudding will not be how many vulnerabilities the cloud companies have, but how they recover from incidents.

The better a company can sustain an attack, the better that company can protect data. A company who says, “I received x, y, z number of attacks and I was able to sustain them and protect them this way” is more trustworthy than the company that is completely opaque. The key to making this work is to create either technology, or standards of process, that increase the visibility of what is going on.


(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)