[
https://issues.apache.org/jira/browse/HDDS-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
István Fajth updated HDDS-10236:
--------------------------------
Description:
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.
was:
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
B: security policy requirements
C: approved security functions
D: approved sensitive security parameter generation and establishment methods
E: approved authentication mechanisms
F: approved non-invasive attack mitigation test metrics
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 security policy authentication
and documentation related questions, note that not all of these areas are
applicable to software and some are needed for certification purposes, those
will be skipped for now.
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.
> 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
> 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: [email protected]
For additional commands, e-mail: [email protected]
