SAFECode would not be SAFECode without the tireless efforts of our Member volunteers and contributors. At the center of our work is the SAFECode Technical Leadership Council. Comprised of representatives from every member company, this group helps determine which projects SAFECode will tackle, and leads the collaboration and development process that supports selected projects and member interests. In this new blog series, we’ll introduce you to the individuals who make up the Technical Leadership Council so you can get to know a little bit more about SAFECode and meet some of the leaders in our industry.
We’ll kick the series off with an interview with EMC’s Reeny Sondhi, who has played a key role the development in many important SAFECode projects, including our flagship paper, Fundamental Practices for Secure Software Development.
Interview with Reeny Sondhi, Director, Product Security Assurance at EMC:
Q. What is the first piece of advice you would give to someone starting a secure development program in their organization?
The first piece of advice I would give comes from our own experience at EMC going back into 2004-2005, when EMC started its own product security program. Based on what we accomplished, the most important thing I would tell someone is not to try to reinvent the wheel. There are a lot of resources that already exist when it comes to software security and creating a secure development program, both from the perspective of industry best practices as well as resources that are already available from various organizations such as SAFECode. As an industry, we must consider how we can utilize these resources to meet the needs of the organizations to which we bring the software security programs.
Software security is an art and a science and since so many resources already exist companies should be tapping into these rather than trying to develop something of their own. Organizations should also be focused on creating an end-to-end process rather than a fly-by-the-seat-of-your-pants approach, thinking that running a few tools will ensure software security. This is not the case. Software security is an end-to-end process that requires the investment in creating a program that can meet the custom needs of an organization while still using the resources that already exist in the industry.
Q. No one disputes that security engineering is critical to ensure consistency, quality and security, but where does the intention most commonly fail in execution?
The intention most commonly fails when the goal is to simply ship a piece of software or ship a product to meet a date. Software developers and software organizations are often under a tremendous amount of pressure to meet a particular deadline because customers expect a product to be out in the market to combat competitive pressures. Software security needs a proper process, due diligence and complete focus in a development organization. It shouldn’t be lower in priority than adding a feature that might give your product edge over the competition or creates more revenue. Secure development must be embedded into the DNA of an organization. It won’t be successful unless there is serious ownership and sense of responsibility behind it as a necessary, formal process. Aligning software security with how products are built should be an integral part of how organizations conduct business. It’s when companies stop paying attention to developing secure software with the right due diligence that intention fails in execution.
Q. What is the first and most important piece of advice you give a customer on how to evaluate the security of software?
Customers are becoming increasingly interested in understanding how they should be evaluating acquired software for security. That said, organizations purchasing software should never expect a guarantee or legal testament from vendors that the software being sold is 100% free and clear of any and every kind of software security vulnerability. Every software has defects and some are security related, making it impossible to make that claim.
It’s also crucial for customers to understand the overall process that vendors follow for software security and realize that it is an extremely important part of how products are developed. Personally, EMC is open to transparency into the process, which is done through our website, blog, and SAFECode publications. The goal is to help make customers comfortable in trusting that we know what we are doing when it comes to software security. Trust is a pillar of EMC’s business and product security is considered to be extremely foundational for us to be able to deliver on our trust pillar.
Lastly, with regard to advice to customers evaluating software security, they should not just be using testing tools as a compliance check to prove that purchased software is secure. These tools cannot replace vendors’ end-to-end process of developing secure software and software security shouldn’t be treated as a compliance check to begin with. Compliance shouldn’t be the goal of the process, it should be a result of the process. To that end, it is the responsibility of the vendor to build that confidence with the customer that they are selling them secure software and need to provide more transparency. On the other side, customers have to be reasonable in what they ask vendors to do as part of their evaluation. To meet both of these requirements there needs to be more open discussion of the best way to evaluate software security – a goal that can be accomplished with the help of organizations such as SAFECode and relying on emerging global standards such as ISO 27034.
Q. I imagine your day job is pretty busy – what motivates you to spend extra time volunteering with SAFECode?
As part of a large software vendor, it’s a responsibility of EMC to give back to the community and share best practices and lessons learned. Sharing our experiences enables other companies to learn from us and do better at their own software security program. Personally, I believe that being a part of SAFECode is helpful for the greater good of the software community. We will be able to build more secure software if more large vendors join the conversation of sharing development practices and take more of a leadership role in the community. We also owe it to our customers to have a dialogue with them about our practices and SAFECode provides the type of venue to voice the message that members want to take back to their customers.
Q. If you could work in any other industry what would it be?
This question is very easy to answer – I would have loved to have been a chef. The reason being that given the opportunity to de-stress myself or to do what I love doing, I love cooking for my family and friends, cooking every cuisine from around the world. I try to fuse the Indian cooking techniques I’ve learned from my Mom and Grandma with techniques I’ve learned from other parts of the world. I love that cooking provides me with a venue to be creative and see an incredible result from mixing and fusing ingredients together. It’s a very satisfying way of spending my time and if I wasn’t working in technology I would have loved to be a chef.