A New Plan

Boulder Labs Classified Network Auditing Tactics and Strategy

INTRODUCTION. The Boulder Labs approach to NISPOM-required system auditing will be based on two fundamental premises: 1) The requirements interpretation will be tailored to this unique development environment and 2) The practical implications for implementing those requirements drive the solution.

1. FOUR KEY CONCEPTS are identified in NISPOM ch.. 8-602, titled “Audit Capability.” They are: recognizing, recording, storing, and analyzing. They may be understood in terms of who/what (recognizing) where/when (recording and storing) and how (analyzing). Why we would do this should be obvious. The following plan explains a proposal to apply the practical possibilities of who, what, where, when and how to recognize, record, store and analyze security relevant systems events transpiring at the Boulder Labs facilities.

2. FACTS. Some of the more important relevant facts surrounding the NISPOM auditing issues at SBIRS Ground in Boulder, CO are:

2.1 SBIRS and the networks and computers it runs on are predominantly very unique special-purpose systems.

2.2 NISPOM requirements are formulated to the lowest common denominators for generic, general-use systems.

2.3 Systems security is an important, vital requirement for government compliance and national security, as well as overall corporate interests.

2.4 Specific requirements for automated audit records of failed access and successful login generate huge amounts of non-security-relevant audit data in this environment.

2.5 Security relevant information as it may exist in the OS-generated audit data has not been adequately defined for this environment.

2.6 Network and systems security are time sensitive issues.

3. ASSUMPTIONS. The success of this proposal rests on several assumptions. These assumptions identify what we believe to be desirable goals and address obstacles with which the auditing program is presently confronted.

3.1 We wish to pursue security incidents less than a week after they happen.

3.2 SSOs will have ownership of the new portion of the auditing program.

3.3 The ISSM (or their designated report) will retain ownership of the existing portion of the auditing program.

3.4 If adopted, the high-level points and processes of this program will be incorporated into the Boulder Labs Master System Security Plan, and submitted to the Defense Security Service for review and approval.

3.5 Future budgets will include equipment dollars to maintain and/or replace the obsolete platforms portions on which the Network Intrusion Detection System (NIDS) will likely initially be deployed.

4. FOUR STEPS. The ISSM is presently somewhere near completing accomplishment of the first two steps of implementing the overall program. This constitutes the existing portion of the program. It involves the recording and storing of the target host-automatically-generated audit data. This part of the program was embarked upon almost a year ago as a joint effort between the security and SA community. It is ongoing, and being actively worked by Aaron Schram (reporting to the ISSM). SSOs have assisted up to this point by identifying missing or mis-configured pieces in the data collection effort. This portion of the program meets the NISPOM requirement to store and retain audit information from every system for one year. The reduction portion of Aaron’s scripting effort also establishes the basis for a practical weekly review.

4.1 Step Three: Recognizing security relevant information. The program forks into two distinct realms of activity at this point: The process for establishing host, or target-based recognition has begun in the form of the audit reduction scripts presently being written and implemented. A network intrusion detection system (NIDS) will enhance these rudimentary functions. It will be employed to provide the primary top level, real-time vector to recognize security relevant activity.

4.1.1 Aaron Schram, ISSM intern/assistant, is presently working to elaborate on the data collection scripts to 1) consolidate them into a manageable, ISST-owned and operated OS audit data collection system, 2) provide a mechanism to dynamically include all hosts on the network for data collection and configuration checking and 3) reduce, store and groom the raw data by means of correctly setting the audit flags and parsing out innocuous data which cannot be otherwise recognized for filtering by the audit daemons themselves due to the nature of various SBIRS software activities. This will provide a manageable, reduced data store that is by definition, security relevant. It will be subject to weekly review and constitute the first level of forensic investigation material. Online raw audit data will remain accessible to the SSOs and maintained for archival purposes by the SA team in both online and/or offline formats, based on the SA’s data archival process, which belongs to them.

4.1.2 A NIDS will be employed as the primary means of security audit recognition due to the network-centric nature of the SBIRS development community and the number of systems requiring monitoring. The SBIRS application includes various processes and scripts running on numerous servers and workstations performing a myriad of interrelated and automatic functions. For the most part, they all share the same network. The vast majority of human interaction for administration, development and testing purposes occurs in a client-server or terminal-connected session across the network, both locally and from distant points in the wide area network. Practically speaking, and from a risk analysis standpoint, the greatest threats to our system environment are network-borne. Contemporary attack and exploit profiles for currently known and yet to be seen malicious activity may not even be subject to OS auditing at all in this environment.

4.2 Step Four: Analysis of recognized security-relevant audit data. The last step to meeting the NISPOM auditing goal is divided into two parts, similarly to the third step. A traditional task of weekly audit data review will meet the basic compliance requirement, as presently interpreted and applied to this facility. An extension comprised of network traffic analysis meets our site-specific requirement to deal with system security issues in a time-sensitive fashion, from the realistic perspective of where the threats are and how to find them in this environment.

4.2.1 SSOs will be responsible for reviewing the reduced audit data generated by the OS on a weekly basis.

4.2.2 SSOs will operate and respond to the Cisco SENTRE IDS console and the Analysis Console for Intrusion Databases (ACID) on a continuous, real-time basis, to appropriately counter, mitigate or discard system identified potential security events as quickly as possible.

5. METHODOLOGY. A portion of the methodology for launching this program will include policy matters beyond the scope of this document. Those details were outlined in a meeting invite email subj: NISPOM Auditing Program, dated 1 March, 2004. Links to those documents will be made available upon request. The practical aspects of the methods used to achieve the auditing goals are presented here in a high-level process-based format as follows:

6. REQUIRED RESOURCES. Time and equipment. In addition to ongoing maintenance support and actually performing the traditional audits as described in section 4.1.2 above, SSO time will be applied to loading, configuring, testing and auditing network traffic via the NIDS sensors and management console (Cisco/AMC) systems. Netoptics taps coupled with a commercially procured Cisco IDS will support a portion of the IDS system monitoring aggregated WAN/LAN links and two other aggregation points. An additional three to five network interfaces will be hosted for positioning as open-source Snort-based IDS sensors at various other locations on the network. Another system will be pressed into service as the AMC to receive, store and process sensor input alert data.

7. IMPLEMENTATION SCHEDULE. Steps three and four were initially embarked upon about four months ago, when it became clear that our auditing program needed help. The implementation schedule submitted for the project at that time remains valid, if pushed to the right by x number of weeks to accommodate a restart. The schedule has since been updated to include new OS audit data collection efforts recently started and now running in parallel as described in section 4.1.1 above.

8. PROCESS OVERVIEW. The ISST will continue performing the presently established auditing practices, as implemented by the currently approved SSP. This basically constitutes security “spot checks.” This activity has proven to be an extremely high cost vs. benefit effort based on many man-hours spent attempting to glean security-relevant information from the OS audit data. By the time reduced audit records reach their storage location and humans have looked at, parsed or otherwise applied some analysis, the process has little value from a security perspective.

8.1.This part of the auditing program “goes through the motions” for the purpose of NISPOM compliance, as presently interpreted. Literally hundreds of hours invested in searching the audit data have thus far evidenced nothing more than normal activity on the systems. The SSOs believe a better approach to recognizing security relevant events is called for.

8.2.Employing NIDS as the primary “vector” to inappropriate activity on the systems will enhance the recognition process. Sensors at key location in the network will monitor all network traffic, analyze it against common databases of known bad activity and apply heuristic adaptation features to our particular traffic patterns. We may also custom tailor the signature database to focus on specific threats or vulnerabilities at will. NIDS recognition is more likely to find security relevant events because the identification criteria are infinitely flexible based on user-defined specific signature definitions, heuristics, and network traffic profiles and content, as opposed to relatively fixed and limited OS auditing flag choices. Both NIDS could even eventually be employed to actively counter detected threats, increasing the security posture within the network by another order of magnitude.

8.3.Results of the front-end analysis performed by the sensors are continuously loaded into a back-end database where a web interface enables the NIDS analyst (SSO) to respond in appropriate ways to whatever the system is picking up. Alerts generated by the sensors are indicated on the analysis console in real time.

8.4.Further investigation into suspected security breaches may lead to traditional audit analysis, depending on the circumstances of a given event or incident. Forensics and evidence gathering could call the raw audit data into play for resolution.

8.5.Successful implementation based on a complete rollout and proven valued performance of the system is expected to eventually invoke a request to DSS for permission to eliminate the analysis portion of the requirement from our traditional audit data reviews in favor of NIDS-based analysis, exclusively. System performance and supporting data including certification of coverage, event detection and resolution statistics, and policy/process documents will be submitted to substantiate the request.

9. SUMMARY. Extensive COTS software is available to employ traditional audit reduction and analysis methods to the raw data being generated by our operating systems in more effective and timely ways. But at what cost vs. benefit? The traditional, outdated approach, whether performed in an automated or manual fashion, provides NISPOM compliance, but little or no additional real security in this environment. We have struggled up to this point even establishing auditing turned on for all machines. It is naïve to assume that all or even a majority of possible malicious activities can be recorded by OS auditing, much less recognized and acted upon by human programmers and auditors. It is reasonable to assume that the traditional auditing process represents a secondary support layer in a strong, layered defense. Being at risk and knowing it, is better than living in a false sense of security.

Effective auditing with available tools and resources is achievable within the broad framework of NISPOM compliance requirements “if” we employ a network-centric approach, shifting our focus away from the traditional auditing paradigm. This approach promises numerous advantages over the OS audit data analysis method. It affords low latency, granular control, minimal support burden, and security team administrative control of the primary auditing vector. That vector is the difficult to find and interpret “what” of security auditing’s who, what, where, when, why and how.

Acronym List

ACID Analysis console for intrusion databases – a PHP-based web application developed by the Carnegie Mellon Computer Emergency Response Team (CERT) used to view, manipulate, and search a database of intrusion detection information.

AMC Analysis and Management Console – computer that hosts ACID

COTS Commercial off-the-shelf software

DSS Defense Security Service

ISSM Information Systems Security Manager

ISST Information Systems Security Team

NIDS Network Intrusion Detection System

NISPOM National Industrial Security Program Operating Manual

OS Operating System

SA System Administrator

SBIRS Space-Based Infra Red System

SSO System Security Officer

SSP System Security Plan