Minimum standards for administrators of national security systems

1. NATIONAL INFORMATION ASSURANCE TRAINING STANDARD FOR SYSTEM ADMINISTRATORS (SA) http://www.cnss.gov/Assets/pdf/cnssi_4013.pdf Minimum standards for administrators of national security systems 11 IAVA

2. Committee on National Security Systems IA functions of an SA are: • work closely with the ISSO to ensure IS or network is used securely • participate in the IS Security incident reporting program • assist the ISSO in maintaining configuration control of systems and applications software • advise the ISSO of security anomalies or integrity loopholes • administer user identification or authentication mechanism of the IS or network. 11 IAVA

3. Differences at Three Levels of SA SA responsibility ENTRY LEVEL: describe and apply the appropriate actions to manage and administer an IS in a secure manner. INTERMEDIATE LEVEL: explain and implement the appropriate actions to manage and administer an IS. ADVANCED LEVEL: verify that the appropriate actions are implemented to manage and administer an IS In accordance with applicable IA regulations, policies, and guidelines. 11 IAVA

4. The Role of DISA in the IAVA PROCESS Version 2.1 11 June 2002 Information Assurance Vulnerability Alert Set 7 IAVA

5. 1. Introduction and Purpose The DOD is concerned with threats that must be protected through risk management. The ASD/C3I tasked: • Establish control of the Department's vulnerability alert system. • Provide CINCs, Services, and Agencies (C/S/A) access to vulnerability notifications that require action. • Require acknowledgement of action messages. • Require compliance and report status to DISA. • Track compliance and report to OSD. • Conduct random compliance checks. 11 IAVA

6. DISA and IAVA Process Handbook Two distinct responsibilities: • Act as agent managing vulnerability notices • Produce vulnerability notices and report statistics on the IAVA Web site Works for the National Communications System as part of DISA’s vulnerability management and is incorporated into configuration management. Intended to control down to the system asset level: the numbers of systems on which a vulnerability exists, • when compliance has been achieved, • when an extension has been requested, and • when an extension has been granted. 11 IAVA

7. Purpose Two tools: • IAVA system, a database tracking compliance statistics, and • Vulnerability Compliance Tracking System database system to track the status of vulnerabilities at the asset level. [Its statistics are rolled up to the IAVA system for a compliance view within the agency.] 11 IAVA

8. 2. The IAVA Process Vulnerabilities identified by or reported to DISA. The DOD-CERT analyses the vulnerability to determine its impact, severity, and ways of correcting or mitigating risk. If there is a need for action, it will inform the C/S/A by issuing either: 1) an IAVA – requires acknowledgement and compliance, 2) an Information Assurance Vulnerability Bulletin (IAVB) – requires acknowledgment, or 3) a Technical Advisory (TA) - notification only. 11 IAVA

9. CINC/Service/Agency Action Download the alert via the NIPRNET or SIPRNET Webpage Fix or comply and send status (complied or not). If not request an extension stating • assessment of risk (e.g.; vulnerability of environment to the exploit) • How system will be monitored for exploitation (e.g.; use of mitigating controls) • A Fix Action Plan with completion date Conduct random compliance checks 11 IAVA

10. VCTS Systems One for unclassified (Sensitive) and one for classified (no higher than secret) assets. All DISA IT assets susceptible to vulnerabilities are registered in the VCTS All IT susceptible to vulnerabilities must be registered Individual workstations will not be registered  the server will be registered and the field will show the number of workstations it supports. Individual machines not managed by a server environment must be registered to ensure proper tracking of alerts. 11 IAVA

11. Assets are: Laptop computers, network printers, facsimiles, and all PEDs need not be registered in the VCTS. However, DISA activities are encouraged to register the OSs. Each activity will then monitor the assets for vulnerabilities associated with these OS. Iin four categories: • organizational, • program level, • mainframe and • laboratory. 11 IAVA

12. Mainframe Assets Mainframe systems run services such as TCP/IP and the UNIX kernel; they must be registered in VCTS. Each logical domain/image must be registered. The system ID field should be populated with an IP address. • Because a mainframe system typically has a staff of systems programmers responsible for the software configuration, registration of mainframe assets will be managed by the ISSO. 11 IAVA

13. Compliance Status (1) Open: newasset impacted by an alert but, no protective actions have been put in place. Most alerts allow 30 days for compliance. If asset becomes operational and registered 30 days after the release of the alert, “open” status not allowed. Not Applicable: the SA, ISSO, ISSM or PM determined a recently released alert does not apply to a registered asset. User must justify this; may be reviewed in compliance validation. Fixed/In Compliance: SA or ISSO has determined the asset is in compliance. Extension Requested: extension submitted and being reviewed. Two types: • The DAA accepts the risk associated with nonstandard corrective action. • The extension used to request additional time for corrective action. 11 IAVA

14. Compliance Status (2) Extension Approved: request approved for a specified timeframe. Management must address the problem and ensure controls are in place. Extension Denied: the Approval Authority evaluated and denied request. SA/ISSO is responsible for immediately implementing corrective actions. Extension Expired: an approved extension has expired and corrective actions must be implemented or another extension request must be submitted. 11 IAVA

15. ISSM in the VCTS Process An ISSM must: • Validate user accounts and remove those not required. • Contact the primary SA for removal of permissions. • Request user account be inactivated • Validate current asset information in the databases. • Determine if the asset description information accurate and current. • Contact primary SA for action. • SA correct asset information • Ensure all ISSOs familiar with the registration process. • Ensure each asset has at least two users with update permission. • Validate extension requests for assets when needed. 11 IAVA

16. XOs in the VCTS Process Executive Officers (XOs) ensure that vulnerabilities are being managed by ISSMs. Must ensure that information recorded within VCTS accurate for their organization. Generally not given authority to update systems but does have browse authority to monitor progress in complying with vulnerability notices. An XO does not have to be given “browse” authority by the SA or ISSM for an asset. 11 IAVA

17. Vulnerability Notice Compliance The Vulnerability Notice Compliance Validation Process requires a Process for each C/S/A. DISA’s IAVA CV Process under development will provide weekly email notices to each organization’s ISSM and Deputy Director to review and validate all vulnerability notice entries in the VCTS. Each organization responsible to ensure that all data in VCTS is accurate and current. 11 IAVA