Friday, July 31, 2009

Reasonable Belief - Depth of Penetration

This is a v.1 figure. Comments, suggestions welcome.

Back in March I began with a high level overview of reasonable belief as it applies to intrusions and notification. I'd like to take a little time to examine the Depth of Penetration as it applies to reasonable belief to see where I end up.

First some criteria.

Depth of Penetration can be simply defined as: The scope of access to resources gained by an intruder.

Major questions to answer:

What account(s) were compromised?
What level of privilege does the account have?
What systems were accessed during the Window of Risk?
What data is the account authorized to access?
What data are at risk?

We also collect system meta-information. This includes:
Who has administrative rights
Who has access to it
What role the system holds in the organization
Where the system is accessible from
What IP address it uses

The objective in establishing depth of penetration is to determine what the intruder compromised, had access to, and the level of privilege obtained.

When a system or network is penetrated by an attacker, an account is involved, even if the account is an anonymous or guest account. If the account is used by an attacker, it is considered compromised. This account will be authorized to access specific resources within a network or system. The intruder will therefore have credentials to access systems and data.

Can a domain or local system account be compromised, and not have resource accounts compromised? Yes. Let's say my local system gets hacked in to and my domain login is compromised. I also have accounts on an ftp server, a web server, a database server, and email. When my domain account is compromised, it does not mean that the other accounts were compromised. If my domain account is compromised, we need to establish the authentication and authorization methods used on each of the resource systems. If the AAA is integrated with the domain, then the attacker will potentially have cart blanch access to all of the resources and data that I have access to. If AAA is not domain integrated, then An investigation in to each of the resources I have access to is required to determine the veracity of the claim that other accounts/resources and data are at risk. This establishes scope.

Suppose a keylogger were installed on my machine. Does that mean that all of my resource accounts were compromised? Again, that's not necessarily true. We can assume the worst and say that everything I have access to is compromised because there was a keylogger on the system. We can also go the route of - whatever is in the keylog file is what was compromised. Which is correct? In reality, neither is true and neither is wrong. The only way to truly determine the correct path here is to examine the keylogger and it's logging mechanisms. Does it write to a buffer and mail it out? Does it log it to a file? Is the file encrypted? Can you decrypt it? This also puts too much emphasis on the keylogger. An examination of other artifacts is required to validate any conclusions drawn from a keylogger examination.

In a third scenario, let's say a system is compromised and a packet sniffer is installed. The depth of the penetration can be difficult to establish in this scenario because many organizations do not log internal network traffic. We must determine what data travelled to/from the system, or was sniffable by the system.

In a fourth example, consider that I am a user working from a desktop machine. I have no privileges beyond an authenticated and valid user account. I am in other words, a "regular user". I visit a website and contract a malware infection. This malware provides remote control over my system, and does not require administrative privileges. The system is now "botted". The person, assuming there is one, at the other end of the connection now has access to whatever I have access to, and may be able to escalate privileges. In this scenario we need to determine if the attacker escalated privilege, and to what degree. In addition we must examine what actions I took while infected; What intranet sites were visited, what systems did I log in to or access? What data did I work with or access during the compromise window? What data did my account have access to?

These examples are slight digressions from the singular topic of Depth of Penetration, but they are important to establishing the actual depth of the penetration.

How does Depth of Penetration actually inform reasonable belief?
Remember that Reasonable Belief is what a layperson believes given similar circumstances. A decision maker is more likely to believe that data is at risk and/or compromised when there is no hard evidence to confirm or refute the data loss if the intruder gained access to a resource with the authorization to read the data stored therein. In the eyes of the layperson, access often equals acquisition. When an attacker gains elevated privileges on a system containing sensitive data, a layperson will inherently lean towards a reasonable belief that the data was acquired. Conversely, a layperson will be less likely to believe data was acquired if elevated privileges were not obtained, even if the compromised account had direct access to sensitive data. In addition, a layperson tends to think less is at risk when a compromise affects one system than they do of a critical or multiple system compromise. These beliefs are commonly strengthened if the examination lacks depth and does not provide a more plausible explanation.

To be effective, this portion of the examination must be able to show in enough detail the accounts used by the intruder;which systems were compromised or used by the intruder;what level of privilege each account had on each system accessed by the intruder;If the account was able to access and/or acquire the data from each system;What data was present.