Episode Transcript
[00:00:00] Speaker A: Miguel, welcome aboard to the show. So happy to have you with us today.
[00:00:04] Speaker B: Nice to meet you. How are you? It's a pleasure.
[00:00:05] Speaker A: So first of all I'll call out that you're calling from Spain so it's quite late at night, so I appreciate you joining today.
[00:00:13] Speaker B: Yeah, yeah. Well, it's almost 9:30 here, so. No problem. It's late, but not that late.
[00:00:21] Speaker A: Wonderful. I gotta ask, Miguel, what got you into cybersecurity? What was your origin story?
[00:00:28] Speaker B: Well, it's a long story actually it started when I finished the university. Well, most of the people will study like cybersecurity courses or programs when they were doing their university studies. That was not my case actually in the university I took like two courses I think related to cybersecurity. One was like system security and the other one was like crypto, cryptographic stuff but nothing really deep. Actually the career in the university was more focusing, developing stuff, you know, that was the trend at that moment. I am Talking about like 15 years ago maybe. But yeah, well, when I finished the university it was like I found a course related to ethical hacking, actually a kind of short to medium term program in an institute there in Peru. Well, I found it interesting because there is, well, ethical hacking is not something that you will learn in the university, let's say or something about you won't be able to find a lot of information about that easy, you know, not in that time. So I found it interesting. I remember I talked with my parents at that moment because, well, I just finished at the university, I was in an internship, it was my first job. So I didn't have enough money to be there to earn money on board me. So well, they agreed and well, I started that way. It was in 2013.
At that moment I was not working in cybersecurity but it was, let's say a life changer for me because I started to see IT and information systems in other way. You know, it was funny because at the moment, well, I was the only one in the job talking about vulnerabilities and attacks, hacks and hacking stuff and well, some of my managers, well, they listen a bit but well, they don't care a lot, at least at the moment. But yeah, well, that's the story. Then I started. I have done a lot of studies after that I was in the MIT also back into 2017 and well, I recently, well, in 2020 I was. I moved here to Spain also to do a master's degree in cybersecurity and now I'm currently doing a Threat intelligence. Cyber Threat Intelligence Master.
[00:03:13] Speaker A: Also, what was the moment that you kind of fell in love with cyber security? Do you remember anything very memorable?
[00:03:23] Speaker B: Well, I think it's, I think. Well, at that moment, I'm talking about 2013. I think it was the fact of being able to do something dangerous. Let's site within a control context, you know, so ethical hacking is basically that using the techniques from the attackers within a defined scope. And well, in order to, in order for people to do that, you need to know how exactly things work behind, you know, so I think it was a mix of these both things because I'm a very analytic person, let's say I like to know how things work behind the scenes. And yeah, if I cannot understand something or if I don't know how it works, well, I'm just to take a couple of hours, make a research and well learn and then apply this knowledge. I think it's a kind of scientific mindset, let's say something like that. I don't know.
[00:04:34] Speaker A: I love that. So I want to talk about penetration testing. I have been vocal on this show that doing pen testing once a year has little value. But there's a different approach that I think is intriguing. And what they really do in this approach where you've been involved in is you're really outsourcing the pen testing to a community. And then instead of paying maybe 20, 50, $100,000 to one pen tester organization, you're giving out these awards to ethical hackers who are actually able to penetrate the system. There's something brilliant about this because it's happening continuously as opposed to pen testing happening, you know, once a year. For your audit perspective, I wanted to learn more about this. I love the concept.
How do you even tap into a community? If a company wanted to, you know, start their own kind of crowdsourced pen testing approach, how do you even go about thinking about that?
[00:05:38] Speaker B: Well, at first, well, as you, as you have mentioned, is, well doing, doing a pen test once per year. Right now, it's, it doesn't, it doesn't make sense. Maybe several years ago, maybe it worked. But the reason why it is not recommended. Well, it's not recommended to do that nowadays is because the surface, the exposure surface, it's constantly changing. Right now, Right now. Well, we have a lot of systems or business processes that are supported by IT processes, by IT tools, IT technologies. Everything is connected. Everything is on Internet, you know, and the surface on Internet. It's constantly changing. The technology is constantly changing. We are seeing now very complex Attacks that are doing by leveraging artificial intelligence, you know.
So that's why in this constant changing environment you need to make regular checks in a minor frequency, let's say. So because of that. Well, several companies have done pen testing models, let's say like the back Pontis program or like said models of pen testing that allow the companies to perform continuous pen tests. When I say continuous, I mean 24, seven hour. 24, seven hours, seven days per year. No holidays, no vacations. Obviously we are talking about pentesters, teams. Well, we are talking about teams of 400, 300 pentesters per company, let's say most of the time. And as far as I know, these kind of companies select people or combo, invite people to join the bug bounty programs. They evaluate them and well, they make a kind of ranking according to the experience of each pen tester, you know. And also they classify the pentesters by their specialty because there are a lot of different kind of attacks. So there are people that pentesters that are specialists in a specific attack and it doesn't matter how complex it can be, they can break the system to get in, you know. So yeah, it's a very interesting model to do pen test and well, it's a benefit for organizations that want to have a continuous review of their systems. You know, basically is that basically how.
[00:08:43] Speaker A: Do you, as an ethical hacker who's really trying to find vulnerabilities in order to help the organization be protected.
How do you, how do you do so in a way that you don't create damage?
[00:08:58] Speaker B: Yeah, well, it is important in an ethical hacking perspective to have a definite scope also. Sorry? Well, it's important to have a definite scope. This scope should be reflected in the contract that should be signed by both parties. I mean the organization that want the service and the company that is offering the service. And there are some kind of. Well, it is called rules of engagement. You know, basically we can call them as the rules of the game. You know, there are. You can establish in these rules what kind of attacks you can perform, what other attacks you are not able, not able and you are not allowed to. To do. The most common attack in this category, it's the negation of services and well, you can define a lot of things inside this rule. So that makes the pen test.
Well, it allows to do the pen test in a controlled environment or with a control scope and it assures that there will be no damage to your systems or to the continuity of your operations.
[00:10:09] Speaker A: Is there a risk because you're kind of Putting certain types of attack out of scope. Is there a risk that malicious hackers might use those type of attacks and you are vulnerable and you won't find it? And if so, what's the solution?
[00:10:23] Speaker B: Yeah, it could be actually, for example, if you, if you don't. Well, there are two kind of tests. The traditional one in quality assurance stage, in the development process. The most common testing is the functional testing.
Just verify that everything it's doing, the every option is doing what they are supposed to do, you know. But in the other hand you have the security testing, you know. But what common, a common thing between these two kind of tests? It's the stress testing. It is basically a kind of test where you send a lot of requests, for example to a specific system or specific, specific functionality in some the system just to try to saturate the system and try to see how the system behaves in this situation. So basically it's the same as denial of service attack, you know. And yeah, if you don't test that and someone tried to do a denial of service to your system, there is a possibility that this system will not that will go down, you know, but it's a risk. Yeah, I agree with that. But you need to consider also that there is a concept that it's called security in depth or deep security.
[00:11:49] Speaker A: Explain, talk us through that. What do you mean by that?
[00:11:52] Speaker B: Yeah, well, security in dev basically is to apply different layers of security in different levels where you, well, and this make you, or bring you the opportunity to block attacks in any of these layers. If the first layer fails, you can block the attack in the next one. If the second layer fails to well, you can block the attack in the third layer and so on. So that is basically security in depth group, let's say of several controls.
Define it to break the kill change of an attack. You know, actually there is a interesting model that it's called kill change attack that basically defines every stage that an attacker will do in order to perform an attack. So it is helpful for organizations that want to implement security in dev because you will know exactly what an attacker will do in each stage. And you can also define controls to or countermeasures for each of these stages.
[00:13:12] Speaker A: What's really important about this, let's call it a philosophy, is really you're modeling your redundant layers of protection based on attack mechanisms. Just kind of think of it, you know, our audience should think about it as if, you know, you're thinking like a hacker in order to basically defend yourself. I think that's a really important concept, especially since a lot of our audience are not necessarily deep into the technical weeds. I appreciate that.
Do you see organizations having complete test environments that are 100% mirrored to production in order to do more sensitive denial of service testing or is that just too expensive to do nowadays?
[00:13:54] Speaker B: Well, it is expensive to maintain actually. But yeah, I saw some organization that are compliant with this requirement. I say requirement because. Well, there are a lot of standards and frameworks that recommend and request this, like ISO27000 or the NIST or any other kind of frameworks that are being used. But yeah, it's hard to maintain, it's hard to implement, let's say. But it's something that it's crucial actually because you can perform pen tests or security tests in production environment. Yes, but you need to be very careful. But there are other kind of specific use cases when you cannot do that. So you need to go to pre production environments and in order to get significant findings, I mean findings that will reflect the reality in a production system, the pre production environments have to be, have to be very aligned or very similar to the production.
[00:15:04] Speaker A: This is a very, very important point because I think what a lot of organizations do, they have a test environment, it kind of doesn't have data or it has garbage data in it and it's not really identical to production. It's quite expensive to create a mirroring process that mirrors production. But once you do it, that's a really good asset to have. And I think there's two advantages. One is of course on the security front, but one advantage that we don't talk about enough I think is that functional bugs that happen in production might not happen in your test environment if they're not completely mirrored. So I think it's a really important quality assurance technique that you're talking about. And there really isn't valued enough. I would love to see more companies doing it. And it's also fair to say another hack or another cheat, you don't have to have your test environment set up all the time, right? If you're doing your release of your software every three weeks or every two weeks, you can set it up for a day or two or three and shut it down later if you don't want to use it. So there's easy ways to basically automate this whole process so you're not really spending as much as you would spend if it was on all the time. So I appreciate those comments, Miguel. When you look at following up so the community finds a vulnerability, you could need to speak to anybody in their organization, from a front end developer to a database developer. How do you even figure out who's the right person to do? And then what do you do next? How do you even engage a discussion with engineering?
[00:16:47] Speaker B: Well, it's something hard to do actually because sometimes. Well, I have worked in several organizations and sometimes I saw that there is not a clear, let's say, structure for a functional extractor, let's say in other cases there are some people that don't want to, to take the responsibility for the assets that they are responsible for. I remember a case back when I was back in Peru where it was a manager that was responsible for several servers, let's say, and we got a finding that could impact on these servers, taking down the servers. And well, he answered us that, well, he won't apply any kind of fix or he won't provide any kind of action plan because for him if the server are offline because an attack, well for him that's not a risk. So it's something funny because you don't expect that kind of answers. But yeah, it's the reality sometimes.
[00:18:04] Speaker A: Well, what was his explanation? Was it about oh, we can easily restore this, we can easily recover. Downtime isn't very costly. Like how did he justify that perspective?
[00:18:17] Speaker B: He didn't give any explanation for that answer. It was just like that. And that's why I remember, I always remember that situation. Because if you don't believe that that's a risk for the operation for the company, not only for you. Because in the end, as I mentioned before, businesses are supported by IT processes, by IT technologies, by IT tools. So in the end, if it fails, the business will fail too. And some people are not aware of that.
[00:18:52] Speaker A: You know, this is actually a really important point and I'll make an argument, let's see if you agree. For security engineers and engineers in general to have a good appreciation of how their tools actually support the business can be incredibly valuable in terms of prioritizing and understanding where to put their focus and their energy.
[00:19:19] Speaker B: Well, actually that is something that people should do, but it is hard to do. I mean, identify critical processes, business processes, and then classify them and try to realize what technologies are behind. It's something hard to do mostly because real case, the person who developed the system is no longer working with us.
[00:19:46] Speaker A: Nobody knows.
[00:19:48] Speaker B: Yeah. And there is no documentation about this process. You know, that was something that I saw frequently in the companies that I work for, but not that often.
I think it's something that happened everywhere actually.
[00:20:05] Speaker A: No, absolutely. You Know what one of the IT managers I worked with did? They're like, okay, we don't know whose this is. We don't know who owns it. We don't know what business process is. We don't know what it's doing. They're like, okay, let's do an experiment. They shut it off.
Let's turn the server off and see what happens.
Lo and behold, they had me on the phone. Me. They had me on the phone 20 minutes later and like, nope, we need that. This is what it does.
[00:20:33] Speaker B: Yeah, sure. If someone complain, well, it is useful for someone. So, yeah.
[00:20:38] Speaker A: Yes, now we know who you are, basically was their response. I gotta tell you, I was not happy, you know, with them at that moment. But I get it. I mean, I understand. Especially if your vulnerability is affecting potentially the wider organization, if it's not isolated. Right. If it's giving you a, you know, zero day or anything like that. Miguel, what an absolute delight. I appreciate it. This is the art of going down the rabbit hole. We went down all kinds of rabbit hol today. I want to ask you one last question. If you had to go back to, you know, 20 something year old Miguel, and this is a difficult question, it's a personal one, what would your advice be to him?
[00:21:17] Speaker B: Well, that's a hard one, actually.
[00:21:20] Speaker A: You know, there's not one person that we ask this question and there's not like an audible like that. So, you know, I'll give you a discount that this is a difficult question.
[00:21:29] Speaker B: Yeah, yeah. Well, something that I will say to a younger me, it's that keep walking, keep doing the stuff that you believe. You know, stick to your convictions, let's say, to your ideas, to your. To your ideals and yeah, just keep walking.
Go further, follow your path.
[00:21:55] Speaker A: Miguel, thank you so much for joining the show today. I appreciate you.
[00:21:59] Speaker B: Thank you, Ari. Thank you. To.
