The launch last week of the IEEE Center for Secure Design is an opportunity to remind the industry of the prominent role of secure design in building secure IT products.
Security engineering requires three main technical activities: Secure design, secure coding and security testing. Much of emphasis has been put by the industry on secure coding and security testing and much less on secure design. That is unfortunate. Continue reading
The following post was co-authored with Steve Lipner from Microsoft and originally posted on the SAFECode blog.
Customers frequently ask all software developers – including SAFECode members – how they can be confident in the security of the software they acquire. We are well aware that acquired software can introduce new vulnerabilities into IT environments and that risk managers need a method for assessing the security of the IT products they procure and the impact those products may have on the organization’s risk posture. Continue reading
This week in San Francisco, tens of thousands of security professionals are gathering for the the RSA Conference. For the seventh year in a row, representatives from EMC’s Product Security Office have been selected by the conference program committee to speak in a session. If you are at the conference, come an meet one of us: Continue reading
Software powers everything – end-user devices, applications, networks, storage, data centers and clouds – and is therefore taking us into a software-defined world. Can we trust software that powers IT? We must, as we strive for resiliency against outages and advanced threats as well as to meet regulatory compliance. Continue reading
This week’s release of the fifth version of the Build Security In Maturity Model (BSIMM-V) reinforces a trend that many of us in the small world of software assurance are witnessing: Developing secure software is no longer the privilege of a few.
I have been closely involved with the BSIMM project since its first version in 2008: EMC was one of the nine companies that were surveyed to build the first version of the model. Five years later, the most astonishing data that BSIMM-V brings to light is 67: The number of firms that have contributed to building the model. The BSIMM-V document makes it clear; these firms have adopted advanced security practices as part of their software engineering process. Five years ago, I am sure that Gary McGraw and his team struggled to even find nine firms willing to share their software security practices.
The journey is far from over; the firms involved with the BSIMM project are large organizations with a well established software engineering process. We need software security to become more ubiquitous across organizations of all sizes and from all verticals. We also need software assurance to expand beyond preventing software vulnerabilities and look at the practices required to ensure the integrity and authenticity of the software code we are delivering as well as the security of the underlying engineering systems and processes that help create this code.
We still have a lot to do, but we are making good progress. Community initiatives like BSIMM provide a great vehicle to continue drive adoption of software assurance practices. Thank you to the BSIMM / Cigital team for continuously updating the model!