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
The Heartbleed vulnerability (CVE-2014-0160) affects the popular OpenSSL cryptographic software library used to secure internet communication. Following the release of this OpenSSL vulnerability, we immediately initiated a review of EMC Information Infrastructure and RSA products to assess any potential impact. 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
How does one measure the best product-related practices that may be in place in the world of Commercial Off-the-Shelf Technology (COTS)? Often specific versions of an Information and Communication Technology (ICT) product are certified by a third party “Lab” that can examine the state of that version in terms of meeting the security requirements for the identified scope. There are some process aspects of product evaluations that come into play such as one’s approach to handling a found vulnerability with a version of software. The advantage of the product version approach is that if one is acquiring a specific version then one knows that it has been specifically reviewed and evaluated. However there are process gaps in product evaluations that are these days focusing less on secure engineering practices and not yet on supply chain security. Continue reading