Modeling Reality: In to the Breach

Erik Anderson (2)

From the Developers Desk, by Erik Anderson


Modeling Reality is a series of blog posts describing how real world scenarios are modeled by our software. This is the third installment.

The past two weeks we’ve talked about vulnerabilities and attacks. When these come together, the result is a breach. The lifecycle of a breach is shown below.breach

For our purposes, a breach occurs when an attacker gains access to a target that we have identified in our business operation model. Potential targets generally consist of confidential customer data, intellectual property, or similarly valuable information. Gaining target access is not always as simple as just breaking into the operation; the attacker may have to chain together multiple vulnerabilities to get from their entry point to their target. In order to cause a breach, the attacker must successfully breach each vulnerability in the chain, the probability of which is determined by a rating of the attacker’s skill. Consequently, each additional vulnerability required reduces the likelihood that the attack is successful, meaning shorter chains are prioritized over longer ones. We do this by using a reverse-off-target approach, starting at the target and working outward, which allows for a more directed search of the possible routes of attack.


The time required to detect a breach depends on the type or types of detectors in place in a business operation as well as the governing policies of the operation. Our model analyzes a wide range of detector types, including intrusion prevention systems, line of sight detectors, and over the horizon detectors. The operation’s policies affect the likelihood of detection. Various types of anomalous activity may trigger a detector. Detectors may require one or several trigger events before flagging a breach. Our system also models the occurrence of false positive detection events.


Once a detector flags a breach, human validation is required to determine the appropriate response: remediating a true positive or ignoring a false positive. This may consist of an alert asking the user of the affected computer to identify the source of suspicious activity, or a notification sent directly to a system administrator for further investigation. If a breach is incorrectly identified as a false positive, the breach returns to the detection phase. Otherwise, remediation can begin.


Remediation requires the identification and repair of the sources of a breach, including patching vulnerable software, eliminating invalid user credentials, changing stolen passwords, cleaning up malware, and removing any backdoors the attacker may have installed. Once remediation occurs, the attacker will attempt to reestablish a foothold. Failure to completely remediate the breach may allow the attacker to regain access, returning the breach to the detection phase.

Comments are closed. Posted by: on

Tags: , , ,