Version /2/02 SECURE AUDITING FOR LINUX SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

Transcription

1 Version /2/02 SECURE AUDITING FOR LINUX SOFTWARE REQUIREMENTS SPECIFICATION (SRS) July 2002

2 Tale of Contents 1. Computer Software Configuration Item Auditing Package Background Scope Document Overview Requirements Functional Requirements General Requirements Recording Requirements Reporting Requirements Encryption Requirements Performance Requirements Systems Administrator Utility Requirements Standards Compliance External Interface Identification External Input Interfaces User Interface External Output Interfaces User Interface Internal Interfaces Computer Resources Constraints Third-party Software Audit Data Log Size System Clock Validation Criteria Documentation Biliography Glossary Issues...21 i

3 List of Figures Figure 1 - SAL System Design...6 ii

4 1. Computer Software Configuration Item Auditing Package 1.1 Background Presently the GIG (Gloal Information Grid) is the main tool for collecting, storing, processing, and disseminating information to the war fighters, policy makers and supporters of the U.S. government. Defense Advanced Research Projects Agency (DARPA) has accepted proposals and funded individual projects to demonstrate a capaility of influencing the open source community in the area of Information Assurance. The intent is to discover the proaility of enhancing an open source operating system that is secure enough to certify for use within the GIG. This project focuses on several aspects within one open source community. Although there are several open source OS s (Operating Systems) in use today this project selected the Linux OS. Linux is a computer OS similar to the Unix OS. Linux was developed y Linus Torvalds in the early 1990 s. In late 1991, Linus introduced Linux on the Internet under the GPL (GNU Pulic License). The decision to license Linux under GNU created a different type of computer OS from those eing sold y major distriutors of OS software. The Linux OS kernel is open source software that is controlled through Torvalds, yet through the GNU license the source code is availale to anyone. There are no license requirements preventing changes to the source code and redistriuting it under a new company, ut the GNU license requires that the changed software must also include source code when eing distriuted. This Open Source strategy allows any software developer access to source code in order to test the capailities and shortfalls of the Linux OS. Torvalds accepts comments and recommendations to the source code from the pulic and he utilizes a team of developers to make decisions on what each official release will consist of. The Linux OS is distriuted as a kernel. The kernel of the OS is the central functional component. The kernel controls access to computer hardware resources, such as the hard drive, printers and floppy disk drive, as well as the man-machine interface (keyoard, screen, etc). Unlike other OS s, such as Microsoft Windows, the Linux kernel does not include a window manager or desktop manager. These are software packages that can e added to a Linux machine after installation of the kernel to afford ease of use. The Linux kernel correctly installed gives you command line interaction only. Several window manager and desktop manager packages availale for Linux have also een developed under the GNU license. Open source software frequently requires a higher level of computer programming knowledge. Companies such as Microsoft and Apple Computer have uilt a usiness on ease of computer use for the customer. Due to large usiness demands these computer software companies have included Information Assurance security within their own OS software packages. Linux on the other hand has never mandated such internal security. Companies that have taken this on, such as Hewlett Packard, have maintained the Linux kernel as is and developed proprietary software to e added to the kernel. This software is not under the GNU license and as of yet carries a large per license charge. Throughout the 1990 s Linux gained in popularity yet continued to fall short of the security requirements of the U. S. Government s Gloal Information Grid. In order for OS s to e utilized in a government-networking environment they must follow certain Common Criteria (CC) requirements. Common Criteria has many aspects to its security. One of the aspects is that the Trusted Computing Base (TCB) must e ale to create, maintain, and protect from modification or unauthorized access or destruction, an audit trail of accesses to the ojects it protects. In order to engage in a manageale segment this project concentrates on secure auditing for the Linux kernel. 3

5 Presently there is a major lack of secure, reliale, scaleale, policy-ased system auditing within the Linux kernel, especially any that proposes to audit activities at the kernel level. Although the Linux kernel operates extremely efficiently, it does not monitor internal program calls to the kernel itself. Such calls would include user logins/logoffs, file accesses, file creation/deletion, privilege modifications, etc; in order to maintain a level of Common Criteria security, it is important to log all users of the system and what commands they execute within the OS. By automatically auditing these system calls to the kernel, the Linux OS would meet the Common Criteria requirements for auditing. These audit logs are important for system administrators to audit the activities of system users and for forensic personnel to track and recreate illegal activity if the system has een compromised. This project investigates which system calls require auditing in order to meet the Common Criteria standards while minimizing the performance impact of auditing on the system. Special care will e taken to produce an architecture that allows the audit system to e secure, reliale, and scalale and to the greatest extent possile, configurale. Securing audit data is the chief requirement of the SAL program. The safekeeping and confirmation that data sent to the logs has not een modified is its highest priority. In essence the SAL program estalishes a chain of custody for the log data. This is especially important to prove in a court of law that the information presented to convict a perpetrator for an illegal action is true and accurate. This is an important feature for the U.S. Government and usinesses alike. Additionally, this project also investigates different ways of securing the audited data as soon as it is written to audit logs. The safekeeping of data will not e assigned to a single system, instead audit data will e gathered, encrypted locally and transmitted to a secure data repository. During transmission to a repository, audit data could potentially travel over untrusted networks, so encryption techniques will e used to prevent possile eavesdropping. Producing a system that is oth scalale and configurale is extremely important for the SAL program. To e used y the U.S. Government and commercial usinesses alike, the SAL program will need to e configurale enough to fit into any estalished Security Policy. These policies can vary from the simple logging of ad passwords to capturing every keystroke and network packet that an instrumented system receives. Configuraility will also e important when the estalished security policies call out different levels of Quality of Security Services (QoSS). Different levels of QoSS provide system administrators the aility to instrument systems differently. Systems with high security requirements will get a fully instrumented kernel while systems with low security requirements will receive partially instrumented kernels. To support these multiple levels of QoSS SAL will develop an application protocol framework that is connection oriented and asynchronous. A final aspect to e incorporated will e a log viewer which will allow a system administrator and/or forensics professional the aility to parse, view or print log information in order to simplify audit log data extraction. This will e a read only function, the audit logs themselves will not e written to during this process to maintain the security of the logs. A project goal of the SAL program is to have these aspects incorporated into a future release of the Linux kernel y Linus Torvalds. 1.2 Scope Purpose of the Work The purpose of the work is to develop an auditing package for Linux (kernel version as of this writing) that is compliant with the U.S. Government s standards as well as Common Criteria standards for security. SAL will also provide a mechanism for collecting log information such that it is admissile as evidence in a court of law. Benefits 4

6 This auditing package will help to meet the information assurance goals for the GIG. It will also e of immediate enefit to law enforcement in computer forensics. Additionally, y residing at the kernel level this audit package will allow for all processes to e monitored. Scope The first goal will e to provide a compliant kernel-level logging facility. Some work has already een done in this area (Auditd and Linux BSM), ut a limited numer of events are logged. Discussions with law enforcement will e conducted to determine the requirements that must e met to allow this data to e admissile as evidence in court. Additional discussions will determine the level of configuraility that is necessary for acceptance y the system administrator community. Ojective To create a compliant logging facility, providing assurance that the data cannot e modified once it is recorded. The source code for this package will e released under the terms and conditions of the GNU Pulic License. Further SAL is not to degrade system performance y a significant margin on an instrumented system. SAL System Design There are three system components in the SAL architecture: the Log Generator (LG), the Log Relayer (LR), and the Data Repository (DR). A machine that can generate an audit log message will e called a generator. A machine that can receive the message and forward it to another machine will e called a relay. A machine that received the message and does not relay it to any other machine will e called a repository. This will e known as the SAL server. Any generator or relay will e known as the sender when it sends a message. Any relay or repository will e known as the receiver when it receives the message. The diagram elow shows some of the components involved with a asic implementation of SAL. It depicts a Linux-ased PC with Auditing generator as the sender of audit information to a Central Logging Server repository. There are many other implementations of SAL that may or may not include one or more relays and one or more repositories. 5

7 1.3 Document Overview Figure 1 - SAL System Design This document will identify the requirements for the Auditing Package Computer Software Configuration Item (CSCI). This Requirement Specification descries what the Auditing Package CSCI is required to functionally perform, along with its required input and output. The Auditing Package will only function as specified within this document. For a definition of the terms, refer to the Glossary section of this document. 6

8 2. Requirements The following requirements apply to the Auditing Package Computer Software Configuration Item (CSCI). The overall requirement is to create an auditing package for the Linux operating system, kernel version 2.4.2, which is compliant with government standards for security. SAL will also provide a chain of custody mechanism that allows the collected and stored information to e admissile as evidence in a court of law. 2.1 Functional Requirements The following section contains the functional requirements, organized y feature, that define the Auditing Package General Requirements The following are goals and requirements that generally apply throughout the Secure Auditing for Linux (SAL) Package. Req No Requirement Description Derived From GEN010 GEN020 GEN030 GEN040 GEN050 GEN060 GEN070 The goal of SAL is to audit all events specified in section during the period eginning from complete system startup and ending with the initial shutdown sequence. SAL will protect audit data from unauthorized modification and deletion. SAL will protect audit data from unauthorized viewing. The goal of SAL is to e included in the kernel as a static module. The goal of SAL is to e configurale to fit into a variety of estalished security policies. SAL will define three security policies. One of the three will meet the level of auditing. The goal of SAL is to scale from a single computer with an instrumented kernel and an external data repository to supporting many hundreds of instrumented computers with multiple data repositories. DoD STD , FAU_STG 1 DoD STD , FAU_SAR 2.1 Common Criteria 7

9 GEN080 SAL will provide a verifiale chain of custody record for all audit log data from the moment it is created on a generator to when it is stored inside a data repository Recording Requirements The goal of SAL is to e capale of recording any of the following events in the context of kernel system calls. Some events map one-to-one with particular system calls while other events map to multiple system calls. Each event configured for auditing will e recorded and sent to a repository. Req No Requirement Description Derived From REC010 SAL will audit logins and logoffs. DoD STD REC020 SAL will audit process invocation and terminations. DoD STD REC030 SAL will audit file or file system accesses and modifications. DoD STD REC040 SAL will audit security privilege changes. DoD STD REC050 SAL will audit user account modifications. DoD STD REC060 REC070 REC080 REC090 REC100 REC110 REC120 REC130 A goal of SAL is to audit Inter-process communication command invocations. A goal of SAL is to audit network configuration modifications. A goal of SAL is to audit memory access command invocations. A goal of SAL is to audit hardware device configuration modifications. SAL will audit startup and shutdown of audit logging processes. A goal of SAL it to audit run-time kernel configuration modifications. SAL will audit retrieval of system-related information. SAL will audit directory operations and traversals. Common Criteria 8

10 REC140 REC170 REC180 REC190 RE00 SAL will audit system configuration modifications exclusive to superuser. Audit data will e stored in an Audit Repository. Audit data that is stored locally will e tagged as such when eing stored at an audit repository so that proper knowledge of such is logged Audit data will e stored such that chain of custody will e maintained and verifiale. All changes to SAL s configuration will e audited Reporting Requirements SAL will e designed to accept messages from other logging systems, such as syslog. While there is no format imposed on these messages, SAL generated messages will contain specific information for each event. Req No Requirement Description Derived From REP010 REP020 REP030 REP040 REP050 REP060 REP070 No assumption is made aout the formatting or content of the message eing logged at a repository. SAL will accept and log any audit messages it receives from authenticated generators. SAL will support the concept of Facility (Similar to syslog) SAL will support the concept of Severity (Similar to syslog) Valid SAL messages will contain a message header, which will have a representation of date and time of the event in UNIX time format (numer of seconds since January 1, 1970) including a 4 digit year. Valid SAL message headers will contain the identification of the sending generator. Valid SAL message will contain a message payload. DoD STD , FAU_GEN 1.2 Common Criteria REP080 For kernel messages a numerical system call identifier(s) associated with the type of event will e included. DoD STD , FAU_GEN 1.2 REP090 For kernel messages a numerical representation of system call return status indicating the success or failure of the event will e included. DoD STD , FAU_GEN 1.2 9

11 REP100 For kernel messages a numerical identification of the user initiating the event will e included. DoD STD , FAU_GEN 2.1 REP110 For kernel messages a numerical identification of the terminal originating the event will e included. DoD STD REP120 For kernel messages a numerical and text identification of the process spawning the event will e included Encryption Requirements Req No Requirement Description Derived From ENC010 ENC020 ENC030 ENC040 The goal of SAL is to encrypt audit data in the kernel. The goal of SAL is to securely generate and manage kernel encryption keys of at least 128 its in length. The goal of SAL is to securely transmit the audit data and encrypted key to the log server at regular intervals The goal of SAL is to include a verifiale signature with each transmission of audit data to the log repository. FCS_COP 1.1 FCS_CKM.1.1 Common Criteria Performance Requirements Req No Requirement Description Derived From PRF010 PRF020 When fully operational, not in a faulted or error state, and the network is availale and operating normally, the goal of SAL is to deliver audit data to the log repository in at most three minutes - measured from when the event occurs to when the log entry and key reach the repository. The goal of SAL is to store audit data at Audit repositories. In the event that transmission to a repository is currently unavailale, local logging will e initiated that will e flagged as suspect when received y the repository. Common Criteria 10

12 PRF030 PRF040 Whether stored locally or on the remote server, the goal of SAL is to store audit data according to time (in UNIX time format). The goal of SAL is to e free of uffer-overflow issues and other known attacks, including denial of service attacks Systems Administrator Utility Requirements The following requirements apply to the utilities provided for system administrators. Req No Requirement Description Derived From SAU010 SAU020 SAU030 SAU040 SAU050 SAU060 SAU070 The goal of SAL is to provide the aility to generate and maintain encryption keys as appropriate for secure transmission of audit data to a log repository. The goal of SAL is to provide the aility to select audited events ased on one or more criteria including user identity. The goal of SAL is to provide the aility to query audit data for log entries pertaining to a user id, time range, system call identifier, or process name. The goal of SAL is to provide the aility to analyze audit data. The goal of SAL is to provide the aility to export audit data in text format for the purpose of printing. The goal of SAL is that only tools availale in the Open Source Community e used for its configuration, installation and maintenance once installed. Configuration of SAL will e accomplished y a configuration tool. This tool will walk an administrator through the steps required to implement SAL in a system. SAU080 The configuration tool will support a minimum of 4 levels of QoSS (HARDENED, MED, LOW, USER DEFINED). Policies will e defined for HARDENED, MED and LOW levels of QoSS. PRF050 SAL will allow the configuration of the audit server y way of a configuration tool. FCS_CKM 1, FCS_CKM 2 DoD STD , FAU_SEL 1.1 FAU_SAR 3.1 FAU_SAA 4 Common Criteria 11

13 2.1.7 Standards Compliance In an effort collaorate with and support the Open Source community the SAL program will use existing standards. In the event that the existing standard fall short of our requirements they will e extended. The extensions of any RFC will e rought ack to the community for review. The specific RFCs are: RFC3164 RFC3080 RFC BSD syslog protocol (the old) - BEEP, protocol used to transmit syslog-reliale messages - BEEP over TCP Req No Requirement Description Derived From STD010 STD020 STD030 SAL will develop a Policy-Based Log Auditing Data Storage format that will e accepted in a court of Law. SAL will implement a Policy-Based Log Auditing Data Storage format. A goal of SAL is to e compatile as a repository with the protocols defined in RFC3164, RFC3080 and RFC3081. Common Criteria 2.2 External Interface Identification This section lists all external interfaces, oth input and output, and identifies which interfaces have fixed interface characteristics (and therefore impose interface requirements on the Auditing Package), and which interfaces are eing developed or modified (thus having interface requirements imposed upon them y the Auditing Package). 2.3 External Input Interfaces This section identifies the external input interfaces and the input data required y System Design User Interface The following requirements define the user external input interface and the entries that SAL accepts from a user: Req No Requirement Description Derived From USR010 SAL shall provide a command line interface, with a Common Criteria 12

14 USR020 USR030 goal of using a graphical interface, for any configurale options on the data repositories. The goal of SAL is to provide a command line interface for any configurale options on the audited system. The goal of SAL is to support the use of a configuration file to configure all aspects of the program (generator, relay, repository). 2.4 External Output Interfaces This section identifies the external output interfaces of System Design, including the output data System Design will e required to produce, for each external interface User Interface The following requirements define the user external output interfaces and identify the output that SAL has to the user. Req No Requirement Description Derived From USR040 USR050 USR060 SAL shall provide a command line user interface, with the goal of using a graphical interface, for the reporting and analysis of audit data on the log repositories. SAL viewing tools will have the aility to display as well as print all selectale views. SAL shall provide filtering capailities to any tool used to view log data. Common Criteria Internal Interfaces The following requirements define the internal output interfaces. Req No Requirement Description Derived From INI010 To remove the need for administrators to support multiple loggers, a goal of SAL is to interface with the standard Linux syslog program. SAL will act in this regards as a Syslog Collector, so that audit data can e stored to a protected secure data repository from non-instrumented systems. Common Criteria 13

15 2.4.3 Computer Resources Req No Requirement Description Derived From CMP010 CMP020 CMP030 CMP040 CMP050 CMP060 The goal of SAL is to work with the most current commercial release of the Red Hat distriution of Linux. The goal of SAL is to work on a minimum of an x86-ased Pentium 233 MMX or AMD K6-233 with 64 megaytes of RAM. SAL will e ale to function as a headless system at the data repositories. SAL s installation disk space requirement goal is to not consume an amount of disk space greater than ten megaytes including source code, compiled code, and all necessary third-party components. A goal of SAL is to support large data repositories (greater than 10 Gigaytes). SAL s data repository will e capale of using additional storage space if it ecomes availale after repository startup. Common Criteria 14

16 3. Constraints This section identifies constraints imposed on the Auditing Package: 3.1 Third-party Software If the installation of any utilities or liraries are required, these will e clearly indicated and discussed in any install documentation. Any such software will not restrict the open source nature of the Auditing Package. 3.2 Audit Data Log Size The size of the audit data log is restricted to the amount of free disk drive space availale to the data repository. However SAL will e developed such that there will e no maximum disk storage limitation, and furthermore will e ale to use additional storage resources if they ecome availale during execution. 3.3 System Clock In order to ensure accuracy of the audit data timestamps, the system clock on the audited system and log server (if applicale) must e set as accurately as possile and periodically adjusted if necessary. When audit data is generated a time stamp is used. This time stamp is maintained with the audit data throughout its existence. When a repository receives audit data the time it was received will e logged and will also stay with the data through out its existence. 15

17 4. Validation Criteria A Software Test Plan (STP) will e created to define a set of qualification methods and to specify for each requirement in this document a method of ensuring that the requirement is satisfied. 16

18 5. Documentation users: The following documentation will e developed and maintained to support this project and the end System Requirements Specification : This document provides the requirements and sources for the system. It also descries the system from a high level, without providing any of the design. Software Project Management Plan : This document estalishes the development process for the project. Software Design Document : This document presents a high level design for the system, decompose this into components, and descrie each component. Software Test Plan : This document descries how the requirements will e tested in the final system. User s Guide : This document descries the use of the system for day-to-day activities. It is intended as a reference for the end user, to supplement any on-line or uilt-in help. Installation Guide : This document details the installation and initial configuration of the system, to include selection of the appropriate policies. 17

19 6. Biliography This section contains a master list of all documents and other sources of information referenced in this CSCI SRS: Department of Defense Trusted Computer System Evaluation Criteria, Department of Defense, Decemer 26, Evaluation Criteria for IT Security, ISO/IEC , Decemer 1, RFC3164, The BSD syslog Protocol, C. Lonvick, Copyright (C) The Internet Society (2001) RFC3080, The Blocks Extensile Exchange Protocol Core, M. Rose, Copyright (C) The Internet Society (2001) RFC3081, Mapping the BEEP Core onto TCP, M. Rose, Copyright (C) The Internet Society (2001) 18

20 7. Glossary This section contains a list of project definitions and acronyms used throughout this document: API Application Programming Interface BEEP BSD CC Blocks Extensile Exchange Protocol Berkley Standard Distriution Class is a rating granted y the National Computer Security Center (NCSC) for products that have een evaluated against the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC). Common Criteria COTS CSCI DARPA Data Repository DoD Generator GIG GPL GUI ID Log Generator Log Relayer OS PC QoSS Receiver Relay Repository SAL Commercial-Off-The-Shelf Computer Software Configuration Item Defense Advance Research Projects Agency Repository Department of Defense SAL implementation that sends audit messages Gloal Information Grid GNU Pulic License Graphical User Interface Identification Generator Relay Operating System Personal computer Quality of Security Service Any relay or repository will e known as the receiver when it receives a message SAL implementation that relays audit messages to a SAL repository SAL implementation that stores audit data to a secure recording device. Secure Auditing for Linux 19

21 Sender SPMP SRS SSS STP Syslog TCB TCP Any generator or relay will e known as the sender when it sends a message Software Project Management Plan Software Requirements Specification System/Susystem Specification Software Test Plan Standard Linux application that currently logs data to a repository. (Not secure or reliale) Trusted Computing Base Transmission control protocol 20

22 8. Issues There are no issues at this time. 21