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