Tony UcedaVelez -- PASTA: Not Just for Breakfast Anymore

0:05Chris RomeoThe Application Security Podcast. Here we go. Welcome, friends. This is our 3rd interview from ISC² Security Congress. We're joined by Tony Isidro Velez, or Tony UV, founder and CEO of VerSprite, a global security consulting firm based in Atlanta, Georgia. Tony leads the OWASP Atlanta chapter as well as BSides Atlanta. This is a deep dive into Tony's experience with threat modeling. We explore the PASTA methodology that he created.

1:00Robert HurlbutEnjoy! Hi, it's Robert Hurlbut, and I'm here with Chris Romeo, and we're at the ISC² Security Congress in Orlando, Florida. And today we have Tony UcedaVelez, who usually goes by Tony UV. He is the CEO and founder of Vercel. And welcome, Tony.

1:18Tony UcedaVelezThanks, Robert. Thanks, Chris, for having me. Pleasure being here.

1:22Robert HurlbutGreat, great. Well, to start off with, what we usually do is we ask everyone, and everyone has one, an origin story, or as we call it, our superhero origin story. How did you get into security? You know, the things that were interesting to you, how did those come about?

1:37Tony UcedaVelezThat's a great question. I think my origin story is going to be very similar to many other superheroes in security, in the sense that I have a lot of IT roots. that began— were really kind of peppered along software development, security— actually not security, IT architecture, system administration, network engineering. And so doing that for a couple of years really allowed me to understand, you know, different types of threats at the— across the OSI model. So you have physical-related, you know, threats, you have network-related threats, you have application-related threats. And so getting a good foundation of network topologies, different ways in which schematics, you know, were put into place at different organizations was definitely very beneficial. Being a system administrator allowed me to basically get a good appreciation for things like patching today or system hardening or user management, service management. And then finally, as a developer, more importantly, you know, I really began to understand and appreciate how call flows happen in an application stack, dependencies on compiled binaries, maybe as part of a framework, and then also the data flow. How does an application handle and manage data?

3:03Chris RomeoSo you say call flow, what do you mean? What do you mean by call flow?

3:06Tony UcedaVelezProgrammatic call flows in, in an application where, you know, one You know, class might call, invoke another class. One function may actually, you know, call another function. So, you know, fast forward to today, that's really important in security to see what is the implicit trust that exists between callers in an application. And, you know, as we'll— as many have found out over the years, there's a lot of implicit trust models that exist in application security. So that background in IT really led me to security in the sense that IT— and this is back in the late '90s, early 2000s— wasn't really as dynamically changing as security. Security, I mean, there was just an evolving threat landscape really that was changing every single day. And for many organizations, security was you know, not even on the radar. So the threats, the threat motives, the exploits were all coming about very fast, and that seemed to be a lot more dynamic than the more static roles of system administration or imaging, imaging new servers or enhancing code or writing new code applications, which may have been just simply a variant of the last 4 versions that I may have written for a given application. So it really caught my attention. It was exciting. It also had a little edge, you know, in the sense that now you're thinking a little bit more dysfunctionally instead of functionally. When you're a sysadmin or a network engineer, you're building networks, you're building subnets, you're writing applications. But when you're a security person, you're really having to think a little bit more nefariously about what could happen.

5:00Robert HurlbutOkay, great. So, and I'm familiar with some of your work in terms of threat modeling. That's been my passion as well, and you and I have talked about that before, but I'd like for you to talk a little bit about some of your work in the last few years on this new way of thinking of threat modeling called PASTA. Other than a dish, what is PASTA?

5:22Chris RomeoYeah, I love pasta, by the way.

5:25Tony UcedaVelezPASTA is an acronym that me and my co-author, who is Marco Marana, We both are heavily involved in the OWASP organization, which is an open-source application security project. And we basically, we recognized a big problem. This was about 8 years ago where a lot of the efforts in security were very adversarial in trying to convince information owners and technology owners about what was wrong with their application. Yeah. And so we spent a lot of time researching about ways in which there could be a more collaborative environment. And so threat— there was already threat modeling methodologies that were out there, and Microsoft was at that time evolving its software-related approaches to application threat modeling. But POSTA is an acronym that actually stands for Process for Attack Simulation and Threat Analysis. And it provides a risk-based approach so that developers and companies overall can start to protect what matters within their applications. So instead of boiling the ocean, and many developers felt like, when is the security remediation list going to end, it was about really attacking the threats that were most likely to happen that created the biggest impact against an application and that you could really substantiate some of these threat claims with evidence for exploitation. So it really aimed to increase the probabilistic analysis for which exploitation could occur. Really, the psychology behind PASTA as a threat modeling methodology was really to think like an adversary, to think like a criminal and say, what do I want and how do I go about getting it without getting caught? And so we thought that sort of mindset going into a methodology would help to prove the exploitability factor of different attacks. And so PASA today is a 7-stage methodology for threat modeling, for application threat modeling, and it focuses on what is the context of business and information that the application manages, one. 2, what is the technology footprint of that application architecturally? You know, are there load balancers upstream? Are there proxies upstream to a web application? How does that impact and affect things like TLS handshakes? Are they terminating at a web proxy? Are they actually ending at the web server? Um, so you want to be able to understand what is the footprint of your technology. And then third stage is really simple. It's about mapping together the different application components in terms of information and actors for the application— what, what user is running different types of calls— and just doing things like data flow diagramming. After that, we want to be able to understand what threats are most likely to affect the application environment based upon substantial threat intelligence. And that's one of the things that we didn't see that other frameworks had, is a way to take in current threat intel into a methodology to shape what you're actually going to mitigate.

8:48Chris RomeoNow, is that coming from the organization, or is there, is there an OWASP threat intel that I can ingest, or do I have to get this from my InfoSec folks?

9:00Tony UcedaVelezThat's a great question, Chris, because It's a challenge. The reality is that with the PASTA framework suggests you get them from both places, but it calls them— it calls it 2 different names. One is threat data, which is data that you harvest within your organization. Your application logs, your system logs, your network logs are telling you something. Attackers, different types of injection payloads that are being attempted, all these things are— can be logged. And so they're already giving you some insight in terms of what's happening nefariously against your application. So that's threat data. Next you have is threat intel, which is what is the world seeing? If I'm in— if I'm a financial institution and I have a pool of web applications, you know, and I'm XYZ Bank, what is ABC Bank seeing in terms of threats? And so those threats are oftentimes consumable through different nonprofit or industry groups like FS-ISAC or the RISC Cyber Information Security Consortium, which is one for retail.

10:06Chris RomeoAnd these are groups of those, of companies that are in those categories, finance or retail, where they gather, they gather sometimes, but they also share a lot of data electronically, right?

10:18Tony UcedaVelezYeah, so that's the, you know, there's been a movement for quite some time of threat sharing. And let's take one that's called IT-ISAC. IT-ISAC is aimed at service providers like Akamai, Rackspace, Internap that are hosting your web application potentially.

10:36Chris RomeoMm-hmm.

10:37Tony UcedaVelezAnd they're concerned about IT-based attacks around DDoS. So they get together and they— it is supposed to really foster show and tell. What are you seeing? You know, what GeoIP places are hitting you up and what is the the ransom-based note that you got that you were going to get DDoSed. And in conjunction with working with FBI, Secret Service, and different other law enforcement agencies, these groups exist to say this is a problem that the industry is facing. So threat intel does that. And just to finish out the framework, you know, so there's— after threat analysis, you go into what's wrong with a vulnerability analysis for your applications. And then you, you want to prove what's wrong by exploitation. And that is basically stage 6 in the PAS methodology, is showing proof of concepts for exploitation. And then because this is a risk-centric approach, it ends with a residual risk analysis and countermeasure development phase where, based upon the actual threats that have the biggest impact identified in step 1, What are the remediation or countermeasure strategies that you want to take as an application owner, as a developer, as a product owner?

11:56Chris RomeoSo, I got one question here that's a bit of a hot-button issue for me. I first heard Adam Szostak from Microsoft, or who used to be at Microsoft, when he was speaking about the idea of thinking like a hacker. And he came out with a very public action against that idea, the idea of getting people to think like a hacker, because it's almost from his perspective, and I tend to lean this way as well, it's very difficult to actually teach someone who's not a criminal to think like a criminal.

12:31Tony UcedaVelezYep.

12:32Chris RomeoSo I'm curious, when I heard that, when you were talking about the think like an adversary, think like a criminal, I'm curious as to how you get there with with people that are using this methodology. Is it, in your experience, have you found a way to get those people to really truly be able to put on the black hat and understand the motivation behind it? Or what's, how would you respond to that?

12:55Robert HurlbutSure.

12:56Tony UcedaVelezI think this problem has existed even before security, and I'll just go back to my superhero days of development and working with QA. So how many developers out there would say, if I could only get you to think like a developer, when you are testing my application. Or even the product manager might say, if I can only get my QA individuals to test more like a product owner. You know, how would you actually use my application, my product, now that you have bought it off the shelf, metaphorically speaking? So, you know, to answer your question, I think that it is needed to think like a hacker because if we do not, then we simply revert back to the status quo of checklists, and it becomes more of an audit function. So you do have a plethora of top professionals out there, you know, across, you know, different organizations that are affiliated with ISC² or ISACA or OWASP, and, you know, the, the list goes on and on. But there's all these prescriptive checks that are devoid of one important thing. 2 important things. One is context. I have a checklist of things that you need to check for, but I don't know what technology set you're using. I don't know the context of information you're using. I don't even know who your threat adversaries are.

14:14Chris RomeoRight.

14:14Tony UcedaVelezAnd what's happening is, is that for those that are consuming it, they're like, you know, they're just simply looking at it pragmatically. Let me just do what I need to do to get over this hurdle and get this out of the way. So, what that actually does psychologically and what we've been seeing that pre any sort of threat modeling from Microsoft or POSTA or anything else is that you have an audit-like approach to security. And so, the intent is to go beyond that status quo mindset. And so, I will recognize that it is very much a challenge to basically think functionally as a developer because that's— you're being paid literally to do that.

14:54Chris RomeoYep.

14:55Tony UcedaVelezAnd then to conversely also think about how to destroy your application at the same time. I mean, that is pretty masochistic because every developer loves their application, loves their creation. Yeah.

15:07Chris RomeoThey're thinking, I'm building this thing, why am I going to try to destroy it? And where Adam ended up with this idea is he was advocating for people to think like a security person. And so I've kind of taken that moniker as well. I would agree with you 100%. We don't want people doing checklists, checkboxes. That's— I don't call that security, that's called compliance. And people are going to maybe tweet at us and not like that fact, but you know what? Checkboxes are not security, they're compliance. And that's just the truth. But I like— I just like the way he put it up, teach people to think like a security person, because we want them to think like us.

15:43Robert HurlbutRight.

15:44Chris RomeoWe don't want them to think— because as security professionals, we have— we can put on the the ideas for how these people attack without necessarily knowing all the steps or being able to demonstrate the exploitation kind of in real time. So I just like where he ended up on that. Think like a security person versus think like a hacker.

16:04Tony UcedaVelezSure. But in essence, I mean, if you think about, you know, and let's kind of take a page from physical security. If you think about, you know, at a more personal level, you know, our homes that maybe we use and you use like home monitoring. So you would want, you know, ADT or Ackerman or whoever you're using to know what's going on in terms of like socioeconomic factors that cause break-ins, or if they see a rise in certain types of assaults, because you're relying on their operations center, which are monitoring your house, to be cognizant of, hey, there's a spike in this type of attack, smash and grab, or home invasions of this type. And that really affects how we defend. And so thinking like a security person, in my— when I listen to that, you know, I basically, I see more of that related to being an auditor because there's been an erosion, unfortunately. I think that thinking like a security person as intended and as designed for that word security, then yes, I agree. But where we're at today is that with a heavily— still, I mean, we're in 2016. It's still a very compliance-driven approach to businesses.

17:24Robert HurlbutSure.

17:24Tony UcedaVelezSo, you know, they want to— they ask the questions, well, what does the PCI Council say? Or what does OCR and HHS say? Or, you know, what does my clients say about what they want? And if they basically say NIST 800-53 and COBIT and CSA Framework and OWASP, you know, ASVS, guess what? It turns into a binary exercise of do you have, do you not have?

17:49Robert HurlbutSure.

17:49Tony UcedaVelezUnder the thin veil of security. So I don't think there's anything wrong with that. I think it's good. I think that it is a slippery slope that as security professionals, you know, you get trapped into that mindset.

18:02Robert HurlbutAll right, and at this conference you're talking about attack trees and cloud containers, right?

18:08Tony UcedaVelezYes.

18:09Robert HurlbutTell us more about that. Sure.

18:11Tony UcedaVelezSo, you know, what's really fascinating, and almost so fascinating that, you know, you always want to go back to the superhero days where it all started in IT, is DevOps, you know, because DevOps has a huge opportunity to do preemptive security hardening and mitigation at so many different layers, you know, everything at the kernel layer of your operating system, at the application layer, your RBAC model, you know, your role-based access control model for your applications, all through these codified manifests, or, you know, basically, for a lack of a better word, XML documents that are providing configurations how everything should work. So with Docker and Dockerfiles, you have basically prescriptive controls that can be baked into your images, your application images. It's definitely an exciting time. So I thought it would be opportune to, again, think like an attacker and think there's a lot of companies that are kind of beta testing this out. What, what are the concerns? What is actually happening in terms of threats today? What has happened? And so today's talk really basically helps those that are interested in containerizing their monolithic applications and decoupling them into understanding what some of the more advanced risks are. And, you know, this is still an evolving threat landscape around Dockers, but there's some easy ways in for hacker syndicate groups, and I think very savvy nation-states that want persistence and infrastructures to, to be able to take advantage of the phenomena around DevOps, containerization, and adopting microservices. So the talk really focuses around, you know, what types of attacks are prevalent and are being witnessed today.

20:08Robert HurlbutOkay, and you're talking about ATT&CK trees. Could you tell us what that is?

20:11Tony UcedaVelezSure, sure, yeah. So an ATT&CK tree, you know, just kind of taking it back to the PAWSTAT threat modeling methodology, really is, is ties into stage 6, which is exploitation and attack analysis. So attack tree is a visual representation of a logical sequence of attacks against exposed weaknesses or vulnerabilities in an application, application framework, or even system platform. It could even encompass some other third-party software that an attacker knows or a development team knows is being used within an application environment. So if you can imagine like a tree-like, you know, uh, formation where you up top you have a threat and every threat is idle unless it's actually realized, supported by an attack, right? So we want to be able to, at the top of this tree, have a threat that is supported by What are the ways in which the threat gets actualized? So let's take the threat of, I want to steal personal identifiable information from a government site that manages personnel, you know, personal identifiable information. So that might be, you know, different government entities from the VA to the IRS and lower operating divisions. So let's say they have a web presence. So my threat's already been, you know, defined. How do I go do that? As an attacker, I want to see what types of web applications they have to support the harvesting and collection of PII, number one. So find that out, do some open-source intelligence gathering. Once I find a nice, juicy website, web application that has use cases that support sign-on, account creation, and I go through that process as a hacker, I see that name, address, phone number, and maybe some personal data points like date of birth, driver's license, or Social Security number gets— is actually factored into the use cases of that application. So, you know, I see that there's, you know, app— the application has, you know, different POST requests. I might, as a security tester, see what those POST requests look like when submitting the data, how they're protected, and then start to do some, some fuzzing techniques, which is basically— fuzzing is just a word where you're playing 20 questions with an application. But as I'm kind of showing, it's a logical sequence of realizing a goal, and the ATT&CK tree basically has each node in the tree is either an attack or it's a weakness that is attached to an attack branch where the attack will actually take advantage of that known weakness. So in my testing, I might find out that a particular use case in a web application does not do any sort of character escaping or doesn't do any sort of input validation. So I will go for— that's a weakness. And I will go and I will try to basically do some injection-based attacks using some malicious JavaScript payloads and see what information, you know, how the application reacts. And so, you know, it's basically, it's a, it's a way to, or it's great in the sense that it provides a logical representation for developers to kind of see the logic behind certain attack flows. And, you know, as the cliché goes, you know, a picture is worth a thousand words. It's really educational for developers to see that. And then, you know, really to add the cherry on top, if you have a security pen tester or application tester that exemplifies that these attacks can happen, then the developers are like, oh, I see it and I get it and it's been done. Let me fix it.

24:13Robert HurlbutOkay. I can remember, you know, years ago, Bruce Schneier came out with his paper on ATT&CK trees, which is a great resource. So for our listeners, if you're interested in learning more about ATT&CK trees, Bruce Schneier wrote a great— just look it up on ATT&CK trees, Bruce Schneier.

24:30Chris RomeoI do have a question about ATT&CK trees in general. Is there a— it seems like ATT&CK trees would be reusable from different, even different organizations. Many people are going to have that same threat of steal PII from my web apps. So is there a place where people are combining these? Is OWASP doing it, or where, where can I go find some good models, some good ATT&CK tree models to look at?

24:54Tony UcedaVelezThat's an awesome question, and you're sharing in my vision to basically take over the OWASP Threat Modeling Project. So that is exactly that. For a long time, just to your point, Chris, I mean, a lot of companies, even across industry, you know, there's a website, they have similar use cases like authentication, you know, sign up, you know, different types of things. And some of the threats and attack patterns would really be beneficial to consume on a mass basis. So what we're trying to do is, as part of a future project that— there's currently an OWASP threat modeling project. We've had, at the heels of AppSec EU in Romeo, Italy this past summer, I met with a lot of threat modeling evangelists and we've been talking about doing just that, you know, building, you know, a resource where developers can see if you have this flavor of a web application or web framework, you inherently have these types of threats. Or if you're in this industry and you have this data model, you inherently have these threats. It's not to say that everything is going to pertain to you, but at least it provides some prescriptive visualization on attacks that they can basically see what the countermeasures are.

26:12Chris RomeoSo how do you see that fitting in with— so MITRE's got a number of projects. They've got the CAPEC, Common Attack Pattern database. They have the CWE, the Common Weakness Enumeration. Is that— do you see what you're talking about here as being complementary to those, or being— would you take data from CAPEC, for example, and use that to fill out your model?

26:36Tony UcedaVelezAbsolutely, absolutely. I mean, another cliché, you know, why reinvent the wheel when there's been You know, those CAPEX, those CVEs, those CWEs, they've—

26:45Chris Romeothey're—

26:45Tony UcedaVelezthey've— the contribution MITRE really, as heavily funded by DHS, is it has gotten a lot of those entries from the community.

26:54Chris RomeoYep.

26:54Tony UcedaVelezSo I mean, it would be— the recommendation definitely is to leverage that content. That's an enormous wealth of information, um, and CWEs in terms of, uh, added content is climbing. You have tool providers that are now using that taxonomy in their sets. So there's a common vernacular, if you will, of using what is an ATT&CK pattern? Oh, well, that's a CAPEC reference. What's a weakness pattern? Well, that's, you know, a CWE reference. So definitely there's some in the industry obviously that say, well, those are, you know, there's not enough breadth or there's not— there's always room for improvement on any sort of like, you know, content.

27:35Robert HurlbutTrue.

27:35Tony UcedaVelezSure. So, at the end of the day, we have a content management problem, right, in terms of a library. And that's why the Microsoft tool limits itself because it doesn't provide interoperability with CAPEX. It doesn't provide interoperability with, you know, these threat intel sources that are prevalent everywhere.

27:53Chris RomeoAnd I'm convinced that they did that on purpose, though, because I've tried threat modeling from both perspectives for large organizations. I've tried, using a custom database that's fed from things like CWE and CAPEC. And then, because we start with, in a past life job experience, we started with STRIDE as our methodology. And then we said, ah, it's too simple, it's too easy. So we built a database from CAPEC and CWE and others and used that to provide people with threats. But then we ended up bringing STRIDE back in because we realized it was, especially for somebody that's brand new to threat modeling. If you've been doing threat modeling for a while, CAPEC and CWE, that just makes sense. It clicks for you. see the connections. But if you take a developer who's never threat modeled before and sit it down in front of them, if you give them that STRIDE methodology, it's simple enough that at least gets the light bulb starts to flicker and boom, the light bulb goes on over their head. Once that happens, then they're ready for the depth and breadth of the universe.

28:52Robert HurlbutRight.

28:53Tony UcedaVelezYeah, I agree. I agree to the fact that if developers have never done threat modeling, ingesting CWEs and all these other alphabet soups, type designations is complex. But, you know, one thing I don't want to contaminate is the true, you know, notion of threats and how it's basically a hierarchy. Threats should really encompass attack patterns, you know, which would be a CAPEC. And what we want, you know, from a risk-centric approach is to basically convey to developers, understand what threats are happening, you know, against applications of your type and understand attack patterns that exist. You know, attack patterns are things like SQL injection or cross-site request forgery or session fixation and stuff like that. So these are attacks, but there's a means to a madness that they support an overarching threat motive. And so with the risk analysis in the tree, they see, well, it's less— this weakness exists in my application, but I have other mitigating controls architecturally, or in order to exploit this weakness in the tree, you know, they would have to— these other conditions would have to apply. So it, you know, the risk-centric approach is trying to solve the problem of there's too many security problems that we have, and it is impossible to think that we're going to, you know, even have a, um, a level of risk that excludes all, you know, the high, medium, lows that you see in your traditional static and dynamic, you know, uh, test— testing, uh, software. So, um, we want to be able to, to help developers think in the context of what's important, and that helps with prioritization. And so at the end of the day, we just want threat modeling to grow.

30:48Robert HurlbutYep.

30:49Tony UcedaVelezAnd so, to your point, it has to be easier. It has to fit in line with agile SDLC methodologies because that's where the majority of the world is going, especially with the proliferation of DevOps.

31:01Robert HurlbutYeah.

31:02Tony UcedaVelezSo, it can't be this long, you know, laborious process that's gonna just make everyone grind to a halt. It also has to be prescriptive, but at the same time, we, we we want to be able to feed this threat model. And like, like the ATT&CK trees are living artifacts, the threat model should be a living artifact because the threat landscape is changing.

31:25Chris RomeoSure.

31:25Tony UcedaVelezSo that's, you know, that's something that's important to emphasize there. But anyway, I think we're, we're all seeing, you know, we're all trying to just get threat modeling to be more widely adopted as an exercise. One of my favorite things that I saw from a developer on Twitter was the fact that, you know, when they do threat modeling, and they do some whiteboarding and they do some data flow diagramming, and they just have someone at the table where they're doing the, the whiteboarding to basically add that context of threats. That's all it takes. You know, this is what we're seeing for these types of web applications, mobile web APIs, you know, for this client-server environments. You know, they don't have that context. And so, uh, this is, I think, where we You know, Adam Szostak and I would agree is that getting that security professional to say, hey, I'm in tune with what's going on. So you're drawing a DFD and let me show you the ingress points or how trust models within your data flow diagram can be abused given your existing calls. Here's a simple one, right? So oftentimes you have a traditional 3-tiered environment: presentation layer, app layer, and data layer. Application calls to the backend are oftentimes under one actor, one service account in an integrated authentication model to a backend store, and it's, it's not in line with all types of use cases of the application. So if your application has a use case of Let me run a report. The service account that's making that backend DB call might be, you know, might be an elevated account. It's not— doesn't just have read privileges to a view object in a database schema. It might have read, write, create, delete to, you know, an actual table object, which is much more dangerous. So simple things like that developers get, and once they get it, they systematically bake it in. And now it's cognitive, and they don't repeat some of this, some of the standard issues over and over. I think that with threat modeling, you know, it'll provide an educational factor to developers to, to, to be security conscious. It's not, you know, saying that they should think like an attacker is, is, is not meant to make them to do away with their functional mindset. It's, it's meant for them to take a step back look at their creation and architecture and think, what could go wrong based upon what my internal or external expertise security friends are telling me? And that's the point.

34:04Chris RomeoYeah, and I refer to that when I'm teaching people how to threat model. I say, what's the worst-case scenario? Give me that. Give me the worst. Don't give me the stuff in the middle, the small things. Tell me what the worst thing is that could happen to this.

34:15Tony UcedaVelezRight.

34:16Chris RomeoAnd causing people to focus in on that leaves all the noise in the background, and then they say, well, then it would be this. This is thing, and then we can work from there and move forward.

34:25Tony UcedaVelezExactly right.

34:27Robert HurlbutOkay, well, to close out, let's ask if you could give us kind of a call to action. What should we do today, taking some of the things that you've talked about, we've talked about today? What would you call people to do? Call to action.

34:40Tony UcedaVelezWell, I think there's— that's a great question, Robert. I think, you know, there's different roles and responsibilities for that. The developers, I think, need to start to ponder about embracing application threat modeling as part of their STLC process, and ideally within their— even their definition phase. You can do that with PASTA, but most typically with threat modeling, they do it in the design phase where they start to kind of, you know, start to position things out, do data flow diagramming, and see, you know, what, um, what calls could be abused. But, uh, so there's a call to action for developers to embrace this, inquire about this more into their software development lifecycle. I think that project managers, uh, the ones that are basically using the leather whip on the backs of developers or product managers, they should also factor in and recognize that baking in this into their product lifecycle, because they have their mantra is let me get my product out on time or before time. So, I can beat the market, beat my competitors, and go-to-market plan. They need to realize that sustainability of reliable applications is something that has financial metrics tied to it. So, there is the traditional approach of rolling out code that's buggy, that is non-sustainable, that has issues, affects product adoption, affects confidence in the product by those that are consuming it. And if they just take a little bit more time in understanding, you know, what extra hours should be factored in to allow for threat modeling, they should really factor that. So that's our call to action for project managers and for development managers as well. And then lastly, I think for security professionals, security professionals are right now, there's a sea of threat intel being thrown our way. You know, it's like a cafeteria food of really a lot of bad and fatty information, you know, as it relates to threat intelligence. And we need to discern. I mean, I'm not gonna name any names, but there's been plenty of evidence over the past 5 years while threat intel-related companies are not really producing quality data. So security professionals within organizations that are alongside these product managers and developers need to start to basically have their stethoscope to good, credible threat intel that is correlated to the application frameworks that their developers are using, the data model of their applications, and that requires them to understand architecture. That's one of the biggest deficiencies I see in security today is the fact that most security professionals do not have a good understanding of TOGAF or SAPSA or traditional IT architecture, and they need to understand that along with these evolving application frameworks— Struts, Spring, these microframeworks that exist today like Scala. They need to get on board because they cannot interface with their developers and give them the necessary pieces of information if they don't even understand how these frameworks are facilitating authorization models, authentication, etc.

38:05Robert HurlbutSo, okay, all right, great. Well, thanks, Tony, for stopping by and talking with us.

38:12Chris RomeoI really appreciate it.

38:13Tony UcedaVelezMy pleasure. Thanks to you both. Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Cartenberg.

38:27Robert HurlbutYou can find us on Twitter At AppSec Podcast or on the web at www.appsecpodcast.org.