Activity 2 Implement and Validate IACs

Process Steps for PM

System Design System Created Differences?

Process Steps for PM

CIO evaluates support/sustain requirements

Evaluation will be signed and loaded as artifact prior to package moving to Certifier Will eliminate orphaned systems Give better configuration management Ensure life cycle management is built into system

Process Steps for PM

Verify database entries Artifacts Ready for Validation?

Process Steps for Validator/Cert Agent

Validation
Validator conducts the test and evaluation If there are problems and they are easily resolved or there are no problems

Analysis of the risk items begins

Notification sent to PM/IAM if any discovered items are not easily resolved Validator Develops and loads the initial Risk Assessment into the C&A Tool (IATS) 2nd Discussion occurs here if needed

Validator updates Risk Assessment, if needed due to the conversation of the discussion

Process Steps for Validator/Cert Agent

Review C&A Plan Conduct Test and Evaluation Notify of Validation problems Corrections

IA Controls Review

IA Controls

Mission Assurance Category (MAC) Levels Confidentiality Levels (CL)

Mission Assurance Category (MAC) Levels DoDI 8500.2, Enclosure 2, page 22:
the mission assurance category reflects the importance of information relative to the achievement of DoD goals and objectives, particularly the warfighters' combat mission.

Mission Assurance Category (MAC) Level 1 MAC I

Systems handling information that is determined to be vital to the operational readiness or mission effectiveness of deployed and contingency forces in terms of both content and timeliness. The consequences of loss of integrity or availability of a MAC I system are unacceptable and could include the immediate and sustained loss of mission effectiveness.
Source: DoDI 8500.2, Enclosure 2, Page 22

10

Mission Assurance Category (MAC) Level II

MAC II
Systems handling information that is important to the support of deployed and contingency forces. The consequences of loss of integrity are unacceptable. Loss of availability is difficult to deal with and can only be tolerated for a short time. The consequences could include delay or degradation in providing important support services or commodities that may seriously impact mission effectiveness or operational readiness.
Source: DoDI 8500.2, Enclosure 2, Page 22

11

Mission Assurance Category (MAC) Level III

MAC III
Systems handling information that is necessary for the conduct of day-to-day business, but does not materially affect support to deployed or contingency forces in the short-term. The consequences of loss of integrity or availability can be tolerated or overcome without significant impacts on mission effectiveness or operational readiness. The consequences could include the delay or degradation of services or commodities enabling routine activities.
Source: DoDI 8500.2, Enclosure 2, Page 22

12

Confidentiality Levels
DoDI 8500.2, Enclosure 2, Page 16
Applicable to DoD information systems, the confidentiality level is primarily used to establish acceptable access factors, such as requirements for individual security clearances or background investigations, access approvals, and need-to-know determinations; interconnection controls and approvals; and acceptable methods by which users may access the system (e.g., intranet, Internet, wireless). The Department of Defense has three defined confidentiality levels: classified, sensitive, and public.

13

Determining IA Controls
Manually, the MAC and Confidentiality Levels are combined to ascertain which IA Controls apply to your system: MAC I, Classified: Use DoDI 8500.2 Attachments A1 and A4 MAC I, Sensitive : Use DoDI 8500.2 Attachments A1 and A5 MAC I, Public : Use DoDI 8500.2 Attachments A1 and A6 MAC II, Classified : Use DoDI 8500.2 Attachments A2 and A4 MAC II, Sensitive : Use DoDI 8500.2 Attachments A2 and A5 MAC II, Public : Use DoDI 8500.2 Attachments A2 and A6 MAC III, Classified : Use DoDI 8500.2 Attachments A3 and A4 MAC III, Sensitive : Use DoDI 8500.2 Attachments A3 and A5 MAC III, Public : Use DoDI 8500.2 Attachments A3 and A6
Source: DoD Instruction 8500.2, Enclosure 4, Page 50, Table E4.T2

14

Determinig IA Controls
Or you can use the DIACAP knowledge service: https://diacap.iaportal.navy.mil

15

IA Controls of Note
Three important IA controls are used by every MAC level: DCCS-1 and ECSC-1 both state that one is to use the DISA Security Technical Implementation Guides (STIG) or the NSA Security Recommendation Guides (SRC) to configure their system. VIVM-1 states that an automated tool is to be used as part of a vulnerability management program. DISA has started the Secure Computing Compliance Validation Initiative (SCCVI)
16

Testing

17

18

Review

Perform a Review Ensure minimum documents for your package is present If documents are missing the reviewer should request them from the submitter and not pass the package onto Navy CA until all documents are received Note: Reviewer should employ all review procedures required by his/her Echelon II command.

19

Review

When submitted to Navy CA they also put your package through an In-depth review

20

Review

Items to check in Review Accreditation Boundary not clear Certification level is clear Site Location is clear MAC category is clear

21

22

23

Test
The primary reason for testing the security of an operational system is to identify potential vulnerabilities and subsequently repair them Network and system security scanning is the most practical way to find out what the vulnerabilities and threats are Examining security vulnerabilities is the first step in reducing site, system, and server liabilities

24

Preparing for the Test

The Test involves considerable amount of time and preparation. A Test can take from one day to several weeks to complete, depending on the size/complexity of the application/network/system. There are many different items to contribute to Test results, such as: Documentation Automated Software Reports Hand-written test results The Test will require at least one tester (person familiar with the system) and one witness (a certification agent that documents the results).

25

Preparing for the Test

Automated software used during the Test could cause a temporary loss of functionality in the network/system; so plan for accordingly. Review the list of controls and validation procedures using the DIACAP Knowledge Service located at https://diacap.iaportal.navy.mil/

26

Sources for Test

DISA and the NSA has written a number of documents on locking down systems based on industry best practices and practical experience. These guides are known as Security Technical Implementation Guides (STIGs) or Security Recommendation Guides (SRG) and they cover technology in use in the Federal Government. For each STIG, there is an associated Security Checklist that allows a security professional to manually review a system for compliance with the STIG. In Accordance with the DoDI 8500.2 IA Controls DCCS-2 and ECSC-1, the DISA STIG or SRG for each system must be used as guidance on locking it down. STIGs and checklists are available at: http://iase.disa.mil

27

Test cases

If there are specific functions of the system that are locally-developed or GOTS, or there are processes specific to your organization that meet the IA controls; then test procedures specific to these elements will need to be developed.

28

DISA
DoD Directive 8500.1 requires that all IA and IA-

enabled IT products incorporated into DoD information systems shall be configured in accordance with DoD-approved security configuration guidelines The use of the principles and guidelines in the STIG will provide an environment that meets or exceeds the security requirements of DoD systems operating at the Mission Assurance Category (MAC) II Sensitive level, containing sensitive information IA Products will effect boundary IA-enabled IT Products can affect the boundary

29

STIGs

30

DISA STIGs
DISA STIGs are used to lock down a system DISA has produced documentation for many operating systems, database engines, and other technologies. NSA has produced documentation for a few operating systems, and hardware technologies.

31

STIGs
DISA STIGs and NSA Guides are configuration standards DISA has produced documentation for many operating systems, database engines, and other technologies.

For more information go to https://iase.disa.mil

32

STIG Example
Local Accounts
To minimize potential points of attack, local users, other than built in administrator and Guest accounts, should not exist on a workstation in a domain. Users should always log onto workstations via their domain and domain accounts. This does not apply to laptop PCs which are designed to function both on the domain and off the domain. (4.024: CAT III) The SA will ensure local user accounts do not exist on a workstation

33

Checklists

34

Checklist
Security Checklist
Lockdown Guide Hardening Guide Benchmark configuration

Security Readiness Scripts (SRRs) Unlicensed tools provided by FSO

35

Checklist example
The GPMC should appear in the Administrative Tools menu after it has been installed on a system. It can also be loaded in an MMC with the following steps: Select Start and Run from the desktop. Type mmc.exe in the Run dialog. Select File from the MMC menu bar. Select Add/Remove snap-in from the drop-down menu. Click the Add button on the Standalone tab. Select the Group Policy Management snap-in and click the Add button. Click Close. Click OK.

36

Gold Disk

37

Gold Disk

Gold Disk was designed to evaluate the following: Windows 2000 (Professional, Member Server, Domain Controller) Windows XP Windows 2003 (Member Server, Domain Controller)
Microsoft Office Netscape Navigator Internet Explorer Antivirus products

38

Gold Disk

Why was Gold Disk Developed? Gold Disk functionality

39

Requirements
Required

OS

Windows 2000 Professional Windows 2000 Member Server Windows 2000 Domain Controller Windows 2003 Member Server Windows 2003 Domain Controller Windows XP

Internet Explorer

Internet Explorer 6.0, Service Pack 1 User account used to run the Gold Disk must have Administrator privileges

Account Privileges

User Right

User account used to run the Gold Disk must have Manage Auditing and Security Log 800 X 600
40

Minimum Screen Resolution

Launch Gold Disk from CD-ROM

To Run Gold Disk from CD-ROM: Insert Gold Disk CD Number 1 in the CD-ROM drive. Right click on the My Computer icon on the Windows desktop Select and click on Explore and navigate to the CD-ROM drive containing the Gold Disk CD. A window similar to Figure 2-1 will be displayed.

41

Launch Gold Disk from Network

To Run Gold Disk from a local or network drive: Right click on the My Computer icon on the Windows desktop Select and click on Explore and navigate to the local or network drive containing the Gold Disk executable and control files. Double-Click the launcher.exe icon.

42

Asset Evaluation
Upon completion of system prescan, two options are available by right-clicking on the asset name in the left side tree view. Evaluate Asset begins the process of scanning the system for vulnerabilities. This action can also be initiated via the Evaluate Asset button located on the Tool Bar. Edit Asset Information allows the user to enter information about the system to be imported into VMS.

43

Known Issues
With every new Gold Disk comes the Known Issues file. It is an Excel file with the top part containing current issues and the bottom part containing resolved issues. The Known Issues files is overwritten with the new and resolved issues with every new release (about every two months). You might want to keep the old Known Issues, if you happen to still be using an older disk.

44

Retina Vulnerability Scanner

45

SCCVI
DISA has also procured software for use in vulnerability assessments. The Navy requires that this software be run on all Navy networks once a month, as per NCDOC CTO 06-02. This software attacks the target like a hacker with some knowledge of your system. SCCVI and the STIGs cover some of the same vulnerabilities, but have two different goals. SCCVI tests for IAVA compliance; whereas the STIGs are used for system lockdown
46

What is Retina
Retina, because it scans from the network, can only see what one would see from the network. Because of this, there are many IAVAs and settings that Retina can not check for.

47

Why do we use it?

Retina tries to look at a system from the hackers perspective. Retina checks to see how an outsider with limited knowledge can compromise the target system. It is a way to test the target systems first line of defense. The DISA Gold Disk/SRR scripts test the rest of the system. There is some overlap in the testing.

48

Why do we use it?

DoDI 8500.2 IA Control VIVM-1 states:
A comprehensive vulnerability management process that includes the systematic identification and mitigation of software and hardware vulnerabilities is in place. Wherever system capabilities permit, mitigation is independently validated through inspection and automated vulnerability assessment or state management tools.

Retina is one of these automated vulnerability assessment tools. DISA has procured and mandated Retina for DoD use.

49

What does this mean to me?

People will be using Retina to scan systems and networks. The results of these scans are used during the Residual Risk Assessment to show some of the risk of the system. We will need to be able to read the reports. Sometimes administrators will require our assistance in understanding the results of these reports.

50

What do you need to know before you scan?

Retina can only see a systems vulnerabilities from the outside. If there is a firewall or router between the system running Retina and the target, you will effectively be scanning the ruleset for the firewall or router; thereby skewing your results. Do not scan through a firewall, router, or other network device that blocks or reroutes TCP/IP traffic.

51

Reports
Remediation Summary Executive

52

Reports
The tests are factual information The analysis is a subjective and detached expert opinion on the validity, integrity, and plausibility of the tests The analysis should be written by someone other than the tester.

53

Interpreting Reports
Interpreting reports requires some knowledge of the associated vulnerability. The reports usually contain a reference for the vulnerability that was located. It is suggested that the reviewer review this reference if they are not familiar with the vulnerability found. Report findings are ranked in order of severity: High Medium Low Informational
54

Executive Report
Check version of the scan engine and audit files for currency against date the scan was run Verify the dates and scan engines for all three reports that are generated Verify the scans are for the amount of devices identified Verify the credentials used have the sufficient privilege to audit registries Do not dump into word doc put into a pdf file

55

Executive Report
All three reports are generated At the same time. Verify the dates and scan engines match for all reports.

Verify you receive scans for the amount of devices identified in the SSAA & topology diagram

Verify the credentials used have sufficient privilege to audit registries. Null account does not.

If you receive a scan that shows all Zeroes this is a red flag!
56

Remediation Report
Verify that the dates and scan engines match for all reports Verify the IP to be used as a line item in the POA&M. Each item should be itemized in the POA&M for action.

57

Remediation Report
Verify the dates and scan engines match for all reports.

Verify the IP as a line item in the POA&M. Each finding should be itemized in the POA&M for action.

58

Ports, Protocols and Services

Watch for differences between Ports and Protocols that use the same number. Example is the DMS application uses Protocols 50 & 51 which are authorized Verify the Ports, Protocols and Services list by the PPS CAL which is updated frequently at: http://iase.disa.mil/ports/index.html Nipr UTNpp Sipr - CNTpp
59

CTO 06-02
CTO 06-02
Requires monthly scans in order to verify IAVA compliance

60

Test Case Content

Test Cases shall contain the following information at a minimum:
Test ID Requirement ID Test Objective Test Methodology (Interview, Observe, Document Review, Test) Test Steps Expected Results Actual Results

61

Sample Test Case

Test ID: NET-24 Requirement ID: VIVM-1 Test Objective: Ensure that the organization is in compliance with the DoD Information Assurance Vulnerability Management (IAVM) program and that a written and signed compliance policy is put into affect. Test Methodology: Interview, Document Review Procedure Script: 1. Verify that the organization is included in distribution for DoD/CERT Information Assurance Vulnerability Alerts (IAVA). 2. Ensure that personnel responsible for tracking and responding to specific IAVAs based on technical content or system responsibilities have been identified in writing. 3. Identify all system resources that have been allocated for use in testing patches, fixes, workarounds, upgrades, etc., for applicable vulnerabilities as described in IAVAs or equivalent notifications vehicles. 4. Check to ensure that vulnerability management policy includes a system of notification and compliance reporting for all vulnerability-related alerts. Expected Result: The organization is in compliance with the DoD Information Assurance Vulnerability Management (IAVM) program and that a written and signed compliance policy is put into affect. Actual Results:
62

Risk Assessment
1. For each failed test there must be an entry in the 2. 3.

4. 5. 6.

Risk Assessment. After the entry is entered, the likelihood of exploitation of that vulnerability must be determined. Once the likelihood is determined, then the magnitude of impact if that vulnerability is exploited must be determined. The likelihood and magnitude are both used to generate a risk level. Then a mitigation (or countermeasure) is listed, if one exists. The risk level combined with this mitigation produces the residual risk.
63

Risk Assessment Likelihood

The likelihood of the risk is how likely is the vulnerability will be exploited. The table below shows the ratings for likelihood.
Definition The attack requires a minimal combination of effort and Likely coincidence of events to succeed, and/or the threat-agent is both motivated and capable. The attack requires moderate effort and coincidence of events to Possible succeed. The threat-agent has some of the resources required and/or a moderate level of motivation. Countermeasures are in place to prevent or significantly impede Unlikely successful exploitation, and/or the threat-agent lacks motivation or capability. Rating

64

Risk Assessment Magnitude of Impact

The raw risk finding indicates the magnitude of impact if this vulnerability were exploited. The table below indicates the ratings used for magnitude.
Definition Successful exploitation could result in sustantial im pact to the organization, including unavailability, m odification, disclosure, or destruction of valued data or other system assets; loss of system High services for an unacceptable period of tim e; or possibly injury to or death of personnel. Successful exploitation could result in m oderate im pact to the organization, such as discernable but recoverable unavailability, M edium m odification, disclosure, or destruction of data or other system assets or services. Low Unavilability, m odification, disclosure, or destruction of data or degradation of system assets and services are easy to detect and correct, and the im pact to the organization is m inor. Rating

65

Risk Assessment Risk Levels

A Risk Level is derived by taking the likelihood rating and comparing it to the magnitude rating. Once that is done, the risk level is shown in the table below.

Likelihood of Exploitation M agnitude of Impact High M edium Low Unlikely Low or M edium Low Low Possible High M edium Low Likely High High M edium or High

66

Risk Assessment Residual Risk

After the risk level any mitigations can reduce it by one more value. For example: with mitigation, a risk level of high becomes medium. These mitigations must be realistic and will be heavily questioned by the reviewers at both the CA and the ODAA. Claims of False Positives from automated tools and Mitigation Strategies must be supported by raw data or documentation to be acceptable to the reviewer.

67

Risk Assessment Mitigation Example

IA Control Test Case/ Procedure Name Vulnerability Likelihood of Occurrence VIVM-1 NET-24 No one is established in writing to handle the IAVA process. Unlikely

Magnitude of Impact

High

Risk Level

Medium

Mitigation Residual Risk

The Network Security Officer oversees the installation of IAVAs as part of his day to day duties. Low

68

Risk Assessment Summary of Risk All of the residual risk results are tallied together to produce an overall risk, or summary of risk. The following criteria are used to derive the summary of risk:
If there is at least one high individual risk, the overall residual risk must be high. If there is at least one medium individual risk, the overall residual risk must be at least medium. If there are only low individual risk items, the overall residual risk is low.

69

Implement and Validate IACs

Finalize documentation and system configuration for Risk Assessment (PM/IAM) Load all artifacts and declare when ready for Validator

70

POA&Ms

71

Validation Report and POA&M Templates

In order for this template to be successfully utilized, Macros must be enabled. The status column from the Validation Report is tied to the status in the POA&M.
The Status on the POA&M will be automatically updated when changes are made to the Validation Report.

The valid status selections are Open, Closed and Inherited.

Upon completion of any or all tests identified in the Validation Report, depress the Update POA&M radio button. This action will automatically move any Closed or Inherited items to the appropriate tab. Also note that if the status is changed back to Open it will also automatically be returned to the Open tab.

If any additional tests are added onto the Validation Report, they will have to be manually added onto the POA&M. This will also require they be manually moved to the Closed and Inherited Tabs.
72

NUDOP

Env IACs

Collaboration

Test (Lab)

ATO

Operate

IV&V Development Operation

73