Understanding the role of logging and monitoring in detective controls with Kailash Havildar

TLDR

• Standardization of logs is very important when designing a Centralized Logging and Monitoring solution. Both from a security and also from an engineering perspective.
• When it comes to Logging, start with User Logs, System Logs, Config Logs, Network Logs, in that order to analyze for Detecting Security issues.
• For Prevention Controls, start with Regions, Services, Access and Configuration controls. This helps organizations approach security in a structured manner.

Host: Hi, everyone. This is Purushottam and thanks for tuning into ScaletoZero podcast. Today's episode is with Kailash Havildar. Kailash is a senior security consultant at AWS who works with customers to deploy and secure their cloud infrastructures. He has presented at reInvent and he has been developing detection controls within AWS, as well as working on native solutions and third party applications to improve customer security posture.

He started out as a consultant with Securonix, where he has learned about threat hunting, detective control implementations, and insider threat program development. He later became an in -house security engineer with a government software provider called Fast Enterprises. Kailash, welcome to the podcast.

Kailash: Thank you.

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

Kailash: Yeah, sure.

Hello everyone again, my name is Kailash Havildar. I am currently a senior security consultant with Amazon Web Services and I've been in Amazon for almost three years now. Started off my security journey, I think even back when I was in high school, when I used to watch all the movies on security, right? Like all the hacker and the cool geeky stuff looks really nice and you get attracted to it and like, okay, this is actually fun.

After the movies, I started getting into books on security. One of the books that really influenced me is the Codebook by Simon Singh. And the book is on cryptography. He also covers about the Enigma cipher, which was encrypted by the British government. And you talk about the movie with Benedict Cumberbatch, I forget the name.

But it's super cool. I recommend that book already. So that's how I got interested into security. And then I came to my masters. I had a very influential information security teacher as well. And then as meant to be, my first job was this company called Securonix, which at that time was a UEBA company. UEBA is User Entity Behavior Analytics Company, right?

So now they're more of a solution. But I started off with them, worked there for three years, moved to another company called Fast Enterprises. Purusottam already mentioned my work history. I'm going again. But in Fast Enterprises, I was their Splunk Admin. I did Splunk. I did Tenable, Vulnerability Management.

I actually got experience hands -on into most different variations of security there. I also used to be their Office 365 guy. I did like phishing tests, user education, and all that fun stuff.

Once all that happened, I got a job within Amazon and I've been here three years, like you mentioned, and every day is now a fun day and that's been my journey into security.

Host: So I have a similar reason. why I started into engineering, but yeah, we'll talk about that sometime. Some other time.

The movie's name is The Imitation Game. Imitation Game. Yeah, that's a lovely movie. It sort of excites you that what is going to happen and it brings the curiosity out of you.

Kailash: Yeah, actually the code book covers some of the... sorry, go ahead.

Host: No, go ahead.

Kailash: The code book actually covers some of that in detail, right? Like the technical aspects of it, how they built the bomb. It's called like B -O -B -E bomb, the cipher Enigma machine. So it's very interesting.

Host: Okay. yeah,, I would love to read that book because I haven't, I have watched the movie of course, but I have not read any book, which is the, or goes into deep, goes into the depth of it. So yeah, I'll try to read it.

One of the things that we ask all of our guests and we sometimes get unique answers is, what does a day in your life look like? So yeah, how does it look like for you?

Kailash: So like I said, I am a, security consultant with AWS. Every day is different for us. It really depends on the customer, right? And that's actually the fun part of my job is because I really don't have repetitive work. I work on different projects every single month. It's always interesting. It's always fascinating. One day we are working with customers, building them code on CloudFormation on Terraform making sure that all the code that we build has some security checks involved, right? Like for example, we write a S3 bucket in Terraform, we make sure that it's encrypted, it's not public facing, and we build CI/CD pipelines for the code that we write, make sure that it has a security scanner tool like Checo, for example, right? Or a TeraTest, make sure it's limited, that it actually passes through all your security scans, and only when all that is good to go, we release that to the customers.

So that's some of the customers. And then we also have like an educational aspect where we actually go and say, okay, this is the cloud. I know you are making a migration from on -prem to cloud, but VM now translates to EC2 instances, right? So we have that educational story as well. Some customers we deal with that.

There's also a few customers who are very mature and they have been on the cloud already. And for those customers, it's a matter of scale, right? The same security controls that you apply on a greenfield customer will not necessarily scale if the customer already has a very big infrastructure in the cloud, right? So for them, it's talking in scale, how do we make sure we have coverage with all that infrastructure within the cloud, within terms of security. So yeah. There's no one.

Host: So it's yeah, it's I I feel like you have you are working with different challenges on a daily basis, right? And you work with different like different customers with different at different stages, correct? Not just startups Greenfield or it's an enterprise at different security maturity level as well. So yeah, I can see how that must be fun. So yeah, yeah and

Today we will talk about one of those topics, right? Like detective controls and what role does logging and monitoring play in it?

So let's get started with the security questions, right?

So when it comes to security, there are three aspects always. Prevention, detection, and remediation. So if we want to talk about prevention,

What tools or tricks that you would recommend, particularly in cloud environments?

Kailash: Sure, sure. Great question. Being in the cloud security, right? Like I think these things are what we talk about or discuss a whole lot of time. Preventive, like the name says, these are controls which are designed before events can happen, right? An example, in just the IT world, not just the cloud, it's just a firewall, right? Where you actually block all your malicious traffic. But in the cloud, we have controls where we can say, okay, make sure that so -and -so action or API call does not happen by this person or this role. So that's a preventive control.

Make sure any of your S3 buckets that you have are not public facing or any databases that you spin up on the cloud are encrypted. So all these are preventive controls that happens even before events can happen, even before you spin up, you have a control which says, okay, it cannot happen without satisfying this condition.

And preventive controls, you said you asked for tricks in the cloud world. I think when we implement all these preventive controls, we go with the number one step is your region controls, right? You have so many regions, which controls do you want to host your infrastructure on?

And then broadly, your second control could be services. All the cloud providers have so many different services. Which services do you want to allow or have your customers or users in the cloud perform operations on? Then you have the third control where you say, okay, within these services, which are allowed within the region, within the service, I want to have more preventive controls. The databases, for example, should have encryption or you cannot spin them up.

This, I think, is the top-down approach that has worked in some of my projects with Preventive controls. That's what I have learned for the Preventive controls.

Host: OK. I like how you have structured them, right? Region, then service, then you have configurations. Correct. Now, if we want to talk about detection, so we spoke about prevention.

If we want to talk about detection, how would you structure that?

Kailash: Sure.

Detection can get a little bit more tricky, right? Because every cloud has its own mechanism for how you can detect these events. But broadly speaking, cloud or on-premise, you have your logging and monitoring systems through which you would be writing your rules or signatures, right? And based on that, you will have detective control set up.

But… for detective controls as well, you need to make sure that there are certain conditions which we will dive more into depth. But you want a robust logging and monitoring system. And based on that, you can actually write the detective controls. You could write them on your own. Or there are a ton of third-party solutions which can help you with detective controls.

My tricks and tips for that is if you are using rule-based solutions, you can perhaps take a shot at that yourself. I think it's easier. But once you go beyond rule -based signature -based detective controls, like if you're talking about anomaly detection, behavioral detection, especially if you're a company which is now starting with writing the detective controls, third -party solutions make it really easy for you because we have tried doing the whole machine learning approaches towards anomaly detection and it can get pretty tough, especially if you are a security guy and not a data science guy or a girl.

Host: True, true. I agree. So now the last pillar is remediation, right? What tools or tricks you have for us in the remediation section?

Kailash: Remediation can be all the way from just an alert or a notification to your users, or it could be automated.

I like the automated approach. And even for that, there's of course third party solutions. Like when I was to work on Splunk, Phantom was the sole platform. And on the cloud world, you have SSM runbooks. You have the particular services that help you with serverless technologies, which can actually do some remediation work for you as well.

The least intrusive way of doing it, Remediation is tricky because say for example, you have a wide-open firewall and you write a remediation where you go and just delete that rule. It can get tricky, right? You don't want to make your application teams angry.

So there's a fine way of doing it. The way that has succeeded in my experience is to start off with something like a soft landing, start off with just notifications to your users and start taking manual controls. And once you have a baseline established, then go with automatic remediations.

Host: Yeah, yeah. Makes sense. And a similar example is like S3 buckets, right? Generally, it's the best practice that S3 buckets should not be public, but you cannot just flip all the S3 buckets to private because some could be hosting assets, right? So yeah, absolutely.

Kailash: That's a great example.

Host: You're spot on with the remediations.

Yeah. So today we want to dive deep into the detective controls, right? And you have built detective controls and you are working with customers also to build the detective controls. And you highlighted logging and monitoring when it came to detective control. So,

What is the role of logging and monitoring if I want to implement the detective controls effectively?

Kailash: Sure. Logging and monitoring are absolutely crucial. Not just for security, but even for your troubleshooting purposes, your compliance purposes and security, right?

So logging is basically just the act of collecting the data from your different services, resources, audits, audit logs, your user data, application data. Monitoring is basically the act of looking into this data, right?

Logging and monitoring together are like the CCTVs for your digital infrastructure. I think that's the most important part. And I have experience working with NIST 853 controls. Where I would start is that they have, I think, 18 control families and audit, and accountability was one of the control families that we refer to for best practices with logging. And that's where I would start with implementing your logging. I think key things is you need to centralize your logging.

Once you centralize your logging and monitoring, sorry, logging, then you're going to put access controls on top of it. You're going to encrypt that. But for all of these, like having a baseline, I would really refer to the NIST 853 controls.

Host: And this is very similar to application or this has similar benefits in application debugging as well, right? Like unless you have a central logging system, it's very difficult, especially in today's distributed services world, it's very difficult to debug if something goes wrong. Yeah, absolutely.

So security is sort of utilizing a similar philosophy where you aggregate and then start analyzing it for security use cases.

Kailash: Exactly.

Host: So a follow-up question to that would be

What type of data or events should organizations prioritize? Let's say you have your databases, you have your applications, and different types of applications, and different types of data sets as well. So while prioritizing the logging and monitoring for security, Is there an order that you follow?

Kailash: I would definitely start off with just user logs, right? That to me is most important. And then the second one I would go is with system changes. So any kind of configuration changes that's happening on your system.

But I think the question also depends on what you are. As a security person, I think this is what I want. I want my user logs, I want my system logs, I want my network logs.

But if you are an application person, you would concentrate more on your application logs because you care more about troubleshooting than security.

But from my perspective, as soon as we go to our customer, we enable logging services. And this can also be done at a centralized level. And the first logging that happens is CloudTrail logging across all of your AWS accounts, right? And that gives you a baseline of what's happening, like who's doing what within your system, at what time, what role is being used, who is this IAM user, what's the actions that's happening, right?

Like all of these is the first thing that I care as a security person. And after that my system changes, which can also be tracked through the audit logs, but configuration changes is what I care about as a second step.

And then of course, I also care about my BPC logs, my network logs, my application logs, my security events, and then obviously the database logs and all that.

Host: Yeah. So now you mentioned so many categories. Let's say you're working with a Greenfield project and the customer is a decent size, maybe not a Fortune 500, a decent size company.

What challenges do you generally see in those scenarios when it comes to implementing logging and monitoring?

And a similar question is like, or related question is, how would you fix those challenges?

Kailash: Sure. I think in my own experience, the most common challenge we had was centralization of the logs can be a relatively easy step. But if you're going to put that in the same solution, that's when you get hit with the license costs, right?

And that I think has been a very big challenge for especially like you said, Greenfield customer. And then I come from that perspective because Greenfield customers that just starting off with the cloud world and all of a sudden they have, yeah, we have audit logs now, network logs and application logs. And we have a centralized all of them into our SIM solution. our SIM solution is now… charging us so -and -so money to hold all this data, right? That can get very tricky.

And also some of the logs by themselves, what I have noticed is there are different fields, right? By default, you can, by default the log supplies 10 fields, but the information that you actually care about and want is probably in a field that is not logged by default.

So when you are setting up logging in, these environments, you want to make sure what fields are supplied by the application or by the service. You want to ensure those fields are within the logs. And another critical aspect also is that you want to look for the kind of logs you want to log, right? In the sense like logging level, do you want your debug logs? Do you want your information logs? Or do you only care about your critical logs, right?

I think these are all some of the challenges that I have sometimes dealt with in my past. But these are actually good challenges because, so for example, in my previous job, we used to generate a lot of logs related to Windows. And this is an example. And we discovered that a lot of the traffic being generated, sorry, not Windows, this was a network logs.

A lot of the traffic being generated once you start looking into it was actually from the firewalls. And the reason why it was having such a spike is because our vulnerability management system was scanning every single day and that was generating a ton of network logs, a ton of Windows logs.

And so back to that point of logging and management, logging and monitoring being your CCTVs for your digital infrastructure, comes back to that point. Like you really understand what's going on within your environments once you start looking into these logs. I think the other, there are so many challenges with logging and monitoring.

I think one last thing that I wanted to mention was, is also like alert fatigue, right? Because once you start generating these logs and processing them, you can end up in a situation where you could have set up a lot of alerts, and your team is just done looking at them. They're like, nope, I get this email every five minutes now. I don't care about this anymore. So alert fatigue is also a big problem that I noticed.

Host: Yeah. So I think two key ones if I want to highlight is that standardization you mentioned. If you have 20 applications running, are they following a standardized format so that it helps with the analysis? And of course, the verbosity of the logs plays a major role in the detection, right? The more verbose, the better you can analyze, but at the same time, it has an impact of the cost. Because if you add verbosity, that means you are ingesting ton of data into your logging system. So which will impact your cost.

On the alert fatigue, totally with you. Like the moment you get second or third, within a few minutes, you will start ignoring them. And if you have seen that pattern from a particular tool, whether it's AWS or some other vendor, you will start ignoring, right? And you will, again, like you will not trust that data anymore because you are not even looking at that. So yeah, you are spot on on that.

Kailash: I think standardization Sorry, you brought a really good point, standardization. And it reminded me of another challenge which is parsing the log data, right? So some of the log data obviously can be like comma delimited, which is simple. SimSolutions can just parse it just like that. But some of them can get really complicated, right? Like to me, writing regular expressions back then was the bane of my existence.

I have started to enjoy writing regular expressions now, but when you are learning that, it's just Greek and Latin, right? So that plays a role with standardization because when we are talking about feeding data into like a SIM solution and you want to cross-correlate logs, right?

From one, let's say that you have different firewalls and you want to look at the destination port, regular expressions play such an important role because you want to make sure that both these firewall logs have the same port number mapped to our destination port or a source port, right?

So that's a great point. I just wanted to call that out.

Host: OK, thank you. So you highlighted about SIM systems, right? Where you can collect the logs and you can analyze them as well.

Any advanced capabilities that you look for when you are, let's say, looking for a SIM system so that you can use those for your detection, either to create detective controls or for your detection capabilities?

Kailash: Sure.

I think when we spoke about logging earlier, we said one of the easy thing to do is, I wouldn't call that okay, easy thing, but relatively easy thing, right, is writing your signature -based or rule -based controls. Rule -based controls, you're looking at if X is equal to Y, then alert me on this, right?

But anomaly detection, I think is one of the key components that SIM can provide, anomaly detection. where in my previous experience, there used to be two kinds, right? One is like a frequency -based anomaly and volumetric based anomaly detection.

When we talk about frequency -based, it used to be, okay, Kyloch goes to, let's see, let's talk about volumetric before frequency hits my brain, but volumetric, I am regularly downloading five MB of data every single day, right? And all of a sudden I am now downloading 5 GB of data and no rule -based detection can actually trigger that, right?

So having that baseline and making that baseline and detecting that based on machine learning algorithms can definitely be super helpful.

One of the other aspects that I used to really enjoy is you can cross-correlate logs. You can actually take up your Windows logs and then you can take up your firewall logs and you can make connections with them. There was also instances where I have downloaded IP geolocations.

A classic example is I log in all the Windows logs who was doing login events and then In the Windows world, I still remember it's 4624, where if a login is succeeded, that's the event code that's recorded in your active directory. And the IP address, where 4624 happens, you can actually get the geolocation data, and you can match that and say, OK, our organization is based in the US, but I have logins coming in from a different country. At that point, you know that something's fishy. Something's not right. And if that person whose login you see is coming from a different country and if he's in the office around you, then something's definitely not right.

So you can make a lot of such cross-correlations, behavior detection, also threat intel logs. You can get dumps of malicious IP addresses regularly. Some of them are even free, which you can download to your solution and look at your network traffic and say, okay, there is some malicious IP addresses, which are actually communicating with our IT infrastructure now.

So those, I think, are me some of the more better use cases of using a SIM solution.

And it can get very advanced. There are also apps which can help you with that process as well. But yeah, I mean, in a very short answer, yes, that to me is advantages of using this.

Host: Makes sense. So a follow up question to that would be there is no way it's possible to figure out these rules or do these things manually, right? There has to be some automation so that you can do the analysis of the logs.

How can automation be used to improve the log analysis and incident response process?

Kailash: Sure. All the things that we spoke about earlier can also be automated, right? Like one of the things that we used to do was all your data models, all your behavior analysis models, all the mission learning algorithms usually run in the night. You set up a time for downloading your malicious IP list. And that happens on a regular basis. You download geo locations on a regular basis and you want to automate all these tasks so that you're not spending time on a regular basis and setting up all these different aspects open.

One other key feature is just setting up your alarms and alerts for some of your use cases, right? Another one, like when we talk about insider threat programs is we used to do interactive logon by a service account, which where you look for interactive logon is basically somebody typing on the keyboard, right? And why is somebody interactively logging on to a service account, right? So something like this, right? Like you have a whole lot of these rule-based detection controls which are written and they are automated to run at a particular time every single day and they can give you results, right?

Automation is definitely key with any of the SIM solutions because you want to make sure that you are not spending all your time just focusing on the results, but you write a rule, automate it, and then it keeps generating your results.

But also the SOAR platforms, like Splunk has phantom, they also definitely help you with automation orchestration processes there as well.

Host: So, so far we have been talking about using the logging and monitoring systems to do the security analysis and put in the detective controls. Now let's talk about how do we secure the logging and monitoring systems themselves.

So let's say you're working with a startup, setting up their logging and monitoring systems.

What steps should I take so that those systems are secure and tamper-proof?

Kailash: Sure. That's a good question. In my previous experience, they used to say, who's going to police the police? We are using this system as the police, but that's a great question. I think number one thing, most of these solutions provide access controls.

For example, within the same solutions itself, there is role -based access control. The application teams can only access their application logs. Security team can only look into like Windows logs, for example, and your infrastructure teams will be looking into the networking logs, right? So you can use the role -based access controls within the SIEM.

Of course, you can have the URL IP level restrictions within the organization firewall rules on who can even access the SIEM in the first place, right? You will obviously be encrypting the data, both transit and rest, all the data that's coming into your sim, where it's stored. So that can also happen.

All the logging systems by themselves will also have its own logging. So for example, SIM solution will also log its own data, right? Like who is accessing what within the SIM, who's doing what queries. And you want to make sure that you're looking at those audit logs. The main thing to see is if somebody is trying to delete that data, right? Windows actually has an event code, I believe it's 1102, which is for the deletion of the log data. And also one of the main rules you want to set up because if somebody is actually getting into your environment, if they're trying to cover the traces, they're probably going to delete your logs.

So I think these are some of the techniques to use, which can be used to make sure that your logging data by itself is secure.

Host: So I like how you structured it. So a follow up question to that would be there is a balance between how much I want to log and the cost of it. As security experts, we might want to log everything, but at the same time it costs business something. So if you are advising a startup or a late stage startup about log retention,

What factors do you take into account and what best practices do you recommend?

And also for securing that storage of the logs.

Kailash: I think that is mostly answered by your compliance framework. Like if you are having to be compliant with PCI, for example, then PCI mandates you need to have at least one year worth of data. I have worked in some projects where the customers were IRS Pub 75 compliant, which meant they had to store the logs for seven years.

Now, it wouldn't be that wise if you store all your data in like a fast storage retrieval mechanism. So even in retention, you want to have lifecycle policies, right? Like for example, you want to keep your three months worth of data for immediate retrieval and analysis, but data after that can be in a glazier storage. Like if you're talking S3 buckets, you could have three months worth of data in your fast standard storage or at least your accessible storage.

And then if it's more than that, you can just put that into like a default glazier solutions. But only if you need the data, you can thaw that data, get it back into faster storage and start analyzing on it. It could be your retrieval policy.

But again, if you're not thinking about compliance, I have also seen companies which do it purely based on your storage costs and your SIM license utilization costs. So it's a combination of a compliance framework and your organizational policies.

Host: Because yeah, ultimately, it not only affects cost, but also it affects how quickly you can get to some of this data for your analysis as well. So having that balance between both of them. So I like the framework that you put in.

Now, what I'm curious about is the logging and monitoring requirements, or do you see them as very similar between all the industries, like health care versus FinTech, or an e -commerce application, or a consumer -facing social application?

Are there any industry standards that can be followed or it's more like whatever way I like, I'll just implement it on my own?

Kailash: There are definitely baselines, right? I think I spoke about NIST 853 in the past, which has like, I believe, 18 compliance or control families. Audit and Accountability, which is the AU family, actually tells you what exact standards you have to follow.

Every compliance framework tells you, that these are the kind of logs you would want to log within your system, and these are the fields that you want within your system. This is where you're going to store them. This will be your lifecycle policies. All the controls related to that, you can find within these frameworks.

if you are thinking more about standards on your detective controls that can get complicated in the sense there are detective controls which are more applicable to your organization, but there are some which can be across all the industries, like you said, right?

Like finance and healthcare. For those, the ones that I have worked on in the past is the MITRE framework. If you have not heard about the MITRE framework, think about that as like a knowledge base, right? For all your different signatures used by threat actors. It's a collection of TTPs, which is threats, technique, and I forget the P. Yeah. Patterns, I believe, or practices. Yeah, I will tell you when I recall the definition of TTP there.

But yeah, so it's basically that list of TTPs, which will give you, okay, there is a group, a threat factor group based out of China, and this is their typical way of getting into your system. And it follows the whole kill chain, right? Like the Lockheed Martin kill chain, where they actually start port scanning you, for example. And after the port scanning, they try to establish reconnaissance, port scanning, you know, like weaponization and the rest of the chain processes.

So Mitre can really help you with at least having a standard applied to your detective controls. There are also apps which I have noticed, like some of the SimSolution have their own apps where some of these also come as pre-canned queries. So you could as well use that as part of your standardization across the industries for detective controls there.

Host: And the P stands for procedures in the TPM. Yeah, even I was trying to think, I thought patterns or practices, but yeah, it's procedures.

So we have been talking about implementing the logging and monitoring systems, right? And the security, how can we use for security, how it can be secured. But now it has cost and you have to show the return on investment, right? When you do the system setup and use it on a day-to-day basis.

What key metrics do you show to the leadership if you need to sort of justify building a logging and monitoring system?

Kailash: Sure. I think the number one thing that has worked in the past is the value that you provide them through actual detection of these security events. I think one of the things that had really worked in the past was I had written some rules which directly had executive-level visibility. And in order to do that, you really have to work on the ratio. So you have to reduce your false positives ratio and increase your true positive ratio.

I think that's a very good metric to start with because if you have written or fine tuned your alerts to such an extent that at least 90 % or 95 % of them are true positives and people are actually looking into your emails and seeing, okay, this is actually a legitimate issue. We need to take action. I think that's a good written on investment, especially if you are investing in like expensive systems than the coverage of what you're logging is across your organization, right? Like how much you are coding, are you getting all your applications in, are you getting all your networking logs in?

How much have you worked in terms of reducing unwanted logs, right? Like how much logs are you getting? How much of that is actually useful? Are you just dumping yourself with your vulnerability management logs because that's really not that useful at certain times, right?

Also your accuracy of threat detection, your incident response speed, right? Like you get an alert, you know that you have an issue. How quick can you resolve that issue? I think these are all some ROI targets that you can achieve with your logging and monitoring systems.

Host: Yeah, I see parallel like this, very parallel to like maintaining a healthy lifestyle, right? You cannot show the ROI that easily, but when it comes to any challenges with your health, you can quickly recover. Those things you cannot present, but they are there to help you out in every way. So yeah, totally it makes sense.

Yeah. And that's a great way to end our security section.

So let's go to the next section, which is rating security practices.

Rating Security Practices

So the way the section works is I'll share one security practice, and you need to rate from one to five, and five being the best. And you can also add a context, like why you gave a particular rating. OK. So let's start with the first one. The first one is conduct periodic security audits to identify vulnerabilities, threats, and weaknesses in your systems and applications.

Kailash: I would give that as a file depending on the frequency of the periodic scan, right? Like if we are talking third-party penetration testing, for example, that can get pretty expensive, right? So we don't want to do that on a regular basis. But one of the things that you want to do is continuous monitoring, which means that you are looking at your dashboards, you are looking at your alerts, you are maintaining how much progress you have made with your alerting system, for example, right? Like, I think it is super important that you have visibility into what's going on in your environment and how that's trending. And for that, I think I would rate that as a five. Host: Okay. The next one is provide training and awareness programs to employees to help them identify and respond to potential security threats.

Kailash: I would also rate this as a five, because, you know, what they say in security, right? Like humans are the weakest chain in the link, link in the chain. But I don't really like that. But I think to a certain degree, yeah. Yeah, I don't want to take a more, I want to take a more political answer and say, I don't really like that statement there. But it is user education and cybersecurity, I think is very important.

One of the things I mentioned that I did in the past was phishing email tests, right? Even now, one of the major threat vectors for any breach is the human aspect of it, meaning phishing emails, leaked credentials, your users are choosing really easy passwords, they're repeating their passwords, right? And if we educate the users, I think at least the first step of getting a data breach reduces greatly. So I would rate that as a five.

Host: Yeah. Yeah. And I agree with you. Like often folks talk about humans as the weakest link. And even though we don't like it, that's often true, right? Most of the attacks that we see are like human mistakes, whether in like, I'm not saying it is intentional, but mistakes made by humans, right? So yeah, understood.

The last one is, development regularly test an incident response plan so that you can quickly detect, respond, and recover from security incidents.

Kailash: Yeah, I think I would give this as a four. I think it's still extremely important to do this. Some of the compliance frameworks even call out that you have to do tabletop exercises on a periodic basis. One of the accounts that I used to follow on Twitter, was just about tabletop exercises, right? A lot of them had having to do with interns, but yeah, Twitter can be a very helpful and useful resource for you, by the way, on incident response scenarios and tabletop exercises.

But yeah, I would give that as a four. You want to make sure that there are playbooks, there are workflows, there's automation built in for at least some of the easy targets with incident response remediations. But even if it's something bigger, you want to have, okay, so if there's actually a data breach, there needs to be a plan. Who's going to take watch shift? Who is going to be working 12 hours on a particular day? We need to have that plan built up so that if there is such a situation, you have a playbook for it at least.

Host: Yeah. Otherwise you'll be scrambling at the last minute, right? While you are being, let's say, attacked, you're still trying to figure out whom to call so that they will come and do the analysis and stuff like that. Yeah. Having that playbook would definitely help. So before we end the episode, there's one last question that I would like to ask is, do you have any recommendation for our audience? It can be a blog or a book or a podcast or anything.

Kailash: Okay. I think so far I have talked about two things, one, Twitter being a major source of what I follow for some of my security. Well, Twitter used to be, now I think some of the accounts I follow are no longer that active.

But podcast, I listen to Darknet diaries, I really enjoy that. I think the way the podcast is done is very story-type, right? So you're not just looking at the technicals, but… the background and how actually the board was the effects of security reach or implication, right? So it's very good. Even when I'm in the gym working out, I sometimes listen to Darknet diaries because it's very playful and it's a good, yeah. So yeah, definitely Darknet Diaries is the code book which I mentioned in the past. I think that's a good book to read for security professionals. I mean, there's so many books and Twitter also just to keep up with what's happening within the security world.

Host: Okay. Yeah. Thank you for sharing that. So yeah, that brings us to the end of the episode. Thank you so much, Kailash, for joining and sharing your knowledge and learnings with our audience.

Kailash: Thank you. It was my honor to be on this podcast and yeah, hope to remain in touch and thank you. Appreciate it again.

Host: Absolutely. Thank you for coming. And to our audience, thank you so much for watching. See you in the next episode.