How to Build a Product Security Roadmap | Shortcuts
Hello and welcome back to Nucleus Shortcuts. Our topic today is What is Product Security and How to Build a Roadmap for Success, and today’s expert on the topic is Anshuman Bhartiya. He is an information security professional of over a decade. He is currently a principal security engineer at Thirty Madison, which is a healthcare company, and he’s worked for some pretty big names including Atlassian, Intuit, and Dell. Enjoy the episode!
Nucleus: How do you define product security? What does that look like in today’s modern enterprise?
Anshuman: Product security is a function within an organization that allows you to establish processes and activities, like set up tooling, security scanners, whatnot, to ensure that the customer data or information that a company’s products either store, process, or transfer is protected against unauthorized access by malicious actors. That’s a very high level overview of how we can think about it. Product security can contain things like application security, which is more focused on just applications, but I know folks use both the terms interchangeably.
Securing applications is one thing, but then how do you deploy those applications on the cloud infrastructure? These days it’s all about cloud, like AWS, Google Cloud, Azure. So, apart from securing the application, the deployment piece also, I believe, falls under product security, because you want to make sure the product is secure from the point where it’s committed, like when the code gets committed to the point it’s actually deployed, the entire lifecycle.
You wrote a great article about a product security roadmap. Why does this matter, in the context of having a successful product security program?
Anshuman: As the first product security engineer, when you are onboarded onto an organization, you have different stakeholders that you are supposed to work with. These might be your VPs of different engineering organizations. These might be your EMS supporting different smaller teams, engineering teams. It’s really important as a founding product security engineer to have your stakeholders come to a shared understanding of what the risks are that your organization faces, and what other product security engineering you are planning to do to address them and in what order. So, a.) I’m making sure everybody is speaking the same language when it comes to the risk. And b.) making sure there is a good understanding of how to address it and how to prioritize what.
How does one go about building a product security roadmap?
Anshuman: I think of the overall product security function being broadly divided into three major categories. The first one is vulnerability management, or how do you deal with vulnerabilities that you discover. Second is security partnerships, or in other words, how do you make sure you are working with your engineering counterparts and integrating security in the SGLC. Those kind of relationships or partnerships are different activities – projects you can do underneath that. And the third is security tooling and operations. This basically contains deploying your scanners, making sure that within any programs that you run, you are collecting valuable data to make sure that you make continuous progress, things of that nature.
So, like I said, each of these categories will have a bunch of activities, projects that you could be doing underneath them. It’s really important to highlight that you can’t be doing everything together at once. So, you should really be thinking about splitting the overall roadmap into a multiyear plan. It can be a three year plan, it can be a five year plan. It really depends on the resources and the priorities, and this roadmap, the way you divide it, it’s really about working on smaller tactical projects in a prioritized order, which eventually contributes towards an overall strategic roadmap of how you go about improving the security posture of your organization.
Nucleus: Contained in all those buckets is the classic people, process, and technology areas of concern. Once you have that roadmap, then you’re building out those tactical projects and prioritizing them to make sure you’re making progress on the longer term road.
In your article, you called these work streams. That’s an interesting way to break out categories of work.
Anshuman: Yeah. Based on my experience, the places where I have heard work stream being used is for, let’s say there is a big project that your company is undertaking. It impacts pretty much all the organizations within that. So, it can be HR, can be legal, can be engineering, can be advertising, sales, marketing, whatever. So really, what you need is a team of individuals that represent each one of these functions, and they are working towards this project. So you can think of it like a work stream, where you don’t necessarily have the entire teams working with you, but you have individuals representing those teams. So I think, yeah, work stream is a good way to make that sense.
Is there one most important thing you’d like folks to walk away with from this conversation?
Anshuman: I think since we are talking about product security and how to get started and how to build a program, I think my advice is to not get overwhelmed and be able to ruthlessly prioritize. I like that term, “ruthless prioritization.” Also bringing along everybody else with you on the journey, like all those stakeholders, is probably the most important thing you can be doing in order to be successful at it. And then just being very thoughtful about what to do, and when, and how to leverage smaller wins in improving the overall security strategy, and the culture. That goes a long way.
Where can people go to check out your blog and learn more about the stuff you’re writing about?
Anshuman: You can check out my blog on anshumanbhartiya.com and you can also follow me on Twitter. I’m available @anshuman_bh. You can feel free to email me. I’m more than happy to collaborate, share ideas.
