forked from fecgov/openFEC
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathopencontrol.yaml
575 lines (575 loc) · 49.1 KB
/
opencontrol.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
---
schema_version: "1.0.0" # 1.0.0 is the current opencontrol.yaml schema version
name: betafec # Name of the project
metadata:
description: "The Federal Election Commission (FEC) releases information to the public about money that's raised and spent in federal elections — that's elections for US President, Senate, and House of Representatives. BetaFEC is a collaboration between 18F and the FEC. It aims to make campaign finance information more accessible (and understandable) to all users."
maintainers:
dependencies: "Data from the FEC"
certifications: # An optional list of certifications stored remotely
- url: https://github.com/18F/GSA-Certifications
revision: master
systems: # An optional list of repos that contain an opencontrol.yaml stored remotely
- url: https://github.com/18F/cg-compliance
revision: master
standards: # An optional list of remote repos containing standards info that contain an opencontrol.yaml
- url: https://github.com/opencontrol/NIST-800-53-Standards
revision: master
references:
- name: New Relic Application Monitoring
path: https://newrelic.com/application-monitoring
type: URL
- name: API Github
path: https://github.com/18F/openFEC
type: URL
- name: Web app Github
path: https://github.com/18F/openFEC-web-app
type: URL
- name: CMS Github
path: https://github.com/18F/fec-cms
type: URL
- name: Regulations Github
path: https://github.com/18F/fec-eregs
type: URL
- name: Style Github
path: https://github.com/18F/fec-style
type: URL
- name: User Provided Service Documentation
path: https://docs.cloudfoundry.org/devguide/services/user-provided.html
type: URL
- name: Code coverage
path: https://codecov.io
type: URL
- name: Code hound
path: http://www.code-hound.com/
type: URL
- name: OWASP's ZAP
path: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
type: URL
- name: gemnysium- Static Security Analysis
path: https://gemnasium.com/
type: URL
verifications:
- key: travis
name: openFEC Travis CI
path: https://travis-ci.org/18F/openFEC
type: URL
- key: travis
name: openFEC-web-app Travis CI
path: https://travis-ci.org/18F/openFEC-web-app
type: URL
- key: travis
name: fec-eregs Travis CI
path: https://travis-ci.org/18F/fec-eregs
type: URL
- key: travis
name: fec-cms Travis CI
path: https://travis-ci.org/18F/fec-cms
type: URL
- key: codeclimate
name: openFEC codeclimate
path: https://codeclimate.com/github/18F/openFEC
type: URL
- key: codeclimate
name: openFEC-web-app codeclimate
path: https://codeclimate.com/github/18F/openFEC-web-app
type: URL
- key: codeclimate
name: fec-eregs codeclimate
path: https://codeclimate.com/github/18F/fec-eregs
type: URL
- key: codeclimate
name: fec-cms codeclimate
path: https://codeclimate.com/github/18F/fec-cms
type: URL
- key: gemnasium
name: Project's Gemnasium Results
path: https://gemnasium.com/github.com/18F/calc
type: URL
- key: gemnasium
name: openFEC gemnasium
path: https://gemnasium.com/github/18F/openFEC
type: URL
- key: gemnasium
name: openFEC-web-app gemnasium
path: https://gemnasium.com/github/18F/openFEC-web-app
type: URL
- key: gemnasium
name: fec-eregs gemnasium
path: https://gemnasium.com/github/18F/fec-eregs
type: URL
- key: gemnasium
name: fec-cms gemnasium
path: https://gemnasium.com/github/18F/fec-cms
type: URL
satisfies:
-
standard_key: NIST-800-53
# CONCURRENT SESSION CONTROL
# Organizations may define the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or a combination. For example, organizations may limit the number of concurrent sessions for system administrators or individuals working in particularly sensitive domains or mission-critical applications. This control addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts.
control_key: AC-10
narrative: "Concurrent sessions are not limited in the apps."
-
standard_key: NIST-800-53
# ACCOUNT MANAGEMENT
# a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];
# b. Assigns account managers for information system accounts;
# c. Establishes conditions for group and role membership;
# d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;
# e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;
# f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];
# g. Monitors the use of information system accounts;
# h. Notifies account managers:
# 1. When accounts are no longer required;
# 2. When users are terminated or transferred; and
# 3. When individual information system usage or need-to-know changes;
# i. Authorizes access to the information system based on:
# 1. A valid access authorization;
# 2. Intended system usage; and
# 3. Other attributes as required by the organization or associated missions/business functions;
# j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
# k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.
-
standard_key: NIST-800-53
control_key: AC-2
narrative:
- key: ""
text: "a. Only relevnet FEC and 18F team mebers have accounts to systems; b. Assigns account managers for information system accounts are assigned in cloud.gov given access to the RDS boxes and given accounts for the CMS; c. Only developers at 18F have access to the cloud.gov orgnization. Access to the CMS is limited to the 18F-FEC team. The RDS is confined to 18F-FEC DBAs and developers; d. see c e. Cloud.gov administrators and 18F FEC staff grant access to accounts. f. Managed by staff g. accounts can be seen in the respective system. h. 1. No atomatic notifications when accounts are not needed outside of cloud.gov. 2. No automatic notifications on accounts outside of cloud.gov 3. j. - k. - "
# I don't know how to answer:
# j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and
# k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group."
-
standard_key: NIST-800-53
# ACCOUNT MANAGEMENT | SHARED / GROUP ACCOUNT CREDENTIAL TERMINATION
# The information system terminates shared/group account credentials when members leave the group.
control_key: AC-2 (10)
narrative:
- key: ""
text: "Account management is be handled by cloud.gov in the RDS databases and by superuser accounts in the FEC CMS."
-
standard_key: NIST-800-53
# ACCOUNT MANAGEMENT | DISABLE INACTIVE ACCOUNTS
# The information system automatically disables inactive accounts after [Assignment: organization-defined time period].
control_key: AC-2 (3)
narrative:
- key: ""
text: "Disabling interactive accounts is be handled automatically by cloud.gov. In the RDS databases and FEC CMS by administrators and superuser accounts can manually do this."
-
standard_key: NIST-800-53
# ACCOUNT MANAGEMENT | INACTIVITY LOGOUT
#The organization requires that users log out when [Assignment: organization-defined time-period of expected inactivity or description of when to log out]. Related to: SC-23
control_key: AC-2 (5)
narrative:
- key: ""
text: "Cloud.gov will log out users duw to inactivity. The RDS boxes use Amazon's log out system. The CMS does not do this."
-
standard_key: NIST-800-53
# ACCOUNT MANAGEMENT | ROLE-BASED SCHEMES
# The organization:
# AC-2 (7)(a)
# Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;
# AC-2 (7)(b)
# Monitors privileged role assignments; and
# AC-2 (7)(c)
# Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate.
control_key: AC-2 (7)
narrative:
- key: "Privileges are set by cloud.gov for most things 18F infrastructure manages the RDS boxes and FEC and 18F staff control CMS privileges."
text: ""
-
standard_key: NIST-800-53
# INFORMATION SHARING
# a. Facilitates information sharing by enabling authorized users to determine whether access authorizations assigned to the sharing partner match the access restrictions on the information for [Assignment: organization-defined information sharing circumstances where user discretion is required]; and
# b. Employs [Assignment: organization-defined automated mechanisms or manual processes] to assist users in making information sharing/collaboration decisions.
# Supplemental Guidance
control_key: AC-21
narrative:
- key: ""
text: "" # not sure how to answer this
-
standard_key: NIST-800-53
# PUBLICLY ACCESSIBLE CONTENT
# a. Designates individuals authorized to post information onto a publicly accessible information system;
# b. Trains authorized individuals to ensure that publicly accessible information does not contain nonpublic information;
# c. Reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that nonpublic information is not included; and
# d. Reviews the content on the publicly accessible information system for nonpublic information [Assignment: organization-defined frequency] and removes such information, if discovered.
control_key: AC-22
narrative:
- key: ""
text: "a. Privileges are set by cloud.gov for most things, 18F infrastructure manages the RDS boxes and FEC and 18F staff control CMS privileges. b. GSA and FEC employees are trained aobut PII through their respective agencies c. Code and content are reviewed via pull request review and FEC content governance d. " #
-
standard_key: NIST-800-53
# INFORMATION FLOW ENFORCEMENT
# The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on [Assignment: organization-defined information flow control policies].
# Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include, for example, keeping export-controlled information from being transmitted in the clear to the Internet, blocking outside traffic that claims to be from within the organization, restricting web requests to the Internet that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between information systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes, for example: (i) prohibiting information transfers between interconnected systems (i.e., allowing access only); (ii) employing hardware mechanisms to enforce one-way information flows; and (iii) implementing trustworthy regrading mechanisms to reassign security attributes and security labels.
#Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering/inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 22 primarily address cross-domain solution needs which focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, for example, high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf information technology products.
control_key: AC-4
narrative:
- key: ""
text: "The API requires a key to use and is rate limited, except for the website key. The API uses the api.data.gov umbrella ant he app itself only accepts requests from the api.data.gov api. Aside form the RDS boxes, the rest of the environment has the additional cloud.gov protections."
-
standard_key: NIST-800-53
# SEPARATION OF DUTIES
# a. Separates [Assignment: organization-defined duties of individuals];
# b. Documents separation of duties of individuals; and
# c. Defines information system access authorizations to support separation of duties.
# Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes, for example: (i) dividing mission functions and information system support functions among different individuals and/or roles; (ii) conducting information system support functions with different individuals (e.g., system management, programming, configuration management, quality assurance and testing, and network security); and (iii) ensuring security personnel administering access control functions do not also administer audit functions.
control_key: AC-5
narrative:
- key: ""
text: "This data is a subset of the FEC's data and it is public information."
-
standard_key: NIST-800-53
# LEAST PRIVILEGE
# The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.
control_key: AC-6
narrative:
- key: ""
text: ""
-
standard_key: NIST-800-53
# UNSUCCESSFUL LOGON ATTEMPTS
# a. Enforces a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and
# b. Automatically [Selection: locks the account/node for an [Assignment: organization-defined time period]; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded.
control_key: AC-7
narrative:
- key: ""
text: "Implemented with cloud.gov and Amazon. Not implemented on CMS."
- standard_key: NIST-800-53
# AUDIT EVENTS
# a. Determines that the information system is capable of auditing the following events: [Assignment: organization-defined auditable events];
# b. Coordinates the security audit function with other organizational entities requiring audit-related information to enhance mutual support and to help guide the selection of auditable events;
# c. Provides a rationale for why the auditable events are deemed to be adequate to support after-the-fact investigations of security incidents; and
# d. Determines that the following events are to be audited within the information system: [Assignment: organization-defined audited events (the subset of the auditable events defined in AU-2 a.) along with the frequency of (or situation requiring) auditing for each identified event].
control_key: AU-2
narrative:
- key: ""
text: "Cloud.gov logs are available for audit. New Relic also has error reporting notifications that are sent to developers and relevent error logs will be review."
- standard_key: NIST-800-53
# AUDIT REVIEW, ANALYSIS, AND REPORTING
# a. Reviews and analyzes information system audit records [Assignment: organization-defined frequency] for indications of [Assignment: organization-defined inappropriate or unusual activity]; and
# b. Reports findings to [Assignment: organization-defined personnel or roles].
control_key: AU-6
narrative:
- key: ""
text: "Cloud.gov logs are available for audit. New Relic also has error reporting notifications that are sent to developers and relevent error logs will be review."
- standard_key: NIST-800-53
# AUDIT REVIEW, ANALYSIS, AND REPORTING | CORRELATE AUDIT REPOSITORIES
# The organization analyzes and correlates audit records across different repositories to gain organization-wide situational awareness.
# Supplemental Guidance: Organization-wide situational awareness includes awareness across all three tiers of risk management (i.e., organizational, mission/business process, and information system) and supports cross-organization awareness. Related to: AU-12, IR-4
control_key: AU-6 (3)
narrative:
- key: ""
text: "Errors are discussed in slack with relevant parties as they are being resolved."
- standard_key: NIST-800-53
# AUDIT REDUCTION AND REPORT GENERATION | AUTOMATIC PROCESSING
# The information system provides the capability to process audit records for events of interest based on [Assignment: organization-defined audit fields within audit records].
# Supplemental Guidance: Events of interest can be identified by the content of specific audit record fields including, for example, identities of individuals, event types, event locations, event times, event dates, system resources involved, IP addresses involved, or information objects accessed. Organizations may define audit event criteria to any degree of granularity required, for example, locations selectable by general networking location (e.g., by network or subnetwork) or selectable by specific information system component. Related to: AU-2, AU-12
control_key: AU-7 (1)
narrative:
- key: ""
text: ""
- standard_key: NIST-800-53
# SYSTEM INTERCONNECTIONS | UNCLASSIFIED NON-NATIONAL SECURITY SYSTEM CONNECTIONS
# The organization prohibits the direct connection of an [Assignment: organization-defined unclassified, non-national security system] to an external network without the use of [Assignment; organization-defined boundary protection device].
# Supplemental Guidance: Organizations typically do not have control over external networks (e.g., the Internet). Approved boundary protection devices (e.g., routers, firewalls) mediate communications (i.e., information flows) between unclassified non-national security systems and external networks. This control enhancement is required for organizations processing, storing, or transmitting Controlled Unclassified Information (CUI).
control_key: CA-3 (3)
narrative:
- key: ""
text: "This system is built for public data."
- standard_key: NIST-800-53
# LEAST FUNCTIONALITY
# a. Configures the information system to provide only essential capabilities; and
# b. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services].
control_key: CM-7 (2)
narrative:
- key: ""
text: ""
- standard_key: NIST-800-53
# LEAST FUNCTIONALITY | AUTHORIZED SOFTWARE / WHITELISTING
# CM-7 (5)(a)
# Identifies [Assignment: organization-defined software programs authorized to execute on the information system];
# CM-7 (5)(b)
# Employs a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the information system; and
# CM-7 (5)(c)
# Reviews and updates the list of authorized software programs [Assignment: organization-defined frequency].
# Supplemental Guidance: The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. In addition to whitelisting, organizations consider verifying the integrity of white-listed software programs using, for example, cryptographic checksums, digital signatures, or hash functions. Verification of white-listed software can occur either prior to execution or at system startup. Related to: CM-2, CM-6, CM-8, PM-5, SA-10, SC-34, SI-7
control_key: CM-7 (5)
narrative:
- key: ""
text: ""
- standard_key: NIST-800-53
# IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | NETWORK ACCESS TO PRIVILEGED ACCOUNTS
# The information system implements multifactor authentication for network access to privileged accounts.
# Related to: AC-6
control_key: IA-2 (1)
narrative:
- key: ""
text: "Access to applications is set by cloud.gov, 18F infrastructure manages the RDS boxes and FEC and 18F staff control CMS access."
- standard_key: NIST-800-53
# IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | REMOTE ACCESS - SEPARATE DEVICE
# The information system implements multifactor authentication for remote access to privileged and non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access and the device meets [Assignment: organization-defined strength of mechanism requirements].
# Supplemental Guidance: For remote access to privileged/non-privileged accounts, the purpose of requiring a device that is separate from the information system gaining access for one of the factors during multifactor authentication is to reduce the likelihood of compromising authentication credentials stored on the system. For example, adversaries deploying malicious code on organizational information systems can potentially compromise such credentials resident on the system and subsequently impersonate authorized users. Related to: AC-6
control_key: IA-2 (11)
narrative:
- key: ""
text: "Access to applications is set by cloud.gov, 18F infrastructure manages the RDS boxes and FEC and 18F staff control CMS access."
- standard_key: NIST-800-53
# IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | ACCEPTANCE OF PIV CREDENTIALS
# The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials.
# Supplemental Guidance: This control enhancement applies to organizations implementing logical access control systems (LACS) and physical access control systems (PACS). Personal Identity Verification (PIV) credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials. Related to: AU-2, PE-3, SA-4
control_key: IA-2 (12)
narrative:
- key: ""
text: "We do not have PIV card intergration."
- standard_key: NIST-800-53
# IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | NETWORK ACCESS TO NON-PRIVILEGED ACCOUNTS
# The information system implements multifactor authentication for network access to non-privileged accounts.
control_key: IA-2 (2)
narrative:
- key: ""
text: "Access to applications is set by cloud.gov, 18F infrastructure manages the RDS boxes and FEC and 18F staff control CMS access."
- standard_key: NIST-800-53
# IDENTIFIER MANAGEMENT
# a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier;
# b. Selecting an identifier that identifies an individual, group, role, or device;
# c. Assigning the identifier to the intended individual, group, role, or device;
# d. Preventing reuse of identifiers for [Assignment: organization-defined time period]; and
# e. Disabling the identifier after [Assignment: organization-defined time period of inactivity].
# Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices.
control_key: IA-4
narrative:
- key: ""
text: "IP addresses are logged in cloud.gov."
- standard_key: NIST-800-53
# AUTHENTICATOR MANAGEMENT
# a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator;
# b. Establishing initial authenticator content for authenticators defined by the organization;
# c. Ensuring that authenticators have sufficient strength of mechanism for their intended use;
# d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators;
# e. Changing default content of authenticators prior to information system installation;
# f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators;
# g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type];
# h. Protecting authenticator content from unauthorized disclosure and modification;
# i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and
# j. Changing authenticators for group/role accounts when membership to those accounts changes.
control_key: IA-5
narrative:
- key: ""
text: "Access to applications is set by cloud.gov, 18F infrastructure manages the RDS boxes and FEC and 18F staff control CMS access."
- standard_key: NIST-800-53
# AUTHENTICATOR MANAGEMENT | PASSWORD-BASED AUTHENTICATION
# The information system, for password-based authentication:
# IA-5 (1)(a)
# Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type];
# IA-5 (1)(b)
# Enforces at least the following number of changed characters when new passwords are created: [Assignment: organization-defined number];
# IA-5 (1)(c)
# Stores and transmits only cryptographically-protected passwords;
# IA-5 (1)(d)
# Enforces password minimum and maximum lifetime restrictions of [Assignment: organization-defined numbers for lifetime minimum, lifetime maximum];
# IA-5 (1)(e)
# Prohibits password reuse for [Assignment: organization-defined number] generations; and
# IA-5 (1)(f)
# Allows the use of a temporary password for system logons with an immediate change to a permanent password.
control_key: IA-5 (1)
narrative:
- key: ""
text: "Cloud.gov and Amazon handle authentication for the respective systems. For the CMS, Django provides password storage system and uses PBKDF2 by default. (a) Adding a complexity check for CMS users (b) Adding a complexity check for CMS users (c) CMS Uses Django password storage protections (d) CMS uses Django password storage protections (e) Password reuse is prohibited by cloud.gov and Amazon, not CMS (f) Temporary password for system logons with an immediate change to a permanent password on the system level with cloud.gov and Amazon, not CMS"
- standard_key: NIST-800-53
# AUTHENTICATOR MANAGEMENT | HARDWARE TOKEN-BASED AUTHENTICATION
# The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements].
# Supplemental Guidance: Hardware token-based authentication typically refers to the use of PKI-based tokens, such as the U.S. Government Personal Identity Verification (PIV) card. Organizations define specific requirements for tokens, such as working with a particular PKI.
control_key: IA-5 (11)
narrative:
- key: ""
text: "No PIV card implementaion"
- standard_key: NIST-800-53
# AUTHENTICATOR MANAGEMENT | PKI-BASED AUTHENTICATION
# The information system, for PKI-based authentication:
# IA-5 (2)(a)
# Validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information;
# IA-5 (2)(b)
# Enforces authorized access to the corresponding private key;
# IA-5 (2)(c)
# Maps the authenticated identity to the account of the individual or group; and
# IA-5 (2)(d)
# Implements a local cache of revocation data to support path discovery and validation in case of inability to access revocation information via the network.
# Supplemental Guidance: Status information for certification paths includes, for example, certificate revocation lists or certificate status protocol responses. For PIV cards, validation of certifications involves the construction and verification of a certification path to the Common Policy Root trust anchor including certificate policy processing. Related to: IA-6
control_key: IA-5 (2)
narrative:
- key: ""
text: "No PIV card implementaion"
- standard_key: NIST-800-53
# AUTHENTICATOR MANAGEMENT | IN-PERSON OR TRUSTED THIRD-PARTY REGISTRATION
# The organization requires that the registration process to receive [Assignment: organization-defined types of and/or specific authenticators] be conducted [Selection: in person; by a trusted third party] before [Assignment: organization-defined registration authority] with authorization by [Assignment: organization-defined personnel or roles].
control_key: IA-5 (3)
narrative:
- key: ""
text: "Uses GSA, Amazon and GitHub authentication."
- standard_key: NIST-800-53
# AUTHENTICATOR MANAGEMENT | AUTOMATED SUPPORT FOR PASSWORD STRENGTH DETERMINATION
# The organization employs automated tools to determine if password authenticators are sufficiently strong to satisfy [Assignment: organization-defined requirements].
# Supplemental Guidance: This control enhancement focuses on the creation of strong passwords and the characteristics of such passwords (e.g., complexity) prior to use, the enforcement of which is carried out by organizational information systems in IA-5 (1). Related to: CA-2, CA-7, RA-5
control_key: IA-5 (4)
narrative:
- key: ""
text: "Cloud.gov and Amazon handle authentication for the respective systems. For the CMS, ading a complexity check for CMS users."
- standard_key: NIST-800-53
# AUTHENTICATOR MANAGEMENT | PROTECTION OF AUTHENTICATORS
# The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access.
# Supplemental Guidance: For information systems containing multiple security categories of information without reliable physical or logical separation between categories, authenticators used to grant access to the systems are protected commensurate with the highest security category of information on the systems.
control_key: IA-5 (6)
narrative:
- key: ""
text: "Cloud.gov and Amazon handle authentication for the respective systems. For the CMS, Django provides password storage system and uses PBKDF2 by default."
- standard_key: NIST-800-53
# AUTHENTICATOR MANAGEMENT | NO EMBEDDED UNENCRYPTED STATIC AUTHENTICATORS
# The organization ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys.
# Supplemental Guidance: Organizations exercise caution in determining whether embedded or stored authenticators are in encrypted or unencrypted form. If authenticators are used in the manner stored, then those representations are considered unencrypted authenticators. This is irrespective of whether that representation is perhaps an encrypted version of something else (e.g., a password).
control_key: IA-5 (7)
narrative:
- key: ""
text: "Cloud.gov and Amazon handle authentication for the respective systems. For the CMS, Django provides password storage system and uses PBKDF2 by default."
- standard_key: NIST-800-53
# IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS)
# The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users).
# Supplemental Guidance
# Non-organizational users include information system users other than organizational users explicitly covered by IA-2. These individuals are uniquely identified and authenticated for accesses other than those accesses explicitly identified and documented in AC-14. In accordance with the E-Authentication E-Government initiative, authentication of non-organizational users accessing federal information systems may be required to protect federal, proprietary, or privacy-related information (with exceptions noted for national security systems). Organizations use risk assessments to determine authentication needs and consider scalability, practicality, and security in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk. IA-2 addresses identification and authentication requirements for access to information systems by organizational users.
# Related to: AC-2, AC-14, AC-17, AC-18, IA-2, IA-4, IA-5, MA-4, RA-3, SA-12, SC-8
control_key: IA-8
narrative:
- key: ""
text: "Cloud.gov and Amazon handle authentication for the respective systems. For the CMS, Django provides password storage system and uses PBKDF2 by default."
- standard_key: NIST-800-53
# # IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS) | ACCEPTANCE OF PIV CREDENTIALS FROM OTHER AGENCIES
# The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies.
# Supplemental Guidance: This control enhancement applies to logical access control systems (LACS) and physical access control systems (PACS). Personal Identity Verification (PIV) credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials. Related to: AU-2, PE-3, SA-4
control_key: IA-8 (1)
narrative:
- key: ""
text: "No PIV card implementaion"
- standard_key: NIST-800-53
# IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS) | ACCEPTANCE OF THIRD-PARTY CREDENTIALS
# The information system accepts only FICAM-approved third-party credentials.
# Supplemental Guidance: This control enhancement typically applies to organizational information systems that are accessible to the general public, for example, public-facing websites. Third-party credentials are those credentials issued by nonfederal government entities approved by the Federal Identity, Credential, and Access Management (FICAM) Trust Framework Solutions initiative. Approved third-party credentials meet or exceed the set of minimum federal government-wide technical, security, privacy, and organizational maturity requirements. This allows federal government relying parties to trust such credentials at their approved assurance levels. Related to: AU-2
control_key: IA-8 (2)
narrative:
- key: ""
text: "Uses GSA, Amazon and GitHub authentication."
- standard_key: NIST-800-53
# IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS) | USE OF FICAM-APPROVED PRODUCTS
# The organization employs only FICAM-approved information system components in [Assignment: organization-defined information systems] to accept third-party credentials.
# Supplemental Guidance: This control enhancement typically applies to information systems that are accessible to the general public, for example, public-facing websites. FICAM-approved information system components include, for example, information technology products and software libraries that have been approved by the Federal Identity, Credential, and Access Management conformance program. Related to: SA-4
control_key: IA-8 (3)
narrative:
- key: ""
text: ""
- standard_key: NIST-800-53
# INFORMATION SPILLAGE RESPONSE
# a. Identifying the specific information involved in the information system contamination;
# b. Alerting [Assignment: organization-defined personnel or roles] of the information spill using a method of communication not associated with the spill;
# c. Isolating the contaminated information system or system component;
# d. Eradicating the information from the contaminated information system or component;
# e. Identifying other information systems or system components that may have been subsequently contaminated; and
# f. Performing other [Assignment: organization-defined actions].
# Information spillage refers to instances where either classified or sensitive information is inadvertently placed on information systems that are not authorized to process such information. Such information spills often occur when information that is initially thought to be of lower sensitivity is transmitted to an information system and then is subsequently determined to be of higher sensitivity. At that point, corrective action is required. The nature of the organizational response is generally based upon the degree of sensitivity of the spilled information (e.g., security category or classification level), the security capabilities of the information system, the specific nature of contaminated storage media, and the access authorizations (e.g., security clearances) of individuals with authorized access to the contaminated system. The methods used to communicate information about the spill after the fact do not involve methods directly associated with the actual spill to minimize the risk of further spreading the contamination before such contamination is isolated and eradicated.
control_key: IR-9
narrative:
- key: ""
text: "Follow GSA and 18F incident response guidelines."
- standard_key: NIST-800-53
# ACCESS AGREEMENTS
# a. Develops and documents access agreements for organizational information systems;
# b. Reviews and updates the access agreements [Assignment: organization-defined frequency]; and
# c. Ensures that individuals requiring access to organizational information and information systems:
# 1. Sign appropriate access agreements prior to being granted access; and
# 2. Re-sign access agreements to maintain access to organizational information systems when access agreements have been updated or [Assignment: organization-defined frequency].
control_key: PS-6
narrative:
- key: ""
text: "No access agreements on the application level"
- standard_key: NIST-800-53
# ACQUISITION PROCESS | USE OF APPROVED PIV PRODUCTS
# The organization employs only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational information systems.
# Related to: IA-2, IA-8
control_key: SA-4 (10)
narrative:
- key: ""
text: "No PIV card implementaion"
- standard_key: NIST-800-53
# SECURE NAME / ADDRESS RESOLUTION SERVICE (AUTHORITATIVE SOURCE)
# a. Provides additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and
# b. Provides the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace.
# Supplemental Guidance
# This control enables external clients including, for example, remote Internet clients, to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Information systems that provide name and address resolution services include, for example, domain name system (DNS) servers. Additional artifacts include, for example, DNS Security (DNSSEC) digital signatures and cryptographic keys. DNS resource records are examples of authoritative data. The means to indicate the security status of child zones includes, for example, the use of delegation signer resource records in the DNS. The DNS security controls reflect (and are referenced from) OMB Memorandum 08-23. Information systems that use technologies other than the DNS to map between host/service names and network addresses provide other means to assure the authenticity and integrity of response data.
# Related to: AU-10, SC-8, SC-12, SC-13, SC-21, SC-22
control_key: SC-20
narrative:
- key: ""
text: "No DNSSEC"
- standard_key: NIST-800-53
# ARCHITECTURE AND PROVISIONING FOR NAME / ADDRESS RESOLUTION SERVICE
# The information systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal/external role separation.
# Supplemental Guidance
# Information systems that provide name and address resolution services include, for example, domain name system (DNS) servers. To eliminate single points of failure and to enhance redundancy, organizations employ at least two authoritative domain name system servers, one configured as the primary server and the other configured as the secondary server. Additionally, organizations typically deploy the servers in two geographically separated network subnetworks (i.e., not located in the same physical facility). For role separation, DNS servers with internal roles only process name and address resolution requests from within organizations (i.e., from internal clients). DNS servers with external roles only process name and address resolution information requests from clients external to organizations (i.e., on external networks including the Internet). Organizations specify clients that can access authoritative DNS servers in particular roles (e.g., by address ranges, explicit lists).
control_key: SC-22
narrative:
- key: ""
text: ""
- standard_key: NIST-800-53
# PROTECTION OF INFORMATION AT REST
# The information system protects the [Selection (one or more): confidentiality; integrity] of [Assignment: organization-defined information at rest].
control_key: SC-28
narrative:
- key: ""
text: "CMS passwords are encrypted, the rest is publicly available data and not encrypted."
- standard_key: NIST-800-53
# PROTECTION OF INFORMATION AT REST | CRYPTOGRAPHIC PROTECTION
# The information system implements cryptographic mechanisms to prevent unauthorized disclosure and modification of [Assignment: organization-defined information] on [Assignment: organization-defined information system components].
# Supplemental Guidance: Selection of cryptographic mechanisms is based on the need to protect the confidentiality and integrity of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information. This control enhancement applies to significant concentrations of digital media in organizational areas designated for media storage and also to limited quantities of media generally associated with information system components in operational environments (e.g., portable storage devices, mobile devices). Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). Organizations employing cryptographic mechanisms to protect information at rest also consider cryptographic key management solutions.
control_key: SC-28 (1)
narrative:
- key: ""
text: "CMS passwords are encrypted, the rest is publicly available data and not encrypted."
- standard_key: NIST-800-53
# INFORMATION IN SHARED RESOURCES
# The information system prevents unauthorized and unintended information transfer via shared system resources.
# Supplemental Guidance
# This control prevents information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This control does not address: (i) information remanence which refers to residual representation of data that has been nominally erased or removed; (ii) covert channels (including storage and/or timing channels) where shared resources are manipulated to violate information flow restrictions; or (iii) components within information systems for which there are only single users/roles.
control_key: SC-4
narrative:
- key: ""
text: ""
- standard_key: NIST-800-53
# TRANSMISSION CONFIDENTIALITY AND INTEGRITY
# The information system protects the [Selection (one or more): confidentiality; integrity] of transmitted information.
# Supplemental Guidance
# This control applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and/or integrity of organizational information can be accomplished by physical means (e.g., by employing protected distribution systems) or by logical means (e.g., employing encryption techniques). Organizations relying on commercial providers offering transmission services as commodity services rather than as fully dedicated services (i.e., services which can be highly specialized to individual customer needs), may find it difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission confidentiality/integrity. In such situations, organizations determine what types of confidentiality/integrity services are available in standard, commercial telecommunication service packages. If it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, organizations implement appropriate compensating security controls or explicitly accept the additional risk.
control_key: SC-8
narrative:
- key: ""
text: "Website uses https. The applications use security groups set in Amazon and cloud.gov"
- standard_key: NIST-800-53
# INFORMATION HANDLING AND RETENTION
# The organization handles and retains information within the information system and information output from the system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and operational requirements.
# Supplemental Guidance
# Information handling and retention requirements cover the full life cycle of information, in some cases extending beyond the disposal of information systems. The National Archives and Records Administration provides guidance on records retention.
control_key: SI-12
narrative:
- key: ""
text: "This is all publicly available informaiton."
- standard_key: NIST-800-53
# SPAM PROTECTION | AUTOMATIC UPDATES
# The information system automatically updates spam protection mechanisms.
control_key: SI-8 (2)
narrative:
- key: ""
text: "No systems that are applicable to spam protection"