 |
Page History
...
Federal Information System | NOT a Federal Information System |
|---|---|
Website(s) used to collect or publish information by or on behalf of the federal government (regardless of the type or sensitivity of information collected, processed, or stored). | Websites operated by third parties, independent from any government organization (e.g., they do not collect, store, or process any information for or on behalf of the federal government). |
Web application/N-tiered application used to collect or publish information on behalf of the federal government. This includes client-server architectures where remote access is possible. | Desktop productivity tools (e.g., Microsoft Office tools, WordPerfect, FileMaker Pro desktop version, MS Access) |
An enterprise database system (e.g., Oracle, SQL, Postgres) that contains federal government records. Note that even an MS Access or FileMaker Pro database, which is normally considered a desktop tool rather than a system, could be considered an information system if it is not limited to use by a single user and if it provides a remote/web user interface that could allow multiple people to access the data. | A Microsoft Access database operated on a single workstation, and that does not provide a remote access user interface (i.e., it is not web enabled and is only accessible form the local workstation). |
A centrally managed and automated system (collection) of Adobe PDF forms that has been web-enabled to allow users remote access and modification of the forms. | Adobe PDF files kept on a local user's desktop computer or on a networked file share drive. |
General Support Systems (GSS) (e.g., enterprise network environment, data center, enterprise database system, enterprise e-mail environment, etc.) used to support federal information and federal technology resources. | User files that are kept in a network file share or network attached drive for the purpose of online storage and backup. (Note that you should never store sensitive or patient related information in group or public file shares without first checking the security policy and checking with your information security officer) |
Any externally operated system where the federal government has a contractual arrangement or expectation to access or receive the data stored therein. That is, data that is not owned solely by the external organization but is collected on behalf of or for the benefit of the federal government. | Third Party Websites and Applications (TPWA) as defined by HHS and on the approved TPWA list. TPWAs are usually subscription based applications like Facebook, Flickr, GitHub, YouTube, Twitter, IdeaScale, Survey Monkey). To view the full list of currently HHS approved TPWAs, go here. |
Any cloud based website or system that that collects, stores, or processes information on behalf of the federal government. Note that cloud systems also must abide by FedRAMP. |
*Please note that even if yours is not an IT system, federal privacy and OMB regulations may still apply, especially if you are collecting information from private citizens or contractors, including, for example, through online or paper surveys, via clinical trials, etc. You should always consult the OMB clearance office and the NCI Privacy Coordinator for additional guidance.
Overview of FISMA and SA&A
The Federal Information Security Modernization Act (FISMA) of 2014 mandates that all federal information systems — including all NCI information systems — must be formally assessed and authorized to operate (ATO) using the National Institute of Standards and Technology's (NIST) Risk Management Framework (RMF). The RMF is the model used to conduct federal system security assessment and authorizations (SA&A), so the terms RMF and SA&A may be used interchangeably. NIST documented the RMF in Special Publication 800-37, Risk Management Framework for Federal Information Systems: A Security Life Cycle Approach. The RMF is also supported by several additional NIST special publications (SP) guides that are designed to work in conjunction with 800-37. To further help system owners implement the RMF, NIH and NCI have also developed agency-specific SA&A guidance, templates, and sample materials, which are discussed in the following SA&A process guidance pages.
NIST Risk Management Framework
NIST's Risk Management Framework (RMF) is the security risk assessment model that all federal agencies (with a few exceptions) follow to ensure they comply with FISMA. The RMF is formally documented in NIST's special publication 800-37 (SP 800-37) and describes a model for continuous security assessment and improvement throughout a system's life cycle. The RMF comprises six (6) steps as outlined below.
Step 1 — Categorize the information system and the information processed, stored, and transmitted by that system based on an impact analysis. FIPS-199 provides security categorization guidance for non-national security systems (CNSS Instruction 1253 provides similar guidance for national security systems). NIH also requires in this step the completion of the e-Authentication Risk Assessment (eRA) and the Privacy Impact Analysis. Together, these three documents define the security baseline for the system, determine what level and type of identity and access controls are needed to protect the system, and determine if any information in the system falls under the Privacy Act (as amended) regulations.
Step 2 — Select an initial set of baseline security controls for the information system based on the security categorization; tailoring and supplementing the security control baseline as needed based on an organizational assessment of risk and local conditions. NIST Special Publication 800-53 provides security control selection guidance for non-national security systems. CNSS Instruction 1253 provides similar guidance for national security systems.
NIST 800-53 groups security controls by families (e.g., Access Control (AC), Auditing (AU), Risk Assessment (RA), etc.) as well as by impact classification (e.g., Low, Moderate, and High) to help identify the proper controls required for each system.
Many of the controls found in 800-53 can also be tailored with organization-specific guidance such as specific password policies, access control policies, and the like. In order to assist system owners with the security control identification and selection process, NCI has developed multiple security control inheritance guides based on hosting environments (i.e., CBIIT hosted, third party hosted, other NIHnet hosted, etc.) to help owners select controls for their system.
Step 3 — Implement the security controls and describe how the controls are employed within the information system and its environment of operation.
Step 4 — Assess the security controls using appropriate assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.
Step 5 — Authorize information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the information system and the decision that this risk is acceptable.
Step 6 — Monitor the security controls in the information system on an ongoing basis including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials.
