• Information Systems Security Manager (ISSM)

Naval Surface Warfare Center, Dahlgren Division, Dahlgren Laboratory, Computer and Network Security (Code CD2S)
17320 Dahlgren Road
Dahlgren, VA 22448
Telephone:  540-653-4150
Fax: 540-653-6143
iaweb@nswc.navy.mil

• Risks and countermeasures of the site
• Risks, valuation, criticality and countermeasures of the workgroup or domain.
• Risks and countermeasures on the individual IS.

For purposes of processing accreditation requests, we group systems as follows:

• Legacy systems with limited risks (e.g., PCs using only MS-DOS or versions of Windows prior to 3.1 and Macintoshes using MacOS 7.5 or earlier)
• Modern desktop systems for which best practices have been identified (e.g., Windows 95 and NT, MacOS 7.6 and later)
• Systems not covered above (servers, networks, Unix variants, classified systems, etc.)

Note that the lines of demarcation are not hard and fast. The grouping is done to provide optimum risk management and Security Officer empowerment.

• Process Description (NSWCDL systems)

1. Prepare and sign a Security Domain Package
2. The ISSO (or other knowledgeable person) prepares the Security Domain Package and reviews it with the Information Systems Security Office. The office provides quarterly training regarding Security Domains and is available for consultation as part of documenting the domain. The package addresses four major areas: valuation, criticality, contingency, and interconnection. When the document is complete, the responsible ISSO(s) and Line Manager sign the package attesting that it constitutes an acceptable risk. The IS Security Office files a copy of the completed domain package.
3. Identify the system details on accreditation request(s).
4. All systems included in the Domain Package are described on one or more Accreditation Request(s) as needed. Users provide basic information to the ISSO and sign the accreditation request acknowledging that the IS and information thereon belongs to DOD, and that use of the IS constitutes consent to monitoring. Multiple systems of the same architecture can be included on one request. If the domain contains more than one architecture (e.g., Windows 95 and Windows NT), at least one request per architecture is needed.
5. Conduct risk assessments and ST&E.
6. Complete a risk assessment for each architecture (e.g., Unix, Windows NT, Windows 95) contained in the Domain. If the system is (or will be) used for classified processing, a risk assessment for that is needed as well. The user (typically) determines the level of risk (low, medium, high) and marks the appropriate block for each threat area. Another knowledgeable individual, (typically the ISSO), then conducts Security Test and Evaluation (ST&E) to verify that all indicated countermeasures are in place and then passes (or fails) that particular vulnerability.
7. Accredit as warranted and update the accreditation database.
8. Presuming that the system passes the risk assessment and ST&E, the appropriate DAA can accredit that system.

Unclassified Legacy Systems.

This includes PCs using only MS-DOS or versions of Windows prior to 3.1 and Macintoshes using MacOS 7.5 or earlier. These systems are beginning to be phased out. There is a whitepaper that details this further. If you have an IS that fits this description, do not send the accreditation request to ISSM. It must be included in a Security Domain Package on file with the Information Systems Security Office and accredited by an ISSO in your department who has a signed appointment letter authorizing him or her as a Designated Approving Authority (aka Accreditation Express). If your department does not have an ISSO on Accreditation Express, now is a good time to do so. Please see the IS Security Web Page for details. The DAA updates the information in the IS Accreditation database and files the hard copy documentation.

Unclassified Modern Desktop Systems

If you have an IS other than what is described above, (i.e., a PC running Windows 3.1, Windows 95, Windows NT, or MacOS 7.6, MacOS 8.x, multi-user computer etc.) the same process applies. For the present, these accreditations are conducted by DAAs described above.

All Other ISs

As above, the user (typically) determines the level of risk (low, medium, high) based on countermeasures selected and marks the appropriate block for each threat area. An individual other than the person conducting the risk assessment, (typically the ISSO), then conducts Security Test and Evaluation (ST&E) to verify that all indicated countermeasures are in place and then passes (or fails) that particular vulnerability.

When the request and risk assessment are ready for review, the ISSO contacts the Information System Security Office to schedule a review. We will schedule you as soon as possible. When we review your request, we may or may not elect to conduct further ST&E. We will do one of the following three things:

1. accredit the IS if it is for unclassified processing and we think the request constitutes acceptable risk.
2. forward the request to the DAA for classified systems if it is for classified processing and we think it constitutes acceptable risk.
3. give the request back to you with our best judgement as to what you need to do to obtain accreditation.

If the IS is to be used for classified processing, it is advisable to prepare a cover sheet for the package that will let the DAA's administrative assistant know where to send the completed package once the DAA has accredited the system.

Once the IS has been accredited, the Security Officer then updates the information in the IS Accreditation database and files the completed request and risk assessment(s).

These include computers that belong to other activities and are located/used at NSWCDL as well as systems that are brought into our spaces but may not be used to process information for us. In any event these systems must be operated at an acceptable risk as described below:

These will be treated as NSWCDL systems for accreditation purposes. They are included in security domain packages and are described in appropriate risk assessments.

Use of these systems will be approved in writing by the cognizant Department Head (or designee). ISSOs will maintain a file of designees appointed in writing by the Department Head. The system will be accredited by the cognizant ISSO using (at least) an abbreviated risk assessment that stipulates the following minimum criteria:

1. The system will not record any classified information.
2. The system will not be connected to any NSWCDL network in any manner.
3. No files on the system will be transferred in any way to any system at NSWCDL.

The risk assessment will be signed by the user (constituting consent to the stated conditions), and the accrediting ISSO.

ISSOs have read and write access to the centralized accreditation database and maintain the hard copy documentation that supports entries in that database.

If you need to move an IS, coordinate the move with your ISSO.

If the move involves an IS used only for processing unclassified information and the accreditation is less than two years old, the ISSO can update the data base to reflect the new location. If the accreditation is over two years old, the IS really needs a current risk assessment to determine if the accreditation is valid.

If the move involves an IS used for processing classified information and the accreditation is less than one year old, the following guidelines apply:

• if the IS is being relocated to a similar or lower threat environment (e.g., office to office OR office to vault), the ISSO can send email (identifying the circumstances) to the ISSM requesting approval for the ISSO to update the database.
• if the IS is being relocated to a environment with an increased threat (e.g., vault to office), the IS must be re-accredited.

In either case, if the accreditation is over a year old, the IS really needs a current risk assessment to determine if the accreditation is valid.

If you have a current Security Domain Package on file with ISSM and need to accredit additional systems, the following guidelines apply:

• If the additions are for systems covered under accreditation express and change the domain valuation by 10% or less, the domain package need not be updated. The cognizant DAA may accredit.
• If the additions are for systems not covered under accreditation express and change the domain valuation by 10% or less, the domain package need not be updated. The cognizant ISSO schedules an appointment (as above) and provides a complete accreditation package (using previously prepared documentation such as SOPs, risk assessments, etc.) to ISSM for review as described above.
• If the additions are for systems covered under accreditation express and change the domain valuation by more than 10%, submit an updated Security Domain Package. The cognizant DAA may accredit.
• If the additions are for systems not covered under accreditation express and change the domain valuation by more than 10%, submit an updated Security Domain Package and a complete accreditation package (using previously prepared documentation such as SOPs, risk assessments, etc.) to ISSM for review as described above.

If you have an IS accredited to process classified information and you need to get it accredited to process unclassified information, it must be sanitized prior to downgrading (see below for information).

An IS must be sanitized prior to being downgraded. To sanitize an IS, you must remove all information. Contact your ISSO or take a look at one of our pages for details. You will need to complete a sanitization form and have it signed by your ISSO. Once the IS has been sanitized (and we have made the appropriate grants for the database), an Accreditation Express ISSO can update the record in the database. The ISSO must keep a record of the sanitization. If a classified IS is being excessed, it must have a sanitization certificate attached. If the system is unclassified, the folks who handle excessed equipment will perform the sanitization and complete the required paperwork.

ISSOs are responsible for maintaining current information in the Accreditation Database. When an IS is excessed, the ISSO needs to update the STATE field to reflect that the IS is not in service.

• An acknowledged state of relative risk substantiated by an updated and accurate Accreditation Database