Application Security Podcast

Alex Mor -- Application Risk Profiling at Scale

March 16, 2022

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.


Chris Romeo  00:00

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. And then we talk about how can you do application risk profiling at scale? Whether you have 10 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.

Tiara Sanders  00:41

You're about to listen to AppSec podcast. When you're done with this, be sure to check out our other show, Hi/5.

Chris Romeo  00:50

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. I am excited to say that I'm joined by Alex Mor. 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 seats, 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 into AppSec. So how'd you get into AppSec, Alex?

Alex Mor  01:39

Cool. Hey, Chris. Thanks for inviting me. Really happy to be here. FYI, I'm based out of Israel. I'm probably going to have a different story, just like everyone else. Just FYI, on where am I today, I'm ABM's largest beer Brewer. The story of how I got to work in the largest beer brewer in the world. To start my journey around 1998, more or less, I think I was around 16, I'm sorry, I was 12. The internet was starting, though we had some static pages, some people just going and reading content. So I started building static HTML web pages, and that was a thing, but you would open the text and it was you would bring big text, you can change the font, and that was the amazing thing of the Internet back then. A few years forward, I got a link to something called Cyber Army. It's a union; it's like volunteers 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 sibulan challenges. I just check in and it's still online. So this is when I first got introduced to SQL injection. We're talking about all this more than 20 years ago; SQL injection was becoming popular because people were developing application 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, you know, the video, the beginning of PHP, you would not have a secure way of doing a SQL queries, right, you would have to do sanitize, remove some characters. Anyway, that's where I was introduced to SQL injection and cross-site scripting, privilege escalation, cookie poisoning attacks, 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 few years forward in Israel, it's mandatory to serve in the military, so I joined the infantry, served there for four years afterward, was discharged, and was kind of looking for places, looking for something to learn, looking for something to do. My parents pushed me 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 a physics degree. And that's what I studied, physics. I really tried to go learn from some of the other departments from Computer Science and Electrical Engineering. So learn some Java, learn some C on the way. But then, I kept maintaining that skills of cybersecurity of hacking some here some there on some free, you know, learning exercises, right. 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 in radiate, people in the hospital, help them get better from cancer. And man, I said, maybe I'm fit for something else. That's when I saw a position, testing and consulting, they just acquired a company called haptics. They just joined the SEM firm in Israel. The interview was easy for me; they just asked me, how do you do cross security? How do you do SQL injection, I've been doing that for ten years. I got accepted for that job. You know, and then the rest is history. The whole career path from a penetration tester, manager consultant, got to know a lot of companies and different products and really interesting implementations of different technologies with different developers or by different developers. Then I got into security architecture, and cloud also started becoming more available, and everyone was switching to the cloud. Then I had an opportunity to come and build an application security program with ABI. I've been with ABI for the past two years.

Chris Romeo  06:08

Very cool. From physics, started in security, you know, as a young person, made your way through the military, into the university to study physics, and now back into security.

Alex Mor  06:24

Defending breaking into our applications to help our product teams, improve them and make better in the room more resilient and harder to break into, you know, with every release, we find new things. With every release, we find new ways to compromise our application. We try to be one step ahead of the attackers every day.

Chris Romeo  06:48

Given that you've had quite a bit of pen-testing experience and braking 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 pen-testing and breaking? Or not enough emphasis? Or what's your take on that issue?

Alex Mor  07:22

First of all, I like pen-testing; if I need to do a quick assessment, there's always a question like, would you do a threat modeling? Would you do a risk assessment? Or would you do a pen-testing? That's the question of how deep can you do the pen-test? Right? Can you do a white box pen-test that would have access to the code, you've had access to the cloud, you'll 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. Then you can just use your time wisely and attack the functionality and attack the business cases, rather than just brute forcing and fuzzing and, wasting three days just to just to do enumeration or reconnaissance. I like doing pen-testing, and we have today, 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. So they're trying to break into that. So for me, I think pen-testing can get you a gap analysis. You want to know what your gaps in your application, you do a pen test, you want to understand how exposed are you to the world, you do a pen test. And you try to do that white box. Not black box, because the black box misses, you know, 30-40% of your attack surface.

Chris Romeo  09:03

It's interesting. As I'm thinking about this because of 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. It's been a long time. Certainly, I know how to exploit SQL injection, cross-site scripting, all the AppSec related things. 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. The reason I look through the lens of the threat model is I feel like I can do the less total amount of time, less effort to be able to look at something from the threat modeling lens. It's 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 getting into more of the nitty-gritty perspective. Now I know both of those things are important, but it's the philosophy of AppSec, and it's okay; we all come from different perspectives and backgrounds. But what do you see as Threat Modeling's role in the way that you approach looking at a given application?

Alex Mor  10:12

We would do threat modeling before testing. So a skill penetration tester would perform what you would call abuse case development, which is the threat modeling, they would access the application, they're not older tools, just serve the application as a user, click on the links, understand what's the functionality on their application, then switch to a higher privileged 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? This is like the threat modeling that the penetration tester does as part of his penetration testing process. They don't start by turning on their scanners and bombarding the application; they will 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 coupon application? Is that the workflow management application? Is that a payment management application? So what are the use cases that would 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? In a way, abuse case development is the one that you're calling threat modeling, but we try to shrink that, you know, into a five-hour or three-hour activity rather than two or three days that you would need to do a threat model. But again, depending on the skill set 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 tried to do with white box. Here's the application; here's the code; here's your cloud. You go to the AWS account, and you start understanding and join the map. Okay, where do I come from? What is the exposed API? What are the internal APIs? How is the application behaving? Is the database exposed? Are there integrations that I need to also attack? Because, you know, when I submit some data in an input field, what happens with the data? Is there machine learning? Is there data analytics? Is there  something else coming and taking that data that I could abuse later on? When I say pen-test, white box, that's where I mean, abuse cases, integration, and then you're focused, you know what you are after, you don't waste time discovering things, because everything is said for you. You can just go in and give value to the business.

Chris Romeo  13:30

Yes. This is great. Alex, I've known you for less than an hour, and I feel like I could talk about AppSec with you for the entire day. I'm going to focus on the back end because I  want to learn about application risk profiling because that's what caught my attention initially. I want to make sure we spend some time understanding that and teaching our audience about it. I actually had found the talk you did at SneCon and where you were talking about application risk profiling. So let's move into that conversation now if you could start by giving me a definition because I don't feel like I have a crisp definition in my mind. What do you mean when you say application risk profiling?

Alex Mor  14:09

Cool. Risk profiling is like risk rating. I started that by looking at the OSI maturity model. One of the things as baseline activities that you will do is you would classify your applications according to risk. The risk rating classification and we want to be able to tell which application is, not more important to the business, but it's more risky from an application security perspective, right. I want to do some differentiation here because when the business says, I 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. Not only, How many people are accessing deputation? What type of data is stored in the application? How many integrations are in the application? We start maybe building, not a threat model, but a static model of characteristics. We call it, you know, in the level one attempt to build a quantitative way of saying, let's give points to characteristics. I'm an enterprise, I have 1500 applications, or I'm a product company, I have ten applications. So which application should we put our limited resources? We have one AppSec engineer per 1000, per 100 developers? Where should they start? Which team should they start working with first?  In my opinion, the way of doing that is making the inventory. Every business has an inventory of applications, let's talk enterprise level, let's talk enterprise. They have the inventory obligation; hopefully, somewhere in there, the enterprise does the full inventory of application. Because some enterprises are formed by mergers, and then you have various business units. Every business unit has its inventory application. We then want to consolidate that somewhere in some system, but then going business by business and asking them, what's in their application? Is there 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? From a PR perspective? How much money are you going to pay if the data is compromised? Can someone sell the data within their application? Then, you know, what's the dollar value of the data of your application? We tried to build that static model? So we asked those questions, very simple questions. Very basic questions like, what is the sensitivity of the data? Is it highly sensitive? Is it public knowledge? Is it Intel knowledge? Are there any compliance requirements for that? Right? Are you bound by GDPR? Are you buying by LGPD, bound by PCI, so trying to build those characteristics, and sometimes, the business, the compliance teams, or the global risk management teams already have that information. We want to tap into their application that they already have, you know, an enterprise typically has some form of inventory management. We want to tap into that inventory management and just enrich the set of questions. Then, again, in the first wave, we do it in the equality. High, Medium, Low, and reach that range that, but we can go a step further and give points. If from zero to 100, every application was given a point from zero to one-hundred. If it's externally facing, you give it seven points; if it's internally facing on eternalness, you give it five points; if it's not exposed, isolated, a workload that moves data from one place to another, you give it one point, and then you go and ask additional questions, right? For example, how many users are using the system? Right? So a million, You give it five points, half a million, three points, just internal employees, four points, right. What is the business impact analysis? If the application goes down, you know, for four hours? Is it a critical availability application? Is that a medium availability application? So if it's critical availability application, we'll give it seven points. If it's a medium, it gets five points, and then so on. 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 of financial data? Are there sensitive PII fields, right? Social Security numbers, DPI, DNI, personal identifiers, and you end up with that, but I want to call a static set of questions that would allow you at the end of that process to click on Excel, sort by risk, and then you find your top 10 risky applications. You know what the top required skill set for cybersecurity junior. It's people working in Excel. So you have to be able to do that.

Chris Romeo  20:09

Yes, true. Who knew Excel was going to be something we would use so much. Like when we were in security school, 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, it's a skill we need.

Alex Mor  20:25

Exactly. Graphs, you know, they said the real skill, Python men, we know Python, but Excel pivoting, and it never works; you have to always try to troubleshoot that.

Chris Romeo  20:37

I'm always searching for how to make Excel work. But you know, at the end of the day, it looks good. I want to talk about scale now. One of the things that we've been focusing on in 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 is one thing to do something for a startup that has ten engineers. Because we only have two applications, let's quickly rate them. One is one-hundred; one is ten points. That's easy. Not easy, but it's easier than when you're in the enterprise with fifteen-hundred applications. When you think about this process of application risk profiling, how do we take this to the masses when you have fifteen-hundred applications in your enterprise?

Alex Mor  21:22

The question that 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 the privacy team, the data protection team, it's with the risk team, the compliance team; there is some team responsible in the organization to map all the applications. Why is there such a thing? Because in the enterprise, every year, you will say, I want to decommission those applications. How do you know which one you have to decommission? I assume there's always already a system. What I would do, I would just tap into that system, tap into that person managing the portfolio of applications and schedule a one-hour meeting with them, and ask for their support, I want to use your system that you're already managing, assuming that we can add custom fields to that application characteristics, portfolio that you have, and it can even be Excel. They can even manage the applications portfolio in Excel. To tap into that already existing process, just add those characteristics, the static ones. Typically, you know, you go to a business, they already have that information, they already know in which application is the sensitive information, they already know which application has sensitive PII fields, again, as an enterprise, fairly mature, you would have those practices already. You just have to connect with those people and align them to that idea of, now we want to risk rank the applications, and we need your help to go and send communications to the people, we have a few new fields in our application inventory management system, that we would need your support by CMDB like, type of system. We have four or five 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 from the attack that is to come. 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.

Chris Romeo  24:07

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 is 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 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?

Alex Mor  24:50

We need to keep the questions simple because, at scale, an AppSec engineer cannot go application, application, 1500, 2000, 5000 applications. That's not the work for an application engineer; we need to find the application owner and ask them to update those simple questions is it internet-facing, does it contain sensitive information? What's the dollar value, or how many users are accessing the application, and we know the dollar value of a human record. We need to ask for their support and ask the application owner support to, again, on a yearly exercise, make sure that the information about your application is up to date. Then we can, again, processes take time. In the first month, I only get 10% of the applications up to date. This is success because we created a new process, we already have some traction, people are already giving us data, and we can already start prioritizing, and processes in the enterprise could take time. I'll assign my application engineer to the first high risk application among the 10% of applications that I already have; what we would typically do is when we test the application, we compare that to the profile, and we find something that meant this PII here, you didn't know, okay, let's update that field. We would feedback to the application inventory teams that they have sensitive information or their application is Internet-facing, it's reachable and help shape that profile for the future, for the next time coming.

Chris Romeo  26:52

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. 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 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. My question is, for you 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? 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 him and go, Yeah, 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? If it gets disclosed, we're going out of business, but you got it as a low. So how do we govern this thing you're talking about?

Alex Mor  27:58

That is our day-to-day job. We go over those risk profiles, we go over the data, and when we prioritize what application should we pen-test next, we take that list, but we don't only look at the high ones; we also look at the low ones. We also go through the entire list and say this application has employee data, and I know it's part of a very important business process. But why is it only low? Then we will do that, check to see some of the scores, and maybe we need to adjust the scores. Remember how we started on giving a score of five to an internet-facing application or a score of five, if the application has SSO, okay, maybe let's increase that score to seven and we can, you know, as long as the application has that ability to, on the spot, regenerate the model, regenerate the scores. We can adjust, we can for sure manually override the application risk and look into something that we know internally that some of the data is not complete, or this is a crown jewel application, this application is used by the business, it's highly important to the business, me to maybe adjust our crown jewel criteria, right? How do we classify applications, but in a way, we try to go over the data. There's a yearly process where you would just check yourself. 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? I think it's for us a continuous process to validate what are our top risky applications. I want to take step one, take you a little forward in the process of classifying applications according to risk, and say, it's not only a static model, but we can also classify application as a call according to changing characteristics. You're 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 the data center to the cloud? That changes the risk of application because if it was hosted, I want to say, the data center is more secure than cloud, right? We can have a whole talk on where the data center is more secure the cloud, because when you go to the cloud everything is open, everything is accessible, you have to go and secure and turn off all those switches, if it's at the data center, you have your parameter, but you're now switching that off to the cloud changes the risk profile for your application. This is kind of like a dynamic change that you have to look into; we can talk about bill of materials. You have a dependency that suddenly has a new high-risk vulnerability. Although this application is 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, that changes the risk dramatically for that application, right, if you 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 for you, the risk profile is always changing for the applications, sometimes, you have an employee leaving the company, and you had a secret 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 was 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. An employee uploads a portion of the repositories to a public GitHub; 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 application instantly. We can have a lot more, you know, use cases like that you replacing your SQL Server, you're replacing your one technology with another technology. What do you know on protecting that technology? So 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 then suddenly, you have a 10% change in your developers joining and starting to build code and starting to create new microservices; how is that going to impact your risk profile 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 the writing? Do they know how to implement authentication or authorization property? Because you have a central authentication gateway, my new microservice has authentication, but those developers introduce more risk. You have to go in and assign training for the developers to make sure that their pull requests are reviewed by a security engineer, a product architect, or a senior developer on that same product team.

Chris Romeo  34:14

One of the things we'd 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. Now they're sitting there going; I'm in, I'm buying into this idea, I want to do this. 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 partnering with the existing inventory. These 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 do this. What are a couple of things you would recommend for them?

Alex Mor  34:53

After they've completed their basic risk classification, they know already what the top risky applications are? They've done that exercise. They even validated that their top 10 risk applications are also important to the business. Now you have to start in a way setting up monitoring, right? You would regularly, every month, every two or three months, go and reach out to the team and ask them, hey guys, we have any new developers. It also depends on what technology you have, you would use a dependency scanner, and you would regularly before you have automation, you will 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 dependency tracks, Nick, white source, checkmarks, whatever. If you have your dependency track, you go and update as a Metadata or a tag within those tools, within your application security, scanning tools that this application is a high risk. I want to know if there's a new high risk vulnerability in a high risk application; I want to see that in the dashboard that as application security engineers and application security leaders, they use those dashboards on a daily basis. We want to see the trend, we want to see the graphs. We have to try to shift from a static risk profiling to the more dynamic ones where we  understand and talk to the people team, and talk to the product team and say, I want to know of every new developer you have on your company because you're managing a high risk application and I want to be connected to you. It can be on a daily basis; it can be on a weekly basis. We have to net no of the businesses that we consider their application is high-risk, and we're going to work with them closely. We're going to help them lower the risk 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 will help you get more visibility. But if you classify an application as high-risk, you can have startups today that would track that application for you. 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 new technology. In our Bill of Materials, you can get a snapshot of the technologies today, right? You use React, you see Azure, you see AWS components, serverless static, but if you can have your bill of materials alert you when a technology is introduced. You can also consider that when I'm 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 are your buckets configured? In a way, once you learn, what are your risk applications, you start actively working on creating more controls, creating more security, monitoring, and then you'll say, this is a high-risk application. What are the security controls that I have don't have a wealth? Do you have a web guys? Yeah. How is your wealth configured? Is it on block mode? Is it on audit mode? Is it in block mode? All right, good. Do you have dynamic scanning? Are you scanning your APIs? Do you have one of the API applications? 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? I'm going to, as I learned, what are my risk applications, I'm going to put my big foot on them. 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.

Chris Romeo  39:36

Awesome. Let's just do one key takeaway. For the audience here, coming out of this whole application risk profiling, give us just a single key takeaway that our audience  can resonate and stay with them. Hopefully, they'll remember it in the next couple of weeks as they think about this idea.

Alex Mor  39:55

I'm going to give you a few. First of all, make sure that you know your top risky applications, and you align that with the business. Because of what's internal for the business, the business has a SaaS application that's critical for them. But they say it's a SaaS application, let's have you know, sock report and ISO 27 report for them; it's not a high-risk application for the application security team. Aligned on that concept with the business and 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 dotnet, no J. S, 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 swag. Let's call that to the product you would not normally give to the regular application. Now that you know you have a high-risk application, you just surprise them with new security technologies. I get three takeaways right on that.

Chris Romeo  41:34

Yeah, that's good stuff. 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 inventing something on the fly here, but in the next month or two, I want to do something called the AppSec random show. I want to invite you to be the first person to be a part of that. 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. I have a feeling we could talk for hours, but we'll constrain ourselves to a period of time. Alex, thank you for joining us to share your thoughts and teach us about application risk profiling. We'll have you back here very soon for our first ever AppSec random show, which is going to be a blast. Thanks for listening to the application security podcast. You'll find the show on Twitter @AppSecPodcast and on the web at You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, with application security; there are many paths but only one destination.

Need more information about Security Journey? Get in touch.

Ready to start your journey?

Book a Demo