---
title: "Alex Mor -- Application Risk Profiling at Scale"
url: https://appsecpodcast.com/alex-mor-application-risk-profiling-at-scale/
date: 2022-03-15
duration_seconds: 2566
guests: ["Alex Mor"]
topics: ["Threat Modeling", "Security Testing", "Software Supply Chain", "Privacy and Compliance"]
audio: https://www.buzzsprout.com/1730684/episodes/10255751-alex-mor-application-risk-profiling-at-scale.mp3
video: https://www.youtube.com/watch?v=bW4oE7BqJXI
transcript: true
---

# Alex Mor -- Application Risk Profiling at Scale

*March 15, 2022 · 43 min*

with [Alex Mor](https://appsecpodcast.com/guests/alex-mor/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [Security Testing](https://appsecpodcast.com/topics/security-testing/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [Privacy and Compliance](https://appsecpodcast.com/topics/privacy-and-compliance/)

[Audio](https://www.buzzsprout.com/1730684/episodes/10255751-alex-mor-application-risk-profiling-at-scale.mp3) · [Video](https://www.youtube.com/watch?v=bW4oE7BqJXI)

## Show notes

Alex Mor is a passionate cybersecurity defender or breaker depending on the time of day, providing expert technical guidance to product teams and building security in their platforms. Alex joins us to talk about application risk profiling. He defines what this concept is to help us understand it. Then we talk about how can you do application risk profiling at scale? Whether you have ten applications or 1500 applications? How do you bring this together and gain real true security value from this idea of profiling your applications? We hope you enjoyed this conversation with Alex Mor. Twitter: @nashcontrol Alex Moore is a passionate cybersecurity defender or breaker, depending on the time of day, providing expert technical guidance to product teams in building security in their platforms.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Alex Moore is a passionate cybersecurity defender or breaker, depending on the time of day, providing expert technical guidance to product teams in building security in their platforms.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Alex Mor:  
→ [OWASP SAMM](https://owaspsamm.org/)  
→ [Alyssa Miller](https://alyssasec.com/)

Mentioned in this episode:  
→ [OWASP SAMM](https://owaspsamm.org/)  
→ [Alyssa Miller](https://alyssasec.com/)  
→ [Alyssa Miller](https://twitter.com/AlyssaM_InfoSec)

Chapters:  
00:00 Meet Alex Mor: Application Risk Profiling at Scale  
06:48 Given that you've had quite a bit of pen testing experience  
09:04 Yeah, and it's interesting for me as I'm thinking about this  
14:06 About what do you mean when you say application risk profiling  
20:10 Knew Excel  
24:07 Alex, who's answering those questions then  
27:55 You got it as a low. So how do we govern  
34:13 One of the things we like to do is, let's imagine

## Transcript

*6,939 words · assemblyai*

**0:00 Chris Romeo:** Alex Moore is a passionate cybersecurity defender or breaker, depending on the time of day, providing expert technical guidance to product teams in building security in their platforms. Alex joins us to talk about application risk profiling. He defines what this concept is to help us understand it, and then we talk about how can you do application risk profiling at scale, whether you have 10 applications or 1,500 applications? How do you bring this together and gain real, true security value from this idea of profiling your applications? We hope you enjoy this conversation with Alex Moore. You're about to listen to AppSec Podcast.

**0:43 Alex Mor:** When you're done with this, be sure to check out our other show, High Five.

**0:47 Chris Romeo:** Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I'm the CEO of Security Journey. Robert is unable to join us this morning, so it's just me flying solo on the podcast. And I am excited to say that I'm joined by Alex Moore, and we're going to talk about this idea of application risk profiling. But before we get there, Alex, our audience always sits on the edge of their seat, whether that's in the car, whether that's on the couch, whatever seat they're sitting on, they're always on the edge of it because they want to know How did you get into application security? And I find these fascinating, just FYI, because we have heard 175 different stories throughout the lifetime of the AppSec Podcast. And it's funny, none of them have been the same. Everyone has had a different story for how they've gotten to AppSec. So how'd you get into AppSec, Alex? Cool.

**1:39 Alex Mor:** Hey, Chris, thanks for inviting me. Really happy to be here. So, you know, just FYI, right? I'm based out of Israel, so I'm probably gonna have a different story just like everyone else. Um, just FYI on, on how— where am I today, right? Um, ABI, largest, uh, beer brewer. Uh, so the story of how I got to work in the largest, uh, beer brewer, uh, in the world. Um, so start my, my journey around 1998, uh, more or less. I think, you know, I was around, uh, 16— sorry, 12. Um, and the internet was just starting, right? We had some static pages, some people, uh, just, just going and reading content. And, and so I started building, uh, static HTML web pages, and, and that was the thing, right? You would, you would open the tags and it was— you would bring a big, um, uh, text and you could change the font. And that was the amazing thing of the internet, uh, back then. Um, so a few years forward, uh, I got a link to something called Cyber Army. Uh, it's like, it's a union, it's like volunteers for, uh, for free internet, you know, spamless, censorshipless, malwareless. I was about 16 at the time, so I signed up and I saw that one can become an officer by completing some challenges. They were called Zebulun challenges. And, you know, I just checked and it's still online. So this is when I first got introduced to SQL injection. So we're talking about almost more than 20 years ago. SQL injection was becoming popular. Because, you know, people were developing applications, developing products, but didn't really go into how to securely build it. And I think back in the time, even the frameworks that we were using, right, you know, the beginning of PHP, you would not have a secure way of doing SQL queries, right? You would have to sanitize, remove some characters. Anyway, so that's where I was introduced to SQL injection, cross-site scripting, privilege escalation, cookie poisoning attacks, right? This is what we would do when you would identify someone by their session ID or by their email that was in the cookies. You would change that email, you would become someone else, right? So a few years forward in Israel, it's mandatory to serve in the military. So I joined the infantry, served there for 4 years. Afterwards, was discharged and was kind of looking for places, looking for something to learn, looking for something to do. And my parents pushed me, okay, you have to do a bachelor's degree. That's really important nowadays. But then I didn't have good scores. I didn't have a good SAT score. So I got accepted to physics degree and that's what I studied, physics. Really tried to go learn from some of the other departments, from computer science and electrical engineering, so learned some Java, learned some C on the way. But then, you know, I kept kind of maintaining that skillset of cybersecurity, of hacking, some here, some there on some free, you know, learning exercises, right? So then I finished my degree and I was looking for a job and they said, man, you have a bachelor's degree in physics, you can come and radiate people in the hospital, help them get better. From cancer. And man, I said, maybe I'm unfit for something else. And that's when I saw a position at Ernst Young Consulting. They just acquired a company called Hactix. So they just joined the Ernst Young firm in Israel. The interview was really easy for me. They just asked me, you know, how do you do cross-site scripting? How do you do SQL injection? Man, I've been doing that for 10 years. So I got accepted for that job. You know, and then the rest is history, right? The whole career path from a penetration tester, managing consultant, got to know a lot of companies and different products and really interesting, you know, implementations of different technologies with different developers or by different developers. So then I got into security architecture and cloud, also started becoming more available and everyone were kind of switching to the cloud. And then I had an opportunity, you know, to come and build an application security program with ABI. And so I've been with ABI for the past 2 years. Very cool.

**6:08 Chris Romeo:** Very cool. So from physics, started in security kind of, you know, as a young person, made your way through the military into the university to study physics, and now Back into security for a few years.

**6:23 Alex Mor:** Back into security. So defending, defending, you know, breaking into our own applications to help our product teams improve them and really make better and more resilient and harder to break into, you know? So, you know, with every release we find new things. With every release we find new ways to compromise our applications. So we try to be one step ahead of the attackers every day.

**6:48 Chris Romeo:** So, given that you've had quite a bit of pen testing experience and breaking experience, I'm curious to see how do you think the industry approaches pen testing? Do you, as someone who's got a lot of experience in that and someone who's now building an AppSec program or in the process of building an AppSec program inside a large company, Does the industry put too much emphasis on pentesting and breaking or not enough emphasis, or what's your take on that issue?

**7:20 Alex Mor:** First of all, I like pentesting, right? If I need to do a quick assessment, and there's always a question like, would you do threat modeling? Would you do a risk assessment, or would you do pentesting? You know? And that's the question of how deep can you do the pentest? Right? Can you do a white box pen test that would have access to the code? You'd have access to the cloud. You'd have access to an environment, and then you can combine the best of breed, right? You can go and see the APIs. You can see the services. You can see the server. You can see what files are there in the deployment, and then you can just really use your time wisely and attack the functionality and attack the business. cases rather than just brute forcing and fuzzing and, you know, wasting 3 days just to do enumeration or reconnaissance. So I really like doing pen testing, you know, and we have today kind of in ABI, we have an AppSec team that's more focused on doing the code review and the white box penetration testing. We have a pen test team that has the same access to the same code, but they're coming from an attacker perspective, right? So they're trying to also to break into that. So, We, again, for me, I think pen testing can really get you a gap analysis, right? You wanna know what your gaps in your application, you do a pen test. You wanna understand how exposed are you to the world, you do a pen test. And you try to do that white box, right? Not black box because the black box really misses, you know, 30, 40% of your attack surface.

**9:03 Chris Romeo:** Yeah, and it's interesting for me as I'm thinking about this because the scenario you just described, I come at this from a different perspective. I've spent a lot of time focusing on threat modeling. I did some pen testing, but it was back when the years began with 19. So it's been a long time. And certainly, I know how to exploit SQL injection, cross-site scripting, all the AppSec-related things. But when I think about the scenario of how do I start if I'm looking at something, I'm thinking through the lens of the threat model. And the reason I look through the lens of the threat model is I feel like I can do less total amount of time, less effort to be able to look at something from the threat modeling lens. It's almost like I'm looking at it from the 10,000-foot view outside of the airplane, whereas I think of the pen test as being a lot closer to the ground because you're really getting into more of the nitty-gritty perspective. Now, I know both of those things are important. But it's just philosophy of AppSec, I guess, is— and it's okay. We all come from different perspectives and different backgrounds. But what do you see as threat modeling's role in the way that you approach looking at a given application?

**10:12 Alex Mor:** Oh, we would do threat modeling before actually testing, right? So a skilled penetration tester would perform what I would call abuse case. development, which is the threat modeling, right? They would access the application, turn off all their tools, just surf the application as a user, click on the links, understand what's the functionality on that application, then switch to a higher privilege role if they have one, map that functionality as well, and then take an hour, go to the beach, do some jogging, and then come up and sit back and say, okay, given that I can be an admin, what are the use cases or the abuse cases that I can compromise a user? Or given that I'm a user, how can I elevate my privileges to that of an attacker? So this is like the threat modeling that the penetration tester does as part of his penetration testing process. So, You know, they don't start by turning on their scanners and bombarding the application. They would start by, as you mentioned, taking a step back and thinking to the business, what's important? What's the business functionality? Is that a coupons application? Is that a workflow management application? Is that a payments management application? Okay. So what are the use cases that would make— cause the highest damage to the business and would make them lose money, would allow me to exfiltrate personal information, would allow me to access data that is considered sensitive in the context of that application, right? And so, in a way, that abuse case development is the one that you're, you know, calling threat modeling, but we try to kind of shrink that, into a 5-hour, 3-hour activity rather than the 2 or 3 days that you would need to do a threat model, right? And again, depending on the skillset of the consultant, right? They can just, after they've done that business case analysis, okay, let's pause, let's go to the cloud, right? We try to do it white box. So here's the application, here's the code, here's your cloud, right? You go to the AWS account and you start understanding and drawing a map. Okay, where do I come from?

**12:40** Right.

**12:42 Alex Mor:** What are the exposed APIs? What are the internal APIs? How is the application behaving? Is the database exposed? Is the— are there any, you know, integrations that I need to also attack? Because, you know, when I submit some data in an input field, what happens with that data? Is there machine learning? Is there data analytics? Is there something else coming and taking that data that I could abuse later on, right? So, So when I say pen test, white box, that's what I mean, you know, abuse cases, integration, and then when you're focused, you know what you're after. You don't waste time discovering things because everything is set for you and you can just go and give value to the business.

**13:30 Chris Romeo:** Yeah, this is great. So Alex, I've known you for less than an hour at this point, and I feel like I could talk about AppSec with you literally for the entire day. So I'm going to focus I do want to learn about application risk profiling because that's really what caught my attention initially. And so, I want to make sure we spend some time understanding that and teaching our audience about it. And so, I actually had found the talk you did at SnykCon where you were talking about application risk profiling. So, let's move into that conversation now. And if you could start by just giving me a definition because I don't feel like I have a crisp definition in my own mind.

**14:05** Sure.

**14:06 Chris Romeo:** about what do you mean when you say application risk profiling? Cool.

**14:10 Alex Mor:** So risk profiling is like risk rating, right? And, you know, I started that by looking at, you know, the OWASP maturity model. And one of the things as baseline activities that you would do is you would classify your applications according to risk, right? So the risk rating classification, And we want to be able to tell which application is not more important to the business but is more risky from an application security perspective, right? And I want to do some differentiation here because, man, the business says, I really need that application. I have so many users using the application. And it might also be a high-risk application from a risk perspective. But for the business, we have to ask ourselves, some more questions, right? Not only how many people are accessing the application, what type of data is stored in the application, how many integrations are in that application. So we kind of start maybe building like a, not a threat model, but a static model of characteristics. So we call it, you know, in the level 1, right, attempt to build a quantitative, or sorry, a quantitative way of saying, you know, let's give points to characteristics. So I wanna, I have, I'm an enterprise, I have 1,500 applications, or I'm a store, I'm a product company, I have 10 applications, right? So which application should we put our limited resources, right? We have 1 AppSec engineer per 1,000, per 100, developers, where should they start? Which team should they start working with first? And in my opinion, the way of doing that is just making the inventory. Every business has an inventory of applications. Let's talk enterprise level, if that's okay. Let's talk enterprise. They have the inventory of applications. Hopefully, somewhere in the enterprise, there's the full inventory of applications because some Some enterprises are formed by mergers, and then you have various business units. So every business unit has their own inventory application. So we then want to consolidate that sometime, somewhere in some system, but then going business by business and asking them, okay, what's in that application? Is that a crown jewel for you, right? If that application goes compromised or breached, What impact to the business does it make? How much money are you going to pay from a stock exchange, right? From a PR perspective, how much money are you going to pay if the data is compromised? Do you have— can someone sell the data within your application? And then, you know, what's the dollar value of the data of your application? So we try to build that static model, right? So we ask those questions. Very simple question, very basic questions like, um, what sensitivity of data? Is it highly sensitive? Is it public knowledge? Is it internal knowledge? Are there any compliance requirements for that, right? Are you bound by GDPR? Are you bound by LGPD? Bound by PCI? So trying to build those characteristics and And sometimes, you know, the business or the compliance teams or the global risk management teams already have that information. So we want to tap into their, you know, application that they already have. You know, an enterprise typically has some kind of form of inventory management. So we want to tap into that inventory management and just enrich the set of questions. And then just, again, in the first wave, we We do it in a quality, right? High, medium, low, and risk rank that. But we then can go a step further and give points, right? So if from 0 to 100, or for every application, right? Give a point from 0 to 100. So if it's externally facing, you give it 7 points. If it's internally facing on the internal network, you give it 5 points. If it's, you know, not exposed, isolated, just a workload that does— moves data from one place to another, you give it 1 point. And then you go and, um, uh, ask additional questions, right? Uh, for example, uh, um, how many users are you— are using that system, right? So a million, you give it, uh, 5 points. Half a million, 3 points. Just internal employees, uh, I don't know, 4 points, right? What is the business impact analysis? If the application goes down, you know, for 4 hours, is that a critical availability application? Is that a medium availability application? So if it's a critical availability application, we give it 7 points. If it's a medium, we give it 5 points, and then so on. And then you keep asking questions like, is there any financial data in the system? Is it processing credit cards? Is that processing or saving in memory, right, of financial data? Are there sensitive PII fields, right? Social Security numbers, DPI, DNIs, right? Personal identifiers. And so you end up with that what I want to call, right, static set of questions that would allow you at the end of that process to click on Excel, sort by risk, and then, man, you find your top 10 risky applications, right? You know what's the top 10— sorry, the top required skill set for a cybersecurity engineer, right? It's doing pivoting in Excel. So you have to be able to— Yeah, that's true.

**20:10 Chris Romeo:** Who knew Excel? Who knew Excel was going to be something we would use so much? Like, when we were in security school, they never said— there never was Excel 102 as a class and knowing we were going to have to know how to make pivot tables to be successful in security. But hey, here's the skill we need. Exactly.

**20:26 Alex Mor:** Graphs, you know, this is the real skill. You know, Python, man, we know Python, but Excel pivoting and it never works. You have to always try to troubleshoot that. So.

**20:36 Chris Romeo:** Yeah, I'm always searching for how to make Excel work. But, you know, at the end of the day, it looks good. So I want to talk about scale.

**20:45** now.

**20:46 Chris Romeo:** So one of the things that we've been focusing on on the podcast here quite a bit as we've talked to a few different people over the last number of months is talking about— it's one thing to do something for a startup that has 10 engineers, right? Because, oh, look, we only have 2 applications. Let's quickly rate them. One is 100, one is 10 points. That's easy. Not easy, but it's easier than when you're in the enterprise with 1,500 applications. So when you think about this process of application risk profiling, How do we take this to the masses when you have 1,500 applications in your enterprise?

**21:20 Alex Mor:** So the question follows is, do you already have an inventory, right? Do you have someone that's maintaining your applications inventory? And typically in an enterprise, there is some role with that. It's either with privacy team, it's with data protection team, it's with risk team, compliance team. There is some team responsible in the organization to map all the applications, right? Because why is there such a team? Because in the enterprise, every year you would say, okay, I wanna decommission those applications. So how do you know which one do you have to decommission, right? So I assume there's already a system. So what I would do, I would just tap into that system, tap into that a person managing the portfolio of applications and, and, and, and, you know, have a scheduled 1-hour meeting with them and ask for their support, right? I want to use the— your system that you're already managing, assuming that we can add custom fields, right, uh, to that, uh, application characteristics, uh, portfolio that you have. And it can even be Excel, right? They can even manage the applications portfolio in Excel. But tap into that already existing process and just add those characteristics, the static ones, right? And typically, you know, you go to a business, they already have that information. They already know in which application there's sensitive information. They already know which application has sensitive PII fields, right? Again, as an enterprise, fairly mature, not, you know, you know, you would have those practices already. So you just have to connect with those people and align them to that idea of, okay, now we want to risk-rank the applications, and we really need your help to go and send, you know, communications to the people. We have a few new fields in our application inventory management system that we would need your support, right? CMDB-like. type of system, right? We have 4 or 5 new fields that would help us classify the risk and would help us prioritize application security engineer activities to better protect the business, to better be prepared for the attackers to come. And that, in a nutshell, is what I would suggest, you know, not reinvent the wheel. Again, if you don't have anything, Start with Excel, connect with the compliance team, connect with the privacy teams, connect with the teams that are responsible for decommissioning applications. They would know where those applications are.

**24:06 Chris Romeo:** So Alex, who's answering those questions then? Because it seems like the characteristic questions that I heard you describing were things like danger if data's disclosed, PII classification, You know, a number of things that to me seems like it requires a relatively savvy AppSec person to have a true answer for. So to who, you know, if we're going to partner with this team that's already doing inventorying of the enterprise applications and building that catalog, do they have the expertise to answer these questions? Does the AppSec engineering group have to answer it? Does the privacy team— like, who do you recommend actually does the work of answering the questions?

**24:49 Alex Mor:** I think we need to keep the questions simple. Right? Because at scale, an AppSec engineer cannot go application by application, 1,500, 2,000, 5,000 applications. That's not the work for an application engineer. We need to find the application owner, right? And ask them to update those simple questions. Is it internet-facing? Does it contain sensitive information? What's the dollar value? or what— how many users are accessing the application. And we know, you know, what's the dollar value of, of, of a human record. So, um, we need to, you know, ask their support and ask the application owner's support to, again, on a yearly— on a yearly, uh, exercise, make sure that that information about your application is up to date. And then we can, you You know, again, processes take time. So if in the first month I only get 10% of the applications up to date, and this is success, right? Because we created a new process, we already have some traction, people are already giving us data, and we can already start prioritizing. And, you know, processes in the enterprise could take time. So I'll assign my application engineer to the first high-risk application. among the, you know, that top 10— sorry, the 10% of applications that I already have. What we would typically do also is when we test the application and we compare that to the profile and we find something that, man, there's PII here, you didn't know? Oh, okay, let's update that field. So we would, you know, feedback to the application risk profile— sorry, application inventory teams that—

**26:34** Yeah.

**26:36 Alex Mor:** they have sensitive information or that application, their application is actually internet-facing. It's reachable, right? And help shape that profile for the future, for the next time coming, right?

**26:52 Chris Romeo:** So when I think about this and what you're describing as far as who's going to be involved in the data collection here, it makes me think governance. And so, a previous friend of the podcast and a friend of mine, Alyssa Miller, we were talking one time on the podcast here about people, process, and tools as being the way you classify, you know, anything that you're trying to achieve in an enterprise. But she also threw out governance. And so, governance is always on my mind now when I think about scale at the enterprise. And so, I guess my question is for you here is if we're having the business owners, be responsible for answering these questions. What's the governance side of this? How do we ensure that they're doing it? How do we— are there— what are the checks and balances to know that they're doing it correctly? Like, do you have people that are doing some spot checking on some of these to look at them and go, eh, well, wait a minute, you've got this thing marked as low risk, but you're saying you have 10 million users and you have PII, and if it gets disclosed, we're going out of business.

**27:54 Alex Mor:** But—

**27:54 Chris Romeo:** you got it as a low. So how do we govern this thing you're talking about?

**27:58 Alex Mor:** That is, you know, that's our daily data job, right? So we go over those risk profiles, we go over the data, and when we prioritize what application should we pentest next, we take that list, but we don't only look at the high ones. We also look at the low ones, and we also go just through the entire list and say, hey, but this application, I know it has employee data, and I know it's part of a very important business process, but why is it only low? Right? And then we would do that check to say, okay, so some of the scores, maybe we need to adjust the scores, right? Remember how we started on giving a score of 5 to an internal-facing application or a score of 5 if the application has SSO? Okay, maybe let's increase that score to 7, and we can— As long as the application has that ability to, on the spot, regenerate the model, regenerate the scores, and for sure we can adjust, right? We can for sure say, manually override the application risk and look into something that we know internally that some of the data is not complete, or, man, this is a crown jewel application. This application is used by the business. It's highly important to the business. We need to maybe adjust our crown jewel criteria, right? How do we classify applications? But in a way, we try to go over the data, and there's like a, you know, a yearly process, right, where you would just check yourself, right? Do the applications that are marked as high risk are the applications that you know with the risk team, with the compliance teams, are indeed a high risk, and you're not missing anything. So I think, you know, it's for us a continuous process to validate what's our top risky applications. And I want to, you know, maybe just step one, take you a little forward in that process of classifying applications according to risk. and say, man, it's not only a static model. We can also classify applications according to changing characteristics, right?

**30:13 Chris Romeo:** Right.

**30:13 Alex Mor:** A kind of dynamic way of looking into application and asking, where is it hosted? Is it hosted at a data center? Is it hosted in the cloud? Are we moving that now from data center to cloud? That changes the risk of application because if it was Hosted, you know, I, I, we, I want to say, you know, data center is more secure than cloud, right? And you can, you can, we can have a whole talk on whether data center is more secure than cloud, because when you go to the cloud, you know, everything is open, everything is accessible. You have to go and secure and turn off all those switches. If it's in the data center, you have your parameter, but, you know, exposing that, switching that off to the cloud changes the risk profile for your application. So this is kind of like a dynamic change that you have to look into. We can talk about a bill of materials. So you have a dependency that suddenly has a new high-risk vulnerability. And although this application is, you know, internally or externally facing, now that you found out there's a dependency vulnerability on your application that's exploitable and an exploit exists, and someone has a path from the functionality that you have in your application into the dependency, and you're using that vulnerable functionality of the dependency, man, that changes the risk dramatically for that application, right? If it used to be a low-risk application in your cloud, but now it has a critical dependency vulnerability, that suddenly becomes a high-risk application.

**31:49** Yeah.

**31:50 Alex Mor:** For you, so the risk profile is is always changing, right? For the applications, man. Sometimes you have an employee leaving the company, and and and you had you know secrets in the code, right? What happened when that employee left the company? And let's say it was a BYOD device, and they had secrets in the code. So they had the code. In their laptop, what's the risk going to change for you now that you know that that employee has credentials to your application? You don't know if they've wiped their machine, wiped their laptop after leaving, or even a different scenario, right? An employee uploads a portion of the repositories to a public GitHub, right? They want to They want to train, they want to do something. Someone accidentally switches the visibility of a repository from private to public. That switches your risk profile for your application instantly, right? And we can have a lot more, you know, use cases like that. You're replacing your SQL Server, you're replacing your one technology with another technology. What do you know on protecting that technology? So, um, you have a new developer joining, you have a low-risk application or a medium-risk application, it's a product, it's still under development, but man, suddenly you have 10% change in your developers, uh, uh, joining and starting to build code and starting to, uh, create new microservices. How is that going to impact your risk profiling for your application now that you know you have applications not trained on secure coding, not trained on secure cloud best practices, and you don't know the quality of the code they're writing. Do they know how to implement authentication— or sorry, authorization properly? Because you have a central authentication gateway, you know a new microservice has authentication, but those developers actually introduce more risk. So, you have to go and assign training for those developers, make sure that their pull requests are reviewed by a security engineer, a product architect, or a very senior developer on that same product team.

**34:12 Chris Romeo:** So one of the things we like to do is, let's imagine one of our listeners is sitting here, and they've heard this conversation that you and I are having about application risk profiling. And now they're sitting there going, okay, I'm in. I'm buying into this idea. I want to do this. What are some— what's some of the advice or next steps you would offer to them as far as how can they get started? I know you mentioned kind of partnering with the existing inventory, the people that are doing the existing inventory, but what other advice would you have as someone who's done this before, imagining that someone is brand new to this idea, they just understood the concept and now they're like, I'm going to go do this. What are the— what are a couple things you would recommend for them?

**34:52 Alex Mor:** Right. So after they've completed their basic risk, uh, classification, right? They know already what are the top risky applications. They've done that exercise. They, they even validated that their top 10 risky applications are indeed, you know, also important to the business. And, and now you have to kind of start, uh, in a way setting up monitoring, right? You, you would, um, regularly every month, every, every, every 2-3 months go and reach out to the team and you can ask them, hey guys, do you have any new developers? And it also depends on what technology you have. You would use a dependency scanner and you would regularly, again, before you have automation, you would rarely go and check, is there any new high-risk vulnerability within my application? You would use your bill of materials. If you're tracking your bill of materials, in some software or, you know, dependency track, Snyk, WhiteSource, Checkmarx, whatever. If you have your dependency track, you go and update as metadata or a tag within those tools, within your application security scanning tools that, hey, this application is a high risk. So I want to know that if there's a new high-risk vulnerability in a high-risk application, I want to see that in the dashboard that, you know, as application security engineers and application security leaders, they use those dashboards on a daily basis, right? We see, we want to see the trend, we want to see the graphs. So we have to, you know, in a way, try to shift from a static risk profiling to the more dynamic ones where we actually understand and talk to the people team and talk to the, product team and say, I want to know of every new employee developer you have on your company because you're managing a high-risk application and I want to be connected to you. So it can be on a daily basis, it can be on a weekly basis, but we have to let know of the businesses that we consider their applications high-risk and we're going to work with them closely and we're going to actually help them you know, lower the risk, right? Or keep the risk at a certain level that would allow us to sleep better at night knowing that this is a high-risk application. I'm paying attention to the development team, to new products, to new features. There are some startups, there are some products that would help you get more visibility So if you classify an application as high risk, you can have— there are some startups today that would track that application for you and it would identify new commits happening, would identify if a repository of that application is suddenly externally facing, would help you identify if you're starting to use a new technology. In our bill of materials, you can get a snapshot of the technologies today. You see React, you see Azure, you see AWS components, serverless, static. But if you can have your bill of materials, you know, alert you when a technology is introduced, so you can also consider that when working with the product team and say, okay, I see you just started using storage accounts, S3 buckets, because I see in your dependencies that you're using that. Component. So let's see what you're doing there. Let me review that. How how are your buckets configured? Right. So in in a way, once you rec you learned what are your risky applications, you start actively working on creating more controls, creating more security monitoring, and then you'll say, okay, this is a high risk application. What are my security controls that I have? Do I have a WAF? Do you have a WAF, guys? Yeah, how is your WAF configured? Is it on block mode? Is it on audit mode? Oh, it's in block mode. All right, good. Do you have dynamic scanning, right? Are you scanning your APIs? Do you have one of the— ah, it's an API application. Do you have API monitoring? Do you have schema validation? Do you have anomaly detection? How are you protecting from attack, from account takeover? Do you have rate limiting? So I'm going to just, you know, just that I learned what are my risky applications, I'm going to put my big foot on them, and I'm going to help them become more secure so that I know these are risky applications and I'm paying the right attention to them.

**39:36 Chris Romeo:** Awesome. Well, if you— let's just do one key takeaway. So for the audience here coming out of this whole application risk profiling, Give us just a single key takeaway that our audience, that can resonate and stay with them. Hopefully, they'll remember it in the next couple of weeks as they continue to think about this idea.

**39:55 Alex Mor:** I'm going to give you a few, right? First of all, make sure that you know what are your top-risky applications and you align that with the business, right? Because what's, you know, internal for the business, the business has a SaaS application that's really critical for them, but they say, it's a SaaS application. Let's have, you know, SOC 2 report and ISO 27001 report for them. It's not a high-risk application for the application security team. So align on that concept with the business and really focus your attention there. Become aware of developers, because if you have a high-risk application and you know it's a high-risk application, make sure that your developers are 100% trained on application security and that you know of every new developer. From the people team, you know, a new guy was hired, they got the big swag, they got the bag, they got the notebook, and they also got an email from the application security team, welcome, here's your training for secure coding in Java, .NET, Node.js, Go. Keep monitoring them, right? Put them in your daily monitoring session. For dependency security, open source security, container security, Kubernetes security, static analysis security, give them that bigger, you know, swag, let's call that, to the product that you would not normally give to the regular applications. So now that you know you have a high-risk application, you just, you know, surprise them with new security technologies. So, I guess 3 takeaways, right, on that?

**41:34 Chris Romeo:** Yeah, that's good. Good stuff. I mean, thank you so much, Alex, for sharing your experience on this issue. I know I've learned a lot, and I want to invite you back. I'm just— I'm inventing something on the fly here, but in the next month or 2, I want to do something called the AppSec Random Show, and I want to invite you to be the first person to be a part of that. And what we'll do is we'll just talk about application security, but we won't have a big idea about where we're going to go. We're just going to start talking about something that I can tell this is a topic you love, just like I do. And I have a feeling we could literally talk for hours, but we'll constrain ourselves to a period of time. So, Alex, thank you for joining us to share your thoughts and teach us about application risk profiling. And we'll have you back here very soon for our first-ever AppSec Random Show, which is going to be a blast.

**42:21** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjournal.com. securityjourney.com/resources/podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, with application security, there are many paths, but only one destination.

---

Source: https://appsecpodcast.com/alex-mor-application-risk-profiling-at-scale/