You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "István Fajth (Jira)" <ji...@apache.org> on 2024/02/01 10:16:00 UTC

[jira] [Assigned] (HDDS-10236) Cryptography compliance with FIPS/FISMA (US regulations)

     [ https://issues.apache.org/jira/browse/HDDS-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

István Fajth reassigned HDDS-10236:
-----------------------------------

    Assignee: István Fajth

> Cryptography compliance with FIPS/FISMA (US regulations)
> --------------------------------------------------------
>
>                 Key: HDDS-10236
>                 URL: https://issues.apache.org/jira/browse/HDDS-10236
>             Project: Apache Ozone
>          Issue Type: Improvement
>            Reporter: István Fajth
>            Assignee: István Fajth
>            Priority: Major
>
> FIPS stands for Federal Information Processing Standards, defined by the National Institute of Standards and Technology (NIST).
> The current version is [FIPS 140 - 3|https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf], which is based on the ISO/IEC 19790, and it overwrites some points of the ISO standard.
> There is a series of modifications under NIST SP 800-140 from A to F as follows:
> [A: documentation requirements|https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140A.pdf] (related to compliance certification)
> [B: security policy requirements|https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Br1.pdf] (related to what to define in policies)
> [C: approved security functions|https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Cr2.pdf] (lists compliant security functions)
> [D: approved sensitive security parameter generation and establishment methods|https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr2.pdf] (defines approved methods for key/security parameter generation)
> [E: approved authentication mechanisms|https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140E.pdf] (approved auth mechanisms at certain security levels)
> [F: approved non-invasive attack mitigation test metricshttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140F.pdf] (no addition to the ISO standard)
> Unfortunately the ISO/IEC 19970 is behind a paywall, but based on FIPS 140-3's description it is highly influenced by FIPS 140-2, so the approach we can easily take for the first steps is to have the first set of requirements based on FIPS 140-2 and understand the differences of 140-3 based on the NIST overrides and the standard itself.
> The main area of focus as a starting point is to work on the security functions and parameter generation related questions, then check authentication related questions, the rest does not seem to be applicable to the actual software itself.
> It is not part of the scope to actually bring Apache Ozone through the FIPS certification process at the moment.
> It is not a goal to make Ozone FIPS compliant by default, the aim is to enable it to be compliant with the FIPS regulations, either via plugging in things that are not compliant and with that enable to plug-in the compliant version also, or make it available to easily rule out the usage of non-compliant things via configuration, without changing the default behaviour.
> FISMA/FIPS 140-2 defines four security levels, from lowest to highest security requirements, then discusses in great details the required physical, electrical, mechanical, personal, and organisational aspects of the requirements for the different security levels, in addition to this it defines requirements for certain processes, like authentication, key management, configuration management, and testing, last but not least, operational requirements, development related questions and guidances are also taking place in the standard.
> From Ozone's perspective the significant parts are related to the used/allowed cryptographic algorithms, the used random sources, how we generate and store keys, and other cryptography parameters, and what checks we implement at startup to ensure the integrity of our cryptographic assets we manage, and/or use.
> In an upcoming design document I will post as a PR for this JIRA, I am summarising the details about the current and desired state in our codebase needed to be compliant with FIPS rules, and the path to get there.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org