Nist - Fips 140-2
Beverly Zielonko
The Federal Information Processing Standard (FIPS) 140-2 is an important IT security benchmark and U.S. government standard issued by the National Institute of Standards and Technology (NIST). FIPS 140-2 validation is required for the sale of products with cryptography modules to the federal government.
To help address the increasing cybersecurity demands of the Federal sector and other critical sectors, the Federal Information Processing Standards Publication (FIPS) 140-2 validation became a requirement for cryptographic products/software used in a U.S. government agency network and other industries to establish a strong baseline for encryption to better protect sensitive data. As a result, programs such as FedRAMP, FISMA, DoDIN APL, Common Criteria, HIPAA and HITECH healthcare regulations inherit the dependency on FIPS 140-2 validation.
In 1995, NIST (the U.S. National Institute of Standards and Technology) and their Canadian counterpart CSE (Communications Security Establishment) teamed up to establish the mechanisms for testing and certifying that the FIPS 140 benchmark had been met. NIST and CSE employees staff the CMVP (Cryptographic Module Validation Program) and CAVP (Cryptographic Algorithm Validation Program), which cooperate with independent third-party testing labs. While the labs conduct functional testing, it is the CMVP that ultimately reviews the results and issues the FIPS 140 validation. This is the formalized certification/validation process adhered to today.
FIPS Compliance is mandatory for US government endpoints, which means that all computers used for government work must be FIPS compliant. Government/federal organizations, subsidiaries, and their contractors must ensure FIPS compliance as they handle information protected by federal government rules.
Highly regulated federal agencies are certainly not alone in seeking secure products they can trust to keep their data safe in accordance with the highest, and most modern standards and benchmarks. Thus, FIPS 140-2 has been widely adopted around the world in both the public and private spheres.
FIPS compliant is the minimum standard that must be met for government endpoints. FIPS validated or certified demonstrates security that goes beyond that minimum. To be FIPS 140-2 certified or validated, the software (and hardware) must be independently validated by one of 13 NIST specified laboratories.
On the other hand, FIPS compliant means that some, but not all of the product, has been FIPS validated. Therefore, you can have products on the market that might have some third-party FIPS validated software and components, but the entire product is itself not FIPS validated.
As a cybersecurity company, BeyondTrust takes a more robust approach to ensuring secure remote access, such as with remote support and privileged remote access solutions, than other vendors. This is readily apparent in both our solution capabilities and in the attainment of certifications and validations, such as FIPS 140-2.
Government agency systems throughout the world hold highly confidential information that needs strong protection to ensure it never risks falling into the wrong hands. The FIPS 140-2 Level 1 validation should give agencies, and private sector organizations that support government agencies, confidence that BeyondTrust Secure Remote Access can meet the security needs of the most demanding environments.
Julissa Caraballo is a Product Marketing Manager at BeyondTrust. She has over 10 years of experience in software product marketing and lead generation. Previously, Julissa worked as a Marketing Director for a medical management software company. She holds a BA in Business Administration/Marketing and a MBA in Healthcare Management. Her certifications include, Certified Digital Marketing Manager, Pragmatic Marketing Certified and Certified Medical Practice Executive. She can be found on LinkedIn and all social media platforms.
The FIPS 140 standard started in January 1994 with FIPS 140-1, developed by a government and industry working group composed of vendors and users of cryptographic equipment. FIPS 140-2 was issued in May 2001 and FIPS 140-1 was sunsetted a year later.
FIPS-140 became the main input to the international standard ISO/IEC 19790:2006, Security requirements for cryptographic modules, issued in March 2006, so NIST was leading the standards process for much of the world. Hundreds, if not thousands, of products were validated under FIPS 140-2. The vendor community knew how to develop and maintain those products for almost two decades, and historically, validation took from six months to at most 12 months, unless something egregious was found, which did not happen very often because the process was well known and vendors knew what to do and how to do it.
FIPS 140-3 was issued in March 2019 and validation submissions began in September 2020. The FIPS 140-3 standard did not change encryption algorithms or key size. What did change in FIPS 140-3 is that the standard now evaluates security requirements at all stages of cryptographic module creation, including design, implementation and final operational deployment. FIPS 140-3 also requires different authorization levels and users for management activities, similar to what SELinux requires with a SecAdmin user (security admin) and an AuditAdmin (the administrator of the audit files). So the vendor community had some changes to make, but hardware vendors most likely did not have to create a new ASIC with new algorithms and merely had to modify firmware.
The delay in developing quantum-resistant algorithms is especially troubling given the time it will take to get those products to market. It generally takes four to six years with a new standard for a vendor to develop an ASIC to implement the standard, and it then takes time for the vendor to get the product validated, which seems to be taking a troubling amount of time.
I am not sure that NIST is up to the dual challenge of getting the algorithms out and products validated so that vendors can have products that are available before quantum computers can break current technology. There is a race between quantum technology and NIST vetting algorithms, and at the moment the outcome is looking worrisome.
A few weeks ago, I wrote about the NIST Random Number Transition and the crisis this will cause at the end of 2015. I am not alone in attempting to raise visibility to this issue. There is a very good blog written by Marc Ireland, from InfoGard Laboratories, titled The RNG Transition is Coming! on the same subject.
I recommended, in my blog, that customers, like the US Federal Government, who require FIPS 140-2 encryption, should check the FIPS 140-2 certifications of the products that they use to make sure they use the mandated NIST SP 800-90A deterministic random bit generator DRBG versus the soon to be disallowed legacy random number generators.
My recommendation is that if you have devices which do not use the NIST SP 800-90A DRBG, you begin taking steps now to transition to products which do support NIST SP 800-90A DRBG before the end of 2015.
Developing and running Linux workloads for U.S. government regulated and high-security environments requires a long and expensive validation process. Reduce your accreditation timeline and pass on your validation costs with the FIPS 140 certified cryptographic packages of Ubuntu Pro on-premise or on Public Clouds.
FIPS 140-2 is required under multiple compliance regimes, such as the Federal Risk and Authorization Management Program (FedRAMP), the Federal Information Security Management Act of 2002 (FISMA) and the Health Information Technology for Economic and Clinical Health Act (HITECH).
Learn about the US government security standards and the common challenges faced by organizations in their implementation. See how the Ubuntu Security Guide can transform systems compliance in a few minutes. Get to know how Ubuntu is a secure platform for government agencies and complying organizations to build, operate and innovate with open source applications and technologies.
Each FIPS 140 certificate is valid for 5 years. However, vulnerabilities happen, and it is our goal to publish fixed packages quickly, irrespective of their certification status. We therefore provide two alternative options. An option to remain with the certified cryptographic packages (called the 'fips' option), and an option to use the certified packages but include security fixes (called the 'fips-updates' option) when available. Check our documentation pages on how to enable these options.
We strongly recommend enabling the 'fips-updates' option that includes the security fixes. The packages from the 'fips-updates' option are updated to include high and critical security fixes during the whole product lifecycle including the Expanded Security Maintenance (ESM) phase.
c80f0f1006