COMMENT: All Secure
Changing the MarketBy Mary Ann Davidson
Purchasing criteria should focus on lifecycle security costs.
I’ve been known to say often over the course of my career that there are no new security problems, just the same old problems with new protocols. (True statement: the application firewall market developed after people got the bright idea to start overloading HTTP to—wait for it—get through firewalls. Kind of like letting in everyone who knocks on your front door and checking IDs only after they are all in your living room.) George Santayana’s oft-quoted statement that those who cannot remember the past are condemned to repeat it was never truer than when it is applied to information security.
That said, the information security market has changed in the last five years, and the driver for security change has been customer demand as much as or more than a “vendor awakening.” Software assurance, in particular, has moved from the theoretical to the practical as more vendors disclose (or are forced to disclose) their secure development practices—if they are not outright competing over them. The market shift has been led by critical customer segments that are focused on their lifecycle security costs as never before and that are demanding more from their suppliers, in part because “unexpected security events” have become a large and unpredictable part of any organizations’ IT budget.
Whether it is a matter of locking software configurations down upon installation or disclosing development practices to the nth degree, the security landscape for vendors has shifted from “nobody will pay more for better security” to competing in Snow White contests to be the universal response to “Mirror, mirror on the wall, who is the most security-minded vendor of them all?” Vendors respond to customer demand, and customers can change and are changing the marketplace for secure software.
The U.S. government is one of the significant players in changing the security marketplace. Cost considerations are leading to heavy use of commercial off-the-shelf software (COTS) as never before, but to feel comfortable about using COTS in critical systems, U.S. agencies want far more transparency to know what they are getting from a security standpoint, including not only how the code was developed but also its provenance ( where it was developed). The Department of Homeland Security, in addition to its many other functions, runs a software assurance forum in which a broad tent of industry players, academics, and customers collaborate on better software development practices. Among other achievements, the participants have produced a draft acquisition guide to help U.S. government procurement officers determine how a supplier has built security into its software. 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 change the market dynamic.
More development practice transparency is good, not only to move the market but also to let security-aware customers know what they are getting. There are third parties that analyze software binaries for security vulnerabilities as a service. This is contributing, I suspect, to the fact that vendors themselves are making increased use of various vulnerability-finding tools. (Why pay a third party when, really, you need to be doing that sort of vulnerability finding yourself before you ship product?)
Secure configurations are another area in which market expectations have changed because of customer demand. A draft bill amending the Federal Information Security Management Act requires agencies to procure “built-in, not bolted-on” security. The Office of Management and Budget has already mandated that federal agencies lock down their desktops per the Federal Desktop Core Configuration (FDCC) for Microsoft Windows Vista and Windows XP. The result is that many vendors must certify that their products run on FDCC-compliant desktops. I suspect that the FDCC will be the first of many such programs that change the market expectation from “Hey, customer, it’s your problem to configure this product securely” to “My product installs more securely than my competitor’s.” It makes a lot of sense for a vendor to do once (lock down its default installation) what customers would otherwise spend time and money doing (locking down individual products).
Having customers make “better security at a lower lifecycle cost” a purchasing criterion is something I’ve advocated for some time. Better security at lower cost—what’s not to like?
Mary Ann Davidson is the chief security officer of Oracle, responsible for secure development practices and security evaluations and assessments. She represents Oracle on the board of directors of the Information Technology Information Security Analysis Center (IT-ISAC), has served on the U.S. Defense Science Board, and is on the editorial review board of SC Magazine.