From: Subject: CERTIFICATION AND ACCREDITATION Date: Wed, 15 Aug 2012 08:03:03 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.ocio.usda.gov/directives/doc/DM3555-001.htm X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 CERTIFICATION AND ACCREDITATION

Chapter 11,=20 Part 1

CERTIFICATION AND ACCREDITATION=20 METHODOLOGY

 

 

1         =20 BACKGROUND

 

OMB Circular A-130, Appendix III = and the=20 Federal Information Security Management Act (FISMA) requires that all = federal=20 agencies institute an agency-wide information security program to = provide=20 information security for the information and information systems that = support=20 the operations and assets of the agency.  This includes those = systems=20 provided or managed by another agency, contractor, or other = source.  =20 All USDA agencies shall institute a comprehensive assessment of the = management,=20 operational, and technical security controls in an information system to = determine the extent to which the controls are implemented correctly, = operating=20 as intended, and producing the desired outcome with respect to = meeting a=20 specified set of security requirements for the system.  These = actions=20 are referred to as system certifications.   = Certification=20 supports the official management decision given by a senior agency = official to=20 authorize operation of an information system and to explicitly accept = the risk=20 to agency operations, agency assets, or individuals based on the = implementation=20 of an agreed-upon set of security controls.   This decision is = referred to as system accreditation.

 

All USDA IT systems require certification = and=20 accreditation prior to the system becoming operational.  The = Designated=20 Accrediting Authority (DAA) makes formal accreditation = determinations. =20 This action supports the regulatory requirement that every USDA system = must have=20 official approval to operate.

 

2         =20 POLICY

 

All USDA agencies and staff = offices will=20 formally certify and accredit all federal information systems in=20 accordance with this policy and the USDA Certification and Accreditation = Guide.  This guide applies to all information and information = systems=20 owned, leased, operated or connected to the Department of = Agriculture. =20 Agency/system owners are responsible for ensuring that all contractors = comply=20 with the C&A requirements defined by this policy for systems they = operate in=20 support of USDA=92s mission.  Agency CIOs act as both the entity = responsible=20 for the overall C&A process and as the Certifying Official = (CO). =20 Accordingly, agency CIOs will ensure that the Designated Accrediting = Authorities=20 (DAA) understands the C&A process,=20 including system risk factors, and accepts accreditation=20 responsibilities.  Further the agency CIO will ensure that the DAA = does not=20 delegate the security accreditation decision or signature authority to=20 subordinate levels.  The agency DAA will ensure that the final = review and=20 signatory authority of the CO is not delegated to subordinate = levels. =20 Other certifications tasks may be delegated at the CO=92s = discretion.  =20

 

Certified systems=20 will undergo an independent concurrence review by the ACIO-CS prior to=20 submission to the DAA. Concurrence reviews will be completed by the = ACIO-CS=20 within 30 days of receipt and the results will be reported to the CO in=20 writing.  All system reviews that result in significant = deficiencies will=20 be returned to the CO for corrective action and/or adjustment = necessitating that=20 the system be placed under an Interim Authority to Operate (IATO) until = the=20 deficiencies are resolved.    In addition, agencies and = staff=20 offices will electronically track significant deficiencies resulting = from the=20 concurrence review.  All USDA IT systems will be certified and = accredited=20 every 3 years, unless the system undergoes significant change.  = Significant=20 Change is defined in the USDA C&A Guide.  Systems accreditation = that=20 occurred prior to the C&A Policy release will be grandfathered under = the=20 previous accreditation guidance until its 3 -year = anniversary=20 or it undergoes significant change.  Agencies will begin the = C&A=20 process for re-accreditation in a in a timely fashion to ensure that the = process=20 is completed before the system anniversary date of the last = accreditation. =20 Agencies are reminded that the = Department=20 CIO has the right to terminate operation of systems that do not undergo = proper=20 certification and accreditation or that do not meet department security=20 requirements. 

 

Interim Authority To Operate = (IATO)=20 Requirements = =96 There are=20 no exceptions to the requirements to certify and accredit all USDA=20 systems.  However, if after assessing the results of the security=20 certification of the IT system, the CO recommends (with ACIO-CS = concurrence) to=20 the DAA and/or the DAA deems that the risk to the agency operations, = assets, or=20 resources is unacceptable, but there is an overarching mission necessity = to=20 place the IT system into operation or continue its operation, an IATO = may be=20 issued. An interim authorization provides a limited authorization = to=20 operate the IT system under specific terms and conditions and = acknowledges great=20 risk to the agency for a 6-month period.  An IATO is = rendered when=20 the identified security vulnerabilities in the IT system, resulting from = deficiencies in the planned or implemented security controls, are = significant=20 but can be addressed within a 6-month time frame.   IATOs can be granted by the DAA for = a maximum=20 period of 6 months.  Agencies will track and report = deficiencies=20 through the Plan of Action and Milestones (POA&M) process.  An=20 extension of this period requires the approval of the Department Chief=20 Information Officer (CIO) and will only be considered for compelling=20 reasons.   Agencies will forward approved copies of systems = IATOs to=20 the CS Certification and Accreditation Program Manager (PM) and those = will be=20 monitored and tracked to ensure that systems are progressing through the = certification and accreditation process.

 

All deficiencies, whether = significant or=20 reportable, must be entered and tracked using the approved database=20 system.  Significant Deficiencies tracked in the POA&M database = must be=20 resolved within 60 days.  Reportable Conditions must be resolved = within 180=20 days.  Agencies must present Cyber Security with verification=20 documentation, and receive concurrence, before a deficiency can be = considered=20 resolved. 

 

3         =20 PROCEDURES

 

Each USDA agency should complete = the=20 C&A phases for certifying and accrediting their systems. These = phases=20 consist of:

 

a        =20 Phase I : Pre-certification

Define Scope of = C&A

Identify Security = Controls

Conduct Privacy Impact = Assessment (PIA)=20

Review System Security = Plan

Review Initial Risk = Assessment

Review=20 approved Interconnection = Security=20 Agreements

Negotiate with = participants

 

b        =20 Phase II : Certification and Accreditation

Conduct ST&E

Update the Risk = Assessment

Update the System Security = Plan

Identify and = Report any=20 Residual Risk

Document Certification=20 Findings/Recommendation

Obtain ACIO-CS concurrence on = the=20 certification package

Accreditation = Decision

 

c         =20 Phase III : Post-accreditation

(Repeat Steps Above every 3 = years or when=20 significant system change occurs)

 

NIST, 800-37 permits the use of = a modified=20 version of the C&A process for systems categorized by the agency as = low=20 risk/ low impact.  In order to qualify as Low Risk/Low Impact, a = system=20 must be rated as low risk/low impact in all three of the assessment = categories=20 of confidentiality, integrity and availability.  These=20 low

risk/impact systems are only required to = complete=20 Phase 1, Pre-certification, which includes the security plan, risk = assessment=20 and  NIST 800-26, NIST Security Self-Assessment Guide for = Information=20 Technology Systems.

 

Please note:

The NIST 800-26 Self Assessment Checklist = or=20 equivalent is not an acceptable substitute for a Risk Assessment.  = These=20 checklists may be used as reference material to a Risk Assessment, but = do not=20 contain sufficient discussion and analysis of a system=92s = characterization,=20 mitigation or residual risk.

 

4         =20 RESPONSIBILITIES

 

a        =20 The Associate CIO for Cyber Security will:

 

(1)           = ;  =20 Develop and = publish=20 policy guidance to assist agencies and staff offices in the = certification and=20 accreditation (C&A) of IT systems;

 

(2)           = ;  =20 Make = available, if=20 feasible, a departmental contract to provide certification and = accreditation=20 services to agencies and staff offices;

 

(3)           = ;  =20 Provide = training on=20 C&A to agencies and staff offices, as required;

 

(4)           = ;  =20 The = departmental CIO=20 has formally delegated Certifying Official (CO) authority to the agency=20 CIOs.   However, certification packages will be submitted to = the=20 ACIO-CS for an in-depth concurrence review prior to submission to the=20 DAA

 

(5)           = ;  =20 Track the = status of IT=20 systems and the associated C&A actions and any approved IATOs to = ensure that=20 systems are certified and accredited within 6 months.

 

b        =20 Agency  Chief Information Officer will:

 

          &nbs= p;=20 General Process Duties

 

(1)           = ;  =20 Implement = and manage=20 the certification and accreditation of all agency IT systems in=20 accordance with this policy; ensures that systems with significant = deficiencies=20 are placed under an IATO in accordance with the requirements outlined = above and=20 that they are certified and accredited in a timely manner within the six = month=20 IATO period;

 

(2)           = ;  =20 Ensure that = a=20 Designated Accrediting Authority (s) is appointed in writing for each = agency IT=20 system and that they fully accept the responsibility for system risk and = operation;

 

(3)           = ;  =20 Ensure that = the DAA=20 designates an independent individual to act as the Agency CO for IT=20 systems;

ensure = that the CO=20 does not delegate final review and signature authority to subordinate=20 individuals;

 

(4)           = ;  =20 Disseminate = this=20 policy to all IT professionals, security officers and business owners = who will=20 be involved in the C&A process to ensure they understand and can = fulfill the=20 roles and responsibilities in this procedure;

 

(5)           = ;  =20 Support and = facilitate=20 the work the Certification Teams to ensure that agency IT systems are = certified=20 and accredited; approve ST&E teams, and ensure that final = C&A=20 packages are accurate and complete;

 

(6)           = ;  =20 Take = necessary actions=20 to ensure that system risks are mitigated by appropriate security = controls and=20 security issues are resolved;

 

(7)           = ;  =20 Monitor the = C&A=20 progress of systems and provide status to Cyber Security, including = those under=20 an IATO;

 

(8)           = ;  =20 Ensure that = all system=20 changes are examined to determine if re-certification and = re-accreditation of=20 the system must be performed; institute appropriate C&A action as a = result=20 of this examination;

 

(9)           = ;  =20 Ensure that = all agency=20 IT systems are routinely certified and accredited every 3 years or when=20 significant changes occurs in the system; and

 

(10)        =20 Ensure that = systems=20 that have significant deficiencies = uncovered as=20 a result of audits, concurrence reviews, IV&Vs or other authorized = processes=20 are placed under an IATO until these findings are resolved and that all=20 corrective actions are tracked and reported to CS through the Plan of = Action=20 & Milestones (POAM) process.

 

Certifying=20 Officials Duties

 

(1)           = ;  =20 Act as the=20 certification agent responsible for the comprehensive evaluation of the=20 management, operational and technical security controls within an IT=20 system;

 

(2)           = ;  =20 Manage and = coordinate=20 the functions of the Certification Team;

 

(3)           = ;  =20 Perform the = final=20 review of the certification package, prior to mandatory ACIO-CS = concurrence, and=20 ensures the signed package is timely and accurate (final review and = signature=20 authority will not be delegated to subordinate levels);

 

(4)           = ;  =20 Provides = recommended=20 corrective actions to reduce or eliminate vulnerabilities in IT systems = and=20 assesses system security plans for completeness and consistency; = and

 

(5)           = ;  =20 Makes = recommendations=20 to the DAA (Authorizing Official) for accreditation of an IT system, = after=20 obtaining concurrence of ACIO-CS.

 

c         =20 The agency Designated Accrediting Authority (DAA) = will:

 

(1)           = ;  =20 Act as the = Authorizing=20 Official with the authority to approve or the operation of an IT system = at an=20 acceptable level of risk;

 

(2)           = ;  =20 Authorize a = system to=20 operate as accredited or under an IATO only with the concurrence of the=20 ACIO-CS.

 

(3)           = ;  =20 Issue an = Interim=20 Authority to Operate (IATO), where appropriate, for an IT system based = on the=20 level of risk involved in system operation or for systems that have = major=20 deficiencies resulting from and IV&V;

 

(4)           = ;  =20 Deny = authorization for=20 an IT system=92s operation or halt a system=92s operation if = unacceptable security=20 risk; and

 

(5)           = ;  =20 Formally = designate=20 independent individuals responsibility for C&A activities in = writing; the=20 DAA shall not delegate the security accreditation decision and the = signing of=20 the associated Accreditation Decision Letter.

 

d        =20 The agency Information Systems Security Program Managers(ISSPM)=20 will:

 

 

(1)           = ;  =20 Assist in = the=20 certification and accreditation of all agency IT systems;

 

(2)           = ;  =20 Participate = in=20 Certification Teams providing guidance,

testing security controls and = assisting in=20 the preparation of the final C&A package, as required;

 

(3)           = ;  =20  Monitor and=20 electronically track using Plans of Action and Milestones (POAM) the = C&A=20 progress on IT systems and report progress to agency CIO, including all = systems=20 under IATO to ensure that deficiencies are corrected in a timely=20 manner;

 

(4)           = ;  =20 In = conjunction with=20 the agency Configuration Control Board (CCB), identify system changes = that=20 require

          =20 re-accreditation; and

 

(5)           = ;  =20 Participate = in the=20 preparation of IATO packages, as required.

 

 

-END=20 =96

Appendix A

 

United States Department of Agriculture (USDA) = Certification=20 and Accreditation Guide

 

 

 

 

 

 

 

 

 

 

 

 

 

Document = Configuration=20 Control

 

Version

Release=20 Date

Summary of=20 Changes

Version 1.0

April 2003

Initial Strawman =

Version 1.1

June 2003

Revised = Draft

Version 1.2

June 2003

Second Revised = Draft

Version 2.0

November = 2003

Third Revised = Draft

Version 3.0

Version 4       =

December 2003

March 2005

Fourth Revised = Draft

Fifth=20 Revision

Table of=20 Contents

 

1.         =20 INTRODUCTION=20 =85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85.1

1.1.        =20 Purpose=85=85=85=85..=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85.= 1

1.2.      =20 Interim = Authority=20 to Operate = Requirements=85=85=85=85=85=85=85=85=85=85=85=85..1

=

1.3         =20 General Support Systems and = Applications=85=85=85=85=85=85=85=85=85=85=85=85=852

1.4         =20 Background=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=85=85..2

1.5       =20 Scope=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=85=85=85=85=85=85=85=85=853

1.6       =20 Outcome=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=85=85=85=85=85=85=85=853

1.7       =20 Structure=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=85=85=85=85=85=85=85=85=853

 

2.         =20 ROLES AND=20 RESPONSIBILITIES=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= 5

2.1.      =20 Designated=20 Accrediting = Authority=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=855<= /SPAN>

2.2.      =20 Certifying=20 Official = (CO)=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=855 =

2.3.      =20 Certification=20 Team=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=856

2.4.      =20 Security = Test and=20 Evaluation = Team=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85..6=

2.5.      =20 Program = Manager=20 and System = Owner=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85..6

2.6.      =20 Information=20 Systems Security = Officer=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85..7=

2.7.      =20 Other = Supporting=20 Roles and Role Delegation =20 =85=85=85=85=85=85=85=85=85=85=85=85..7

 

3.         =20 The = C&A=20 Process=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=85=85.8

3.1.      =20 Phase = 1: =20 Pre-Certification=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =859 =20

3.1.1.    =20 Step = 1: =20 Define the System and Scope of the C&A = Effort=85=85=85=85=85=85=85=859

3.1.1.1. =20 Determine the=20 Security = Categorization=85=85=85..=85=85=85=85=85=85=85=85=85=85=85...9=

3.1.2.    =20 Step = 2: =20 Identify Security Controls and Construct a Compliance=20 Matrix=85=8511

3.1.3      Step 3: = Conduct=20 Privacy Impact Assessment=85=85=85=85=85=85=85=85=85=85=85=85=8512 =

3.1.4      Step 4: = Review the=20 System Security Plan=85=85=85=85=85=85=85=85=85=85=85=85=85=85.12 =

3.1.5.    =20 Step = 5: Review=20 the Initial Risk = Assessment=85=85=85=85=85=85=85=85=85=85=85=85=85.12

3.1.6.     =20 Step 6: Review approved Interconnection Security=20 Agreements=85=85=85=85=85.13

3.1.7       Step = 7:=20 Negotiate with = Participants=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85...13<= /P>

3.2.      =20 Phase = 2: =20 Certification and = Accreditation=85=85=85=85=85=85=85=85=85=85=85=85=85=85.14

3.2.1.    =20 Step = 8: =20 Conduct a Security Test and = Evaluation=85=85=85=85=85=85=85=85=85=85=85.14

3.2.2.    =20 Create=20 the = ST&E=20 Plan=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85..14

3.2.3.    =20 Execute the=20 Test = Plan=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85...15

3.2.3.1. =20 Create = the=20 ST&E Report and Recommend = Countermeasures=85=85=85=85=85=85..15

3.2.4.    =20 Step = 9: =20 Update the Risk = Assessment=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=8516

3.2.5.    =20 Step = 10:=20 Update the System Security = Plan=85=85=85=85=85=85=85=85=85=85=85=85=85=8516

3.2.6.    =20 Step = 11: =20 Document Certification = Findings=85=85=85=85=85=85=85=85=85=85=85=85=85...16

3.2.6.1. =20 Interim = Authority=20 to = Operate=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= .17

3.2.7.    =20 Step = 12: =20 Accreditation = Decision=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= 17

3.3.      =20 Phase 3: = Post-Accreditation = Phase=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85.18

3.3.1.    =20 Configuration=20 Management=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=8518

3.3.2.    =20 Re-Accreditation=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=85=85=85=85=85=85=85=85.19

 

4.         =20 Summary=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=85=85=85=85=85=85=85=85..20

 

 

TABLE  A-1=20 GLOSSARY OF TERMS

TABLE A-2 = ACRONYMS

TABLE A-3 = REFERENCES

TABLE A-4=20 DOCUMENTATION

TABLE A-5 USDA=20 CHECKLISTS

TABLE A-6 SECURITY = EVALUATION=20 REPORT

TABLE A-7 BASE = LEVEL EVALUATION=20 CRITERIA - RESERVED

TABLE A-8 SECURITY=20 ACCREDITATION DECISION LETTER SAMPLES

 

INTRODUCTION

Purpose

This Certification and Accreditation Guide is = intended to=20 provide a comprehensive and uniform approach to the certification and=20 accreditation (C&A) process.  Individuals responsible for, or = involved=20 in the C&A process, will use this guide as a resource to assist them = in=20 certifying and accrediting the United States Department of Agriculture = (USDA)=20 general support systems and major applications.

 

A primary purpose of this guide is to support the = Office of=20 Management and Budget (OMB) Circular A-130, Appendix III requirement for = agencies to =93ensure that a management official authorizes in writing = the use of=20 each system/application=85before beginning or significantly changing = processing in=20 the system.  Use of the system shall be re-authorized at least = every three=20 years.=94  Agencies are also reminded that the Department CIO has = the right=20 to terminate operation of a system that does not undergo proper = certification=20 and accreditation.

 

Ideally, the C&A process should be integrated = into the=20 system development life cycle (SDLC) during the capital planning and = investment=20 control (CPIC) process.  During development, the system security = plan (SSP)=20 should be written and the initial risk assessment completed in order to = provide=20 an assessment of the possible risks to the system.  Additionally, = the=20 security-related documents listed in Appendix D of this Guide should be=20 completed during this processphase.

 

However, many USDA legacy systems already in place = have not=20 gone through the C&A process as part of the SDLC.  The = requirement for=20 system approval applies to these systems as well.  If systems have = not=20 obtained official approval to operate prior to deployment, they must = complete=20 the C&A process and obtain approval to operate.  New = regulations state=20 that every USDA system and application must have official = approval to=20 operate. This approval can consist of an unconditional approval (which = is good=20 for three years or until a significant change occurs).  The = approval=20 can also be an Interim Authority to Operate (IATO), which is only = valid for=20 up to 6 months.  An extension of this period requires the = approval of=20 the Department Chief Information Officer (CIO) and will only be = considered for=20 compelling reasons.  An IATO can be granted if risks have been = identified=20 and a mitigation plan with a specific timetable for addressing those = risks has=20 been approved.

  

1.2=20      Interim Authority to Operate = (IATO)=20 Requirements 

 

The CO may make a recommendation, with the = ACIO-CS=92=20 concurrence, to the DAA to obtain an IATO if a mission critical system = has an=20 unacceptable level of risk to agency assets based on the security=20 certification.  An IATO may also be deemed necessary by the DAA if = there is=20 an overarching mission need to place a new system into operation or = continue=20 processing in an existing system. An IATO is rendered when the = identified=20 security vulnerabilities in the IT system, resulting from deficiencies = in the=20 planned or implemented security controls, are significant but can be = addressed=20 within a 6-month timeframe. An extension of this period requires the = approval of=20 the Department Chief Information Officer (CIO) and will only be = considered for=20 compelling reasons.  Agencies will forward IATO Request = Submissions=20 to the ACIO-CS and those will be monitored and tracked to ensure that = systems=20 are progressing through the certification and accreditation = process.  Phase=20 1 of the C&A Activities must be completed in order for an IATO to be = approved.  The IATO Request Submission is a structured approach to = monitor=20 the effectiveness of the security controls in the IT system = during the=20 6-month period. Consequently, the IATO Request Submission submitted by = the IT=20 system owner is used by the authorizing official and CS to = monitor the=20 progress in correcting deficiencies noted during the security=20 certification.  Agencies must forward to the C&A PM a copy of = the DAA=20 letter, indicating that the specified IT system has been granted an = IATO. =20 A template of the DAA IATO letter is in Appendix F along with a template = for the=20 IATO Submission.

 

All deficiencies, whether significant or = reportable, must be=20 entered and tracked using the approved database system.  = Significant=20 Deficiencies tracked in the POA&M database must be resolved within = 60=20 days.  Reportable Conditions must be resolved within 180 = days. =20 Agencies must present Cyber Security with verification documentation, = and=20 receive concurrence, before a deficiency can be considered = resolved. 

 

Finally, agencies should be reminded that, in = accordance with=20 OMB policy, an IT system is not accredited during the period of = limited=20 authorization to operate.  When the security-related deficiencies = have been=20 adequately addressed, the interim authorization should be lifted and the = IT=20 system accredited to operate. 

 

1.3     =20 General Support Systems and Applications

As stated above, all systems and applications are = required to=20 be certified and accredited.  The differences between General = Support=20 Systems (GSS) and Applications that are germane to the certification and = accreditation of such systems focus on the extent of activities = performed for=20 each.  An application =93performs a clearly defined function for = which there=20 are readily identifiable security considerations and needs=94[1] whereas=20 a GSS =93provides standard information security capabilities, such as = boundary=20 defense, incident detection and response, and key management, and also = delivers=20 common applications, such as office automation and electronic = mail=941.=20 The scope of the certification will vary depending on the type and = extent of=20 the systems.   For example, a GSS, such as the USDA Wide Area = Network=20 (WAN), will require extensive testing to ensure that all system = components are=20 evaluated against the baseline security requirements.  Applications = that=20 reside on a GSS that has already been certified and accredited may refer = to=20 portions of the GSS risk assessment and Security Testing & = Evaluation=20 (ST&E) activities (such as testing and document evaluation) on = certain=20 components used by those applications rather than repeating ST&E and = risk=20 assessment activities on those components.

 

1.4      = Background

The Federal Information Security Management Act[2] (FISMA)=20 is the most recent legal requirement mandating that Federal agencies = develop a=20 comprehensive IT security program.  Laws such as FISMA, as well as=20 requirements in OMB Circular A-130, mandate that security must be = developed at=20 both the programmatic and system levels. 

 

The National Institute of Standards and Technology = (NIST)=20 Special Publication (SP) 800-37 provides guidelines for security = certification=20 and accreditation of information technology (IT) systems, as does the = National=20 Security Telecommunications and Information Systems Security Instruction = (NSTISSI) No. 1000, National Information Assurance Certification and=20 Accreditation Process (NIACAP).  IT systems can only be allowed to = operate=20 if they do not compromise legal or regulatory security = requirements.

 

1.5=20      Scope

The scope of this guide includes identifying roles = and=20 responsibilities of key players, defining the C&A process, and = describing=20 the three phases that comprise the C&A process.  The guide is = based=20 on OMB Circular A-130, dated November 2000, NSTISSI No. 1000, = NIACAP,=20 dated April 2000, Federal Information Processing Standards (FIPS) = Publication=20 (PUB) 102, dated September 1983, NIST SP 800-37, May 2004, and = other=20 applicable Department and Federal IT security laws and regulations.

 

1.6=20      Outcome

The C&A methodology outlined in this guide will = provide=20 USDA system owners and program managers with uniform guidance on how to = certify=20 and accredit their IT systems.  Proper use of the C&A = methodology will=20 assure the Department that the level of security implemented and = controls in=20 place adequately protect assets given an acceptable level of residual=20 risk.  The Department will benefit from the C&A activities = performed on=20 IT systems in the following ways:

 

=B7        =20 Formal approval to operate

=B7        =20 Standard operating environment through utilization of = baseline=20 security requirements

=B7        =20 Clearly defined system boundaries

=B7        =20 Privacy implications reviewed (Privacy Impact = Assessment/System of=20 Records Notice)

=B7        =20 Documented security plans

=B7        =20 Defined and tested contingency plans

=B7        =20 Established configuration management processes

=B7        =20 Heightened information security awareness

=B7        =20 Validated security controls

=B7        =20 Measured levels of risk based on identified threats and=20 vulnerabilities

=B7        =20 Defined security roles and responsibilities

 

1.7=20      Structure

This guide is organized into four major = sections. =20 Section 1 introduces the Department=92s C&A Guide.  Section 2 = provides an=20 overview of the roles and responsibilities of the key parties involved = in the=20 C&A process. 

 

Section 3 describes the C&A process, which = consists of=20 three phases comprising 12 major steps.    A checklist = has been=20 included at the end of each phase.  These checklists are reminders = of all=20 the actions that occur during that specific phase of the C&A = process. =20 They are designed to provide a quick reference for all participants in = the=20 process.

 

Section 4 contains a summary of the C&A = methodology=20 described in this Guide.  Table A-1 provides a glossary of terms = used in=20 the document.  Table A-2 contains a list of acronyms.  Table = A-3=20 provides a list of document references used to develop this C&A=20 methodology.  Table A-4 provides a list of required system = documentation=20 that must be maintained for each system as part of the system=92s = certification=20 and accreditation.  Table A-5 provides a list of the USDA software=20 application and operating system checklists that have been developed for = use in=20 the C&A process.  Table A-6 provides templates for conditional = and=20 unconditional Security Evaluation Reports (SER), respectively.  = Table A-7=20 contains the evaluation criteria for various C&A documents.  = This table=20 exists as a separate guide to facilitate the usefulness of the = checklists since=20 they must be completed for all systems undergoing certification and=20 accreditation.   Table A-8 contains Security Accreditation = Decision=20 Letter (Samples).  Table A-9 is the form to use when submitting a = request=20 for an Interim Authority to Operate (IATO).

2       =20 ROLES AND RESPONSIBILITIES

 

The following sections describe the various = personnel=20 involved in the USDA C&A process and their particular = responsibilities.

 

2.1=20      Designated Accrediting = Authority

The Designated Accrediting Authority (DAA) is a = USDA program=20 area executive with the authority to evaluate the mission, business = case, and=20 budgetary needs for the system in view of the security risks present in = the=20 system=92s operating environment.  The DAA is a senior level = official or=20 executive who has the authority to formally approve the operation = of an=20 IT system at an acceptable level of risk within its environment.  = The DAA=20 is the business owner of the general support system or major application = being=20 certified.  By accrediting a system, the DAA assumes responsibility = for the=20 residual risks of operation of the system in a stated environment.  = The DAA=20 approves security requirements documents, memoranda of agreement (MOA),=20 memoranda of understanding (MOU), and any deviations from security = policies.=20

 

If the DAA is presented with a system with = unacceptable=20 risks, but a plan for remediation, he or she may issue an Interim = Authority to=20 Operate (IATO), which will allow the system to remain in operation for 6 = months.  During that time, the mitigation strategies for reducing = the=20 unacceptable risks should be implemented.  A regression ST&E = should=20 also be completed to ensure that the unacceptable risks are = mitigated. =20 IATOs are only good for six months; an extension of this period = requires the=20 approval of the Department Chief Information Officer (CIO).  =

 

In addition to having the authority to accredit = systems for=20 operation, the DAA has the authority to deny approval for systems to = operate=20 and, if the systems are already operational, the authority to halt = operations if=20 unacceptable security risks are found to exist.  The right to = reject=20 residual risk present for any general support system or major = application=20 remains the right of the DAA if they are not comfortable with the level = of risk=20 presented.

 

In some situations where IT systems interconnect,=20 certification and accreditation activities may involve multiple=20 DAAs.   If so, agreements detailing which security controls = are=20 expected to be on which systems must be established among the = responsible DAAs=20 and documented in the accreditation package.  In these cases, it = may be=20 advantageous to agree to a lead DAA to represent the other DAAs during = the=20 C&A process.  NIST SP 800-47 provides guidance on how to = coordinate=20 security for interconnecting systems.  Additionally, the DAAs shall = sign=20 system Interconnection Security Agreement (s).

 

In the event of inter-agency or inter-department = connections,=20 the DAAs should draft and sign MOAs or MOUs that provide details on = which agency=20 or department is responsible for what areas of security.

2.2=20      Certifying Official (CO)

The USDA Chief Information Officer (CIO) is the = Department=92s=20 Certifying Official (CO).  The CIO has delegated the authority to = certify=20 agency systems to each agency CIO.  Thus, the CO for each agency = will be=20 the agency CIO unless a conflict of interest exits.    If = the=20 agency CIO is also the DAA, the agency Administrator or Head will serve = as the=20 DAA or will appoint another senior executive level manager to act = in this=20 capacity who is not in the CIO=92s chain of command.  The CO = will be=20 the point of contact for the agency with regards to certification=20 activities.  The mission of the CO is to evaluate the certification = package=20 from a technical perspective, obtain the mandatory concurrence from the = ACIO-CS=20 and present a recommendation to the DAA in regards to the accreditation = of the=20 system.  At the conclusion of the C&A process, the = certification team=20 will present the certification package to the CO, who will evaluate the = risk to=20 the system.  At that point, the CO will make the final decision = about=20 whether or not to request concurrence from the ACIO-CS and, if = concurrence is=20 reached, recommend the DAA accredit the system and will prepare the=20 accreditation package to present to the DAA. 

2.3=20      Certification Team

The certification team consists of the technical = personnel=20 from the business unit responsible for conducting the certification=20 activities.  The certification team is responsible for identifying, = assessing, and documenting the risks associated with operating the = system,=20 coordinating C&A activities, and consolidating the final C&A=20 package.  The team will assess the vulnerabilities in the system, = determine=20 if the security controls are correctly implemented and effective, and = identify=20 the level of residual risk of the system. 

 

2.4=20      Security Test and Evaluation = Team

The security test and evaluation (ST&E) team = consists of=20 personnel independent of the IT infrastructure and business function and = is=20 responsible for performing the ST&E on the system to validate the = results of=20 the risk assessment and that the controls in the System Security Plan = (SSP) are=20 present and operating correctly on the system.  The ST&E team = should be=20 independent in the sense that they should not have a) been involved in = the=20 development of the system and b) been involved in the other = certification=20 activities, such as writing the SSP and conducting the risk = assessment. =20

 

In order to ensure independence, the ST&E team = must be=20 approved by the CO prior to the commencement of the C&A process.

 

The purpose of the ST&E is to ensure that the = risk=20 determinations made during the risk assessment are accurate and provide = a=20 thorough portrayal of the risks to the system and its data.  The = results of=20 the ST&E, together with the rest of the certification package, will = be=20 presented to the CO so that the CO may make an accurate determination of = the=20 risk to the system, obtain concurrence from the ACIO-CS and thus provide = an=20 informed accreditation recommendation to the DAA.

 

2.5=20      Program Manager and System = Owner

The Program Manager and System Owner = represent the=20 interests of the user community and the IT system throughout the = system=92s life=20 cycle.  The program manager is responsible for the system during = initial=20 development and acquisition, and is concerned with cost, schedule, and=20 performance issues.  The system owner assumes responsibility for = the system=20 after delivery and installation, and is responsible for system = operation, system=20 maintenance, and disposal.  Together they are responsible for = ensuring the=20 system is deployed and operated according to the security controls = documented in=20 the security plan and are also responsible for seeing that system users = and=20 security support personnel receive the requisite security = training. 

 

The program manager and system owner will = coordinate the=20 C&A effort and provide the necessary staff and information to the=20 certification team.  They will review the certification package = before it=20 is presented to the CO.

 

2.6=20      Information Systems Security=20 Officer

For operational systems, the Information Systems = Security=20 Officer (ISSO) is responsible for the day-to-day security of a = specific=20 IT system including physical security, personnel security, incident = handling,=20 and security awareness, training, and education.  The ISSO, in = conjunction=20 with the configuration control board (CCB) also identifies pending = system or=20 environment changes that may necessitate re-certification and = re-accreditation=20 of the system.  For developmental systems, the ISSO serves as the = principal=20 technical advisor to the program manager for all security-related = issues.

 

2.7 =     Other=20 Supporting Roles and Role Delegation

There are other individuals within USDA such as = user=20 representatives, security program managers, operations managers, and = facilities=20 managers that may also have concerns or interests in the C&A = process. =20 User representatives typically represent the operational interests of = the user=20 community and serve as the liaison for that community throughout the = life cycle=20 of the system.  User representatives may assist in the C&A = process to=20 ensure mission requirements are satisfied while meeting the security = controls=20 defined in the security plan.  Security program managers ensure a = standard=20 C&A process is used throughout the agency, provide internal C&A = guidance=20 or policy, and, if appropriate, review certification packages prior to = DAA=20 review.  Operations managers oversee the security operations and=20 administration of IT systems.  Facilities managers oversee changes = and=20 additions to facilities housing IT systems and ensure that changes in = facility=20 design or construction do not adversely affect the security of existing=20 systems.

 

2.8  Associate = Chief=20 Information Officer for Cyber Security (ACIO-CS)

 

Prior to formal submission of the certification = package to=20 the DAA, the CO will submit the package and all supporting documentation = to the=20 ACIO-CS for a mandatory Independent Verification and Validation=20 (IV&V).  The ACIO-CS will perform an in-depth IV&V of the=20 certification package and will either concur with the recommendation to=20 accredit, recommend/concur with the need (and requisite mitigation plan) = to=20 issue an IATO or make the determination that the certification package = is=20 insufficient for accreditation or an IATO.  The concurrence of the = ACIO-CS=20 is mandatory prior to submission to the DAA.

 

3       =20 The C&A Process

The C&A process is comprised of three = phases:  the=20 pre-certification phase; the certification and accreditation phase, and = the=20 post-accreditation phase.  Phase 1, the pre-certification phase, = has=20 various steps that include:  defining the scope of the C&A = effort,=20 identifying existing security controls, reviewing any approved=20 Interconnection Security Agreements (ISA), conducting Privacy Impact = Assessment=20 (PIA), reviewing the SSP, reviewing the initial risk assessment, and = negotiating=20 with the participants.  Phase 2, the certification and = accreditation phase,=20 consists of additional steps:  conducting the ST&E, updating = the risk=20 assessment with findings from the ST&E, updating the SSP, = documenting=20 certification findings; and forwarding the certification findings to the = DAA for=20 an accreditation decision.  Phase 3, the post-accreditation phase, = consists=20 of managing the configuration of the system and re-accreditation.  = The=20 various phases and steps are depicted in Figure 3-1 and are described = more fully=20 in the following sections.

 

Figure 3-1

The C&A Process (High & Medium = Systems)

 

 

 

Note: Low impact = systems=20 perform only Phase 1 and complete NIST 800-26 Self = Assessment.

 

3.1 = Phase=20 1:  Pre-Certification

Phase 1 involves gathering information about the = system to be=20 certified, determining the scope of the certification effort, validating = the=20 initial System Security Plan (SSP) for the system, performing the = initial=20 validation of the risk assessment and system security controls, and = determining=20 the C&A schedule.  During phase 1, the system owner or program = manager=20 will coordinate with all stakeholders in the C&A process to ensure = that the=20 certification schedule is set.

 

3.1.1      = Step=20 1:  Define the System and Scope of the C&A Effort (High, Medium, Low Systems)

During this phase, the certification team should = gather all=20 available system information (e.g., design documents, system = descriptions,=20 graphics, system plans, approved Interconnection Security Agreement, = Privacy=20 Impact Assessment, etc.) in order to get a comprehensive system = description and=20 to define the scope of the certification and accreditation effort.  = Defining the system involves cataloging the different types of software, = hardware, and communications equipment comprising the system in order to = understand what needs to be examined for the C&A effort.

 

During Phase 1, the C&A key participants - the = DAA, the=20 CO, the program manager, the system owner, the certification team, the = ISSO, and=20 other officials in the agency or department that have an interest in the = system=20 - should agree on the scope and schedule for C&A activities.  = It is=20 recommended that the ACIO-CS be involved at this point to assure that = the scope=20 and schedule is adequate.  The participants should also evaluate = the system=20 and determine the appropriate security categorization for the system in=20 writing.  The security categorization is determined by the levels = of=20 concern for confidentiality, integrity, and availability of data, and = defines=20 what activities will take place during the ST&E phase of the C&A = effort.  In addition, the certification team should inform the CO = about who=20 will be performing the ST&E.  The CO must approve of the = ST&E team=20 and ensure they are fully independent from the IT infrastructure and the = business function prior to the commencement of the rest of the C&A = process.=20

 

3.1.1.1           = ;           =20   Determine the Security Categorization (High, Medium, Low Systems)

In order to determine the appropriate security = categorization=20 for the system or application, the levels of concern must first be = identified=20 for confidentiality, integrity, and availability.  FIPS PUB 199 = provides=20 guidance for assigning security categorization factors for information = processed=20 on federal systems.  Each factor is assigned a level of low, = moderate, or=20 high.   Confidentiality provides assurance that the system = data is=20 protected from disclosure to unauthorized personnel, processes, or=20 devices.  Integrity provides assurance that the data processed by = the=20 system is protected from unauthorized, unanticipated, or unintentional=20 modification or destruction.  Availability provides assurance that = the=20 system data and resources will be available to authorized users on a = timely and=20 reliable basis.

The format for documenting the security = categorization is as=20 follows:

 

CATEGORIZATION =3D=20 [(confidentiality, RISK-LEVEL), (integrity, RISK-LEVEL), = (availability,=20 RISK-LEVEL)]

If the level is Low, Low, Low, agencies can = certify and=20 accredit the system using a modified process that requires only Phase 1=20 activities and the completion of NIST-800-26 prior to the formal = accreditation=20 of the system.  However, if the score contains one rating of medium = or=20 high, the system must be rated as medium or high impact and proceed = through the=20 complete process described in Section 3.

 

Table 3-1 below provides guidance on how to = determine which=20 level of concern should be assigned to each factor.

Table 3-1

Levels of Concern=20 for Confidentiality, Integrity, and Availability

 

Level of Risk

 

LOW

MODERATE

HIGH

Confidentiality=20

Preserving authorized = restrictions=20 on information access and disclosure, including means for = protecting=20 personal privacy and proprietary information.

[44 U.S.C=20 =A73542]

The = unauthorized=20 disclosure of information could be expected to have a limited = adverse=20 effect on agency operations (including mission, functions, image, = or=20 reputation), agency assets, or individuals.  A loss of=20 confidentiality could be expected to cause a negative outcome or = result in=20 limited damage to operations or assets, requiring minor corrective = repairs.

The = unauthorized=20 disclosure of information could be expected to have a = serious=20 adverse effect on agency operations (including mission, functions, = image,=20 or reputation), agency assets, or individuals.  A loss of=20 confidentiality could be expected to cause significant degradation = in=20 mission capability, place the agency at a significant = disadvantage, or=20 result in major damage to assets, requiring extensive corrective = actions=20 or repairs.

The = unauthorized=20 disclosure of information could be expected to have a = severe or=20 catastrophic adverse effect on agency operations (including = mission, functions, image, or reputation), agency assets, or=20 individuals.  A loss of confidentiality could be expected to = cause a=20 loss of mission capability for a period that poses a threat to = human life,=20 or results in a loss of major assets.

Integrity

Guarding = against improper=20 information modification, destruction, and includes ensuring = information=20 non-repudiation and authenticity.

[44 U.S.C.=20 =A73542]

The = unauthorized=20 modification or destruction of information could be expected to = have a=20 limited adverse effect on agency operations (including mission, = functions,=20 image, or reputation), agency assets, or individuals.  A loss = of=20 integrity could be expected to cause a negative outcome or result = in=20 limited damage to operations or assets, requiring minor corrective = actions=20 or repairs.

The = unauthorized=20 modification or destruction of information could be expected to = have a=20 serious adverse effect on agency operations (including = mission,=20 functions, image, or reputation), agency assets, or = individuals.  A=20 loss of integrity could be expected to cause significant = degradation in=20 mission capability, place the agency at a significant = disadvantage, or=20 result in major damage to assets, requiring extensive corrective = actions=20 or repairs.

The = unauthorized=20 modification or destruction of information could be expected to = have a=20 severe or catastrophic adverse effect on agency = operations=20 (including mission, functions, image, or reputation), agency = assets, or=20 individuals.  A loss of integrity could be expected to cause = a loss=20 of mission capability for a period that poses a threat to human = life, or=20 results in a loss of major assets.

Availability

Ensuring = timely and=20 reliable access to and use of information.

[44 U.S.C.=20 =A73542]

The = disruption of access=20 to information could be expected to have a limited adverse effect = on=20 agency operations (including mission, functions, image, or = reputation),=20 agency assets, or individuals.  A loss of availability could = be=20 expected to cause a negative outcome or result in limited damage = to=20 operations or assets, requiring minor corrective = repairs.

The = disruption of access=20 to information could be expected to have a serious adverse = effect=20 on agency operations (including mission, functions, image, or = reputation),=20 agency assets, or individuals.  A loss of availability could = be=20 expected to cause significant degradation in mission capability, = place the=20 agency at a significant disadvantage, or result in major damage to = assets,=20 requiring extensive corrective actions or repairs.

The = disruption of access=20 to information could be expected to have a severe or=20 catastrophic adverse effect on agency operations (including = mission, functions, image, or reputation), agency assets, or=20 individuals.  A loss of availability could be expected to = cause a=20 loss of mission capability for a period that poses a threat to = human life,=20 or results in a loss of major = assets.

*Adapted from FIPS = PUB 199,=20 =93Security Categorization of Federal Information and Information = Systems=94, Table=20 1

 

3.1.2      = Step=20 2:  Identify Security Controls=20 and Construct a Compliance Matrix (High,  Medium & Low = Systems)

During this step, the team should identify all = security=20 controls that should be present on the system including those specified = in the=20 SSP, review system privacy implications to include preparation of a = Privacy=20 Impact Analysis (PIA) and Systems of Records (SOR) Notice (if = required),=20 and additional requirements needed to secure the system at the = proper=20 security categorization.    The controls should be = compiled from=20 USDA Cyber Security Manual 3500, other federal guidance, including OMB = A-130,=20 NIST 800-53, FISMA, and industry best practices.

 

The security controls should include management, = operational,=20 and technical controls for the system, as it will be operated, as well = as=20 environmental controls and physical security controls. Once the security = controls are identified, a Security Controls Compliance Matrix (SCCM) = shall be=20 constructed.  This matrix should list each security control, the = reference=20 from which the security control was derived, and whether or not the = control has=20 been implemented.  The SCCM shall be completed during ST&E and=20 submitted as part of the certification package.  Table 3-2 provides = an=20 example of an SCCM entry.

Table 3-2

Sample Security Controls Compliance Matrix

 

Security Control

Compliance

Comments

Yes

No

Other

Assignment=20 of Responsibilities

1.

Responsibility for=20 security has been assigned in writing to an individual trained in = the=20 technology used in the system and in providing security for such=20 technology (OMB Circular A-130 Appendix III, Section = A-3)

 

 

 

 

 

 

3.1.3    Step 3: Conduct a = Privacy Impact=20 Assessment (PIA) and if required complete a System of Records Notice=20 (SOR)        (High, Medium, Low=20 Systems)

During this step, agencies should determine the = impact the=20 system data has on individual privacy.  Therefore, each agency = shall=20 complete the Privacy Impact Assessment detailed in Chapter 3, Part 2 of = the=20 Cyber Security Manual.  This measure ensures that agencies have = thoroughly=20 examined the privacy implications of system data collection.  In = addition,=20 The Privacy Act requires agencies to publish a System of Records (SOR) = Notice=20 subject to 5 U.S.C. 552(E)(4).  Specifically, a =93system of = records=94 is=20 defined as a group of records under the control of any agency from which = information is retrieved by the name of the individual or by some = identifying=20 number, symbol, or other identifying particular assigned to the=20 individual.  DM 3555-001, Chapter 11, Part 1, Certification and=20 Accreditation, Appendix C, contains additional guidance on SOR Notices. = in the=20 Appendices.  SOR shall be reviewed and updated every two years to = ensure=20 they remain current.

3.1.4      = Step=20 4:  Review the System Security Plan   (High, Medium, = Low=20 Systems)

The system security plan should provide a system = description,=20 a list of the security requirements for the system, and should explain = how the=20 system security controls meet the security requirements.  The = initial SSP=20 should be created during system development as part of the security = requirements=20 definition for the system.  SSPs should be updated whenever changes = are=20 made to the security posture of the system.

 

During this step, the existing SSP should be = reviewed to=20 ensure that it accurately follows the methodology in the USDA OCIO=92s = Annual=20 Guide to System Security Plans and NIST 800-18, =93Guide for Developing = Security=20 Plans for Information Technology Systems,=94 and describes the most = current system=20 configuration and all the security controls included in the = system.  The=20 team should also verify that the controls described are appropriate for = the=20 security categorization and that the SSP provides information about any = user=20 organizations, both internal and external, that connect to the = system.  If=20 the system does interconnect with other systems or organizations, = details about=20 the security controls on those connections shall be documented in an = ISA.

 

Specific review criteria for SSPs are presented in = Appendix=20 G, =93Base Level Document Evaluation Criteria.=94  There are = separate SSP=20 evaluation documents for GSS and applications.  These = criteria will=20 be used by the ST&E team to review the SSP, so it is essential that = the SSP=20 fulfill the criteria presented.

 

3.1.5      = Step=20 5: Review the Initial Risk Assessment (High, Medium, Low = Systems)

After the SSP is reviewed, the initial risk = assessment should=20 be inspected to ensure that it identifies all apparent threats and=20 vulnerabilities in the IT system and is consistent with the guidance = provided in=20 the USDA Risk Assessment Methodology, DM 3540-001, and NIST 800-30, = =93Risk=20 Management Guide for IT Systems=94.  The risk assessment should = also=20 determine the overall level of risk present on the system given the type = of data=20 the system processes, the security controls on the system, and the = system=92s=20 operating environment.  The initial risk assessment should be = performed=20 before the system is fielded to verify that the security requirements = specified=20 during development have been met.  Risk assessments shall be = updated every=20 time there is a change to the security controls on the system that might = affect=20 the residual risk to the system.

 

Please note: = The NIST=20 800-26 Self Assessment Checklist or equivalent is not an acceptable = substitute=20 for a Risk Assessment.  These checklists may be used as reference = material=20 to a Risk Assessment, but do not contain sufficient discussion and = analysis of a=20 system=92s characterization, mitigation or residual risk.

 

Specific review criteria for risk assessments are = presented=20 in Appendix G, =93Base Level Document Evaluation Criteria.=94  = These criteria=20 will be used by the ST&E team to review the risk assessment report, = so it is=20 imperative that the risk assessment fulfills the criteria presented.

 

3.1.6   Step 6: Review the=20 Interconnection Security Agreement (ISA) (High, Medium,

           =20 Low Systems)

If this system will be connected to other IT = systems, the=20 business owner must discuss the requirements for connectivity with the = other=20 system=92s business owner and work to identify the security requirements = for this=20 connection.  The ISA is started during the Initiation Phase of the = SDLC, is=20 refined during the Acquisition/Development Phase but the ISA may not be=20 completed until the actual system Implementation Phase.  An ISA = will be=20 done for each system that will be connected to the new system.  = Additional=20 guidance on preparing the ISA is contained in Chapter 15, Part 1, = Security=20 Controls in the System Development Life Cycle (SDLC).

 

3.1.7   = Step 7:=20 Negotiate with Participants  (High, Medium, Low Systems)

After steps 1 through 4 are complete, all the = participants,=20 including the DAA, the CO, the program manager, the system owner, and=20 certification team should meet to review the extent and scope of the = planned=20 C&A effort.  The participants should review the = confidentiality,=20 integrity, and availability levels determined for the system and should = verify=20 that they are accurate and that the security categorization is = appropriate for=20 the system.  The participants should also review the SCCM to ensure = that it=20 accurately reflects the security requirements applicable to the = system.  At=20 this point, a schedule should be set for the remaining steps in the = C&A=20 effort.  This step should also occur for Low Impact/Low /Risk = systems even=20 though the required actions are less stringent.

 

The checklist below provides a quick reminder of = all=20 activities that should take place during Phase 1 of the C&A = process.

 

Phase 1 Checklist

 

Has = the scope of=20 the C&A effort been defined?

 

Has = the security=20 categorization been determined and documented?

 

Have the Security=20 Controls been identified?

Has = a review of=20 the approved ISA been done?

Has = a PIA been=20 conducted? 

 

Has = a Security=20 Control Compliance Matrix been constructed?

 

Has = the System=20 Security Plan been reviewed?

 

Has = the Risk=20 Assessment been reviewed?

 

Have all=20 participants in the C&A process negotiated a schedule for the=20 remaining C&A activities?

 

Guidance for Low Impact Systems: For = low impact=20 systems, the information system owner may employ the services of the = Information=20 Systems Security Officer or other designated individuals to prepare the = security=20 assessment report containing the results of the NIST 800-26, Self=20 Assessment.  The security assessment report, based on NIST 800-26, = can be=20 an abbreviated document synopsizing the results and highlighting those = areas=20 that need further attention.   For low impact systems the=20 accreditation packages consists of: the updated system security plan, an = abbreviated NIST 800-26 Security Assessment Report, updated Risk = Assessment,=20 Security Categorization Document, and a Plan of Action and Milestones=20 (POA&M).  Note: the POA&M is a new requirement.

 

3.2    =20   Phase 2:  Certification and Accreditation = (High=20 & Medium Systems)

During the certification and accreditation phase, = the=20 certification team will conduct ST&E to evaluate the effectiveness = of the=20 security controls on the IT system, and then use the results of the = ST&E to=20 update the risk assessment and the SSP.   The results of this = phase=20 will be documented as certification findings and included in the final=20 certification package.  The certification package will then be = presented to=20 the DAA for a final accreditation decision.

 

3.2.1      = Step=20 8:  Conduct a Security Test and Evaluation (High & Medium=20 Systems)

During this step, the team should evaluate the = effectiveness=20 of the security controls through hands-on testing.  ST&E = consists of three steps:  creating the ST&E Plan, executing the = test=20 procedures, and documenting the results in the ST&E Report with = recommended=20 countermeasures.  Figure 3-2 illustrates the three main steps (and = the=20 sub-steps) involved in performing an ST&E.

 

Figure 3-2

Security Test and=20 Evaluation Process

 

3.2.2     =20 Create = the=20 ST&E Plan (High & Medium Systems)

There are two steps involved in writing an ST&E = plan.  First, test objectives should be derived from the security = controls=20 identified in Phase 1, Step 2 and compiled in the SCCM.  The test=20 objectives should correspond to the appropriate technical requirements = to test=20 the security features of operating systems and software used for the = system,=20 administrative, procedural, environmental, physical, and communications = security=20 requirements.

 

Second, detailed procedures shall be written to = test each=20 control or requirement.  Procedures can consist of hands-on testing = for=20 technical requirements, interviews with personnel for administrative=20 requirements, document review for procedural requirements, and = observation of=20 facilities for environmental and physical requirements, or a combination = of=20 techniques.

The extent of the ST&E activities will vary = according to=20 the security categorization of the system.  Systems that process=20 information at a higher sensitivity or criticality level will need more = involved=20 verification activities, such as penetration testing, than systems that = process=20 non-sensitive information.

 

The USDA has created security checklists for many = popular=20 operating systems and software packages.  These checklists should = be used=20 as the base technical test objective set for ST&E plans, where=20 applicable.   Table A-5 contains the most recent list of USDA=20 checklists available.

These lists can and should be used to develop the = test=20 procedures to be executed in the next step.

 

3.2.3     =20 Execute the=20 Test Plan (High & Medium Systems)

After the ST&E plan has been approved by the = C&A=20 officials, the test procedures in the plan shall be executed.  An = important=20 part of the ST&E is the careful review of security-related = documentation,=20 such as the risk assessment, PIA (if required), SSP, Security = Features=20 User=92s Guide (SFUG), the Trusted Facility Manual (TFM), and the = Contingency Plan=20 in accordance with DM 3500, CS-032 and CS-033.  A successfully = tested=20 and executable Contingency Plan is required for the completion of = the=20 ST&E.  These documents should be reviewed to ensure that they = are: 1)=20 developed in accordance with the appropriate USDA and federal guidance; = and 2)=20 that they are up-to-date and usable for their intended purpose.  A = detailed=20 list of security-related documentation that should be reviewed is = included as=20 Table A-4 of this document.  Table A-7 provides the evaluation = criteria=20 that should be used to review each document.

 

During testing, two witnesses =96 one from the = certification=20 team and one person from the system owner=92s office =96 should witness = all ST&E=20 activities to ensure that all procedures are properly executed.  =

 

3.2.3.1           = ;           =20 Create the ST&E Report and Recommend Countermeasures = (High &=20 Medium Systems)

After the testing activities are complete, any = findings from=20 the testing should be documented in a ST&E report.    = The=20 report should identify which controls are complete, which security = controls are=20 only partially implemented and those controls that are either not = implemented or=20 are ineffective.  These results will be used as input to update the = risk=20 assessment.

 

After the ST&E report is complete, the system = owner and=20 the program manager should discuss the appropriate countermeasures to be = implemented.  These countermeasures should address any security=20 requirements that were found to be not implemented or = ineffective.  =20 Recommended countermeasures may be implemented immediately or may be = included as=20 part of a remediation plan and schedule for an IATO.

 

3.2.4      = Step=20 9:  Update the Risk Assessment (High & Medium Systems)

This step involves using the results from the = ST&E to=20 update the risk assessment and determine the remaining risk for the = system once=20 corrective actions have taken place to address findings from the=20 ST&E.    Updates to the risk assessment should be = included in=20 the form of an addendum to the original risk assessment report.  = Risk=20 should be determined for both individual findings and the overall system = or=20 application.  This risk determination will be included as part of = the=20 certification package.  Both the USDA Risk Assessment Methodology = and the=20 NIST SP 800-30 should be used to ensure that all necessary risk = assessment areas=20 are completed.

 

The risk assessment update should consist of the = following=20 steps, as shown in Figure 3-3:

 

  • The list of threats to the system should be=20 reviewed.  The list should include but not be limited to hackers, = malicious insiders, attacks against the system facility, and natural=20 disasters.=20
  • Assess each system vulnerability identified = during the=20 ST&E.  Evaluate the likelihood that one of the identified = threats=20 will exploit an identified vulnerability.=20
  • Assess the possible impact to the system and the = agency if=20 the vulnerability was exploited.=20
  • Make a determination of risk based on the = likelihood that=20 the threat will exploit the vulnerability, and the impact that would = result.=20
  • Evaluate the risks of all identified = vulnerabilities to=20 determine an overall level of risk for the system or application. =

 

Figure 3-3

Risk = Assessment=20 Steps

3.2.5      = Step=20 10: Update the System Security Plan, ISA and PIA (High & Medium=20 Systems)

Using the guidance in NIST SP 800-18, the SSP = should be=20 updated to reflect the results of the ST&E activities and the final = risk=20 assessment.  Updates should also be made in the approved ISA &=20 PIA.  Any countermeasures implemented as a result of the ST&E = findings=20 should be added to the list of system security controls.

 

3.2.6      = Step=20 11:  Document Certification Findings (High & Medium = Systems)

Once the certification activities are complete, the = certification team should document the findings from the certification = process=20 in a Security Evaluation Report (SER).  This report will summarize = the=20 findings and other relevant security issues identified during = certification=20 activities.  A template for the SER is included as Appendix F of = this=20 document.  The certification team then compiles this report. =20 Certification findings should include ST&E findings, risk assessment = findings, and any other relevant issues discussed during certification=20 activities.  These findings should be compiled .  = Certification=20 findings should include ST&E findings, risk assessment findings, and = any=20 other relevant issues discussed during certification activities.  = These=20 findings should be compiled, along = with the=20 other certification documents into a certification package and forwarded = to the=20 CO for review.  Table 3-3 below contains a list of the items that = should be=20 included as part of the certification package.

 

Table 3-3

Certification=20 Package Contents (High & Medium Systems)

Certification Package

 

Security Controls=20 Compliance Matrix (completed)

 

Security Test and=20 Evaluation Report

Approved=20 Interconnection Security

 Agreement

PIA/SOR Notice=20 (if required)

 

Risk=20 Assessment

 

System Security=20 Plan

 

Security=20 Evaluation Report

Note the Certification Package Contents for = Low Impact=20 Systems - For low impact systems the security accreditation package = consists=20 of: the updated System Security Plan, an updated Risk Assessment, an = abbreviated=20 NIST 800-26 Security Assessment Report,  Security = Categorization=20 Document, and the Plan of Action and Milestones.

 

The CO will evaluate the risks and issues presented = in the=20 SER and the other documents in the certification package.  The CO = then=20 develops a Certification Statement that states the extent to which the = system=20 meets its security requirements.  As part of the Certification = Statement,=20 the CO also provides a recommendation for an accreditation = decision.  The=20 CO then forwards the certification statement and the SER to the ACIO-CS = for=20 mandatory concurrence.  If the ACIO-CS concurs, the CO will forward = the=20 package to the DAA with the recommended accreditation decision.  =

 

3.2.6.1  Interim Authority to = Operate

See = Section 1.2 for=20 information on Interim Authority to Operate.

 

3.2.7      = Step=20 12:  Accreditation Decision  (High, Medium & Low = Systems)

During the final step of Phase 2, the DAA will = review the=20 Security Evaluation Report and issue the decision to issue a full = accreditation=20 or to deny accreditation after weighing the residual risk and other = factors=20 discussed in the package.   In the case of a low impact = system, the=20 DAA will review the SSP, Risk Assessment and abbreviated Self Assessment = and=20 make a risk based decision to grant the system accreditation or deny the = system=20 accreditation because the risks to the system are not at an acceptable=20 level.  Based on an evaluation of residual risk, the CO=92s = recommendation=20 and the ACIO-CS=92 concurrence, the DAA can make a risk-based decision = to grant=20 system accreditation or to deny system accreditation because the risks = to the=20 system are not at an acceptable level.  The accreditation decision = will be=20 documented in the final accreditation package, which consists of the=20 accreditation letter and supporting documentation and rationale for the=20 accreditation decision. 

 

The = following checklist=20 provides a reminder of all the actions that should take place during = Phase 2 of=20 the C&A process for high and medium impact systems:

 

 

Phase 2 Checklist

 

Has = the ST&E=20 Plan been created and approved?

 

Has = security=20 testing been performed?

Have Privacy=20 Implications been reviewed (if required)?

 

Has = the approved=20 ISA been reviewed?

Has = the ST&E=20 Report been written?

 

Were the=20 countermeasures recommended in the ST&E report implemented on = the=20 system?

 

Has = the Risk=20 Assessment been updated?

 

Has = the System=20 Security Plan been updated?

 

Have the=20 certification findings been documented?

 

Has = the=20 certification package been forwarded to the CO?

 

Has = the=20 certification package obtained ACIO-CS concurrence?

 

Has = the CO=20 completed a Security Evaluation Report and forwarded it to the=20 DAA?

 

Has = the DAA=20 issued an accreditation = decision?

 

Note the Certification Package Contents for = Low Impact=20 Systems - For low impact systems the security accreditation package = consists=20 of: the updated System Security Plan, an abbreviated Security Assessment = Report,=20 updated Risk Assessment, Security Categorization Document, and = the Plan=20 of Action and Milestones.

 

3.3     = Phase 3:=20 Post-Accreditation Phase

During the post-accreditation phase, the system = configuration=20 will be managed to ensure that changes to the system are monitored to = ensure=20 that they do not adversely affect the security posture of the system and = to=20 facilitate follow-on C&A activities.  Additionally, the system = owner=20 should keep the SSP, risk assessment, as well as other documents = current, adding=20 any new security controls as they are implemented.  Periodic = testing (at=20 least annually) of the Contingency Plan is a necessary component of the=20 Post-Accreditation Phase and, although this may be a part of the SSP, it = needs=20 to be addressed at a higher level of visibility.  Finally, at the = end of=20 Phase 3, the system will go through the C&A process again as part of = the=20 re-accreditation of the system.

 

3.3.1     =20 Configuration Management

Once the system or application has been officially=20 accredited, the system owner should maintain configuration control over = the=20 system to ensure that the security posture of the system is not = threatened by=20 authorized or unauthorized changes to system software or hardware.  = Any=20 changes to system security settings, hardware, or software should be = discussed=20 and approved by the CCB.  Additionally, a security professional = should be=20 on the CCB to ensure that security issues are covered and = addressed. 

 

Any changes that are implemented should be = documented in the=20 SSP (for security changes), design documentation (for software code = changes), or=20 the inventory list (for hardware and/or software changes).  = Large-scale=20 system changes (e.g., software version changes, operating system = changes) may=20 require re-accreditation activities to ensure that the system has not be = exposed=20 to additional risk.

 

3.3.2     =20 Re-Accreditation

Federal regulations mandate that systems be = re-accredited=20 every three years or when significant changes are made to the system=20 configuration.  Program managers and system owners should keep this = in mind=20 when planning system changes.  If the system is not significantly = altered,=20 the system owner should begin the certification and accreditation = process for=20 re-accreditation in a timely fashion to ensure that the process is = complete=20 before the three-year anniversary of the system accreditation has = passed.

 

The following checklist provides a reminder of all = the=20 actions that should take place during Phase 3 of the C&A = process.

 

Phase 3 Checklist

 

Has = the system=20 owner maintained configuration control?

 

Have all changes=20 to the system been approved by the CCB?

 

Have the hardware=20 and software inventories been updated every time the system = configuration=20 changed?

 

If = major system=20 changes have been implemented, has the system been re-accredited = in its=20 new configuration?

 

Is = the three-year=20 anniversary of the system accreditation approaching?  If so, = have=20 plans been made to begin the re-accreditation=20 process?

 

4           = ;=20 Summary

Certification and accreditation includes technical = and=20 non-technical assessments that establish the extent to which the system = or=20 application meets a set of specified security requirements for its task = and=20 operational environment.  The job of the Certifying Official is to = provide=20 a technical evaluation.  The ACIO-CS will provide assurance that = the=20 certification package meets federal and USDA policy and processes. The = outcome=20 of this process=BEthe = accreditation=BEassures the DAA that the level = of security=20 used will protect systems information and processing capabilities.  =

 

The C&A process should be integrated into the = SDLC during=20 CPIC process.  New regulations state that every USDA general = support=20 system or application must have official approval to operate. If systems = have=20 not obtained official approval to operate prior to deployment, they must = complete the C&A process and obtain approval to operate.

 

In summary, the C&A process comprises three = phases: =20 the pre-certification phase; the certification and accreditation phase, = and the=20 post-accreditation phase.  Phase 1, the pre-certification phase, = has=20 several steps:  defining the scope of the C&A effort, = identifying=20 existing security controls, reviewing the Interconnectivity Security = Agreement=20 (ISA), determining Privacy implications, reviewing the SSP, = reviewing the=20 initial risk assessment, and negotiating with the participants.  = Low=20 Impact/Low Risk systems follow a streamlined certification process, but = still=20 require approval by the DAA in order to operate.  Phase 2, = the=20 certification and accreditation phase, consists of additional steps that = include: conducting the ST&E, updating the risk assessment with = findings=20 from the ST&E, reviewing PIAs, updating ISAs and SSP, documenting=20 certification findings; and forwarding the certification findings to the = DAA for=20 an accreditation decision.  Phase 3, the post-accreditation phase, = consists=20 of managing the configuration of the system and re-accreditation every = three=20 years or when the system changes significantly.

 

 

 

TABLE=20 A-1:  GLOSSARY OF TERMS

Accreditation: The formal declaration by the = DAA that=20 the system is approved to operate using a prescribed set of safeguards = and=20 should be strongly based on the residual risks identified during=20 certification.

 

Application:  A system that performs a = clearly=20 defined function for which there are readily identifiable security=20 considerations and needs (e.g., an electronic funds transfer system or = an air=20 traffic control system).

 

Availability:  Available on a timely = basis to=20 meet mission requirements or to avoid substantial losses.

 

Certification: The comprehensive assessment = of=20 technical and non-technical security features and other safeguards = associated=20 with the use and environment of a system to establish whether the system = meets a=20 set of specified security requirements.

 

Certifying Officer (CO):  The = Certifying Officer=20 assumes the role of an independent technical liaison for all = stakeholders=20 involved in the C&A process and is an objective third party, = independent of=20 the system developers.  The Certifying Officer provides a = comprehensive=20 evaluation of the system, including technical and non-technical = controls, to=20 determine if the system is configured with the proper security controls = in=20 place.  

 

Confidentiality:  Protection from = unauthorized=20 disclosure.

 

Configuration Management Plan: A plan that = describes=20 the management controls involved in all changes and updates made to a = system=20 that affects security.  The plan includes all documentation = supporting=20 these changes and updates.  This plan is maintained throughout the = C&A=20 process and updated according to system development lifecycle (SDLC)=20 activities.

 

Contingency Plan:  Preventive measures=20 established to assist an organization in their ability to quickly and = cost=20 effectively recover critical IT resources.

 

Continuity of Support:  Preventative = measures for=20 protecting the IT systems as well as procedures for restoring any system = disruption

 

Designated Accrediting Authority = (DAA):  The=20 Designated Accrediting Authority determines accreditation based on = security=20 risks of the system, business case, and budget.

 

Disaster Recovery Plan:  A plan that = identifies=20 recovery procedures in the event of natural or man-made disasters or=20 catastrophes affecting the availability of the system.  This plan = is tested=20 annually to ensure the continued effectiveness and adequacy of the = plan. =20

 

General Support System:  A collection = of=20 interconnected information resources under the control of a single = authority and=20 security policy, including personnel and physical security, which shares = common=20 functionality. Provides standard information security capabilities, such = as=20 boundary defense, incident detection and response, and key management, = and also=20 delivers common applications, such as office automation and electronic = mail.

 

Information Sensitivity:  The formal = process of=20 identifying each system in terms of its confidentiality, integrity, and=20 availability.

 

Information System: An information = system is a=20 discrete set of information resources organized for the collection, = processing,=20 maintenance, use, sharing, dissemination, or disposition of information. = (USC=20 T44;C35;S3502)

 

Integrity:  Protection from = unauthorized,=20 unanticipated, or unintentional modification.

 

Privacy Impact Assessment (PIA):  A = tool used to=20 evaluate the impact that information systems have on an = individual.  The=20 PIA process is designed to guide agency system developers and operators = in=20 assessing privacy through the early stages of development.

 

Residual Risk: The portion of risk that = remains after=20 security measures have been applied.

 

Risk Assessment:  The process of = analyzing=20 threats to and vulnerabilities of an information system to determine the = risks=20 (potential for losses), and using an analysis as a basis for identifying = appropriate and cost-effective measures.

 

Security Test and Evaluation: An evaluation = of all=20 hardware, software, and physical security features that are part of a = system.=20 This process involves testing these features to determine what threats = and=20 vulnerabilities exist for the system.  The findings are documented, = and=20 recommendations are made that may be included in the risk = assessment.

 

Significant Change:  A significant = change alters=20 the mission, operating environment, or basic vulnerabilities of the=20 systems.  Examples of significant change include: increase/decrease = in=20 hardware, application programs, external users, hardware upgrades, = additions of=20 telecommunications capability, dial-in lines, changes to the program = logic of=20 application systems, relocation of the system to a new physical = environment or=20 new organization.  Changes determined by the CCB to be significant = will=20 require re-accreditation.  Changes that impact Privacy Act Data = will=20 require re-accreditation.  Changes in protection requirements such = as the=20 sensitivity or classification level of the data being processed, = increase in the=20 mission criticality of the system or changes in the federal or USDA = policies are=20 also considered significant change.  A violation or incident that = calls=20 into question the adequacy of the system security controls is considered = a=20 significant change.  In addition, findings from any security review = that=20 identifies unprotected risk are considered a significant = change.  =20 These could include the system IT security review, physical or = information=20 security inspection, internal control reviews, Office of the Inspector = General=20 (OIG) or General Accounting Office audits.

 

System Development Life Cycle (SDLC): A = structured=20 approach for systems development from planning and support to disposal = of the=20 system.  A proven series of steps and tasks utilized to build and = maintain=20 quality systems faster, at lower costs, and with less risk.

 

System of Records (SOR) Notice:  A = system of=20 records is defined as a group of records under the control of any agency = from=20 which information is retrieved by the name of the individual or by some=20 identifying number, symbol, or other identifying particular assigned to = the=20 individual.

 

System Security Plan: A set of requirements = that are=20 used to delegate how system security will be managed.  This plan = includes=20 system identification, management controls, operational controls, and = technical=20 controls.  The system security plan outlines responsibilities for = all=20 system users and describes the rules of behavior for those = users.

TABLE=20 A-2: ACRONYMS

ACIO-CS

Associate Chief = Information=20 Officer for Cyber Security

C&A

Certification and=20 Accreditation

CCB

Configuration = Control=20 Board

CIO

Chief Information=20 Officer

CO

Certifying = Officer

CPIC

Capital Planning = Investment=20 Control

DAA

Designated = Approving=20 Authority

FIPS

Federal = Information Processing=20 Standards

FISMA

Federal = Information Security=20 Management Act

IATO

Interim Approval = to=20 Operate

ISA

ISSO

Interconnection = Security=20 Agreement

Information = Systems Security=20 Officer

IT

Information=20 Technology

MOA

Memorandum of=20 Agreement

MOU

Memorandum of=20 Understanding

NIACAP

National = Information Assurance=20 Certification and Accreditation Process

NIST

National Institute = of=20 Standards and Technology

NSTISSI

National Security=20 Telecommunications and Information Systems Security

OCIO

Office of the = Chief=20 Information Officer

OIG

Office of = Inspector=20 General

OMB

Office of = Management and=20 Budget

PIA

PUB

Privacy Impact = Assessment

Publication

SCCM

Security Control = Compliance=20 Matrix

SCL

Security = Certification=20 Level

SDLC

System Development = Life=20 Cycle

SER

Security = Evaluation=20 Report

SFUG

Security Features = Users=92=20 Guide

SOR

SP

System of = Records

Special = Publication

SSP

System Security = Plan

ST&E

Security Test and=20 Evaluation

TFM

Trusted Facility=20 Manual

USDA

United States = Department of=20 Agriculture

TABLE A-3:=20 REFERENCES

 

Computer=20 Fraud and Abuse Act

As amended 1994 and = 1996, U.S.C.=20 Section 1001 and 1030 Amended Title 18 Crimes and Criminal = Procedure.

 

FIPS=20 102           &nbs= p;       =20 National Institute of Standards and Technology (NIST), Federal = Information=20 Processing Standards (FIPS), Guidelines for Computer Security = Certification and=20 Accreditation, September 1983

 

FIPS=20 191           &nbs= p;       =20 National Institute of Standards and Technology (NIST), Federal = Information=20 Processing Standards (FIPS), Guideline for the Analysis of Local Area = Network=20 Security November 1994

 

FIPS=20 199           &nbs= p;       =20 National Institute of Standards and Technology (NIST), Federal = Information=20 Processing Standards (FIPS), Security Categorization of Federal = Information=20 Systems (Draft), May 2003

 

FISMA       &= nbsp;           &n= bsp;  =20 (P.L. 107-307), Federal Information Security Management Act (FISMA) = January=20 2003.

 

NIST SP=20 800-18         National = Institute of=20 Standards and Technology (NIST), Guide for Developing Security Plans for = Information Technology Systems, December 1998

 

NIST SP=20 800-26         National = Institute of=20 Standards and Technology (NIST), Security Self Assessment Guide for IT = Systems,=20 November 2001

 

NIST SP=20 800-30         National = Institute of=20 Standards and Technology (NIST), Risk Management Guide for IT Systems, = January=20 2002

NIST SP=20 800-34         National = Institute of=20 Standards and Technology (NIST), Contingency Planning Guide for = Information=20 Technology Systems, Currently under development

NIST SP=20 800-47         National = Institute of=20 Standards and Technology (NIST), Security Guide for Interconnecting = Information=20 Technology Systems, September 2002

NSTISSI=20 No. 1000     National Security = Telecommunications and=20 Information System Security Instruction (NSTISSI) No. 1000, National = Information=20 Assurance Certification and Accreditation Process (NIACAP), April = 2000.

 

OMB=20 A-123           &n= bsp;  =20 Office of Management and Budget (OMB) Management of Federal = Information=20 Resources Circular A-123 (Management Accountability and Control), 21 = June 1995=20

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =  =20

 

 

 

OMB=20 A-130           &n= bsp;  =20 Office of Management and Budget (OMB) Management of Federal = Information=20 Resources Circular A-130, Appendix III, 28 November 2000

 

Privacy=20 Act           &nbs= p;   =20 (http://www.usdoj.gov/04foia/privstat.htm)

TABLE A-4:=20 DOCUMENTATION

To fully address system security throughout the = system=20 development life cycle, various documents should be created and = maintained=20 throughout the life of the system.  These documents and a brief = description=20 of their contents are listed below, along with resources that provide=20 information on how to develop each document.

 

Document

Description

References

Agency Self=20 Assessment

The agency Self Assessment should be = completed in=20 accordance with NIST guidance to ensure that system security = controls are=20 maintained to protect system assets and information.

NIST SP 800-26

System=20 Security Plan

 

 

 

The SSP should contain a description of the = security=20 controls required for the system and how those controls are = implemented as=20 part of the system=92s security posture.

 

NIST SP 800-18

DM 3565-001

Security=20 Test and Evaluation Plan

The ST&E Plan should contain procedures = and/or=20 checklists for validating that each required security control is=20 implemented. 

NIST SP=20 800-26

Security=20 Test and Evaluation Report

The ST&E Report contains results from = functional=20 and security testing conducted on the system as required by the = security=20 categorization.

NIST SP=20 800-26

Risk=20 Assessment Report

The Risk Assessment report should contain the = findings=20 from the ST&E Report as well as an evaluation of the risk that = each=20 finding poses to the system.  The residual risk to the entire = system=20 should be determined.

NIST SP=20 800-30

DM=20 3540-001

Contingency=20 and Disaster Recovery Plans

Contingency plans and disaster recovery plans = contain=20 all procedures that will be taken in the event of an incident that = shuts=20 down the system or a large emergency that destroys the system=20 entirely.  These procedures should provide for system and = data=20 restoration in a certain amount of time based on system=20 criticality.

NIST SP=20 800-34

DM=20 3570-001

Trusted=20 Facility Manual (TFM)

The TFM should = contain=20 procedures for system administrators that explain how to operate = the=20 system or application in the most secure manner.   = Emergency=20 backup and system shutdown procedures should be included in the=20 TFM.

NCSC-TG-016

NCSC-TG-015=20

CS-032=20 Guidance

Security=20 Features User=92s Guide (SFUG)

The SFUG should be written for system and = application=20 users and should clearly explain the security procedures and = precautions=20 that users are expected to follow, i.e., procedures for = maintaining=20 password secrecy, etc.

NCSC-TG-026

CS-033=20 Guidance

Standard=20 Operating Procedures

These procedures should include the = day-to-day=20 processes for running the system or application.  These can = be=20 incorporated into the TFM or SFUG or can be standalone = documents.

N/A

Configuration Management Plan

The CM plan should address configuration = management=20 through the operations and maintenance phase of the system life=20 cycle.  The Plan should contain procedures for maintaining=20 configuration control over system components, software, and=20 documentation.

EIA-649

DM=20 3520-001

User=20 Manuals

Manuals providing instructions for users on = how to=20 operate the system.  May be combined with the SFUG.

N/A

Vendor-Supplied Hardware Manuals and=20 Documentation

Any hardware user manuals, system = administrator=20 manuals, or other hardware documentation provided by the = vendor.

N/A

Vendor-Supplied Software Manuals and=20 Documentation

Any software user manuals, system = administrator=20 manuals, or other software documentation provided by the = vendor.

N/A

Accreditation Statement

The accreditation letter signed by the DAA, = along with=20 any other supporting documentation submitted in support of the=20 certification package.

N/A

Waiver=20 Documentation

Any = system/security waiver or policy exception request that has bee = approved=20 and in force. Includes and approval documentation and any fix = POA&M=20 information

N/A

Interconnectivity

Security=20 Agreements

Agreements between agencies or departments = with=20 interconnecting information systems.  If this system will be=20 connected to other IT systems, the business owner must discuss the = requirements for connectivity with the other system=92s business = owner and=20 work to identify the security requirements for this = connection.  The=20 ISA is started during the Initiation Phase of the SDLC, is refined = during=20 the Acquisition/Development Phase but the ISA may not be completed = until=20 the actual system Implementation Phase.  An ISA will be done = for each=20 system that will be connected to the new system.

 

NIST PUB 800-47

DM 3540-001

DM 3575-001

Application=20 or System Design Documentation

Any design documentation, system = specifications, or=20 software requirements specifications as required by the = USDA.

N/A

Privacy=20 Impact Assessment

A Privacy Impact Assessment must be performed = to ensure=20 the security of the data.

If required, a Systems of Record Notice must = also be=20 completed.

Privacy Act

DM=20 3515-002

TABLE A-5:=20 USDA CHECKLISTS

 

The USDA has developed information security = checklists for=20 the following operating systems and software applications:

 

=A7   =
UNIX
=A7   =
Mainframe
=A7   =
Windows NT (server and desktop)
=A7   =
Telecommunications
=A7   =
IBM AS 400
=A7   =
Web Farm
=A7   =
Personal Electronic Devices
=A7   =
Novell Networks
=A7   =
Windows XP
=A7   =
Telework & Remote Access
=A7   =
Windows 2000
=A7   =
Portable Laptops & Desktop =
Computers

 

 

 

TABLE A-6:=20 SECURITY EVALUATION REPORT

 

TITLE [Use only = CAPITOL letters]=20 (ACRONYM)

SECURITY EVALUATION=20 REPORT 
 

Subject: Conditional Certification of the TITLE = (ACRONYM). 

Purpose: In compliance with P.L. 100-235, January 8, 1998 = =93Computer=20 Security Act of 1987=94 and in accordance with FIPS PUB 102, = =93Guideline for=20 Computer Security Certification and Accreditation=94, this security = evaluation=20 report has been performed to satisfy the OMB Circular A-130 requirements = to=20 periodically certify and accredit systems every three years. 

Introduction: ACRONYM provides =85 PURPOSE/FUNTION 

System Architecture: ACRONYM operates in ARCHITECTURAL=20 DESCRIPTION=85 

(List ONLY the software components tested.) 

Documentation: 

A ACRONYM Risk Assessment dated DATE, and related documents = were=20 submitted.  

The ACRONYM Security Test and Evaluation Plan dated DATE was = submitted=20 with the certification documentation. The security test and evaluation = was=20 conducted at FACILITY LOCATION on DATE. A ACRONYM Security Test and=20 Evaluation Report was submitted DATE. Response to the security = findings=20 listed in the ACRONYM Security Test and Evaluation Report was = received on=20 the following date: DATE.  

[If there are multiple responses list the date of each = response.] 

Major Findings: This section is divided into three parts:=20 clarifications, safeguards, and vulnerabilities. 

Clarifications: None 

 

Safeguards: ACRONYM relies on =85DESCRIPTION OF SECURITY = SAFEGUARDS IN=20 THE SYSTEM=85 

Vulnerabilities: 

The following vulnerabilities were identified during certification=20 activities:

The RISK LEVEL shall be indicated for each finding as = follows: 

 

Conditions of Certification: Any = conditions of this certification are listed below and are identified as = either=20 restrictions or recommended corrective actions. 

 

Restrictions: = [Conditions]. 

 

Recommended Corrective Actions: = The=20 following actions are recommended for implementation to further reduce = the risk=20 associated with ACRONYM: 

[The RISK LEVEL is NOT included in this = section.]

 

Mandatory Concurrence: The ACIO-CS has = performed an=20 in-depth IV&V and has found the following :  Any = conditions for=20 accreditation,  correction actions etc. will be detailed = here.  If the=20 certification package, in the judgment of the ACIO-CS, is not adequate = for=20 accreditation, the reasons will be detailed here.

TABLE A-7: BASE LEVEL DOCUMENT EVALUATION=20 CRITERIA

 

Introduction

 

This document contains Certification and = Accreditation=20 (C&A) Base Level Document Evaluation Criteria checklists that are = intended=20 to provide standardized criteria for developing and evaluating C&A=20 documentation during the C&A process for Major Applications (MAs) = and=20 General Support Systems (GSS).   The organization responsible = for=20 developing the C&A documentation should use the checklists to assist = them=20 while developing the documents and to ensure the documents are ready for = evaluation purposes by the Security Test and Evaluation (ST&E) team = to=20 support certification of the respective system.  The ST&E team = should=20 use the criteria checklists during their evaluation of the system=92s = security in=20 order to determine whether the existing documents possess the critical = elements=20 necessary to meet Federal and Department-level security requirements for = certification and accreditation.

 

With the exception of the security plan checklists, = which are=20 different for agency level security plans, GSS, and MAs, all the = checklists=20 should be completed for each certification and accreditation = effort.  The=20 evaluator should select the appropriate security plan checklist(s) for = the=20 system depending on whether the system undergoing evaluation is a GSS or = an=20 MA.

 

Format

 

Each checklist identifies the critical requirements = specific=20 to each document and provides columns where the evaluator marks whether = or not=20 the requirement is fulfilled and annotates any specific comments next to = the=20 requirement.  Directly after the requirements checklist is a = section for=20 the evaluator to add overall comments about the state of the document = and=20 whether or not it meets the necessary requirements for=20 certification.    There is also a section for evaluator=20 recommendations =96 if the evaluator does not feel that the document = meets enough=20 of the requirements for certification, he or she can list specific=20 recommendations for the agency to implement in order to improve the=20 document.

 

By signing the evaluation checklist, the evaluator = is=20 attesting to the fact that the evaluation is complete and correct, to = the best=20 of their knowledge, and that the document adequately describes the = critical=20 elements for the respective document.  If the evaluator feels that = the=20 agency needs to revise the document in order to meet the necessary = standard for=20 certification, they should state this explicitly in the Evaluator = Comments and=20 Evaluator Recommendations sections.  Once the necessary changes = have been=20 made, the document should be re-evaluated using a new checklist for the = revised=20 document.  The final completed checklists should be submitted as = part of=20 the ST&E report, which is reviewed by the Certifying Officer as part = of the=20 certification package and process.

 

Scoring

 

There is no set scoring method.  Whether or = not a=20 particular document has met enough of the criteria in order to be = adequate for=20 the purposes of system certification is the judgment of the = evaluator.  The=20 evaluator should explain briefly in the Evaluator Comments section why = he or she=20 feels that the document meets the requirements for certification, = particularly=20 if there are specific requirements that have not been met.

 

System Identification=20 ___________________        = Configuration=20 Management Plan

 

Requirement*

Yes

No

Comments

Is there a CM Plan for the GSS/MA?

 

 

 

Does the Plan identify a Configuration = Management=20 Specialist (CMS)?

 

 

 

Does the Plan identify a Configuration = Management=20 Authority (CMA)?

 

 

 

Does the Plan identify a Configuration = Control=20 Authority (CCA)?

 

 

 

Does the Plan Identify a Configuration = Control Board=20 (CCB) for the GSS/MA?

 

 

 

Does the Plan contain an approval = signature?

 

 

 

Is there a CCB charter for the = GSS/MA?

 

 

 

Is there an ISSO or ISSPM assigned to the = CCB?

 

 

 

Is the CCB charter signed by the CMA and = CCA?

 

 

 

 

Evaluator=20 Comments:

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

 

 

System=20 Identification ___________________  Security Features Users Guide=20 (SFUG)

 

Requirement*

Yes

No

Comment

Is the SFUG marked =93For Official Use = Only=94?

 

 

 

Is the SFUG accessible only on an Intranet = site?

 

 

 

Does the SFUG contain required technical = security=20 features information?

 

 

 

Does the SFUG contain required Security = Policy=20 Information?

 

 

 

Does the SFUG contain required = security-related command=20 information?

 

 

 

 

Evaluator=20 Comments:

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

 

 

System=20 Identification=20 ___________________         =        =20 Trusted Facility Manual (TFM)

         &= nbsp; =20

Requirement*

Yes

No

Comment

Does the TFM provide or reference the = required=20 information necessary to configure and install a specific secure=20 system?

 

 

 

Does the TFM present or reference cautions = about=20 functions and privileges that should be controlled when running a = secure=20 facility?

 

 

 

Does the TFM provide or reference  = procedures for=20 examining and maintaining the audit files?

 

 

 

Does the TFM provide or reference detailed = audit record=20 structure for each type of audit event?

 

 

 

Does the TFM provide or reference the = administrator=20 functions related to security, to include changing the security=20 characteristics of a user?

 

 

 

Does the TFM provide guidelines on the = consistent and=20 effective use of the protection features of the system?

 

 

 

Does the TFM explain how the protection = features of the=20 system interact?

 

 

 

Does the TFM provide guidelines on facility = procedures,=20 warnings, and privileges that need to be controlled in order to = operate=20 the facility in a secure manner?

 

 

 

Does the TFM include or reference procedures = to ensure=20 that the system is initially started in a secure state and = procedures to=20 resume secure system operation after any lapse in system = operation?

 

 

 

Is an accurate and up-to-date copy of the TFM = retained=20 at each site=92s off-site back-up storage facility in order to = support=20 disaster recovery operations?

 

 

 

Is the TFM marked =93For Official Use = Only=94?

 

 

 

         &= nbsp;           &n= bsp; =20

Evaluator=20 Comments:

 

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

 

 

 System=20 Identification=20 ___________________         =             &= nbsp;    =20 Risk Assessment Report

 

A.  = System=20 Introduction and Characterization

Requirement*

Yes

No

Comment

Is the purpose of the assessment = described?

 

 

 

Has the scope of the system, in terms of both = system=20 boundaries and areas to be assessed, been explained?

 

 

 

Is the system=92s business or technical = requirements=20 explained?

 

 

 

Is the information infrastructure explained? =

 

 

 

Has the IT assets to be assessed been = identified?=20

 

 

 

Has the data flow been explained?

 

 

 

Has the interface to other systems been = explained and=20 identified?

 

 

 

Has the software and hardware components been = identified?

 

 

 

Has the system security architecture been = explained and=20 identified?

 

 

 

Has the system security architecture, which = depicts the=20 operating system, been explained and identified? 

 

 

 

Has the system security architecture, which = examines=20 the facilities where the system is contained, been explained and=20 identified?

 

 

 

Has the system security architecture, which = explains=20 the information storage requirements been explained and = identified?=20

 

 

 

Has the applicable system security policies = governing=20 the system (agency policies, federal requirements, laws, etc.) = been=20 explained and identified?

 

 

 

Has value of the information been = determined?

 

 

 

 

B. =20 Findings

Requirement

Yes

No

Comment

Have the system security vulnerabilities = been=20 explained and identified?

 

 

 

Have the potential threats and impacts = been=20 explained and identified?

 

 

 

Has the threat analysis been explained?=20

 

 

 

Has the impact analysis been = explained?

 

 

 

 

C.  Analysis = and=20 Recommendations

Requirement

Yes

No

Comment

Have the findings been analyzed in terms = of a=20 Business Risk?

 

 

 

Have the recommendations for mitigating = each risk=20 been identified and explained?

 

 

 

Have the recommendations for mitigating = each=20 residual risk (if any) been identified and explained?

 

 

 

 

 

Evaluator=20 Comments:

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

 

 

System=20 Identification=20 ___________________         =     =20 Overall Agency Security Plans

 

Requirement*

Yes

No

Comment

Does the plan address the appropriate = management of IT=20 security within the USDA agency/mission area?

 

 

 

Does the plan address the current security = management=20 philosophy and specific functions of the ISSPM(s)?

 

 

 

Does it include audits of system patches, = personnel=20 clearances, use of unauthorized or illegal software, incident = response and=20 reporting, change management procedures, security controls or as = defined=20 in DR 3140-1?

 

 

 

Does the security plan, discuss in detail how = your=20 agency uses management controls to protect information assets, = ensure that=20 systems are heading towards certification and accreditation, = conducting=20 periodic reviews of information security procedures to ensure they = work as=20 intended and providing support for the role of the ISSPM in the=20 organization?

 

 

 

Does the security plan, discuss in specific = detail the=20 implementation of security policy and program activities?  = This=20 portion of the plan should identify the assessments on which the=20 determinations were made and policies created to meet the = requirements of=20 CIA.

 

 

 

Does the plan, identify, describe or clarify = the policy=20 that establishes and maintains the ISSP within the USDA agency, = mission=20 area or program? 

 

 

 

Does it include the specific internal ISSP = policies=20 issued during the past year and those being planned for the = upcoming=20 year?  These can be policies, notices, or directives and = should be=20 noted by subject and date issued.

 

 

 

Does the plan, identify and discuss long-term = strategies to incorporate Information Systems Security (ISS) into = the=20 overall agency mission and into next generation of agency IT = systems? The long-term = Information Systems=20 Security Program Strategy is based on the organizations: Policy=20 Integration; Technology needs; Resource base and budget = requirements;=20 Security accomplishments/setbacks of the previous year; New = initiatives=20 (Telecommuting, PKI, VPN, E-Commerce, etc.,); Security goals and=20 challenges for the upcoming year; conformance to departmental = architecture=20 (infrastructure/security)? 

 

 

 

Does the security plan provide the foundation = for=20 linking security planning and activities from the Capital Planning = and=20 Investment Control (CPIC) and Government Information Security = Reform Act=20 (GISRA) now called the Federal Information Security Management Act = (FISMA)?

 

 

 

Has the plan developed Performance Measures = for their=20 security program?

 

 

 

Does it describe in detail the Overall = Performance=20 Standards for the agency Security Program and how they are=20 measured?

 

 

 

Does the plan discuss the agency's security = program=20 risk assessment methodology? 

 

 

 

Does it include a Risk Assessment Report,=20 vulnerabilities found and mitigation strategies?

 

 

 

Does the plan discuss your agency efforts to = implement=20 privacy protection to include privacy training and number of = Privacy=20 Impact Assessments conducted?

 

 

 

Does the plan discuss the implementation of=20 configuration management procedures and techniques within your=20 agency?

 

 

 

Does the plan discuss in detail your = agency=92s=20 compliance program?

 

 

 

Does the plan discuss the upcoming agency = specific=20 plans for implementing an internal Security Awareness and Training = Program=20 and specialized training? This program should include details on = planned=20 annual security seminars, use of electronic media, such as e-mail = or=20 bulletin boards to enhance security awareness, and plans for = briefing new=20 employees/contractors on security awareness.

 

 

 

If the agency does not have an active = security training=20 and awareness program, does it provide specific details, including = time=20 frames, on the plans to meet this requirement?

 

 

 

Does the plan, include a statement as to = whether all=20 individuals working for the agency (federal employees as well as=20 contractors) have received the appropriate background screening,=20 suitability determination, and security clearance (if required)=20 appropriate for the position to which they are assigned?

 

 

 

Does the plan discuss the ISS program's = incident=20 handling strategy and the internal procedures developed to support = DM=20 3500-1, Chapter 1, USDA Computer Incident Response = Procedures?

 

 

 

Does the plan discuss the Program contingency = planning=20 process to include: (1) identifying the mission, business, or = critical=20 functions; (2) identifying the resources that support the critical = functions; (3) selecting contingency planning strategies; (4) = anticipating=20 potential contingencies or disasters; (5) analyzing = vulnerabilities and=20 risks, and  (6) physical and environmental security. =20 Information should also be included on Business Resumption Plan = and=20 Contingency of Operations Plan (COOP)?

 

 

 

 

 

Evaluator=20 Comments:

 

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

 

 

 

System Identification=20 ___________________         = General=20 Support System Security Plans

 

Requirement*

Yes

No

Comment

Does the plan describe the function or purpose = of the=20 application and the information processed?

 

 

 

Does the plan describe the processing flow of = the=20 application from system input to system output?

 

 

 

Does the plan provide a general description = of the=20 technical system? 

 

 

 

Does it include any environmental or = technical factors=20 that raise special security concerns (dial-up lines, open network, = etc.)?

 

 

 

Does the plan describe the primary computing=20 platform(s) used and a description of the principal system = components,=20 including hardware, software, and communications = resources?

 

 

 

Does the plan list interconnected systems and = system=20 identifiers?

 

 

 

Does the plan require that written = authorization (MOUs,=20 MOAs) be obtained prior to connection with other systems and/or = sharing=20 sensitive data/information?

 

 

 

Does the plan describe, in general terms, the = information handled by the system and the need for protective=20 measures?

 

 

 

Does the plan describe the risk assessment = methodology=20 used to identify the threats and vulnerabilities of the system? =

 

 

 

Does the plan discuss performance measures = should be=20 established around criteria such as Level of System Compromises,=20 Timeliness of User Administration and Overall System Availability = or other=20 measure that reflect security?

 

 

 

Does the plan list any independent security = reviews=20 conducted on the system in the last three years?

 

 

 

Does it include information about the type of = security=20 evaluation performed, who performed the review, the purpose of the = review,=20 the findings, and the actions taken as a result?

 

 

 

Does the plan include a set of rules of = behavior and=20 does it contain a signature page to acknowledge receipt?

 

 

 

Do the rules of behavior clearly delineate=20 responsibilities and expected behavior of all individuals with = access to=20 the system, state the consequences of inconsistent behavior or=20 non-compliance and include appropriate limits on interconnections = to other=20 systems?

 

 

 

Does the plan state which phase(s) of the = life cycle=20 the system, or parts of the system are in? 

 

 

 

Does the plan provide the date of = authorization, name,=20 and title of management official authorizing processing in the=20 system? 

 

 

 

If not authorized, does it provide the name = and title=20 of manager requesting approval to operate and date of = request?

 

 

 

Does the plan state if individuals have = received=20 background screenings appropriate for the position to which they = are=20 assigned?

 

 

 

Does the plan address the physical security = measures=20 provided for the system and the facility in which it is housed in=20 accordance with the Cyber Security Manual, Chapter 2?

 

 

 

Does the plan address physical access, fire = safety,=20 failure of supporting utilities, structural collapse, plumbing = leaks,=20 interception of data, mobile and portable systems?

 

 

 

Does the plan describe the controls used for = the=20 marking, handling, processing, storage, and disposal of input and = output=20 information and media, as well as labeling and distribution = procedures for=20 the information and media (discuss user support, audit trails, = restricting=20 access to output products, external labeling, controlling = storage)?

 

 

 

Does the plan describe the procedures = (contingency=20 plan) that would be followed to ensure the application continues = to be=20 processed if the supporting IT systems were unavailable = (agreements for=20 backup, documented backup procedures, location of stored backups, = tested=20 contingency/disaster recovery plans)?

 

 

 

Does the plan discuss restriction/controls on = those who=20 perform maintenance and repair activities and special procedures = for=20 performance of emergency repair and maintenance?

 

 

 

Does the plan discuss version control that = allows=20 association of system components to the appropriate system = version?

 

 

 

Does the plan discuss procedures for testing = and/or=20 approving system components  (operating system, other system, = utility, applications) prior to promotion to production?

 

 

 

Does the plan discuss change identification, = approval,=20 and documentation procedures?

 

 

 

Does the plan discuss virus detection and = elimination=20 software installed? 

 

 

 

Does it describe any restrictions to prevent = users from=20 accessing the system or applications outside of normal work hours = or on=20 weekends?

 

 

 

Does the plan discuss if intrusion detection = tools=20 installed on the system?

 

 

 

Does the plan discuss if penetration testing = performed=20 on the system? 

 

 

 

Does the plan discuss documentation for a = system=20 includes descriptions of the hardware and software, policies, = standards,=20 procedures, and approvals related to automated information system = security=20 in the application and the support systems(s) on which it is = processed, to=20 include backup and contingency activities, as well as descriptions = of user=20 and operator procedures?

 

 

 

Does the plan describe the awareness program = for the=20 system (posters, booklets, and trinkets)?

 

 

 

Does it describe the type and frequency of=20 application-specific and general support system training provided = to=20 employees and contractor personnel (seminars, workshops, formal = classroom,=20 focus groups, role-based training, and on-the job = training)?

 

 

 

Does the plan discuss if there are procedures = for=20 reporting incidents handled either by system personnel or=20 externally?

 

 

 

Does the plan describe the method of user=20 authentication (password, token, and biometrics)?

 

 

 

Does the plan describe the level of = enforcement of the=20 access control mechanism (network, operating system, and=20 application)?

 

 

 

Does the plan describe how the access control = mechanism=20 supports individual accountability and audit trails (e.g., = passwords are=20 associated with a user identifier that is assigned to a single=20 individual)?

 

 

 

Does the plan describe controls to detect = unauthorized=20 transaction attempts by authorized and/or unauthorized = users? =20

 

 

 

Does the plan discuss the audit trail support = accountability by providing a trace of user actions?

 

 

 

Does the plan discuss audit trail include = sufficient=20 information to establish what events occurred and who (or what) = caused=20 them?  (type of event, when the event occurred, user id = associated=20 with the event, program or command used to initiate the = event.)

 

 

 

 

Evaluator=20 Comments:

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

System=20 Identification=20 ___________________         = Major=20 Application Security Plans

 

Requirement*

Yes

No

Comment

Does the plan describe the function or = purpose of the=20 application and the information processed?

 

 

 

Does the plan describe the processing flow of = the=20 application from system input to system output?

 

 

 

Does the plan provide a general description = of the=20 technical system? 

 

 

 

Does it include any environmental or = technical factors=20 that raise special security concerns (dial-up lines, open network, = etc.)?

 

 

 

Does the plan describe the primary computing=20 platform(s) used and a description of the principal system = components,=20 including hardware, software, and communications = resources?

 

 

 

Does the plan list interconnected systems and = system=20 identifiers?

 

 

 

Does the plan require that written = authorization (MOUs,=20 MOAs) be obtained prior to connection with other systems and/or = sharing=20 sensitive data/information?

 

 

 

Does the plan describe, in general terms, the = information handled by the system and the need for protective=20 measures?

 

 

 

Does the plan describe the risk assessment = methodology=20 used to identify the threats and vulnerabilities of the = system?

 

 

 

If there is no system risk assessment, does = it include=20 a milestone date (month and year) for completion of the = assessment?

 

 

 

Does the plan discuss performance measures = should be=20 established around criteria such as Level of System Compromises,=20 Timeliness of User Administration and Overall System Availability = or other=20 measure that reflect security? 

 

 

 

Does the plan include a set of rules of = behavior and=20 does it contain a signature page to acknowledge receipt?

 

 

 

Do the rules of behavior clearly delineate=20 responsibilities and expected behavior of all individuals with = access to=20 the system, state the consequences of inconsistent behavior or=20 non-compliance and include appropriate limits on interconnections = to other=20 systems?

 

 

 

Does the plan state which phase(s) of the = life cycle=20 the system, or parts of the system are in? 

 

 

 

Does the plan provide the date of = authorization, name,=20 and title of management official authorizing processing in the=20 system? 

 

 

 

If not authorized, is the name and title of = manager=20 requesting approval to operate and date of request, = provided?

 

 

 

Does the plan state if all positions been = reviewed for=20 sensitivity level?

 

 

 

Does the plan state if individuals have = received=20 background screenings appropriate for the position to which they = are=20 assigned?

 

 

 

Does the plan address the physical security = measures=20 provided for the system and the facility in which it is housed in=20 accordance with the Cyber Security Manual, Chapter 2?

 

 

 

Does the plan address physical access, fire = safety,=20 failure of supporting utilities, structural collapse, plumbing = leaks,=20 interception of data, mobile and portable systems?

 

 

 

Does the plan describe the controls used for = the=20 marking, handling, processing, storage, and disposal of input and = output=20 information and media, as well as labeling and distribution = procedures for=20 the information and media (discuss user support, audit trails, = restricting=20 access to output products, external labeling, controlling = storage)?

 

 

 

Does the plan discuss if the application = software=20 developed in-house or under contract?

 

 

 

Does the plan discuss if the government owns = the=20 software? Was it received from another agency?

 

 

 

Does the plan discuss if the application = software a=20 copyrighted commercial off-the-shelf product or = shareware?

 

 

 

Does it describe if it been properly licensed = and=20 enough copies purchased for all systems?

 

 

 

Does the plan discuss virus detection and = elimination=20 software installed?  If so, are there procedures for updating = virus=20 signature files, automatic and/or manual virus scans, and virus=20 eradication and reporting?

 

 

 

Does the plan discuss if intrusion detection = tools=20 installed on the system? 

 

 

 

Does the plan discuss if penetration testing = performed=20 on the system? 

 

 

 

Does the plan discuss documentation for a = system=20 includes descriptions of the hardware and software, policies, = standards,=20 procedures, and approvals related to automated information system = security=20 in the application and the support systems(s) on which it is = processed, to=20 include backup and contingency activities, as well as descriptions = of user=20 and operator procedures?

 

 

 

Does it list the documentation maintained for = the=20 application (vendor documentation of hardware/software, functional = requirements, security plan, general system security plan, = application=20 program manuals, test results documents, standard operating = procedures,=20 emergency procedures, contingency plans, user rules/procedures, = risk=20 assessment, certification/accreditation statements/documents, = verification=20 reviews/site inspections)?

 

 

 

Does the plan describe the awareness program = for the=20 system (posters, booklets, and trinkets)?

 

 

 

Does the plan describe the major = application=92s=20 authentication control mechanisms and the method of user=20 authentication?

 

 

 

Does the plan describe how the access control = mechanism=20 support individual accountability and audit trails (e.g., = passwords are=20 associated with a user ID that is assigned to a single = person)?

 

 

 

Does the plan discuss the controls in place = to=20 authorize or restrict the activities of users and system personnel = within=20 the application? 

 

 

 

Does the plan describe controls to detect = unauthorized=20 transaction attempts by authorized and/or unauthorized users? =

 

 

 

Does the plan discuss if the public accesses = the major=20 application?

 

 

 

Does the plan discuss the audit trail support = accountability by providing a trace of user actions?

 

 

 

Does the plan discuss audit trails designed = and=20 implemented to record appropriate information that can assist in = intrusion=20 detection?

 

 

 

 

Evaluator=20 Comments:

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

 

 

 

System=20 Identification=20 ___________________         =           =20 Privacy Impact Assessment

 

Requirement*

Yes

No

Comment

Has a Privacy Impact = Assessment=20 Form been developed for the system?

 

 

 

Has a Privacy Policy = Analyst been=20 assigned?

 

 

 

Has the system owner = addressed what=20 data is to be used, how the data is to be used, and who will use = the=20 data?

 

 

 

Has the system developer = addressed=20 whether implementation of the owner=92s requirements presents any = threats to=20 privacy?

 

 

 

Have any privacy risks = been=20 identified by the system owner, Privacy Policy Analyst or system=20 developer?

 

 

 

Has the individual been = identified=20 and documented who has access to the data in a = system?

 

 

 

When an individual has = been granted=20 access to a system, has their access been limited, where possible, = to only=20 that data needed to perform their assigned = duties?

 

 

 

Are procedures in place = to detect=20 and deter browsing or unauthorized access, when individuals using = other=20 systems (International, Federal, State, or Local entities) are = granted=20 access to all of the data in that system?

 

 

 

Are data retention = procedures=20 documented?

 

 

 

Are the intended and = potential=20 monitoring capabilities of the system, defined and safeguarded to = ensure=20 the privacy of customers and prevent unnecessary = intrusion?

 

 

 

 

Evaluator=20 Comments:

 

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

 

 

System Identification _____________________   = Disaster=20 Recovery and Business Resumption Planning

 

Requirement*

Yes

No

Comments

Is there a Disaster Recovery Plan for the = GSS/MA?=20

 

 

 

Does the Plan describe the system=92s Concept = of=20 Operations?

 

 

 

Does the Plan provide a general description = of the=20 system architecture and functionality and how this system supports = the=20 business process

 

 

 

Does the Plan identify the roles and = responsibilities=20 of the key players, such as the management team, damage assessment = team,=20 and system executive?

 

 

 

Does the Plan outline the contingency = planning=20 organization?

 

 

 

Does the Plan = document the=20 system=92s operational status and completed contingency = actions?

 

 

 

Does the Plan document the Notification and = Activation,=20 and Recovery Phases for contingencies?

 

 

 

Does the Notification and Activation Phase = describe the=20 scope and magnitude of disruptive events that would necessitate = plan=20 activation?

 

 

 

Does the Recovery Phase include detailed, = sequential=20 steps to take to shut down the system at the damaged site and = establish=20 temporary operations at another location or using alternate system = components?

 

 

 

Does the Recovery Phase include a description = of the=20 testing that should be done before bringing the alternate system=20 online?

 

 

 

Does the Reconstitution section focus on = activities=20 required to restore the system and its operating environment to = normal=20 conditions?

 

 

 

Does the Reconstitution section include a = description=20 of the operational testing of the permanent system before = operations are=20 returned to it?

 

 

 

Does the Plan discuss the need and = requirements for=20 concurrent processing?

 

 

 

Does the Plan define the criteria for = deactivation of=20 the Plan?

 

 

 

Does the Plan address the requirement for = training on=20 and periodic testing of the Plan?

 

 

 

Does the Plan contain populated Appendices A = through I=20 as described in the USDA OCIO IT Disaster Recovery and Business = Resumption=20 Planning Certification and Accreditation Checklist?

 

 

 

 

Evaluator=20 Comments:

 

 

 

 

 

Evaluator = Recommendations:

 

 

 

 

 

Evaluator Signature:

 

 

Date:

 

 

TABLE = A-8:

ACCREDITATION LETTER SAMPLES

 

Security Accreditation = Decision=20 Letter (Authorization to Operate)

 

From: Authorizing = Official=20             &= nbsp;           &n= bsp;           &nb= sp;   =20 Date:

 

Thru: Senior Agency = Information=20 Security Officer

 

To: Information = System Owner=20

 

Subject: Security = Accreditation=20 Decision for [INFORMATION = SYSTEM]

 

 

After reviewing the = results of=20 the security certification of the [INFORMATION = SYSTEM] and its constituent system-level components = (if=20 applicable) located at [LOCATION] and the supporting evidence provided in the = associated=20 security accreditation package (including the current system security = plan, the=20 security assessment report, and the plan of action and milestones), I = have=20 determined that the risk to agency operations, agency assets, or = individuals=20 resulting from the operation of the information system is acceptable.=20 Accordingly, I am issuing an authorization to operate the = information=20 system in its existing operating environment. The information system is=20 accredited without any significant restrictions or limitations. This = security=20 accreditation is my formal declaration that adequate security controls = have been=20 implemented in the information system and that a satisfactory level of = security=20 is present in the system. The security accreditation of the information = system=20 will remain in effect as long as: (i) the required security status = reports for=20 the system are submitted to this office every [TIME PERIOD]; (ii) the vulnerabilities reported during = the=20 continuous monitoring process do not result in additional agency-level = risk=20 which is deemed unacceptable; and (iii) the system has not exceeded the = maximum=20 allowable time period between security accreditations in accordance with = federal=20 or agency policy. A copy of this letter with all supporting security=20 certification and accreditation documentation should be retained in = accordance=20 with the agency=92s record retention schedule.

 

Signature =

 

Title

 

Enclosures =

 

 

Security=20 Accreditation Decision Letter (Interim Authorization to = Operate)

 

 

From: Authorizing = Official=20             &= nbsp;           &n= bsp;           &nb= sp;   =20 Date:

 

Thru: Senior Agency = Information=20 Security Officer

 

To: Information = System Owner=20 Subject: Security Accreditation Decision for [INFORMATION = SYSTEM]

 

 

After reviewing the = results of=20 the security certification of the [INFORMATION = SYSTEM] and its constituent system-level components = (if=20 applicable) located at [LOCATION] and the supporting evidence provided in the = associated=20 security accreditation package (including the current system security = plan, the=20 security assessment report, and the plan of action and milestones), I = have=20 determined that the risk to agency operations, agency assets, or = individuals=20 resulting from the operation of the information system is not = acceptable.=20 However, I have also determined that there is an overarching need to = place the=20 information system into operation or continue its operation due to = mission=20 necessity. Accordingly, I am issuing an interim authorization to = operate=20 the information system in its existing operating environment. An = interim=20 authorization is a limited authorization to operate the information = system under=20 specific terms and conditions and acknowledges greater agency-level risk = for a=20 limited period of time. The information system is not considered=20 accredited during the period of limited authorization to operate. The = terms and=20 conditions of this limited authorization are described in Attachment A. = A=20 process must be established immediately to monitor the effectiveness of = the=20 security controls in the information system during the period of limited = authorization. Monitoring activities should focus on the specific areas = of=20 concern identified during the security certification. Significant = changes in the=20 security state of the information system during the period of limited=20 authorization should be reported immediately. This interim authorization = to=20 operate the information system is valid for [TIME PERIOD]. The limited authorization will remain in = effect=20 during that time period as long as: (i) the required security status = reports for=20 the system are submitted to this office every [TIME PERIOD]; (ii) the vulnerabilities reported during = the=20 continuous monitoring process do not result in additional agency-level = risk=20 which is deemed unacceptable; and (iii) continued progress is being made = in=20 reducing or eliminating vulnerabilities in the information system in = accordance=20 with the plan of action and milestones. At the end of the period of = limited=20 authorization, the information system must be either authorized to = operate or=20 the authorization for further operation will be denied. Renewals or = extensions=20 to this interim authorization to operate will be granted only under the = most=20 extenuating of circumstances. This office will monitor the plan of = action and=20 milestones submitted with the accreditation package during the period of = limited=20 authorization. A copy of this letter with all supporting security = certification=20 and accreditation documentation should be retained in accordance with = the=20 agency=92s record retention schedule.

 

Signature =

 

Title

 

Enclosures

 

TABLE A-9, INTERIM = AUTHORITY TO=20 OPERATE (IATO) FORM

 

IT=20 Certification and Accreditation IATO Request Submission

 

 

Name of = System:

 

Risk Level of=20 System:

 

 

Name of=20 DAA:           &nb= sp;           &nbs= p;         =20 Email:           &= nbsp;           &n= bsp;           &nb= sp;=20 Telephone Number:

 

 

Name of=20 CO:           &nbs= p;            = ;            = =20 Email:           &= nbsp;           &n= bsp;           &nb= sp;=20 Telephone Number:

 

 

Name of C&A=20 POC:           &nb= sp;           &nbs= p;           =20 Email:           &= nbsp;           &n= bsp;           &nb= sp;=20 Telephone Number:

 

__________________________________________________________________= ____

 

1.     =20 Are all of the Phase 1, = Certification and Accreditation Activities, complete?

 

 

 

2.     =20 Provide an explanation = of the=20 exception requested. Identify each vulnerability.

 

 

 

3.     =20 Identify the = mitigation=20 strategy, such as system replacement, for mitigating risks to the = information=20 residing on the system, identified as an =93Action Item=94.

 

 

 

 

4.     =20 Attach the formal = Business=20 Case necessitating the service

 

 

 

 

5.     =20 Identify the resource = estimated=20 funded/unfunded/reallocation

 

 

 

 

6.     =20 Provide the scheduled = completion=20 date

 

 

 

 

7.     =20 Attach Plan of Action = &=20 Milestones (POA&M) with interim completion dates

 

 

 

8.     =20 Provide current = status

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  =20          Appendix=20 B

USDA PRIVACY IMPACT ASSESSMENT=20 FORM

 

Project Name:=20 ___________________________

Description of=20 Your Program/Project:=20 _________________________________________________________________________= _________________________________________________________________________= _________________________________________________________________________= _________________________________________________________________________= ____________________________________________________________________

 

DATA IN THE=20 SYSTEM

 

1.   = Generally=20 describe the information to be used in the system.  =

 

 

 

2a.  =20 What are the sources of the information in the system?

 

 

 

2b.  =20 What USDA files and databases are used? What is the source=20 agency?

 

 

 

2c.  =20 What Federal Agencies are providing data for use in the = system?

 

 

 

2d.  =20 What State and Local Agencies are providing data for use in the=20 system?

 

 

 

2e.  =20 From what other third party sources will data be = collected?

 

 

 

2f.  =20 What information will be collected from the customer?

 

 

 

3a.   How=20 will data collected from sources other than the USDA records and = the=20 customer be verified for accuracy?

 

 

 

3b.   How=20 will data be checked for completeness?

 

 

 

 

 
 
 
ACCESS TO THE=20 DATA

 

1.   =20 Who = will have=20 access to the data in the system (Users, Managers, System = Administrators,=20 Developers, Other)?

 

 

 

2.    = How is=20 access to the data by a user determined?  Are criteria, = procedures,=20 controls, and responsibilities regarding access = documented?

 

 

 

3.    = Will users=20 have access to all data on the system or will the user=92s access = be=20 restricted?  Explain.

 

 

 

4.    = What=20 controls are in place to prevent the misuse (e.g. browsing, = unauthorized=20 use) of data by those having access?

 

 

 

5a.   Do=20 other systems share data or have access to data in this = system?  If=20 yes, explain. 

 

 

 

5b.   Who=20 will be responsible for protecting the privacy rights of the = customers and=20 employees affected by the interface.

 

 

 

6a.  =20 Will other agencies share data or have access to data in this = system=20 (International, Federal, State, Local, Other)?

 

 

 

6b.   How=20 will the data be used by the agency?

 

 

 

6c.   Who=20 is responsible for assuring proper use of the data?

 

 

 

 

 

ATTRIBUTES OF THE = DATA

 

1.   Is=20 the use of the data both relevant and necessary to the purpose for = which=20 the system is being designed?

 

 

 

2a.  = Will the=20 system derive new data or create previously unavailable data about = an=20 individual through aggregation from the information = collected?

 

 

 

2b.  = Will the=20 new data be placed in the individual=92s record (customer or=20 employee)?

 

 

 

2c.  = Can the=20 system make determinations about customers or employees that would = not be=20 possible without the new data?

 

 

 

2d.  = How will=20 the new data be verified for relevance and accuracy?

 

 

 

3a.  = If data=20 is being consolidated, what controls are in place to protect the = data from=20 unauthorized access or use?

 

 

 

3b.  = If=20 processes are being consolidated, are the proper controls = remaining in=20 place to protect the data and prevent unauthorized access? =20 Explain.

 

 

 

4a.   How=20 will the data be retrieved?  Can it be retrieved by personal=20 identifier?  If yes, explain.

 

 

 

4b.  = What are=20 the potential effects on the due process rights of = customers:

  • consolidation and=20 linkage of files and systems;=20
  • derivation of=20 data=20
  • accelerated=20 information processing and decision making;=20
  • use of = new=20 technologies.

 

 

 

4c.  = How are=20 the effects to be mitigated?

 

 

 

 

MAINTENANCE OF=20 ADMINISTRATIVE CONTROLS

 

1a.  = Explain=20 how the system and its use will ensure equitable treatment of=20 customers.

 

 

 

2a.  = If the=20 system is operated in more than one site, how will consistent use = of the=20 system and data be maintained in all sites?

 

 

 

2b.  = Explain=20 any possibility of disparate treatment of individuals or=20 groups.

 

 

 

2c.  = What are=20 the retention periods of data in this system?

 

 

 

2d.  = What are=20 the procedures for eliminating the data at the end of the = retention=20 period?  Where are the procedures documented?

 

 

 

2e.  = While the=20 data is retained in the system, what are the requirements for = determining=20 if the data is still sufficiently accurate, relevant, timely, and = complete=20 to ensure fairness in making determinations?

 

 

 

3a.   Is=20 the system using technologies in ways not previously employed by = the=20 agency (e.g. Caller-ID)?

 

 

 

3b.   How=20 does the use of this technology affect customer = privacy?

 

 

 

4a.  =20 Will this system provide the capability to identify, locate, and = monitor=20 individuals?  If yes, explain.

 

 

 

4b.  =20 Will this system provide the capability to identify, locate, and = monitor=20 groups of people?  If yes, explain.

 

 

 

4c.  =20 What controls will be used to prevent unauthorized = monitoring?

 

 

 

5a.  =20 Under which Systems of Record notice (SOR) does the system = operate? =20 Provide number and name. (SORs can be viewed at http://www.access.gpo.gov/)

 

 

 

5b.   If=20 the system is being modified, will the SOR require amendment or=20 revision?  Explain.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Appendix C

System of Records (SOR) Notice=20 Guidance

 

The = Privacy Act=20 requires agencies to publish in the Federal Register a =93notice of the = existence=20 and character of the system of records=94 subject to the Act (5 U.S.C.=20 552(e)(4)).  Specifically, a =93system of records=94 is defined as = a group of=20 any records under the control of any agency from which information is = retrieved=20 by the name of the individual or by some identifying number, symbol, or = other=20 identifying particular assigned to the individual.

 

The = Privacy Act=20 also requires agencies to send reports to Congress and the Office of = Management=20 and Budget (OMB) on the agency=92s intention to establish any new system = of=20 records, and under certain specified circumstances, the agency=92s = intention to=20 alter an existing system of records.

 

The = report on a=20 new or altered systems of records must be prepared and distributed no = later than=20 30 days prior to establishment of a new system of records.  This = 30-day=20 period is established to provide Congress and OMB an opportunity to = review the=20 proposed new or altered system and to provide comments, if = desired.  The=20 30-day period commences on the day the transmittal letter, with = attachments, is=20 signed and dispatched.

 

The = Director,=20 OMB, has the authority to waive the 30-day advance notification period = provided=20 that the transmittal letter specifically requests a waiver and the = Department=20 can demonstrate compelling reasons for not waiting the 30-day = period.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Appendix D

INTERCONNECTION SECURITY=20 AGREEMENT

 

 

Purpose=20 =96 The purpose = of this=20 Interconnection Security Agreement (ISA) is to identify and document to = all=20 signatories satisfaction:

 

=B7        =20 Existing = risks and=20 mitigation strategies for all of the systems being interconnected, = regardless of=20 whether they are General Support Systems (GSS) or Major Applications = (MA). =20 Note: Any automated process that relies on Information Technology = (IT) must=20 be considered either a GSS or a MA.

 

=B7        =20 Any = additional risks=20 and mitigation strategies introduced through the interconnection of = these=20 systems for all participating systems.  The National Institute of = Standards=20 and Technology (NIST) Special Publication  (SP) 800-47, =93Security = Guide for=20 Interconnecting Information Technology Systems=94 states = =93A system interconnection is = defined as the=20 direct connection of two or more IT systems for the purpose of sharing = data and=20 other information resources. The document describes various benefits of=20 interconnecting IT systems, identifies the basic components of an=20 interconnection, identifies methods and levels of interconnectivity, and = discusses potential security risks associated with an=20 interconnection.=94

 

=B7        =20 Documentation of all=20 systems impacted by the interconnection, regardless of their = participation in=20 this agreement.  (In the event a MA or GSS is not a signatory to = this=20 agreement, their role in the interconnection must be documented and a = separate=20 ISA must be prepared.)

 

=B7        =20 Provide = appropriate=20 levels of assurance (appropriate is very subject, might be well to = include=20 specifics) in accordance with NIST SP 800-47 and to the satisfaction of = all=20 signatories that the documented risk and mitigation strategies are = operating as=20 stated and are effective.

 

INTERCONNECTION STATEMENT OF = REQUIREMENTS=20 =96 This = section shall=20 contain:

 

=B7        =20 a clear = description of=20 the systems covered by this agreement,

 

=B7        =20 each systems = intended=20 purpose and target community,

 

=B7        =20 data = sensitivity=20 (information to and from systems is = Sensitive-but-Unclassified=20 unless specified otherwise),

 

=B7        =20 a = description of the=20 interconnection, including a graphic representation of the=20 interconnection,   the purpose of the interconnection and a = clear=20 description of the authorities under which all of the systems = operate. =20 (This can include statutory/regulatory requirements, project goals and = should=20 also clearly state the responsible management unit and system = owner.) =20

 

This agreement shall be reviewed = and=20 updated on an annual basis  or should be amended whenever = major =20 changes to the systems concerned are planned and executed.  A = change log=20 and a new signature page should be attached whenever these events=20 occur.

 

SYSTEM SECURITY CONSIDERATIONS = =96=20 General = information, data=20 descriptions and data/work flows shall be documented in this section as = well as=20 risks and mitigation strategies so that a clear picture is presented to = each=20 participant of any residual risk.  Any residual risks should be = associated=20 with either the business or mission component, administrative component = or the=20 customer component.  To that end, the following documents shall be = included=20 (where data sensitivity allows) to the ISA:

 

=B7        =20 Risk = Assessments =96=20 Risk = Assessments for=20 systems included in this agreement shall be amended by all participants = to=20 include the details of the agreement.  A copy of the amended Risk=20 Assessment shall become an attachment to this agreement. A copy of the = Residual=20 Risks accepted by the DAA should also be included.

 

=B7        =20 System = Security=20 Plans =96 System Security=20 Plans for systems included in this agreement shall be amended by all=20 participants to include the details of the agreement.  A copy of = the=20 amended System Security Plan shall become an attachment to this=20 agreement.

 

=B7        =20 Configuration=20 Management Plan =96 Configuration Management Plans = for systems=20 included in this agreement shall be amended by all participants to = include the=20 details of the agreement.  A copy of the amended Configuration = Management=20 Plan shall become an attachment to this agreement.

 

=B7        =20 Trusted = Facilities=20 Manual =96 Trusted=20 Facilities Manuals for systems included in this agreement shall be = amended by=20 all participants to include the details of the agreement.  A copy = of the=20 amended Trusted Facilities Manual shall become an attachment to this = agreement.=20

=B7        =20 Security = Test and=20 Evaluation Plan/Report =96=20 Security Test and Evaluation Plans and subsequent reports for systems = included=20 in this agreement shall be amended by all participants to include the = details of=20 the agreement.  A copy of the Security Evaluation Report shall = become an=20 attachment to this agreement.

 

=B7        =20 Miscellaneous=20 Security Assurance =96=20 Additional citations should be included to address any additional = security=20 concerns and any deviations from USDA or NIST Guidance and/or = Policy. =20 Additional citations should also be included for USDA policies that = delegate=20 specific security responsibilities to agencies/staff offices for=20 execution.  Examples include, but are not limited to:

 

o      =20 Incident=20 Reporting

o      =20 Employee/Contractor=20 Trusted Behavior Expectations

o      =20 Information=20 Exchange Security

o      =20 Maintenance and=20 Review of appropriate records, logs and audit trails

o      =20 Applicable=20 Certification & Accreditation/Interim Authority to = Operate

o      =20 Any other = agency/staff office policies or practices

 

Executive Summaries/Sign-Off =96 = An Executive = summary=20 shall be prepared that details all residual risks and is tied directly = to the=20 portion of the ISA that contains all appropriate signatures.  = Conditions=20 for revocation of an ISA authority shall appear in this area as = well.

 

 

 



[1] NIST Special Publication 800-37 =

[2] Public Law 107-307

* These criteria were derived from CS-009, = Guidance on Configuration Management, Part 1 =96 Policy and=20 Responsibilities and USDA Guidelines for Writing Configuration = Management=20 Plans (CMPs) Ver 1.1.

 

* These criteria were derived from the = USDA=20 Guidelines for Writing the Security Feature Users Guide = (SFUG).

 

* These criteria were derived from the = USDA=20 Guidelines for Writing Trusted Facility Manuals (TFM).

 

* These criteria were derived from NIST = Special=20 Publication (SP) 800-30, Risk Management Guide for Information = Technology=20 Systems, and the USDA Risk Assessment Methodology = guide.

 

* These criteria were derived from NIST = 800-18,=20 Guide for Developing Security Plans for Information Technology=20 Systems.

 

* These criteria were derived from NIST = 800-18,=20 Guide for Developing Security Plans for Information Technology=20 Systems.

 

* These criteria were derived from NIST = 800-18,=20 Guide for Developing Security Plans for Information Technology=20 Systems.

 

* These criteria were derived from USDA = Cyber=20 Security Privacy Requirements.

 

* These criteria were = derived from=20 USDA OCIO IT Disaster = Recovery and=20 Business Resumption Planning Certification and Accreditation Checklist, = Version=20 1.0.