piątek, 16 listopada 2012

An intelligence-driven, threat-focused …






The article starts with saying what does mean APT.  This type of threat is becoming more and more serious. As we have developed groups of methods and barriers for self-propagating viruses and other "automatic threat" we are facing a problem when it comes for Incident response for  Advance Persistent  Threat.  

"Advances in infrastructure management tools have enabled best practices of enterprise-wide patching and hardening, reducing the most easily accessible vulnerabilities in networked services. Yet APT actors continually demonstrate the capability to compromise systems by using advanced tools, customized malware, and “zero-day" exploits that anti-virus and patching cannot detect or mitigate. Responses to APT intrusions require an evolution in analysis, process, and technology; it is possible to anticipate and mitigate future intrusions based on knowledge of the threat."

Intrusion Kill Chain or Intrusion Scenario is simply process that is deployed by intruder. The article is presenting a lot of concepts and statements, how to think about incident response process basing on case studies of attacks.  Lockheed Martin is showing that we need to know how the attack looks like to know how to defend  against  APT. This is obvious, but when we  look at this approach… we will find out  that there is a great knowledge behind countless shortcuts and processes.  Really awesome article.
Basing on fantastic  work made by Richard Beitlich, I am presenting one of intrusion scenario (simplified version):



To sum up and describe the graph we are going through these stages :

     1.    Reconnaissance : all activity of scanning, vulnerability scanning, checking connectivity, what 
          system are we talking with, versions, patches, infrastructure.
     2.    Exploitation
     3.    Reinforcement: methods of leveraging our privileges on the owned machine, using methods  
    and tools to create backdoor, and our  “place” on the victim machine.
     4.    Verification : checking if we have easy access to the attacked machine, are we brining any
          alarms etc. 
     5.    Cyber crime : in this stage the attacker is performing his plan (theft, vandalism .etc)

Another scenario is presented by United States Department of Defense and called “Kill chain”. 

Quickly summarizing:

      1.    Reconnaissance
      2.    Weaponization
      3.    Delivery
      4.    Exploitation
      5.    Installation
      6.    C2
      7.    Actions

The second model is more detailed and “exploit” stage is divided into more specialized levels. Nevertheless both approaches and models show how does an attack looks like and what are the purposes of each stage. It is worth mentioning, that during intrusion, the attacker may use several different IPs – for example every stage with other source.  At the same time, different protocols, tools or even systems might be used. What I think is, that there are a variety of methods and ways of prevention. Here  discussing  the attack from a hacker point of view, we are finding several stages where we can use different type of protection. On the other hand – for  investigator, there are multitude places, factors that must be checked during intrusion detection process.  Sure, the human factor is always crucial in attacking or preventing or even investigating the crime scene. This cannot be still called cyber crime, but rather fight between “bad and good” guys and their skills.

czwartek, 15 listopada 2012

Open Source Solution and Documentation?

Guys, just quick reference to AlienVault solution and its resources.  Looking for some documentation related with subject of building Incident Response Process I found out that there are awesome articles delivered by this product!





OSSIM, the Open Source SIEM developed by AlienVault is good looking product with bunch of tools and great features. It's developers say :


"OSSIM provides all of the capabilities that a security professional needs from a SIEM offering, event collection, normalization, correlation and incident response - but it also does far more."

Possibly, I will review this solution on my own - hopefully writing some kind of review - , but today only passing links to documentation. "SIEM for ITIL-Mature Incident Response" divided into two great parts gives really good background for Incident Response process development. This can be find here and here

I really encourage all IT Security Pro's to read and understand!

poniedziałek, 12 listopada 2012

Investigate the Incident


The purpose of digital investigation is to determine the what, when, where, how, who and why related with the incident. In huge environment, with wide and complex infrastructure this stage can be divided into several layers or stages. Typically we can find this  phase splited into two steps : data  acquisition and data analysisGoing further we know that information can be considered on different layers. The first one can be described on low-level technical layer – connected with OOV hypothesis. OOV stands for order of volatility and can be simply called as data’s expected life span concept. This was introduced by Dan Farmer and  Wietse Venema in “Forensic Discovery”.

Physical data:
  Volatile information
        Non-volatile information

   

Volatile data is the data that will be over-written or vanish due to its nature and operation system behavior. This type of data can be found on registers, caches and main memory. What is more, information about network connections, processes is also volatile but its expected life span is a little bit longer that for main memory – just several seconds or minutes. This data cannot be found on forensic duplication. Non-volatile information can retain in memory even when machine is not powered. We are collecting all relevant information from a person or system that raised an alarm. This is another layer of information.

Incident information:
        Technical data
        Standard data

   

Let start from the second one. Non-technical (or other data)  can be understood as information taken from interviewed owners, administrators or simply witnesses involved somehow in incident.  This can be any reports, files, documentations, or filled form (initial response).

The technical data:
        Host-based evidence (later HBE)
        Network-based evidence (later NBE)

Host-based evidence

This is simply a collection of information gathered in Live incident response process. I can say that also memory-imaging (disk imaging) is part of live response – sure – one of its subtypes. I will be back to Live Incident response process later. Host based evidence is set of : logs, documents, files, records, network connections, routing tables, list of processes, libraries and so on. This is all that can be obtained from machine and not from network nodes that are nearby. 

There are several ways of HBE acquisition :
a)      Live Response
b)      Forensic Duplication

According to “Incident Response and Computer Forensics” written by Chris Prosise Kevin Mandia and Matt Pepe there are three types of live response:

                         Initial
    o   Take volatile data.
    o   Possibly acquire a forensic duplication.
                         In-depth
    o   Obtain volatile and non-volatile data.
    o   After scrutinizing it all, response strategy can be taken.
                         Full
    o   Obviously, we are acquiring everything from the suspected host/workstation.

The problem of cyber-crime and intrusion detection is constantly growing. There are thousands of possible threats and types of attacks. At the same time security and its Incident process response is evolving.

After initial information is presented, CSIRT is choosing the “right” steps. Types have been listed previously, but what can be said is that the hybrid method is always another type of response. We are looking for a clue information, and then following the path or choosing to acquire memory dump and check the evidence later.
Forensic duplication is obtained when we need to analyze what was going on victim/suspected machine. What files have been removed, hidden and basically all information that can be taken from file system.

I am presenting methods of windows data acquisition in another article.

Network-based evidence

What need to be remembered is  that incident response appears when the standard, or automatic security controls fails. We have tons of network/security appliances in our companies, tons of false-positive alerts and very often sophisticated malware or attack occurs and shows where do we have security gap.
NBE is the information that is gathered (or can be reactively) from network nodes such as routers, DNS servers, taps, hubs .etc. This is all packages that can be catched by any network device -  supporting standard formats.This is all information that can be found in network traffic. It allows confirming and determining whether incident occurred or not. In another words this is the type of data that is complementary to information obtained from live response – usually only  data  available. 

niedziela, 11 listopada 2012

Incident response strategy


... a little bit out of order with the first post, but this is what I will be referring to constantly. Here briefly introducing ways that CSIRT can react after the incident occurs. This is  fundamental and shortened model but will be developed over time and well described.

Choosing right strategy isn’t always easy. It depends how sufficient information do we have, what are the circumstances of incident, and  factors such as level of importance/risk connected with suspicious machine or other business aspects.

Incidents vary widely. Here you can find  first approach to list possible incident response strategies.

Incident Type
Examples
What to do?
Authentication Failures
-system recognizing consecutive failures made by functional/standard account
-account locked-out
-lack of access
SIEM logs correlation, creating report, supporting appropriate RA’s with data and logs. Escalating problem to another team – policy violations.
Authorization Failures
-using own machine for not-business purposes
-unacceptable use of IT resources
-policy violation(any)
-authority failures
Collecting evidence, contacting with user’s/owner’s manager to confirm whether the case is known, contacting user, launching CSIR, observing.
Malware
-machine infected by virus
-suspicious host behavior
Observation is required, launch memory-imaging, live response could be the quickest method, AV, vulnerability scanning, files removal, cleaning.
Out of service status
-host is not longer alive
-host is not registered
-host is not known
Escalating to other RA’s, sharing information with operational services, tracking.
Computer Intrusion
-workstation has been compromised
-leak of information
-buffer overflow attacks
-IT sabotage
Immediate data collection – getting to know what/who/why, Isolating machine, finding root-cause and information that had been lost, fixing, patching, recovering system.
Losing data integrity
-Issue on application or database level
Supporting operational services with all evidence, escalating
DoS attack
-DoS, DDoS
Immediate contact with support, confirm that this is not  false-positive

 What is obvious is that response strategy for each event will differ. There are numerous  methods of policy violation and possible ways to track intruder. We will be building concept of strategy response as a model, as a qucik reference and standard fundamental knowledge in this field.
The level of maturity of this model will be increasing over time. All methodology of incident response will be presented, step after step.