Having the responsibility for securing a portfolio of more than 100 products, I have dealt with thousands of engineers, product managers and other stakeholders across EMC and RSA to get them to adopt security development best practices. Through highs and lows, I have learned a few things that I want to share with the community through this and future postings.
Any chef will tell you that, to successfully cook a recipe, you need good ingredients and a secret sauce. Software security assurance is no exception. When it comes to the ingredients, there are five of them in a successful software security initiative: Policy, People, Process, Technology and Customer Operations.
1 –POLICY: A policy and standard document outlining functional and non-functional security requirements to define the organization’s security expectations for developed applications. This document typically covers critical security capabilities, proper handling of secrets and passwords in the code as well as software design, development and testing considerations. At EMC, we created a Product Security Policy that started as a set of 54 security criteria and now represents 80 criteria that we are driving across our offerings. These criteria, derived from customer security policies, from industry standards and from software security best practices, are the reference for the rest of our software security assurance initiative.
2 – PEOPLE: A training program to ensure that all the personnel involved in the definition and development of the software understand software security fundamentals as well as the software security standard and policy. At EMC, we have put in place an aggressive security engineering training curriculum for the various job roles in the product organization. We have also set up internal online communities to ensure the sharing of best practices.
3 – PROCESS: A Security Development Lifecycle driving security is part of the application development lifecycle from cradle to grave. At EMC, we use the criteria of our Product Security Policy to develop a scoring mechanism that provides a standardized view of the security of our products. Our Security Development Lifecycle also includes recommendations and controls for product planning, product design, software development, source code protection, product testing, product documentation and product assessment for product release.
4 – TECHNOLOGY: A set of proven security technologies shared between software developers to drive consistency and strength across developed applications. At EMC, we call this the “Common Security Platform.” It is a set of software components developed by RSA that provide core security capabilities around Encryption, Authentication, Authorization, Accountability (security logging) and Key Management that drive our products towards a common implementation and the support of open or industry standards such as LDAP, Syslog or SSL/TLS.
5 – CUSTOMER OPERATIONS: Activities and deliverables to ensure that internal or external customers can deploy and operate the developer software securely and in accordance with their internal security policy. At EMC, we are focusing our secure product operations initiative on:
- Enabling secure product serviceability for our customer service employees and partners
- Providing secure deployment guidelines for our products
- Tracking and alerting our customers of security patches required for our products and,
- Gaining the security certifications (e.g., Common Criteria, FIPS 140) expected by some customers
Now, the secret sauce: being born, raised and educated in France, you will not be surprised to hear me say that the software security assurance secret sauce that makes these ingredients work together is more an art than a science. Yet, in my upcoming posts, I will share more about our approach and about strategies for securing software.
