Skip to content
InTechnology Podcast

#49 – What Than Means with Camille: Secure Development Lifecycle (SDL)

In this episode of What That Means, Vernetta Dorsey, a Product Security Staff Engineer at Intel, and Diana Carroll, a Product Security Expert, get to the heart of the secure development lifecycle (SDL) with Camille. Whether this is a brand new topic to you or you’re looking to scale up your existing SDL, they give fantastic insight across the board.

 

We cover:

  • What the secure development lifecycle is and why it is so essential to get right from the beginning
  • Why forward-thinking, integrated partnerships are meaningful when it comes to SDL
  • How someone might effectively go about scaling up a secure development lifecycle across an organization
  • Additional support systems and processes to consider for your secure development lifecycle
  • The similarities and differences between SDL as it applies to hardware and software

…and more.  Check it out!

 

The views and opinions expressed are those of the guests and author and do not necessarily reflect the official policy or position of Intel Corporation.

 

Here are some key take-aways:

  • A security development lifecycle (SDL) is what companies in the industry utilize to make better products.
  • SDL is most effective when security attributes are incorporated from the get-go. However, even after your product has been released, you still need to focus on maintaining it due to the ever-changing nature of the industry landscape and emerging threats.
  • It’s crucial to know how long you want to support your product so that you can adapt as needed.
  • Companies should always be thinking about worst-case scenarios to prevent them from happening.
  • It’s important to form an integrated partnership between those developing the products and a security or product assurance organization so that no detail goes overlooked.
  • Automation can be a great labor-saver, but that doesn’t mean AI can do everything for you, and you have to be sure you’re putting in the proper maintenance.
  • Scaling up a secure development lifecycle should be a gradual and collaborative process because rushing it, especially if people aren’t aligned, tends to go poorly.

 

Some interesting quotes from today’s episode:

When we talk about the security development lifecycle, we’re talking about certain attributes, assessment tasks or activities that one would want to include in their product development lifecycle.”

 

“One of the things that we’ve learned over the years is that it’s much easier and more cost-effective if you start incorporating your security attributes in at the beginning, rather than trying to tack them on later, after the fact.”

 

“We find the most issues when people don’t think about the ultimate, the bad case. And that’s why it’s critically important that this fits within the actual development and engineering teams.”

 

“Nobody knows a product better than the people that are building it. And that can be their biggest strength. And sometimes a weakness too, because the thing about not seeing the forest for the trees kind of comes into effect. Sometimes somebody is so focused down in the details, that they need somebody to help them zoom out and look at that bigger picture, that broader forest, of how it needs to interact with all these other parts of the ecosystem.”

 

“Automation can be very valuable. Because from a developer’s perspective, or a validator’s perspective, I would often find myself in the spot where if I had to do something more than two or three times, I would rather write a script to do it for me and focus on something else.”

 

“One of the things I have seen is when somebody builds out this great automation system, and then they don’t maintain it for a few years, it can go from becoming a great helper to a handicap.”

 

“If you don’t have that expertise in-house, today, there are places you can go to help build that out.”

 

“If you try to go from zero to 100 miles per hour all at once, it’s going to be a shock to the system. And that’s often tended not to go so well. I would say pick a place to start and focus on incrementally adding and improving and expanding the scope of what you’re doing.”

 

“You have to really know your company culture, know your development engineers, to understand which lever you would need to engage and to get everyone on board to where you want to go.”

 

“If you don’t have the validation systems, and the ability to update products after you’ve shipped them out, or things like that, that impacts not only your overall quality, but also your ability to respond and improve your security and products as well.”

 

“It’s really important to get your architecture right because once you burn something in, you can’t fix it, versus the software where you have the capability to make updates and changes much later in the process.”

 

“Regardless of whether you’re talking hardware or software, or even different types of software, context is key.”

 

“If we’re not thinking about it, that means the hackers or the bad actors have more opportunities to take this thing that someone’s making for the good of humanity and use it in a way that was not intended.”

Share on social:

Facebook
Twitter
LinkedIn
Reddit
Email

Announcer 00:01
Welcome to what that means with Camille Morhardt.

Camille Morhardt 00:05
So Hi, and welcome to this episode of What that Means. Today we’re going to talk about secure development lifecycle with Vernetta Dorsey, who’s a product security staff engineer at Intel. And with Diana Carroll, who’s a product security expert. Welcome, Diana and Vernetta.

Vernetta Dorsey 00:23
Thank you.

Diana Carroll 00:24
Thank you.

Camille Morhardt 00:25
First, I’d like to kick it off. Can you each or can you combine them together define in case somebody doesn’t actually know what it is secure development lifecycle? What is that?

Vernetta Dorsey 00:37
When we talk about the security development lifecycle, we’re talking about certain attributes, assessment tasks or activities that one would want to include in their product development lifecycle. It’s been around for 10 plus years and industry companies, take it massage it make it their own for what their specific processes include, but it’s something that they’ve been trying to utilize to make better products. Diana, what would you add to that?

Diana Carroll 01:03
It’s all about building product security in as part of your product development processes. Because one of the things that we’ve learned over the years is that it’s much easier and more cost effective if you start incorporating your security attributes in at the beginning, then trying to tack them on later after the fact. Or even worse, to try to do that, after it’s been out in the market and an issue has been found.

Camille Morhardt 01:35
So if that’s the lifecycle you’re talking about, beginning at design, where does it end,

Diana Carroll 01:42
Even after you’ve published it, or deployed it or whatever your word is, you’re still needing to keep it up to date to maintain it, for the life of the product.

Vernetta Dorsey 01:53
That lifecycle includes the industry or the landscape changing. So you want to make sure you incorporate that in your planning at the beginning of how you will be able to do that it’s very important to keep that in mind as you’re creating or building your product. Because that will impact how you support and how you can respond to different things as they come up.

Camille Morhardt 02:12
As people are doing different use cases with the product you might have released five years ago, you have to be ready to adapt or as new vulnerabilities are discovered or as new threats are emerging. Exactly. Is STL, or secure development lifecycle commonly abbreviated as STL. Is it like a group of people? Or is it a set of processes or a package of tools? Like what does it consist of?

Diana Carroll 02:43
Ultimately, it depends on what you’re developing. That drives a lot of what’s going to be in scope as far as those processes and tools and solutions.

Vernetta Dorsey 02:53
It can vary significantly across industries. But the intent really is to understand your development process, whichever one you use and integrate certain security assurance activities, task tooling, to ensure that the product that you actually release has a certain level of assurance based off what you know, at the time that you release it. And with the flexibility to understand how you’re going to update or change as the industry and landscape updates and changes through the years. Again, it’s another really important reason to understand how long you want to support your product. What are the impacts and implications to your customers, and understand that as you roll it in, in the process.

Camille Morhardt 03:33
Product development per se, may occur largely outside of a security or product assurance division at a company, you’re talking about incorporating these processes and tools and principles from secure development lifecycle, perhaps monitored or initiated out of a security assurance or product assurance group, separate from the product division that’s building and designing the products. So how do those integrate? How do the two organizations work together? Just generally, in a situation in industry?

Vernetta Dorsey 04:07
Have some strong feelings about that question. So Diana, do you want to go first? Do you want me to start? I’ll let you go ahead. Ideally, in Nirvana state, you want this integrated into your development process, the outside agency should really just be in your guard rail should really just be the thing that makes sure that the things that you have set that are part of how you make your product, your service, your whatever, is integrated in a way that makes sense. That outside agency really just wants to make sure that you have a good view of the landscape, you have a good view of your industry, and that you’re using the things that are appropriate in the space that you’re in. But you want those practices, those activities, those tasks, to be part of what your day to day engineers or developers are doing. Because we want people as I said before, to create to plan things about not just is this function in the way I want it to, but also to look at what is the worst thing someone can do with this just in general, because that’s where we find the most issues when people don’t think about the ultimate, the bad case. And that’s why it’s critically important that this fits within the actual development and engineering teams. From my perspective.

Diana Carroll 05:23
It has to be a partnership, because nobody knows a product better than the people that are building it. And that can be their biggest strength. And sometimes a weakness too, because the thing about not seeing the forest for the trees kind of comes into effect. Sometimes somebody is so focused down in the details, that they need somebody to help them zoom out and look at that bigger picture, that broader forest, of how it needs to interact with all these other parts of the ecosystem.

Camille Morhardt 05:57
Are there typically two sets of things in product development in tech, do you have a product development lifecycle, and then separate from that is a secure development lifecycle. And somehow they come together where needed, or you were mentioning full integration for net, I’m not sure.

Vernetta Dorsey 06:16
You start to get a bit of diminishing returns if you have separate set. Because if the developer and if the engineer doesn’t want to break their product, thinking how the adversary might in the field, because again, as Diana stated, they know their product best, they know what they’re trying to do. So they also need to try to make sure what they don’t want to happen is incorporated, that needs to be included in the lifecycle. So if we’re talking about software, then you can think of things like DevOps, we have set DevOps, we’re integrated along that tool chain of how they perform DevOps, there’s certain things that are security modules to do scanning checks, different models, you turn on and off. And that is right at the development space that’s not separate, that’s integrated into what they’re doing. And that is critical from a perspective of how we make sure that we look at the right approach. That’s what I was trying to say. So if you have a separate organization, you want them to be looking forward looking, again, what’s going on in industry, what’s going on in the landscape, what are the next big things that we need to incorporate today in that toolset that the developers and engineers are using, that’s where that spotty really brings to bear the benefit of having that significant knowledge. Because then they can update the toolset, update the requirements, but you want the developers and you want the engineers to try to be using that on their day to day, and you want them to try to break what they make all of that kind of thing on a day to day basis.

Camille Morhardt 07:47
Looking ahead at what’s coming and making sure that you’re getting the right kind of security tools or checks or processes into the developer area. So it’s fully integrated for them. They’re focused on product and requirements. And you’re focused on what they’re going to need to know to make sure that the product is secure. Ultimately, a couple of things I’ve heard floating around in industry now, when it comes to these kinds of processes and tools are automation. And also artificial intelligence, which I think sometimes AI gets kind of thrown around. It’s like the new blockchain, anything you’re working on, how are you doing AI. So I would be curious as to your guys’s take on those two items, automation and artificial intelligence and how they work relative to secure development lifecycle.

Diana Carroll 08:42
Automation can be very valuable. Because from a developer’s perspective, or a validators perspective, I would often find myself in the spot where if I had to do something more than two or three times, I would rather write a script to do it for me, and focus on something else. Automation can be a great labor saver when you’ve got automated test scripts, for example, that help make sure that you haven’t broken anything with your latest upgrade. But you also have to remember that automation and even AI isn’t going to necessarily be able to think for you. It can be great for helping you keep you from having to do repeat, work over and over again and let you move your focus to what’s current. And now, but it doesn’t mean that you don’t need to continue adding test cases improving it building on it, because the security landscape changes fast. There’s always new things coming up. The hot thing of a few years ago is obsolete today. And one of the things I have seen is when somebody builds out this great automation system, and then they don’t maintain it for a few years. It can go from becoming a great helper to a handicap.

Vernetta Dorsey 10:00
I think Diana is that spot on, I was simply to add that, as we’re in the midst of the 21st century, we know technology and Dilantin, fernet, change and even more rapid pace. So using automation and AI as tools to enable you to go faster within this 3d landscape are the key, but you have to maintain it, you have to stay abreast of it. But it will help you gain those insights of where to go. And when to go in a certain area.

Camille Morhardt 10:27
I’m thinking of some organizations who may not even have a secure development lifecycle established or it may be more nominal, as opposed to a process that’s mature and expected of all products. How would somebody who’s trying to scale this out or ramp this up across an organization? How do you go about that? Is it just kind of mandating that it be done? Or are you trying to build partnerships? Are you showing the value somehow? How do you kind of convince the rest of the organization or maybe your peers who are in business units to adopt it? Or how do you make it easy to adopt.

Vernetta Dorsey 11:08
There are a couple of different thought processes and ways you can garner folks interest and an earnestness about this topic. One of them is to show that there are in fact holes and gaps in a product, we can do that by having some type of hackathon, if you will, to show where the areas of opportunity to improvement and once you show folks that, hey, there are areas of opportunity in the existing thing that you already are working on, then you can talk about, okay, let’s go back to how we think about these things. What are the things we need to consider, these are some tools you can use, there’s some open source tools, again, for scale, and scope, you can use them things that are already existing in industry, there are companies that focus on this type of work that you can come in, have them do some work on your particular product, they’ll give you a path to say these are the things of issue. And they’re consulting firms that you can enable as well. And then use them to help you set up your programs based off your scale your scope in your industry, it’s not a one size fit all. And if you don’t have that expertise in house, today, there are places you can go to help build that out.

Diana Carroll 12:14
It’s always a journey. If you try to go from you know, zero to 100 miles per hour all at once, it’s going to be a shock to the system. And that’s often tended not to go so well. I would say pick a place to start and start somewhere and focus on incrementally adding and improving and expanding the scope of what you’re doing. If you’re starting out initially with just picking a tool, a static analysis tool, for example, or a port checker or something. And starting off with, okay, what does this tool find that maybe we can fix or clean up or improve? start there, you’re not finding so many good things there, you’re getting used to running that tools and add another one, there’s a lot of different ways you can start. Potentially you start with training, you’ll bring in a consultant to look at where you could shore up your processes and improve that sort of an approach. There’s a lot of ways to do it. The key is to start somewhere and commit to making it an ongoing effort.

Camille Morhardt 13:15
What is the one thing that you need as part of your STL? Or you don’t really have an STL?

Diana Carroll 13:22
The first step is you really need to sit down and think about where am I? Where do I want to go? And what is my plan to get there.

Vernetta Dorsey 13:31
If you’re the decision maker that can say I want this for my company, perfect, you need to commit and then say, Hey, we’re gonna start this journey, that commitment, and then your plan, you just bit by bit, you’ll get there.

Camille Morhardt 13:44
The other thing I’ve heard in the past is that if you don’t have hard gates, or basically teeth as a part of your secure development process. In other words, as the product moves through it, there’s various checkpoints or milestones. And if waivers are too free flowing, then nobody will really adopt there has to be a consequence, there has to be a stop ship. What’s your take on that?

Vernetta Dorsey 14:11
I think that’s a perspective based off of an environment of how people behave in a certain environment. Because if you give people the opportunity, understand why you’re doing anything from the top down, and you have that actual commitment, and follow through from the leaders of an organization. It’s not this thing that will just go through milestones, because a lot of companies aren’t built like that. The culture within the company, the people that are there, they commit to a thing once their leaders show that, hey, this is important. If you have a hackathon or you have a consultant comes in, they show you hey, these are the areas and this is how it’s impacting what you’re doing in your industry. I believe that’s a very company culture based statement. And there are other places out there that come in with, we want to have the best product no matter what. So what do I need to do? Show me Is this the tool that I need to use. So you have to really know your company culture, know your development engineers, to understand which lever you would need to engage, to get everyone on board to where you want to go.

Camille Morhardt 15:21
I’m hearing you say kind of like a partnership in the sense of know, your organization. And if that’s showing them that their product they’re building right now has a potential hole to get them engaged, or if it’s a mandated thing. For note, I know you were an army officer before maybe that’s a military culture, we’re going to do this now. And that’s all that has to be done. I don’t know.

Diana Carroll 15:46
I’ve seen that a lot in IT organizations, from I was in it years ago. was they Okay, they set down the law, so to speak, this is what you’re going to do now do it. That doesn’t work as well, in some other organizations. The old saying about the carrot and the stick, you know which one motivates the mule to go forward. Some organizations really do respond better to a carrot, you can have a developer spend 15 minutes checking that boundary and a function while they’re writing the code. Or a you can spend months and $15 million fixing a buffer overflow in your product next year. Sometimes the carrot showing them why it’s important to do this before prevent these kinds of defects before they make it into the marketplace can be more effective than a thou shalt do this. On the organization. I want to make sure that I’m clear here, I thoroughly engaged with the have a hackathon have a consultant come in and do an assessment of where you are today. But you need to know your organization to understand what is the motivation of your organization, if you have cultural concerns within your organization, you know what you need to do to get a shift, if you have all the folks that say, hey, just show me why what we’re doing right now doesn’t work, then you’ve consulted to get that act on you show them they’re like, okay, we’re ready to do this, we see that this is something we can do better. If your culture is one that you have to do a little nuance, you need to add something else to that mix, then that’s the fact. But you do have to understand that and you might have to do a little bit of work to truly be aware of which is the right level, you’re going to need to.

Camille Morhardt 17:25
What kind of other support systems or groups or processes Do you need in place in your company or organization to support SDL? Like I’m thinking of product security incident response team or other kinds of things that might have SDL is a very internally focused operation, except for like you’re saying, looking ahead at potential trends, but what other kinds of organizations or things would you want to set up if you’re interested in doing that?

Diana Carroll 17:58
So there’s a lot of organizations at Intel that I sometimes refer to as fellow travelers, because there’s a lot of places where what we work on and focus on intersects. Privacy is one of those, because security and privacy kind of tend to interlock and a lot of cases, sometimes regulatory comes in with those things, regulatory requirements. And of course, there’s a lot of quality aspect things. And that includes learning from escapes, whether they’re customer reported incidents, those types of things. P certs o achaar. Product security incident response, I think the key was ticket. But we somehow have ended up teams. Yeah, we Yeah, we ended up using that acronym for a lot of things. And a lot of ways security can be an aspect of quality. And so if you don’t have the validation systems, and the ability to update products after you’ve shipped them out, or things like that, that impacts not only your overall quality, but also your ability to respond and improve your security and products as well.

Camille Morhardt 19:13
But I know for I think secure development lifecycle was born as kind of a software check. And obviously, Intel and a number of other companies also make hardware. So is it different to apply a secure development lifecycle process to hardware versus software?

Vernetta Dorsey 19:35
The principles are the same, why we’re doing the thing, what we’re looking at in certain phases. It’s the how that becomes different based off of what you’re doing. It’s really important to get your architecture right because once you burn something in, you can’t fix it, versus the software where you have the capability to make updates and changes much later in the process. The principles of what we’re looking for. The same, but it’s just the how mechanisms that are a bit different. And you can attribute those different steps it based off of your industry and what you’re doing.

Diana Carroll 20:08
And regardless of whether you’re talking hardware or software, or even different types of software, context is key. And that’s no less true with hardware. But it’s no more true either. Think about it this way, you did need to reboot your personal machine personal laptop, like what every week give or take, then that’s normal. That’s accepted. That’s fairly standard for a client machine. But if Google or Facebook is offline for 10 minutes, it’s on the headline news, the context of what’s an incident is very different from software servers versus client machines. And it’s also different for hardware versus software, you have to adjust what you’re focusing on or what you’re concerned about, depending on the context of the product. When you get into like, you know, drones or IoT devices, each of them has their own context and their own set of concerns for security.

Camille Morhardt 21:07
What are people arguing over right now, SEO has been out for a while, a couple of decades, even? And I think it’s evolved? Um, is there an inflection point that’s coming up? Or? Or do people get really excited at conferences where you’re talking about secure development lifecycle? Are there sides to different topics?

Diana Carroll 21:31
Where people are people. They love to argue.

Vernetta Dorsey 21:34
We everyone agrees that modeling is a key component of city development lifecycle. But the way that one does the threat model is the big deal. That changes all the time, I think it’s in those house steps across the board across all the phases of the lifecycle that people fight, they don’t really fight about the fact that it’s needed. It’s just how you do it. Yeah.

Camille Morhardt 21:55
Let me ask Diana, what is the favorite part of your job? What’s your favorite thing to do?

Diana Carroll 22:01
It’s two things really. One is the people that I get to work with, I get to work with some of the most amazing, smart, passionate people, they care about what they do, they want to make things better. And they’re willing to, you know, put their time and effort and energy into doing that that is far and away My favorite thing about what I do. And the second thing is that like I mentioned before, security’s a rapidly changing landscape, it’s one where context is important. Which means that you never get bored, really find never get bored with it. There’s always something new, there’s new developments, there’s new products coming out that you got to figure out how they’re mapped to this whole landscape. There’s always new events and new developments and new things happening.

Camille Morhardt 22:50
Vernetta, hat do you think is the biggest challenges in security that companies aren’t aware of? They’re not thinking about?

Vernetta Dorsey 23:00
Across the board, what I see is companies aren’t thinking about security assurance of their product, if they’re not, quote unquote, building a security feature. They feel like when you say a security development lifecycle that you’re only talking about, oh, I’m building this security feature, my favorite graphic, is of a house where the front door has the feel safe lock, there’s chains around it, all of these things are blocking the house and they say, look, this house is super security, potential buyer, but then the burglar around the back going in the vent window of the basement. And so what I see from companies is they’re addressing the elephant in the room of Oh, it’s the front door, let me secure it, make sure I track all that. But the way you structure that house, especially for the context, the environment, you have to have this vent window in the basement. So what are you doing about that vent window, because you have to have it and it’s there, and everyone knows it’s there. So that to me is the struggle one getting people to realize that in this 21st century, where technology is changing, you have to think about the structure of your product, wherever it’s going, I’m always about it’s how we think about it, how our planners Think about it, how our investors think about it, if we’re not thinking about it, that means the hackers or the bad actors have more opportunity to take this thing that someone’s making for the good of humanity, and use it in a way that was not intended. When you think about it from the beginning, you can make sure it still performs exactly the way you want it. Because you’ll be thinking about these security implications early, not after things becomes very expensive when you’re trying to tack on. And then you might take a performance hit or you might take this thing because you’re trying to do it after the fact if you start at the beginning, you can be creative and be innovative and finding new way to do it in a way that meets your needs as well as your customers needs from his creations perspective.

Camille Morhardt 24:50
You’ve given me a lot to think about both of you. Thank you so much for joining and taking time out of your day in protecting the product. In compute that are going out into the world of vernetta. Thank you, Diana. Thank you very much. I think we do get into a few other topics in some other episodes of what that means. We do talk about products security incident response team. We do talk about privacy and its policy, you can check out a few others, even blockchain if you’re interested. Thanks for joining us on what that means.

Announcer 25:24
Subscribe to what that means with Camille Morhardt.

More From