a technology job is no excuse solvitur ambulando
Getting software ready for government. Posted on 3 March 2014 by gunnar
The world of US Government IT is highly regulated, and the blizzard of acronyms and rules can make it hard to work with. That goes both ways, because it’s also hard to get things done in government. If you’re selling software, or working on an open source project that might be used by the government, there’s a lot of homework you can do to make things easier for everyone. Unfortunately, that homework is not obvious. I get asked about this a lot, so I made this list. While most of these items are specific to the US Federal government, state and local agencies will have similar requirements. They’ll all have different names for them, and slightly different requirements at the margins, but all governments basically want the same things.
These two are no help.
FIPS 140-2 The US Government wants to make sure that any cryptography being used for data-in-transit or data-at-rest has been reviewed by a third party. The National Institute for Standards and Technology (NIST) created a certification regime for crypto software called the Federal Information Processing Standard (FIPS) 140-2. FIPS describes which crypto algorithms may be used, and how they’re to be certified. I’m duty-bound to mention that RHEL has FIPS-certified libraries, but our downstream friends like CentOS and Scientific do not. Keep that in mind when proposing your software stack to the government. Questions you should be able to answer. Have your tried running your application or tool with RHEL in FIPS mode? Does your project use cryptography or handle cryptographic keys? Are you using a FIPS-certified library, or your own?
Common Criteria Common Criteria is a security certification for products that do “information assurance” work. If your product performs authentication, authorization, or access control by itself, it probably needs a Common Criteria certification. Without that certification, government customers will be unable to buy your product or may be forced to purchase a competing product that is certified. I wrote a Common Criteria Primer that has a lot more detail. A good way to avoid the need for Common Criteria certification is to offload any “information assurance” work to another tool that’s already been certified. Like FIPS, Common Criteria applies to RHEL specifically, and not our downstream friends. Just sayin’. Things to think about Do competing products or projects have a Common Criteria certification? You can find them on the CCRA’s list of certified products. Does your application perform information assurance functions? Have you budgeted for any engineering or QA work that certification might require? If you’re an open source project, which companies or not-for-profits would be willing to certify for you?
Section 508 Both Federal and State governments require that end-user tools and operating systems be accessible by those with disabilities. Section 508 of the Rehabilitation Act of 1978 must be met by the agencies, not by a vendor. Of course, the agencies need documentation from the vendor to meet the rules. That’s where the Voluntary Product Assessment Template (VPAT) comes in. Many agencies will require a VPAT for products that they purchase. In some cases, this is simple: “I don’t need to meet the Section 508 requirements because I’m not an end-user tool.” In other cases, you’ll need to document how you’re using alt tags on your images, that your product or project can be operated by a screen reader, etc. Questions a government sales guy will eventually ask. Do you have a VPAT for your tool? Is your product accessible to the blind? Do you have ALT tags on all your images? Can you do everything on the CLI you can from the GUI?
SELinux SELinux is a big deal for many government agencies who run Linux. At Red Hat, we’ve spent 10 years training our customers to leave SELinux turned on. If your software requires that SELinux be disabled, it is a serious bug that needs to be fixed as soon as possible. Once your software functions properly with SELinux turned on, the next step is creating an SELinux policy. This is often easier than you think it will be, and you will be drastically improving the security of your deployments. Questions you should already know the answer to. Does your application work with SELinux enabled and enforcing? Does your application have its own SELinux policy? Why not? Does your application require any specific changes to the existing, certified targeted policy in RHEL? Why would you make your life so complicated? Would your tool be more awesome if it knew how to separate different kinds of information? How would a user separate patient data from billing data in a healthcare setting? Can your application treat Top Secret info different from Unclassified info?
Hardening Just like the private sector, the government has a set of baseline configuration requirements for the systems it installs. In the Federal government, there are different rules for the DOD, the Intelligence Community, and the Civilian agencies. In the DOD, there are the “Security Requirement Guides,” or SRGs. In the civilian agencies, they use the “US Government Configuration Baseline,” or USGCB. And so on. Especially for new software, government customers are reluctant to field anything until they have a hardening guide that they can show their security officers to prove that they’ve configured the system properly. Without a hardening guide, it can take many man-months of effort to gain the necessary approvals. The good news is that all these baselines use the same vocabulary for describing how things should be configured, which is found in the NIST Special Publication 800-53. Even better: Everyone now uses the same method to manage their preferred hardening rules. That’s called the Secure Content Automation Protocol (SCAP), and I wrote a layman’s explanation of SCAP you might enjoy. In the past, each agency created their own guidance, which was bad for everyone involved. This is now changing. If we create SCAP content for our software, agencies may now use that directly. At Red Hat, we try to produce SCAP content at minimum, and ideally a human-readable hardening guide, as well. We’re creating and collecting all this content through the scap-security-guide Fedora project. Questions I get all the time How do I configure your application securely? How do I know if I’ve configured this correctly? How can I prove to my security guy that I’ve configured this right? Wouldn’t it be awesome if the government told you how to make your app more secure? If you have a hardening guide, does everything work when the system is hardened?
Smart Cards and Two-factor Authentication In the US Department of Defense, every employee has a Common Access Card (CAC). This is an x509 smart card which, incidentally, was provisioned from a Red Hat Certificate System. These smart cards are widely used, and in many cases, their use is mandatory on DOD computer systems. In the civilian agencies, every employee has a Personal Identity Verification (PIV) card. The PIV are mostly used as an employee badge, but more and more agencies are beginning to use the PIV cards to improve their information security procedures. This means that their use is becoming mandatory, as well. If you only accept a username and password in your software, there is a very good chance that it will be difficult to use in the government. Questions you should keep asking until you get a good answer Can I log into your application with a smart card? Have you tested this with both CACs and PIVs? Can I use my smart card credential to log into a web service? Is your app taking advantage of all the awesome things RHEL’s SSSD can do? Can you use Active Directory and RHEL’s IDM as a source of identity?
USGv6 compliance The US DOD and civilian agencies have agreed on a common interoperability test for IPv6 called USGv6. IPv6 implementations are tested by independent labs to make sure they all work together. Do I care about USGv6? Is IPv6 part of your test plan? Are you sure everything works when you have no IPv4? That’s it! I hope this helps. If you think I missed something, or need more explanation, just let me know in the comments.
common criteria, fips, scap, srg, STIG, usgcb
gunnar
View all posts by gunnar Õ
© 2018 a technology job is no excuse Powered by WordPress | Theme: Graphy by Themegraphy
