Chris Lindsey [00:00:01]:
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 DAS system running a DAS scan, hopefully your DAS 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 DAS, they should at least mimic some of the low hanging fruit that the pen testing companies are going to find.
Toby Jackson [00:00:27]:
Right? And 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. They have trouble finding stuff. They keep digging.
Toby Jackson [00:00:56]:
So you get yourself a better, a better test. You make sure things are in a better state before you get started for sure.
Chris Lindsey [00:01:04]:
So the goal is one weekend, 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 would, you know, other things are there. Hello, and welcome to the secrets of Appsec Champions podcast. My name is Chris Lindsey and we are continuing our series decoding application security. Today we're going to speak with Toby Jackson about maturing your program. What does that look like? What does it look like to take it to the next step? With that being said, welcome to the program, Toby.
Chris Lindsey [00:01:41]:
Please introduce yourself.
Toby Jackson [00:01:42]:
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. Currently, 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.
Chris Lindsey [00:02:12]:
Awesome. Thank you for coming, Toby. That's absolutely amazing. So let's hit the ground running. 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. It's going to that next level.
Toby Jackson [00:02:30]:
So the next step might be actually doing a maturity and risk review. There's a lot of templates out there. New York DF's 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 kind of get a gauge of, from a true standpoint, where the organization is and what stuff can also supplement your risk and gap list that you've already created.
Chris Lindsey [00:02:57]:
And so 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?
Toby Jackson [00:03:09]:
It 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 mid year, 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 real critical for the leadership as you're continuing to educate and have meetings with them. They like to know what's next.
Toby Jackson [00:03:48]:
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.
Chris Lindsey [00:04:06]:
It's one of those things where we 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, you bring up a good thing with that risk. 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.
Toby Jackson [00:04:45]:
It the first time, it's New York DF's. So there is an FFEIC cat assessment is what they need to look for. So that's something that's real simple that you can use your financial institution, but I find it's pretty simple and it's a good gauge of things with minimal time.
Chris Lindsey [00:05:01]:
No. Very cool.
Toby Jackson [00:05:03]:
And in 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 30, 60, 90 days to validate.
Toby Jackson [00:05:52]:
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. So 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. So for many people that come into a security leadership position, sometimes I see someone that's fully compliance 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.
Toby Jackson [00:06:36]:
So having that right blend is critical. And having the right person that can see everything and see the big picture is important. So 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 and getting help from someone that does. So having the right people work for you and work with you is also critically important to your success.
Chris Lindsey [00:07:04]:
Absolutely. Would you consider penetration testing something that you would want to do internal, external, or both right out of the gate?
Toby Jackson [00:07:11]:
Well, what I found is pen testing is very expensive. Typically, pen testing, an app, I see on average about $20,000 depending on how deep you go. Typically that's, you know, two users and an admin in, you know, the two roles, doing an authenticated pen test on an application is, 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 URL's 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.
Toby Jackson [00:07:49]:
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, 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 in to their ideas as well as far as where they think you should focus. So 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 think about in your statement of work, having a round of 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.
Toby Jackson [00:09:13]:
If you have a staff internally, that's great. Definitely makes things easier. So 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.
Chris Lindsey [00:09:24]:
So you bring up a good point. So if you are doing an external pen test, there is a window that they say, here's your results. Now you have this window to go fix the results and we'll test them again for free to validate. You fixed it. If you don't go through and you miss that window now, it's going to cost you. So you're right, you're bringing up a good point for those who are listening. If you're going to use an external pen testing company, put it into your plan, schedule it properly. That way you have time to you get the results back and you have a chance and the resources allocated at that moment to address the findings.
Chris Lindsey [00:10:02]:
Toby, typically with the companies you've worked for, you've been at and you've done these external pin tests, what is the typical turnaround? Three weeks, four weeks, a month, two months, three months.
Toby Jackson [00:10:14]:
It really depends on their workload and if you've planned in advance and 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 tag team that will go address these, not only for the pen test, but it's good to have a dedicated team 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.
Toby Jackson [00:11:08]:
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 advanced planning and coordination is definitely key.
Chris Lindsey [00:11:26]:
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. 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.
Toby Jackson [00:11:52]:
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. So you get yourself a better test if you make sure things are in a better state before you get started for sure.
Chris Lindsey [00:12:25]:
So the goal is one weekend, 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, other things are there. 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 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, 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 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 re evaluate what we're doing or do we keep moving forward? And what does this look like on.
Toby Jackson [00:13:28]:
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 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's good to have something else that is looking at your tool set. 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.
Toby Jackson [00:14:27]:
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 a solution every three years just based on what I've seen.
Chris Lindsey [00:14:38]:
Well, and today's buzzword is AI. You're starting to see AI and all the sales stuff that's out there. It's one of those things where it's like, hey, 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?
Toby Jackson [00:14:58]:
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. 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 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.
Toby Jackson [00:15:36]:
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 continual 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.
Chris Lindsey [00:16:27]:
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 chat, JPT and other tools and asking it to clean them up for you or make them better for you. And 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. Now your code is part of their code base. 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 information, 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.
Toby Jackson [00:17:31]:
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 XYZ. 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're aware of what it can do for your business.
Toby Jackson [00:18:13]:
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 going to be stored, where it's going from a country and compliance standpoint, things like that. So this is where having that business relationship is going to be key at keeping you aware of what people are doing from an AI perspective.
Chris Lindsey [00:18:34]:
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 in my opinion, as AI forms, and there's all these AI components coming out and tools. Just another checkbox too. Hey, 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 chat GPT API endpoint, 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 definitely differently. So it's one of those topics that'll be interesting to see as we keep going down the road, what happens with AI.
Chris Lindsey [00:19:28]:
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 and a lot of other components. And I want to touch base on this briefly, but security champions having a security champion program and 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?
Toby Jackson [00:19:58]:
Yeah, if you're in a larger organization with a big application team, obviously you can't educate everybody and have everybody involved in the remediation aspect. This is where your champions come in that are typically your architects, the head leads, having them on board and having that communication with them. They can help you greatly by making that change from 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. Well, outside of security, obviously, security can't do it all. We definitely need help from everyone.
Toby Jackson [00:20:50]:
This is another example of needing that from the development and leaders in the development team, for sure.
Chris Lindsey [00:20:56]:
We've got a lot of great information about what does it look like to mature your program? We've talked a lot about the training. We've talked about AI. We've talked about the tools. One thing I'll throw in there, making sure your security tools are always up to date, making sure you have all your definition files. That's key. I would also say something that typically gets overlooked from time to time. And, Toby, let me know if you think it is. But firmware updates on your hardware, too.
Chris Lindsey [00:21:23]:
You've got firewalls, you've got other things. I mean, updates go beyond just your simple tool definition files.
Toby Jackson [00:21:32]:
And this is where you have your communication with infrastructure being another important channel, having them on board with the patching, 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 input, 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 also important.
Chris Lindsey [00:22:25]:
Absolutely. Do you ever do any security drills?
Toby Jackson [00:22:28]:
You really need to be 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 you had some executives take this, and at the end of the day, we're not very happy. One, that they weren't engaged, and then two, them getting concerned because they thought a real event was gone going. 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, or doesn't happen to coexist with something else ongoing. I've seen people do really good phishing attempts that just happen to have something within the fish related to something bad in the news.
Toby Jackson [00:23:26]:
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.
Chris Lindsey [00:23:36]:
So one of the things that I share with my family and it's kind of a little off topic, but 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, at a 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 cent.
Toby Jackson [00:24:31]:
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.
Toby Jackson [00:25:09]:
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 going to 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 sending out newsletters, educating the users that this is a new threat, explaining to them this new AI technology.
Chris Lindsey [00:25:31]:
One of the things that I've done with my family is we have a keyword or term that we use internally to ensure that 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 if they don't know the keyword and at an executive level, I mean, you could be talking a lot of money or a lot of something that could happen. For example, support me. 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 CEO's or whoever, simply because of AI and the abilities that it can do. And so having that extra layer, a keyword or term or.
Chris Lindsey [00:26:23]:
Exactly what you just said. Toby. Hey, the CEO just reached out to me. I'm going to text the CEO to say, 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 validation? And then that would be helpful.
Toby Jackson [00:26:42]:
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 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 is as good as it can be. 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 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.
Chris Lindsey [00:27:32]:
So, Toby, let's talk a little bit more about education.
Toby Jackson [00:27:34]:
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 nobu four 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 on formalizing a better year plan. So as you mature, you might just have the normal user base, take XYZ courses, securing your laptop around passwords, you name it.
Toby Jackson [00:28:40]:
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 Oauth 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.
Toby Jackson [00:29:23]:
So thinking about those things and putting together a bigger plan with HR as you mature, the security requirements and 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. So if you have that capability, if you're in a big organization, definitely take advantage of that with your HR team.
Chris Lindsey [00:29:50]:
That's very true. And 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 with this training, it brings to light. Now all of a sudden your developer has an aha 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.
Chris Lindsey [00:30:40]:
And so with the developer training and developer education, now you're starting to raise that awareness with your developers to the point where they're starting to now recognize not just from what the tools are. Hey, the tools are spitting 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. So, no, that's absolutely important.
Toby Jackson [00:31:13]:
And one thing I'll bring up just from a learning experience, I can't believe I have to say this, but I will. Just because you have some application leadership that you think no coding, don't always assume that. I found out early in my career that I always thought when I relayed 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.
Toby Jackson [00:31:44]:
However, they were not realizing that once they got a foothold in your environment, they can move laterally into other systems. So never assume that your leadership knows when you're talking security vulnerabilities with 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.
Chris Lindsey [00:32:10]:
Exactly. And something else to consider too, with your pen testing or as you're finding things and seeing things from a security team or from the development side, record those right, record the finds, record the attacks, because 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 multilayered where I have to stack two or three or four steps on top of each other before I can get in. Once you start getting to that layer and that level, it makes it tougher for the tools to be able to dig in and actually get a hold of and find for you.
Toby Jackson [00:32:54]:
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 going to keep finding these over time, they keep digging. Let's go back and fix the real reason and problem behind this code around 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. So having the various teams, when you're going through the pen test, the initial report, 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, you know, 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 that particular item, which might just require a complete change of direction in how your application functions, which is probably a bigger code change.
Toby Jackson [00:34:03]:
But ultimately, at the end of the day, that is probably faster, easier and more complete than 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, right.
Chris Lindsey [00:34:27]:
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 were the thoughts 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 your other applications and ask the question to your point. Authentication mechanisms, are they correct? Is it the same? 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.
Toby Jackson [00:35:11]:
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 your stopgates and making sure those exist to make sure things are fixed before they're rolled out into production is also critically just as important just to prevent something from being deployed that shouldn't.
Chris Lindsey [00:35:36]:
Toby, I appreciate the time that you've spent with us today and a lot of the advice, a lot of the conversation has been absolutely amazing because this is moving to the next step, next type stuff, right? The AI and the validations that we were just talking about, the communication with the C suite, 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, hey, 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. Toby, thank you so much for your time today.
Toby Jackson [00:36:21]:
Thank you, Chris.
Chris Lindsey [00:36:22]:
Have a good one. I appreciate it. Thank you so much for joining me on this episode of Secrets of FAfSec Champions. If you found this valuable, hit that subscribe button on Apple Podcasts, Spotify, or wherever you get your podcast cast. And hey, ratings and reviews are like gold forest. So if you're feeling generous, please leave a kind word. It helps others discover our show. Until next time, take care.
