INFORMATION ASSURANCE (IA) STRATEGY TEMPLATE

INFORMATION ASSURANCE (IA) STRATEGY TEMPLATE

FOR SUBMISSION BY ACQUISITION PROGRAM MANAGERS

Department of the Navy Chief Information Office (DON CIO) Guidance



1. Document Format:

Create the IA Strategy as a stand-alone document that contains sufficient information that clearly

communicates the strategy to the reader. This document should be short (i.e., typically less than 5 pages

long) that describes the program's strategy for complying with Department of Defense (DoD) IA

requirements (outlined in the draft DoDI 8580.bb) and describes at a high level the program's certification

and accreditation (C&A) strategy. Recommend using the IA Strategy template provided in enclosure (1)

to document the minimum required information.



2. Submission and Review:

Submit the IA Strategy document with your Clinger-Cohen Act (CCA) Compliance submission to DON

CIO. Once your CCA Compliance package arrives at DON CIO, the DON CIO CCA Compliance

Coordinator will separate the IA Strategy from the CCA Compliance package for the DON CIO IA Team to

review. If the DON CIO IA staff has questions or concerns about the IA Strategy, the staff will coordinate

with the Program Managers (PM) respective representative for resolution. Upon resolution of all questions

and concerns, the PM shall submit a revised strategy that reflects the required clarification.



3. Approval Process:

Once the DON CIO IA Team has approved the IA Strategy the following actions will take place:



 For Acquisition Category (ACAT) IC and II programs: the IA staff will coordinate with the

DON CIO CCA Compliance Coordinator for input into the approval of the overall CCA Compliance

package,



 For ACAT ID, IAC, and IAM programs: the IA staff will forward the IA Strategy to the DoD

CIO for approval. The DON CIO is required to obtain DoD CIO approval on IA Strategies for

ACAT ID, IAC, and IAM programs before DON CIO approval of the CCA Compliance packages

for those programs. Figure 1 illustrates the approval process.









Page 1 of 12 11/16/2008

PM submit IA Strategy to DON CIO



DON CIO Receives Clinger-Cohen Act (CCA) Compliance Package

(Including IA Strategy)









IA Team Reviews

IA Strategy Program Manager

Revises IA Strategy







Any

No Yes

Problem

Areas? IA Team Documents

System Registration/Certification Team Deficiencies and Sends

Reviews Rest of CCA Compliance Package to Program Manager

ACAT

Yes ID, IAC or No

IAM

Program?









IA Team Forwards IA Strategy (Via Email) to

ASD(NII) for Review







Any

Problem Yes

Areas?



No

ASD(NII) Responds (Via Email) that IA

Strategy is Appropriate





DON CIO Approves CCA

Compliance Package





Figure 1

4. Coordination and Review Lead Time:

Allow at least two months for DON CIO and DoD CIO review and approval of an IA Strategy. For ACAT

IC and II programs (i.e., where the IA Strategy is approved at the DON CIO vice DoD CIO level), allow four

weeks for review and approval. We will make every attempt to accommodate shorter review schedules, but

the best advice is for you to submit your IA Strategy to DON CIO as early as possible. The IA staff

encourages the PM to submit draft IA Strategies for informal review and will make every effort to promptly

review them subject to the staff’s workload.



5. Additional Information:

Enclosure (2) provides further clarification of some of the IA requirements. If you need additional

information about the IA Strategy process or template, please contact Peggy Johnston at (703) 602-6110 or

Margaret.Johnston@navy.mil.









Page 2 of 12

ENCLOSURE 1: DON CIO INFORMATION ASSURANCE (IA) STRATEGY TEMPLATE

Information Assurance (IA) Strategy for

[Program Name]

[ACAT category]



[Document Date]



The Information Assurance (IA) Strategy should provide concise, assertive statements describing

how the program’s IA features comply, or will comply, with applicable law, Federal, DoD, and

DON policies, and describe the program’s certification and accreditation approach.

The IA Strategy is typically a short document that provides the information outlined below. As the

program matures, the Acquisition IA Strategy should also evolve. The PM should maintain the IA

Strategy with revisions as required until system retires and/or phases out.



(1) Introduction:

(a) Brief Program Description:

 Identify the Acquisition Category (ACAT) of the program. Identify current

acquisition life cycle phase and next milestone decision. Identify whether the

system has been designated “Mission Critical” or “Mission Essential” in

accordance with DoDI 5000.2.

 Provide program schedule showing all major milestones, SDD spirals (if

applicable), DT/OT milestones, and IOC/FOC milestones if clarity is needed.

(b) Mission Assurance Category (MAC) and Confidentiality Level:

 Identify the system’s MAC and Confidentiality Level, as specified in the

applicable requirements document, or as determined by the system User

Representative on behalf of the information owner, in accordance with DoDI

8500.2 located at:

http://www.dtic.mil/whs/directives/corres/pdf/i85002_020603/i85002p.pdf.

(c) System Description:

 Provide a high-level overview of the specific system being acquired.

 Provide a graphic (block diagram) that shows the major elements/subsystems that

make up the system or service being acquired, and how they fit together.

 Describe the system’s function, information exchange requirements (IER),

interfaces with the GIG, other IT or systems, and primary databases supported.

 Describe, at a high level, the IA architecture that will secure the system,

including any protection to be provided by external systems or infrastructure.

 If the system will utilize IP communications, it must conform to the Departments

IPv6 policy.



(2) Policies, Standards, and Architectures:

Provide an overview of the IA features and describe how those features are consistent with DoD

and DON policies, standards, and architectures. If they do not apply, provide the specific

Page 3 of 12

exception as stated in the policy, standard, or architecture.

(a) Program Interoperability:

 Comment on whether interoperability requirements are impacted by the IA

design.

(b) System/Network Interaction

 Address if the system has a high degree of system-to-system information

exchange or systems or components are connected to the Global Information

Grid (GIG). (See Enclosure (2) for additional guidance.)

(c) Governing Requirements Documents:

 Describe the program’s methodology used for addressing IA requirements early

in the acquisition lifecycle. Specify whether any specific IA requirements are

linked to the approved governing requirements documents (e.g. Mission Needs

Statement (MNS), Capstone Requirements Document (CRD), Operational

Requirements Document (ORD), Initial Capabilities Document (ICD),

Capabilities Design Document (CDD) or Capabilities Production Document

(CPD)). Describe how program IA requirements are linked to an approved,

validated, up-to-date System Threat Assessment Report (STAR).

 Describe how IA requirements implementation costs (including costs associated

with certification and accreditation activities) are included and visible in the

overall program budget.

(d) Acquisition Strategy:

 Provide a summary of how information assurance is addressed in the program’s

overall acquisition strategy document.

o Describe how the RFP for the System Development and Demonstration

Phase contract was, or will be, constructed to include IA requirements in

both the operational and system performance specifications, and integrated

into the system design, engineering, and testing.

o Describe how the RFP communicates the requirement for personnel that are

trained in IA.

o Explain how the program complies with Section 4.17 in DoDD 8500.1 and

E3.2.5 in DoDI 8500.2 for the use of evaluated commercial-off-the-shelf

(COTS)/government-off-the-shelf (GOTS) IA products. Address whether

the program will be purchasing COTS IA or IA-Enabled products, and the

program’s means for verifying that the mandates of DoDD 8500.1 and

DoDDI 8500.2 on COTS/GOTS IA products will be followed. (See

Enclosure (2) for detailed guidance.)

(e) DOD and DON Policies:

 Describe the extent to which the program complies with the principal DoD and

DON IA policies, including:

o DoD Directive (DoDD) 8500.1, "Information Assurance (IA)," October

24, 2002 located at:

http://www.dtic.mil/whs/directives/corres/pdf/d85001_102402/d85001p.pdf;



Page 4 of 12

o DODI 8500.2, “Information Assurance (IA) Implementation,” February

6, 2003 located at:

http://www.dtic.mil/whs/directives/corres/pdf/i85002_020603/i85002p.pdf;

o DoD 8510.1-M, "Department of Defense Information Technology

Security Certification and Accreditation Process (DITSCAP) Application

Manual," July 21, 2000 located at:

http://www.dtic.mil/whs/directives/corres/pdf/85101m_0700/p85101m.pdf;

o DoD 5200.40, “DoD Information Technology Security Certification and

Accreditation Process (DITSCAP)”, December 30, 1997 located at:

http://www.dtic.mil/whs/directives/corres/pdf/i520040_123097/i520040p.pdf;

o SECNAVINST 5239.3, “Department of the Navy Information Systems

Security (INFOSEC) Program”, July 14, 1995 located at:

http://neds.nebt.daps.mil/Directives/5239_3.pdf; and

o Identify any other DoD and DON IA policies that are applicable, and

explain how the program complies with those directives.

 All IA strategies submitted to the DON CIO should contain explicit reference to

the program’s plans regarding Public Key Enabling (PKE). (See Enclosure (2)

for detailed guidance.)

o If the system must comply with DoD public key requirements, explain

how you plan to implement.

o If the system is exempt, explicitly mention the reasons why, with

reference to current DoD policy on PKI and PKE.

 These and other related directive documents are available by accessing the

Information Assurance Support Environment (IASE) web site at:

http://iase.disa.mil/policy.html , the Washington Headquarters Service (WHS) web

site at: http://www.dtic.mil/whs/directives/, and DON website at:

http://www.doncio.navy.mil/(2445al45ddfwuxe0tanmssu0)/policy.aspx?sType=policy.

(f) Threat Analysis/Risk Assessment (unclassified):

 Describe the methodology used to determine threats and risks to the system.

 Identify the program documentation that identifies the IA requirements,

including how information and/or systems are protected from various threats and

risks and to what degree.

 Briefly include how a system risk assessment, based on system criticality, threat,

and vulnerabilities, was or will be performed.

 In lieu of including a detailed, classified discussion of threats and vulnerabilities,

the IA Strategy should reference the applicable threat or vulnerability

assessment, as applicable.

o In the case of an AIS application, describe whether there were specific

threats unique to this system’s IT resources due to mission or area of

proposed operation.

o State whether the Defense Intelligence Agency (DIA) generic IT threat

database and the Defense Information Systems Agency (DISA)

Vulnerability Management (VM) database were used as a basis for

determining security requirements.

Page 5 of 12

o Additionally, refer to DoD Directive 5160.54 located at:

http://www.dtic.mil/whs/directives/corres/pdf/d516054_012098/d516054p.pdf

and SECNAVINST 3501.1 located at:

http://www.doncio.navy.mil/(2445al45ddfwuxe0tanmssu0)/Contentview.aspx?I

D=714 for guidance in defining requirements for critical assets.

(g) DOD Cryptographic Modernization Program: (See Enclosure (2) for additional

guidance.)

 If the program uses Type 1 cryptographic equipment, address whether or not the impact

of the DOD Cryptographic Modernization Initiative (CMI) upon cryptographic functions

has been considered.

(h) Privacy:

 For systems that collect, process, store, and/or transmit personally identifiable

information, briefly explain how and where notices are posted on systems to clearly

inform users that: 1) The organization collects information, 2) What information is

collected, and 3) Why the organization collects such information. Also, explain what

measures the program will use to protect personally identifiable information.

(i) System Survivability:

 Identify how information system survivability is addressed through incorporation of

protection, detection, reaction, and reconstitution capabilities into the system design.

Comment on whether critical and sensitive operations and the supporting computer

resources have been identified, if comprehensive contingency planning has been

developed and documented, and if tested contingency/disaster recovery plans are in

place.

(j) IA Shortfalls:

 Identify any significant IA shortfalls, and proposed solutions and/or mitigation strategies

(Include as classified annex if appropriate).

o Specify the impact of failure to resolve any shortfall in terms of program

resources and schedule, inability to achieve threshold performance, and

system or warfighter vulnerability.

o If the solution to an identified shortfall lies outside the control of the

program office, provide a recommendation identifying the organization

with the responsibility and authority to address the shortfall.

o If applicable, identify any Acquisition Decision Memoranda that cite IA

issues.



(3) Certification and Accreditation: (See Enclosure (2) for detailed guidance.)

In accordance with DoDD 8500.1, all acquisitions of AISs, outsourced IT-based processes, and

platforms or weapon systems with connections to the GIG must be certified and accredited in

accordance with DoDI 5200.40, “DoD Information Technology Security Certification and

Accreditation Process (DITSCAP).” All internal networks (enclaves) that are “embedded” in

weapon systems or other products are also subject to the DITSCAP, and PMs should consider

the application of appropriate IA controls for all other acquisitions that involve the use of IT.

Describe the overall certification and accreditation approach for this program in regards to the

following areas:





Page 6 of 12

(a) DITSCAP, reference DoD Instruction 5200.40 and DoD Manual 8510.1-M

(http://iase.disa.mil/ditscap/), C&A process, status update:

 Provide the name of the Designated Approving Authority (DAA)(s) Certification

Authority (CA), and User Representative and describe their involvement in the

system security design activities.

o Discuss the DAA(s)’ agreement on the certification and accreditation

approach to be used.

o If no involvement has taken place, then discuss the extent to which the

responsible DAA(s) will become involved.

 Describe the current status of the program’s certification and accreditation

o Provide a timeline or chart describing the target completion dates for each

phase of certification and accreditation, in accordance with DoD 5200.40.

Normally, DITSCAP Phase 1 will be completed prior to or soon after

Milestone B; Phase 2 and 3 completing prior to Milestone C; and

Authority to Operate (ATO) issued prior to operational test and

evaluation. If the DITSCAP process has started, identify the latest phase

completed, and whether an Authority to Operate (ATO) or Interim

Authority to Operate (IATO) was issued. If an ATO has not been

granted, include a POA&M for achieving.

o If the program is pursuing an evolutionary acquisition approach (spiral or

incremental development), describe how each increment will be subjected

to the certification and accreditation process.

(b) Director of Central Intelligence Directive (DCID) 6/3 “Protecting Sensitive

Compartmented Information Within Information Systems”

 If the system being acquired will process, store or distribute Sensitive

Compartmented Information (SCI), compliance with Director of Central

Intelligence Directive (DCID) 6/3 “Protecting Sensitive Compartmented

Information Within Information Systems” is required. If only a segment of the

system is required to comply with DCID 6/3, then the program’s approach to

compliance should be addressed for that segment.



(c) System Security Authorization Agreement (SSAA) Status:

 Describe the status of the program’s SSAA in its development lifecycle. If the

SSAA is still in draft form, provide a top-level timeline for SSAA development

and approval.



(d) Testing Strategy and Evaluation description:

 Describe the strategy for testing the security aspects during developmental test

and evaluation (DT&E) and operational test and evaluation (OT&E). Also,

include the dates (future or past) of these tests.

 Discuss how IA testing has been integrated into the program’s test and evaluation

planning, and incorporated into program testing documentation, such as the Test

& Evaluation Master Plan (TEMP).





Page 7 of 12

(4) Relevant Associated Program Documents:

 Provide statement that this version of the acquisition IA strategy is reflective of

the Program CRD/ORD/ICD/CPD dated _________, and the Program C4I

Support Plan (C4ISP) dated ________.



(5) Point of Contact:

 Provide the name and contact information for the program management office

individual responsible for this IA Strategy document. It is recommended that the

Program Office’s formally appointed Information Assurance Manager be the

point of contact.









Page 8 of 12

ENCLOSURE 2: ADDITIONAL IA STRATEGY INFORMATION



This attachment provides additional information to assist in completion of an IA Strategy submitted

to the DON CIO. It includes information on:

1. Global Information Grid (GIG),

2. DoD Public Key Infrastructure (PKI) and Public Key-Enabling (PKE),

3. DoDD 8500.1 and DoDI 8500.2 on use of COT/GOTS,

4. DOD Cryptographic Modernization Program; and

5. Certification and Accreditation (C&A).



1. Global Information Grid (GIG):

The GIG is defined in Deputy Secretary of Defense Memorandum, "DoD Chief Information Officer

(CIO) Guidance and Policy Memorandum (G&PM) No. 11-8450, Department of Defense (DoD)

Global Information Grid (GIG) Computing" April 6, 2001

(http://www.defenselink.mil/nii/org/cio/doc/GPM11-8450.pdf) as:

A. The globally interconnected, end-to-end set of information capabilities, associated

processes, and personnel for collecting, processing, storing, disseminating and managing

information on demand to warfighters, policy makers, and support personnel. The GIG

includes all owned and leased communications and computing systems and services,

software (including applications), data, security services, and other associated services

necessary to achieve Information Superiority. It also includes National Security Systems as

defined in section 5142 of the Clinger-Cohen Act of 1996.

B. Includes any system, equipment, software, or service that meets one or more of the

following criteria:

(1) Transmits information to, receives information from, routes information

among, or interchanges information among other equipment, software and

services (see para (C) below with respect to embedded information

technology). Examples include, but are not limited to, systems with:

servers, routers, or virtual private networks.

(2) Provides retention, organization, visualization, information assurance, or

disposition of data, information, and/or knowledge received from or

transmitted to other equipment, software and services. Examples include,

but are not limited, to systems with: databases, hard drives, back-up storage,

or firewalls.

(3) Processes data or information for use by other equipment, software and

services. Examples include, but are not limited, to systems with: hubs and

disk drives.

C. The embedded information technology within a product is not considered part of the GIG.

If it provides the functionality described in (B) above, however, it must meet GIG interface

criteria. (An external interface is not considered GIG, but must meet GIG interface

criteria.)



2. DoD Public Key Infrastructure (PKI) and Public Key-Enabling (PKE):

The DoD PKI, in concert with the Common Access Card (CAC), provides a solid foundation for

interoperable, public key enabled security services at multiple levels of assurance. Given the

importance of PKI, all IA strategies submitted to the DON CIO should contain explicit reference to

the program’s plans regarding PKE.



Public key cryptography is a critical element of the DoD and DON overall technical strategy for

information assurance. Authors of IA strategies must consider that:

Page 9 of 12

 All DoD unclassified networks and information systems that authenticate users

shall be PK-enabled using class-three certificate-based tokens.

 Specialized systems that do not support commercially available certificate-based

authentication applications are exempt from this requirement.

 Applications and systems connected to the Global Information Grid (GIG) must

comply with DoD policy and guidance on PKE.

 Applications that do not require public key cryptography are exempt from the

PKE requirement; however, programs should strongly consider that public key

cryptography strongly benefits the security of all applications.



In addition to the DoD Directive 8500 series guidance, program managers should also consult the

following guidance on PKI and PKE (available at:

http://www.defenselink.mil/nii/org/sio/ia/pki/documents.html):



 DoD CIO Memorandum, “PKI and PKE Implementation Update," of October 7,

2003

 DoD Chief Information Officer Memorandum, “Public Key Infrastructure Policy

Update” May 21, 2002

 DoD Chief Information Officer Memorandum, "Public Key Enabling (PKE) of

Applications, Web Servers, and Networks for the Department of Defense," May

17, 2001

 DoD Chief Information Officer Memorandum, DoD Public Key Infrastructure

(PKI),” of August 12, 2000



3. DoDD 8500.1 and DoDI 8500.2 on use of COTS/GOTS:



 Section 4.17 in DoDD 8500.1 requires that all IA and IA-enabled IT hardware,

firmware, and software components and products incorporated into DoD

information systems comply with the evaluation and validation as follows:



o Acquisitions of commercial off the shelf (COTS) IA and IA-enabled IT

products (to be used on systems entering, processing, storing, displaying,

or transmitting national security information) be limited to only those

products that have been evaluated and validated in accordance with:

 The Common Criteria,

 The National Information Assurance Partnership (NIAP) program,

or

 The Federal Information Processing Standard (FIPS) validation

program.

o Acquisitions of government off the shelf (GOTS) IA and IA-enabled

products be limited to only those products that have been evaluated by

National Security Agency (NSA) or in accordance with NSA-approved

processes.

(An IA product is an IT product or technology whose primary purpose is to provide

security services, correct known vulnerabilities, and/or provide layered defense against

various categories of threats. Examples of IA products include data/network encryptors

and firewalls. An IA-enabled product is a product or technology whose primary role is

not security, but which provides security services as an associated feature of its intended

operating capabilities. Security-enabled web browsers and email applications are

Page 10 of 12

examples of IA-enabled products.)



 Section E3.2.5 in Enclosure 3 of DoDI 8500.2 further qualifies the IA/IA-

enabled product acquisition requirements in terms of existence of approved U.S.

Government Protection Profiles for particular technology areas versus

availability of validated products that match the Protection Profile descriptions.

Protection Profiles are implementation-independent specifications for IA and IA-

enabled products developed in accordance with the Common Criteria. Each

DON acquisition program should carefully review the 7 qualifications outlined in

Section E3.2.5 of DoDI 8500.2, and document in its IA Strategy how the

program complies (or intends to comply) with the DoD requirements for

acquisition of IA and IA-enabled IT products.



For additional information, consult the following references:

 DoD Directive 8500.1, “Information Assurance (IA),” dated 24 October 2002, and DoD

Instruction 8500.2, “Information Assurance (IA) Implementation,” dated 6 February 2003,

available at http://www.dtic.mil/whs/directives/

 National Information Assurance Partnership (NIAP) Web site, http://niap.nist.gov/.





4. DoD Cryptographic Modernization Program:



ASD (C3I)’s Memorandum, “Name the Policy” of 23 February 2001 establishes the development of

a DoD Cryptographic Modernization Initiative (CMI) to address the challenges of modernization

and transformation of the Type 1 cryptographic inventory and supporting infrastructure. This

direction was based upon compelling evidence regarding the state of the current cryptographic

inventory. Specifically, current Type 1 cryptographic devices are:

 Based on security and component technologies that are 20-30+ years old and unless replaced

or upgraded will reach the end of their useful cryptographic lives

 Becoming logistically unsupportable in the near future

 Designed to operate in point-to-point configurations even though DoD is increasingly

moving to net-centric information architectures

 Not designed to support the increased Allied and Coalition partner interoperability

requirements that include the ability to add and delete Coalition partners on a very dynamic

basis.



The CMI will ensure the availability of logistically supportable cryptographic devices,

implementing robust cryptographic algorithms in a cost-effective manner throughout their life

cycle. CJCSI 6510.02B sets policy for the modernization of DoD cryptographic equipment held by

DoD Components, and outlines responsibilities and actions associated with the replacement of

specific Type 1 cryptographic equipment items. Each DON acquisition program that employs Type

1 cryptographic equipment items should carefully assess the impact of the CMI on its actual (or

planned) Type 1 cryptographic equipment implementation.



For additional information, consult the following references:

 CJCSI 6510.02B, “Cryptographic Modernization Plan,” dated 27 November 2002, available

Page 11 of 12

at http://www.dtic.mil/cjcs_directives/cjcs/instructions.htm

 NSA Cryptographic Modernization Program Office Web site (on SIPRNET),

http://www.iad/nsa.smil.mil/programs/cmp/index.cfm.



5. Certification and Accreditation (C&A):

The IA Strategy must address the overall C&A status for this program is as mandated by the

DoD Instruction 5200.40, DoD Information Technology Security Certification and

Accreditation Process (DITSCAP) and DoD Manual 8510.1-M, DoD DITSCAP Application

Manual (http://iase.disa.mil/ditscap/) in relation to the following four C&A program phases:



 Phase 1, Definition: includes activities to verify the system mission, environment and

architecture, identify the threat, define the levels of effort, and identify the Designated

Approving Authority (DAA) and Certification Authority (Certifier), and document the

C&A security requirements. This phase culminates with a documented agreement

between the Program Manager, DAA, Certifier, and user representative on the approach

and results of Phase 1.



 Phase 2, Verification: includes activities to document compliance of the system with

previously agreed on security requirements. For each life cycle development activity,

there is a corresponding set of security activities that verifies compliance with the security

requirements and constraints and evaluates vulnerabilities (reference DoD Directive

5000.1, Defense Acquisition).



 Phase 3, Validation: includes activities to assure the fully integrated system in its specific

operating environment and configuration provides an acceptable level of residual risk.

Validation culminates in an approval to operate.



 Phase 4, Post Accreditation: includes activities to monitor the system management,

configuration, and changes to the operational and threat environment to ensure an

acceptable level of residual risk is preserved. Security management, configuration

management, and periodic compliance validation reviews are conducted. Changes to the

system environment or operations may warrant beginning a new DITSCAP cycle.



The strategy must also detail the status of the System Security Authorization Agreement

(SSAA), which is a formal agreement among the DAA(s), the Certifier, user representative,

and Program Manager. It is used throughout the entire DITSCAP to guide actions, document

decisions, specify IA requirements, document certification tailoring and level-of-effort,

identify potential solutions, and maintain operational systems security.



The strategy must also address the program’s Security Test and Evaluation Strategy. The

objective is to evaluate the technical implementation of the system’s security design and to

ascertain that security software, hardware, and firmware features have been implemented as

documented in the SSAA. When necessary, the strategy should discuss the program’s plans

for operating under Interim Authority to Operate (IATO) status and provide a POA&M for

achieving an ATO.









Page 12 of 12