Action Item and Competency |
Student Checklist |
1. Access controls and the criteria established in a SSAA |
|
2. Access controls for objects (e.g., data, information, and applications) |
|
3. Access controls for privileged users and/or processes |
|
4. Access control mechanism implementation and policy |
|
5. Access control policies |
|
6. Access control policies and appropriate “umbrella” guidance and policies |
|
7. Access control policies implementation |
|
8. Access control policies that are applicable to information security |
|
9. Access control policy changes and appropriateness for a system being certified |
|
10. Access control privilege assignment |
|
11. Access control requirements and user roles and group management |
|
12. Accreditation boundary of a system |
|
13. Activities associated with configuration control, i.e., physical and functional audits, inventory of the hardware and software components, etc., |
|
14. Adequacy of the implemented access control mechanisms identified in an access control policy |
|
15. Adherence to the parameters of a certification |
|
16. Administrative security policies and procedures to limit the impact of system technical security deficiencies |
|
17. Administrative security procedures appropriate for a system being certified |
|
18. Adoption of requirements which were previously unspecified, but which may be crucial to secure deployment and operation of the system |
|
19. Agreements specified in an MOU or other instruments |
|
20. Alert capabilities provided by audit/intrusion detection tools |
|
21. Alterations to the parameters of a certification process as the system development progresses and the design is modified |
|
22. Alternative means to satisfy audit collection requirements |
|
23. Aperiodic security test and evaluation plans and procedures to test and evaluate agreed upon audit functionality and events |
|
24. Applicable laws, statutes, and regulations |
|
25. Appointment of personnel with any level of privileged access identification |
|
26. Appraisal in support or denial of certification and involved site personnel |
|
27. Appropriate access controls definitions for the IS under review for subjects (e.g., local and remote users and/or processes) |
|
28. Appropriate certification analysis level and adjustment of C&A guideline activities to a program strategy and system life-cycle |
|
29. Appropriate statutory authorities, and the resource and training requirements necessary to conduct a certification |
|
30. Appropriate requirements for system security |
|
31. Appropriate risk management methodology for an IS to be certified |
|
32. Appropriate level of effort |
|
33. Appropriate types of system development and maintenance environments |
|
34. Appropriate documentation policies in preparing an SSAA |
|
35. Appropriate capabilities in a system to mitigate risk from malicious/mobile code contamination |
|
36. Appropriate hardware and its functions |
|
37. Appropriate software and its intended use |
|
38. Aspects of physical security, such as a defined secure work area the means used to protect storage media (e.g., hard drives and removable disks) and protecting access to workstation ports (e.g., communication ports) |
|
39. Assistance of a contractor team or other government organizations |
|
40. Audit elements used to capture information that meets specified security requirements |
|
41. Audit elements and capabilities available on a system being evaluated |
|
42. Audit retention capability and system security requirements |
|
43. Audit event characteristics and their granularity (i.e., type of event, success/failure, date/time stamp, user ID) |
|
44. Audit trail protection from unauthorized alteration and deletion |
|
45. Audit log overflow policy implementation |
|
46. Audit collection requirements relative to system certification |
|
47. Audit collection requirements and a stated authorization policy |
|
48. Audit processes support of the interpretation of audit data |
|
49. Audit policy implementation (to include which events are to be recorded, what action should occur when the log fills, how long audits are to be retained, etc.) |
|
50. Audit procedures to implement a policy (i.e., data reviews, audit retention and protection, response to alerts, etc) |
|
51. Availability of audits including recovery from permanent storage |
|
52. Available security analysis tools used to find security anomalies |
|
53. Available tools to test system capabilities in order to identify residual risk |
|
54. Best security engineering practices as defined by the National Information Assurance Partnership (NIAP). |
|
55. Boundaries of a certification process |
|
56. Budget elements related to the certification process |
|
57. C&A guideline (e.g., NIACAP, DITSCAP) activities to fit a program strategy |
|
58. C&A guideline activities to meet a system schedule (for example, if the system has already completed preliminary design, all C&A guideline phase one activities should be completed as soon as possible) |
|
59. C&A guideline plan and SSAA review by the DAA, CA, PM, and user representative |
|
60. C&A team formation after the CA knows the certification level and tasks required |
|
61. C&A process agreement with the SSAA |
|
62. C&A guideline process and the system life-cycle at the current system phase or activity |
|
63. Capabilities of add-on audit analysis and intrusion detection tools |
|
64. Capabilities employed to enforce the protection of the operating system by preventing programs or users from writing over system areas |
|
65. Certification process boundaries |
|
66. Certification team's roles and responsibilities |
|
67. Certification boundaries |
|
68. Certification milestones |
|
69. Challenges to an MOU or other instruments |
|
70. Change in the security processing mode |
|
71. Changes to a previously approved system configuration and/or operating environment and determination if an assessment of impact is required |
|
72. Changes, to include additions for improving the roles and responsibilities, and accountability for personnel with various levels of access to information systems |
|
73. Changes that may affect an existing certification |
|
74. Changes to original documentation policies |
|
75. Changes to the SSAA |
|
76. Changes to implemented access control mechanisms to meet requirements identified in access control policies. |
|
77. Components which are not to be included in an evaluation |
|
78. Comprehensive evaluation of the technical and non-technical security features of the IS and other safeguards |
|
79. Conditions under which certification activities are accomplished |
|
80. Conditions upon which an accreditation decision is to be made, including the technical evaluation of security features, as well as other safeguards |
|
81. Configuration control and compliance with required INFOSEC policy and technology |
|
82. Configuration control changes |
|
83. Configuration control deficiencies |
|
84. Configuration control for continued applicability |
|
85. Configuration control in place versus that which has been specified in the current SSAA |
|
86. Conformance/non-conformance to specified system certification documentation requirements |
|
87. Connections of systems to networks or to each other and following a defined set of requirements as found in the SSAA |
|
88. Constraints, assumptions, and dependencies of an implemented C&A process |
|
89. Contents of a user registry and access control tables |
|
90. Contingency planning activities |
|
91. Contingency planning process |
|
92. Contingency planning |
|
93. Coordination among related security disciplines, e.g., physical, emanations, personnel, operations, and cryptographic security. |
|
94. Coordination among the various offices responsible for related disciplines |
|
95. Corrective approaches as potential mitigating factors |
|
96. Countermeasures defined in the SSAA for physical security, personnel security, all aspects of INFOSEC, etc. |
|
97. Criteria for generating alerts provided by audit/intrusion detection tools |
|
98. Criteria for personnel selection for a certification team |
|
99. Critical contingency elements |
|
100. Critical contingency elements and IS requirements in relation to mission accomplishment to assure system recovery and reconstitution |
|
101. Critical elements of mission contingency planning identification in relation to a specific operational environment |
|
102. DAA, program manager (PM), and user and understanding of security policies and procedures |
|
103. Data ownership and responsibilities with access control rights |
|
104. Data sensitivity and labeling requirements to determine system classification |
|
105. Data which supports trend analysis |
|
106. Deficiencies in system documentation (missing documents or inadequate detail in the existing documentation) |
|
107. Deficiencies/discrepancies in a configuration control policy |
|
108. Deficiency and alternative safeguards and procedures that could be employed to limit the impact of system deficiency |
|
109. Developers and maintainers and system security engineering principles |
|
110. Development of an MOU or other appropriate instruments |
|
111. Development team's approach to life-cycle system security planning |
|
112. Development of configuration control policies |
|
113. Development and inclusion of a comprehensive system security policy |
|
114. Diagrams or text that clearly delineate the components that are to be evaluated as part of the C&A task |
|
115. Discrepancies or deficiencies in contingency plans |
|
116. Documentation adequacy of detail |
|
117. Documentation policies for continued applicability |
|
118. Documentation policies for updates |
|
119. Documentation of security-related function parameters, defaults and settings |
|
120. Documentation and system configuration of security function defaults and settings, ensuring that all inappropriate factory defaults have been changed |
|
121. Documentation policies that apply to the preparation of the SSAA |
|
122. Documenting mission need elements identification in the critical system contingency plan |
|
123. Effectiveness of all security features, such as password aging and internal labeling, and document the results |
|
124. Effectiveness of applications security mechanisms and their interactions with other systems and network security mechanisms |
|
125. Effectiveness of password management implemented to enforce policies and procedures |
|
126. Effectiveness of password management software in enforcing policies and procedures |
|
127. Effectiveness of intrusion detection capabilities |
|
128. Effectiveness of the contingency plan as described in the SSAA |
|
129. Effectiveness of the disaster recovery plan as described in the SSAA |
|
130. Effectiveness of a contingency plan |
|
131. Elements of life-cycle activity versus the risk management process components of mission, vulnerabilities, threat, and countermeasures to determine if system development activity is ready for certification. |
|
132. Evaluation techniques, e.g., documentation review, automated tools, and written test plan and procedures, etc., in the conduct of the security test and evaluation |
|
133. Evaluation technique(s) to exercise and evaluate security countermeasures or capabilities documented in the SSAA |
|
134. Findings and the overall level of residual risk in a system |
|
135. Flow of critical information from one component to another |
|
136. Formal approvals for other systems and networks for which interconnectivity is sought |
|
137. High level overview of the types of hardware, software, firmware, and associated interfaces envisioned for the completed system. |
|
138. How technical and non-technical security requirements are derived |
|
139. How access privileges are set |
|
140. How a system handles error conditions |
|
141. How a system will operate according to legal mandates |
|
142. How system operating policies and procedures define the implementation of the security requirements |
|
143. Identification of anomalies which indicate successful violation/bypass of security capabilities |
|
144. Identification of audit requirements |
|
145. Identification and authentication mechanisms which identify users and/or processes |
|
146. Impact of audit requirements on system operation requirements |
|
147. Impact of network vulnerabilities |
|
148. Impact of policy and procedures on risk and operations |
|
149. Impact and residual risk of the absence of security features that are necessary for secure systems operations |
|
150. Impact of the mission statement on security requirements |
|
151. Implementation of the change control management processes |
|
152. Implementation of user privileges and group management assignments |
|
153. Improvements to the plans developed by site personnel |
|
154. Information access and configuration control issues for a system |
|
155. Information security planning for life-cycle system security |
|
156. Information security policy |
|
157. Information security policy for the secure operation of the system |
|
158. Inherent audit capabilities of a proposed implementation |
|
159. Inherent and residual risks and the potential corrective approaches |
|
160. Insider threat, including the good intentions of a trusted employee who circumvents security in order to accomplish their job |
|
161. Integrity of an MOU or other instruments |
|
162. Interactions between different security domains in support of system mission and functions |
|
163. Internal system structure including anticipated hardware configuration, application software, software routines, operating systems, remote devices, communications processors, networks, and remote interfaces |
|
164. Interpretation of mission critical elements in support or denial of certification with involved site personnel |
|
165. Intrusion detection mechanisms work as outlined in an SSAA |
|
166. Labeling in accordance with the requirements documented in an SSAA |
|
167. Life-cycle processes and procedures compliance with accreditation |
|
168. Life-cycle processes and procedures to support mission accomplishment |
|
169. Life-cycle processes and procedures discussions with cognizant site personnel |
|
170. Life-cycle security planning |
|
171. Life-cycle security planning and requirements, directives and laws |
|
172. Life-cycle security planning with respect to certification requirements |
|
173. Life-cycle system security planning |
|
174. Life-cycle system security attributes to involved site personnel |
|
175. Life-cycle system security planning accomplishment |
|
176. Life-cycle system security planning proposed by the development team |
|
177. Maintenance of configuration documents |
|
178. Maintenance of configuration documents for conformance to an SSAA |
|
179. Maintenance procedures needed to ensure physical security protection against unauthorized access to protected information or system resources |
|
180. Managed and default file permission settings and factory settings |
|
181. Management of the access control tables and lists |
|
182. Media in use being marked as appropriate, based on the requirements defined in the SSAA |
|
183. Milestone relations to roles and responsibilities |
|
184. Mission critical elements identification (e.g., operational procedures and classification requirements) |
|
185. Mission critical elements, to include system mission, functions, and system interfaces |
|
186. Mission operational environment (e.g., charter, scope of authorities, activation call-up procedures, Information Warfare Condition (INFOCON) processes). |
|
187. Mission description relationship to documented IS needs, including system life cycle |
|
188. Mission statement and applicable security certification requirements in the SSAA |
|
189. Mission-specific discipline relationships and IS requirements with involved site personnel |
|
190. National security classification of data using the mission |
|
191. Nation-state security laws, treaties, and/or agreements |
|
192. Nation-state security laws, treaties, and/or agreements with involved site personnel |
|
193. Nation-state security laws, treaties, and/or agreements in relation to mission needs and accomplishment |
|
194. Need for access control policies |
|
195. Need for contingency planning |
|
196. Need for coordination with related disciplines |
|
197. Need for recertification and reaccreditation |
|
198. Network architecture and what security mechanisms are used to enforce the CIA security policy |
|
199. Network vulnerabilities corrective measures |
|
200. Network vulnerabilities for the system developers and maintainers |
|
201. Network connectivity policy and the proposed implementation for connection |
|
202. Network security posture in light of the CONOPS and the abilities of the expected users and system administrators. |
|
203. Network vulnerabilities that are present during the development of the system |
|
204. Network vulnerabilities |
|
205. Non-technical and technical test/evaluation results, the impact of any countermeasures, and residual risk |
|
206. Operating system and application system security features |
|
207. Operating system integrity capabilities present in the information system management and functionality and their definitions in the SSAA |
|
208. Operating system integrity capabilities and confirming their presence in the information system by incorporating operating system configuration management guidelines, including installing the latest patches and consulting with available experts |
|
209. Organizational point of contact for legal advice |
|
210. Organizations, individuals, and titles of the key authorities involved in the C&A process |
|
211. Parameters of a certification |
|
212. Parameters of a certification and those of similar systems or parallel certifications |
|
213. Parameters of a certification that ensure mission accomplishment |
|
214. Periodic review of the system/product life-cycle. |
|
215. Periodic review of the system/product life-cycle and conformance to the SSAA |
|
216. Personnel selection for the certification team based on the requisite skills |
|
217. Pertinent logical, sequential, and coherent document which will support the DAA’s decision to approve or disapprove |
|
218. Physical support features of a facility, including air conditioning, power, sprinkler system, fences, and extension of walls from true-floor to true-ceiling construction, sensitive space, work space, and the building |
|
219. Physical environment in which a system will operate, including the physical, administrative, developmental, and technical areas and known or suspected threats |
|
220. Physical, environmental, technical, and procedural security disciplines |
|
221. Policy conformation to applicable laws and directives and data owner requirements |
|
222. Post-accreditation periodic compliance validation reviews in the SSAA or as requested by the DAA |
|
223. Potential threats based upon an analysis of the operating environment, and the system development environment inclusion in the certification reports for the DAA |
|
224. Potential avenues of corrective action |
|
225. Potential threats that can affect the confidentiality, integrity, and availability of a system |
|
226. Presence of a disaster recovery plan as documented in the SSAA |
|
227. Presence of and the appropriate use of application security features |
|
228. Presence of change control policies in an SSAA |
|
229. Presence of documentation or a manual used by the system administrator (SA) and information system security officer (ISSO) to set up the system security configuration. |
|
230. Presence of intrusion detection capabilities as defined in the SSAA |
|
231. Presence of system standard operating procedures |
|
232. Principles and practices of information security |
|
233. Procedures needed to counter potential threats that may come from inside or outside of the organization |
|
234. Processes for analyzing audit information |
|
235. Process for an assessment of the impact of changes to the existing SSAA |
|
236. Process diagram of system life-cycle activities and identification of the current phase of life-cycle activity |
|
237. Process review management |
|
238. Process tailoring to an incremental development strategy (if one is used) |
|
239. Protections to prevent audit trails from being modified by any means, including direct edits of media or memory |
|
240. Protections to prevent configuration files and pointers that can run in a supervisory state from unauthorized access or unauthorized modifications, deletions, etc. |
|
241. Protections to prevent the operating system kernel from being modified by any process, program or individual except through an approved organizational configuration management procedure. |
|
242. Purpose of a system and its capabilities in the SSAA |
|
243. Purpose, scope, and contents of a particular MOU or other instruments |
|
244. Related security disciplines and how they apply to the certification of the system |
|
245. Related disciplines needed for a certification team |
|
246. Related disciplines required for accomplishing IS certification |
|
247. Relationship between security policy and procedures and the security requirements |
|
248. Report generation capability |
|
249. Representative processes which must use appropriate identification and authentication mechanism |
|
250. Required security evaluation documentation |
|
251. Requirement for discretionary/mandatory access controls (DAC/MAC) |
|
252. Requirements of a system certification MOU or other instruments |
|
253. Requirements for additional countermeasures based on the security policy being implemented (e.g., routers, firewalls, guards, intrusion detection devices) |
|
254. Requirements that are applicable to a system under certification and accreditation |
|
255. Requirements for disaster recovery/continuity of operation |
|
256. Requirements for emergency destruction procedures |
|
257. Requirements for respective access control features |
|
258. Resource requirements necessary to accomplish the certification process |
|
259. Respective parties and their roles |
|
260. Responsibilities and requirements for team members with specialized knowledge defined via an MOU or other instrument |
|
261. Restrictions needed to reduce the risk of operating the system to an acceptable level |
|
262. Results of automated security analysis |
|
263. Results of changes to the SSAA |
|
264. Results of related security discipline testing |
|
265. Results of testing to support a system residual risk analysis |
|
266. Results and recommendations, based on findings, in support or denial of continued certification |
|
267. Results of an ST&E access control tests |
|
268. Results of the verification of a disaster recovery plan |
|
269. Results of the ST&E pertaining to operating system integrity |
|
270. Results/findings and technical personnel who would be responsible for correcting the findings. |
|
271. Risk management methodology appropriate to the certification of the system. |
|
272. Risk management methodology and threat mitigation examples and explanations |
|
273. Role of related security disciplines in the overall protection of the system |
|
274. Roles and responsibilities of personnel assigned access to a system |
|
275. Roles and responsibilities of a certification team |
|
276. Roles and responsibilities of individual certification team members |
|
277. Scope and parameters of certification |
|
278. Security laws and system development activities |
|
279. Security countermeasures provided by application security mechanisms |
|
280. Security policies and procedures not covered under the laws, agency-specific procedures, etc. |
|
281. Security requirements and a requirements traceability matrix (RTM) |
|
282. Security solutions and implementations that meet specified system security requirements. |
|
283. Security test and evaluation plans and procedures to test and evaluate agreed upon security countermeasures provided by application security mechanisms |
|
284. Security test and evaluation plans and procedures to test and evaluate agreed upon security countermeasures for access control |
|
285. Security test and evaluation plans and procedures to test and evaluate agreed upon security countermeasures documented in the SSAA. |
|
286. Security test and evaluation plans and procedures to test and evaluate agreed upon security countermeasures for network connectivity. |
|
287. Security test and evaluation plan/procedures to test and evaluate agreed upon security countermeasures enforced by the operating system |
|
288. Security tools |
|
289. Security relevant changes found by tools |
|
290. Security requirement collection process |
|
291. Security countermeasures documented in an SSAA |
|
292. Security requirements for the specific mission, environment, data classification level, and architecture |
|
293. Security requirements for interconnectivity with other systems/networks |
|
294. Security requirements that develop a common understanding among the DAA, PM, and Certification Authority |
|
295. Security processing mode identification |
|
296. Security attributes of both data and users accessing the connected system |
|
297. Security clearances of the user population and the access rights to restricted information |
|
298. Security engineering principles that are applicable to information security |
|
299. Security engineering principles and practices |
|
300. Security engineering principles and practices compliance with information security policies |
|
301. Security certification requirements |
|
302. Security certification requirement inclusion in the ST&E plan |
|
303. Security certification test procedures |
|
304. Security certification test plan documentation |
|
305. Security features that will be necessary to support site operations (the physical security description should consider safety procedures for personnel operating the equipment) |
|
306. Security activities to system development activities to ensure that security activities are relevant to the process and provide the required degree of analysis |
|
307. Security countermeasures that implement effective access control |
|
308. Security policies and procedures (i.e., audit policies, access control policies) as minimum requirements into the ST&E plan |
|
309. Security requirements and assisting in the development of ST&E plans and procedures |
|
310. Security requirements |
|
311. Setting certification boundaries |
|
312. Setting of certification boundaries as part of the SSAA. |
|
313. Skills needed to perform an analysis and produce the supporting documentation |
|
314. Source of the security requirements |
|
315. Source of the security requirements for use during negotiations, development of the SSAA, and compliance validation |
|
316. Specific security domains as they apply to system mission and function |
|
317. Specific findings, including risk analysis/mitigation. |
|
318. SSAA accordance with the configuration changes. |
|
319. SSAA revision |
|
320. SSAA validation from the DAA/CA perspective |
|
321. SSAA and other policy development though and MOU or other instrument |
|
322. ST&E evaluation report documentation |
|
323. ST&E testing results for access controls |
|
324. ST&E results |
|
325. Stated system requirements for confidentiality, integrity, and availability in the system design/SSAA documentation |
|
326. Status reporting of MOUs or other instruments |
|
327. Status of a system's current risks |
|
328. Strengths and weaknesses of access control policies |
|
329. Support or denial of certification explanations to involved site personnel |
|
330. System CONOPS and security CONOPS in the SSAA |
|
331. System functions and capabilities |
|
332. System development approach and the environment within which a system will be developed and maintained |
|
333. System recovery capability during loss of power situations |
|
334. System user's characteristics and clearances |
|
335. System description consistency with documented mission needs |
|
336. System configuration control |
|
337. System configuration control plan assessment against policy |
|
338. System operating environment and threat descriptions in mission documentation |
|
339. System maintenance and upgrade procedures and compliance with configuration management procedures (e.g., remote software updates). |
|
340. System mission focusing on the security relevant features of the system required for the SSAA |
|
341. System criticality in an SSAA |
|
342. System architecture including the configuration of any equipment or interconnected system or subsystem of equipment used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, etc. |
|
343. System concept of operations (CONOPS) |
|
344. System acquisition strategy and system life-cycle phase |
|
345. System resources to log all required events |
|
346. System criticality and its impact on the level of risk that is acceptable |
|
347. System external interfaces and the relationship between the interfaces and the system |
|
348. System internal interfaces and data flows |
|
349. System ability to produce viable, inclusive audit data for review and analysis (e.g., selection capabilities for review of audit information) |
|
350. Team members and their composite expertise in the whole span of activities required, and their independence from the system developer or PM |
|
351. Technical finding translation into comprehensible language for non-technical managers |
|
352. Technical aspects of a system meeting the technical security requirements for its intended use |
|
353. Testing tools |
|
354. Threats, such as penetration attempts by hackers, damage or misuse by disgruntled or dishonest employees, and misuse by careless or inadequately trained employees |
|
355. Tools and compliance with accreditation |
|
356. Topics that security policies and procedures must address as part of the certification process |
|
357. Training procedures matching the users’ levels of responsibility, and providing information on potential threats and how to protect information |
|
358. Types of data and data sensitivity |
|
359. Types of data and the general methods for data transmission |
|
360. Unacceptable network vulnerabilities |
|
361. Unintentional human error, system design weaknesses, and intentional actions on the part of authorized, as well as unauthorized users |
|
362. Unique certification analysis documentation requirements |
|
363. Use of audit information to identify attempts to violate/bypass the proper operation of system security capabilities |
|
364. Use of audit information to validate the proper operation of automated system security capabilities |
|
365. Variance between documented and actually installed software and operating systems |
|
366. Various details of an MOU or other instruments |
|
367. Vulnerabilities inherent to a system's specific operating system, applications, and network configuration |
|
368. Where to focus the analysis and testing |
|
369. Whether the audit trail meets the requirements as defined in the SSAA and document the results |
|
370. Whether a disaster recovery mechanism adequately addresses the needs of a site |
|
371. Whether identification and authentication mechanism can correctly identify users and/or processes |
|
372. Whether or not automated security tools produce expected results |
|
373. Whether or not a defined security processing mode is adequate for approving system certification |
|
374. Whether or not application security features produce expected results |
|
375. Whether a plan sufficiently protects the security of information and the investment made in life-cycle security processes |
|
376. Who in a system has access to information views, who grants access authorization, and the parameters used to validate access authorization |
|
377. Tool compliance with accreditation |
|
378. Results of the verification of change control policies |
|