Camille Morhardt 00:55
I’m Camille Morhardt, host of InTechnology podcast, and today I have with me Vernetta Dorsey Windsong. Vernetta is Director of Product Assurance Security Governance at Intel Corporation and I’ve worked with her for a number of years now. Very impressed with her on personal and professional level. So really looking forward to the conversation today.
Vernetta Dorsey Windsong 01:16
Thank you. I’m happy to be here.
Camille Morhardt 01:18
So define for us product security. Well, I guess you have to define product security before you define its governance really.
Vernetta Dorsey Windsong 01:26
Sure, so product security- when people talk about cybersecurity, right, you automatically think about networks–IT defending your network from malicious acts and all of those good things. When we talk about product security, we’re talking about what are the things that make up your network, right? You have devices, you have a computer, you have a server, you have all of these things. How we build those is product security. Making sure that we design them with security in mind, that we proactively use one open source versus another one because of better security principles and understanding what are the potential threat actors. So product security is that development of your product with security in mind, so that you build a better product that gets in that then gets put into those networks and things that from a cybersecurity, you see people are protecting, right.
And then governance, from an organizational perspective, is we have a product security assurance program, and we set certain requirements, we follow certain rules, we tell people, “hey, please do this thing and not that.” And the governance of that–are we tracking the right things in industry? Are we tracking the right requirements and regulations? Do we have the right coverage? You may have interviewed some folks who’ve talked about different compliance aspects, maybe FIPS, or SOC 2 or different NIST regulations, right? So if these are things that we need to follow, are we following them? How are we following them?
As Intel, you know, we created this thing called the Security Development Lifecycle. And so we asked our people to follow this. The governance then says, “Okay, how do we check and track that it is being followed? Is it effective? And if it’s not effective, what do we do to make it better? How do we make improvements? How do we add things as the industry and the landscape changes based on new threats? AI, it’s coming in multiple levels. So how do we, how do we look at that? How do we use AI? And how do we govern AI in our product; so the landscape is always changing. So we always want to make sure that we’re able to understand what it’s going to take. So governance is, what do you say you’re going to do? Okay, are you doing that? And then how, how well, and what can you change? Right? So we look at our SDL, Security Development Lifecycle, and then we also look at what requirements are we telling teams to do. And have we done the right diligence on that? So it’s kind of like an internal focus to our iPass group, and then an external focus to the execution of what we’re asking people to do.
Camille Morhardt 03:58
Is it more of a sort of practices and processes that you monitor and track? Or is it like the end result/end goal and product? Do you know what I’m saying? Do you have a measure for the product itself? In the end, other than I suppose, does it get hacked? Right, once it’s out in the market?
Vernetta Dorsey Windsong 04:15
Yeah, so it’s both actually. So when you look at the practices and processes, so on my team, we have an exception process. So we tell people, “hey, you need to follow the security development lifecycle, because it has all these requirements based off of certain rules that you should apply based off your product or service based off what you said you’re going to do,” right? So if a team doesn’t or can’t meet a certain requirement, they have to get an exception. And so then we can track by our products and services, how many have exceptions? what type of exceptions they were, because sometimes you can say “I can’t do it right now, but I’ll fix it later.” And then there’s times you say, “I won’t be able to do it at all.” So that’s one factor.
The other factor is that we look at assessments, a risk assessment in general of some of our products and services of how well they’re doing. So to your point, like think about it for mergers and acquisitions, if we’re going to acquire some company that already has an offering some type of product offering out there, how do we know from a product security perspective, that it’s fitting into what we expect? So we do assessments on that, and then have get well plans to get them to that place. So it’s a little bit of both of during the process of development. And then after at the end, there’s assessments we can do to check for that how well it is.
Camille Morhardt 05:26
But you’re also, in some senses, you’re kind of an auditor of what a product group is doing. So who audits you?
Vernetta Dorsey Windsong 05:34
(laughs) So another great thing about a governance team is that I say that, we should know where our holes are before anyone outside–whether it’s Intel audit or another outside, if you get like a Deloitte and Touche or someone else, an outside audit agency. If you have a robust governance program, you should not get any surprises from any external body. Because you should have methods in place, things that you’re tracking, engagements with your customer, so you understand where the weaknesses are, what’s going on to fix them. And then when you do get an external audit or review, you are able to know. Shouldn’t have any surprises. That’s our goal.
Camille Morhardt 06:11
Okay. What advice do you have for maybe it’s a smaller company or a new division in a bigger company trying to wrap their hands around for product security. Like where do you start?
Vernetta Dorsey Windsong 06:25
So, I think from a product security perspective, if you want to make sure you have good governance, you want to make sure you have data and metrics. As you as you build your capability, understand, what are you building; so if you’re, if you’re building out a requirements set, maybe you’re saying, “Okay, the first thing I can do as a small company is I can at least make sure that everybody understands what the requirements are, as we build our products or services.” And then you can monitor, you can monitor the usage of that tool, you know, from a requirement perspective. You want to be able to monitor and observe how your company or your unit is using the requirements, but using the tools you’re putting in place. So if you say, “Hey, I can build requirements. I can’t control some of these other things. But I can control the requirements set.” Then build metrics off that and track that. And then as you get that into control, then you can build another piece that you’ll be able to use. So I would say take it piece by piece instead of trying to just do everything at once. Because that will overwhelm your teams, and they won’t be able to actually complete the goodness that you want them to.
When you’re thinking about rolling out a new initiative or something, a new product, with governance, I say always thinking about the culture of your company, the communications and the change that you’re asking them to do. Because that will allow you to govern the process early on, and not have to play catch up. And that’s something that is useful in getting traction. Because governance is also like you said, we do a lot of audits, we do a lot of reviews. People tend to think, “Oh, it’s just compliance.” But from a product security perspective, I believe that it’s a way to enable faster time to market and faster and better quality of product.
Camille Morhardt 08:12
So I think you were alluding to this, but I want you to touch on it a little bit more explicitly, like what are the areas when you’re rolling something out and you’re dealing with product groups that I mean, no matter what the company, they’re trying to go fast, and they’re trying to get, you know, something competitive out in the market. So what are the typical bottlenecks or roadblocks or issues you come up against? Or what are the areas where you have to say, “okay, you know, here’s the places that we could run into resistance or run into just challenges?”
Vernetta Dorsey Windsong 08:44
I think a lot of it is mindset. When you think about product security, a lot of people don’t think about it early enough. So training, awareness of understanding of what’s going on. Because when I talked to different developers, kids in college and I talk about if you can think about what can someone do bad with your product, right? What’s the worst they can do? And then design for that change, change your design so that you’re eliminating that. Thinking about that differently in the beginning helps. And so that is probably the biggest bottleneck, because until that light bulb comes on for them, people think it is just something that someone else is telling them to do. But once you understand that it’s going to help you, and it can either be a competitive advantage or just make sure you get the right product out the door without having lots of issues after you release it, that change of mindset typically helps the most for me.
And then getting the right tools understanding where you go a click down, what are you really trying to do? And what is the what is the way to track those metrics and use the tool that is the least intrusive to what you’re doing; don’t just get the tool that says “we do all of your products for you to governance in one slide” and it gives you all of this tech dev, because you don’t actually need all of those things. So go for the smallest piece that you need to make the biggest difference, monitor it, get your data, and then go from there.
Camille Morhardt 10:11
Well, that makes me want to ask a question about automation and various tools that go into practices like and I know, I had you on a couple of years ago on Secure Development Lifecycle. So there is a podcast out there that talks about what is the secure development lifecycle. And of course, Intel applies that on the hardware side, as well as the software side. Can you automate various kinds of tools within a secure development lifecycle?
Vernetta Dorsey Windsong 10:39
In any type of pipeline delivery, you can automate it, right. So if you have a continuous integration, continuous development software platform, and then there are some hardware aspects, not as much, but there are some things that you can put into your tool chain that will give you early warnings. And again, you can automate from a software side a lot; you can automate your requirements, you can automate your code check-ins, you can automate the responses to that, as well. So you can track again, from a governance perspective, I might want to know how many times do we have bad check ins? So because that might be an indicator that we need to ramp up our training? Or, what do we do before folks touch code, right, if we’re seeing a lot of stoppage of work, because the check in didn’t go through because they had these types of errors. So the governance really, I think, is really around data management using that data to have informed decisions on what you need to tweak next, or what’s the thing that’s hampering you the most.
From a secure development lifecycle perspective, we can pull data on what kind of projects are being registered based off of the survey. And then that can help us inform us, do we need to update any certain types of requirements? Are we seeing an uptick in these types of projects? This all helps, again, from a continuous improvement perspective, to hone in on the areas that your business may be focused on. So because you don’t want to do over. No one has time for that. Right? You want to focus on the piece that is going to give you the most return on your investment for your governance program.
Camille Morhardt 12:13
Do you see governance programs in industry actually implementing AI as a part of that continuous improvement or AI to help them discover options for it?
Vernetta Dorsey Windsong 12:23
Yeah, that definitely is part of the conversation now, because especially when I’m talking about data, I’m talking about analytics. And anything that helps us go through data faster, more accurately, can learn with the assistance of some human glue, just makes your program better. So that’s definitely something that most programs are looking at if they haven’t already.
Camille Morhardt 12:43
So one other question is, how do you get continuous feedback from- like, if you discover a problem with a product later that of course, you missed, right or the process missed, how should companies look at building that back into their processes?
Vernetta Dorsey Windsong 13:01
Right, so, first understanding where it came from, right? So if it’s something that was missed, and you should have found, you can analyze, oh, that we had a checker for this, but somehow it didn’t pick this up. And you just have to do the retrospective for that and then you can update your requirements for your automation. Sometimes what happens out in the field is something new. This is another reason to use AI, right? Because then you can add that into the learning model that “hey, this is something new.” From a security perspective, you’re always going to have something new, something novel that we don’t know about, but you want to rid the normal and the routine things that you can.
And so we’ve done, well, something like a key learning or something where you say, “Hey, what are our misses? What has been released out into the world that we could have prevented?” And then you just have to go through this process of a retrospective to understand what part of the system failed. Because sometimes it’s training, sometimes it’s miscommunication. Also, we need to clarify the requirement. And then other times, it’s, “Hey, this use case didn’t actually exist in the space before.” So we have to create that and plan for that.
I don’t know if there’s some automatic way; I still feel like that’s a fairly human process. But you need to have a process–and that’s part of the governance, so you need to have a process to look at that, because that becomes your self-improving mechanism that says you didn’t just do something once and put it out there. You understand that it’s a living environment that changes.
Camille Morhardt 14:34
How do you prevent scope creep, or governance creep? Like you said, nobody has time to do more than what’s needed and nobody has, nobody has time to not do what is needed, right? Because you don’t want to have a problem hit the market that you could have solved. So how do you balance that? I mean, it seems like the more you know, the more governance there is, the bigger the process, the heavier the lift. So I’m just wondering how to address that.
Vernetta Dorsey Windsong 14:59
So part of that is making sure that, again, you’re intercepting at the right time. There’s a lot of things that happen if you wait too late, and it gets really bloated. Reason what I mentioned before about designing with security in mind, if you can do it early on and make it more of a pull than a push process; if my governance is more because people are asking what do they need to do differently and they’re thinking about it, then it becomes less of that overhead piece. I see a lot of the bloat where if you will, on governance, because people either don’t know so they get farther down the road, and then they get hit with you have to do all of these things, right, that we’re tracking, and they didn’t know about it. And so most people, if they can plan for it, just like any project management, right? If you can plan for it, it’s not a big overhead because you’re running through the system.
And then the other part to that is also just you have to set time for retrospectives looking at what’s working and what’s not, you may have thought this would be a great governance add to track this certain thing by causing people to do X, right? But if it’s not providing any value, you’re not getting real data out of it, then you have to cut that out. And so you have to have some type of process where you’re looking at what you’re doing. That’s why I said there’s two pieces: there’s the external to your customer, like where you’re tracking that, that work of where you set the metrics up, and then you also have to make sure you’re looking at why are we using this requirement? Why did the body that sets the requirement pick this? And do we need to change that? Right? And that’s how you try to reduce the bloat from what you were saying as well.
Camille Morhardt 16:31
My last question. What’s your favorite part of your job?
Vernetta Dorsey Windsong 16:35
My favorite part of my job, actually, it is my team. I love my people, they do great work. And I love when they succeed. I love when they get kudos from my boss and my boss’s boss, because they just knocked it out of the box. And that and when they’re in it, and when it’s because they push themselves or I asked them to do something they didn’t think they could do. And they nailed it. That’s the best part of my job. And I love seeing people win because then we all win. Right? Everybody wins and people are happy and that’s really the best part of my job.
Camille Morhardt 17:04
Vernetta Dorsey Windsong who is Director of Product Security Governance at Intel, thank you so much for joining us today.
Vernetta Dorsey Windsong 17:11
Thank you for having me.
