This is a response to a question I was asked by a State CIO (not our state), regarding legislation that addresses security in procurement. Now I’m sharing with you:
I’ve been very interested in strategies to turn security into a “market force” through the creation of competitive differentiators, and using the purchasing power of the government. I feel this is a non-regulatory way to address the problem—to leverage the fact that we’re capitalists. This was a message delivered to, and very well-received, by the Deputy Secretary of DHS in a recent meeting.
I’m not aware of legislation that’s created an actual requirement for demonstrable security in a product or service—with the exception of the Fedramp program for cloud products. See below:
Effective legislation would, in my opinion, create an expectation that it is the responsibility of the state to purchase products and services that are differentiated by their attention to security. This would have to be based on standards—but don’t create the standards.
Make the products attest that they adhere to existing industry standards (for example OWASP for web application security), and ideally that they’ve been validated by a third party as having met the standard. Don’t make it a mandate that they hire a third party to test the product, just score them higher on the RFP response if they have! Change is thus forced in a non-regulatory way, just by using the power of the purse. Companies start to advertise the fact that their products are demonstrably secure, and capitalism starts to do its thing.
I see the procurement security issue (or supply-chain security) done more through innovation than legislation, and by industry groups more than government. An example is the recent Boeing/DHS conference on that topic a few weeks ago in Mukilteo, WA—sharing ideas rather than waiting for a standard to be imposed by regulators. Also, most of the effort seems around newer technology purchases like cloud products (SAAS and IAAS—PAAS, I think is a notable exception).
The PCI standard mandates that web applications meet security requirements on a quarterly basis (with testing performed by an approved vendor), and that you can only engage a payment processor that has been certified for security. That’s an industry control, and is a reasonably effective way to achieve an outcome; the companies making the money are to provide security, not the organizations spending the money.
At the City of Seattle, we modified procurement and contract language to create an expectation of security, and used that as proposal scoring criteria. The minimum qualifications to bid included third-party attestation OR allowing the City to perform testing for security against the OWASP standard (for SAAS applications).
Evaluation of the product or service included specific scoring on security in policy, vulnerability management, et al., and the RFP template was connected to a spreadsheet of security questions on COTS, SAAS, Proserv, etc, so that the relevant queries on security were integrated into the posted RFP for the product or service being sought. Contract language included the expectation for security management of the product, and submission of additional testing attestation if the product underwent structural or functional changes.
The Fedramp program for cloud providers was created through legislation (HR 1163 in 2013). Fedramp is a standards-compliance certification program for cloud products, with third-party assessment required. Federal agencies cannot procure these products from non-certified vendors. I am aware of nothing similar at the state level.
Part of the NIST framework talks about third-party security, but not in great detail for the lowest tier of “compliance.” The NIST framework was created through executive order (EO 13636 in 2013), so it’s an example of a non-legislative solution.
In my view, when we can collectively implement a market-based strategy to require security in the products we buy, we will turn a significant corner. Changing our thinking about how we secure our information technology and implementing the change through organizational innovation has to happen now. Waiting for legislation—especially federal legislation—is Quixotic.