Understanding the Continuous Security and Incident Response Landscape

TLDR;

Thanks, Jan, for the insightful conversation. Here are a few things that I gathered.

• For the compliance and security debate, understand different personas and their agendas, have a governing body that works with all of these personas, and helps with prioritization.
• Always start with basic security practices and focus on one program at a time so that it doesn't get out of hand when it comes to implementing security practices or compliance controls.
• Network segmentation plays a major role when it comes to incident response. It helps with reducing the blast radius.

Host: Hi, everyone. This is Purusottam and thanks for tuning into the ScaletoZero podcast. Today's episode is with Jan Hertzens. Jan is a senior security consultant at AWS. He has been active in technology for decades across various disciplines from security and integration to name a few. He has worked in various roles as well like developer, functional analyst, team leader, and consultant. And he also created XCleaner in 2001 the first anti-spyware program at that time and co-founded a company called Xblock Systems in 2002 and served as its CTO.

So yeah, thank you so much for joining me in the podcast today.

Jan: Thanks for having me.

Host: Absolutely For our audience, do you want to briefly share about your journey?

Jan: So how this all happen the the weird accent is Began? I started my career as a regular application developer doing Oracle Form 6 for those old enough to remember that and then worked at Capgemini Ernst & Young as a manager of what was then called the Internet Company in Cine Center where we had to work directly with customers and actually had to explain to them what the Internet was and why we would be good at them.

And it also involved everything from building the application to building the servers to doing the networking to securing everything. So there are lots of stories on the security of early web servers, which I will not get into today

And yeah, while I was doing that in the early 2000s, I accidentally started a company with a buddy of mine in Ohio because we stumbled on a gap in the market in terms of anti-spyware, anti-spouseware is what it was called then as well. So commercial keyloggers were being sold to literally spy on people. So we built the solution on that. That was sort of, started as a joke because the software said, this is completely undetectable and unremovable. And I took that as a personal challenge. And we built a company that did that.

And then I took a year's sabbatical letters and young to go run the company in Ohio and then one thing led to another sold the company to another company in Silicon Valley I did a couple of years here and moved around a little bit to another company which was like a medium-sized startup where I was director of security responsible for the sort of software as a service call center company that did that.

And then after that, I ended up at AWS as a security consultant, basically doing sort of the same thing as I was doing in the immediately off the books. A little bit is helping my buddies who were running startups, getting them secured. Now I'm doing it with more firepower behind me.

And would let the need for begging and screaming to get funding for security.

Host: That's quite an interesting journey. So I'm curious, what does a day in your life look like nowadays?

Jan: So in terms of the roles, so at AWS, we have a professional service department whose role is to get our customers in the cloud. Underneath of that, you have various specialties like big data, IoT, database, etc. And the security specialty helps our customers move their more sensitive workloads.

And the workload customers can be very broad from sitting down with the CTO to discuss the PCI strategy for the next couple of years to working with a developer to debug an S3 bucket policy, giving training or workshops, helping with presales, hacking Python code, and when I'm not working with customers, I'm usually mentoring new colleagues or obsessing about some internal process improvements.

It isn't really a typical day for me. In the years before Armageddon, I was often flying out to visit customers in sort of interesting locations. I did projects from Honolulu to London and I like soaking up the culture there.

And these days I'm working mostly remotely. yeah, most of the stuff is handled via video conference. And this greatly confuses my puppy because he always thinks that there's new people that might be. So yeah, that's about it.

Host: And especially you work with so many customers, so every day it's not the same team, right? So.

For today, we are going to talk about like continuous security and incident response. So let's start.

There is always a debate between security practitioners and experts when it comes to compliance and security. And at the same time, practitioners understand that you have to balance between both of them, like compliance requirements and continuous security.

So can you help us understand what these mean when we say continuous security or compliance requirements?

And how are they different from each other?

Jan: Split it up in basically three personas that I deal with three three types of people all with their own agendas and drivers, right?

There the people who are building apps who don't want to get polled right so did not get owned is their driver There are people that do compliance like we have to do PCI compliance because that's the law and if we don't then they're shut us down and now we don't have any money and then we're going to be homeless. That's their drive.

So they need to check some boxes, right? For that, whether you like it or not, some boxes need to be checked, right? So that's their driver. And then there's, the management team, which drives this stuff and they have a more high-level view of that.

What typically happens is they get some product that says like, run this on your system and it'll tell you how many vulnerabilities you have. And they put it on a graph, their job their focus is to make the line go down right? There's now so many vulnerabilities. There are 10,000 now by the end of the month I wanted to 5,000 or whatever to make life right so the not get pwned Check the box and make the line go down.

And Those are needed to be balanced right the last sort of sort of kind of the easiest one mostly. Because They have, have, There's only one criteria there that you see. combining it with the other ones, that's where the art is. quite often they are in conflict.

For example, I had a customer who they say their focus is on not getting pwned, Their main focus was literally on line go down They were doing things like hey this vulnerability scatter said that we have 14,000 vulnerabilities on our EC2 and Directed a whole bunch of people trying to fix those.

But, they didn't realize a couple of things like some of them things were Systems in auto-scaling groups Let me let you think about why that is a little bit silly because The short answer is if the auto-scaling goes up and down then you have to repatch those four thousand thing. The other problem is That they had was all of the stuff was not properly managed and old systems, right?

So if your OS is no longer supported, then you can try patching, but you're just going to get new vulnerabilities, right? So there's the triage process that needs to be done in there that wasn't being done, right? So you focus on the line going down because you think you're securing it, but you're not right. And then, on the other hand, you have things like,

Hey, the developers have admin access in production and they have keys on their laptops. That's in my book, a bigger problem than that.

Host: I guess what you're highlighting is the priority, right? persona, the three personas that you highlighted have different agendas and different priorities. Balancing them is the most important factor instead of just looking at one persona and driving the security program based on that, Right?

So then in that case, how do I find that balance?

Jan: Most indicative of success at customers in running these programs is they have a well-supported center of excellence for their cloud security. You can call it different things, but that's sort of what I mean. A central location Understand what's going on and that manages it centrally and that sets the rules right like And that's something that you have to explain on the line go down people is that not all of these 20,000 vulnerabilities are equal to each other. It's not involved 1400 of them that it's better than you solve these three about there.

So to me running these scanners is like going to the doctor and getting an EMR scan or any sort of scan over your body right it'll say like well you have ingrown toenails. You let's work no you also have possible liver cancer let's deal with that first right so yeah so i just made that up not a real doctor but those are the things you have to have to do the triage process first and drive based on of that.

It doesn't help like setting these things and doing the patching like crazy on our time ship You have to set up the policy first. Are we making those images properly? Who's making them like those high-level things that need to be done first?

And quite often these things are processes that get fired off because there's a problem Because it was an exploit because they got pwned, Right? There's an immediate reaction. Fix everything right now without thinking like, let's cut the toenails first. No, let's do the most important first stuff. Let's the policy on you shouldn't be drinking that much tequila. So those are those are the different things.

Host: So having that central governing body which looks at each persona and their agenda and then sets the priority would help the organization if I.

Jan: Yes. It's on them to also speak the different languages to the other people. here's a report in nice primary colors, which has the graphs on it and stuff like that and drive that.

That's what I sometimes do like make that report but also do it differently than what the tools generate. Do the report per team. Like this team versus that team and now all of a sudden the manager knows how to manage. That thing is running behind like I got to go yell at this dude, right, and then on the other hand like the thing that I found out is quite often those development teams. They're good at developing but they're not necessarily very fluent in cloud.

So what I try to do for them is to come up with easy how-to's and Big stuff that they can say here. This is how to make sure that your S3 bucket is encrypted. This is how you make sure that you apply for a WAF. Here's an example of it. And here's a script that will deploy it. Instead of just giving them the white paper and here, go figure it out.

They don't have time to learn 14 new different concepts. They just want their product released because their manager is yelling at them, why are they late?

Host: One of the things that you highlighted, which I really like is the communication.

While working with different personas, you have to tailor your message accordingly. You cannot have one-size-fits-all communication for all of them.

So when it comes to the cloud, you have to incorporate both those strategies, from a compliance perspective, and also from a practical security implementation. And often, the organizations follow based on some compliance regulations. It could be driven by data residency requirements sales goals or any certification that you need to attain.

So how do they differ from practical or continuous security implementations?

Jan: I'll have to do a quote here from my favorite philosophers. It says, I fear not the man who practiced 10,000 kicks once, but I fear the man who practiced one kick 10,000 times. And that was Bruce Lee saying that.

I feel like a lot of these Implementations try to do everything all at once without really focusing on a particular thing or doing the basics, right? Like doing the basics of networking and I am, etc, right? Those are the things where it all quite often goes wrong in my opinion You have, the compliance requirements must be important. That's one of the things that I always ask when I go somewhere like, okay What are your requirements, right? Do you have PCI? Do you have a hip or do you have whatever right? Let's put it on board like these are the things that you have an internal program.

And then the thing that people usually don't do is Ask why we want to have this. Right. we need a Palo Alto Why? Because we want to inspect the stuff. Why? we have to decrypt the stuff. Okay. Why?

Why do you want to see that?

What is he going to do?

Like, well, with compliance. Yeah. But why is it, what is the higher-level goal that you're trying to do instead of just checkboxes and stuff? And that quite often gets forgotten, especially in a migration to the cloud. Like these things don't make sense there.

And I always tell these things, like, tell customers these things are not the Bible, right? They're not always good for your particular organization. We often see disconnects.

A practical example, is CIS. CIS is a great industry standard. It's referenced all over the time, right? Now, have you ever tried applying the CIS-recommended hardening guide on a machine? And then put production software on it that still works. That I've never seen it not take several months and lots of blood sweat and Frustration taken out right? And for not always the best Return on effort is what I'm saying.

Another example AWS CIS says one of the rules is that you have to have a cloud watch alert that fires an SNS topic that sends out an email every time there's a security group change. Hold on that means whenever somebody releases anything or makes any change at all. You're firing off emails to me. We don't know like and then then then usually some manager and then or security guy like one of the things I ask him - How many unread emails do you have right now in your inbox Just tell me the number of digits. Is it three digits or four digits of unread emails that you have? Do you think getting more emails is going to be part of the solution or the problem?

Host: Yeah It's just more noise and more spam. Yeah, it's like when the volume goes up you start ignoring them.

Jan: And these are just opinions Right that quite often don't match what is going on in the real world in 24 Right in 24 you do not alert via email because that's just stupid right you have like a central sim you have an expensive Splunk you have a Slack message that goes in there that manages that. But you do not send email because that's not gonna fly and it's also not gonna fly whenever the minute changes happen, Right? And one of the other things that we were talking about was also the conflict between the requirements for compliance and security.

One of the examples is it's mandatory to have multi-factor authentication on the root account for an AWS account. It's mandatory to rotate the password. That sounds good but what I actually recommend to my customers is what they're using like API-based creation of AWS accounts so we're not creating the root account at all right? So if it doesn't exist it can't have a new So yeah, and then you find we have a finding here that we have to fix we have to rotate the account So we have to create the account. Are you helping?

Host: So you're creating more problems for yourself.

Jan: Yeah, that's what I'm saying is like you should not do this and unthinkingly and that's a lot of people do that Like they try to like we have to be compliant. The auditor is going to come in two months We have to get through this come hell or high water and that does not always go through again, there's the high-level three eyes that make sense.

Like you can tell a customer, you can tell them the auditor, this is a compensating control for that, right? It depends on where you want to put your prioritization on that.

Host: And I have seen often that the auditors are not looking for a direct match with the controls, right? They are trying to see if you have enough security controls in place, to match with what, let's say, CIS or PCI has defined as a requirement. And as long as you sort of can cater to it with some related security controls or something like that, as you were highlighting, then that should be good enough.

Another thing that you highlighted, which I really liked, is why? Like asking that question, right? Often on a day-to-day basis, we are like, yeah, whatever was told me that I need to implement MFA for the root account, If it doesn't exist, let me create and then enable route account, MFA.

Instead, if you ask why and try to get to the bottom of it, maybe you don't have to create that route account and you increase work for yourself, right?

So your role has evolved throughout your career from director of security, now general AI lead. How do you approach this? Do you approach it in the same way? or do you approach it differently, like balancing between compliance requirements and the continuous security implementation?

Jan: So, Gen .ai is very sexy and very hip now. You can't say anything without it. You can't even buy a toothbrush without Gen .ai in it these days. And there's a lot of people jumping in on that. I'm a very down-to-earth guy. There are a lot of people talking about securing like the GenAi stuff.

In my book again do practice the standard kick first and do the securing of your data Properly as you've done before right? 99 % of the stuff in securing like the gene instance is the same as doing a regular application or an SAP or whatever, you make sure that your data is encrypted. You make sure that you have access control. You make sure that you have your networking set correctly, that you use minimal privilege, and stuff like that.

If you do those basic things right, then you're already 99 % of the time there. In terms of like GenAi specific, GenAi specific securing rights, there's there's a couple of different things that that customers need to have in mind.

I'm personally one of those people who pragmatically don't trust the model right don't trust the model with critical stuff if don't give it stuff and then expect it to keep it secret Right? Some people try to make sure to apply rules inside the model never to talk about something like that or never drive that gets very tricky, pretty quickly.

I like to make it Look at it as a black box where it doesn't have the input. It can't have the output You still have to do your regular access control and you manage the personas that have access to it, identification, authorization towards this thing, you still have to do the logging, etc. But those are the basic stuff, right?

You can get into very like optimizing the performance of that and applying various layers on which rag somebody has access. But, I would use that. I would rather have the course security right now on that.

And then it still gives you a whole bunch of functionality that you don't have right now.

Host: Since we speaking about Gen .ai and you work with a lot of customers who are incorporating security into their cloud infrastructure,

What patterns have you seen? How are organizations leveraging when it comes to compliance or when it comes to security or even incident detection and response?

Jan: So a couple different things that we that I talked to with my customer in different levels of maturity, right? We have the crawl walk, run and I'm calling. I'm not just doing Gen AI because that's hip these days. I'm doing regular AI because Gen AI is a subcategory of AI, which is a subcategory of machine learning that we've done for the past. And it's all one big blob.

So I would say start off with managed services that have the AI or the ML inside there, something like GuardDV, for example, which can detect non-normal behavior off-off-cut. Right, right. There's there's that we have that will Do fraud detection and things like that that all run in the background. It's a very easy system that you can deploy and then as you go up the stack You can do things like hey all of our security findings Let's stick them in a security lake and let's use some visualization tools and then let's use queue so that we can ask questions to the data like what okay stuff like that.

That has been very practical We've been doing things like the queue for business where basically part is you can you can dump a whole bunch of files in a bucket or in a database or whatever. Give it access to and then ask questions for it which gives you a lot of benefits on that.

Another cool thing that I've been working on that has not been officially released yet is the automatic remediation of findings. So where it looks at like how you have these findings in there creates a summary of that, but also like generates code to remediate.. And that's sort of a fun thing that I happen.

Again, I'm always that my job is to be paranoid. So I'm, I keep, keep my, my LLM on a short leash, right? It's like, you can use it. I use it a lot for code development and code generation, which I also included in there, but I see it sort of as sort of like a weird intern. That's, that's pretty fast. Knows a lot, but does that sometimes. Right? So you don't a hundred percent trust them, trust, but verify these things.

We build systems, for example, you have this finding. We know what the detection is. We know what the finding is like. Your bucket is not encrypted. Let's generate some test cases, positive and negative test cases. That is say, create me IEC code that generates a compliant bucket and another one that creates a non-compliant bucket. We can test that automatically because on the first it should pass and on the other it should fail. Right, the same test. So programmatically test that with known code, right?

Now I asked you to generate a remediation code, right? And then again, run that against the positive and the negative one, see what happens and it either fixes it or it doesn't fix it, that's where you can automate the validation of your code to like 95 % already. So sort of cool stuff that you can do there that's very helpful in my opinion.

Host: I like how you structured it, right? For organizations who want to, let's say, get into GenAI for security and all, start with managed offerings. Don't just start building a new model and all, rather start with something off the shelf and then maybe use a RAG approach to feed more context. And if that doesn't serve your purpose once you validate that. Maybe at that moment, you can.

Jan: You can build your models. We have tooling to do that. That's a little bit more propeller hat to keep it going well. But then you have your models that can be very high, highly focused on that particular thing. And then you can build that exactly as how you want it.

But yeah, I'm a big fan of always using the simplest solution to a particular problem. And if somebody else already has done it, then it's easier to just buy it or use it.

Host: And that makes sense, right? Often, most of the technology is simple, but we make it complicated in our heads, right? Or we try to go for the most complicated solution. So yeah, keeping it simple makes the most sense.

So, one of the things that I want to learn from you is you work with many customers and you must have been part of many war rooms or war stories that you might have heard about incident response in the cloud. So before we talk about some of these stories,

Can you tell our audience what incident response means to you?

Jan: So incident response, cloud or not, just means having to deal with bad stuff happening in your environment. And it's usually cut up in a different in a couple of different pieces. You have the preparation for it. You have to be ready for it. And I'll talk about that later. You have to identify what's going on. So you have to have something that fires off the logging etc. You have to you have to rein it in. You have to limit what that particular thing can do that can talk about how that's different in the cloud versus on-prem, and then you have to remediate and fix it. And then afterward your lessons learned from it. So you have to see like, what happened and why did it happen and how can we fix it so that it doesn't happen in the future?

So the interesting part of how that's different, is how that can be different in the cloud is, you, where, where, where are you normally in an on-prem data center? if you have to isolate something, have to go right over literally run in, and pull cables. you can do this all API driven and you can automate that. That's one of the biggest, benefits is like you can automate everything. So you have, you're not staying on higher footing, but on equal footing with the attacker who's also running a script. So you can run the script to fix things.

That's why I'm saying that the preparation is always the biggest part of it. Having limitations on your limiting the blast zone. You can do micro-segmentation in the cloud, which is way harder if you have regular hardware firewalls that you have to deal with. But you can say, this thing can only talk to where it comes, it can only get incoming connections from that load balancer and it can only make outgoing connections to that particular database. And the load balancer can only be accessed via the connection that comes from the WAF.

So those things you can pre-build pretty easily. And then the cool part about this, one of my favorite things is the idea of, and with my excuses to the vegans, the cattle versus pets. Right in the old days. They have one web server that lives forever that you rub the right way and that you make sure that doesn't thing happen in a is like if something ever goes wrong, you shoot it in the head and you drop it and you replace it. All right. That's also literally what would like them the load balancer and the auto-scaling group works. Right?

So all of these things, by the way, I feel like if you're doing the job right in designing things properly, security comes sort of as the part of the best practices not just these separate things because that's so that's so weird geek needs no just Having having a secure and stable infrastructure is something that everybody wants, right? So being able to auto-scale is cool being able to auto-scale and have immutable Instances right where we're even patching them and like having a scanner running on them or stuff like that No, you you make your image once and you make sure it never can change right? That makes it makes it as hard as possible for these things to get there right harden it up, so that replacing it or like it's just a question of like hey kill the instance and done or maybe we want a snapshot at first right and moved automatically move that image to somewhere in our lab where it's secure and where we can do forensics on it And then I don't know depending on what we want to do. We got to find out who it was in sudo,

Host: Yeah, so you highlighted network segmentation and that's a very powerful technique that organizations can leverage to minimize the blast radius. So we recorded an episode with Tom Adamski from AWS itself and we spoke at length about network segmentation. So I'll suggest our audience also take a look at that episode.

So that they get an idea, right? And they can connect between what Jan is saying and what Tom is saying and how they can be connected from an incident response perspective. Yeah, so to jump on that, right?

Jan: One of the things that I found that worked well is working with the application team, right? Instead of just security. And they're always, well, the second rotation is part of the firewall. And the firewall is just the security guys, right?

You guys don't really know what we're doing for me It works best if you make that part of the application delivery, right? If you deliver an app it should come with an artifact that defines what this app does it should run on Linux with this amount of RAM and it should connect to these databases and it should listen on this port and these processes should run.

That is important information to know and that's what the application guy should be able to tell you. If they don't, then they're effing up already there in the definition of data. It's also important for any operational management to say, hey, how can I see if this box is healthy or not? So we need to know it in the past. We can also say, hey, this box needs to access these URLs. If you make that part, of the manifest of the application, then you can automate all those things without people needing to fudge firewalls or doing these things.

And then you have a very narrow segmentation that will work. And you can even put that same automation in the QA environment so that when the application developer's artifact is not 100 % correct, it automatically fails there before it fails in production.

And now you know like, hey, if this application all of a sudden goes to www.microsoft.com, which normally is no big deal if you see it on your network, but that's not on the approved list. So now that is a big priority. One thing like why this application made that request and you can automatically kick off your incident response process on there. Like either the application it did something wrong or the definition is wrong or we just got hacked.

You immediately know that something is wrong. And then you could say like, hey, my remediation, you can automate that. And you can say, let's roll back to the previous version. That is all with a zero downtime solution if that's what you're trying to do.

Host: Yeah. One of the key things that I got from your response is speaking with the application developers, ultimately all of us are trying to deploy something to the cloud. So like when I say all of us, like it's the developers who are building the application that will be deployed in the production system. So speaking with them, you get that clarity that what exactly are the resources needed? How do they communicate with each other? How are those communications secure? So the sooner you catch them, the better it is rather than doing it in a production system, live production system.

Jan: And you speak their You speak their language. Like things like what kind of data is on there is that from there, you can then tell like this is highly secure data or whatever. And then like, now we can use that to define our PCI scope or whatever it is or for our HIPAA compliance. That one does PHI stuff like that.

Host: Right. Right. So we spoke about two things, right? Incident response. And we also spoke about touched on Gen. AI. So now if I want to marry them together with Gen. AI,

What type of new attacks you are noticing that need an incident response plan?

Jan: there's always you hear about that, like, chat, GPT jailbreak, or whatever, you can get it to say dirty words or data that it shouldn't, right? That's where we're and we see that a lot. I personally don't I Try to attack that on an earlier thing right on an earlier level.

I've done the data, right so that the worst thing that could happen is it says it says a dirty word Where something to somebody was asking for it, right and stuff like that or it gives you wrong information, right?

So I see it as like an output validation, right? There are various techniques that you could do depending on what your use cases if it's like an internal where you'd say like before like we want to do something that searches best practices and then that searches all our wikis and stuff like that if somebody gets to search something then we assume that they already have access to it.

I actually know a big company that did exactly that where they put all the wikis and stuff like that in the database in an inner rag. And then people, and it works well, right? So somebody asked like, what are the secret projects that are not listed? Right. And like, here's an alphabetical list of all the secret projects.

That was that was technically internal product, but they didn't think about that. That particular dimension of access that they did there. So,

Hosy: Right. So so that is one side of the coin. If I flip to the other side,

How can tools like Gen .AI be used to sort of defend from some of these attacks or remediate even?

Jan: Yeah, so what I did before, what I talked about before is like helping the people understand for protection, helping the people understand what the requirements are, how things work, right? So you can do, you want to do like summaries of the project, like how do I being able from a development point of view, right? If we shift it all the way left, right? How do I securely create a new bucket in company XYZ that I'm working at, right?

Being able to just ask you and type it in and say, here's an example code that you do, right? So that already is a win, right? Or having it integrated in your IDE is already a big win for that, right?

So there's that level, very much left. And there's the help in analyzing big amounts of data that you found, like looking for patterns and stuff. That's where both classical ML, like pattern analysis, and GenAI can work together. You find the low -level patterns versus finding the high -level patterns and being able to consolidate it and try to figure out what things do what this is trying to do is build the graph of what's going on. So these tools are there.

Then there's the custom queries that you can build on inside your data lake. And then stuff like what I was trying to do is like having an automation kickoff. Like, hey, propose me some code to fix this particular thing, right? I still wouldn't trust it to do it immediately. But I would use it to help the, help the incidents responder as sort of like an assistant, right? Like, or like they came in. it says that they came into that port. Okay. Automatically. by the way, here's a knackle rule. Here's an AWS CLI command that adds a knackle rule that blocks that particular port right now. I just generated that for you. yeah, that looks good. Let's, let's copy paste that right. Or let's not do Right? the decision like a sort of like the assistant towards the incident responder, right? Or like here's here, right? Or basically what I've done is also I've brute forced it a little bit in like, these are the expected problems that we have and things that we've had in the past, right? And these are probable findings that we could have generate me example resolutions for all of these in a loop and reviewed those beforehand.

It's like that I found very practical in doing the thinking before the screaming starts.

Host: I like how you said, use it as an assistant which is helping you, giving you pointers rather than using it as a solution. Like when you get pointers, validate it and then maybe use it. In the example that you gave, there is an ACL rule which can be implemented to block traffic. So validate it and apply it so that way you are sort of using that for your incident response programs in a much better or faster way.

Jan: Yeah. And that's also the important part about incident response. You have to test it. You have to train it, right? The philosopher Mike Tyson says, everybody has a plan until they get punched in the face. So you have to do all these plannings beforehand and know what's going on, maybe run some simulation. let's imagine that we got pawned, right? What are we going to do? What would we do?

There's also some of the workshops that I run is like, go to a simulation. And every single time we would find customer would find new things that they didn't think about right? let's say that the website that the DNS was out or that the website was was hacked like, okay What would you do? maybe the the next action is let's put up a standard web page that says that we're down Okay, but can we present that? we technically we need marketing approval for that does anybody know how to conduct that marketing? No, maybe if you should put that in the plan or these two. Does anybody know whether this has legal implications or not? Maybe we should review that with legal first before like yeah, let's do that Let's write that on the stuff.

So just doing these even a tabletop exercise, right? Can get you a lot of stuff and then yep There's always the the the hands -on stuff. I love doing the AWS jams, I don't know. You've known it. It's sort of for people who don't know, it's sort of like Defcon captured the flag without the horrible music. Where you try to, where you have a real life environment and you have to go fix something like, hey, this bucket is open or this bathroom is miss. We're going to go and fix it. And every single time people do that, they, they learn something.

And what I also see, what I love is the meta-learning because I tell them to go in groups of like four people and then there's a strategize. Do I do four incident responders or do I do like? Like an Ops guy and network guy and application guy and stuff like that and sort of like building that that team building on there is also very exciting as a side benefit that I noticed with that farm pretty interesting.

Host: Yeah, it not only teaches you to respond to incidents but also teamwork right? How do you work together? Who is responsible for what?

Jan: And then how do we do it making stupid stuff? Like how do we communicate securely when when there might be an attacker in our systems, right?

I've seen that I've seen places where the Attacker had a Zero day in Active Directory and Active Directory was the SSO for all the other stuff like How do you know who you're talking to? Stupid stuff like what's our backup plan on these things, right?

Host: Right, right. Yeah, having without having an incident response plan would be like a chaos, right? You are trying to figure out things while there is an incident happening. So yeah, that's never recommended. Having something documented in place and yeah, tabletop exercises is something that you highlighted. It is key also because having something documented versus having done something like simulating it a few times is very different, right? You have some muscle memory, so you know that based on which incident you go to which team and what next steps you need to take as well. So yeah, that's a very important points that you highlighted.

So that sort of brings us to the end of the security question section.

Rating Security Practices

The way it works is I will highlight a security practice and you need to rate from one to five, one being the worst and five being the best. And you can add context why you gave a particular rating. So let's start with the first one.

Conduct periodic security audits to identify vulnerabilities, threats and weaknesses in your systems and applications.

Jan: So I would give that a solid four. It's definitely something you need to do. You can improve on that by again shifting it left, doing your scanning and your vulnerability assessment before it goes to production instead of afterwards. But it's definitely a strong requirement there.

Host: Makes sense. The second one is use strong passwords which contains uppercase, lowercase letters, numbers, and symbols, and also change it frequently.

Jan: I would give that a… Amiga three. Because okay. there's better stuff that you can do right people are horrible at this stuff so I Found that the best approach is to use SSO but also to use things that cannot be fished, right? Currently, state-of-the-art is like you have a have like a hardware key, right? Like a light phyto works perfectly with that. It's something like this. It worked like a Yubi key. Yeah, it costs like like like 20 bucks and it's amazing the number of Things that that that can prevent it right because people will be fished right people will click on email links, right? So it's like our job is don't I hate it when when they say like hey, we should give training to people. We should tell them not to click suspicious links.

What the heck is a suspicious link? And If you could tell me in a deterministic way what suspicious was, why the heck are you not blocking that email beforehand? So you can't ask, you can blame a user for doing the things you can't do.

Same thing with passwords. I've had in the same problem with where we had the issue with the SSO being untrusty. We had to come up with a solution where people went into the office and the security guards handed out Yubi keys after validating their... Have everybody come in and show their ID and show their badge and then have the security guard issue a thing and so that got stuck into there as a workaround to get like, because how else are you gonna do that, right? If can, if Andy got pawned, like, Andy got pawned. That means that they had admin on the laptops as well. Yeah, now what we do.

So these things are better. The strong passwords and the rotation. I find, so that's why I give that a three. I instead of rotating it, I would do the new validation of actually checking it against, against pawnedList, right? If the path had already been used, then…

Host: Don't use it. Use a new one. Makes sense. The last one is, development regularly test an incident response plan to help quickly detect, respond to, and recover from security incidents. Feels like we just spoke about it. We spoke about Yeah, how would you?

Jan: That would be a solid five. I agree with that.

Host: So yeah, so before we end the episode, I have one last question for you. Do you have any recommendation for our guests? sorry, for our audience? It can be a blog or a book or a podcast or anything.

Jan: I thought about that, and I want to recommend a book that blew my mind several years ago. That's called Daemon by Daniel Suarez, who's actually like a developer and also in security. I love the fact it's a sci-fi book, but of 10 years ago. Instead of phasers and Star Trek stuff in there, it has things like AI, and global currency - that is virtual. Self-organizing groups of people, wireless networking, driverless cars. wow. 3D. So many. Like that's the sci-fi stuff in there, right? So it's not like it doesn't exist yet. It's just the applications of that stuff.

So I found that very interesting. It also has some societal implementation. So I'll drop you a link for those who are interested in that.

Host: Thank you. And what we'll do is when we publish this episode, we'll also tag the book so that our audience can go there. All right. So yeah, thank you so much, for coming and sharing your knowledge with us. It was lovely to speak with you.

Jan: Yeah, thank you so much. Thanks for having me.

Host: Absolutely. And thank you, everyone, for watching. See you in the next episode. Thank you!