(upbeat music)
- Incident response
is one of the most critical areas of information security,
whether for incidents occurring in traditional platforms
or cloud services.
Despite all the best laid plans
and all the effort invested in security systems,
the possibility of an incident of some sort occurring
can't be totally eliminated.
The National Institute of Standards and Technology
has published a standard for incident response frameworks
called Special Publication 800-61.
While incidents affecting cloud services
can be mapped to the standard,
some gaps exist due to the unique characteristics
of the cloud.
These gaps are covered in domain nine
of the cloud security associations guidance.
Unfortunately, there are plenty of challenges
when conducting incident response on cloud services.
The commodity nature of cloud,
means that it can be difficult or impossible
to get support from a cloud service provider
in responding to an incident.
SLS typically don't cover incident response support,
addressing only service fee refund claims.
Resource pooling and elasticity may substantially
complicate the technical activities of incident response
and forensics.
Maintaining stability and integrity of evidence
when it exists on a shared and still operational
infrastructure, can be extremely challenging.
Resource pooling also causes privacy concerns
for co-tenants.
When collecting incident evidence such as logging,
NetFlow data, physical machine images, and so on.
This can be addressed through filtering out
co-tenant information,
but that filtering has to be done through a forensically
acceptable process.
In the cloud, data can cross jurisdictional boundaries
without the cloud customer being aware.
The legal implications of trans jurisdictional
investigations, can affect what evidence can be recovered
and the extent to which incident response can be effective.
The nest incident response model has four stages,
preparation, detection and analysis, containment
and eradication and recovery.
These stages flow from one to another,
with some cycling back as the incident progresses,
and with learnings being used to refine preparation plans.
There are four significant considerations
in preparing for cloud deployment incident response.
When designing processes to implement,
the NIST incident response model,
it's important to ensure that the location of cloud data
is taken into account.
This will have a significant bearing on how investigations
and response processes work.
The level of support available from the service provider
in the event of an issue,
will be an important consideration for incident response.
If the incident is a major cloud issue,
then the service provider
will be driving their own response,
including some level of communication with customers.
If it's a customer issue,
then the service provider may not be involved at all.
Threat intelligence is an important source of information
prior to any incident due to malicious activity.
It can help avoid incidents,
and can help more quickly identify the cause of incidents
that do occur.
It's important to establish ongoing access to a data feed
of indicators of compromise.
The structured threat intelligence
and trusted exchange standards STIX taxii,
are commonly used for this.
The most important part of the preparation stage, however,
is testing the incident response process and plan.
And the initial exercises can be expected to flush out
a number of issues with cloud services.
Running cyber instant response exercises,
will help refine and mature process.
Timely detection has a fairly direct relationship
to minimizing the impact of an incident.
There are a number of issues that need to be considered
when designing and operating the incident detection
and analysis subsystem.
Incident detection is based on log data,
typically from the enterprise perimeter.
In the case of cloud deployments,
the source and availability of log data
needs to be identifying.
The consistency of data also needs to be managed,
particularly around timestamps.
Both physical and virtual cloud components may change.
And this can introduce data inconsistencies.
It's also important to ensure the correct interpretation
of cloud sourced log data.
Log retention and availability for analysis
also needs to be considered
given the ability of advanced malware,
to exist for considerable periods of time
before being detected.
Forensics will be difficult.
Customer might as well not be able to carry out
traditional hands-on forensics on cloud infrastructure.
And any requirement for forensics,
will be limited to the terms and conditions
in service agreements.
In June, 2014, NIST released the draft NISTIR 8006.
NIST cloud computing, forensic science challenges.
This publication lists 65 problems
covering lack of control over,
and reduced visibility into the infrastructure,
difficulties in assessing and aggregating logs.
Hypervisor incompatibilities,
the difficulty in establishing and validating the forensic
soundness of what can be collected,
encrypted data and issues around preservation.
Containment of attacks in cloud environments,
requires evolution of traditional containment methods.
Containing an attack on a cloud target
can be more effective and manageable,
when leveraging native capabilities
provided by a cloud service provider.
Network access controls between virtual networks
or subnets within those virtual networks,
protect and contain East-West traffic
within a cloud network infrastructure.
Josh Payne's deep cloud security research project,
has looked at various aspects of responding to malware
in the cloud environment.
And a visionary strategy
could be to provide a containment mechanism
using blockchain.
In terms of eradication and recovery,
refreshing virtual machines is a significant benefit
of the virtualized environments using clouds.