Who Pushed Vendors Toward Better Security?

In the past five years, software assurance has moved from the theoretical to the practical, as more vendors disclose or are required to disclose their secure development practices if they are not actually trying to use these practices as competitive differentiators.

The market shift has been led by critical customer segments as much or more so than by a vendor awakening.

Customers are increasingly focused upon lifecycle security costs in part because unexpected security events have become a large and unpredictable part of organizations’ IT budgets. Whether it’s providing secure software configurations or disclosing secure development practices, the software landscape for vendors has shifted from “nobody will pay more for better security” to vying in Snow White contests to be the universal response to: “Mirror, Mirror on the wall, who is the most security-minded vendor of all?” Customer demand is changing the marketplace for secure software, a trend that will accelerate through purchasing power or by policies with the effect of regulation.

The US federal government is a significant player in changing the security marketplace. Cost factors are leading to the increasing use of commercial off-the-shelf (COTS) software. In order to feel comfortable using COTS in critical systems, US federal agencies want more transparency regarding how, where and by whom the software they use is developed, in part to better assess risk, of which software security-worthiness is a large component.

A number of US government agencies, including the Department of Defense (DOD), the National Security Agency (NSA), the Office of Management and Budget (OMB) and the Department of Homeland Security (DHS) are focused on software security. The Department of Homeland Security (DHS), for example, runs a software assurance forum where a broad tent of industry, academia and customers collaborate on better software development practices.

Multiple DHS software assurance working groups have produced materials in areas as diverse as secure development practice, security metrics, acquisition and developer education.

The DHS Software Assurance Acquisition Working Group has recently produced the guide “Software Assurance in Acquisition: Mitigating Risks to the Enterprise” to help US government procurement officers determine how a supplier has built security into its software and to gauge software security risks as part of acquisition instead of assuming unknown and unknowable risks after software is already acquired.

The guide provides a lifecycle approach to acquisition: how to address security during planning, contracting, monitoring and acceptance and follow-on acquisition phases. The guide includes extensive due-diligence questionnaires covering software assurance areas such as architecture and design, software development, testing, manufacturing and packaging in addition to related areas such as security training, whether organizations train and/or certify their developers in secure development practice.

Support and lifecycle issues are also addressed to ascertain, for example, how vendors handle security vulnerabilities in their products and patch production (including testing, versioning, and ensuring that patch application does not undo security settings).

The guide discusses the purpose for the questions, the threats that the questions attempt to gauge, and weighs the responses in terms of priority. In other words, the due diligence questionnaires have intelligence built into them instead of being a set of yes/no questions with no rationale as to why the questions — and answers — are important.

While no questionnaire can be all-encompassing, the mere fact of asking suppliers questions related to secure development practice will signal the marketplace, as economists say, that security is important and will ultimately change the market dynamic. Even in the short run, knowledge is power, especially in procuring software that will be used for critical government applications.

Of particular note are sections relating to the self-defense capabilities of software. Historically, most software developers focus on making software as flexible as possible, while too often neglecting “security hygiene” that can improve the baseline defensibility of software. Most developers also fail to consider the possibility of software being deliberately attacked. Moving software from security-aware to self-defending is critical if software is to perform as the infrastructure it actually is. Engineers, for example, build safety factors into their designs on the assumption that sometimes, things go badly wrong; if devices fail, they must fail safely.

Secure configurations are another area where market expectations have changed due to lifecycle cost concerns. That is, if a vendor can do something once (provide a secure configuration out-of-the-box) that benefits a large customer segment and that customers would otherwise have to do repeatedly (that is, securely configure multiple instances of an operating system or application), the economic argument is all for the vendor securing once and many customers than consuming pre-secured software.

A customer sector that successfully demands secure configurations from their suppliers is in a position to lower their lifecycle security costs and also raise the security bar for other customer sectors, since a vendor who can successfully deliver pre-secured software is likely to offer it to multiple customer sectors, not just the customers demanding it.

OMB has grasped the economic benefit of “secure once, use securely many times” by mandating that US federal agencies configure their desktops per the Federal Desktop Core Configuration (FDCC) for Windows Vista and Windows XP. Federal government contractor systems that interface with federal government systems are also subject to FDCC. The federal government believes it will improve security, reduce lifecycle costs, and decrease application-compatibility issues by using a common, enterprise-wide configuration instead of hundreds of different configurations.

The result of FDCC is that multiple vendors must certify that their products run on FDCC-compliant Windows-based desktops. FDCC compliance was mandated by Feb. 1 2008 and affected vendors are in various stages of certifying their products.

FDCC grew out of a US Air Force acquisition program in which Microsoft agreed to deliver their products in an Air Force-specified secure configuration. The benefit to the Air Force was lower lifecycle costs from supporting a single secure configuration instead of hundreds of configurations, and from being able to test patches against a single configuration instead of hundreds of configurations. OMB (via FDCC) is attempting to do more broadly what the Air Force accomplished with a single supplier, thereby broadening the purchasing power that federal agencies collectively wield.

Despite the obvious benefits of FDCC-like programs, there are many challenges with them in areas as broad as governance, scope and timing of implementation. In terms of governance, there is a fundamental difference between a bilateral agreement (single customer-single supplier) and a multilateral configuration standard with which many vendors must comply.

In the latter case, to ensure a level playing field for suppliers, multiple affected stakeholders require input to and should have the same opportunity to consume any secure configuration standard. This calls for governance around standard configuration setting to avoid even the appearance of gaming configurations to the advantage of a single supplier.

The scope of secure configuration programs is a concern in that software is often explicitly designed to be configurable; specifying a single configuration may thus be counter productive. For example, no two business software customers are likely to use identical financial calendars, charts of accounts, sets of financial and operational reports, and so forth.

Therefore, specifying a single mandated application configuration is not desirable. The key to FDCC-like mandates moving forward will be correctly specifying configuration of security-relevant parameters without requiring a one-size-fits-all approach that negates the intentional and beneficial configurability of software. For example, a database can be configured to do online transaction processing (OLTP) or data warehousing, the overall configuration options for which are of necessity quite different.

The timing of secure configuration mandates may also be problematic. Software production is an industrial manufacturing process in that major changes — including configuration changes — can only occur during fixed windows of a product lifecycle (typically, major product releases instead of patches) and must be both heavily tested as well as consumed by downstream components as part of their software development lifecycle.

It may take three to five years for a secure configuration change to ripple through the entire product stack that must consume it. Allowing vendors to make progress at significant (major release) milestones is preferable to asking them to meet an arbitrary deadline that may force them to install products in a way that breaks everything that depends on current settings.

Even with some of the timing, scope and governance challenges of secure configuration programs, it is nonetheless a crucial means to change the market expectation for software vendors from “it’s the customer’s problem to configure this product securely” to “my product installs more securely than my competitor’s product.” Increasing the default security posture of software makes too much sense not to do it.

There is broad awareness among customers and software vendors that software security must improve. Lowering lifecycle costs to customers through secure configurations and providing them with the tools to know how much security they are getting is a critical trend that will enable the market for better software security to flourish.