EMC World was 2 weeks ago in Vegas, and every year the level of interest in Trust in general and security in particular seems to increase dramatically. I found myself in dozens of conversations with various customer IT personnel asking about IT’s role in securing their environment and what steps they could take. Being in Las Vegas always tends to offer plenty of time for deep contemplation and reflection (as long as you can remember it the next morning), and as I often do I started to think not just about what people were saying but how they were saying it. Most of the conversations focused heavily on what steps people could actively take to help fix security problems – e.g. install new tools, fix processes, train users, etc. – what seemed to be missing was discussion around how to minimize the existence of security issues in the first place. I realize many readers will think this is just semantics, but in working with customers in the field I’ve found that the distinction is important and frequently overlooked.
What do I mean by minimizing security issues? It’s the use of contractual controls as part of the acquisition process to minimize the amount of security risk that any new IT products or services introduce into the environment. Take a look at the consumer model – virtually every major new product that has been released in the last few years has been discovered to have one or more major security flaws shortly after its introduction. The vendors then enter into a cycle of fix-release-repeat as subsequent security issues are identified. The same types of issues tend to exist for many enterprise-grade IT products, but the lower volume and secular nature of vendors has tended to keep much of it out the public eye.
What organizations need to do is to start mandating that IT vendors adopt better product/service security practices by requiring good security as part of their IT technology acquisition cycle. This means getting the IT security team engaged early in the initial project planning process, not after the products or services decision has already been made (which is what typically happens). IT security should work with the IT and purchasing teams to develop and implement a set of global standard security requirements that apply to all RFPs and contracts, as well as working with project teams to ensure each discrete project has an appropriate set of unique requirements.
Organizations should address three levels of detailed security requirements as part of their standard RFP/contract process – security design, security integration and security functionality. Security design defines requirements for how the vendor ensures the inherent security of their products or services. It should include requirements for items such as vendor security training/awareness program for their developers/administrators, a vulnerability management program for reporting and tracking any discovered vulnerabilities and security configuration guidance for the product/service. The more potential (or even realized) security risks a given product or service introduces to an organization’s environment, the more difficult and expensive it will be for the organization to address the risks. Customer need to work with vendors to help drive better security of their offerings, not just push that responsibility out to their customers.
The second type of defined requirements, security integration, needs to identify how a product should integrate with existing security controls. Some examples are integration with Active Directory for identity management, support for external key managers if the offering support encryption and support for Security Assertion Markup Language (SAML). The inability to integrate with existing security products and standards increases the cost, complexity and ultimately the security risk for the organization. While mandating native integration with all of the security controls in a given environment is most likely unrealistic, greater levels of integration should be weighed positively in the RFP.
The final set of requirements should address any native security functionality integrated in the offerings. These will vary widely depending on the type of product or service as well as the organization’s policies. The primary example of this would be native encryption, which can eliminate the need to purchase and implement a separate encryption capability. Another potential example would be native security policy support.
Like a lot of foundational security controls, writing RFPs and contracts isn’t very sexy or exciting, but a little time spent with a pen can significantly improve your security risk while at the same time reducing costs and complexity. If you’re interested in finding out more about EMC’s efforts in the area of product security, check out our Product Security websites at http://www.emc.com/products/security/index.htm and http://productsecurityblog.emc.com/. There’s also some great information and opinions at http://blog.safecode.org/.