Thursday, September 12, 2013

CCSK Study: Domain 9 - Incident Response

  • Self-Service nature of cloud may make CSPs unwilling to corporate to the extent required during an IR
  • Dynamic pooling may complicate the IR process when it comes to things like forensics
  • Resource pooling may cause privacy issues (for other cloud tenants)
    • Technical challenge that should be addressed primarily by the provider
  • Data may cross jurisdictional boundaries which can complicate the IR process
    • Tasks may be prescribed by legislation
    • Tasks may be prohibited by legislation
    • Need legal staff on the IR team
  • Eradication and recovery steps may be sped up due to the nature of how systems are provisioned in the cloud
  • Some investigations can be sped up
    • VMs can be moved to local resources for analysis
    • VMs can be paused to preserve memory
  • Different cloud architectures pose different problems to IR teams/process
    • Consider the visibility and control a customer has in each cloud scenario (IaaS,PaaS,SaaS)
    • Even in IaaS there are various aspects of the infrastructure that the customer does not control
      • How do you get logs/data from those sources
  • IR LifeCycle (NIST Version)
    • Preparation
      • Most important phase (regardless of cloud or not, really)
      • Make sure both the physical and logical data flows are mapped out
      • Establish SLA with CSP
        • points of contact
          • and HOW to contact (out-of-band, etc)
        • incident definitions and criteria
        • CSPs support (available event data, notifications, etc)
        • definitions of roles and responsibilities
        • IR Testing (if allowed)
        • Scope of post-mortem activities
      • Agree on format of data exchange
        • IODEF
        • RID
    • Detection and Analysis
      • timely detection depends on availability of the data and the ability to correctly interpret that data
      • data may come from non-transparent, provider-owned infrastructure
      • Key point:  Customers must make sure they have access to the relevant data
        • What information should be logged
        • How are the logs stored (tamper-proof) and proven that they are consistent and complete?
        • Logs should take into account the dynamic nature of the logged information
          • Is the time on the servers correct?
          • Are you getting logs from all components and can you put that together properly?
        •  Log retention settings?
        • What log format is being used?
          • CSS quoted but has since been abandoned
      • SLA should require CSP to provide notification of any breach detection of provider-hosted infrastructure / services
      • Forensic capabilities
        • Still an area under research (especially for SaaS and PaaS)
        • Customers should try and pick vendors that have forensic capabilities built in
    • Containment, Eradication, Recovery
      • Depending on deployment scenario, some tasks (such as eradication, recovery) can be made easy
        • IaaS: shutdown node, restore from snapshot, etc
      • SLA should include a "lessons learned" activity after the recovery
  • Recommendations
    • A clear understanding of how a CSP defines events vs incidents
    • CSP and customer should agree on communication channels
    • Customers must understand a CSPs role/support for IR
    • IaaS customers should leverage virtualization offers for forensic analysis and IR
    • CSP should be included in the design phase for an IR
  • Requirements
    • eIRP should include the approach for detecting and handling incidents involving a CSP
    • SLA must guarantee support for incident handling
    • Yearly testing


I think this domain touches on some key points.  Although, as a customer, you want to utilize a CSPs resources, you must understand what impact that will have in your ability to respond to a breach.  One interesting situation would involve the policy to "disclose" that a breach has occurred.  A customer and CSP may disagree on the best way to handle this and this could cause an embarrassment for one party.  This domain stresses that the SLA should be well defined and discussed, and I think is an important step that is missed during most conversations.

Capturing data from sources in the cloud can pose another problem.  One must consider the costs of first collecting the data (processing, storage, memory) and then the cost of transmitting that data to the corporate office for analysis.  What if you are also doing Security-as-a-Service?  The more abstract you get (PaaS, SaaS) will make this task even more difficult as now you are relying on the logs the provider has given you access to.

As stated in the domain, the technical solutions to the technical problems are still up in the air.  A balance needs to be found in the cost for any given solution and the benefit received from that. 

No comments:

Post a Comment