Cloud Incident Response and Security

Cloud computing was the theme of the day at the FIRST conference, with talks on security and incident response both concluding that we may need to re-learn old techniques. The adoption of at least some form of “cloud” seems to be inevitable, so we need to understand how to do this with an acceptable level of risk. Unfortunately assessing the risk requires both an understanding of the criticality of data and processes and knowledge of the security measures implemented by the cloud provider; one or both of these may be missing. Clouds are not inherently more or less secure than in-house physical machines: indeed the list of problems looks depressingly familiar – security by obscurity, lack of standards, lock-in, downtime, information leakage, application and platform vulnerabilities, power failures and burglary. These may be either increased or decreased by sharing infrastructure with a large number of other, unknown, parties.

Incident detection and response on traditional computers has increasingly focused on monitoring network traffic, but “network traffic” between cloud virtual machines may never leave memory and even if it does, the physical networks are monitored by a cloud provider with no way to distinguish a denial of service attack from a successful product launch! For the same reason logs from the cloud platform, even if they are available from the hosting provider, are likely to be very hard to interpret. Applications written for clouds therefore need to do their own logging, where possible to external storage since an attack may well result in the virtual machine and its data disappearing without trace. Incident response teams should work with application developers to ensure that relevant information is logged and preserved; ideally each application should have its own Security Response Plan covering logging, incident response tools, access management, fix deployment and escalation. In some cases traditional incident response tools may work on cloud platforms, but teams need to know which will give reliable results and practice using them before they are needed in an emergency.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *