Securing the Product Lifecycle: Building Global Compliance into IoT Development

Hi, everyone. Welcome. We're so glad that you could join us today for the securing the product life cycle webinar. We have a great presentation prepared for you today and some really great speakers, so I'm excited to get into this. our amazing panelists here, and they're gonna give a brief introduction on, on their background, and then we'll get into the content here. So with that said, I'd love to turn it over to Ali. Good morning and good afternoon, and hello to wherever you are in the time zone spectrum. My name is Ali Siddiqui, and I'm going to be hosting you know, cohosting with my my partner here, Curtis Yanko. I started my career a little bit background. I started my career in automotive electronics control systems, and then, you know, I spent a lot of time doing control systems engineering with Caterpillar for for machinery and power systems and and other critical infrastructure controls. And, you know, slowly, about a decade ago or more than a decade ago, I transitioned from being, you know, systems engineer and for controls to securing those same control systems and critical critical infrastructure. And it all started because of twenty thirteen US president's executive order to protect the nation's critical infrastructure. And and since then, I have worked in multiple very large organizations to either build up and set up a product security program and or run a security program and ensure it to to get to better stage. So that's what I bring here. And currently, with Finite State, I I am helping, you know, multiple clients do the same that I had done for for my employees before to set up product security program and and enhance their overall security for the products. With that, Kurt? Thanks, Ali. It's an impressive background. Mine's a little more straightforward. I've been in IT for over thirty years. It if you go back to the nineteen nineties when I when I got started, it was just build and release management. Right? I I can even lay claim to authoring twenty disk at install processes way back then. But, you know, you fast forward, it culminated in me running a DevSecOps team at a Fortune one hundred company, and it's there where I started to really get into supply chain security and self you know, via software composition analysis and also just really partnering with security teams as we were building security into our pipelines back then. So then for the last ten years, I've been working with application security testing companies really focused on supply chain security and static analysis and stuff like that. So that's how I got, where I am today. And I think we're ready for the next slide, Nicole. Now let's see if I can do this on my end. Alright. So here's what we have in store today. In general, we're gonna start at a very high level and slowly work our way down to the more practical parts. It's our hope that in the end of this, you'll see how, secure development life cycle can help organizations meet the demands of current and future regulations, where security is important. And I think that sort of touches on the the main thing is the real shift of late as the importance of security as we develop things. Next slide, please. So we we wanted to start at this thirty thousand foot level. We threw up some of the major regulations that are really driving adoption these days. But there's a pretty good chance if you've joined us here today, you're impacted by at least one of these or at or maybe even better, you're you're just really interested in finding ways to build security into your products and and just do the right thing and do a good job. These aren't just compliance checkboxes. These regulations are fundamentally changing how products need to be developed, monitored, and maintained throughout their life cycle, and they're they're really driving adoption. Like, I don't think a lot of companies would just sign up to do this on their own. Like, it it takes stuff like this to sort of force our hands at time. Anyone with a keen eye might notice the connected vehicle rule in here, which is indeed a very different beast than the others. It's not really about building security, and it's really about supply chain management. But that holds true until you actually have an issue and need to apply for a specific authorization, at which time your security posture will come into play. Alright. Next slide, please. And I think this is Ali. Yes. So, you know, what is you know, this this slide, I wanted to summarize a little bit, you know, the crux of all these different regulations and the the their requirements. They kind of boil boil down to few, you know, principles and and methodologies in terms of what need to be done. So first of first of all, obviously, you know, you want to your products to be secure by design. So you start start your work right from the start of you know, start phases where, you know, you're designing, developing, you know, thinking about the product concept at the very start, you know, do risk assessment, secure coding practices, other things like that model. And we'll talk more in detail about the framework. And then, you know, this the the second thing we have listed here is, you know, have an understanding of what is going into your product, including, you know, having that software bill of materials, which is which we'll talk more about. Having visibility and control and transparency over your supply chain, you know, having, you know, doing the, you know, threat intelligence and mediation and other things. The the the very high level focus is transparency, and you don't want to be hiding in the marketplace and in the security community in general. So you wanna be publicly acknowledging issues. If there is issue in your product, you wanna make sure you have a program to to do the advisories, you know, CVEs, if you can register the CV authority, those kind of things. And then, you know, setting up, you know, software update and continuous monitoring, vulnerability management, those type of programs to make sure that while you are operating the product, you are still keeping things in control and check-in terms of security. Finally, you also want at the same times, no matter how good security we do, we all know as security professionals, things can happen and incidents do happen. So you want to be ready. You don't want to be surprised. You wanna be ready with incident response plan. You know, you have to have, you know, process and and and tooling and methodologies to to properly report and remediate those incidents if and when they happen. Next slide, please. Okay. So earlier, we talked about regulations, and and some of them are already in effect, and others don't kick in until twenty twenty six or even twenty twenty seven fully. But one of the reasons we need to think about acting now is product development and delivery cycles can be long. You know, I'm pretty sure the twenty twenty six model year cars are already in flight with twenty twenty seven models probably not far behind. And I don't know that it's that different in the world of IoT and and other devices that are impacted. So, you know, this is why a lot of people we're talking to are trying to get in front of this issue today. The CRA is in full effect in twenty twenty seven, but reporting obligations begin in twenty twenty six. And implementing a secure product development life cycle can require a lot of change. You might have to overhaul your your supply chain. You're gonna have to, integrate all of the security controls needed or at least, you know, relative to the gaps that you already have, and and that can be complex and time consuming. So waiting to start will only likely put you under pressure, increase cost, and just make it all that much more stressful. So, again, we see a lot of folks coming to us looking to get started now even though these things don't really kick in for a little bit. But if we can advance the slide, I think the real reason, that we wanna get started is is the cost of failure is high. Right? This is not the kind of thing that we can be lax about and go into. Losing access to a market is a much bigger penalty than just incurring fine, which is sort of the equivalent of a corporate slap on the wrist. Right? Don't get me wrong. The fines are still in play and can be quite costly under the structures, so the the they're they're significant in and of their own right. But I like to remind folks that European regulations are why all your iPhones out there have USB C charging ports these days. And it was worth it to Apple to make that change to not lose access to that market. Right? If they hadn't done the change, people wouldn't be buying iPhones in Europe. But guess what? They did, and and you have it. And it's just a really good example, one good example of how powerful and what a powerful motivator regulations like this can be to affect this kind of chain. Oh, yeah. Again, the last thing I was gonna say, it does it does represent real fiscal threat to your company, and it's a rare case where we're really aligned. For many organizations, the challenges lie in up leveling your security posture. Now many of you probably are already doing some of this, maybe even most of it. Right? But it's really about making sure we're at some point, we're gonna have to be doing all of it. So maybe you're already doing mess SBOMs manually or maybe or maybe you have a slightly more mature process. Your vulnerability management engineering teams are gonna be pushed to do a lot more and look deeper into security issues. It it we're gonna have to take that a lot more seriously and be able to document that stuff. It's not enough to just ship a secure product anymore. You'll have to demonstrate the ability to continuously monitor the threats landscape, and there's requirements to provide timely updates when major issues surface. So so think that, you know, when those vulnerabilities get logos and start to become household names. So gone are the days of default passwords and leaving it to your customer to make the changes necessary to secure your product. We're gonna have to do the things for them and ship a secure product. Right. Alright. Oh, you got this? Alright. Alright. So if if there is any specific, you know, questions, comment, Nicole, for for for other things so far, we can talk. Otherwise, we'll we'll shift to discussing a practical tested, tried framework and some methodologies to help organizations establish a comprehensive product security program that will put those organization onto a solid foundation to comply and align to connect regulations and also, you know, future briefing. So with that, I think we'll we'll join. Mhmm. Okay. Very good. So this framework, I mean, most of you, if not all of you, have seen some variants of this somewhere. But I I thought this was a good way to represent the entire life cycle of a product. And this DevSecOps model sold the capabilities and activities that should be built into product life cycle, right, from the concept all the way up to the end of life stage of the product and everywhere in between. You can think of this program this this diagram in two parts. The left side, your dev part, represents your, you know, early phases from from concept to to release, which is usually owned and operated and executed by product r and d or engineering teams. And to the right side of the diagram, that represents post release operations phase, life cycle of the product, which is usually executed and managed, in many cases by product operations teams or in collaboration with IT or, you know, in many cases, many products, those things are, you know, outsourced to to some outside vendors as well, so just just for the practical perspective. So what I'm going to do is just spend some time on this slide, walk through some of the, you know, major active teams and actions that need to be built in into each phase of the the life cycle. So starting from the top left, obviously, you start any product with the planning phase. And in this starting planning phase, you wanna make sure that you don't lose sight of security requirements and data privacy requirements. You wanna make sure that those are identified and the sources will be external, like regulations, industry standards, some internal, which would which should driven by internal security policies of the company or from the customers. We wanna make sure you you have those requirements properly identified, documented, and become tractable over time as the, you know, product development life cycle. You you wanna make sure that they are implemented, and eventually tested, validated, verified, to be implemented correctly. So that's that's very important to to have that started very early. Same thing goes with the vendor assessments. You know, it is it is absolutely critical that we identify all vendors that contribute to your product, whether it's their supplying electronics hardware, you know, board support packages, they're supplying software that goes into product, or even the service providers. You know, many of us end up outsourcing software development for the software that goes into the product. You want to identify those vendors also. And the idea here is you put together a methodical way of assessing and evaluating the vendor's security capabilities, you know, what kind of prosecutor program they have, what kind of security controls they have in the product they're supplying you. And overall goal is to partner and work with the vendors that are at least up to your own, you know, security standards because your customers expect the product to be at certain security standard, no no matter whether it's supplied by, you know, supplier or built by yourself. So that's that's vendor assessment. You want to assess, make sure you maintain a list of all approved vendors for certain components that they are supplying. And, the the next thing during the plan fit, I believe, which needs to be started as soon as you have high level architecture, you know, technical, you know, plan design of the product, we start your threat modeling exercise. We're going to talk a little bit more about threat modeling, later in this. And once you move to the phase where you have, you know, software and you're building software, coding everything, all the, you know, basic, basic aspect of good software, secure software, including secure coding, you wanna start taking and running, software completion analysis, static analysis for for your source code. And as you move to the build stage, now you have, you know, final artifact, built artifact that, you know, finally is, and that's where you wanna make sure that you use the the, you know, the build artifact to get the software composition analysis done that will give you list of vulnerabilities in in the product to fix, you know, early in the cycle of, you know, coding and building. You wanna run that software completion, not the vulnerability. And, eventually, you wanna have a clear software bill of material, and we'll talk more why this is important and how to do later about s bombs. In in all this, we wanna make sure, you know, nowadays, most of the most of the organizations are building products using automated CICD pipeline, and that need to be secured as well in itself. Every tool, every the whole process that that that, you know, builds your software. Moving on to the testing cycle. Again, you do dynamic testing for security. Also, you wanna do penetration testing. And usually, in practice, penetration testing should be done, a light one, at every release even if you're releasing every month or every quarter. But at least a full blown penetration testing either if you have capability internally or using an external, you know, vendor. You want full blown penetration testing at least once a year or during any major architectural changes of the product. So if you have a release where you are changing, adding major components, you wanna make sure that you do the full penetration testing. So moving on to the right side, obviously, when you want you'll make sure you are releasing the product in a secure manner. And by that, what I mean is you secure the distribution channel. Many of, you know, IoT and embedded suppliers, we we develop the binaries and even put it on the website to be downloaded and installed by the customers to make sure you have, you know, security in place for the for the artifact in terms of, you know, integrity, authenticity, and other checks. You you wanna secure the release artifact itself through digital signature and other three code signing approaches. And then, you know, when you are deploy deploying, make sure you are deploying with the secure default configuration. So from the get go, it should be secured. Make sure system is important. And then during the operations, the things we talked before, make sure your vulnerability management in place, you are identifying, you know, managing, remediating vulnerabilities. You have incident response, not just a plan, but a plan that is practiced frequently enough to to be ready for any time, you know, set up proper patching and update cadence, establishing especially for IoT and and all the cloud side things, you wanna make sure you have complete visibility and monitoring all the time for entire back end cloud infrastructure application and and and everything else that you're hosting. And then you gotta have a very clear understanding of how long. In fact, CRA is going to require you to declare how long you're going to support the product from security patching perspective and when it will when the plan end of life is. So, you know, in our experience and, you know, me personally, many places, you start building these high level capabilities. You will set foundation alignment to any security standard or, I mean, should be regulation. So, Nicole, can you please forward? Why this framework and this model works is because it is derived from all majors industry standards that regulators reference when they are designing the regulations requirement. And, you know, many of us have been part of, you know, drafting or reviewing certain regulations, and I was personally part of, like, GDPR and and to some extent CRA, you know, commenting part. They all refer to these these known industry standards, which, you know, this this framework is directional. Also, it provides a common language and taxonomy for all teams and functions within your organizations. And especially, you know, for for for me, it works for very large, very complex global organizations, and there are so many different teams doing different you know, contributing to different facets and parts of the product. It is absolutely important. And this kind of model gives you a a common language, common taxonomy for everybody to speak the same language. Because it's easy to confuse between terms and and things if if it's not commonized. So that's that's a great benefit to this. Another thing is we're focusing on building key common capabilities instead of, you know, going and coming through each regulations of each upcoming standard, you're starting to build focusing and building your capabilities. And then, you know, these are aligned. They are proven to be aligned to mostly standards anyway. And then especially regulations come, they might be adding little things. So instead of building a new new program or new process, you might have to tweak or add a little thing to for new regulations. And this has improved very especially when we were doing sort of the previous employer assessment about CRA. It turned out it was a lot of things, but since we had a fairly good security program in place, it it turned out, you know, gap was very small. So we didn't panic in terms of CRA. He added a couple of things we had to we had to add to the program. Also, you know, these capabilities enable organizations to not only align and comply to current regulations, but also get ready for the future ones. Like I said, the most regulators, they are going to align to known established industry standards for security. So that has helped. Alright. Next slide, Nicole. So now I'm I'm gonna do a little bit, deep dive, a little bit talk about one of the artifacts that we discussed, threat model and architecture review. And we have identified few more that, you know, Kurt will talk after this. But, you know, we wanted to spend some more time. This this had been talked and emphasized by a lot of standards and regulators, the importance of doing this for for you know, internally for your customers, for your organization, but also for regulators, it's very important. So, basically, I mean, threat modeling is is is just a structured process for identifying, analyzing, mitigation mitigating potential security risks, gaps, and issues into, you know, to to a system or a product, and this is done at in the design architecture level. So you you use the the in a product design and architecture to analyze, any gaps. It involves systematically examining the potential gaps and threats to make sure that, you know, we are addressing those, you know, before the product gets released at design time or date. Hold on. If if you look at this this slide on the left side diagram, I mean, this is very oversimplified, threat model diagram, but, you know, all threat modeling, there are many many methodologies that are industry accepted and popular, and I've listed few of them. You know, attack tree analysis has tried past the or any of them, you can choose to do threat modeling. But all of them, you know, start with building a good true representative architecture diagram, threat model diagram that represents your controls flow, data flow, identify boundaries, you know, major boundaries, trust boundaries. And once you have that, you you wanna make sure you are, you know, comparing these requirements, and then you move and identify likely threats using one of these methodologies. And once you you you identify then assess the threat, you know, how bad it is for your your product, your customer, your, you know, environment, and then find ways identify ways to either to, you know, changing your design or implementing some additional security controls. How do you mitigate those identified threats? And then when you you keep tracking those tests and make sure that you're you're closing the book in terms of validating, verifying towards the end. Alright. That's very high level about threat model, and we'll move to the next one. Sorry. Just unmute, please. Yeah. The mute button is the most powerful button in the world, but I found it. Alright. So I did I do wanna draw attention. You know, this comes up a lot. When we talk about SBOMs in context, really what we're talking about is the idea that SBOMs are not required by name in most of these regulations or even in the security frameworks. They list out capabilities. Right? They talk about things that you need to be able to do without implying a solution. So sometimes the language we might see is stuff like identify or inventory third party component. Right? We get language like that in these things. And, Nicole, if you can advance for me, please. Then they go on to say, you need to be able to assess them for risk. They don't really get into what that means. Right? We we kinda understand what it means, but they don't say you have to use a CVSS score or anything like that. They just say you have to be able to assess them for risk. And one more. And then you also many of these, certainly in the world of IoT and any of, you know, these devices that are gonna live in the wild for, for years, unlike my days when I was supporting web apps and we could update it every month, we have to be able to provide ongoing monitoring and ability to deliver updates. Right? So the risks are temporal. They emerge over time, and we have to demonstrate through the regulators that we have these capabilities. Right? So when you think of all of those things, SBOMs are a great way to approach it. Right? They provide that inventory. They give us a mechanism to assess them for risk and provide the ability to do ongoing monitoring. Next slide, please. Now if oh, I'm sorry. I went behind. So if there's a slide in this whole deck that I'm pretty passionate about, it it's this one. Because this is kind of one of the big you know, this is the this is easy to gloss over. This is one of the really big elements that comes along, with these requirements. It's especially important that team work on on, on what matters most and be efficient because there's just so many vulnerabilities. Right? Everyone has run a scanner, an SBOM tool, or any other kind of security scanner, and you you you initially just sorta get overwhelmed with the sheer volume of findings. So let's get into some different ways that we can turn these mountains into a molehill as it were. And the first one I'm gonna talk about is probably the one that is least used. It's probably the one that people don't really think of or proactively do, which is just proactively. Right? And and, really, what you wanna be is looking at your dependencies and updating them before there's a fire. Right? You don't wanna wait for there to be a severe vulnerability. You wanna have mechanisms in place that can identify components as they're aging and use that as a feedback mechanism to your development teams to say, hey. Let's take a look at it, and see, you know, if there's a newer version we can get to. By the time a component is a year old, you're probably at least three to four versions behind. Could be as much as ten or twelve. Sorta depends on the project and the project's pay pace. But I wanna point that out first because that all by itself will go a long ways towards sort of mitigating all of the rest of these things. Right? If if we're proactively tapping, we start to we should see a reduced number of items that we now have to deal with in the next three categories. Alright. So next, within those, once we do have a bunch of vulnerabilities, it doesn't matter how well we patch. There's always gonna be vulnerabilities. There's always gonna be zero days. There's almost always gonna eventually be something on that Kev list, the the known exploitable vulnerabilities. And these are where you need to start. Right? This is a risk based approach. This isn't looking at my, you know, CVSS, you know, sevens through tens and focusing on the fits and highs. And I and I recognize some shops still march to that. But, really, we at Finite State advocate more of a risk based approach where we we look at it, top down. PED list items represent real risk. These these represent things that are actively being exploited in the wild, and you can reasonably expect, you could be next. Right? So most of the regulations forbid shipping anything with these in them, so it's absolutely imperative that you deal with them. You can't generally explain these away. The expectation is that you get them out of your product. Next, we go on to what I call the mature exploit. We talk about this often as being weaponized. And mature exploits are not somebody wrote a POC. That's a lot more of an academic dialogue of how I might, you know, try to explain why I feel the code is vulnerable. And if I use these sorts of algorithms or approaches or techniques, why I think I can get the the software to behave in a way nobody expected. So mature exploits really are basically a loaded gun sitting out there waiting for someone to pointing it point it at you and pull the trigger. They're fully automated. Often, weaponization often means they already have a malicious payload or certainly have already have the mechanism in it to deliver a payload. So these become really important to start focus on, and they're not always just gonna be those CVSS nines and tens. Right? These things will can run the gamut down in down to seven and and below. So these are super important to deal with. And and because now you're working on real stuff, this is real risk. This isn't theoretical risk. This isn't just a CVE that doesn't have a POC or anything else. Nobody's done anything. I don't care what its score is. It doesn't represent real risk yet. It's not to say it can't become a zero day. I'm not saying that. But the odds are not likely. Right? Whereas there's generally a relatively short distance from a mature exploit to ending up on the cav list. And, again, not all the time, but odds are in the favor of that making that next step. So one more. The this is a relatively new I I've been hearing about reachability for probably the last probably four or five years. A lot of people see it as, you know, something of a holy grail in this space. And, really, this becomes really important in a modern setting with all these vulnerabilities because to satisfy a lot of these frameworks and our suppliers and and the market and the regulators to get access to the market, we have to be able to demonstrate that we're in control, that we understand what's happening. So when we can say, hey. Yes. I see this CDE. I know it applies to this function, and we know that that function isn't called in our code. That's a reason why, yeah, I'm it's gonna be in my SBOM. We're gonna be transparent about the fact that it's there, but we're also gonna demonstrate that we've done our homework and realize it doesn't affect us. So reachability sort of cuts two ways for us. It can help us in terms of what we should work on, the things that are reachable, but it also allows us to get a bunch of things off of our plate that aren't reachable. Again, this is all with an eye towards just dealing with the sheer mountain of vulnerabilities that tools like this can produce on a single project, let alone your whole portfolio. So these are the levers that I see being used the most to deal with that mountain and make it manageable. Because this is probably like I said, this is one of the bigger elements in the room as we do this. This is the there's just this giant number. Your security folks are gonna have to start to prioritize them, And this is where tensions start to build up between teams. Like, you're sending stuff over to the devs, the devs are saying, well, this isn't even real and all that stuff. Right? So we have with evidence like this and insights like this, we can help remove that tension between those teams and let the developers know, hey. You're working on stuff that's real. You're working on stuff that's reachable. Right? We're we're not just throwing over a bunch of vulnerabilities that don't really apply. Alright. And then I guess the last one didn't list it here, but the last one I would just call out is that you probably have a bunch of vulnerabilities that have no POCs or anything else. They can largely be deprioritized. Right? I don't care what their score is almost. Some of you will still see if they're high enough. You wanna react to them, but it should help just get a lot of vulnerabilities off your plate. Thank you. Back to Ali. Alright. So I'm gonna talk, you know, a little bit about, you know, how do you get it started with with all the new different activities and capability that you we have to eventually build to to to have a a holistic security program. I'll go through these these, you know, few of the major capabilities. But before I get to specifics, I think the the first step to start is evaluate, do an assessment of your own capabilities, what you have today, you know, using these frameworks, which level, which majority you are. And then once you have that person, you will have understanding which areas to prioritize and focus first. But if you don't have it, when you're literally starting, you don't have much, the first thing to always focus is software scanning, which I have not listed here. That because that there you know, you go out in the market, there are tools that can do software companies and analysis on binary as well as on the source code. You definitely wanna scan your code for aesthetic code analysis. So bunch of SaaS tool, very mature industry available. So scanning put put in place as soon as you can because that's a low hanging fruit in terms of implementing, and it's a big bang because it gives you, you know especially software composition analysis gives you all known vulnerabilities in your product, you know, right at the gate. So that gets gets you, you know, far far far better in terms of, you know, making the product secure overall. But other than that, you know, other capabilities, focus on building these core competencies and capabilities by starting small and then, you know, adding on to it over time. For example, you know, you might start, you know, building requirements on a word slide or Excel sheet. And then eventually, you know, a little bit later, you can move on to putting those items into Jira so that you can track them over the time and, you know, to the closing or any other, you know, work management tool workflow management you use. And then once you mature enough, you can go to professional platforms like SD Elements of the Words and others who who provide you, you know, a a fully capable platform to not just start customized requirements, but also manage them throughout the life cycle. Same thing for threat model. I mean, the threat model diagram that I showed, you can very, very start with that level. We we call them level zero threat model, which means in IoT world, you probably will show four boxes there, you know, a device, a cloud, back end, a web application, mobile application. Maybe just just four boxes and do your the most basic threat model you can start with. And then as you mature in terms of that capability, you start doing level one threat model where you you go ahead and break down the comp software components within the device, software components within the cloud back end, and then start doing in a much cheaper threat model as you go. You know, another another example, you know, pen testing. This is this is another capability you wanna start doing from get go. Initially, you can utilize external vendor to do your threat modeling, to do your pen testing, but eventually slowly start building internal capabilities of pen testing. You might have to start with internal capabilities only, you know, lightweight. I mean, you're using some of the automated tools, scanners. You might have, you know, some traffic analyzers, sporty scanners, basic stuff. We start doing pen testing and still rely on, like, very formal pen testing by your vendor. But, eventually, over time, it takes years to transition that capability internally. And still, you have to use the external vendor in many case because I've experienced, myself that many of your customers will require you to do pen testing, by external party as part of your your contract or or commitment. So that's that's another area that, yeah, I think you can slowly build up. Another area is monitoring incident response and vulnerability management. All these capabilities, again, we we can start very slow. For example, on on cloud monitoring side, you can deploy a a simple cloud security posture management tool, you know, you know, Sophos and Qualysys and and cloud side of the world to monitor your cloud application and environment for basic configuration issues or CVEs at the runtime environment checking, that kind of stuff. And then you continue building on that maturity. So the so the whole mantra is don't be scared. Assess the entire framework and have a plan. It might be multiyear plan, but the you know, slowly start you know, it it started small and keep adding on to it to to become more and more mature over over time. And that has been, you know, proven. It's it's frustrating if you start doing everything at once. We've had it and as an organization, and then it's caused a lot of stir. But, you know, I give the analogy of boiling the frog. If you put the frog in cold water and and and it start boiling slowly before the frog real realizes this it's already toast. Right? But if you put the the frog into a boiling water, it's gonna jump out. So that's that's the analogy. Next, Nicole, please. Alright. Alright. Kirk. Yep. I'll bring us home just to share with everyone. Ali, you thought it was important that if I started, I finished to give us some bookends. So so here I am. We're hoping at this point, we've we've shown you some of the importance of the software development frameworks and how their ability to act as a north star, right, and to start to guide us to where we need to get to satisfy these regulations that you and and many of you may be dealing with them today. Or, and then, also, it just is gonna put us in a good position as new regulations emerge, and I'm sure there'll be new regulations that legislators aren't gonna stop. There are lots of different frameworks out there that exist. We haven't talked about any one in in particular, but I I think what with the genesis of this talk is when you've looked at several of them, you start to realize what they have in common. And that that was our goal today, Ali, was to sort of share with you what they have in common without getting specific into any of them. If you're coming from something that sort of predates that, you might wanna look at, like, the NIST SSDF. The reason I mention it in particular is because it does a good job of mapping other existing security controls, some of which you may already be using. So if you're looking at, you know, how does this fit in with where I am today? That might be a good place to start that I can think of. So, yeah, so the you know, these things, we we've touched mostly on the product development. I think Ali touched out a little bit on vendor management. There are other aspects to these plans. A lot of them are probably more traditional, security of securing our environment, our our our employees and access management stuff. We didn't get into every facet of it. But when you are when you are starting down your journey of secure product life cycle, just know that you can keep making incremental improvements. I think that was a key message here. You you don't have to do it all at once. We can focus on different areas, start at different levels of maturity. Don't let perfect be the enemy of good enough, but also know it's we don't longer live in a a time where good enough is okay. We are gonna have to continue to improve and get to where we can satisfy all of the requirements. And so with that, I say, thank you for taking the time to listen to us today, and I believe, we can open it up to questions. Alright. Thank you. I do have one question here, and I'll just pose it to both of you. Can you share an example of how you see SPDL helping with cross functional team alignment between among product security teams, security, and compliance? That's really good question. And, Kurt, I'll take on this first, and and then, you know, you can you can add on too. But I touched on this before, in terms of when I you know, talking about why these kind of frameworks are effective. And I'll I'll continue with the same same theme that if you establish a common set of capabilities with using common language, common taxonomy, that goes a long way in bringing everybody to the same understanding of what is being done and what will be required. But then the second level of thing that unifies the internal groups in the organization is always tie everything to your business and customers. Think about customers. You know? I I work for the company that, you know, developed the security system for the schools, and and they are dominant in in in North America in all the school, whether it's access control systems or video surveillance or other things called the safety security of of the schools. When when I talk even for internally as a security leader, when I'm trying to talk to product groups to do something about security, additional work. I always bring in not just a, say, the hardware and cloud and mobile app. I talk about the school and who are we protecting the kids. So you always try to your mission of the company, your customers, and business. That goes a long way in bringing various groups within the company together. It's been successful. That third thing I've noticed is if you are a security professional, a security product security person, don't go to engineering and product as if you are know it all, police, or enforcer. Because engineers are very smart creatures. They they find to work around you if you go in with that attitude. My suggestion and research is tested that that that the process that work is go as a partner. Say that, hey. I know you guys are trying to do good things for the customer, for for our market, for our company. I'm here to help you do it better, maybe hopefully faster with lesser effort because that's music to ears for engineers. They're already loaded hundred twenty five percent of their capability. So those are few few tidbits and, you know, practical things, Nicole. I I just wanna add two cents, and I think you touched on it lightly. But as someone who's been in the space a long time and and the the the reason silos exist in the beak in the beginning is there's not a there's no real alignment. We're we're almost at odds. Right? You know, developers are trying to go fast, and security folks are trying to slow them down. But the the major shift that I've seen at a high level is there's clear alignment to the business. Right? There's clear alignment to getting your products to market in a timely manner, maintaining access to those markets. You know, it's not just cost avoidance of fines or what what might happen if bad things happen. Right? There there's much more clear alignment that everybody's pulling in the same direction. So I I think it helped I I think these frameworks actually help reduce those silos and and give everybody something in common to focus on. Great. Thank you so much. And I think we have already touched on this a bit, but I did wanna call out this question just to give another opportunity to share perspective. For teams who are resource constrained, which are a a lot of teams, right, what's a practical first step that they could take that we could take to start adopting SPDL? I talked about this field. So, Kurt, I I think I'll I'll give you opportunity to pile on. Yeah. No. I think you should run with this one. You know? Yeah. I mean, go ahead, Ramadan. You mean it's, you know to me, it's so you're doing a gap and you're filling in gaps at this point. We we talked about, you know, this you know, starting small and building onto it. That's the mantra I'll repeat again. But practical sense and and, you know, I hear you, whoever asked these questions. I I totally hear you. There is there is never enough resources not for, you know, not for engineering, not for product development organizations, and not totally not for security groups. You know, companies are resource constrained. And in many cases, unfortunately, even in this day and age, top of many companies, security is still seen as a necessary evil that they have to do it. They don't want to do it, but they have to do it. And hence, your your real budget and resource are always tight. So, you know, in addition to the things I talked about this, my suggestion here that what works is focus on things that can you can start with less resource heavy, more reliance on external partners initially. So you you can get started with the security program by hiring an external partner who who has expertise in your area, come in and do the assessment for you. You the assessment could be for your product, like, you know, threat modeling of your entire solution or, you know, entire organization in the light of a framework. You can do that. Same thing for for pen testing. You don't need to build capabilities internally to do pen testing to start with. You can you can hire pen testers. And I know it's expensive, but it's it's it's it's really worth the money. And especially especially in my experience as, you know, working for OEMs, the customers do value those pen tests done by external parties. So it it it bears a lot of credibility. So that you can do. Same thing for scanning. There is no excuse to not implement the scanning. I mean, it's nowadays platforms have become so good that they can integrate into your CICD build process pipeline. You can trigger a scanning automatically at build time or any build time you've you you decide as a policy matter. Even the platforms are getting much, much better, not just scanning and telling you what they found, but now the most of the the the scanners are getting to next level, including our finite state. We're starting to focus more on helping triage, you know, prioritization that level. So I think that the areas of advancement in that is going to certainly help with if you are in resource control. You get that's where a lot of resources are spent. You got thousand vulnerability you have to sift through. You gotta find which ones are important and immediate, which ones I can find for two months. And and I think those areas will help you with resources. That's great. Thank you so much. I think with that, we are gonna go ahead and wrap up, and I just want to let everyone in the audience know we're gonna be following up with some resources on how Finite State can specifically help you with your SPDL adoption, everything from the SPAM management to addressing vulnerabilities at scale to penetration testing and compliance services. We have a lot of things we could offer to help if your team is resource constrained or is looking, to advance your product security program in general. So we will send those resources to all of our, attendees here after the session. And with that, I wanna thank Ali and Curtis so much for a great presentation. We were able to get very technical with this. It's always fun to kinda hear, especially your practitioners', perspective. So I think the audience, from what I could tell, really enjoyed the session. Thank you for your time. I wanna thank everyone who joined us here. Again, we will send the recording to you, and feel free to share that with your team. We feel like this is something that, if shared amongst teams, could could really be a value to you. And then, of course, reach out to Ali or Curtis or myself at Finite State. We'd love to continue the conversation with you. And with that, I will sign off, and thank you again, for joining. Thanks. Goodbye. Thank you. Thank you. Bye.