Information System Security Engineering and ManagementModule 1.docx

Information System Security Engineering and Management
Module 13, Overview of:
13a. Government Crypto Devices and Policies
13b. Physical Security
13c. Information Security Audits
Spring 2011
CS6803 Information Security Management
Copyright 2011
Module 13a Objectives
To give an overview of some Department of Defense (DOD)
networks, particularly the “Global Information Grid,” where
crypto is used
To discuss
The general principles used in National Security Agency (NSA)
crypto products
Some sample NSA crypto equipment
Government Key Management Policies and Practices
The focus of this talk in on topics for those who will be working
for the US Government, particularly the DoD, intelligence
agencies, etc.
This material is required for the 4011 and 4013 certifications
Copyright 2011
Global Information Grid (GIG)

The GIG is essentially a secure intranet for the national security
community, including DoD, the Intelligence Community (IC),
etc.
From an NSA website describing the GIG and Information
Assurance (IA):
The GIG will be a net-centric system operating in a global
context to provide processing, storage, management, and
transport of information to support all Department of Defense
(DoD), national security, and related Intelligence Community
missions and functions - strategic, operational, tactical, and
business - in war, in crisis, and in peace.
Copyright 2011
The GIG concept has been in use since circa 2000, and is really
an integration of many existing and planned networks
Integration is at the level of the communications networks, the
information layer, and the management layer
IA is standardized, and is embedded into all aspects of the GIG
High assurance crypto on all links
Standard, high assurance multifactor authentication
Defense in Depth
NSA is responsible for GIG IA (security) through their GIG IA
Portfolio Office (GIAP)
Copyright 2011
The GIG communications network includes very high bandwidth
fiber backbone (both leased from commercial providers and
government owned), satellite links, and terrestrial copper and

wireless components to the individual user.
The network is all IP, including voice and other media.
Legacy networks have been, or will be, transitioned into the
GIG architecture.
Note that “the grid” or “the global grid” has been adopted by
many in popular culture to refer generically to a/the set of
devices and sensors connected via the Internet
Copyright 2011
GIG Vision
The following slides are from a public NSA briefing a few years
ago, and provide more insight into the GIG vision
Also read the NSA page on the GIG in the webliography
Copyright 2011
INTEGRATED
INFORMATION
INFRASTRUCTURE

Information Services and
transport
Service Agents
Intelligent, integrated
communication intranetwork
Adaptive, dynamic resource
management
Secure
NAVIGATION
GEO-POSITIONING
Robust
Distributed
Inexpensive
SURVEILLANCE
Continuous
Global
High Resolution Imagery
Day/Night/All Weather
WEAPONS
Remote/Local
Accurate
Responsive
Inexpensive
COMMAND AND CONTROL
Commanders Internet
Situation Monitoring
Planning and Replanning
FORCE ENHANCEMENT
Mobile
Lethal
Sustainable
Flexible
INFORMATION OPERATIONS

Defensive IW
Offensive IW
Assurance
LOGISTICS SUPPORT
Just Enough
Just In Time
Fully Visible
Copyright 2011
An internet-like transport architecture between space, air and
ground nodes
Integrated Space, Air and Ground Networks
Global access to deployed / mobile Users (COTM)
Timely delivery of air and space data to Theater and CONUS
(AISR, SISR support)
Automated, dynamic, high assurance network operations
Increased capacity and connectivity: RF and laser
communications network
Network of Networks
Enable Future Innovations and Growth Through A Flexible Yet
Secure Network Architecture

Integrates mobile/tactical users and global intelligence services
via IP (optical comm links and EHF, Ka and X-band)
Copyright 2011
Copyright 2011
Aside on Fiber Backbone Communications Protocols
The link and network layer protocols on fiber backbone
networks are different from the familiar ethernet, 802.11n, etc.
Protocols used on backbone fiber include:
Synchronous Optical Network (SONET) at the link layer
Asynchronous Transport Mode (ATM) over SONET at the
network layer (ATM is also used elsewhere)
Internet Protocol over fiber (usually IP over WDM or DWDM)
for link and network layer
SONET and ATM are very common on high speed links, and
require special encryptors
SONET and ATM are lower in the ISO protocol stack than IP,
which is often carried on SONET and ATM, as well as Ethernet,
WiFi, etc.
The next few slides discuss SONET and ATM very briefly
Copyright 2011
Aside on Fiber Backbone Communications Protocols: SONET
Synchronous Optical Network (SONET)

Primary link layer optical backbone technology deployed today
Paths are switched in multiples of 155 Mb/s (OC-3); 2.5 Gb/s
(OC-48) and 10 Gb/s (OC-192) trunks are the norm, and 40 Gb/s
(OC-768) trunks are being deployed now.
SONET “frames” carry telephone circuits, T1, T3, ATM, IP
directly, and other protocols
Typically used to link facilities over dedicated or leased fiber
links
Links may be the whole fiber or individual wavelengths
(“lambdas”)
DoD facilities may be classified enclaves
Copyright 2011
Aside on Fiber Backbone Communications Protocols: ATM
Asynchronous Transfer Mode (ATM)
“virtual circuits” (VCs) between endpoints (often routers, but
also some end user devices, video, sensors, etc.)
56 byte “cells” (similar to packets, but fixed size and small)
Usually carried over SONET
ATM VCs carry telephone circuits, IP packets, other protocols
Commonly used for router to router links
Sometimes gets “closer” to the end user; multiple ATM end
points may go out over the same SONET link
Copyright 2011
Aside on Fiber Backbone Communications
Fiber backbone connects single security level enclaves at
different locations: need Type I SONET, ATM backbone
encryptors
IP encryptors also needed, especially when a facility is not at

one security level
MLS is needed for MLS endpoints
Non-MLS used for single level endpoints and to link single
level enclaves
Need higher speed IP encryptors in the near future
Current roadmap is a transition to IP directly over fiber with
Wave Division Multiplexing (WDW) for different paths (router
to router)
Will need very high speed IP encryptors for IP directly over
fiber, which are in development
Copyright 2011
SIPRNet, NIPRNet
Two longstanding networks still in use are NIPRNet and
SIPRnet
NIPRNet is the Non-secure IP Router Network is for sensitive,
but unclassified (SBU) data, such as personnel, medical, etc.
data
SIPRNet is the Secure IP Router Network is for Secret data (but
nothing higher)
Both are standard IP networks, and may connect to the public
internet with firewalls
SIPRNet is used within classified environments, and uses NSA
approved Type I encryption to tunnel through the internet where
it is connected. It cannot communicate directly with any nodes
that are not on SIPRNet
Both of these are run by the Defense Information Systems
Agency (DISA), essentially the IT organization for DoD.
Other special networks are used for TS and higher information

Copyright 2011
Crypto for Classified Data
The rest of the slides in section a present an overview of
government crypto, particularly NSA crypto for classified data.
Copyright 2011
Trends in Government Cryptography & Key Management
Technology and Policies
Evolving, particularly for classified information
Overall IT and network infrastructure is moving from expensive
custom equipment to COTS (Commercial off the shelf) products
and standards where feasible
Moving from point to point encryptors (T1, ATM, SONET, etc.)
to more modern and dynamic environments (e.g. IP networks,
SecureXML, etc.), but still using GOTS (Government Off The
Shelf) crypto; may allow some COTS products for Secret soon.
Policies and implementation complicated by need for controlled
sharing among very diverse military and intelligence coalitions
Also complicated by domestic homeland security coalitions
(CIA/NSA/FBI/DHS, FEMA, local law enforcement, etc.)
Things change slowly, so there is still a lot of legacy equipment
in use now and for the future
Copyright 2011
Status of Government Cryptography & Key Management
Policies
Recent “roadmaps” are being changed
Major technical and policy problems still unsolved, especially
for coalitions

Patriot Act allows the data sharing issue among “intelligence
community”, the FBI, DoD, and law enforcement, but they still
have different definitions for S, TS, etc. and systems are not
interoperable
A new “Information Sharing Environment” is under
development to facilitate this.
Clearance and need to know are still important
Policies on data sharing and searching/correlating data from
different organizations are still being developed
Technology to enforce security for such such data sharing is
still needed
Crypto and PKI will have to fit into this environment
Copyright 2011
CAVEAT
This talk has the most recent information released to the general
public on the web
More information is available that can only be accessed from
.mil or .gov domains: such information is not in this lecture
Some of the material is already out of date for new deployments
But basic design and policy principles are similar
Most of this is still currently in use in places
Lots of legacy crypto is still used
Different departments and agencies interpret and enhance
security policies differently
When you start a federal job, find out what is in place for your
organization at the time you start
Copyright 2011
NSA Approved Cryptography

An NSA-approved cryptographic device consists of 3 certified
components:
An approved algorithm
An implementation that as been approved for the protection of
classified information in a particular environment
A supporting key management infrastructure
“Zeroize” button to securely erase keys and unencrypted
information (even after power loss) in an emergency on most
crypto devices
Cryptography and Key Management Policies
Copyright 2011
Traditional NSA/NIST Encryption Classes
Type 1 - U.S. Classified
Type 2 - U.S. Federal Inter-Agency
For Sensitive but Unclassified (SBU) government
communications; “Warner Amendment” unclassified data
Type 3 - Interoperable Inter-Agency (Federal, State and Local)
& Commercial Use
NIST-approved data encryption standards (DES, AES, etc.)
Type 4 - Proprietary
Not a federal standard, not used for federal info
Exportable, for Commercial & International use
NSA is responsible for Type 1, 2; NIST for Type 3 standards
(FIPS Standards)
Copyright 2011
NSA Approved Type I Devices
Algorithms

Last 2 decades: Baton (crypto), Skipjack (crypto), Firefly (Key
exchange) originally classified; some now declassified
Since 2003, AES is also allowed and recommended for new
devices
128 bit and higher for Secret
192 bit and higher for TS and above
Keys
True random numbers needed
Generation based on physical phenomena; pseudo-random not
strong enough
Historic: centrally generated and tested by NSA
Difficult distribution problem
Now used for special purpose keys
Session keys generated by NSA approved embedded hardware
(e. g., leaky resistor for random noise generation) in crypto
devices
Copyright 2011
NSA Approved Type I Devices (continued)
Hardware design and implementation approved by NSA
Usually a separate hardware device (box, card) is required
Careful attention to “red-black” separation
Red == classified; black == unclassified (but classified
information that has been encrypted with an approved algorithm
is considered “black”)
Common Criteria Level 6 or higher (Orange Book B2)
equivalent or better assurance level
Rigorous check for covert channels, “sneak circuits”
Rigorous check for cross-talk (EMSEC)
Failure modes cannot allow for information leak from red to
black

Copyright 2011
Government AES Usage Policy
NIST/FIPS approved for protecting sensitive (SBU) electronic
data
Analyzed by NSA for use with classified data
Algorithm allowed for classified, unclassified, & commercial
use
Crypto devices still need NSA approval for use with classified
data
NSA policy for use of AES with classified data:
128-bit key & above are suitable for SECRET info
TOP SECRET info requires 192 or 256 bits
See webliography for full policy statement
New Type I encyptors being developed with AES as a built in
option
Sample Government Crypto Devices
The following slides and corresponding webliography links
describe many of the crypto devices still in use, but it is a far
from exhaustive list.
You may find this information interesting to scan or browse
through, but it is not required for this course. This is just a
bunch of snapshots in time (including one old snapshot of a 10
year old Navy web site listing the crypto gear that they used
then).
Most of the links are to vendor web sites, so the gear there is
still available, even though it may seem very dated. Upgrading
systems can be a very long process in the government.
Copyright 2011

Copyright 2011
Sample Type I Devices: Legacy
Link encryptors, e. g. KG-84, KG-192, KIV… for T1, etc.
Still widely used by DoD
e. g. Secure IP Router Network (SIPRNet)
New technology used to emulate old devices for compatibility
Smaller, lower power, more reliable, but still use the old
protocols and algorithms so they interoperate with the old
crypto's still in use
Still need to support older key distribution methods
Copyright 2011
Recent Type I Devices: Network (SONET)
KG 189 SONET backbone encryptor (widely used, but GD has
rolled SONET capability into the KG 75, which was originally
only ATM)
KG 340 SafeNet SONET 10G encryptor (2008)
Note: SafeNet also sells a commercial SONET 10G encryptor
which is only EAL4 (pending), FIPS 140-3 (pending) and not
approved for classified material
KG-530 40G encryptor contract awarded 11/2009 (see
webliiograph)
Copyright 2011
Recent Type I Devices: Network (Examples)
KG 75 Fastlane Asynchronous Transfer Mode (ATM) virtual
circuit encryptor (see GD web site in webliography); new
versions also support SONET

KG 175 Taclane series “classic” IP (200 Mb/s) (see GD web site
in webliography)
KG 175D Taclane Micro—compact version of Taclane, also
HAIPE compatible (see later slide)
Copyright 2011
Recent Type I Devices: Endpoints (Examples)
KOV-26 Talon PCMCIA card encryptor (L3 Communications)
(Eternet, wifi, HAIPE compliant)
SecNet WiFi card/encryptor (see Harris web site & look at the
antenna on the card!)
STE (L3 Communications) encrypting phone/fax/modem; secure
mobile phones for CDMA, GSM, satellite phones
Sectera (GD) series: wireline, GSM wireless, Sectera Edge
Smartphone
Fortezza PCMIA card for crypto & credentials (holds multiple
keys, identity info, and has crypto engine, all in a tamper
resistant package)
Copyright 2011
Some NSA Approved Crypto Products (Graphic Circa 2001, But
Devices Commonly In Use Today)
Copyright 2011
Fortezza® Card

PCMCIA hardware token for crypto processing and key storage
Implements NSA/NIST-compliant crypto standards for network
security
11 character PIN; card disabled after 3 consecutive wrong pins
“tamper-resistant”: destroys key if tampered with
Fortezza Plus card for secret level keys and encryption
Copyright 2011
Secure Terminal Equipment (STE)
ISDN phone (fax and modems also available)
Key materials & crypto hardware on Fortezza Card
Approved for Classified use
Phone not classified when card is removed
Copyright 2011
Sectera Edge Smartphone
Wireless voice to Top Secret; reportedly used by Obama
Wireless data access to SIPRNet (Secret IP Router Network—
only to Secret level)
$3500
Copyright 2011
Sample Type I Devices: Recent and Projected
High Assurance IP Encryption (HAIPE) program

Multiple products exist now and more are in development, going
to very high data rates: trend for most new crypto
NSA adaptation of IPSEC protocol for session setup, mutual
authentication, key exchange, and headers
“Hardened” protocol stack and Type I crypto algorithms
IPv6 versions under development: see webliography
L3 KG-245 series 1 Gb/s and 10 Gb/s products available now.
Copyright 2011
Sample Type I Devices: Recent and Projected (continued)
Secure VoIP phones
Lots of issues and different architectures proposed
Voice over Secure IP (i. e., VoIP on an already secure network)
Secure Voice over IP (i. e., a secure version of VoIP over an
unsecured network)
Some Voice over Secure IP already deployed
Copyright 2011
Classification of Keys
All key material (keys, seeds, etc.--collectively called keys in
this lecture) are classified using the same classification scheme
as other data data, and may include additional codewords (e. g.,
“COMSEC”)
Key classification is primarily about access rights, not key
length/strength, although there are some broad policy rules
given later
All keys used for Secret and above data come from NSA or
approved NSA equipment
Any equipment loaded with keys is classified at the level of the
highest level key (join of all the levels if non-linear ordering)

Classified keys, keyed equipment, and anything with keys are
handled and stored as other classified equipment
Labeling
Physical access control, with storage in approved containers or
facilities
Inventory management
Possible compromises reported to ISSO
Approved destruction
Copyright 2011
Classification of Keys (continued)
Key use:
Key must have classification level not lower than information
encrypted
Crypto device must be of the appropriate class (Type 1, Type 2,
etc.) or stronger required for the level of the information
Key Management: key issuer and key user must have
classification level not lower than the key
When cryptos set up a secure communication path, endpoint
crytpos mutually authenticate and ensure that the other end is
using a key of the same classification level
When equipment can set up multiple communications paths (e.
g., a KG-175 ATM encryptor), and the equipment is NSA
endorsed as MLS, different paths may be at different levels;
then a key for a path’s classification level is used for that path,
and is verified by both endpoints
Copyright 2011
Key Storage on Cryptos
Most cryptos have multiple keys loaded, including

Authentication keys
“Key encryption keys” (KEKs) used only to encrypt keys for
local storage or transfer
Multiple communication keys
Currently active session keys
Keys are changed on a regular basis, and future keys may be
preloaded on the crypto
Emergency keys that are used in a crisis situation in place of the
current key
Copyright 2011
Key Transfer: Physical Devices
Paper (human transcription), paper tape, mag tape (not used any
more)
Electronic data storage examples
DS 101 Fill Device
Small device used to hold keys that plugs into a special socket
on the the front panel of a crypto; think of it as a pre-cursor to a
USB thumb drive for keys (but not using USB)
Used to load new keys from NSA
Used to reload keys in case they are zeroized
CIK--Crypto Ignition Key
Looks like a plastic key with metal contacts
“split key”: CIK is matched to a device, and half the key is
stored on the device, half on the CIK
Device is not classified when CIK is not loaded
Used on earlier secure phones, etc.; some still in use
Fortezza PCMCIA card
Stores multiple keys for various purposes
Used to store keys for current secure ISDN phones
DoD Common Access Card (SBU, unclassified only)

Copyright 2011
Key Transfer: OTAR
OTAR (Over the Air Rekeying)
Sending new keys to a remote crypto over the communications
link
Keys are encrypted with the KEK for transmission
Keys are automatically loaded onto the crypto devices
Typical method in recent and future cryptos
DS101 still used for initial keying and key backup
Government Identity Cards
DoD Common Access Card (CAC)
Required for all DoD personnel
“Smart Card” for Identification, physical access, and
computer/NIPERNet network access
Includes human readable and machine readable information,
certificate for PKI
See CAC Home Page, CAC FAQ, Jan. 2006 news story cited in
the webliography
NIPRNet is the primary DoD network for unclassified
information
Copyright 2011
Government Identity Cards
HSPD 12 (2004) (see webliography)
Mandated a common ID card for all government employees and
contractors
Personal Identity Verification (PIV) card now being deployed in

response to HSPD-12
Functionally similar to CAC: for ID, physical access,
computer/network access
Smart card, human and machine readable; has certificate for
PKI
Not CAC interoperable; move to a common standard for both
Copyright 2011
Copyright 2011
Federal Government PKI
Strong push to use PKI for all user access to federal systems
DoD requires the use of the Common Access Card (CAC) token
(PKI) for access to the Non-Classified Internet Router Network
(NIPRNet)
PIV for all civilian government employees, contractors
Separate Public Key Infrastructure policies for DoD (including
classified) and unclassified federal agency information
Both based on X.509 certificates
See webliography for detailed DoD and Federal policy
documents
DoD has established four certificate assurance classes to be
used in various environments, with different policies for each
class
Major points are summarized in the next slide
Details for some are in the following slides
Copyright 2011
DoD PKI Roadmap 2000
Still on the web, but due for a publicly released update :-)
Basic concepts and designs still operative

Progress along the roadmap has been made
Part of the overall DoD Key Management Infrastructure (KMI)
KMI also includes generation and distribution of classified keys
for Type I encryptors
A framework for generation, production, distribution, control,
revocation, recovery, & tracking of public keys (certificates) &
their corresponding private keys
Uses CAW & Fortezza® cards for a X.509-based PKI
Specially designed to suit DoD needs, maintained by DoD
Being implemented in phases
See webliography for roadmap details
Copyright 2011
DoD Certificate Assurance Classes
Copyright 2011
Key Management Life Cycle For PKI
The next few slides go through the primary steps in the key
management life cycle for a certificate in a PKI, with comments
on the specific policy considerations in DoD and other federal
agencies
The basic principles are applicable to civilian and commercial
PKI
Copyright 2011

User Registration
User register with a “Registration Authority” (RA, also called
Local Registration Authority, LRA) which is responsible for
verifying the identity of the user and the user’s need for a
certificate
Identity verification is a key issue for any PKI or Identity
system (such as passports, drivers license, etc.)
This is the potential week spot in any PKI or Identity system
not just DoD systems
DoD identity verification policy depends on certificate Class,
with in person registration required for Class 3 and higher.
Forms of identification that are acceptable (military ID, federal
ID, multiple non-federal IDs, etc.) are spelled out in the
policies
Copyright 2011
Key and certificate generation
The RA transmits the registration information to the Certificate
Authority (CA)
The public/private keys are generated and certificates are
created and digitally signed by the CA
The signing key is a critical information asset; if it is
compromised all certificates signed by that CA should become
invalid, and digital signatures from prior user certificates can be
forged
DoD class 4 and 5 CAs use the high assurance Certificate
Authority Workstation (CAW)
The certificate provides a cryptographic binding of the user ID
to the public key
The certificates are issued to the user

Copyright 2011
Key Registration
The identity and public key information care registered and can
be distributed
The public key information is posted to the appropriate
directory services
The private key may be archived for key recovery; CAW and
DoD policy mandate this
The archive may be at the CA or as a separate service
Copyright 2011
Operational Use
The certificate is on HardWare or SoftWare token
Class 5 on HW token (e. g., Fortezza Plus) (Fortezza can hold
multiple keys from mutliple CAs)
Class 4 on HW token (e. g., Fortezza, CAC)
Class 2, 3 on SW token
PIN/Passphrase or biometric is used for certificate access
control
Class 4, 5: system generated
11 digit pin on Fortezza
Automatic lockout after 3 successive failed attempts
Class 2-3: user selected PIN/passphrase
Copyright 2011
Key Storage and Update
Storage of Key Material
PIN/passphrase or biometric protection for key material on
tokens

Fortezza Plus is not classified when not activated by the PIN
A Fortezza Plus not in a workstation is, by default, not
activated by the PIN, so it is unclassified and may be carried
around
Key Update
Keys, certificates have expiration dates built in
Life depends on policy; typically 1 year for class 4-5
Update for hardware tokens requires in person visit to CA
Copyright 2011
Key Recovery and Revocation
Key Recovery
If token is “locked” due to repeated false authentication
attempts, CA can “unlock” it; for FORTEZZA, a CAW must be
used.
If the token is lost/destroyed, keys can be recovered from
registration information to decrypt existing documents
CAW provides key recovery services
Key Revocation
Keys may be revoked if a user’s classification level or need to
know change, if the user is no longer trusted, or if the token
thought to be lost or compromised
Certificate Revocation Lists (CRLs) are distributed
Timely distribution of CRLs is an issue
Copyright 2011
The following slides are graphics taken from the Roadmap
document
There are also two graphic slides on the overall Key

Management Infrastructure of NSA
Reminder: these are not new documents, but are the latest
available to everyone. If you start a job with the federal
government, check for the current information
Copyright 2011
PKI System Context in DoD
Copyright 2011
PKI System Elements
Copyright 2011
DoD PKI Architecture
Copyright 2011
DoD PKI Deployment

Copyright 2011
DoD PKI Roles
DOD PKI
Web-Based
Cert Auth (CA)
DOD
Directory
Services
LRA
User
1
User Registration
Web-based
2
Password
Relying
Party
Local Registration Authority

NSA
Commercial
Class 3 and below PKI

High Grade Electronic Applications
EKMS

Root
X.509 Certificate
Based Applications
Current Class 4 PKI
(DMS)

Root
Recent KMI Architecture
Copyright 2011
i
l
KMI
Managers
Medium Assurance
ROOT

NSA
High Assurance
ROOT
CF, Tier 0

Manual Systems
REGIONAL
SITES
(Servers)

Medium Assurance
Certification Authorities

High Assurance
KMI
Management
Servers
Networks/Web
BASE/POST
ACCOUNT
(Client Workstation)

g
i
t
a
Commercial
KMI Architecture Vision
Module 13b:
Physical Security
(Government Focus)
Copyright 2011
Module 13b Objectives
To discuss the basics of physical security
Copyright 2011
Physical Security
Physical security is critical to the protection of sensitive
information

DoD has detailed policies on the physical security of classified
materials
The policies depend on the classification level of the materials
Policy topics are discussed, but not specific policy parameters
Copyright 2011
Layered Physical Security
Physical security is done in layers:
Facility security (ground, buildings)
Restricted area security (part of a building specifically for
classified materials)
Locked “containers” or “safes” to store classified materials
Computers with classified information
Physical security also includes personnel security, which is not
covered here
Copyright 2011
Facility Clearances
A facility Clearance (FCL) is required for any facility that will
contain classified materials or where classified work will be
done
An FCL does not mean that classified materials or work can be
anywhere
Restricted areas are areas (possibly the entire facility) where
classified materials can be stored or classified work can be
performed; restricted areas meet further requirements
Every facility with a FCL is required to have a Facility Security
Officer (FSO) who is responsible for ensuring that the facility
security policies are enforced

Copyright 2011
Facility Clearances Requirements
The activities at the facility must require access to classified
information for legitimate U.S. Government needs
The facility must have a reputation for integrity and lawful
conduct in business practices (e. g.., if there are compromises of
classified information, or if security policies are violated, the
FCL may be revoked)
The facility must not be in under foreign ownership, control, or
influence, to the extent that granting FCL would be inconsistent
with national interest
The Facility Security Officer (FSO) must be a U.S. Citizen
employee
Senior Management and the FSO must have a Personal
Clearance
Copyright 2011
Facility Perimeter Considerations
Stand-off zones to restrict proximity to facility
Barriers
Eliminate potential surveillance from outside perimeter (trees,
fences, other buildings, etc.)
Guards, patrols, lighting
Copyright 2011
Restricted Areas
Rooms, suites, floors, whole buildings, or whole facilities

where classified work is performed
Different restricted areas may be needed for different security
levels
Multiple restricted areas within one facility are often used for
different levels, different codewords, etc.
Restricted areas may be nested, e. g., a TS restricted area inside
a Secret area
A Secure Compartmentalized Information Facility (SCIF) is a
restricted area for highly classified (e. g., TS/codeword)
materials
Copyright 2011
Perimeter Control for Restricted Areas
Clearly defined perimeter – No barriers necessary (but are
usual)
Access control to the area
Policy may dictate “two person rule” for some highly sensitive
areas: one person cannot be in the area alone
Personnel within the area are responsible for challenging all
individuals who may lack proper authority
Inspections must be done randomly
All individuals are subject to inspection
Must be done within facility grounds
Inspections are not necessary for highly personal – purse,
wallet, clothing etc.
Inspections on entry and exit
Copyright 2011
Automated Access Control System
Automated access control systems may be used for entry to

restricted area (no physical guard to check ID, although one
might be nearby)
Two factor ID normally used:
ID badge (smart card, mag strip, RFID)+ PIN
ID badge+ biometric
“Piggybacking” (admitting more than one person on one ID) not
allowed
Both IDs must be used to open door if a “two person” rule is in
effect
Copyright 2011
Automated Access Control System (continued)
Typically used for “inner” areas with guards at outer perimeter
Manufactures must meet the following requirements
Chances of unauthorized access are no more than one in 10,000
Chances of authorized access being rejected in no more than 1
in 1,000
Locations of access must be protected
Tamper alarm protection is mandatory for Top Secret Closed
Area
Copyright 2011
“Uncleared” Visitors in Restricted Areas
Cleared personnel may escort uncleared personnel into a
restricted area (depending on policy)
All classified information must be stored in an approved safe
and all classified discussions stopped while an uncleared visitor
is present
Visual or audible warning are often used as a reminder while
uncleared are present, e. g., flashing red light on ceiling

Copyright 2011
Other Restricted Area Policies
Policies depend on classification level
TEMPEST protection
Electronic
Audio
Visual
Wall materials/strength/thickness
Door materials/strength
Window materials/strength (if permitted at all)
Copyright 2011
Other Restricted Area Policies (continued)
Locks (type, strength)
Intrusion detection systems (motion, audio, thermal, vibration
sensors
Alarms
Use of insecure phones
Restrictions on removing storage media (disks, tapes, CDs, USB
drives, etc
Copyright 2011
Storing Classified Information
When not in use classified information is kept in approved safes
(“containers”) with combination locks
Safe construction practices defined by government policy based

on classification level
Safe can ONLY be used for classified information
End of Day Security Checks –
At the close of each day – ensure all classified data is securely
stored
At the end of each shift – ensure all classified data is securely
stored except when facility is in continuous operation
Checks may be performed by security guards on a daily basis
Checks may include looking through unsecured materials (desk
top, unsecured desk drawers, unsecured cabinets, etc.) to ensure
no classified material has been left unsecured
Clean Desk Policy may be in effect
Copyright 2011
Protection of Combinations
Record of names with combinations maintained by Site Security
Office in locked safe
Combinations selected by Site Security Office
Combinations cannot be shared
Combinations cannot be written down by the user
All containers are locked if not under the direct supervision of
an authorized person
Combination is dependent upon classification of contents,
upgrade in classification requires a new combination
Copyright 2011
Changing Combinations
Combinations are changed in the following circumstances:
Assignment of safe to a new person
Assignment of safe to new security level

Termination of employee
Withdrawn, suspended or revoked clearance
Compromise of security container
Unlocked and unattended safe
Copyright 2011
Protection of Classified Information on Computers
Computers with classified information must be in a restricted
area with a security level at least as high as the information on
the computer
Laptops with classified information must have that information
encrypted with approved Type I encryption when the laptop is
removed from the restricted area
Other protection mechanisms (use depends on classification
level, policy)
Removal or disabling of writable media drives
Removal or disabling of ports (USB, firewire, etc.)
Disable booting from removable media
Forced use of password on startup, after idle period
Encryption of disk contents
Locking to desktop
Periodic checking for keystroke loggers, etc.
Module 13c:
Information Security Audit

Copyright 2011
Module 13c Objectives
To understand the principles of the security audit:
What is a security audit?
The goal of the security audit
What organizations are involved
How an audit is conducted
The outcome of an audit
This module is about the process, not a detailed roadmap for an
audit of a specific organization
This section is not specific to DoD or government
organizations. Most large corporations perform regular security
audits, usually at a 2-3 year interval.
Copyright 2011
What is a Security Audit?
As with seemingly everything in this course, there is no
standard definition :-)
In general, a security audit is a review of the current status of
information security done by an external organization
Corporate: usually a “security audit” department outside the IT
organization (usually reporting to the CFO, part of corporate
audit) is used to audit corporate or business level information
security
A small company may hire an outside firm that specializes in
security audit
Federal government departments are audited by GAO, as
required by FISMA (lecture 6)
Federal government contractors doing classified work are
subject to a security audit of the classified systems

Copyright 2011
One Definition of a Security Audit
“A computer security audit is a systematic, measurable
technical assessment of how the organization's security policy is
employed at a specific site. Computer security auditors work
with the full knowledge of the organization, at times with
considerable inside information, in order to understand the
resources to be audited.” (Security Focus; see webliography
Copyright 2011
What a Security Audit is NOT
It is not penetration testing (Pentest): Pentest is a very detailed
and complete set of testing for a certain class of vulnerabilities;
audit covers a much broader range of security issues and is not
as detailed in all of them
…but pentest of certain critical vulnerabilities may be part of an
audit
It is not a review of Audit Logs: audit logs are just logs of
certain activities in a system, and only looks at security from a
forensic (after the fact) perspective
…but a selective review of some audit logs to look for security
policy violations might be part of an audit
Copyright 2011
Who Is Involved in an Audit
The Audit Team: the ones conducting the audit

The Audited Organization (Audit Target)
Management
Make resources and personnel available to the auditors
Be interviewed by auditors
Receive and act on audit results
Employees and contractors
Be interviewed by auditors (some, not all)
Answer questions about system elements on which an auditor is
performing “hands on” evaluation
Copyright 2011
Audit Principles (A Useful, But Not Universal View)
The audit team is from outside the organization being audited
The audit team is very familiar with the overall corporate (or
government agency) business and practices
The audit team starts with the risk analysis and security policy
of the organization being audited
The audit is essentially an external verification that the
documented risk management approach and security policies are
being implemented and followed properly
Sometimes questions about the risk management approach and
security policy are raised at the audit and referred to higher
management as part of the audit final report
You have to have a good risk analysis and derived policies in
place well before the audit!
Copyright 2011
Security Audit Focus
Security audits are part of the on-going process of defining and
maintaining effective security controls and policies

Everyone who uses any computer resources throughout the
organization is potentially involved
Auditors perform their work through personal interviews,
vulnerability scans, examination of OS settings, network
configuration, examination of individual’s computers, etc.
Interviews: all higher level managers, key security personnel,
and a random set of general users (usually not all)
Examination of individual’s computers: all with access to
highly sensitive information, random set of others
Primarily concerned with HOW security policies are actually
implemented
Risk Analysis
Policies of the systems being audited
86
Copyright 2011
Audit Software Packages
Software is available for some phases of security audit
Provide automated checklists for specific audit questions; may
be add-ons to ISO 17799, OCTAVE, etc.
Provide test suites for specific audit topics, such as
vulnerability scans, password cracking, etc.
These are just a starting point for the audit team!
Copyright 2011
A Few Issues That Might Be In An Audit (from Security Focus)
Are passwords difficult to crack?
Are there access control lists (ACLs) in place on network

devices to control who has access to shared data?
Are there audit logs to record who accesses data?
Are the audit logs reviewed
Are the security settings for operating systems in accordance
with accepted industry security practices?
Have all unnecessary applications and computer services been
eliminated for each system?
Are these operating systems and commercial applications
patched to current levels?
How is backup media stored? Who has access to it? Is it up-to-
date?
Are there adequate cryptographic tools in place to govern data
encryption, and have these tools been properly configured?
Have custom-built applications been written with security in
mind?
How have these custom applications been tested for security
flaws?
How are configuration and code changes documented at every
level? How are these records reviewed and who conducts the
review?
88
Copyright 2011
Other Questions That May Be In An Audit
Do employees and contractors understand the security policies
that apply to them?
Interview with particular and randomly selected people
Do they follow these policies?
Interviews, and hands on analysis of individual computers from
particular and randomly selected people
Look for policy violations, such as illegal or disallowed

software, downloaded copyright protected content, pornography,
etc.
Do they understand what to do and who to call if there is a
“security event” on their computer, or any system they have
access to?
Is there a disaster recovery plan? Have the participants and
stakeholders ever rehearsed the disaster recovery plan?
Copyright 2011
Audit Stages
Pre-Audit
Auditors
Target
Audit
The Actual Auditing
Post-Audit
Report on findings to audit target management
90
Copyright 2011
Auditors spend significant time preparing for each audit (days
to weeks)
They need to understand the scope of the audit
They review:
Results of previous audits (make sure problems have been
corrected)
Latest risk analysis and assessment
Currently applicable security policies (corporate, organization,

and system specific)
Previous security incidents
Policy for use of proprietary (corporate, civilian, government)
or classification (DoD) markings and handling of materials
Understand the systems in the target organization
High level functions
Security controls
Understand the nature of sensitive information used by the
target organization
Prepare checklist for each audit step
Pre-Audit: Auditors
91
Copyright 2011
Pre-Audit: Target Organization
Prepare the organization for the audit
Review policies with all employees
Remind employees of the purpose and conduct of the audit
Non-confrontational
Honesty in all answers
Review specific issues with relevant people
Critical areas--make sure all policies are known and followed
Make sure issues raised in prior audit have been addressed, and
be prepared to explain how to auditors
Copyright 2011
Auditors should minimize impact on operations
Audit should be conducted in a non-confrontational manner

The auditors want to uncover problems so they can be fixed, not
to cause trouble
Identifying and solving security problems is in everyone’s
interest
Collect data about the physical security of computer assets
Perform interviews of site staff
Go through the prepared checklist
Perform network vulnerability assessments
OS and application security assessments
Access control assessment
etc.
Auditors should be looking for unexpected problems
The Audit
93
Copyright 2011
Short briefing to target management at the end of the audit
Raise any issues that need to be addressed immediately
Otherwise, provide general information
Do not give details until the audit team has a chance to meet
and evaluate all survey and test results.
Audit team reviews all results and generates final report
Final report
Overview of organizations security posture
Cite all security deficiencies
Rate severity
Recommend corrective actions
Follow-up audit on a smaller case maybe schedule
Post Audit: Audit Team

94
Copyright 2011
Post Audit: Target Organization
Review audit results
Take corrective actions as needed
Some low severity deficiencies may be left as is after a review
by the organization due to either cost/benefit analysis, or a
documented willingness to accept the risk
Update the risk analysis and policies as needed
Start getting ready for the next audit!
Copyright 2011
Audit Associations/ Groups
U.S. General Accounting Office (GAO)
National State Auditors Association
National Association of State Auditors, Controllers, &
Treasures
Information Systems Audit and Control Association (ISACA)
SysAdmin, Audit, Network, Security Institute (SANS)
96
This is the final slide in the final lecture in this course.
I hope you have found this course interesting, and, more

important I hope you have learned useful and important ideas
and ways of thinking about security that will be of value in your
career.
My best wishes for success to all of you.
Bill Hery
Copyright 2011
Copyright 2011CNSS Policy Statemement on AES use for
classified material13a. DoD crypto Federal X.509 Policy
(2006)13a. DoD crypto This is for federal agencies, not DoD
classified systems
http://jitc.fhu.disa.mil/pki/documents/dod_x509_certificate_poli
cy_v9_0_9_february_2005.pdfArmy requires PKI for
NIPRNET13a. DoD crypto Common Access Card FAQ13a. DoD
crypto Information Sharing Environment13a. DoD crypto An
environment is under development to allow DoD and the
"intelligence community" to align classification levels and share
classified data on automated systems
Copyright 2011NIST on PKI (4/06)13a. DoD crypto DoD PKI
Roadmap13a. DoD crypto DoD X.509 Crypto Policy13a. DoD
crypto DoD PKI Program Management Office13a. DoD
crypto DoD PKI web site. Many pages are only available in .mil
and.gov domains IPv6 and HAIPE13a. DoD crypto Common
Access Card Home Page13a. DoD crypto HSPD-1213a. DoD
crypto HSPD-12/PIV FAQ13a. DoD crypto On a Department of
Commerce site, but is essentially the same in all
departments PIV and CAC13a. DoD crypto Harris DoD WiFi
crypto products13a. DoD crypto NSA Suite B Crypto13a. DoD

crypto Suite of cryptographic algorithms and protocols
recommendations consistent with NSA security policy for both
classified and unclassified materials GD Crypto Products13a.
DoD crypto A web site showing various Type I crypto products
from General Dynamics, including Fastlane, Taclane, and
Sectera Copy of Navy Crypto web site13a. DoD
crypto Interesting site with a copy of a Navy site on Type I
crypto gear. This copy was probably made in the early 2000's.
The Navy site is no longer publicly available. This is an
interesting resource on legacy crypto, and early versions of
some of the recent ones (Taclane, Fastlane). Certificate
Authority Work Station13a. DoD crypto GD website on their
CAW for the NSA approved PKI.
Copyright 2011NSA Global Information Grid (GIG) IA
page13a. DoD crypto A quick intro to the GIG, mostly about the
IA component TALON PCMCIA encryptor13a. DoD crypto L3
web site for the product L3 Crypto devices13a. DoD crypto This
page lists a range of communications devices for DoD, but look
at the KG, STE, Talon, Guardian, and OMNIxi series devices
for crypto gear KG-530: 40 Gb/sec SONET encryptor13a. DoD
crypto A contract to develop this was awarded to GD HSPD-
12/PIV FAQ13a. DoD crypto On a VA site, but essentially the
same for all govt agencies Federal X.509 Policy (2009)13a.
DoD crypto This is for civilian federal agencies, not DoD
classified systems Common Access Card FAQ13a. DoD
crypto Common Access Card (CAC) FAQConducting a Security
Audit: An Introductory Overview13c. Security
Audit Information Systems Audit and Control Association
(ISACA)13c. Security Audit Home page for ISACA Security
Auditing: A Continuous Process13c. Security Audit A more
detailed list of things to included in an audit

C
er
t. C
la
ss
5
4
3
2
T
o P
r
o
t
e
ct
C
l
a
s
s
if
i
e
d D
at
a on
Unp
r
o
te
c
te
d

N
et
wo
r
ks
M
i
s
s
ion C
rit
i
ca
l
D
at
a on
Unp
r
o
te
c
te
d
N
et
wo
r
ks
Mo
s
t
R
e
m
ai

ning
App
li
c
at
ion
s
Mo
s
t
R
e
m
ai
ning
App
li
c
at
ion
s
C
r
yp
t
o
N
S
A
c
e
rtif
i
e
d
T

ype
I
N
IS
T
/
N
S
A
T
ype
II
N
IS
T
FI
PS
N
IS
T
FI
PS
T
oken
s
A
ll
c
r
yp
t
o
f
un
c
t

i
ons
i
n ha
r
d
w
a
re t
oken
s
P
ri
v
a
t
e
k
e
ys on
h
ar
dw
ar
e
t
oken
s
P
ri
v
a
t
e
k
e

ys on
so
ft
w
are
tok
e
ns
P
ri
v
a
t
e
k
e
ys on
so
ft
w
are
tok
e
ns
Co
m
mon
C
ri
t
eri
a
E
A
L
5

-
7
3
-
4
1
-
2
1
-
2
U
s
e
r ID
RA
I
n P
er
son
I
n P
er
son
I
n P
er
son
No
t i
n pe
rs
on
P
IN
/

p
a
ssph
ra
s
e
o
r
b
i
om
etr
i
c
CA
W
g
e
ne
rat
ed
Sy
s
t
em
gen
era
t
e
d
U
s
e
r s
e
le

c
te
d
U
s
e
r s
e
le
c
te
d
Cert. Class
5
4
3
2
To Protect
Classified Data on Unprotected Networks
Mission Critical Data on Unprotected Networks
Most Remaining Applications
Most Remaining Applications
Crypto
NSA certified Type I
NIST/NSA Type II
NIST FIPS
NIST FIPS
Tokens
All crypto functions in hardware tokens
Private keys on hardware tokens
Private keys on software tokens
Private keys on software tokens
Common Criteria EAL
5-7
3-4
1-2

1-2
User ID RA
In Person
In Person
In Person
Not in person
PIN/passphrase or biometric
CAW generated
System generated
User selected
User selected
� EMBED MS_ClipArt_Gallery.2 ��
�
�
�
�

Information System Security Engineering and ManagementModule 1.docx

Information System Security Engineering and ManagementModule 1.docx

Recommended

Recommended

More Related Content

Similar to Information System Security Engineering and ManagementModule 1.docx

Similar to Information System Security Engineering and ManagementModule 1.docx (20)

More from dirkrplav

More from dirkrplav (20)

Recently uploaded

Recently uploaded (20)

Information System Security Engineering and ManagementModule 1.docx