Command Core System (CCS) Security Design Document

smileybloatΔίκτυα και Επικοινωνίες

20 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

149 εμφανίσεις






Command Core System (CCS)

Security Design Document


















Prepared By:

Department of the Air Force

Command Core System (CCS) AFIERA/RSEC

2513 Kennedy Circle

Brooks Air Force Base, Texas 78235
-
5123

30 November 2001

CCS Security Design Document

30 November 2001



Document Version 1.3

i

CCS SECURITY DESIGN
DOCUMEN
T

REVISION AND HISTORY

PAGE

Document
Version #

Software
Release #

Revision

Date

Description

of Change

Section # /

Paragraph #

Page #

1.0

4.1

Date of First
Published Document


29 March 2000

This was the initial
document.

NA

NA

1.1

4.3

16 March 2001

Versi
on Upgrade



1.2

4.3

31 May 2001

Update



1.3

4.4

30 November 2001

Version Upgrade




CCS Security Design Document

30 November 2001



Document Version 1.3

ii

CCS SECURITY DESIGN
DOCUMENT

TABLE OF CONTENTS

SECTION 1 SCOPE

................................
................................
................................
..................

1
-
1

1.1

Identification

................................
................................
........................

1
-
1

1.2

System Overview

................................
................................
.................

1
-
1

1.3

Document Overview

................................
................................
............

1
-
4

1.4

Document Organization

................................
................................
.......

1
-
4

SECTION 2 REFERENCED

DOCUMENTS

................................
................................
.........

2
-
1

2.1

References

................................
................................
...........................

2
-
1

SECTION 3 STATEMENT
OF POLICY

................................
................................
...............

3
-
1

3.1

Introduction

................................
................................
.........................

3
-
1

3.2

Security Policy Summary

................................
................................
....

3
-
1

3.2.1

System Philosophy of Pro
tection

................................
...........

3
-
2

3.2.1.1

Policy for Software Maintenance

..........................

3
-
4

3.2.1.2

Backing Up Files and Schedules for Backups

.......

3
-
4

3.2.1.3

System Recovery

................................
...................

3
-
5

3.2.1.4

Minimum and Maximum User Clearances

............

3
-
5

3.2.1.5

Connecting to CCS

................................
................

3
-
6

3.2.2

CCS Protection
................................
................................
.......

3
-
6

3.2.2.1

Accountability

................................
.......................

3
-
7

3.2
.2.2

Confidentiality

................................
.......................

3
-
7

3.2.2.3

Integrity

................................
................................
.

3
-
7

3.2.3

Policy Objectives

................................
................................
...

3
-
7

3.2.4

Policy Requirements

................................
..............................

3
-
9

SECTION 4 SECURITY R
EQUIREMENTS

AND CCS SECURITY DES
IGN

................

4
-
1

4.1

Introduction

................................
................................
.........................

4
-
1

4.2

Security Description

................................
................................
............

4
-
1

4.2.1

Security Design

................................
................................
......

4
-
2

4.2.2

Security Features

................................
................................
....

4
-
3

4.2.3

Network Communications Security Design
...........................

4
-
3

4.3

C2 Security Requirements

................................
................................
...

4
-
3

4.3.1

Audit

................................
................................
......................

4
-
3

4.3.1.1

ORACLE Audit Function

................................
......

4
-
4

4.3.1.2

UNIX Audit Function

................................
............

4
-
8

CCS Security Design Document

30 November 2001



Document Version 1.3

iii

4.3.1.3

Intruder Alert

................................
.......................

4
-
12

4.3.2

Discretionary Access Control

................................
..............

4
-
13

4.3.3

Identification and Authentication (I&
A)

.............................

4
-
15

4.3.4

Object Reuse

................................
................................
........

4
-
16

4.3.5

System Architecture

................................
.............................

4
-
16

4.3.6

System Integrity

................................
................................
...

4
-
16

4.4

DoD Minimum AIS Security Requirements

................................
.....

4
-
17

4.4.1

Access Control

................................
................................
.....

4
-
18

4.4.2

Accountability

................................
................................
......

4
-
18

4.4.3

Accreditation (On
-
going)

................................
.....................

4
-
19

4.4.4

Contingency Planning

................................
..........................

4
-
19

4.4.5

Data Continuity

................................
................................
....

4
-
19

4.4.6

Data Integrity

................................
................................
.......

4
-
19

4.4.7

Least Privilege

................................
................................
.....

4
-
20

4.4.8

Markings

................................
................................
..............

4
-
20

4.4.9

Physical Contr
ols

................................
................................
.

4
-
20

4.4.10

Security Training and Awareness

................................
........

4
-
22

4.4.11

Risk Management

................................
................................

4
-
22

SECTION 5 SYSTEM DES
CRIPTION

................................
................................
..................

5
-
1

5.1

Introduction

................................
................................
.........................

5
-
1

5.2

Technical Description

................................
................................
..........

5
-
1

5.2.1

Graphic User Interface (GUI) Supported

...............................

5
-
2

5.2.2

Modules
................................
................................
..................

5
-
3

5.2.3

Network Design

................................
................................
.....

5
-
3

5.2.4

Network TCP/IP Connectivity Design
................................
...

5
-
3

5.2.5

objs Directory (Forms and Reports)

................................
......

5
-
5

5.3

System Assets

................................
................................
......................

5
-
5

5.3.1

CCS Hardware Requirements

................................
................

5
-
6

5.3.1.1

Database Server

................................
.....................

5
-
7

5.3.1.2

Client Workstation Hardware

................................

5
-
7

5.3.2

Interface Installation Requirements

................................
.......

5
-
8

5.3.3

CCS Software Requir
ements

................................
.................

5
-
8

5.3.3.1

Database Server Software

................................
......

5
-
9

5.3.3.2

Client Workstation Software

................................
.

5
-
9

5.4

Interfaces

................................
................................
.............................

5
-
9

SECTION 6 LEVELS OF
TRUST

................................
................................
...........................

6
-
1

6.1

Introduction

................................
................................
.........................

6
-
1

6.2

Access Levels of Trust

................................
................................
........

6
-
1

6.3

DAC

................................
................................
................................
.....

6
-
1

CCS Security Design Document

30 November 2001



Document Version 1.3

iv

6.3.1

HP
-
UX DAC

................................
................................
..........

6
-
1

6.3.2

CCS Application

DAC

................................
...........................

6
-
2

SECTION 7 NOTES

................................
................................
................................
..................

7
-
1

ANNEXES

A


Abbreviations, Acronyms, and Terms

................................
................................
..............

A
-
1

B


CCS Security Design Document Recommended Corrections, Revisions, or



Updates Form

................................
................................
................................
......................
B
-
1

EXHIBITS

Exhibit 3
-
1: Policy Objectives Table

................................
................................
..........................

3
-
8

Exhibit 3
-
2: Policy Requirements Table

................................
................................
.....................

3
-
9

Exhibit 4
-
1: CCS Network Topology

................................
................................
.........................

4
-
2

Exhibit 4
-
2: Events ORACLE Audit
ing is Configured to Capture
................................
.............

4
-
5

Exhibit 4
-
3: CCS Application Logging

(ORACLE)

................................
................................
...

4
-
6

Exhibit 4
-
4: CCS Application Selective Logging
(ORACLE)

................................
...................

4
-
7

Exhibit 4
-
5: ORACLE
Connection Audit Log

................................
................................
...........

4
-
7

Exhibit 4
-
6: ORACLE Audit Log

................................
................................
...............................

4
-
8

Exhibit 4
-
7: Events UNIX Auditing is Configured to Capture Table

................................
........

4
-
9

Exhibit 4
-
8: UNIX Lastb File

................................
................................
................................
.....

4
-
9

Exhibit 4
-
9: UNIX Maillog File

................................
................................
...............................

4
-
10

Exhibit 4
-
10: UNIX Messages File
................................
................................
...........................

4
-
10

Exhibit 4
-
11: UNIX Security File

................................
................................
.............................

4
-
11

Exhibit 4
-
12: UNIX Spo
oler File

................................
................................
..............................

4
-
11

Exhibit 4
-
13: UNIX Sylog File

................................
................................
................................
.

4
-
12

Exhibit 4
-
14: Intruder Alert Event Viewer Screen

................................
................................
...

4
-
13

Exhibit 5
-
1: CCS Client Server Architecture
................................
................................
..............

5
-
2

Exhibit 5
-
2: CCS Modular Layout

................................
................................
..............................

5
-
4

Exhibit 5
-
3: Network TCP/IP Connectivity Design

................................
................................
...

5
-
5

Exhibit 5
-
4: CCS Hardware Architecture

................................
................................
...................

5
-
6

Exhibit 5
-
5:

HP 9000 Server Minimum Hardware Requirements

................................
..............

5
-
7

Exhibit 5
-
6: Client Workstation Minimum Hardware Requirements

................................
.........

5
-
7

Exhibit 5
-
7: CCS Software Architecture

................................
................................
....................

5
-
8

Exhib
it 5
-
8: Database Server Minimum Software Requirements

................................
...............

5
-
9

Exhibit 5
-
9: Client Workstation Minimum Software Requirements

................................
..........

5
-
9

Exhibit 5
-
10: CCS Interfaces and Movement of Data

................................
..............................

5
-
11

Exhibit 5
-
11: CCS Interface Structure

................................
................................
......................

5
-
12

Exhibit 5
-
12: E300 Personnel Interfaces

................................
................................
..................

5
-
13

Exhibit 5
-
13: HAZMAT PC LAN Interface

................................
................................
.............

5
-
14

Exhibit 5
-
14: H
HMS Interface
................................
................................
................................
..

5
-
15

CCS Security Design Document

30 November 2001



Document Version 1.3

v

Exhibit 5
-
15: PORTACOUNT Interface

................................
................................
..................

5
-
16

Exhibit 5
-
16: ESAM LIMS Interface

................................
................................
.......................

5
-
18

CCS Security

Design Document

30 November 2001



Document Version 1.3

1
-
1

1.


SECTION 1

SCOPE

1.1

Identification

The
Command Core System (CCS) Se
curity Design Document
describes how the CCS program
implements system security within the CCS structure necessary to meet class C2 system
certification. This document also serves as a reference throughout the life cycle of the system
and addresses how sy
stem changes and maintenance affect the integrity of CCS automated
information system (AIS) security. CCS is developed by TRW, Incorporated (Inc.), under the
direction of the Department of the Air Force, CCS Air Force Materiel Command Institute for
Enviro
nment, Safety & Occupational Health Risk Analysis (AFIERA)/RSEC, 2513 Kennedy
Circle, Brooks Air Force Base (AFB), Texas (TX) 78235
-
5123.

1.2

System Overview

CCS was developed for the Air Force (AF) for implementation at bases throughout the world.
Its object
ive is to provide the means for the Air Force to monitor and control the use of
hazardous materials/environments, and to monitor their effect on military and civilian personnel.

The
CCS is a client/server relational database application that provides a bas
e
-
level data
repository and query capability for Environmental, Safety, and Occupational Health (ESOH)
related information at each Air Force base.
The system allows a user to perform all necessary
tasks related to the maintenance, reporting, and use of th
e environmental and medical data
required by an ESOH support organization.
It enables (cradle to grave) tracking of hazardous
processes and their effect on people and the environment. The system is designed to enable
ESOH support organizations to share c
ommon information without duplicating already available
data systems. It will interface with material management information systems for materials issue
and chemical properties information, personnel information systems for demographic
information, medica
l testing and information systems for occupational health information and
waste management information systems for hazardous material disposition information.

The system is modularized to support base
-
level bioenvironmental engineering, occupational
medici
ne, public health, occupational safety, environmental and waste management, air quality,
and pollution prevention functions and organizations. The paragraphs that follow highlight the
various functions provided by the modules.



Air Program Information Mana
gement System (APIMS)

provides an integrated
information system that stores data necessary to comply with Title V of the 1990 Clean
Air Act, and Toxic Release Inventory (TRI) reporting requirements. The APIMS can hold
data on source categories and their s
ources, equipment that relates to each source and
algorithms needed to calculate emissions. The APIMS uses this information to calculate
air emissions on the source categories or sources that are specified by the user.

CCS Security

Design Document

30 November 2001



Document Version 1.3

1
-
2



Employee Demographics

maintains basi
c employee information. Key information
includes the social security number (SSN) or other employee identifier that is used to track
an employee throughout various work assignments, medical screenings, fittings for
protective equipment, and so forth.



Envi
ronmental Sampling

provides options to manage all aspects of environmental
sampling. Environmental sampling tracks the sample from the sample point through lab
analysis. This menu is designed to track different types of samples including, waste water,
po
table water, ground water, soil, and so forth.



Industrial Hygiene

establishes Potential Exposure Groups (PEGs) to categorize
employees or groups of employees that share a common set of potential exposures;
establishes test and training requirements to redu
ce risks associated with accident or
exposure; institutes controls that protect personnel by requiring respirators, hearing
protection, Personal Protective Equipment (PPE), and so forth, based on the PEG
assignment; tracks licensed requirements associated
with various processes and the results
of surveys that monitor the environment and employee health.



Interfaces

provides the system administrator (SA) with rights to set up and run external
interfaces to CCS.



Material Management

tracks material management a
ctivities by recording material
constituents, material inventory, material use, and material issue (in which material is
issued to a person/PEG for use in a specific process). It provides options to prepare
information for TRI reports on chemical release.

Through this menu, information
concerning chemical hazards, accidental exposure, potential hazards, and recommended
treatments for exposure is recorded and tracked.



Occupational Medicine Services (OMS)/Public Health

maintains records of employee
medical
information. The menu includes screens on which to record clinical test
requirements based on a PEG, medical test and audiogram results, and medical testing
requirements.



Pollution Prevention

provides a method of identifying the use of hazardous material
through the review of technical documentation associated with the processes performed.
The menu includes options to identify substances mandated for use in technical manuals,
hazards associated with substance use, and information concerning treatment for
exposure.
It also includes a project management option to manage projects associated with
identifying hazardous substance use and reducing or eliminating the use of given
substances.



Preferences

provides the SA easy access to the preferences table for set
ting up interface
file locations, and other system and database options for their installation.



Preventive Health Assessment

provides a capability to perform preventive health
assessments on employees. This module is still in development.

CCS Security

Design Document

30 November 2001



Document Version 1.3

1
-
3



Program Assessme
nt

provides a tracking system of compliance assessment and
management programs (CAMP). Projects can be opened against each criterion of an
assessment to track progress in resolving discrepancies. The findings of the CAMP
inspection at a base will be ente
red into CCS and updated/tracked on a daily basis by both
the Inspector General's (IG’s) office and the base where the inspection occurred.



Safety

tracks information associated with any incident that might occur at the work site.
All aspects of the incide
nt can be reported, including medical results and resultant
compensation.



Shared Functions

provides general functions needed by users of different CCS modules.
These functions include screens to identify unique processes, maintain organizational data,
rec
ord accounting (with cross billing tracking) transactions, establish training course
requirements, track employee work assignments, record employee attendance, monitor
equipment use, and track shop visits.



Waste Management

provides options to manage all as
pects of hazardous waste
generation, movement, and disposal. Hazardous waste includes materials that, either alone
or combined, are hazardous and must be disposed of by way of a regulated process.



User Management

provides management of CCS user accounts.
These functions include
account creation, deletion, unlock, lock, password change, force password change and
assignment of roles.

Operated by Air Force military and civilian employees, and occasionally by Air Force
contractors, the CCS database server oper
ates on a 24
-
hour
-
per
-
day, 7
-
days
-
a
-
week
-
basis,
supporting external system interfaces and functional user workstations.

CCS Security

Design Document

30 November 2001



Document Version 1.3

1
-
4

1.3

Document Overview

This document is a resource to ensure that the CCS development team meets Government
-
trusted
systems requirements duri
ng system design and during significant changes throughout the life
cycle.

This document provides the following information:



Describes CCS



Explains how security is implemented within the CCS structure



Explains how the security safeguards satisfy the protec
tion objectives



Explains how CCS meets the Trusted Computer System Evaluation Criteria (TCSEC)
class C2 requirements defined in Department of Defense (DoD) 5200.28
-
Standard
(STD)



Illustrates the CCS security system design



Summarizes the CCS security philos
ophy and policy

The contractor, TRW, INC, handles DBA functionality. The only DBAs are located at the CCS
development site due to the constant change of personnel at operational sites. Hill AFB
personnel may perform system administration functions as req
uested by the DBA team.
Technical responsibilities at operational sites are handled by SAs.

1.4

Document Organization

This document

is organized as follows:



Section 1 identifies CCS, its background, the document, and the organization of the
document.



Section
2 lists the documents, guides, and manuals referred to or used to produce this
document.



Section 3 describes CCS’ security policy and CCS’ philosophy of protection.



Section 4 describes the security design, features, and network. It defines the C2 and
DoD
security requirements and describes how CCS’ system security mechanisms
satisfy the requirements.



Section 5 provides a technical description and describes the CCS system.



Section 6
describes access levels of trust and CCS’
Discretionary Access Control

(DAC
).

CCS Security

Design Document

30 November 2001



Document Version 1.3

1
-
5



Section 7 contains general information that aids in understanding this document.



Annex A identifies all abbreviations, acronyms, and terms used in this document.



Annex B contains a reproducible form for users to make recommended corrections,
changes, an
d comments for future versions of this document.

CCS Security

Design Document

30 November 2001



Document Version 1.3

2
-
1

2.


SECTION 2

REFERENCED DOCUMENTS

2.1

References

The
CCS Security Design Document
was developed using the following documents:



Air Force Instruction (AFI) 33
-
202,
Communication and Information

Computer
Security
,
1 February 1999



Air Force Systems Security Instruction (AFSSI) 5021,
Vulnerability and Incident
Reporting
, 15 August 1996



Air Force Policy Directive (AFPD) 31
-
1,
Security

Physical Security
, 1 August 1995



AFPD 31
-
4,

Security

Information Security
, 1 Septembe
r 1998



AFPD 31
-
5,
Security

Personnel Security Program Policy
, 1 August 1995



AFPD 33
-
1,
Communications

Command, Control, Communications, and Computer
(C4) Systems
, 17 September 1993



AFPD 33
-
2,
Communication and Information

Information Protection
, 1 December

1996



AFPD 37
-
1,
Information Management

Air Force Information Management
, 19
November 1993



Air Force Systems Security Instruction (AFSSI) 5024,
Volume I, The Certification
and Accreditation (C & A) Process
, 1 September 1997



AFSSI 5024,
Volume II, The Certi
fying Official's Handbook, 1 September 1997 AFI
31
-
401, Information Security Program Information

Information Security Program
Management
, 1 January 1999



AFSSI 5024,
Volume III, Designated Approving Authority Guide
, 1 March 1999



CCS Computer Operator’s Manu
al
, Version 4.4, 30 November 2001



CCS Security Policy
, 1997



CCS System Administrator User Guide
, Version 4.4, 30 November 2001



CCS System Security Authorization Agreement
, 30 November 2001

CCS Security

Design Document

30 November 2001



Document Version 1.3

2
-
2



CCS Trusted Facility Manual
, 30 November 2001



Computer Security Cen
ter (CSC)
-
STD
-
003
-
85,
Computer Security Requirements
, 25
June 1985



Department of Defense (DoD) 5200.28
-
STD,
DoD Trusted Computer System
Evaluation Criteria (TCSEC)
, December 1985



DoD Military Terms
, 7 August 1999



DoD 5400.7
-
R,
DoD Freedom of Information Ac
t Program
, September 1998



DoD Directive (DoDD) 5200.28
-
STD,
Department of Defense Standard
-

Trusted
Computer System Evaluation Criteria
, December 1985



DoDD 5400.7,
DoD Freedom of Information Act Program
, 24 April 1980



DoDD 5200.28,
Security Requirements f
or Automated Information Systems (AISs)
, 21
March 1988



DoDD 5200.28,
Security Requirements for Automatic Data Processing (ADP)
Systems
, Revised June 1979



DoDD 5200.28
-
STD,
Department of Defense Trusted Computer System Evaluation
Criteria
, (Supercedes CSC
-
S
TD
-
001
-
83, dated 5 August 1983), December 1985



DoDD 5400.11
-
R,
Department of Defense Privacy Program
, August 1983



Federal Information Processing Standards Publication (FIPS Pub) 31,
Guidelines for
Automatic Data Processing Physical Security and Risk Manage
ment
, June 1974



FIPS Pub 97,
Guidelines for ADP Security Design Document Planning
, 27 March
1981



Joint Publication 1
-
02,
Joint Doctrine Division, J
-
7, Joint Staff, DoD Dictionary of
Military and Associated Terms
, 19 October 1999 (Web site)



Military Health
System (MHS),
Automated Information System (AIS) Security Policy
Manual
, April 1996



National Computer Security Center (NCSC), NCSC
-
TG
-
005,
Trusted Network
Interpretation of the Trusted Computer System Evaluation Criteria
, 31 July 1987



NAVSO P
-
5239
-
15,
Cont
rolled Access Protection (CAP) Guidebook Module 15,
Information Systems Security (INFOSEC) Programming Guidelines
, December 1994



NCSC, NCSC
-
TG
-
0027,
A Guide to Understanding Information System Security
Officer’s Responsibilities for Automated Information S
ystems
, Version 1, May 1992

CCS Security

Design Document

30 November 2001



Document Version 1.3

2
-
3



NCSC, NCSC
-
TG
-
007,
A Guide to Understanding Design Documentation in Trusted
Systems
, Version 1, 2 October 1988



Office of Management and Budget (OMB) Bulletin No. 90
-
08,
Guidance for
Preparation of Security Plans for Federal Comp
uter Systems that Contain Sensitive
Information
, 9 July 1990, Section III. E,

Security Control Measures for Major
Applications
, February 1996



OMB Bulletin No. 90
-
08,
Guidance for Preparation of Security Plans for Federal
Computer Systems that Contain Sensi
tive Information
, 9 July 1990



Office of the Assistant Secretary of Defense (Health Affairs) OASD(HA), Defense
Medical Information Management Automated Information Systems (AIS) Security
Team,
Military Health Services System (MHSS) Automated Information Sys
tem
Security Policy Manual
, Version 1.0, April 1996



Public Law 100
-
235,
Computer Security Act of 1987
, 1987



Special Publication 8
-
00
-
12, National Institute of Standards and Technology (NIST),
Technology Administration, U.S. Department of Commerce,
An Intro
duction to
Computer Security: The NIST Handbook
, October 1995

CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
1

3.


SECTION 3

STATEMENT OF POLICY

3.1

Introduction

This section describes CCS security policy and CCS’ philosophy of protection.

3.2

Security Policy Summary

A security policy is the set of laws, rules, a
nd practices that regulates how an organization
manages, protects, and distributes sensitive information. CCS is required to implement
automated system security safeguards that satisfy the regulations and directive requirements.
The following documents p
rovide a detailed explanation of the security requirements and control
measures:



DoDD 5200.28,
Security Requirements for Automatic Data Processing (ADP)
Systems
,

Enclosure 3, Minimum Security Requirements



DoD 5200.28
-
STD
,

Section 2.2 Class (C2),
Controlled

Access Protection



NCSC
-
TG
-
005
,

Section 2.2 Class (C2),
Controlled Access Protection



OMB Bulletin No. 90
-
08,
Guidance for Preparation of Security Plans for Federal
Computer Systems that Contain Sensitive Information
, Section III.E, S
ecurity Control
Measure
s for Major Applications

CCS security safeguards must be designed to ensure:



Accountability

authorized users are held responsible for their actions



Availability

the system and its data are available for the intended use



Confidentiality

of sensitive system
data



Data Integrity

system data is protected against unauthorized modification

Additionally, CCS’s communication services are required to be properly configured to mitigate
risks associated with unauthorized intrusion and modifications from external system

interfaces
and network connections. Furthermore, procedural controls must be implemented at each ESOH
organization to ensure CCS system security safeguards are properly implemented and maintained
throughout the system’s life cycle.

CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
2

3.2.1

System Philosophy of P
rotection

Although CCS does not process classified data, diligent care is taken to avoid accidental release
of the unclassified but sensitive data (including Privacy Act data). Media may be cleared by
overwriting the media once with binary zeros or binary

ones. For specific instructions dealing
with purging and clearing media, refer to Air Force Systems Security Instruction (AFSSI) 5020,
Remanence Security
.

CCS operates in the System High Security Mode wherein each user, with direct or indirect
access to
the system, its peripherals, remote terminals, or remote hosts, has all of the following
attributes:



Approved clearing procedures for equipment are performed prior to releasing the
equipment for off
-
site maintenance.



Approved maintenance procedures for CCS

resources. Prior notification and
approval must be obtained from the security manager for all maintenance activities
before they begin. Maintenance personnel in training are supervised by a trained
technician when working on CCS resources.



Formal access

approval and signed non
-
disclosure agreements for all the information
stored and/or processed. A copy of the Command Core System User
Agreement/Account Request is contained within the
CCS Trusted Facility Manual
,
the CCS release compact disc
-
read only me
mory (CD
-
ROM,) and the CCS web site.
New users may download and complete a Portable Document Format (PDF) copy of
the form from the CCS web site.



Valid need
-
to
-
know for some of the information handled by CCS.



Valid security clearance (none currently requi
red) for all information within CCS
(unclassified).

The security system is structured according to the configuration of the system equipment and the
need
-
to
-
know operations of its users. Its design addresses the risks to each component, and
limits access
to functions and the database as is appropriate for the need
-
to
-
know level of each
user category. Only capabilities appropriate to users’ role are accessible by users. Menus and
forms are visible, but data are not.

The configuration consists of the follo
wing:



Database of environmental health and safety information



External access by way of military network (MILNET) supports communications
between the CCS development site and the database server

CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
3



Internal network that supports communication between the oper
ational site user and
the database server



Operating systems (OS) that run the database and application

Because of CCS' equipment and personnel components, the security design is structured to
safeguard the following:



Access to the database



Application secu
rity



Corruption of the database



Database security



Physical security of the hardware

The categories of users consist of the following:



Database Administrator (DBA)



User



Operational Site SA

The data protection objectives for user authorization requirements a
nd constraints are as follows:



Ensure data availability on a timely basis



Protect data from unauthorized disclosure



Protect data from unauthorized, unanticipated, or unintentional modification

CCS enforces this philosophy by using evaluated products, comme
rcial off
-
the
-
shelf (COTS)
products, system development, and documented procedures. All activities inside the AIS are
protected by this enforcement.

CCS relies on the diligence of the operational site SA, the development team DBA, and the
network site adm
inistrator to monitor the (OS), database server, and interface processing and all
other CCS activities. These typically include passive monitoring, firewalls, and physical
security.

The CCS operational site servers provide for receipt and timely distribut
ion of data entrusted to it
in a manner that is sufficiently error
-
free and physically secure. CCS procedures perform code
or format conversion that preserves the integrity of data and controls information. Personnel,
physical, and administrative securit
y mechanisms applied to CCS minimize risks of denial of
CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
4

service and unauthorized disclosure. Within its available resources, CCS provides uninterrupted
continuity of operations.

CCS requirements for Class (C2),
Controlled Access Protection,

are verified d
uring CCS' test
and evaluation phases. These requirements apply to the development, testing, and operational
CCS systems processing functional
not classified but sensitive
information in the System High
Security Mode of operation. As a minimum, the follo
wing Class C2 evaluation criteria (cited in
DoD 5200.28
-
STD) apply:



Documentation

Design Documentation, Security Features User Guide, Test
Documentation, and Trusted Facility Manual



Life
-
Cycle Assurance

Security Testing



Operational Assurance

System Archite
cture and System Integrity



Security Policy

DAC, Object Reuse, Identification and Authentication (I&A), and
Audit

3.2.1.1

Policy fo
r

Software Maintenance

All original software copies are write
-
protected, inventoried, and kept in a secure location.
Backups of criti
cal files on the servers are made weekly. Critical files include security
-
related
and audit files, as well as those files designated as critical by operational personnel. Full
database backups are performed nightly or before installing and configuring ne
w software. All
backups are stored at a secure off
-
site location.

3.2.1.2

Backing Up Files and Schedules for Backups

The schedules for the backups are as follows:



Daily

CCS keeps one week of daily backup tapes. One tape is labeled for each day
of the week (Monda
y through Friday). The operational site SAs are responsible for
creating the backup tapes.



Monthly

On the last day of the month, the operational site SA pulls the backup tape
and replaces it with a new tape. This monthly tape is verified before being arc
hived
offsite. The operational site SA is responsible for pulling the backup tapes and
labeling them. Monthly tapes are kept for one year.

The
Hewlett Packard (HP)
-
UNIX (
UX) (HP
-
UX) server is configured to automatically export the
database and copy the e
xport (dmp) file and log files to the tape. It is the operational site SA’s
responsibility to ensure that the tapes are changed according to the above schedule.

CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
5

3.2.1.3

System Recovery

CCS is a historical database in that data input into CCS is not deleted. Ther
efore, the purpose of
the export tapes is for data recovery, not long
-
term storage/archive. If a recovery is required, the
system is rebuilt using the HP
-
UX and ORACLE software. The database is then recovered from
the latest export tape using the ORACLE
import utility.

Backups are clearly identified with detailed descriptions and date information, thus ensuring that
the correct backups are used to recover the database. A log is maintained to record the access,
the date, the tape retrieved, and the purpos
e of the required tape. After the restoration has been
successfully completed, the tape is “Entered” to the on
-
site safe or off
-
site location and the log
annotated.

3.2.1.4

Minimum and Maximum User Clearances

CCS users have authorized access either by an explicit

official authorization or by an implicit
authorization derived from official assignments or responsibilities (DoD Directive 5400.7,
DOD
Freedom of Information Act Program
, 24 April 1980).

CCS users are personnel with the ability to log onto CCS or systems

connected to CCS. They
include the operational users, administrators, and maintainers of CCS systems and components.
All users will comply with CCS security policies and procedures and will report security
problems to their respective security manager.



CCS Operational Sites

CCS operational site users (direct users), with access to CCS
components and data, are not required to have security clearances, but generally have
at least a SECRET clearance by virtue of their related duties. Regardless of their
cl
earance level, further access restrictions are imposed by the system because all
authorized users do not have the need
-
to
-
know all CCS information. CCS users are
authorized system access based on a valid functional need
-
to
-
know. Security
clearances are n
ot required for indirect users of CCS information, other than a
favorable National Agency Check (NAC).



CCS Development Team

CCS is developed in a closed environment. Personnel are
active participants during all phases of development. Application develope
rs have
sufficient clearances and/or authorizations to preclude introduction of malicious logic
into the application. Anytime a person is terminated or has suspicious activity, their
access rights immediately revoked. For every new software release, all
user accounts
are reviewed and new access accounts created.

CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
6

3.2.1.5

Connecting to CCS

Users’ connections to CCS are governed by regulations and CCS’ policy outlined in the
CCS
Security Policy

document. System or network designated approving authorities (DAAs) tha
t
need connection to CCS, must review the capabilities and limitations of CCS in terms of the
security services or capabilities provided (or not provided), as identified in formal risk analysis
and accreditation documentation. The CCS DAA cooperatively pr
ovides risk analysis and
accreditation information, as necessary, to assist the requesting DAA.

Classified system DAAs requiring connection to CCS to exchange
unclassified
or

not classified
but sensitive
information with CCS provides assurance to the CCS D
AA that the interface is one
-
way only and that classified data cannot contaminate CCS. The responsibility for ensuring the
integrity of a one
-
way interface rests with the classified system DAAs. In each and every
instance, any one
-
way interface from CCS
to a classified system is mediated by at least a Class
B1 device (DoD 5200.28
-
STD).

System or network DAAs desiring connection provide the CCS DAA with a Memorandum of
Agreement (MOA) or Memorandum of Understanding (MOU) which includes, at a minimum,
data
description and classification; user clearance levels; name of the cognizant DAA
empowered to resolve conflicts; intended recipients of transmitted data, and the security
mechanisms to be implemented before connecting to CCS. Security mechanisms enforce t
wo
fundamental rules:



They protect data from disclosure or alteration as data exchanges occur between CCS
and the connected system.



They are in place to protect CCS and its authorized users from unauthorized access by
way of the connected network or system
.

The CCS DAA approves the connectivity of systems or networks to or through CCS. A
representative MOA or MOU for each system or network connectivity to CCS is contained in the
CCS System Security Authorization Agreement (SSAA)
.

3.2.2

CCS Protection

User identi
fications (IDs), passwords, and DAC protect and preserve the accountability,
availability, confidentiality, and integrity of CCS and the information it contains.

Unless additional software is loaded on the personal computer (PC), the only way the user can
access CCS is through the application. With additional software, a user can access CCS through
SQLPLUS and Open Database Connectivity (ODBC) connections. Regardless of the connection
method, access to the data is controlled with the parameters establishe
d in the DAC.

The following sections describe the security requirements and additional security measures that
are applicable to each area.

CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
7

3.2.2.1

Accountability

Accountability enables system activities to be traced to individuals, who then may be held
responsible

for any activity that adversely affects system security. This security area is
supported by audits and by I&A. For additional information, refer to Section
4.4.2
,
Accountability
.

3.2.2.2

Confidentiality

Con
fidentiality is the concept of holding sensitive information in confidence, limited to
appropriate individuals or a group of individuals, to safeguard against unauthorized disclosure.
This security area is supported by the following security requirements:

access, data continuity,
DAC, least privilege, markings, object reuse, physical controls, and security testing.

3.2.2.3

Integrity

Integrity is the concept of protecting information from unauthorized, unanticipated, or
unintentional modification. It ensures that
a system performs, as it should, free from
unauthorized, deliberate, or inadvertent manipulation or tampering. The following security
requirements support system integrity: access, data continuity, data integrity, DAC, least
privilege, physical controls,
system architecture, and system integrity.

3.2.3

Policy Objectives

By following the policy objectives listed in
Exhibit
3
-
1
,
Policy Objectives Table
, the system and
its information are protected against loss, m
isuse, unauthorized access, disclosure or
modification, unavailability, and undetected activities.

Policy
Objective

Description

A

Users are held accountable for their actions.

B

User access to the system and its information is controlled using automated
and manual methods.

C

All reported and suspected security incidents can and should be investigated
and resolved in a timely manner.

D

All security mechanisms accurately mediate and enforce the system security
policy.

E

Users and SAs understand the secur
ity features and functions and are made
aware of their security responsibilities.

F

Users can access only information to which they are entitled.

CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
8

Policy
Objective

Description

G

All media and printed material are handled in a manner appropriate to the
sensitivity of the information t
hat they contain.

H

Security functions are maintained continuously during interrupted service,
and the system can be recovered in a timely manner.

I

All hardware and software function accurately at all times.

J

The system meets mission requirements on a

timely basis.

K

The information is held in confidence and limited to those who have a need
-
to
-
know.

L

The data are free of errors during processing and transmission.

M

Each user is uniquely and positively identified to the system before access is
grant
ed.

Exhibit
3
-
1
: Policy Objectives Table

CCS Security

Design Document

30 November 2001



Document Version 1.3

3
-
9

3.2.4

Policy Requirements

Exhibit
3
-
2
,
Policy Requirements Table
, outlines the security requirements that address the
p
olicy objectives listed in
Exhibit
3
-
1
,
Policy Objectives Table
.

Security Requirement

Policy
Objective(s)

Access

B, K, M

Accountability

A

Audit

A, C, M

Contingency Planning

H, J

Data Continuity

K

Da
ta Integrity

L

DAC

B, F, K

Documentation

E

I&A

A, B, M

Least Privilege

F, K

Marking

G

Object Reuse

B, F

Physical Controls

B

Risk Management

H, J

Security Testing

D

Security Training and Awareness

E, G

System Architecture

D, L

System Integrity

I

Exhibit
3
-
2
: Policy Requirements Table

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
1

4.

3.


SECTION 4

SECURITY REQUIREMENT
S AND CCS SECURITY D
ESIGN

4.1

Introduction

This section describes the security design, features, and network. It defines the C2 and Do
D
security requirements and describes how CCS’ system security mechanisms satisfy the
requirements.

4.2

Security Description

Specific Government requirements mandate the enforcement of the security of an AIS. C2 is a
minimum
-
security class that is required fo
r the CCS system. A system operating at a C2 level of
trust must enforce DAC and users accountable for their actions through logon procedures,
auditing of security
-
relevant events, and resource isolation.

To be certified and accredited for this security c
lass, CCS must be evaluated to determine how it
meets the security requirements. Evaluation testing is performed internally and then by assigned
OASD (HA) evaluators. The CCS system is evaluated using the NCSC guidelines for
implementing OSs in a C2 mann
er. For more information on the security testing, refer to the
CCS Security Test Plan and Test Description

and the
CCS Security Test Report
. DoD 5200.28
-
STD,
DoD Trusted Computer System Evaluation Criteria,

and DoDD 5200.28,
Security
Requirements for Aut
omated Information Systems
outlines these requirements.

The CCS assets consist of hardware and software from standard Air Force and DoD contracts.
At all sites, the central database server is a HP 9000/D
-
220, with a HP
-
UX OS. Peripheral
equipment associa
ted with the central server includes a system console and may include an
uninterruptable power supply (UPS). CCS utilizes an ORACLE Relational Database
Management System (RDBMS), associated Structured Query Language (SQL) facilities, and
support tools.

To

access CCS, PC workstations
(note: it is up to each local facility to provide the operating
systems for end users)

operate under Microsoft Windows 95, Windows NT 4.0, or Windows
2000, and run ORACLE applications with a suite of supporting ORACLE tools to

access the
central database. To view the client, server, and network relationship, refer to
Exhibit
4
-
1
,

CCS
Network Topology
.

CCS users interface with CCS from the client workstations. The ORACLE RDBM
S and
associated NET8 software provide a client
-
server session to enable the user to access the
centralized database on the HP
-
UX. The HP
-
UX automates all transactions exchanged with
systems external to CCS. To view a graphical representation of the clie
nt
-
server architecture and
the network communications connectivity, refer to
Exhibit
4
-
1
,

CCS Network Topology
.

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
2

Base ETHERNET
MILNET
Base Firewall
Database Server
Base Network Server
Users (Client) PC
Users (Client) PC
Users (Client) PC
CCS Topology
TCP/IP Wrapper

Exhibit
4
-
1
:
CCS Network Topology

4.2.1

Security Design

CCS security safeguards are implemented by different elements of the system. CCS security
controls are integrated to ensure protection of the system, the data processed, and the data stored
by the system. The compilat
ion of system security safeguards comprises the CCS Trusted
Computing Base (TCB). In addition to the security safeguards inherent to CCS, the
Transmission Control Protocol/Internet Protocol (TCP/IP) wrappers, operational site firewalls,
and client worksta
tions’ OSs provide complimentary safeguards. Complementary saf
e
guards are
considered those security controls that are an integral part of another system and enhance the
protection of another system.

CCS design includes control points at each system interf
ace, within the system to minimize the
potential for unauthorized access, input of invalid data, and unauthorized data manipulation. The
automated system provides the following security functions:



Audit trails for tracking changes to CCS data



Certified C2

level of trust

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
3



Restricted level of access by user role



User ID and password
-
controlled user access



TCP/IP wrapper

4.2.2

Security Features

CCS security mechanisms provide protection in the following ways:



Auditing



DAC



I&A



Network Security

4.2.3

Network Communications
Security Design

CCS operational sites use their base’s internal network to communicate. All outside
communications go through the base firewall. Communications outside the operational site use
the MILNET. The CCS development team uses their internal net

to communicate with each
other. Any communications between the CCS development team and CCS operational sites are
accomplished through the MILNET. The development team supports the operational sites as a
Tier 3 help desk. This requires access to the pr
oduction instance to perform troubleshooting.
Upgrades are performed to the system by the development team. When a new operational site is
installed, CCS receives authorization from the base to route through the base firewall and
establishes a static rou
te for communications to the base using the MILNET. To view a graphic
of the network security design, refer to

Exhibit
5
-
7
,
CCS Software Architecture
.

4.3

C2 Security Requirem
ents

C2 security requirements derived from DoD 5200.28
-
STD serve as the foundation for the CCS
system certification and accreditation. The following paragraphs address each of the C2 security
requirements and state how CCS meets the requirements. The com
pilation of system security
safeguards implemented within the CCS application establishes the CCS TCB.

4.3.1

Audit

C2 Security Requirement

Auditing provides the capability to record successful and
unsuccessful events associated with individual users and the date

and time the event occurs.
Access to audit data must be restricted to authorized personnel and must be protected against
unauthorized access and destruction.

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
4

CCS Auditing

The combined secure auditing features of the HP
-
UX OS and the ORACLE
database softw
are are fully compliant with the C2 level security requirements established by the
National Computer Security Center, the Trusted Computer Systems Evaluation Criteria, and the
Trusted Database Interpretation.

CCS performs two levels of audit: server and a
pplication. Both audit logs are reviewed to
ensure the integrity of the system and the application. The application is monitored through the
ORACLE audit function. Intruder Alert, installed on all HP
-
UX servers, audits SSH connections
and failures.

CCS
auditing generates records of user activity for the following purposes:



Assess potential security damage



Detect unauthorized access attempts



Detect unusual or suspicious user actions



Deter illegal activity by warning users that their actions will be audite
d



Identify specific users performing suspicious actions



Provide evidence in investigations

4.3.1.1

ORACLE Audit Function

In ORACLE, all of the audit records are stored in the sys.aud$ table. ORACLE creates various
views of the sys.aud$ table to facilitate ease of

review. Three of these views are
DBA_AUDIT_OBJECT, DBA_AUDIT_STATEMENT, and DBA_AUDIT_SESSION.
Auditing is vital to the security of the ORACLE database and the system. Audit information
enables the development team DBA and operational site SA to monito
r who is using the system.
Both success and failure events are recorded. Regular reviews of the audit records are carried
out to detect unauthorized attempts to log in or attempts to exceed assigned permissions. Audit
logs are written to until the file
system is full. At this time, error messages will alert the SA of
the problem. When the log file is full it will not overwrite itself. All log files are archived
weekly on the system and the system maintains four weeks of logs. The logs and archives ar
e
backed up to tape daily. Each SA are required to establish tape rotation procedures to retain the
required data for six months.

CCS operational site SAs and the development team DBA perform the following auditing
functions:



Access the Audit Tables and V
iews

The ORACLE audit table is accessed and
reviewed.

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
5



Back Up the Audit Files

The audit table is backed up automatically with the daily
export files. Events older the 30 days are removed from the system. If events older
than 30 days need to be reviewed,
they are recovered from the export files.



Load Saved Audit Files

If it is necessary to view an event log table that is older than
what is stored in the database, the sys.aud$ table is restored from the monthly backup
tape.

The ORACLE database uses a native

auditing mechanism that provides accountability for
modifications to database objects. The following events are audited for all users:



Create role



Create user



Grant/revoke role



Open database

The events ORACLE captures are identified in Exhibit 4
-
2, Event
s ORACLE Auditing is
Configured to Capture.

ORACLE Event

Success

Failure

Logon and Logoff

X

X

Object Access (performed when required)

X

X

User and Group Management

X

X

Security Policy Changes

X

X

Database Restart, Shutdown, and System

X

X

Exhibit
4
-
2
: Events ORACLE Auditing is Configured to Capture

The events the CCS application’s logging table logs as they occur in the CCS application are
identified in Exhibit 4
-
3, CCS Application Logging (ORACLE).

Log
ging Table Item

Description

1


CREATE TABLE

9


CREATE INDEX

10


DROP INDEX

11


ALTER INDEX

12


DROP TABLE

13


CREATE SEQUENCE

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
6

Log
ging Table Item

Description

14


ALTER SEQUENCE

15


ALTER TABLE

16


DROP SEQUENCE

21


CREATE VIEW

22


DROP VIEW

30


AUDIT OBJECT

31


NOAUDIT OBJEC
T

32


CREATE DATABASE LINK

33


DROP DATABASE LINK

43


ALTER USER

51


CREATE USER

52


CREATE ROLE

53


DROP USER

54


DROP ROLE

55


SET ROLE

79


ALTER ROLE

100


LOGON

101


LOGOFF

102


LOGOFF BY CLEANUP

110


CREATE PUBLIC SYNONYM

112


CREATE PUBL
IC DATABASE LINK

113


DROP PUBLIC DATABASE LINK

114


GRANT ROLE

115


REVOKE ROLE

Exhibit
4
-
3
: CCS Application Logging

(ORACLE)

NOTE:

To view a table that shows the events that are recorded in the CCS log
ging table, refer
to
Exhibit
4
-
5
,
ORACLE Con
nection Audit Log
, and to view the actual text that is
recorded for those events, refer to
Exhibit
4
-
6
,
ORACLE Audit Log
.

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
7

CCS application’s logging table logs the following events on an “as required basis”. These
actions can be selectively audited by a user as they occur in the CCS application. Th
ese actions
should not be routinely audited due to the large amount of data that they will generate. To view
the logging table items, refer to Exhibit 4
-
4, CCS Application Selective Logging (ORACLE).

Logging Table Item

Description

2


INSERT

3


SELECT

6


UPDATE

7


DELETE

Exhibit
4
-
4
: CCS Application Selective Logging
(ORACLE)

NOTE:

To view a table that shows the events that are recorded in the CCS logging table, refer
to
Exhibit
4
-
5
,
ORACLE Con
nection Audit Log
, and to view the actual text that is
recorded for those events, refer to
Exhibit
4
-
6
,
ORACLE Audit Log
.

To view an example of the ORACLE connection audit log, refer to
Exhibit
4
-
5
,
ORACLE
Con
nection Audit Log
.


Exhibit
4
-
5
: ORACLE Con
nection Audit Log

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
8

To view an example of the audit log, refer to
Exhibit
4
-
6
,
ORACLE Audit Log
.


Exhibit
4
-
6
: ORACLE Audit Log

4.3.1.2

UNIX Audit Function

In HP
-
UX
, all of the audit records are stored in the /var/adm/syslog directory. Auditing is vital
to the security of the computer system. Audit information enables the operational site SA and
the development team DBA to monitor who is using the system and what m
odules of the system
are accessed. Both success and failure events are recorded. Regular reviews of the audit records
are carried out to detect unauthorized attempts to log in or attempts to exceed assigned
permissions.

CCS operational site SAs and the d
evelopment team DBA performs the following auditing
functions:



Access the Audit Files

The ORACLE audit table is accessed and reviewed.



Back Up the Audit Files

The UNIX audit log directory is backed
-
up daily by way of
an automated Cron job and saved to tape
. On the 7
th
, 14
th
, 21
st
, and 28
th

of the month,
the backup logs are archived to the backup directory, cleared, and reset. The
directory is copied to the backup tape daily to ensure there is always a backup
directory. The audit logs are copied to the ta
pes as well as to the UNIX backed up
event logs located in directory: “/var/adm/syslog/week#”. The # equals the week of
the month. UNIX audit logs are available online for only a period of 4 weeks. If an
audit log older than 4 weeks needs to be reviewe
d, the archived tapes are used.



Load Saved Audit Files

Event logs are backed up every week. Audit logs older
than 4 weeks are stored on the regular system backup tapes. If review of audit
information more than 4 weeks old is required, files from tape mus
t be restored.

UNIX uses the auditing capability of the native logging functions and the TCP/IP wrapper. The
wrapper is a utility program that wraps around the server to provide additional protection. The
following events are audited for all users:

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
9



Conne
ctions and connection type (maillog)



Failed login attempts (lastb)



FTP commands, Internet Protocol (IP)/Domain Name System (DNS), connection
type, boot screens (message file)



Security concerns, user attempts, promotion attempts, refused connections (securi
ty)



System failures (spooler)



System level message, failed connections, users’ automatic actions

The events UNIX captures are identified in
Exhibit
4
-
7
,
Events UNIX Auditing is Configured to
Capture T
able
.

UNIX Event

Success

Failure

Logon and Logoff

X

X

User and Group Management

X

X

Security Policy Changes

X

X

Restart, Shutdown, and System

X

X

Exhibit
4
-
7
: Events UNIX Auditing is Configured to Capture T
able

To view a sample of the failed login attempts, refer to
Exhibit
4
-
8
,
UNIX Lastb File
.


Exhibit
4
-
8
: UNIX Lastb File

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
10

To view a sample of the connectio
ns and connection type, refer to
Exhibit
4
-
9
,
UNIX Maillog
File
.


Exhibit
4
-
9
: UNIX Maillog File

To view a sample of the FTP commands, IP/DNS, connection
type, boot screens, refer to
Exhibit
4
-
10
,
UNIX Messages File
.


Exhibit
4
-
10
: UNIX Messages File

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
11

To view a sample of the security concerns, user attempts,

promotion attempts, refused
connections, refer to
Exhibit
4
-
11
,
UNIX Security File
.


Exhibit
4
-
11
: UNIX Security File

To view a sample of the system fail
ures, refer to
Exhibit
4
-
12
,
UNIX Spooler File
.


Exhibit
4
-
12
: UNIX Spooler File

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
12

To view a sample of the system level messages, failed connections, users’

automatic actions,
refer to
Exhibit
4
-
13
,
UNIX Sylog File
.


Exhibit
4
-
13
: UNIX Sylog File

4.3.1.3

Intruder Alert

Intruder Alert is an intrusion detection system
installed on the CCS server. This system monitors
changes to critical files on the HP server. This software has three components: agent, manager,
and client. The Agent and Manager are installed on the HP server. The Client is installed on the
SAs deskt
op. The Client monitors audit tampering, failed login attempts, file tampering, and
logins at the Unix level. All of these events can be viewed from the same screen. The query
can be adjusted so that only one type of event is viewed at a time or all ev
ent types are viewed
for a specific time period.

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
13

To view a sample of the Intruder Alert event viewer see
Exhibit
4
-
14
: Intruder

Alert Event
Viewer Screen
.


Exhibit
4
-
14
: Intruder

Alert Event Viewer Screen

4.3.2

Discretionary Access Control

C2 Security Requirement

DAC defines and controls access between users and objects (that is,
files and directories). DAC ensures objects are protected against unauthorized access. The DBA
and operati
onal site SA assign access to objects by authorized users.

CCS DAC

There are two methods for controlling DAC in CCS. The HP
-
UX OS has DAC that
is in effect when logging in from the system console or using SSH to the server. The CCS
application also has i
ts own set of DAC user roles that control a user’s actions when logged in to
the application.

DAC is based on associating privileges with a group (HP
-
UX groups) and then adding users to
the group. When UNIX in installed on the HP, it creates numerous grou
ps. Access to files can
be controlled by group or by the individual user ID. These groups are used to administer the
accounts on HP
-
UX and control the ORACLE software on the server. Installed UNIX groups
that are not utilized by CCS are deactivated or d
isabled. The unused groups will have no
CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
14

members. CCS users do not need a UNIX account to access the CCS application. The
operational site SA is a member of both the ORA_ADM group and the INTERFACE group. The
operational site SA group was created so that

operational site SAs could perform the following:
shut down and start up the server, check to see that the Transparent Network Substrate (TNS)
listener is operational, manage interface data in which they have access to, perform system
backups, and applic
ation export. Only the development team DBA has full access for managing
the server and the database.

The operational site SA is responsible for providing physical security as well as data security.
The operational site SA maintains on file all signed us
er agreements (
Command Core System
User Agreement/Account Request
) for all users accessing the system. The agreement covers both
AFB procedures and C2 level security issues. Users are categorized on a need
-
to
-
know basis and
are assigned the lowest securi
ty group consistence with their work requirements. All accounts, at
a minimum, change their passwords every 90 days. Users cannot reuse previously used
passwords. Currently, DBAs must change their password when initially logging onto the
console but sho
uld change their password at their first login. User privileges will be suspended
by the system after the account has been inactive for a period of 90 days.

When a user’s password is changed by the operational site SA or development DBA, it will
automatic
ally expire requiring the user to change the password upon connecting to the system.
Users are instructed not to log into the application from more than one PC at the same time.

The CCS application has a user role set for each user ID. When the user logs

into the
application, the role is used to control access to CCS functionality. Only capabilities appropriate
to user’s role are accessible. Though menus and forms are visible, no data is displayed when
forms are queried.
Database forms are stored on th
e general network. The CCS SAs are the only
users who can grant permissions to the directory.
The available roles are built into the CCS
application and cannot be modified by personnel on site. Thus, DAC is an integral piece of CCS.
The operational sit
e SA needs only decide what roles are to be assigned to specific users within
CCS.

The CCS application utilizes

users, roles, and passwords to control users access to system
functionality (objects).
CCS is an “object” based system. As an object
-
based sys
tem, ownership
and access to all objects (for example, files and programs) are controlled by the security
mechanisms of ORACLE’s RDBMS. DAC is enforced within CCS by ORACLE roles. Only
individuals with system administration privileges can grant access to

the CCS tables. CCS SAs
a
s
sign user privileges during the establishment of individual accounts. Individual users granted
privileges to access certain tables based on their inclusion within a specific role. CCS u
s
ers are
granted roles; the roles in turn

grant select, insert, update, delete, and execute privileges to
certain objects. However, users do not own any system objects and cannot grant access or
privileges to other users. With the exception of the multi
-
purpose client workstation, users do
not
have personal storage space on the system servers. Consequently, DAC is implemented and
controlled by CCS SAs.

ORACLE provides extensive security features in order to safeguard information from both
unauthorized viewing and intentional or inadvertent dama
ge. This security is provided by
CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
15

granting or revoking privileges on a person
-
by
-
person and privilege
-
by
-
privilege basis, and is in
addition to (and independent of) any existing computer system security.

System personnel (that is, system operators, DBAs, s
ystem security perso
n
nel, and so forth) are
assigned individual UNIX accounts and must log into the HP
-
UX OS and ORACLE with a
unique user ID and password. CCS audit is targeted at capturing the events performed by system
personnel. While system personne
l have access to the raw data stored in the ORACLE tables,
assimilation of this sensitive i
n
formation is impractical outside of the CCS applic
a
tion.

All the PC clients accessing CCS are deployed on the Microsoft Windows 95, Windows NT 4.0,
or Windows 2000
OS. The Microsoft Windows 95, Windows NT 4.0, and Windows 2000 OSs
provide local security for files, folders, printers, and other resources. Either the local computer
or a domain controller authenticates users in order to access any resources on the comp
uter or
network. The exact configuration of the PCs are site specific. It is the operational site's
responsibility to setup the PCs to meet C2 specified guidelines that match the operational site’s
base defined requirements. This provides no risk to CCS

since all CCS data and data files are
permanently stored on the server and the CCS software tightly controls access to this data. CCS
cannot accept responsibility for the files and data resident on the individual PCs, except to
provide awareness training

and recommendations for the implementation of CCS on a PC. The
Microsoft Windows 95, Windows NT 4.0, and Windows 2000 PC itself, is not officially part of
the CCS TCB.

In addition to the access controls enforced by system authentication, all unnecessary
network
services (that is, mail, anonymous FTP, Trivial File Transfer Protocol (TFTP), and so forth) have
been deactivated and the remaining network services confi
g
ured to reduce potential unauthorized
system access. In the event of an unauthorized intrus
ion, system audit records the malicious
a
c
tivity.

The CCS roles have been created with all the permissions necessary for users of the CCS
application. Adding additional user roles or modifying the default security profile and
authentication parameters cre
ate the opportunity to defeat security controls. The CCS
application utilizes the ORACLE Forms runtime software, which requires a user name and
password. After entering in a name and password, CCS sends the data to a component on the
server which queries

the CCS database for user rights. Passwords are stored in the database in an
encrypted format. Not even the SAs can tell what each user's password is. SAs can reset user
passwords as needed.

4.3.3

Identification and Authentication (I&A)

C2 Security Requireme
nt

I&A requires all users to properly identify themselves with a unique
identifier before pe
r
forming any actions. Authentication data must be protected from
unauthorized a
c
cess. Unique identifiers are used to enforce individual accountability to an
assoc
iated audit event.

CCS I&A

CCS enforces I&A through the passwords. For anyone to have access to CCS, the
following must have been performed or established:

CCS Security

Design Document

30 November 2001



Document Version 1.3

4
-
16



A valid user ID and password must have been established with proper authorization



A user account mu
st have been established on the database being connected to



The proper software installed on the client



The client must be connected to the correct network

4.3.4