Tools −> FAAS −> Concept Paper
Free Audit Aggregation System
(FAAS)

Todd Heberlein

3 Oct 2012

This document summarizes the concept and goals of the Free Audit Aggregation System (FAAS), a system to help organizations on their road towards FISMA compliance1. FAAS provides the software (programs, scripts, configuration files, and DB schemas) to aggregate "audit data" in a batch mode model, let administrators browse the collection of logs, and let administrators download local copies of a particular log (e.g., for detailed analysis). "Audit data" can be any blob of data – BSM audit data, a tcpdump file, a security.evtx file, etc.
1 Introduction
FISMA, passed into law in 2002, requires Federal agencies to protect their computer systems and the Federal data they process. FISMA requires, in part, the agencies generate, protect, retain, and analyze audit data to look for signs of misuse as well as support incident response.
The Free Audit Aggregation System's (FAAS) goals are to support organizations in their efforts to comply with FISMA and to be generally helpful securing your systems. FAAS generates software (programs, scripts, configuration files, and database schemas) to aggregate audit data at a centralized server.
Initially, the target audit data is the BSM audit data generated by Mac OS X, but FAAS is data agnostic. The data that can be uploaded and managed by the FAAS server can be anything – BSM audit data, tcpdump data, Windows security.evtx files, etc.
FAAS is not designed to replace or compete with commercial Security Information and Event Management Systems (SIEMS). FAAS is a cheap (as in free) audit data aggregation tool. Additional analysis tools can be built on top of it.
This document provides the background on the need for something like FAAS, describes an initial design an for FAAS, lists the initial set of goals, and encourages people to provide feedback, including testing early iterations of the software..
2 FISMA
In 2002 Congress passed and the President signed into law the "Federal Information Security Management Act of 2002" (FISMA). FISMA, recognizing the importance of information security to the economic and national interests of the United States, requires each Federal agency to develop, document, and implement a program to protect Federal information and information systems. Outside organizations (i.e., contractors) that provide or operate information systems for Federal agencies or process Federal information are also required to follow this law.
FISMA triggered the creation of a cascading set of additional documents to implement the law. Figure 1 shows a partial family tree of these documents. FIPS 200 specifies the minimum security requirements to meet the security categories described in FIPS 199. SP 800-53 fleshed out the security controls necessary to meet the security requirements spelled out in FIPS 200.
The expert system running on the DIDS Director was responsible for mapping activity reported by each individual monitor (both network and host monitors) to the same NID. Then future messages of even the slightest suspiciousness reported by any of the sensors (e.g., a string in a network connection picked up by the network monitor or anomalous browsing behavior picked up by the host monitor) would be aggregated to the NID.

Figure 1: FISMA Family Tree
FIPS 200 specifies the minimum security requirements in 17 areas, including "Audit and Accountability" (AU). That requirement states
Organizations must:(i) create, protect, and retain information system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity; and (ii) ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions.
The goal of FAAS is to help meet this security requirement.
3 Audit and Accountability Security Controls Stack
NIST Special Publication (SP) 800-53 fleshes out the security requirements spelled out in FIPS 200 by identifying a list of security controls to meet each security requirement. SP 800-53 identifies 14 audit controls. Figure 2 provides a conceptual grouping of most of these audit controls along with a party responsible for each group. Each layer builds on the layer below it (think of it like a network protocol stack).
The first (and bottommost layer) is the responsibility of the organization's appropriate managers. They develop the audit policy and identify the auditable events they must collect in order to meet this policy.
The second layer is Apple's responsibility. Apple's BSM auditing system must generate the audit records, provide appropriate content in the audit records, timestamp the audit records, and protect those audit records (through appropriate permissions) while the data is on the host.
The third layer is where the FAAS server comes in. It provides additional protection for the audit data by storing it off the end systems that might be compromised. The server can provide the storage capacity to retain the audit data as necessary, so micromanaging storage requirements on a large number of end systems won't be necessary.
The fourth layer, which is not part of the FAAS system, consists of analysis tools to review, analyze, report on, and reduce the audit data. Having all the audit logs from a large numbers of systems accessible from one location (the FAAS server) should greatly facilitate these activities.

Figure 2: Audit Requirement Stack
4 Straw Man Diagram
Figure 3 shows the basic straw man diagram for FAAS. At the bottom are the end systems to be protected: MacBooks, iMacs, Mac Pros, Windows and Linux systems, etc. These systems have small agents that, at various moments in time, bundle up an existing log file and forwards its to the FAAS server.
The FAAS server stores each log file and records in a database the file name, the data type, and the host that sent it.
On the right are human analysts using a simple client (perhaps a web browser) to view basic statistics about data collected, browse the log files, and download a selected log file for local, in-depth analysis using local tools.
Not shown (and not part of FAAS) are automated analysis tools that can query the database, extract appropriate log files, perform analysis, and generate reports.

Figure 3: Straw Man Diagram
5 FAAS Goals
The FAAS project has the following goals:
  • Cheap. The FAAS tool will be free, and any additional tools it uses (e.g., perhaps PostgresSQL DBMS and Apache web server) should be free. The only exception may be to require purchase of Apple's OS X Server software.
  • Quick releases. FAAS will follow the "design a little, build a little, deploy, and repeat" pattern. The goal is to get something deployed quickly (2-3 weeks), test, refine the feature request set from operational experience, and start working on the next release.
  • Extensible. Any data will do. Each data file uploaded will be tagged with a data type, but FAAS will make no effort to analyze the data.
  • Public protocol and API. Fully specify the network protocol and APIs on the server so others can (1) build custom agents to feed other types of audit data to FAAS and (2) build analysis tools to process the stored data.
  • Batch mode. Initial releases will assume that the data will come in periodic chunks and not a continuous stream of data. This simplifies the design.
  • Large data sets. High fidelity audit log files can be several Gigabytes in size, so the transport mechanism and server needs to support large data sets.
6 Help Wanted
If you would like to help by providing feedback on the design and especially by testing early releases, I would really appreciate it.
You can find me (Todd Heberlein) on the Fed-Talk mailing list.

@NetSquared_USA  copyright Net Squared, Inc., 2008-2013