Christian Frichot -- Threat Modeling with hcltm

0:00Chris RomeoHere's a list of things that Christian Frichot is. He's an AppSec hacker, a security leader, co-author of the Browser Hacker's Handbook, co-founder of Asterix Information Security, now part of CyberCX, ECU Cybersecurity Hall of Fame alumni, and he's a developer of HCLTM, the DevOps threat modeling tool. Christian joins us to talk about HCLTM. What is it? Why he created it? and where he sees it going in the future. Tune in to hear about a different approach to threat modeling. We hope you enjoy this conversation with Christian Frichot.

0:35Christian FrichotNone of the top 50 university programs teach secure coding in their curriculum. At Security Journey, we help enterprises reduce vulnerabilities through application security education for developers and everyone in the SDLC. With over 400 up-to-date lessons created by industry-leading security experts and a programmatic approach that creates security champions, Our program has increased AppSec knowledge as much as 85%. Visit securityjourney.com to try our training today.

1:03Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I'm the CEO of Curve Ventures, and I'm also joined once again by my good friend Robert Hurlbut. Hey, Robert.

1:31Robert HurlbutHey, Chris. Yeah, it's Robert, and I'm with Acquia. I'm a principal application security architect and threat modeling lead, and really excited about our topic tonight to talk about threat modeling and some— a new tool.

1:46Chris RomeoYeah, something that, you know, threat modeling is something we never talk about. It's like, you know, we'll have to stop and explain what it is. Literally, 1/3 of the Application Security Podcast has been dedicated to threat modeling.

2:00Christian FrichotIndeed.

2:00Chris RomeoBut we're super excited to have Christian Frichot with us this evening, for us this evening, for him this morning. But Christian, we always like to just jump right into your security origin story, giving you almost no time to warm up at all. Take it away. How'd you get started in AppSec?

2:17Christian FrichotYeah, look, I think I came into application security through a pretty typical pathway. I was involved in network security, Windows network administration, Active Directory. I'd studied computer science at university and had fallen in with like a security research group, which was actually probably the first time I came across one of my, my you know, one of my very, very critical mentors to my career. I've had like 2 or 3 people that I've kind of latched onto in my journey into security. And yeah, just kind of went into the kind of IT space in a high-risk security environment. So it was a company that was involved in mining diamonds, and they actually had challenging network security controls for surveillance and access control and things like that. And throughout all of my time in that space, I also just had a big passion for software development. I always loved building little tools and hacking on software and reading and understanding software. And then, I guess, when AppSec and OWASP in particular started to grow in kind of, I guess, popularity, Seeing a pathway where you could actually kind of combine typical security with application software development was just this goal. That was exactly where I wanted to be. And then, yeah, I think I helped spin up the first OWASP chapter down in Perth in Australia, which is where I currently live. And, you know, just got involved in the community as much as I could. I was one of the core developers of the Browser Exploitation Framework, or BEEF. For a number of years. And that led me to, um, being one of the co-authors of the Browser Hacker's Handbook, which was one of— it was a Wiley publication. The, uh, the primary author was a gentleman called Wade, who was another big mentor of mine, and he was the BeEF creator. And so getting exposed into that industry was, uh, I was super fortunate to, to score a job up with LinkedIn up in, um, their Silicon Valley and lived up in, in the SF Bay Area for about 5 years working at a handful of different companies, just continuing to focus on application security. And I love talking and hanging out with other people who are passionate about threat modeling because absolutely my favorite capability, I would say, that, that AppSec people bring to bring to their area of expertise. And so anything that we can do to help, you know, make that process easier or more effective or, you know, kind of more accessible to more people, I'm absolutely on board. And then, yeah, I was working up in the US and then moved back to Perth around 2019. Uh, randomly just before COVID kind of kicked off. And then obviously that put a lot of turmoil on job opportunities and work styles, and I kind of bounced around a little bit. But now I'm a principal product security engineer at Atlassian, focusing particularly on their partnership approach. So we work very, very closely with software product teams to become I, like, offer a white glove product security AppSec experience, which mostly is threat modeling.

5:58Chris RomeoYeah, excellent. So, I have so many questions, and we haven't even gotten to the actual, you know, HCLTM thing that we're going to talk about here. But you mentioned mentoring a couple of times. And so, I'm curious when I hear people talk about the fact that they've had people that have mentored them in their career, What would you say are some of the big takeaways you learned from having those mentors in your career path?

6:27Christian FrichotYeah, I think it's twofold. I think succeeding and being effective at your work, and in particular, like security-style work, it's really, it's this combination of things. And I think like a lot of us, when you're younger in your career, You know, and in particular for people who are kind of more technical in their nature, just because of, I don't know, growing up with computer games and things like that. You know, there's, you kind of, you have this real drive and passion to upskill and learn more. And security has this really interesting avenue where security research now is a very, it's a very large portion of what our industry does. There's a lot of people that spend a lot of time doing this because we've got events like DEF CON and things like that where you can go and present, and it's quite interesting. But I think, you know, there's that other side of what we do, which is as critical really, which is all about communication and influencing and building relationships and building networks. And I think for me, the individuals that had these big impacts on me kind of helped me grow in those areas, as well as being like great technical leaders and being able to guide me in that growth as well. And I think honestly, the things that I got out of them, or at least the method that they were using to deliver this kind of mentoring, was mostly informal. Like, these weren't necessarily like really formal mentoring relationships, but certainly people that would you know, they would champion efforts that I was being involved in. They would support things. Like, in particular, you know, Wade Alcorn, who was the co-author of the book, you know, he was just a great person to talk to about all sorts of technical security things, but also seeing how, you know, his approach to security consulting, for instance. Because he'd been doing security consulting and he's been, you know, a key player in the security consulting space in Australia for a long time. And so, it was kind of like, it wasn't just this one thing. It was these individuals that seemed to have a couple of superpowers. And I think it was learning from that. And there's a bit of like a proximity to that that really helps as well. But also, even just getting them to bounce ideas off is really invaluable. And also kind of feeling safe in doing so. Like, You know, sometimes ideas are completely, they're completely wacky and that's absolutely okay. But to be able to have a space and a relationship with someone where you can kind of say, so what about this? And they're like, you know, that's, I can see how that might work, but maybe if you went this direction, that might be better. And yeah, I think I look, I've just been really, really fortunate to have a handful of these folks in my career. And now I really strive to look for opportunities where I can offer the same to younger people as well.

9:26Chris RomeoI figured that was going to be the case after hearing.

9:29Christian FrichotYeah.

9:29Chris RomeoAnd then I would say I'm in the same boat. Like, I looking back, I've told these stories before on the podcast, but like, I literally was standing on the backs of giants in the industry and didn't even know it. And so they taught me so much and put up with so many what I now realize were dumb questions and patiently explained it to me time and time again. So like, it's really— it really changed my approach to mentoring and helping others. And really, I want to see other people succeed. Sounds like you. I think we're probably all in the same— we're all in that same boat. Like, Yeah, our industry needs more people. We need to pass on the things that others imparted to us, bring it to other people. And so that's something that I'm super passionate about. Robert is as well as far as doing that. But, you know, we should probably talk about this other thing we came to talk about. So Robert, how do we get into this next topic?

10:17Robert HurlbutYeah, so Christian, so this new tool that has been around for, I think, a short while, HCLTM. What is it?

10:30Christian FrichotYeah, I mean, firstly, it's a not very imaginative name for a security tool. What it is, is the context here is that I worked remote for a company called HashiCorp. And HashiCorp, if you haven't interacted with them or heard of them, they are a cloud— they're kind of like a cloud software and DevOps tool company. If you haven't heard of HashiCorp, there's a good chance that you may have heard of some of their products, including Terraform and Vault. Now, they have a whole suite of other products, both in the security space and also in the kind of cloud operating model area. But HashiCorp is an interesting organization to work for because they combined a couple of things that I really liked. I've been involved in open-source software on and off for years and years and years. I really like the approach of open-source software. And HashiCorp, their entire business model is built on open-source software. And then obviously, they sell closed enterprise feature set versions of those products. And that's how they drive revenue. But, you know, Terraform and Vault are these fantastic examples of very well-known DevOps and cloud software tools that you can jump on the internet and clone the software and read it all yourself. Now, one of the underpinnings of HashiCorp tools is they— and in particular, if you've ever written Terraform files before, they created a language specification called the HashiCorp Configuration Language, or HCL. And I, I had worked at a couple of places that were large Terraform and Vault customers. And I really liked just the language, like the specification. And if you, if you've, if you've never seen it before, it's kind of like, it looks a little bit like JSON. So it's kind of, I think it's a superset of JSON, but it kind of has a layer of simplicity on top. So it's not, not as strict in the formatting. But one of the, one of the powers that it brings is that it actually has a bit of a compute engine inside of it as well. So, so the specification itself, HCL, is, is again open source software that they've released. It's a software package that HashiCorp products use inside of themselves. And whilst I was working at HashiCorp, Their approach to, I guess, work management and software delivery was something that I hadn't really come across before. But it was very much like working very closely with software engineers. You could see the importance of engineering managers as far as finding ways to help solicit a state of flow for software engineers was really, really important. As in, they recognized that everything that we can do to optimize how an engineer and the developer productivity and the developer experience is actually critical to the success of how we deliver software. And watching how these folks worked and watching their processes, I like all these things kind of bubbled up. You know, they spend a lot of time in Slack, they spend a lot of time in GitHub, they spend a lot of time in their IDE. And kind of not much else. And literally any, any kind of process or security tool or exercise or anything that you have to do that pulls a software engineer, uh, or like a DevOps engineer out of the tools that they're using is this friction point. And, um, you know, it has this opportunity to disrupt their flow. So looking at the way they work, looking at the way they constructed their build pipelines and things like that, I kind of was like, okay, actually, I really like a lot of how software is developed within HashiCorp. And a number of other companies around the place develop software in very, very similar ways. It's very, very, you know, Git-driven environments. There's a lot of CI/CD automation. We've obviously seen this big trend over the last couple of years where CI/CD is now moving closer into source code management products such as GitLab and Bitbucket and, um, and GitHub and Azure DevOps as well. Um, and so I kind of was like, okay, cool. Obviously software development at HashiCorp is really, really optimized. How, how we do threat modeling within HashiCorp, you know, kind of a little bit more ad hoc. And that's completely natural. Like there's a There's a maturity curve that you find with organizations as far as, you know, how, you know, what capability of maturity are they with regards to threat modeling. And they might start off with really ad hoc, unstructured, you know, maybe some person comes and documents something, or maybe they do a workshop or something. And we wanted to kind of lift the game there. And so part of that was, okay, so— Yeah. What's a very HashiCorp-style way that we could help people do threat modeling? And HCLTM was my thinking around that, to basically provide a threat modeling template language, like a text file-driven format that's very human readable, but also programmatically interfaced, like you can interface with it programmatically, which also had a CLI like driven from the CLI, which was also then very integratable into CI/CD. Because that was kind of like, that was how HashiCorp worked. It was like all their tools, like if you've ever used Terraform or Vault, like they all have a very unified CLI experience. And part of that is because they all inherit this library, which was actually written by the co-founder of HashiCorp. It's like a CLI library. And so I was kind of like, okay, so this is what they're doing. How does something that works to do and optimize for threat modeling fit into that model? So that was kind of like, I guess, the origin story of HCLTM.

17:05Chris RomeoSo just to— I'm just kind of trying to think through the workflow of the customer that you were building this HCLTM tool for. And so, as you said, it's a developer, or they are a developer, They're living in their IDE all the time and using the tools. And so, the intention with HCLTM was to give them something that was part of their world already versus giving them something completely new. And then, so I guess my question is, how does HCLTM interface with what they do? Like, is it—

17:44Robert HurlbutYeah.

17:44Chris RomeoIs there a structured set of language and commands and things that they had to learn to be able to threat model using it? Or tell us kind of what about the user experience.

17:55Christian FrichotYeah, for sure. And I think it's worth noting that this, you know, I think there was definitely like a couple of selfish reasons as well that I was interested in doing this. I think, again, looking out in the industry, there's a handful of really fantastic threat modeling tools out there that do similar kind of things, which is that kind code-driven style threat modeling approach, like ThreatSpec, I believe, is one that comes to mind. And if I'm recalling it correctly, that's the one where you can put annotations inside of code. And right, it extracts all the information from all your actual software, and it helps you construct data flow diagrams. And you can kind of start to map out controls and risks actually within your software itself. Which is just like, to me, that's a very high level of maturity approach to this problem. And like, I love, there's so much I love about the tool, but it was just like, I can see where in some places that absolutely makes sense. But I think there was a delta with the processes that I was seeing. And so HCLTM really is centered around the challenges, or I guess like, The value proposition really to me for threat modeling is kind of twofold. It's a threat model— for threat modeling to be effective, I kind of believe that it has to be able to drive valuable change, right? Absolutely. If you're doing— if you're spending time doing threat modeling and it's not driving change, or if it's not identifying things that people can address, and it's not actually lifting the security of a product, then maybe it's not as effective as it could be. So I believe that's one of the core tenets of any kind of threat modeling process or technology. The second one is documentation. And for me, this is kind of where HCLTM fits a little bit better. It is meant to be a very modular and unified way to document a threat model. Ideally, I would love for it to get better at helping drive change, which could be filing tickets or helping build a roadmap or a to-do list or a punch list or things like that. There's future issues on the GitHub repo to investigate those sorts of things. But right now it really is focusing on what's a smart way to document. And one of the things that really underpins this is it is a, it's a HCL-looking syntax. So you define a text file.

20:31Chris RomeoMm-hmm.

20:32Christian FrichotYou know, you define your threat model in there. You would describe the system or the scope of work that you're looking to threat model. You can document attributes associated with that system, such as is it internet-facing, or you can add arbitrary kind of key-value items to it. You can document all of your information assets and your use cases and any third-party dependencies. You can define a data flow diagram in there, and the tool can construct diagrams. Out of those, the DFD specifications. It actually uses a package that was originally created by Marketta, who are a marketing tech company out of the SF Bay Area as well. So I leveraged some of their existing Go packages as well for that. But it's also not super opinionated as far as like diagramming, like diagramming it like we record. So I recognize diagramming is an important aspect of effective threat modeling. Some would argue. But I'm also like, but if you're going to diagram in Miro or in, you know, Adobe Photoshop or in PowerPoint, it actually— that's, that's cool as well. Like, absolutely. If you're gonna, if you're gonna mock up what a system looks like in some other tool, that doesn't prevent you from using this specification. So we can embed an image from somewhere as a data flow diagram. And then, um, it allows you to define threat blocks. And basically, that's the whole premise of the language. There's blocks inside of this specification. You can define a threat. You can define proposed controls with control effectiveness. And because of the underlying features of HCL, it's also very modular. So you can include references from other locations. So for instance, you might maintain a central repository of controls in a separate GitHub repo, And the language and the associated tooling allows you to kind of dynamically pull in these modules as well. So there's kind of, you know, there's the language specification on one side, and then there's the CLI tooling on the other. And the CLI tooling is used for iterating. So you could like, just give me a list of all the threat models in this particular folder with various attributes, or show me the output of a rendered threat model, which might take in modular content from other places. Or maybe build me a dashboard. So build me an index page and individual threat model files. And then that's then kind of wrapped around the CI/CD. I mean, the CI/CD just uses the CLI tooling anyway. But the idea is that the process would be, you know, a software developer has a repository, they can throw a threat model file in this repository and add some CI/CD that anytime that file is changed, it republishes the threat model back into the repository in like a pretty or a unique format or, you know, or something like that. So it's kind of like a specification to define kind of somewhat programmatically a threat model and then some tooling to kind of turn that into a human-readable file that in theory can live inside of the software repo along with the software and it can be managed with GitHub. So it's got that history and it's got You know, you can see who made the changes to various parts. And so, it really is, it's looking at the tools that developers are using and trying to reuse those things because there are a lot of benefits of using Git, for instance. Yeah.

24:05Chris RomeoSo, when we think about the threats, then, like, as a developer, say I'm a newer developer, maybe I don't know, maybe I've heard of STRIDE, but I don't even know what STRIDE actually stands for. So, like, is there a STRIDE external file where you've defined spoofing, tampering, everything else that exists in Stride, and then I can reference that somehow? Or how do I know, as a developer, what the threats are that I need to describe in this file?

24:33Christian FrichotYeah. And look, that's definitely a gap in the tool. Like, there's definitely probably a degree of either prior training or experience that someone has to bring to it. So there are plans to look at providing some automated threat suggestions, as in, You know, if you have an asset in your system and it's an AWS RDS database instance or something like that, that might come with certain threats and control recommendations. And the plan is to eventually to have templated-up recommendations engines in it. Currently, I've had a couple of people actually submit— I'm trying to think what they actually were, but there were control libraries for the OWASP proactive controls and the AWS security checklist. So there's already files in there that basically kind of define using the taxonomy from these third parties, like control recommendations. But currently, there's no smarts to say, if you have an asset like this, or if you have a process like this, then you should probably consider these controls. Definitely a gap. And I think some of that comes back to just fortune in that A lot of the places I've worked, they do threat modeling training, like threat modeling onboarding and threat modeling training is something that exists. So there's probably a degree of assumption around how someone would use this. But it does have, for instance, when you define threats, you are able to nominate them as— or sorry, when you are looking at controls and threats, you're allowed to kind of nominate them as like, which part of STRIDE is this related to? So there is aspects of supporting those sorts of frameworks in there, but it's not necessarily anything more than just allowing someone to be more verbose in their documentation of a threat model. I'm very, very open to suggestions to making this easier and smarter for DevOps people. I definitely feel that there are still, like, a ton of gaps. But, I mean, that's kind of part of the excitement of working on these things. It's like, well, how— How do people use it? You know, and, you know, what can we do better? Which is exciting.

26:46Chris RomeoYeah.

26:48Robert HurlbutAnd with that in mind, so there's an assumption, it sounds like, of training. Do you provide some clues to help a team to— how do I get ready to start to use this and understand threat modeling? Because there's different ways that you can teach threat modeling depending on the tool. And I've had that experience where if you made a tool selection, sometimes your training needs to sort of fall into that so that people, when they experience it, they go, oh, what's this? This is completely different than what I just learned. So do you have any guides or anything to help teams?

27:23Christian FrichotNot doc— I think I maybe point out some of the Microsoft material and maybe point out somewhere in the README to show Stackz threat modeling. book, probably I don't do enough. Like, I think there's a degree of a— I think going back to that, companies that have a maturity spectrum as far as threat modeling goes, this is probably not one of the things that is like, if you are very, very early in your days and you've never done this, or if you're not working on DevOps, you know, if you're not. And so, I think one of the reasons that I kind of do tie it to DevOps is that HCL as a configuration language and managing everything in code is obviously a very DevOps thing. This tries to fit that model. I agree, learning curve, probably not the best. Lots of room for improvement. There's definitely some things that are quite obvious. Like, when you look at the specification, you're like, oh, okay, cool. Like, I could just— I could write one of these myself. But you're exactly right. I think there is that missing gap, which is typically what security professionals will bring. You know, it's like—

28:30Chris RomeoYeah.

28:31Christian FrichotHey, software engineer, you are obviously the expert in your software. I'm the security expert that's been around the industry for a while, and I understand more of the threats that a software like this might face if it's published onto the internet. Definitely room for improvement. And I mean, I think that's a challenge for all, like, all of us who are passionate about threat modeling. How can you— how can we work to lift everyone in this space? Yeah.

28:56Chris RomeoYeah.

28:56Robert HurlbutAnd close those gaps, right? So the thing I like about this is, as you mentioned, there's the HCL. So for those who are familiar with HashiCorp, they are already familiar with the language. If they're already in a DevOps environment and that approach, then this is helping meet some of those needs to have a tool that they can use. Some of the other gaps you mentioned, I think those can be filled in time. So, but no, that's great. I appreciate just understanding a little bit more about where it fits and approaches.

29:34Chris RomeoYeah. I think this is the future, right? Like, you know, I've been kicking around the world of threat modeling now for, I don't know how many years, 10, 12, 13, it's probably 14 years or so. Like, I did some work at Cisco in helping to roll the early versions of threat modeling out after we were looking at what Microsoft was doing and they were telling, they were explaining it to us as far as what they had done. And then we were trying to copy what they were doing. And so, but when I think about like, where do I think threat modeling's gonna go in the future? I think what you've got here is the direction. I think this is where everybody's gonna go. Like, yes, I love data flow diagrams. That's how I teach it because that's how it makes sense to me. But data flow diagrams on their own don't sit well in code repositories because somebody checks it in and it immediately ages out. Like, 5 seconds later, it's out of date and it's a PNG that doesn't really have a lot of value. And so, I think the direction, I think where you've gone with this as far as having a language to be able to program or in a configuration-style language define the threat model itself, I think that's going to be something that'll be able to live on Because it can become part of how software is developed. We just describe our threats in this, and like you said, then you can use the tool to pull mass results across a whole repo. You can use it to look at all the threat models in a repo and draw some conclusions from it. And so, yeah, I think where you've gone and where you're going in the future, I think this is where we need to go because developers can't just work with PNG data flow diagrams.

31:13Christian FrichotYeah. And it is quite funny. I think that's the other side. I mean, if you've worked at a handful of places and in particular organizations that have these various levels of maturity with threat modeling, no one does it the same. Like, everyone does it different. Processes kind of all— they kind of all smell similar. And like you said, when Microsoft came out with the— when they first published SDL, I mean, that was an incredible moment, really, for our entire industry. And it's quite interesting how that, for literally every company around the world, has been just this one document, right? This one document that got published, and all of a sudden, everyone was like, holy moly, like, Microsoft just published how they're trying to fix security. And part of that was the mnemonic of STRIDE. You know, it was kind of like, that's when all their threat modeling stuff came out. And Microsoft's approach to threat modeling, whilst absolutely amazing, is very, very appropriate for Microsoft. But how do you pick that up and apply that to a small company that's mostly software engineers, maybe one security person? You just can't. And I love, I love this, you know, I love this spectrum of tooling and processes that are available. And the fact that coming back to my tenets of what I believe is important, driving valuable change and documenting this so people can come into a situation and really quickly come up to speed with, like, hey, I've never worked on this product or system before, but there's this threat model and it's documented all these things. So now I kind of I think I can understand what I'm facing or what I have to kind of help you with. I mean, that could literally be, you know, sitting down in a room with a soft, you know, handful of software engineers and a product owner for an hour and just asking what could go wrong, you know, and whiteboard some stuff. And then you create a Confluence page or you create a Google Doc, and that's your threat modeling. And that's, completely acceptable and completely valuable. And then you go to this absolute other spectrum where people are using expensive enterprise threat modeling tools, and they're like, these systems do all this automation, and they integrate with the AWS environment, and they build out all these diagrams. And like, that's also just absolutely awesome. But it's just so funny, this journey that so many companies are on, just no one Like, no one's landing at the same spot. And so for me, like, going back to ThreatSpec, I loved, really loved the idea that, like you said, software is ever-evolving. And the only source of truth that software has is its code. And what's interesting is that as literally all software has been moved into a Git-style flow, not only do you have what the the reality of the product is in its current state of software, you can also kind of journey back through time. And it's kind of funny because things like ThreatSpec and HCLTM, they really try and take advantage of that, where it's like these threat modeling artifacts and these aspects of the system will change over time. And if we can make it a little bit easier for a software engineer to maintain those things, as opposed to Jumping into Miro, updating a diagram, exporting a PNG. Like, I think that's a win. It is obviously still a point of friction. Like, this is obviously— it's like a mental context switch that someone will have to do. I think ThreatSpec is very clever in the fact that it's like annotation in code because, I mean, that's the files that these people are working on constantly.

35:04Robert HurlbutYeah.

35:04Christian FrichotIt's such a cool approach. want to see more of these sorts of things. Like, I would love to see other tools like this. Um, I guess the other side of what, what, um, what this does, and it's not super, super well fleshed out, is it also has the ability to parse, um, Terraform files because a lot of the language is the same, and it can extract information assets out of, uh, Terraform as well. So the idea is that Maybe there are some shortcuts that we can offer you. It's like, cool, if you're already defining all of your cloud storage assets for Azure inside of Terraform, you can, you know, pipe the output of a Terraform command in through an aspect of HCLTM and it'll just spit out all the information asset blocks, for instance.

35:50Robert HurlbutHmm.

35:51Christian FrichotAnd I kind of like those sorts of, you know, Unix philosophy as far as being able to kind of tie commands together to handle input from something else and pipe it in and then kind of do smart things out the back of that as well. So, There's a little bit of that as well. And I think there's lots of opportunity for other tools to be doing more of that. So I'm, I'm always interested in, in looking at those sorts of things. You know, obviously working at Atlassian means I use Confluence all the time. So been doing some experiments as far as, well, this thing can output HTML files or Markdown files. Can I make it like auto-generate Confluence pages? So, I've, you know, I've done some tests in that as well, which also absolutely makes sense for certain organizations where maybe they want to manage a threat model inside of their software repo, and anytime that file is updated, have the CI/CD update a document in Confluence. I mean, that seems like a totally— that makes sense as far as use cases go.

36:48Chris RomeoYeah, I think, you know, everywhere we turn in the world of AppSec tooling now, we hear developer-centric. Like, it's, you know, we're recording this episode on April 4th, so RSA is 20 days away from right now. And I know I'm going to walk across RSA floor, and I'm going to see lots of AppSec tooling companies that are developer-centric, is what they say or what they claim to be. And so, yeah, the more I hear you kind of describe your philosophy and your approach, like, you're really doing it. You're doing developer-centric by taking threat modeling and meeting the developers where they are versus trying to do something else. And so, I also wanted to throw a couple of plugs in here.

37:26Robert HurlbutYeah.

37:29Chris Romeoto past episodes, 'cause you were talking about Microsoft and them releasing the SDL. We did an interview with Steve Lipner a few years ago where we just asked him, hey, can you tell us the whole story? Tell us the trustworthy computing story. And so, he went back to previously to the memo, the Gates memo.

37:44Christian FrichotRight.

37:45Chris RomeoAnd 'cause he was there, he was one of the initial people that founded the organization inside of Microsoft to react to the Gates memo and carry it forward in the future. And so, he told us that whole historical story. We also have— we've had Loren Confine, Felderon before, who created Stride. I always thought Adam Szostak created Stride, and then Adam yelled at me one time. Not really, he didn't yell at me, but he said, I didn't do that. It wasn't me. It was Lorne. And so, we've had a chance. So, we've had a lot of those Microsoft folks that have done a lot of— that helped us kind of lay that foundation for threat modeling, which is— it's been great to hear their stories as well.

38:20Christian FrichotAbsolutely.

38:22Chris RomeoSo, where do you think this is— where are you going to take this in the future then? What's the future of HCL TM look like?

38:28Christian FrichotYeah, I mean, I definitely— I kind of hinted at it. I think driving change out of a threat model is one of the things that, you know, a lot of the enterprise tools in this space, like, they integrate with work management style solutions. So they might integrate with Jira, or they can file GitHub issues or whatever. I think there's— there's that aspect of it is something that I'm I've got tickets to investigate how that might look. And I think that's critically important because I think being able to drive change is such an important part of threat modeling. I mean, you think back to basics, like the process is to early identify security risks and challenges and get things in place to reduce the likelihood or impact of those things eventuating before the software gets developed and published out to the internet or packaged up and pushed into an enterprise. Because as soon as it's out there, it's obviously, you know, at that point, if that vulnerability or that issue is identified, and in particular if it's an architectural issue, it's just, it's a very costly exercise. And I'm sure You know, we've all spoken about it before. It's like identifying bugs earlier is cheaper to fix than if it's something that's deployed. To get there, you have to be able to drive those changes in meaningful ways. And again, this software-centric approach is issues. Like, how do you manage issues? Where do you document your issues? And again, this is every organization does it different. Some people have Trello boards and some people use Jira. Other people just entirely use GitHub issues. And so there's kind of like, that's a, it's a, it's a big space to look at addressing. And I need to explore it.

40:28Chris RomeoDo you see it as a bidirectional communication or a unidirectional communication in HCLTM's world?

40:35Christian FrichotI'd say, I mean, that's a I've— at the moment, I'm opened. I don't know. I think in theory, it would be lovely for it to be two-way. I don't— I think the way that the language works so far, everything that it publishes out from the CLI tools has all been one-way.

40:52Chris RomeoOkay.

40:53Christian FrichotBut, I mean, there's nothing stopping it from being something that could periodically poll backwards and forwards because obviously, the whole specification is programmatic, but it's—

41:05Robert HurlbutYeah.

41:06Christian FrichotIt's not something that I've looked into too much. It's also, it's just an interesting space because even if you look at other AppSec tools out there, they don't, they don't all follow the same approach. Like if folks have used Snyk, uh, quite a bit before, or Snyk, Snyk, um, you know, this thing might identify 10,000 issues the first time you run it on a repo. Do you really want that to file 10,000 Jira tickets? You know, so it's kind of like even those tools have their funny workflows where they might have a dashboard and they'll show you all the issues and then they'll give you the opportunity to, okay, so which ones do you actually want to file as actual tickets? So, there is, there's this, there's a bit of a journey of exploration that is worth doing.

41:47Chris RomeoDo you want to immediately make enemies with everyone in engineering? File 10,000 Jira tickets then. I recommend it because they will hate your guts forever. Because one, it screws up all their metrics that they're measured against. And 2, they're the ones that have to go through and try to trudge through 10,000 issues and close them.

42:05Christian FrichotExactly. Yeah. And we haven't, like, the industry, we have not solved this problem. Like, it's all tools in this space, all, you know, any kind of code-based application security tools have this challenge, and they all solve it a little bit different. I think it's It's an interesting, it's an interesting opportunity. Like it's a, it's a space for opportunity. And there's obviously, you know, there are vendors that are looking to emerge, I imagine, in that space as far as kind of centralized AppSec style triage platforms. And I think those things are quite interesting as well.

42:41Chris RomeoYeah. Yeah. We're starting to see them. I mean, I've started to see some of them into the market, you know, that are, that are becoming kind of, I hate to call them a SIEM for AppSec tools, but that's really what you'd need, right? I mean, SIEM was created— I mean, I was doing incident response in the late '90s and early 2000s. We didn't have any correlation happening. We were just dealing with raw events coming off from security devices. So, we'd get hundreds or thousands of alerts from a given intrusion detection system with no correlation on them at all. And so, yeah, I think AppSec is ripe for some type of AppSec SIEM solution that helps to translate and funnel those 10,000 issues into really the 5 things that we care about right now. Maybe there's a policy that says, in the early days, we only care about things that are this level that are in these components. We fix those 5, and then we move on to the next stage.

43:38Christian FrichotAbsolutely. And actually, like, the policy side of things is really interesting. One of the first releases of HCLTM, I ended up having a very brief chat with Clint, uh, Gibbler over at TLDRSec. And obviously Semgrep already can parse HCL. And so he kind of jumped to the conclusion, it's like, oh, wait a minute, like you could write Semgrep rules to check. You could almost use Semgrep as a policy validation to make sure that your threat models had certain attributes. And I was like, I mean, yes. And I think that kind of comes back to— this is a— that's the really interesting approach. Unified specification languages that you could in fact do policy controls. Like, if you have a threat model file that's, you know, published, you could have a rule in Semgrep that basically, you know, flags something if someone has a whole bunch of threats but none of the controls are, you know, implemented, as an example. Um, I think all that space is just— there's, there's a lot of opportunity out there for, for this stuff. And I think you're right. I think the SIEM— I think, you know, traditionally AppSec and incident response has not been necessarily 2 parts of security that have come together as closely as they probably could have. We're seeing a lot more PSIRT, you know, product security incident response teams and capabilities emerging now. But I think, again, like, you're right, I think there's this opportunity for things to be improved in this space. It'll be exciting to see how this grows over the next few years, I would say.

45:07Chris RomeoYeah. Yeah, I'll tell you what I see at RSA. Maybe there'll be a few of you. I bet maybe the show floor— I have a feeling the show floor this year is going to be artificial intelligence is your solution to everything. If you didn't even know you have the problem, you just ask the AI, it'll tell you you have the problem and it'll tell you the solution.

45:26Christian FrichotYeah. Have you— I was trying to figure out, have you folks done— have you talked to anyone about the threat modeling, like ChatGPT for threat modeling? Because I think That stuff's kind of a little bit interesting as well. It'll be—

45:37Robert HurlbutYeah.

45:38Chris RomeoYeah, we had— we just did an episode a few episodes ago on the OWASP AI Security and Privacy Guide. And so that was very eye-opening. That was Rob Vanderveer who explained that to us. And yeah, that was just to— just that is a— I think from what I've seen, the best catalog of AI-related threats in one place so far. And it got me thinking a lot about You know, the way you can, you can mess with the, you know, mess, you know, garbage in, garbage out still applies when you're just because you're using, you know, large language models. If you give it garbage or you can manipulate the data, the training data, you can get— yeah, there's a threat to be had there. So yeah, that's something we want to dive into some more because that's, you know, it's on everybody's mind right now as far as, you know.

46:25Robert HurlbutYeah.

46:25Chris RomeoOne, how am I going to integrate ChatGPT and OpenAI into whatever it is that I build? Oh, grocery store delivery. Of course you need ChatGPT built into the app to tell you if you need eggs, you know, whatever. So Christian, what about key takeaways and or maybe a call to action? Like, what do you want our audience to do with with HCLTM or you know give them some homework?

46:49Christian FrichotYeah, I mean look, I I'm always happy to hear about people who have used it. I know. There's been a couple of blogs from folks who have kind of talked about their journeys using the tool in their organizations. I'm honestly just open to any feedback, hopefully constructive, but, you know, also I've got pretty thick skin. Honestly, I just, I love to hear about where this, where this fits into people's and organizations' processes, where it doesn't, and that's completely okay. And, The kind of like those things which are like, you know what, if it did this, then this would be tremendously valuable. I'm obviously really, really excited to hear about those sorts of things. So I mean, honestly, any eyes on it, any people doing little experiments with it, I mean, that all sounds, that sounds super exciting to me. So yeah, I would love some feedback from people.

47:46Chris RomeoAnd the best place for them to go is the GitHub repo, right?

47:49Christian FrichotAbsolutely. Yep. Yeah, I've got the discussions feature turned on. I don't use it too much, but I know people have thrown suggestions in there. Like, one of the issues that I'm working on right now is looking at the— Irius Risk have the OTM, the Open Threat Model spec. And so it obviously makes sense that they're part of the outboard— like, the output could be like, oh, you can specify that you're going to generate threat models using that specification as well. Which totally makes sense. So yeah, any ideas like that, can't promise that they're all going to get done in a short period of time. But, and also, I mean, honestly, if people are comfortable with Golang and want to contribute pull requests, super excited about that as well. So yeah, any help.

48:36Chris RomeoVery cool. Very cool. Christian, thanks for all of your efforts developing this tool and making it open source and making it available to the community. It's You know, Robert and I are both passionate threat modelers, and so it's great to see tools that provide other, you know, other ways of thinking for people to try out and see if it fits. Like you said, like, everybody does this differently. And so there's a percentage of the world that will really latch on to using HCL as the language to define their threat models and embed it in their developer's workflow. So, thank you for all the work and effort you've put into the tool. Also, thank you for sharing the story with us. We look forward to a future conversation with you about something else related to threat modeling.

49:19Christian FrichotFantastic. Honestly, thank you so much both for having me on today. It's been an absolute, absolute pleasure. I've had a lot of fun.