lnterservicellndustry Training, Simulation., an.d Education Conference (1IITSEC) 2009

Implementing Information Assurance - Beyond Process

Misty Piatek

Booz Allen Hamilton

Johnstown, PA

Piatek_Misty@bah.com

James Newkirk

PEOSTRI

Orlando. FL

.Tames.R.Newkirk@us.army.mil

ABSTRACT

Information Assurance (IA) has been around for decades and has finally obtained the attention it deserves. Ten yearsago, the term "IA" was known only by small groups of security experts often labeled as 'paranoid' or 'rigid'. Today,IA is well-known by most individuals involved with Government contracts ranging from high-level executives toengineers of many disciplines. Many have sought information on IA processes through reading papers and attendingbriefings, however, many questions still 100m concerning the nuts and bolts of baking IA into systems beingdeveloped. This time, let's forget the four-phase DlTSCAP and the five-activity DIACAP and talk implementation.

This paper goes beyond IA processes and addresses how to actually integrate IA requirements into your system. Thepaper delves deeper into the IA controls using Department of Defense Instruction (DaDI) 8500.2 as an example. Itdiscusses in detail, the technical, administrative, and physical controls required for many systems, summarizes whatthey mean, and provides guidance on how to implement them. Additionally, the paper covers product selection andwhat to do if a desired product is not on an approved products list. The paper also addresses the importance ofestablishing a secure baseline configuration on the products selected prior to software and application development.

Implementing IA in system development is paramount to protecting all information systems from any form ofcompromise. If left ignored, not only would systems be more vulnerable to attack, they would also not be permittedto operate without obtaining the required Authorization to Operate (ATO). If you are looking for a good read on IAprocesses, our 2008 I1ITSEC Paper, "DlACAP - Information Assurance Evolved" can be downloaded from theIIITSEC site; however, if you truly crave knowledge on the nuts and bolts of implementing lA, beyond the process,you want to read this paper.

ABOUT THE AUTHORS

Ms. Misty Piatek is an Associate at Booz Allen Hamilton specializing in Information Systems Security Engineering.She has a Master's in Business Administration from Saint Francis University and a Bachelor's of Science inComputer Science from the University of Pittsburgh in Johnstown, PA. Ms. Piatek is an accomplished ProgramManager and IA analyst that has been in the Information Technology field for over 12 years. Ms. Piatek obtainedboth her Project Management Professional (PMP@) and Certified Information Systems Security Professional(CISSP@) certifications.

Mr. .Tames Newkirk serves as the Deputy to the Director of the Cyber Security Office in the CIa at the ProgramExecutive Office for Simulation, Training and Instrumentation (PEO STRI) in Orlando, FL. He assists in managingthe Cyber Security Office which provides support across the $3.5 billion a year organization with over 1100 military,civilian and industry personnel servicing over 335,000 training systems around the world. Mr. Newkirk served in theU.S. Navy and then worked as a contractor for the Army before joining the Army Acquisition Corps as aGovernment employee and has completed over 12 years of recognized Government service. He holds a Bachelors ofScience in Business Administration - Management Information Systems (MIS) from the University of CentralFlorida.

2009 Paper No. 9367 Page J of 11

Report Documentation Page Form ApprovedOMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.

1. REPORT DATE 2009 2. REPORT TYPE

3. DATES COVERED 00-00-2009 to 00-00-2009

4. TITLE AND SUBTITLE Implementing Information Assurance - Beyond Process

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Booz Allen Hamilton,Johnstown,PA

8. PERFORMING ORGANIZATIONREPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited

13. SUPPLEMENTARY NOTES Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) held in Orlando, FL on30 Nov - 3 Dec, 2009.

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT Same as

Report (SAR)

18. NUMBEROF PAGES

11

19a. NAME OFRESPONSIBLE PERSON

a. REPORT unclassified

b. ABSTRACT unclassified

c. THIS PAGE unclassified

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

lnterservicellndustl). Training, Simulation, and Education Conference (l/ITSEC) 2009

Implementing Information Assurance - Beyond Process

Misty Piatek

Booz Allen Hamilton

Johnstown, PA

Piatek_Misty@bah.com

SHIFTING FOCUS FROM PROCESS TOIMPLEMENTATION

Understandiog the Information Assurance (IA)Certification and Accreditation (C&A) process is veryimportant to achieving the desired outcome; but it onlyscratches the surface of understanding what reallyneeds done to achieve an Authorization to Operate(ATO). Through outreach efforts, training, articles andpresentations, the training and simulation communityhas learned that IA requirements are planned andenforced from program inception. The community hasalso leamed about the Department of DefenseInformation Assurance Certification and AccreditationProcess (DIACAP) by which IA is integrated into theSystem Development Lifecycle (SDLC). Moreinformation on implementing the DIACAP process canbe found in the 2008 IIITSEC Paper, "DIACAP ­Information Assurance, Evolved" (Newkirk & Piatek).

There has been a shift in the type of knowledge that thetraining and simulation community is craving.Questions are evolving from simple process-basedquestions to more complicated questions regardingunderstanding the nuts and bolts of implementing IArequirements. Common questions include:

• What technologies and devices must be a partof the system?

• What products can be used in the system?• What technical configuration changes need

implemented on system components?• What policies and documents are required?

If you have similar questions, roll up your sleeves andget ready to learn the details on how to implement IA.

THE IA CONTROLS

The IA controls/requirements for Department ofDefense (DoD) systems with a classification level ofTop Secret and below are documented in DoDInstruction (DoDI) 8500.2. The controls are brokenout into eight subject areas as summarized in Table I(DoD, 2003, p.49). Assignment of individual controlsis based on the Mission Assurance Category (MAC)and Confidentiality Level (CL) of the system. The

2009 Paper No. 9367 Page 2 of IJ

James Newkirk

PEOSTRI

Orlando, FL

James.R.Newkirk@us.army.mil

MAC level can be either I, II or III with level I beingthe most mission critical with the highest integrity andavailability needs. The CL can be either Classified,Sensitive or Public.

Table 1. IA Control Subject Areas

-, tAreaName # Controlsin Area

Security Desi2:n and Confi2:uration 31Identification and Authentication 9Enclave and Computing Environment 48Enclave Boundary Defense 8Physical and Environmental 27Personnel 7Continuity 24Vulnerability and Incident Mana£l:ement 3

This paper sheds light on what many of these controlsmean. The logical grouping of our control explanationsdivert slightly from the subject areas called out in DoD!8500.2 and Table I above and are based on how thecontrols are implemented.

The controls levied by DoDI 8500.2 can fit into threemain categories: technical, administrative, and physical.Technical controls leverage technology in the form ofhardware, software, and firmware that protect data andinformation systems. A few examples of technicalcontrols include encryption, auditing tools, and anti­virus. Administrative controls focus on the human'element through the development of policies,processes, training and awareness, etc. to prevent orrespond to unauthorized access, as well as, otherdisruptive events. Physical controls use means such asfences, locks, badges, and guards to prevent or detectintrusions into protected areas.

TECHNICAL CONTROLS

The technical controls account for a largerepresentation of the DoDI 8500.2 controls. Thesetechnical controls help influence and shape the designof the system by determining what types of IA

lnterservice/lndustry Training, Sim.ulation, and Education Conference (l/ITSEC) 2009

technologies are required to protect the system. Thetechnical controls also define how systems should beconfigured to reduce the risk of the system. Thetechnical controls discussed in this section do notrepresent an all inclusive list due to the large number oftechnical controls and the limited size of this paper.

Boundary Protection

One of the first steps in designing the system is todefine the system's boundary or boundaries. Externalinterfaces (anywhere data potentially leaves/enters theboundary) must be defined, understood anddocumented. These interfaces must be protected usingdevices such as securely configured routers, firewallsand Intrusion Detections Systems (IDS). Specialconsiderations must be given to Controlled Interfaces(CIs), such as, Cross Domain Solutions (CDS). A CI isan interface that provides connection between twoboundaries with different classification levels. In orderto connect boundaries through a cr, an accreditednetwork guard must be deployed and guidance fromChairman of the Joint Chiefs of Staff Instruction(CJCSI) 62I1.02C must be followed (CJCS, 2008).Guards are expensive, timely to deploy and networksrequiring them are looked at under a microscope toensure Classified data does not bleed over to the lowside of the network.

The existence and integration of connections to theInternet are dependent on the CL of the system.Classified systems do not allow for any connection tothe Intemet. Sensitive systems can accommodate aninternet connection, but it must be physically isolatedfrom the system and located within a DemilitarizedZone (DMZ). Public systems have few restrictionsregarding internet presence.

Instructions for restart and recovery of boundaryprotection devices must be documented and available.This provides for the ease' of recovery from unexpectedevents. MAC I and II systems require the securitysupport structure providing boundary protection to bepartitioned and maintain separate execution domains(e,g, a firewall providing protection for the boundarycannot also be used for non-seemity purposes such ashosting a web application or for general computinguse), These network devices must also be physicallysecured in a room with access control mechanisms inplace to prevent unauthorized access.

Boundary protection devices, just like all otherhardware, software, and finnware products, must beselected from an approved list of products.

2009 Papa No. 9367 Page 3 of 11

Product Selection

When choosing products for the system, manyconsiderations must be made. Selected IA and IAenabled Comanercial off the Shelf (COTS) orGovernment off the Shelf (GaTS) products must haveundergone or be in the process of undergoingevaluation by the National Infofmation AssurancePartnership (NIAP). A helpful resource for informationon approved products can be found at the NIAPCommon Criteria Evaluation and Validation Scheme(CCEVS) web site (www.niap-ccevs.om).

However, finding a product on the list is not the onlyconsideration. The robustness level for which theproduct has been evaluated and approved is alsoimportant. Security Robustness is defined as thestrength of a security function, mechanism, service orsolution, and the assurance that it is implemented andfunctioning con-ectly (NIAP, 2009). There are threelevels of robustness for consideration: high, medium,and basic.

• High robustness provides fOf the moststringent protections and rigorous securitycountermeasures. High robustness is used toprotect highly valued assets, assets in hostileenvironments, or both.

• Medium robustness provides for layering ofadditional safeguards above good commercialpractices. Medium robustness is consideredfor environments less hostile than those ofhigh robustness, as well as, for lesser valuedassets.

• Basic robustness equates to best commercialpractices where protection requirements areminimal.

The required robustness level of the selected product isdirectly related to the CL of the system (DoD, 2003).

• Classified systems with data that traversessystems of a lower classification level requirethe use of high robustness products;

• Sensitive systems require the use of mediumrobustness products if the information transitspublic networks or the system is accessed byindividuals that don't have authorization toaccess all the information on the system; and

• Public systems require the use of basicrobustness products.

So how does robustness impact your selection ofproducts? The answer: When looking at the NIAP­CCEVS Validated Products List (VPL) or Products inEvaluation List, you will need to look at the column

Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2009

titled "Conformance Claim". In this column you willsee references to Evaluation Assurance Levels (EALs):

• Basic Robustness requires a EAL:::: 2,• Medium Robustness requires a EAL :::: 4 and• High Rohustness requires an EAL > 6 (NIAP,

2009).

What if the product I need is not on the list?If a product is not cUlTently on the CCEVS VPL, thenthe product should he searched for on the CCEVSProducts in Evaluation list. If the product is found onthis list, it can be used with the understanding thatselecting a product undergoing evaluation poses therisk of selecting and buying a product that mayultimately fail the evaluation. If this occurs, anapproved product must be selected as a replacement,resulting in costly re-design and implementation.

There is another search you can perform if the desiredproduct is not on the NIAP-CCEVS VPL. A repositoryof other approved products is kept by different serviceorganizations such as the, Army, Navy, Air Force andMarines. These repositories contain information onproducts/systems accredited and approved for use bythe organization's Designated Approval Authority(DAA.). If the product is in the organization'srepository, it should be approved for use; however, the

+ Product is available for use ifmbustnessrequirementsare met++ Product is available fbrllse ifevaluationjscompletedsuC(;es~fully

+++ Product isavuilable,for use ifrobustness requirements are metandDAA approves

DAA has the final approval and should he consulted.Repositories include:

• Navy - Department of Navy Application andDatahase Management System (DADMS),

• Air Force Enterprise InformationTechnology Data Repository (EITDR),

• Army - Anny Portfolio Management Solution(APMS) and

• Marines - Marine Corps Enterprise SoftwarePortfolio.

If the product isn't listed in one of the aboverepositories, the answer becomes more complicated.The approach for this product is based on whether ornot a Protection Profile (PP) exists for the technologyarea (IDS, Firewall, etc.) and whether or not there areany other products available that have been evaluatedagainst the PP. If an alternate approved product exists,it should be used. If there aren't any approved productslisted for the technology area and a PP does exist, youmust request that the vendor of the product submit theirproduct for evaluation through a NIAP CommonCriteria Test Lah (CCTL). If a PP doesn't exist, thenyou must request the vendor submit their product forevaluation at the DAA leveL Figure 1 summarizes theworkflow for selecting products for use.

Figure I. Prodnct Selection Workflow

2009 Paper No. 9367 Page 4 ofJ J

Interservice!Industry Training, Simulation, and Education Conference (I/ITSEC) 2009

Government Fnrnished Eqnipment (GFE) andCnstom ApplicationsGovernment Furnished Equipment (GFE) is oftenanother consideration as part of your architecture, Ittypically comes in the form of a custom developedhardware/software product that is required for use,OFE is required to undergo its own C&A effort by theorganization developing the product. A Memorandumof Agreement (MOA) can be used to note therequirement to use the OPE as part of the architecture.

Other custom developed applications are also acommon consideration, These applications can beaccredited as part of the system by ensuring:1, The application design and functionality is fullydocumented to include: roles and permissions;information on the type and format of data that isprocessed, imported, and exported; validation methodsand results; and a lifecycle support plan,2, The Application Security and Development SecurityTechnical Implementation Guide and software qualitybest practices are followed (DISA, 2008).3. The application is developed on a securelyconfigured platform and doesn't use any restrictedports, protocols or services,

Other Product Selection ConsiderationsMobile Code and Public Domain Software arediscouraged but can be used under certaincircumstances. DoDI 8552.01 (DoD, 2006) categorizesmobile code into 3 main types. The three types arebased on what the mobile code can access or performduring execution. Approval for use will depend on:

• the type of mobile code,• whether or not it is signed with a trusted code

signing certificate and• how it was obtained.

Even if mobile code is not intended for use on thesystem, fUlther burden of proof that it isn't installed isrequired, For example, the Defense InformationSystems Agency (DISA) Gold Disk can be used to scanthe system and show all applications residing on thesystem, That scan should prove that only approvedapplications are on the system and mobile code is notpresent, as expected,

Open source software must comply with all of the sameIA requirements as any other product. If the softwarelibraries are supported with a limited warranty or nowarranty at all, an alternative solution must be selected.If no alternative is available, the DAA can approve itsuse if it is critical to the success of the mission.

2009 Paper No. 9367 Page 5 of JJ

Freeware and shareware are prohibited unless the DAAdeems it critical to the success of the mission,

Estahlishing the Secure Baseline Configuration

Now that your products have been selected, they needto be configured according to configuration guides.This is also referred to as establishing a secure baselineconfiguration,

Tbe DoD! 8500.2 (DoD, 2003) IA control "Securityand Design Configuration ConfigurationSpecifications (DCCS)" requires that all IA and IAenabled products be configured in accordance withconfiguration guidance such as the Security TechnicalImplementation Guides (STIGs) provided on the DISAwebsite (http://iase,disa,mil/stigs). Configurationguides provided by the NSA System Network andAttack Center (SNAC) can be used in the absence of aSTIG, these guides can be found on tbe NSA website(http://www.lisa. gOYlia/guidance/securitv confil!uration

guides). in the event that STIG or SNAC guidance isnot available, best security practices should be used.

Configuration guides used to establish the securebaseline configuration take you through a seriec'\ of stepsand configuration changes that ensure the system hasthe minimum security configurations in place; theseconfigurations include but are not limited to:

• appropriate service packs and patches areinstalled,

• necessary registry key edits are made,• Access Control Lists (ACLs) are configured

properly,• auditing roles and permissions are properly

configured,• password policy is properly set/enforced, and• messaging services are disabled or properly

configured.

Tools and scripts are available to expedite theconfiguration process on some platforms, For example,approved Windows Operating Systems (OS) can rnnthe DISA Gold Disk to automate the process ofconfiguring the OS. Security Readiness Review (SRR)Evaluation Scripts can also be used to assist with theconfiguration of applications such as Unix-like OSs,Virtual Memory System (VMS), Oracle and more.

Once the secure baseline configuration has beenachieved, an image of the devices should be created inorder to proVide backup for quick restoration of thesystem, Other special procedures required to restore thesystem should also be recorded to facilitate recovery, It

Interservice/lndustry Training, Simulation., an.d Education Conference (I/ITSEC) 2009

is important to understand that development ofapplications should not occur on the developmentstation until the baseline configuration has beenestablished, Development prior to the baselineconfiguration can lead to increases in schedule, budgetand frustration due to the fact that the application beingdeveloped may function differently once the securebaseline configuration is established,

Ports, Protocols and Services Management (PPSM)

The use of acceptable ports, protocols and services(PPS) is another important consideration in the designand implementation of the system, IA control "SecurityDesign and Configuration - Ports, Protocols andServices (DCPP)" requires that the system comply withguidance set forth for the use of ports, protocols andservices (DoD, 2003), The guidance is hased on DoDI8551.1 (DoD, 2004) and includes reference to the PI'SCategory Assurance List (CAL) (DISA, 2009),

This PPS CAL catalogs various ports, protocols andservices and highlights them in three colors, whichrepresent their assurance level category, PPSshighlighted in red are considered low assurance andunacceptable for use unless approved by the DefenseInformation Systems Network (DISN) DAA underspecific conditions and restrictions given no otherfeasible alternative exists. PPSs highlighted in yelloware designated as medium assurance and can beimplemented only if additional mitigation strategies areapproved hy the DISN DAA and employed. PPSshighlighted in green reflect high assurance and bestpractice for use on DoD systems, Some examples ofcommon PPSs that should be avoided include: FileTransfer Protocol (FTP), Internet Relay Chat (IRC),Remote Login (LOGIN), Network Virtual TerminalProtocol (TELNET), SHELL, and Finger (DISA,2009), More secure alternatives exist and can be usedwith acceptable mitigation strategies,

All PPSs used within the houndary must be documentedin the System Security Plan (SSP) or InformationSecurity Plan (lSP). Any PPSs not required foroperation by the system must be disabled, Thissupports the IA principal of least privilege and reducesthe system's risk of exploitation, Unnecessary open orenabled PPSs will be detected during test andevaluation and will be reported as findings,

Instant Messaging

Instant Messaging (IM) within an enclave can be usedas long as it performs an authorized and officialfunction, The 1M products selected for use must be

2009 Papa No. 9367 Page 6 of 11

approved and configured according to the 1M ST1G(DISA, 2009) and in compliance with the PI'S CAL.File sharing through 1M is prohibited given its ability tobypass security and auditing policies within the enclave,The 1M server is required to be located behind thefirewall and the 1M gateway server must be located inthe DMZ, Any unused 1M Services must be disabled,

Implementing an 1M capability within the boundarycarries many policy and documentation requirements.Usemame and passwords policies apply, as do auditingand logging, usage behavior, and many others. The 1Marchitecture will also need to be documented in detail aspart of the C&A package.

1M clients, servers or gateways are strictly prohibitedfrom communicating with any public network. 1Mtraffic within the enclave boundary is not permitted toleave the boundary, and 1M traffic from outside theenclave boundary is not permitted into the enclavehoundary.

Encryption

Encryption requirements address two states of data: (1)Data at Rest (DAR) and (2) Data in Transit. Encryptionrequirements are levied based on:

• the state of the data,• the classification level of the data.• the classification level of the networks in

which data traverses and• the "need to know" of the users accessing

those networks and network devices,

Encryption - Data at RestDAR refers to all data in computer storage includinghard disks, Compact Discs (CDs), Digital VersatileDiscs (DVDs), Universal Serial Bus (USB) drives, cellphones, and other removable storage media.

For systems with a CL of Classified, it is suggested thatClassified, non-Source and Methods Intelligence (non~

SAMI) information be encrypted using FIPS ]40-2compliant cryptography; however, the decision isultimately left to the data owner on whether or not torequire data at rest encryption in this instance. If theenclave contains SA.I\!lI information and can potentiallybe accessed by individuals lacking clearance for accessto SAMI information, then NSA-approved cryptographyis required to encrypt all the SAMI data, For systemswith a CL of Sensitive, the information owner candetermine if Sensitive data is to be encrypted usingFIPS ]40-2 cryptography. Data that has been reviewedand approved for public release does not require

lnterservicellndustry Training, Simulation, and Education Conference (I/ITSEC) 2009

encryption. However, it is important to note that allUnclassified DoD information is treated and protectedas Sensitive until it is reviewed and approved for releasein accordance with DoD Directive 5230.9 "Clearance ofDoD Infonnation for Public Release" (DoD, 1996).

DAR - PasswordsAll the above information holds true for data at rest;however, there are a few caveats. Passwords onUnclassified systems or Classified systems that don'tcontain any SAMI data must be stored using FIPS 140­2 compliant cryptography. Passwords on Classifiedsystems that contain· SAMI data with users that don'tpossess the appropriate clearances for SAMI data mustbe stored using NSA approved cryptography.

DAR - Mobile DevicesMobile devices such as laptops, removable hard drives,Personal Digital Assistants (PDAs), cell phones andother portable and removable media increase the risk ofdata exposure. Given this serious risk, the DoDreleased the DoD Policy Memorandum "Encryption ofSensitive Unclassified Data at Rest on MobileComputing Devices and Removable Storage Media"(DoD, 2007) stating that all Unclassified data stored onmobile devices and removable media that has not beenspecifically approved for public release must be treatedand protected as Sensitive data, thus requiring it to bestored using PIPS 140-2 compliant cryptography(DlSA, 2008).

Encryption - Data in TransitData traversing a network is referred to as Data inTransit. Additional requirements are considered fordata in transit and are based on the classification of thedata, the classification of the network it is traversing,and the "need to know" of the users accessing thenetwork. All Classified networks require the corebackbone to be encrypted using NSA-approved Type Icryptography. Any Classified data that is transmittedacross a network that is cleared to a lower classificationlevel than the data itself (for example, Top Secret datatraversing a Secret backbone) must be encrypted in aseparate tunnel with NSA-approved cryptography. Ifthe data is transmitted over a network with the sameclassification level, but not all users of the network havethe appropriate "need-to-know", the data must beencrypted in a tunnel using I.:<IPS 140-2 compliantcryptography. Any SAMI information in transit acrossa network at the same classification level must beseparately encrypted in a tunnel using NSA-approvedcryptography.

In the event remote access is required and approved,encryption requirements are applicable. If the remote

2009 Paper No. 9367 Page 7 of JJ

user is accessing Sensitive data the session must beencrypted using PIPS 140-2 compliant cryptography.Remote access to Classified systems is seriouslydiscouraged and rarely approved; however, if it isrequired, the session must be encrypted with NSAapproved cryptography. Additionally, in wirelessnetworks all Unclassified, Sensitive information mustbe encrypted nsing FIPS 140-2 compliant cryptography.Table 2 proVides a simplified summary of encryptionrequirements for both DAR and Data in Transit.

Table 2, Summary of Encryption Requirements

Type of I)ah\ FIPS 140-2 NSADAR - Public Releasable - -DAR - Sensitive X'DAR - Classified/no SAMI X+

DAR - Classified/SAMi XDAR - Passwords on XSensitivelPublic networkDAR - Passwords on XClassified/no SAMiDAR - Passwords on XClassified/SAM1DAR - Mobile Devices XTransit - Classified backbone XTransit - Data higher Xclassification than backboneTransit - Data where users X++

lack "need to know"Transit - SAMI x++Transit - Remote Access to XSensitive dataTransit - Remote Access to XClassified dataTransit - Wireless networks Xwith Sensitive data+ Data Owner decides the requirement for encryption++Data is tunneled within NSA encrypted backbone

Identification, Authentication and Access Control

Identification, authentication, and access control isanother large area of consideration when designing andimplementing systems. Identification andauthentication serve as a foundation for access control.Once a user identifies himself/herself. the user'sidentification factors are verified through the process ofauthentication. Once authenticated into the system,access control mechanisms are used to determine whatthe user has access to based on attributes, roles, andpermissions.

Interservice/lndustl}' Training, Simulation, and Education C011ference (l/ITSEC) 2009

Identification and Authentication applies to humans,devices and services. MAC I and II systems requirethat users be authenticated via a DoD Public KeyInfrastructure (PKI) Class 3 or Class 4 certificate and ahardware security token or using aNSA-certifiedproduct. A smart card and the Common Access Card(CAC) are examples of the hardware security token thatcontain the certificates, MAC III systems only require aClass 3 certificate.

Group authenticators to applications/networks may beused if they are used in conjunction with an individualauthenticator based on DoD PKI, If they are not basedon DoD PKl, approval must be obtained from the DAA.If a password is used in conjunction with a personalidentifier, the password must meet complexityrequirements. For example, passwords must be at least14 characters long with a mix of upper case letters,lower case letters, numbers and special characters.Expiration and password re-use must be configured inaccordance to DoD or organization policy (whichever ismore stringent), All passwords must be encrypted bothat rest and in transit. Classified systems requiretesting/password cracking to be performed in order toensure password strength measures are followed andeffective.

Logon attempts must be strictly controlled to combatbrute force attacks and other attempts to gainunauthorized access. Systems must be configured tolock accounts after either a set number of consecutiveunsuccessful logon attempts or a set numberunsuccessful logon attempts within a decided period oftime. For Classified systems, after successful logon, thedate/time of the last logon must be displayed includingthe location of the logon and the number ofunsuccessful logon attempts since the last successfullogon, This will help the user identify any suspicious,unauthorized activity using their account. All DoDsystems, regardless of MAC or CL, must display theDoD Warning Message in compliance with the DoDMemorandum Subject: Standard Mandatory DoDNotice and Consent Banner (DoD, 2008).

There are two principles in IA that apply heavily toaccess control. These principles are: 1) the Principle ofLeast Privilege and 2) the Principle of Separation ofDuties. The principal of least privilege supportsproviding the least amount of access/permissionsnecessary for any user or device, This limits a user'sability to cause intentional or unintentional damage,This principal is supported by requiring any changes tosystem configuration or production code to beperformed by authorized individuals through privilegedaccounts, Privileged users, such as administrators, must

2009 Paper No, 9367 Page 8 of 11

have separate accounts to calTY out privileged functions.They must have non-privileged accounts to performtheir non-privileged, day-to-day functions,

The principal of separation of duties supports separatingjobs/functions to ensure a single individual does nothave the power to defraud a system. Collusion wouldbe required to accomplish such an attempt. Forexample, the administrator and auditor roles must usedistinct accounts and be assigned to differentindividuals, This ensures that a singleuser/administrator cannot cover their tracks bymodifying or destroying audit data after intentional orunintentional damage occurred on the system,

Audit

Auditing can be viewed as both a technical andadministrative function, Auditing in the form of usingtechnology and system configurations to ensure useractions are logged and stored is a technical function,Auditing assists in the identification and investigation ofunauthorized activity, Systems that are MAC I, II, orClassified require that automated, continuous on-linemonitoring and audit trail creation is implemented andimmediately alerts personnel of suspicious activity. Theautomated system must have the capability toautomatically disable the system during serioussituations, MAC III, Sensitive or Public systems onlyrequire manual, periodic review of audit data. Auditlogs must record the success/failure of the following:

• logon events,• account management,• directory Service access,• account logon events,• object access,• policy change,• privileged use,• process tracking and• system events.

As briefly stated earlier, it is important that the auditdata be protected from unauthorized access andmodification. A separate auditor role must beestablished for auditors and ensure separation of dutiesby excluding administrators and other privileged usersfrom inclusion into the auditor group.

Audit records must be backed up at least weekly ontoother system media for MAC I and II systems. MAC IIIsystems should also be backed up routinely based onbest practices, but a specific timeframe requirement isnot specified in DoD! 8500.2.

Interservicellndustry Training, Simulation, and Education Conference (l/ITSEC) 2009

Virus Protection

All IA and lA-enabled devices, such as servers,workstations and mobile devices, must deploy anapproved Anti-Virus solution capable of receivingautomatic updates. In the event Anti-virus isdetermined to be a detriment to the function andperformance of the device, thorough testing must beperformed to prove degradation to pelformance existsand negatively impacts the mission (burden of proof isrequired) and documentation must be updatedaccordingly, The ultimate decision lies with the DAAas to whether or not the absence of Anti-Virus on thedevice is acceptable; however, obtaining this type ofapproval isn't common,

ADMINISTRATIVE CONTROLS

As described earlier, administrative controls focus onthe human element through the development of policies,processes, training and awareness programs, etc. toprevent or respond to unauthorized access and otherdisruptive events, Many DoDI 8500.2 controls requirethe development, documentation, implementation andaudit of policies, procedures, standards, guidelines andother documentation. In this section, you will learnabout many of these requirements to include themajority of the documentation required.

Configuration Management

Configuration Management (eM) plays a key role inIA. CM is paramount throughout the SDLC inunderstanding and documenting the ever-changingfunctional and physical attributes of the system. eMhelps individuals understand how the system haschanged, who authorized the changes, when changeswere implemented, etc, All DoD systems required tocomply with 8500.2 controls must fol1ow a CM Plan.The CM Plan must formal1y document CM roles andresponsibilities to include the establishment of aConfiguration Control Board (CCB). MAC I and IIsystems require the Information Assurance Manager(lAM) to participate as a memher of the CCB in orderto assess IA impact of any proposed changes. The eMPlan also addresses the processes for:

• reviewing and approving system changes anddocumentation,

• testing system changes, patches and updatesprior to deployment, and

• verifying that the eM process is followed andeffective,

2009 Paper No, 9367 Page 9 of 11

All documentation discussed under administrativecontrols is required to be managed under the applicableCM Plan.

IA Architecture Documentation

Documentation detailing architectural information ofthe system is required in order for the system to beproperly designed, implemented, and maintained, aswell as, for the DAA to be able to make an informeddecision on whether or not the system maintains anacceptable level of risk in order to receive its ATO.

Much of this documentation is part of the DIACAPPackage and is located in the InfoITImtion Security Plan(ISP). However, other pieces of supportingdocumentation may contain the information and can bereferenced in the ISP. Documented architectureinformation in the I.SP must include:

• Appointment of IA roles, responsibilities andcriteria, such as clearances, training andcertifications. This includes identification ofthe DAA, Certification Authority (CA), UserRepresentative (UR). and lAM

• Detailed architecture boundary diagramshighlighting external and controlled interlacesand the protection mechanisms in place at eachinterface

• Hardware and software baseline inventories• Detailed data flow diagrams• Description of data and corresponding

sensitivity/classification levels• User roles required for access control and

privileges assigned to each• Unique security requirements• Use of mobile code, impact assessment and

mitigations• Use of public domain software, impact

assessment and mitigations• Use of system libraries• Protection mechanisms for DAR and data in

transit• Ports, Protocols and Services in use• Restoration priority of subsystems, processes

and information

Hardware and Software Baseline InventoriesBoth a hardware and software baseline inventory mustbe documented and managed under the eM Plan. Thisinformation is often found in the ISP; however, thesebaseline inventories must also be separately stored in afire rated container in the event the main documentationis destroyed.

Imerservice/lndustry Training, Simulation, and Education. Conference (I/ITSEC) 2009

Information Assurance Vulnerability ManagementPlan (IAVMP)

An Information Assurance Vulnerability ManagementPlan must document how IA Vulnerability Alerts(lAVAs), lA Vulnerability Bulletins (IAVBs), and lATechnical Advisories (IATAs) are received, evaluatedfor applicability, tracked, and implemented, The planmust include a detailed process for downloading andinstalling patch files on test systems in a mirrored labenvironment, and patching the deployed systems if noissues are found.

Incident Response Plan

An Incident Response Plan must be developed toidentify who incidents are reported to and whatprocedures to follow once and incident has occurred.The plan identifies members of the incident responseteam and outlines their roles and responsibilities. It willalso define a user training program for identificationand response to incidents. The Incident Response Planis required to be exercised every six months for MAC Isystems and annually for other systems.

Policies and Procedures

Many policies and procedures are required for thesecure operation of systems. Many times these policiesand procedures are already in place at the site in whichthe system will be deployed, These policies can be"inherited" and referenced as part of the system'sdocumentation. If the policies and procedures do notexist or are not stringent enough, modification orcreation of new policies and procedures is required.Proof must be provided to show that the policies doformally exist in writing and are being followed.Validation methods typically used include review ofdocumentation and the performance of interviews.Required policies include:

• Personnel policies such as hiring, suspensionand termination procedures

• Acceptable use policy for the system• Account Management procedures to create,

modify and delete botb privileged and non­privileged accounts. The procedures alsodetail in accordance with DoD policy howoften account lists are reviewed and whendormant accounts are suspended. In manyinstances the lAM is required to track allprivileged accounts.

• Data handling and dissemination for markingand labeling in accordance with DoD 5200,lR

• Backup and recovery procedures

2009 Paper No. 9367 Page 10 of 11

Disaster Recovery, Contingency and Continuity ofOperations Plans

Plans must be developed that provide information onwhat to do in the event of a disaster or disruption inavailability of the system or sub-system. These plansmust identify mission and business essential functionsand their priority for restoration. These plans detail orreference procedures for the backup and restoration ofhardware and software, Operation and timeliness ofalternate sites is based on MAC level.

• MAC I systems require an identicalgeographically distanced "hot site" bemaintained in parallel to the main system. Thehot site must immediately be available foroperation without loss of data or function. Theplan must be fully tested semi-annually.

• MAC II systems require that an alternate sitebe identified in the event a disaster ordisruption occurs, allowing all business andmission essential functions to resume within 24hours. Plans must be exercised annually toverify their effectiveness.

• MAC III systems require an alternate site thatpermits the partial restoration of mission orbusiness essential functions within 5 days of adisaster. Plans must be exercised annually toverify their effectiveness.

Backup copies of critical software, data. restorationprocedures, and audit trails must be stored in a fire­rated container at a separate location. The availabilityof spare parts is also a consideration in the continuity ofoperations. Requirements for the availability of spareparts is based on MAC level and ranges from immediateavailability for MAC I to within 24 hours for MAC IIIsystems.

Other Required Documentation

A few additional pieces of documentation are requiredin order to get an ATO for the system; they include:

• MOAs - Required for all interconnectingsystems and/or boundaries. Also required forany IA or IT services required for operation ofthe system.

• Documented proof showing IA as a budgetedline item for the program

• Software development plans and software testplans

• IA test plans and procedures• IA test results (DIACAP scorecard)• IA mitigation strategies (Plan of Actions and

Milestones (POA&M))

Interservice/lndust1}' Training, Simulation, and Education Conference (1/ITS£C) 2009

PHYSICAL CONTROLS

Physical controls protect, monitor and control theenvironment of the facilities. Controls often timesinclude security guards, locks, cameras, fences, badges,and more. Physical controls may be inherited from thesite at which the system is to be installed. Some ofthese controls are implemented with technology, whileothers require documentation and implementation ofpolicies and procedures required to secure the facilities.Personnel must be trained in all facets of environmentalcontrol. Physical controls are not detailed in this paperbut cau be fouud iu DoDl 8500.2 (DoD, 2003), Someexamples include:

• Automated vs. manual fire detection,inspection and suppression based on MAClevel

• Automated vs. manual temperature andhumidity controls based on MAC level

• Emergency lighting• Voltage regulation• Positioning of data displays, such as, monitors

to deter shoulder surfing (looking over one'sshoulder to access data)

• Data handling and dissemination in accordancewith DoD 5200,lR (DoD, 1997)

• Facility guarding, access policies andprocedures

CONCLUSION

The road to success in implementing IA is baking IAinto the SDLe. IA requirements must be considered atprogram inception and must be defined early in theacquisition strategy and process. This ensures IA isiucluded iu the budget aud the Statemeut of Work(SOW),

Once the program is awarded, the engineering teammust ideutify all applicable IA requiremeuts for thesystem. Many of the IA requirements are complex andnot easily understood. Trained and certified systemsecurity engineers should be integrated into the team toprovide guidance and system security engineering.Using certified system security engineers is not only asuggestion, but also a requirement mandated by DoDDirective 8570.1, Information Assurance Training,Certificatiou aud Workforce Mauagemeut (DoD, 2004),

REFERENCES

Chairmau of the Joiut Chiefs of Staff (CJCS), (2008).Instruction 6211.02C Defense Information SystemNetwork (DISN): Policy and Responsibilities.

2009 Paper No. 9367 Page 11 of 11

Defeuse Iuformatiou Systems Agency (DISA), (2008).Application Security and Development. RetrievedJuue 26, 2009 fromhttp://iase.disa.mil/stifIs/sti r:./apnlicarion secUli tv and development stig v2r1 tInal 20080724.pdf

Defense Iuformatiou Systems Agency (DISA), (2008).Frequently Asked Questions DoD PolicyMemorandum~ "Encryption of SensitiveUnclassified Data at Rest on. Mobile ComputingDevices and Removable Storage Data. RetrievedMay 27, 2009 from http://iase.disa.mil/policy­guidance/faq dar encryption policy memo J8mar08 update-6 finaL doc

Defeuse Iuformation Systems Ageucy (DISA), (2009).Instant Messaging Checklist. Retrieved April 23,2009 fromhup:lliase.disa.millsti '2.'s!cheeklistlinstant messaging checklist vlr2.5.pdf

Defeuse luformation Systems Agency (DlSA), (2009).Ports, Protocols and ,5'ervices Management(PPSM) Category Assurance List( CAL) Sorted byServices. Retrieved April 23, 2009 fromhttp://iase.disa.millports/index.html

Departmeut of Defeuse, (1997). 5200.I-R InformationSecurity Program.

Department of Defeuse, (1996). Directive 5230.9Clearance ofDoD Information for Public Release.

Departmeut of Defense, (2004). Directive 8570.1Infonnation Assurance Training, Certification andWorkforce Management.

Departmem of Defense, (2003). Instruction 8500.2Infonnation Assurance (IA) Implementation.

Departmeut of Defense, (2004). Instruction 8551./Ports, Protocols and Services Management(PPSM).

Departmeut of Defense, (2006). Instruction 8552.01Use of Mobile Code Technologies in DoDInfomwtion Systems.

Departmeut of Defense, (2007). Memorandum:Encryption of Sensitive Unclass(fied Data at Reston Mobile Computing Devices and RemovableStorage Media.

Department of Defeuse, (2008). Memorandum: Policyon Use of DoD Information Systems - StandardConsent Banner and User Agreement.

National Information Assurance Partnership (NIAP).Protection Profiles Frequently Asked Questions.Retrieved April 23, 2009, from http://www.uiap­~cevs.ondcc-scheme/faqs6m.

Newkirk, J. & Piatek, M. (2008). DIACAP-Information Assurance, Evolved.