Last updated: 
2 weeks 6 days ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Cloud Incident Response and Security

Tuesday, December 11, 2012 - 11:19

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.