Payatu > What would you recommend as must have elements of a robust Product Security Framework?

Vikram > While building a product security framework, it is important to start with a threat assessment to ensure you’re addressing the right areas that could have a potential impact, at the same time, striking a balance between what’s necessary and what might be an over-kill in terms of security. In addition to this, it is also important to implement a process that governs each phase of the product lifecycle to ensure security is engrained as early as possible, starting from design itself. Detailed checklists of controls, awareness and accompanying tools act as important support mechanisms to the process and framework.

Payatu > What are some key areas to keep in mind while developing the threat model of a product?

Vikram > Business perspective is probably the most important aspect or understanding to have while developing a threat model in order to ensure the threats we’re assessing are actually most relevant. Apart from this, a solid understanding of the product technology and deployment mechanisms are key to developing a comprehensive threat model or conducting a threat assessment of any product. Reasons for this are simple, every type of technology, infrastructure, data stores bring their own threats to the table that are important to understand and mitigate effectively. For example, you could secure a web application or product end to end via rigorous assessments in a pre-production setup, but all you need is a poorly configured S3 bucket in it’s production deployment to cause a data leak!

Payatu > Product leaders sometimes have to de-prioritize security risks to meet business demands of a faster time to market. How would you recommend leaders balance the need for speed without security tradeoffs?

Vikram > It’s common for security leaders in progressive organizations to be faced with this discussion, and it’s an important one at that, after all security should act as a function that “enables” business in a secure manner. It is important, in such situations for security leaders to place the security risks in question in a business friendly manner and wherever possible, accompanied by it’s business impact – if it were to go south. At the same time, implementing compensatory controls are a great way to buy time in the event a security risk is de-prioritized for business reasons. However, there are some security risks, that would always be non-negotiable, and these should be called out clearly with associated business impact.

Payatu > What are some of the best practices of aligning product security teams to work closely with an engineering organization?

Vikram > As I mentioned earlier, it is integral for a product security function, to align themselves at each stage of the product development lifecycle to ensure vulnerabilities are flagged as early as possible. As “left” as you take this, lower the cost to fix an issue, the same is true for any bug, not just a security bug. Again, it is important for the product security team to act as a “consultant” to engineering teams during the SDLC constantly working together and suggesting ways to design and develop products in a secure manner. This might not always be scalable, hence it helps to devise a set of checklists or guidelines that could be made readily available to engineering teams with the same objective. Awareness is another important aspect in this discussion, where it helps to conduct sessions with engineering teams, these should not be generic, but specially curated with content specific to the product – such that the team can relate to the issues and if they’re passionate about their product, they’ll most likely not induce the same security bug again 🙂

Payatu > Product security cannot prevent or fix all software vulnerabilities. Do you agree with the statement? If it is true, what would you recommend are some of the best practices to seamlessly align product security and incident management.

Vikram > Known fact: automated vulnerability testing is only half as good as a human ethical hacker. And unfortunately, one can’t hire too many! There will always be bounty hunters or black-hat hackers out there who will end up finding something that your tools or ethical hackers haven’t yet. And what’s worse, if one keeps worrying about that and not acting on how to identify and respond to such attempts, that gap is only going to widen. Even before incident management, I would suggest one tries out crowd-sourced ethical hacking or “bug bounty”, where a number of “hackers” are actually hunting for your own good (this has it’s own caveats, not getting into that right now though). At the same time, it is super critical to monitor what’s being missed out in terms of vulnerability identification, and hoping the same is caught before it’s too late. Incident management is often a function that deals with standard threats whether network or endpoint, but if an organization could align the incident management team to understand product or application threats and create use cases, monitoring rules etc around the same, it would help bridge the gap to an extent. Though it is important to detect an active threat, it is even more critical to act quickly to contain the same, and when incident responders actually understand applications and threats associated, it would accelerate the process.

Payatu > Is there an ideal ratio of product security engineer to product engineers?

Vikram > I would say there is no such thing as an ideal ratio here, it is purely a factor of business priorities, risk appetite and technical know-how of both engineering as well as product security teams.

Payatu > Do you recommend the use of Automatic Vulnerability Testing, Fuzzing tools? Help us understand the human element vs. automation in product security.

Vikram > Absolutely, automated testing helps detect certain types of vulnerabilities fairly early in the SDLC, which can scale unlike manpower. Human ethical hacking is something that still holds a significant place in a product security lifecycle, but has it’s own limitations as well. Hence it is important to strike the right balance, for example, automated testing should be used as a tool to reduce the manual effort an ethical hacker has to invest to find vulnerabilities. At the same time, it is important that the tool is efficient both in terms of performance / speed and accuracy, else precious time would be spent in maintaining and reviewing the same.

Payatu > Can you share your insights for an aspiring product security engineer? What does a career in product security engineering look like?

Vikram > Information security in general is a very exciting domain, and product security, ethical hacking probably top the list within! Ethical hacking in my opinion forms the base of a strong security career. And here why I firmly believe so, if someone knows how to hack, he or she mostly likely would know how to protect applications well too. Not just applications, but networks, infrastructure as well. Once you’ve had your share of ethical hacking, you could spin your career in multiple directions. Bounty hunting to take your skills next level, incident response, information security management, forensics, the list goes on…

Payatu > What has helped you the most in your career as product security leader?

Vikram > There are many aspects to talk about, but I would like to mention automation and engineering development here. Organizations today are looking to solve problems, but they’re also looking to solve these quickly and sustainably. I’ve maintained a similar outlook within various job roles, constantly looking at technology backed solutions to address security requirements efficiently and at scale.

Payatu > Please tell our readers a little bit about yourself? How do you enjoy your time when you are not keeping products secure?

Vikram > I possess a never-ending thirst for automation and get restless when things are too quiet 🙂 We’re constantly looking for ways to either “up” our game in the threat detection space (which is a constantly evolving landscape and super interesting) or we try and build security products of our own at MMT to make our lives easier, hackers are a lazy bunch by design 😉