Brad Arkin has been in software security for about as long as software security has been a topic. He helped build the software security practice at Cigital (now part of Synopsys) in the late 1990’s, was a technical director at software security consultancy @stake (later Symantec), spent 12 years in product security at Adobe, ultimately as Chief Security Officer, and is currently Cisco’s Senior Vice President, Chief Security and Trust Officer.
He joined Rohit Sethi, our CEO, on our podcast channel The Balancing Act for our Leaders in Security series. The Balancing Act regularly interviews software security practitioners to discuss the challenges they face in securing their products and environment and balance the need for both security and business requirements.
Here are some key takeaways from the podcast. You can listen to it in its entirety here.
1. Brad is a mathematician at heart
He majored in computer sciences at George Washington University “because I figured it would help me get a job”. He discovered a copy of the first edition of Bruce Schneir’s “Applied Cryptography” during an internship after his freshman year and found the perfect opportunity to combine the two. His first job at Cigital was focused on cryptography topics before pivoting to software security with Gary McGraw and John Viega.
2. He has seen the evolution of software security from the beginning
In the late 1990’s when Brad was starting his career, security wasn’t on the radar of most organizations. Companies were focused on producing features and security added cost and time to the process. Many at the time viewed it as “a wasted resource”.
Organizations now are acutely aware of the need for security but can be challenged by multiple priorities. In Brad’s words, the question for security leaders today is “How can I invest resources in a way that’s going to actually move the ball and make me and the people that rely on my software safer over time”. It requires discussions and buy-in from engineering, senior leadership, and security. He doesn’t pretend this is a simple problem and understands the desire to do “something” doesn’t always lead to the correct decision. “I think there’s a lot of activities which naively might seem useful, but they’re not actually productive and making the code more secure.”
3. On meeting customers’ security expectations
Whether the product is shrink-wrapped software, a physical device, Software as a Service, or on-premises, today’s customers expect software to be secure. The problem, Brad explains, is that their expectations are “not always communicated explicitly. They just expect it to be secure”. When it is not, relationships can be damaged and trust difficult to reestablish.
The answer is better communication, in particular if there is a security event. Brad argues for a “no holds barred, honest postmortem about what went wrong, what we are doing differently next” involving the customer and internal teams. Discussions such as these allow teams to “prove you’re working at it and you’ve got a plan”.
4. The role of certifications in security
Brad believes the industry will see more domestic and international standards adopted. Today, the value of certification may be only as reliable as the company’s efforts and the quality of its auditors. “Some organizations are doing great work. Their controls make sense. The way they’ve implemented it makes sense. [They have] third party attestation where these folks really did a good audit.” While others may have poor controls and questionable auditors. Both, however, have certification. For less experienced customers “it’s hard to tell which [certification] is gold plated and which one is really tarnished.”
5. How to start a product security program
Organization’s taking their first steps in building a security program have lots of choices. They key is a leader who is “centrally anointed” by senior management. Next, you need “Embedded security capabilities within the engineering teams that are actually building the product for the customer.” These two teams “…mutually own the security roadmap of activities”.
Next is the discovery phase to identify “relevant security and technical debt within a code base. And then once identified, how do you prioritize and stack rank the different items of improvement that you can invest in that would address the technical debt at a pace commensurate with the risk it represents for the business.”
6. Why CEO and Board relations are critical
Not every security leader reports to the CEO, but Brad believes a good relationship with the CEO – and Board of Directors – is critical. Businesses often engage in a series of tradeoffs between security and business needs. Security leaders need the ability to have an “out-of-band escalation channel” to the CEO and Board about risks and benefits when they believe bad security decisions are being made.
7. Security’s role in the organization
Sometimes conversations with the CEO or the Board will result in the product shipping anyway. This leads to a better understanding of an organization’s appetite for risk. After all, security’s ultimate role is to help achieve business goals. In Arkin’s words:
“If we were to just sit with our back to the customer and do security work all day and not worry about customer problems or the other things the customers want to buy, then that’s not really the point of why we’re all here together. So you have to start to balance security with everything else we’re doing.”
Listen to the full podcast here.