By 1992 monitoring of network traffic for attacks, referred to by the Department of Justice as “keystroke monitoring” was starting to gain traction. This letter, by the now Director of the FBI, raises the concern that this may be a criminal act and recommends actions to reduce the chance that network administrators could face charges.

From 1990 to 1992 UC Davis, Haystack Labs, and Lawrence Livermore National Laboratory (LLNL) worked on the Distributed Intrusion Detection System (DIDS). We handed it off to the United States Air Force (USAF), which funded the work. The USAF planned to roll it out across the entire Air Force network. They hired Trident Data Systems (TDS) to "productize" our prototype and support the roll out. Eventually the network monitoring portion (my NSM) and a centralized Director was rebranded ASIM and rolled out Air Force wide. As far as I know, the ASIM sensor grid was the first global-scale intrusion detection system. This document shows some screenshots of DIDS at about the midpoint of its development.

Google's software update system can serve as a model Advanced Persistent Threat (APT). APTs often embed programs in a penetrated system. These programs wake up from time to time, call home, download additional programs and instructions to carry out, and modify systems. Google's software update performs all these steps too. Furthermore, because the Google Chrome browser is so widely used and updated so frequently, Google's update process provides analysts ample opportunity to test their data sources, tools, and skills for their ability to detect and reconstruct the "attack". The paper "The Advanced Persistent Threat You Have: Google Chrome" made the claim that if the analyst could not perform the analysis of Google's update system, they were probably not prepared for malicious APTs. The paper then provided a partial reconstruction of the update activity. This paper describes how the analysis in that first paper was performed. It describes the computer system, data collection, and analysis tool. It then shows how the tool and data were used to reconstruct the "attack".

The Advanced Persistent Threat (APT) has become the watchword for cyber espionage damaging our national and economic security. Do you have APTs inside your organization right now? How can you be confident of your answer? I argue that you probably already have a "benign APT" inside your organization, and your ability to detect, analyze, and understand this benign APT's actions will tell you whether you have a chance to do the same for malicious APTs. That benign APT is Google's software update system. I pose key questions that your organization should be able to answer about this activity. I present a summary of my findings and a somewhat detailed analysis of Google's update activity. To determine if your organization is prepared for a modern threat, you should consider a similar exercise with the data you currently collect and the tools you use to analyze that data. If you fail with the Google APT, you will probably fail with a real APT.

Windows 7’s auditing system can provide a rich source of information to detect and analyze a wide range of threats against computer systems. Unfortunately few people know this auditing system exists much less how to turn it on and configure it. This paper provides step-by-step instructions to configure a simple audit policy useful for understanding how data was exfiltrated from the computer.

In 1987 Dorothy Denning wrote in her seminal paper "An Intrusion-Detection Model" the following words: "exploitation of a system's vulnerabilities involves abnormal use of the system; therefore, security violations could be detected from abnormal patterns of usage." With these words, Denning kicked off 20 years of research, development, and publications in anomaly-based intrusion detection, where systems build statistical profiles of normal usage patterns and detect variations from those profiles. Unfortunately, the statistics behind statistical-based detection can lead to some unintuitive results, from surprisingly high numbers of false alarms to the potential of making a site less secure. This paper highlights some of the problems, causes, and implications anomaly-based detection.

This report describes our findings and recommendations for the Department of Energy's (DOE) CPP defensive cyber security operations. The source for our information included interviews with Lawrence Livermore National Laboratory (LLNL) Computer Incident Advisory Capability (CIAC) personnel, unclassified documentation provided by CIAC, and information retrieved from the web. Our focus was on defensive cyber security and not on offensive operations or counterintelligence.

In the paper "Why Anomaly Detection Sucks" we looked at an alert to an unexpected event (an anomaly) on one of our systems. To our frustration, we could not identify the underlying cause of the event, and we were left with many lost hours and a very uncomfortable feeling that something might be wrong but we could do nothing about it. This report follows our continuing quest to identify the underlying cause of the alert. Having exhausted the leads using the original alert, we set up a system to allow the apparent attack to continue. This activity led us back search for new evidence on the original host - some dating back a year and a half. Eventually we traced down the cause of the alert, and it was not from any attack.

The techniques used by intrusion detection systems are often described as signature-based or anomaly-based. In this overly simplified view, signature-based techniques detect specific and known attacks or attacks against known vulnerabilities, and anomaly-based techniques detect unexpected activity (presumably an intrusion would be unusual). Anomaly-based detection generally has a longer history and has had more extensive government sponsored funding than signature-based detection. Anomaly-based techniques also hold the promise of detecting a wider range of misuse than signature-based based techniques, including misuse by insiders that do not exploit any vulnerabilities and previously unknown attacks against unknown vulnerabilities. However, despite these apparent advantages that anomaly-based techniques have over signature-based techniques, signature-based techniques have enjoyed considerably more operational success than anomaly techniques. This paper addresses, in part, why this is the case through a real-world example we had to endure.

As originally envisioned, the Environment Aware Security project would consume detailed information about a network (e.g., vulnerabilities and topology) and a (potentially hypothetical) adversary's capability and produce (1) a set of systems that can be penetrated by the adversary and (2) a prioritized list of changes to the network (e.g., patches to specific systems) to maximally disrupt the adversary's ability to move through the network. The prioritized list of changes, referred to as Network Tasking Orders (NTOs), was envisioned as the primary way network and system administrators would interact with the system. This document describes the future directions for the ARDA sponsored Environment Aware Security project.