Industry View

Who Pushed Vendors Toward Better Security?

Hint: It had something to do with pressure from customers and government agencies, writes Oracle Corp. CSO Mary Ann Davidson

By Mary Ann Davidson, CSO at Oracle Corp.

Page 3

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.