Maturing your AppSec Program
This episode highlights the role of AI in security, stressing the necessity of establishing policies and user education to manage its usage effectively.
This episode of Secrets of AppSec Champions focuses on maturing your application security program including insights on key steps to elevate your security posture.
Guest: Toby Jackson - Sr. Director of Information Security and Compliance at Imperial PFS
Host: Chris Lindsey
Key takeaways from this episode:
- Conduct a thorough risk and maturity assessment. Use available templates to understand your current state and identify gaps.
- Prioritize vulnerabilities and create a long-term plan. Address low-hanging fruit quickly while developing a strategic roadmap for tackling larger issues.
- Invest in penetration testing. While expensive, pen testing provides valuable insights and validates your existing security tools. Prioritize testing high-risk applications and ensure your development team is prepared to address findings.
- Continuously evaluate your security tools and technologies. Stay informed about new solutions and industry best practices, particularly in the rapidly evolving field of AI.
- Establish a security champions program. Empower key individuals within your development and infrastructure teams to promote security awareness and best practices.
This episode also touches on important considerations for:
- Emerging threats from AI technology and the importance of user education and strong authentication practices.
- Integrating security training with HR to streamline employee education.
- Raising developer awareness on vulnerabilities to enable early detection and remediation.
- Collaborating with teams for effective solutions to address underlying security issues, not just symptoms.
Intro:
The nice thing too is when doing a pen test, it also gives you some validation on the tools that you run internally. If you have a DAST system running a DAST scan, hopefully your DAST results mimic or at least have some of the things. Well, if you’re doing your job, they shouldn’t be on the penetration testing tool reports. But with DAST, they should at least mimic some of the low hanging fruit that the pen testing companies are going to find.
You bring up a good point. If you have stuff that your DAST and SAST tools are showing and you’re not addressing, you’re making the lives of the pen testers easy. They’re going to find the common stuff and not really dig.
So it’s in your best interest to do a pen test when you have all the easy stuff off the table just so they dig and find more. I can’t stress that enough. They’re only going to dig as deep as they think they need to. If they have trouble finding stuff, they keep digging.
You get yourself a better test if you make sure things are in a better state before you get started, for sure.
So the goal is one week in, sorry. We can’t find anything. Our penetration testing’s looking good. Hopefully, at that point, you’re like, we’ve done our job well. We’re doing a good job. We’re succeeding. And hopefully, knock on wood, you know, other things are there.
Conversation:
Hello, and welcome to Secrets of AppSec Champions.
My name is Chris Lindsey, and today we’re going to be speaking with Toby Jackson. Today’s conversation is going to be around maturing your application security program. Toby is a senior director of information security and compliance at Imperial PFS.
Welcome to the program, Toby. Please introduce yourself.
Hi. My name is Toby Jackson. I’ve been in the security industry, IT industry area, since the mid nineties.
Built my way up through the years through various security type positions.
I now lead the program where I’m currently at. So very familiar with maturing your program.
I’m actually in the process of doing that for the second time at this new institution. So definitely have some lessons learned from the first time that I’m applying to the second time. So glad to be here.
Awesome. Thank you for coming, Toby. That’s absolutely amazing. So let’s hit the ground running.
Steps to Mature Your Application Security Program
So maturing your application program, what does that look like? Can you walk us through some of the things that we should be thinking about and focused on from taking our program from, hey, it’s running, to that next level.
So the next step might be actually doing a maturity and risk review.
There’s a lot of templates out there.
New York DFS has a template for measuring risk and measuring maturity.
It’s pretty simple compared to the others I’ve seen, so that would be a good place to start to get a gauge of from a tourist standpoint where the organization is, and what stuff can also supplement your risk and gap list that you’ve already created.
Then once you have taken that risk and put that risk together and have the results, what’s the next best step to take those results and actually move the needle and get those implemented?
That comes down to education, relaying to everybody, hey, these are our risks, these are our areas of focus, And then figuring out a timeline. If you start midyear, obviously, you might already be constrained from a budgetary standpoint and technology standpoint, you can’t do much. But this is where the plan, the long-term plan comes into play, taking care of the things that are short term that you can get off the board while you wait for that next budget cycle.
So putting that all together in your longer-term plan will definitely help and outline where you’re taking the program. So this is really critical for the leadership as you’re continuing to educate and have meetings with them. They like to know what’s next. They like to know where you’re taking things.
And then also, you need to take where the business is going, their goals, and incorporate those into yours. So this is just a continuing education and continuing that leadership buy-in throughout the year.
It’s one of those things where you may have the relationship upfront. You just have to keep feeding and having that good relationship because maintaining that relationship is key. That way when you do have a finding or something comes up or after the risk assessment, going to them and sharing that with them and saying, Hey, here’s our findings and here’s what we have.
That’s absolutely key and important, again, for success and for the longevity of your program.
Utilizing Risk Assessment Tools
You bring up a good thing about that risk, you and I, you’ve shown that to me before, and the information on there is quite valuable. Can you share the name of that again for anybody listening that might have missed it the first time?
It’s New York DFS.
So there is a, what they call a CAT assessment. An FFEIC CAT assessment is what they need to look for. So that’s something that’s really simple that you can use if you’re a financial institution, but I find it’s pretty simple and it’s a good gauge of things with minimal time. And then talking about the risk review and also the maturity of the program, when you first step in, obviously the risks are there, the vulnerabilities are there.
You need to have a plan of addressing the vulnerabilities as another parallel of action items, understanding the pen tests, your vulnerability management system, validating it, seeing everything, validating it’s configured correctly.
I’ll go off on a tangent here.
When you come in, don’t assume the tools are correct. I can tell you time and time again, people put in the least amount of effort for those tools, and it’s not always right. So it’s in your best interest to question everything and relook at everything that’s supporting your security environment, your security tools and just doing a round of validation. So that’s something that you can do with your staff in the first thirty, sixty, ninety days just to validate things are where they should be.
Oftentimes, you’d be amazed at what you find.
So taking that and looking at that and focusing on that is very important. You could be planning for long term, but if you get hit with a vulnerability or something that exists, even if you first come in the door, it’s on you. I’ve seen a lot of people come in and focus on the high-end stuff and not dealing with the details.
The details, I hate to say, are very important. For many people that come into a security leadership position, sometimes I see someone that’s fully compliant and working with the leadership, but they don’t really have the technical grasp to understand the real risk and what they might face.
Other people focus too much on the technical side and never really relay and educate to the senior management. So having that right blend is critical and having the right person that can see everything and see the big picture is important. I know a lot of security leaders may be lacking in some areas. It’s very important that you know who you are and what you lack. So if you don’t have that expertise in one particular area, you’re focusing in getting help from someone that does.
Having the right people work for you and work with you is also critically important to your success.
Cost Considerations for Penetration Testing
Absolutely. Would you consider penetration testing something that you would want to do internal, external, or both right out of the gate?
Well, what I found is pen testing is very expensive. Typically, pen testing an app I see on average about twenty thousand dollars depending on how deep you go. Typically, that’s two users and an admin in the two roles. Doing an authenticated pen test on an application is a good start.
However, trying to pen test everything is definitely difficult and expensive. What I would do is I would do an assessment and find out what all your exposed URLs are, kind of like an asset list if you will, on your applications. Figure out which ones are important, which ones are higher risk. Let’s say they deal with payments versus those that don’t. Some have sensitive data, some that don’t.
Taking those apps, figuring out what’s going to be used that’s currently being built, stuff that is being used that’s highly valuable and then stuff that’s sunsetting and then putting a priority list, if you will, of those applications and start assessing those and have some type of plan to assess those, whether that be a pen test, or just getting Burp suite and starting that program internally. Just kind of depends on the resources that you have at your disposal, will help dictate how far and how quick you can move with that. But it’s always good to have a plan and talk with the application leadership, just so they’re on board, so they can weigh into their ideas as well as for where they think you should focus.
Planning for Effective Penetration Testing
Having that connection with the application development team, understanding the tools they have will also help with your pen test. If you have a pen test and you really don’t have the development staff that can fix those, your pen test might only have a small window to do validation. If you can’t get that code or change in quickly, you have the results but really have no way to validate the fixes if it takes your team some time to get that done. So that’s something else to to think about in your statement of work, having around a validation and understanding, what that looks like, just so you have time to actually get the changes in place and have them validated by them if they have the only expertise to do validation outside.
If you have a staff internally, that’s great. Definitely makes things easier. So that that’s just one of those things based on your team size. You just have to figure out what you need to do there. But the validation efforts are very important.
Yes. You bring up a good point. If you are doing an external pen test, there is a window that they say, here’s results.
Now you have this window to go fix the results and we’ll test them again for free to validate you fixed it. And if you don’t go through and and you miss that window, now it’s gonna cost you. So you’re right. You’re bringing up a good point. You know, for those who are listening, if if you’re gonna use an external, pen testing company, you know, put it into your plan, schedule it properly. That way, you have time to, you know, you get the results back and you have a chance and the resources allocated at that moment to address the findings.
Toby, typically with the companies you’ve worked for, you know, you’ve been at and you’ve done these external pen tests, what is the typical turnaround? Three weeks, four weeks, a month, two months, three months?
It really depends on their workload and if you’ve planned in advance and coordinated with coordinated with them on their availability.
Oftentimes, there’s big projects that have different timelines. You need to make sure when you do your pen test, that team is available, and there’s some dedicated folks that can do it. Just because they’re an application developer doesn’t mean they necessarily know how to fix, something, indirect object reference, cross site scripting, SQL injection. You just need to make sure you have the right staff available that knows how to fix that. So what I would recommend is having a plan in advance and the senior people already dedicated kind of as your as your tag team that will go address these. Not only for the pen test, but it’s good to have a dedicated team, you know, that’s planned on the side in case you have some urgent vulnerability you find out about with your application.
Let’s say you have some type of open source component or your DAST or SAST tools have something that bring up something new. Having an understanding of what that deployment model looks like and who it would go to and the time involved is critical. It’s going to be very hard going to them every year not planning and asking them to make changes last minute. It’s just not going to happen. So this is just where some some advanced planning and coordination is definitely key.
Evaluating Security Tools and Technologies
Well, and the nice thing too is with doing a pen test, it also gives you some validation on the tools that you run internally. You know, if you have a DAST system running a DAST scan, hopefully, your DAST results mimic or at least have some of the things well, if you’re doing your job, they shouldn’t be on the pen you know, penetration testing tool reports.
But with DAST, they should at least mimic some of the low hanging fruit that the pen testing companies are gonna find.
You bring up a good point.
If you have stuff that your DAST and SAST tools are showing and you’re not addressing, you’re making the lives of the pen testers easy. They’re gonna find the common stuff and not really dig. So it’s in your best interest, to to do a pen test when you have all the easy stuff off the table, just so they dig and find more. I can’t stress that enough that you’re only gonna get they’re only gonna dig as deep as they think they need to. If they have trouble finding stuff, they keep digging. So you get yourself a better test if you make sure things are in a better state before you get started.
So the goal is one week in sorry. We can’t find anything. Our penetration testing is looking good.
Hopefully, at that point, you’re like, we’ve done our job well. We’re doing a good job. We’re succeeding.
And hopefully, knock on wood, you know, other things are there.
So let’s talk about, tooling if that’s okay with you for a little bit. Let’s dig a little, in a little bit different direction. So with tooling, you know, the first episode, we had talked about coming in and figuring out what tools you have and where they are. Now we’re starting to mature and the questions become, you know, are the tools that we’re using the right tools? Are we using the right companies? Are we using the right, let’s say, ASPM or some technology to bring the results together?
Is this now something that we’re starting to look at as we’ve matured our program? Looking at the results, asking the questions, are we using the right tools? Maybe this is where we come in and say, hey, we need to you know, reevaluate what we’re doing or do we, keep moving forward and what does this look like?
On that front, on the pen testing front and also your security tools in general, you should always be reassessing those at renewal. Hey, is this still the right product for us? Do they have any new modules that they’ve introduced, you know, for security product that we may need to look at? Or maybe there’s some new services that are being provided. That’s definitely key.
The SAST, DAST solution, same thing. Just looking to see if, hey. Are we utilizing this well? Is there something that may work better for us?
And if you can afford it, I would definitely recommend having a tool that can check, your main SAST and DAST environment, even if you just have a one off one license or simple freeware tool that can also do your assessment to back up your scans. It it it’s good to have something else that I know the tool sets are expensive, but I think this is something if you can find, let’s say, a demo of a product, to reassess an application that you’re already assessing with your tools just from a fact check or double check standpoint, I think it’s definitely time spent. And then also just keeping track of the typical Gartner Quadrant, what are people using?
Because I know there’s a lot of competition. I would say the landscape changes greatly where I wouldn’t be surprised if you’re changing the solution every three years.
The Role of AI in Security
Well, today’s buzzword is AI. You’re starting to see AI in all the sales stuff that’s out there. You know? It’s one of those things where it’s like, hey. You know, we have automated remediation or we have automated this or automated that, and it uses AI.
Do you have any thoughts on AI as far as good, bad, ugly?
Well, to be honest, that was what I spent my first half of today working on, just matter of chance looking at Copilot and some of the things there. I definitely think it has its place. I think it’s still fairly new.
You really have to have an idea of what you’re looking for. I think there’s definitely AI is definitely going to be good for the business on automating some of the routine tasks depending on your business model. As far as the automation with IT, I know there’s products out there to do, you know, better code.
I’m just very leery of those products, especially with their cloud access, making sure you understand where your data is going and making sure people don’t have the ability to make a mistake.
So I think having insight there is really important.
However, with your whole user base having the ability to hit the web, I don’t know how good your tools are from letting people go out and start to do things. This is where having policies on what they can and can’t do are very important, especially with code, just so you don’t have intellectual property walk out the door.
So I think the best thing on the AI front is to not ignore it, get ahead of it, have policies and procedures in place and then have some type of blocking on the perimeter if you can and then just continue education with the users.
I think we’ll have more education come out on AI as we get further along. Unfortunately, though, now that it’s so new right now, it’s really a sensitive time, and you need to be aware of what your users might be doing.
No. You bring up a good point because there are companies that make the news where you find out their developers are uploading their entire code base into ChatGPT and other tools and asking it to clean them up for you or make them better for you. And, you know, some things that most companies don’t realize is if you read the terms and conditions, anything you upload into these systems now becomes part of their learning and language model as well. And so now your code is part of their code base.
And so, you know, things to consider as you’re looking at AI tools is just knowing who owns the code, who owns the rights, who owns the stuff that’s uploaded into their systems. Because if you’re uploading something into their system and it’s just using a learning language model in LLM that analyzes it and returns it but not adds to its own, that’s one thing. But if it’s adding to its own learning language and its own, you know, information, then then all of a sudden things can become a little bit more hectic or problematic for you as a company, especially if you’re uploading sensitive pieces of information.
Leadership Engagement in AI Discussions
Yeah. And I will tell you this is where, from an AI perspective, you need to go to the top, work your way down just so everybody’s aware of what you can and can’t do. This has to be a discussion you have at your leadership just because of the unknown and how quick things are changing.
They need to be on board, and you need to be aware of what the business might be looking at because unless you’re on top of it, they might be looking at something and not even involve you purchase it, and then this is in your environment doing x y z. So from an AI perspective, I would definitely have a leadership discussion on this, make sure the business units, hey, we’re aware of this functionality is out there. We are aware of what it can do for your business, but you have to engage us on this before you get started on anything, just so we can assess where the data is going, how it’s gonna be stored, where it’s going from a country and, compliance standpoint, things like that. So this is where having that business relationship is gonna be key, at keeping you aware of what people are doing from an AI perspective.
And it’s also important with your security tools because your security tools may be inadvertently sending stuff over to an AI system doing analysis off prem versus on prem. And so these are things that, you know, in my opinion, as AI forms and and, you know, there’s all these AI components coming out and tools, you know, just something to, you know just another checkbox to, hey. You know, what are you guys doing with the data that is being analyzed with AI? And who’s your AI vendor? Because some people are wrapping current AI vendors out there. For example, you can use the ChatGPT, API endpoint and and tie that into your own system, and there’s companies doing that. There’s also companies using their own learning language models, LLMs, and they’re doing things, you know, definitely differently.
So, it’s one of those topics that’ll be interesting to see as we keep going down the road, you know, what happens with AI. So as we’ve been talking about AI, you keep bringing up training. We talked about training for the C-suites. We talked about training in a lot of other, components. And I want to touch base on this briefly, but security champions. Having a security champion program and, you know, taking that and sharing the information that comes from the security team down into the developers and having a pulse on what’s going on in development. Do you have anything you want to throw in on that?
Yeah. If you’re in a larger organization with a big application team, obviously, you can educate everybody and have everybody involved in the remediation aspect. This is where your champions come in that are typically your architects that have leads. Having them on board and having that communication with them, they can help you greatly by making that change, a culture standpoint, with the rest of the team.
And if nothing else, just bring things to your attention. If they see something that is not good from a security standpoint, whether it be code or some new relationship or some new integration, they’re bringing that to you. So having that chain is very critical on getting things done and establishing the communication of trust. Obviously, security can’t do it all.
We definitely need help from everyone. This is another example of of needing that from the development and leaders in the development team for sure.
Maturing Security Programs
So we’re, you know, we’ve got a lot of great information about what does it look like to mature your program.
You know, we’ve talked a lot about the training. We’ve talked about AI. We’ve talked about the tools.
You know, one thing I’ll throw in there, you know, making sure your security tools are always up to date, making sure you have all your definition files. That that’s that’s key. I would also say something that typically gets overlooked from time to time, and and tell me let me know if you think it is, but firmware updates on your hardware too. You’ve got firewalls. You’ve got other things. I mean, updates go beyond just your simple, you know, tool definition files.
And this is where you have your communication with infrastructure being another important channel.
Having them on board with, the passing, the expectations, having everything documented that you have, the old term, you can’t protect what you don’t know you have.
So having that direct communication with the infrastructure team is important.
So if you have something you see in the news, you know what applies to your environment.
And you also have others on your team or even outside of your team watching that as well. So expanding that with your champions, if you will, into infrastructure, just like you did your application team, is key. Knowing who your contacts are from an infrastructure standpoint to help you with security initiatives will definitely help you in the long run, whether it be for urgent patching, whether it be for implementation of new security tools, just having that, rapport, communication there, to help you when you need, is is is also important.
Absolutely. And, do you ever do any security drills?
You really need to be up to a point of maturity before you can do this, and then having key people be aware of it. So there’s no one that can get in trouble.
I’ve seen people perform tests. They didn’t inform everybody and yet some executives take this. And at the end of the day, we’re not very happy, one, that they weren’t engaged and then them getting concerned because they thought a real event was ongoing. So I think testing is important.
You just need to know who to notify, have that proper channel of who knows versus who doesn’t, and then having those tests well planned out. If you have a phishing campaign, you need to make sure the material and everything you’re submitting and using, doesn’t offend somebody or doesn’t happen to coexist with with something else ongoing. I’ve seen people do really good phishing attempts that just happen to have, you know, something within the phish, related to something bad in the news. So, having a good understanding of what you’re sending out, who it’s going to hit, and the potential negative impact of those tests is important.
I think I’ve got one more question, and then, we’ll kind of bring it to a close here.
Emerging Threats from AI Technology
So one of the things that I share with my family, and it’s kind of a little off topic, but, and again, it almost hits on AI. So one of the threats that’s going on right now is someone can take a recording and a short video of somebody speaking, take their voice, change it over, and mimic a CEO calling the financial officer. This actually just made the news recently where somebody had taken voice samples, changed them, and made it a phone call to the CFO and said, I need some money. Would you please, wire me money? Here’s the information. And actually, the person did because they’re thinking they’re talking to the CEO.
So my question to you is kind of high level. What can we do to protect ourselves from this? I have an idea. I’ll ask you first, and then I’ll share my two cents.
I think it’s very simple just because it’s video, in this day and age. I can’t remember the name of the AI tool that’s used for this. I saw it the other day and mentioned something on it in chat. But, ultimately, what it comes down to is just sticking to your same validation channels that you would if you got a text or an email from someone, just validating through the proper channels, reaching out to them in a different method.
Is still the same path.
Video is no different than email or a text. Just doing that second level validation is critical, just to make sure that isn’t happening to you. Just like anything else on any email you get that’s trying to trick you, it’s something urgent, something on a timeline. So it just goes with the training.
Video shouldn’t be handled any differently. I know that’s gonna be hard for people to do, but it’s just one of those mindset changes with AI. We just have to make that adjustment. So this is where, you know, sending out newsletters, educating the users that this is a new threat, explaining to them this new AI technology.
One of the things that I’ve done with my family is we have a keyword or a term that we use internally to ensure that, you know, if you really are who you say you are, what’s the term? What’s the keyword? And so I would encourage everybody, including even in business, have keywords with each other so that you know that it truly is the right person that you’re speaking to because, you know, if they don’t know the keyword and, you know, at an executive level, I mean, you could be talking a lot of money or a lot of, you know, something that could happen. For example, support may get a phone call from the CEO.
Hey. Please reset my password. I’m stuck. I can’t get in.
Having that password or that extra authentication at that time because the voice could be identical to the CEOs or whoever simply because of AI and the abilities that it can do. And so having that extra layer, you know, a keyword or term or exactly what you just said, Toby. Hey. The CEO just reached out to me. I’m gonna text the CEO to say, are you sure were you the one that just reached out to me? Or I just need to confirm what was the password you wanted me to send as a second method of authentication or, you know, validation.
And then that would be, you know, helpful.
Yeah. And I’d even go to the point where not only is the video something that’s cropping up more, but so is, people hijacking your SIM, from a phone standpoint for intercepting, you know, your SMS messages and whatnot.
I think both of those areas are things you probably should look at this year and make sure process and procedure around all of that as good as it can be, you know, whether it be questions and answers that the help desk already knows. I just see a lot of things where people are bypassing things from a social engineering perspective.
You’ve seen it with Microsoft and some others, even with, you know, getting by their Okta items. So I think this is an area that will probably be more news this year in this front. So having a good plan around validating and improving those processes you already have, they’re worth a review. Yeah.
No. Very true.
Toby, I appreciate the time that you’ve spent with us today. And, you know, a lot of the advice, a lot of the conversation has been absolutely amazing because, you know, this is moving to the next step, next type stuff. Right? The AI and the validations that we were just talking about, you know, the communication with the c suite, you know, what you’re doing when you first walk in the door, the training, the education, all the way around is truly moving the needle in the right path and getting everybody on board to at least understand.
We’re doing a security program. This is what’s going on. Here’s what we’re aiming for. This is what it’s going to take for us to be successful.
The penetration testing and everything comes together to get that next layer and level of security. Thank you so much for your time today. I appreciate it and have a good one. I appreciate it.
So Toby, let’s talk a little bit more about education.
Integrating Security Training with HR
Yeah. So one thing I think is really important when you come into an organization, obviously there’s training that HR needs to provide, from their requirement standpoint. And this is where you can partner with them and add more security aware things, to that training plan with them.
I know a lot of training platforms. If you have some security tools that have videos, I know a lot of corporate training programs you can import those, what they call SCORM files, into the HR training.
So you can have those available to your users as well and incorporate that more in the overall company required training. So if you have those capabilities with your training, let’s say you have, KnowBefore or some other type of platform, you can definitely take those videos, incorporate those into the corporate system, have them track it, and work with HR so as you mature, you might just have the normal user base take x y z courses, you know, securing your laptop, you know, around passwords, you name it. As you mature, you can start to add to those, and some of your controls will also require you to add to those.
For example, you might have some infrastructure staff that are admins, and they might require additional training as you move that maturity model up. Those are some of the requirements to go from a maturity three to a maturity four. So those are some things you can take advantage of with working on this overall plan with HR. You can start to incorporate these things as you get better and mature.
There’s also developer training. You might start off with the basic OWASP type training.
But as you move forward, you might require OWASP for everyone that comes in the door, but provide supplemental training for developers that changes every year after that. So thinking about those things and putting together a bigger plan with HR, as you mature the security requirements in your controls, something that I definitely would recommend.
That way, it’s really not on you to track and trend. The HR system can do that for you.
And it looks better to the users because they have training all coming from one platform. If you have that capability, if you’re in a big organization, definitely take advantage of that with your HR team.
Raising Developer Awareness on Vulnerabilities
No. That’s very true. One of the things that we’ve seen, full disclosure, Toby and I did work together previously and one of the things that we ran into is as developers become more and more educated with the developer side, they understand what SQL injection looks like. They understand what cross site scripting looks like.
They understand what command injection looks like. And as they learn more and more and more about what the different security vulnerabilities are and the common ones and the easy pitfall ones to get into, then what this training, it it brings to light. Now all of a sudden your developer has an moment, they’re looking at source code and all of a sudden they realize, wait a second, I’m staring at a vulnerability right in its eye. I need to do something and this is not a simple vulnerability.
This is a critical vulnerability that needs to be addressed. And so with the developer training and developer education, now you’re starting to raise that awareness with your developers to the point where, you know, they’re starting to now recognize not just from what the tools are, hey, the tools are spending all this stuff out to me. Now the developers are seeing now the tools are coming out with these vulnerabilities. I now see these vulnerabilities or I’m now spotting vulnerabilities that the tools are maybe not able to pick up because of how they’re implemented or where they sit.
And one thing I’ll bring up just from a learning experience, and I can’t believe I have to say this, but I will.
Just because you have some application leadership that you think know coding, don’t always assume that. I found out early in my career that I always thought, when I relate what a SQL injection was to somebody in an application development executive role. They knew what I was talking about.
I found out that was not the case.
They might have thought it was just, hey. This will just limit the application. This is a simple application. I don’t care.
There’s no data in it I care about. However, they were not realizing that once they got a foothold in your environment, they can move laterally into other systems. So never estimate that or never assume that your leadership knows when you’re talking security vulnerabilities of applications that they all know what that is and how it really affects them. So when you’re having those education sessions, be very clear, the worst-case scenario on your pen test, what this stuff really means to the organization.
Exactly. And something else to consider too with your pen testing or as you’re, as you’re finding things and seeing things from a security team or, you know, from the development side, record those. Right? Record the fines, record this, you know, the attacks because, you know, that way if you record the attacks and you share it with the development team, now they can physically see how did you carry out the attack, how can I validate that I fixed the attack? Because having the how did they attack me, how did they get through, what were the steps. Some things are multi layered where I have to stack two or three or four steps on top of each other before I can get in. And once you start getting to that layer and that level, you know, it makes it tougher for the tools to be able to dig in and actually get a hold of and find for you.
Right. And one other thing you may find out in those discussions, for example, I’ll use an item I’m familiar with. Indirect object references are found in pen tests often because authentication isn’t around, a lot of the requests. So this is where, hey.
The pen test is gonna keep finding these over time. They keep digging. Let’s go back and fix the real reason and problem behind this code, around the the real problem with authentication. So these pen tests can not only point out things that are wrong, but point out things on a bigger scale that are wrong with your application.
Collaborating with Teams for Effective Solutions
So having the various teams when you’re going through the pen test, the initial reports, talking with the pen testers and figuring out what’s the best way to approach this.
The documentation will typically have you hitting the mole, if you will, on the head, like the mole game, when in reality, you should be going back and looking at how you’re doing this within the whole application and changing your ways that you’re addressing, which might just require a complete change of direction in how your application functions, which is probably a bigger code change. But ultimately, at the end of the day, that is probably faster, easier, and more complete than, you know, hitting the individual object reference items during each pen test when they find more and more. So just something to think about, when doing those tests and having an understanding and relaying to leadership how it’s important and what things need to be done to truly fix them.
And when you have the same development team that you scan an application, look at what else the team has written because typically a lot of the methodologies or the, thoughts and and design for one typically spans multiples. So it’s more than just scanning one. Yes. We scanned one application. We focused in on one application. But take those findings and go look at factor authentication?
You know, are they at the same standard? Do I have multi factor authentication capability designed within my own application to help enforce that our users using the application are in a better place?
Right. And the education of the application developer is important. You may go fix something and they reintroduce it. So having education there is important, but also your QA process, understanding, you know, your stop gates and making sure those exist to make sure things are fixed before they’re rolled out into production, is also critically just to prevent something from being deployed that shouldn’t that isn’t ready.
Thank you so much for joining us today on Secrets of AppSec Champions. If you found today’s information valuable, hit that subscribe button on your Apple Podcast, your Spotify, or wherever you’re listening to today’s episode.
Ratings and reviews are like gold for us. So if you’re feeling generous, please leave us a kind word as it helps others find our show. Until next time. Take care.