Hoops and Hurdles 4
Information technology vendors face a number of obligatory, or practically obligatory, technology standards when selling to the government. They also must contend with a particular environment created by policy directives. We’ve broken out the most important unique prerequisites that companies likely will come across, while also including a section for open source vendors. How many of these hurdles you’ll jump over—or through—depends on the nature of your federal business. Possibly you won’t need to go through FedRAMP, or you’re not required to deal with Section 508. No matter—concentrate on the imperatives most relevant to you, although passing knowledge of all can come in handy.
Cybersecurity
Security for government networks, data, end user devices—all of which fit under the umbrella term of cybersecurity, as used in government circles—has skyrocketed to prominence. Government systems face constant challenges ranging from script kiddies to state-sponsored advanced persistent threats. What follows is an overview of how the government manages its cybersecurity problem and the security standards it uses.
FISMA
The basic framework the government applies to cybersecurity comes from a law known as the Federal Information Security Management Act of 2002 (FISMA).1 The law applies to any system that supports federal operations, including private sector–owned systems contracted for by the government.
From a private-sector perspective, FISMA is frustrating because it requires agency assessment and authorization of systems, not products or solutions. There is no such thing as a FISMA product certification.
Roughly, FISMA requires federal agencies to classify systems into categories according to levels of risk. Having identified risks, agencies assess appropriate controls, drawing from a catalog contained in a public document known as Special Publication (SP) 800-53. SP 800-53 is maintained by the National Institute of Standards and Technology (NIST), the government’s applied science and measurement laboratory. Defense and intelligence agencies have additional controls. NIST provides an overview of FISMA’s underlying principles in SP 800-39.
Having chosen the appropriate controls according to a system’s assessed risk profile, agencies check to see that the controls have been implemented correctly, are effective, and operate as intended. A federal official must sign off on the system in order for it to be permitted to operate, a step known as authorization.
FISMA authorization of a system by one agency means little to another, meaning that system components can undergo multiple assessments and authorizations. An exception to that rule applies to some cloud services under a program known as FedRAMP, discussed below.
In the Defense Department, the assessment and authorization process is called the DoD Information Assurance Certification and Accreditation Process, more commonly referred to as DIACAP.
FIPS 140-2
In addition to issuing special publications, NIST publishes a slew of federal computing guidelines known as Federal Information Processing Standards, or FIPS. One of the most important today for vendors is the standard for cryptographic modules, FIPS 140-2. It’s become a widely known, if unevenly enforced, control in federal IT anywhere unclassified data is supposed to be encrypted. (Cryptographic specifications for use in classified systems are maintained by the National Security Agency, which tends not to discuss them publicly.)
FIPS 140-2 differs from other FIPS standards in that NIST has set up a validation program for vendors’ cryptographic modules with accredited third parties. Gaining validation, from the moment a company decides to pursue it to the time it gets it, often takes 9 to 12 months. In all, including the costs of producing documentation, making code changes, laboratory expenses, and personnel costs, certification might cost anywhere from $100,000 to $250,000. The cost partially depends on what level of certification you’re aiming for; there are four levels, with Level 4 being the most secure. Cryptographic modules gain an overall rating, but individual aspects of a module, such as cryptographic key management, are individually assessed, too.
Since 1995, of the 1,549 modules submitted for certification under FIPS 140-2, or its superseded predecessor, 140-1, a plurality have gained an overall Level 2 certificate. Only a handful of companies have attained Level 4 (see Figure 4-1).
Whether to get a certification or not is a difficult question to answer, given the irregularity with which the government enforces FIPS 140-2 validation as a requirement. Manufacturers of remote access software and endpoint- or network security products have little choice but to get certified. But sometimes solicitations will ask vendors to affirm they are “in compliance” with FIPS standards rather than demanding a formal validation certificate. As a result, some companies skate by for a decent amount of time without a validation. Probably at some point, they’ll encounter a big opportunity where validation is an absolute prerequisite and will be forced to hustle for a formal certificate.
Certification can be a competitive advantage if you happen to be in a niche in which most companies aren’t certified. In such cases, one company often quietly certifies its offerings and suddenly becomes a loud proponent of certification. That segment of the federal IT market becomes deeply earnest about FIPS 140-2, and companies queue up to certify their products. A few years later, the certified products are obsolete, and the earlier status quo of patchy compliance reasserts itself.
Common Criteria
The Common Criteria for Information Technology Security Evaluation, more commonly known as just Common Criteria, is an international standard overseen in the United States by the National Security Agency. Common Criteria is broadly concerned with the overall robustness of a product’s security design.
Like FIPS 140-2, it’s commonly referenced but not always consistently implemented, although current federal policy explicitly states that any commercial item procured for purposes of a national security system must be Common Criteria–certified.2 Gaining Common Criteria certification is really expensive, ranging from about $250,000 to $500,000.
Certification criteria are arranged in series of graduated rungs called Evaluation Assurance Levels (EALs), with EAL7 being the most secure. Which EAL level serves as the standard minimum default has varied. Some years it’s been EAL4, other times EAL2.
After gaining certification, companies face the problem of what to do about new product versions, since a change in even one line of code technically negates the certification. Companies forced by circumstance or business strategy to take Common Criteria seriously usually deal with it by keeping certification valid for significant product updates, or through a regular schedule of validation updates about every six months. Evidence of long-term commitment toward refreshing certification goes a long way toward pleasing agency customers who treat Common Criteria with importance.
FedRAMP
Sellers of cloud computing services rated as low or moderate risk under FISMA must undergo a security baseline certification through a program known as the Federal Risk and Authorization Management Program (FedRAMP). Companies that can show that a particular offering meets the relevant FedRAMP security controls gain something called a provisional authorization for the offering. That provisional authorization should be valid across the entire government, although individual agencies can still require companies to add agency-specific controls before granting the offering the authority to operate on their networks.
Companies get FedRAMP certification via a private-sector third-party assessment organization (3PAO). Anytime a cloud service undergoes a significant change, the offering must gain recertification. An obvious example of a significant change is the addition of a new service on top of an existing one—for example, if an infrastructure-as-a-service (IaaS) provider were to add software-as-a-service (SaaS). However, if the IaaS infrastructure itself has not gone through significant change, the provisional authorization process for the new combined IaaS and SaaS could leverage the documentation from the previous IaaS provisional authorization.
Approved Products List
Network device and security companies wanting to do business with the Defense Department might find an additional hurdle in their path, the Approved Products List (APL). The APL, managed centrally on behalf of all military services by the Defense Information Systems Agency (DISA), is a list of network infrastructure and voice, video, and data services that have gone through testing for interoperability, as well as security.
The APL is a bit of a barrier—not only because testing is long and expensive, which it is—but because companies can’t initiate the process on their own. Instead, a DoD sponsor must do so. The key is finding an effective sponsor willing to stick his neck out for you.
Enough companies break through to show that it’s possible. But even for listed companies, the APL can be a pain, since approval doesn’t transfer to new versions of approved products. Keeping an item on the APL often means maintaining an otherwise outdated model for DoD customers as the original approved product is superseded elsewhere.
Section 508
When people refer to Section 508, they’re talking about rules surrounding accessibility of information and communication technology for people with disabilities. The goal is for disabled users to have access to IT functions comparable to those that nondisabled users have. The name comes from an amendment added in 1986 to the Rehabilitation Act of 1972 (which was heavily rewritten in 1998).3 National security systems are exempt from it, as are products located in places frequented only by service personnel for maintenance, repair, or occasional monitoring.4 You can find current accessibility standards on the website of the Access Board, an independent federal agency.
The amount of attention paid to accessibility as an issue in federal IT is cyclical, and in the past few years we’ve been in a trough, although there are indications on multiple fronts that focus on accessibility is increasing again.
Companies can demonstrate the applicability of Section 508 to their products by completing a document called the Voluntary Product Accessibility Template (VPAT). Match up the listed accessibility standards to features in your offerings to determine whether accessibility standards apply. If they do, state how your offerings are, or can be made, accessible. Your offering need not necessarily include accessibility functionality in order to be accessible; in many cases, accessibility is achieved through compatibility with assistive devices such as screen readers.
Some contracting officers ask companies to certify that they are Section 508 “compliant” despite the fact that that isn’t how the accessibility law works. There’s no such thing as a Section 508 certification; the Access Board doesn’t test and review products. Accessibility is achievable in multiple ways, making compliance open to interpretation. Should certification of compliance be a condition of submitting an offer, as it sometimes is, refer to your VPAT, so it’s clear what you are and are not promising in terms of accessibility.
If you hail from a part of the private sector not yet reached by accessibility standards, you need not necessarily add such features, since a contracting officer can make a written finding of commercial nonavailability as a means of satisfying the section.5 Contracting officers are prevented from making those determinations if available commercial items meet even some accessibility standards.
If you’re from a commercial sector where accessibility standards have penetrated, an offering that meets none or only some of the standards will be passed over in favor of one that meets all the standards, even if your offering costs less. If your VPAT indicates that you have greater accessibility than your competitor, you should win the business. The government also accepts equivalent facilitation, meaning that a company relies on an alternative means to deliver the same functionality.
Contracting officers can, in addition to nonavailability findings, find that accessibility standards would create an “undue burden” on the agency.6 But the fact that an accessible product is significantly more expensive than a nonaccessible product is not by itself grounds for an undue burden finding.
Even if a contracting officer makes a commercial nonavailability or undue burden finding, “alternative means of access” still must be provided to disabled users. Responsibility for providing that alternative means probably will fall on the government unless you’ve somehow promised to satisfy the entirety of Section 508 requirements.
SmartBuy
When the General Services Administration early last decade launched a mechanism for negotiating software licenses on a governmentwide scale and dubbed it SmartBuy, many software publishers were convinced they were witnessing the birth of a next generation of federal buying mechanisms.
From then on, said federal officials at the time, the government would buy software in bulk. What previously prevented the government from getting the lowest license prices possible, they said, was the fact that agencies acted individually and so dispersed the buying power of the government. While big agencies might have been able to negotiate good deals, smaller agencies were paying drastically more for the same or similar licenses and software updates. By establishing blanket purchase agreements with software vendors in the expectation that the agreements would become the definitive federal source for those vendors’ products, the government could present a unified, price-reducing face to industry.
Initially, it seemed that a new age of government procurement had arrived. These days, it’s evident that some of the energy around the initiative has dissipated. An attempt to push through a Federal Acquisition Regulation rule making SmartBuy mandatory for consideration among civilian agencies died a quiet death in early 2011, when acquisition officials stuffed the proposed rule into a “holding file.”
And software companies haven’t proved that eager to cooperate. Federal officials won a notable victory when in 2005 they practically forced Oracle into SmartBuy (Oracle was supposedly badmouthing SmartBuy to agency customers), but the pace of new SmartBuy vendors has slowed. Many companies reject SmartBuy on the grounds that the program does not generate demand, margins are too low, and the hurdles for receiving an agreement too many. Reaching an agreement involves lots of ongoing scrutiny over company commercial sales and practices—and contractors must pay a 2 percent fee when a buying agency chooses to use these agreements. “We’re already on the GSA schedule; we get audited all the time. We have to put discounts into that program—we’re not going to go through all this stuff again for another program when we don’t see the payback,” one software executive told us.
Special Considerations for Selling Open Source Software to the Government
Free and open source software, by its very nature, still engenders suspicion among some government officials, particularly those who retain the outdated view of it as the territory of wide-eyed, bushy-bearded coders with questionable hygiene and a propensity to make sweeping statements about the need for revolutionary movements.
A once more practical, though now obsolete, objection to open source was that it is not a commercial item. But in fact it is, since the very definition of a commercial item is something that’s customarily used by the general public and that has been sold, leased, or licensed to the public.
Some of the confusion is due to the fact that the open source business model is admittedly different from the proprietary model, since open source companies are willing to give away their product and make money by selling services such as distribution, support, integration, and training. An October 16, 2009, Defense Department memo titled “Clarifying Guidance Regarding Open Source Software” should settle this argument once and for all since it states that “in almost all cases, [open source software] meets the definition of ‘commercial computer software.’”
Another objection has been over open source license terms and is rooted in a common misconception of those terms. The worry is that should the government incorporate open source software and make changes to the code, it would be required to distribute those changes back to the public. Not so. Open source licenses—including the GNU General Public License, which is the most common open source license—permit alterations for internal use and the distribution of that code within an organization without activation of the requirement to make the changed code available for public download. It’s only when any organization makes its changes available outside its boundaries do open source licenses generally require that the new code be made available to the entire public.7
Where the boundary for internal use distribution exactly lies—whether it encompasses the entire federal government or just a department or agency—is unknown and probably doesn’t matter. Plenty of agencies realize there’s value to be had by distributing their changes back to the open source community and so voluntarily distribute without prodding.
As we neared completion of this book, a defense contractor and the Army worked themselves into a brief tizzy over whether a clause in the Apache license exposes the government to an open-ended liability that would be illegal under a fiscal law known as the Antideficiency Act (ADA). The ADA prevents the government from committing to spend money that Congress hasn’t yet appropriated, and the worry was that an indemnification clause in the license would create a future unlimited obligation. The upshot is that it doesn’t. Under the license terms, the only way the government would be liable to pay indemnification claims to Apache coders is if it itself were to indemnify a third party. Since the likelihood of that occurring is so near zero as to be practically zero, the problem was declared to be irrelevant.
Final Note
Government prime contractors are well aware of the policies mentioned in this chapter. Unfortunately, many of the leading technology manufacturers and software developers are not. While the government is committed to using commercial products as much as possible, the most frequent argument for not doing so is the private sector’s inability to easily accommodate the government’s requirements. The more manufacturers try to accommodate them, the more grateful agencies are likely to become.
ENDNOTES
1. 44 USC 3531–3549.
2. U.S. National Security Agency. CNSS Secretariat. National Information Assurance Acquisition Policy No. 11.
3. 29 USC 794(d).
4. FAR 39.204(b) and (d).
5. FAR 39.204(c).
6. FAR 39.204(e).
7. There is in fact just one (deeply unpopular) open source license that requires all derivatives, regardless of distribution, to be made public. It’s called the Reciprocal Public License, and it was developed by a guy in Denver for use in a particular web application framework product.