Boulder Labs Classified Network Auditing Tactics and Strategy
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
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.
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
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:
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
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.
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