Blue Team And Digital Forensics with Karan Dwivedi

TLDR;

• Understanding the threat model in depth is very important for Blue Team to be successful.
• Red Team should be considered as partners rather than adversaries in building and improving the threat defense program.
• Accuracy of digital forensic data is key for analyzing and improving security difference programs. It should not be compromised in order to move fast.

Transcript

Host: Hi everyone. Thanks for tuning into another episode of Scale to Zero. I’m Purusottam, Co-founder and CTO of Cloudanix. Today’s episode is focused on threat detection and blue teaming to discuss on this topic, we have Karan Dwivedi with us.

Karan is a Security Engineering manager at Google with expertise in defensive engineering, which is also known as Blue Team, and it covers areas like threat detection, incident response, and digital forensic, to name a few. He has successfully led projects with very large scale tech companies in Silicon Valley to improve security for over a billion users. His interviewing articles@alltheaspawn.com are provided as interview preparation material by Google hiring team. He serves as a program committee member of the DFRWS Conference besides SF Conference, and he’s part of the editorial board member of several international journals in digital forensics as well. Karan, it’s wonderful to have you in the show for our viewers who may not be familiar with your work. Do you want to share about your journey a little bit?

Karan: Yeah, thanks for having me here. It’s a pleasure to talk to you. I think I’ve been in Silicon Valley for the last, I want to say seven or eight years. I started my career at Yahoo. And right when I joined, I mean, they had the world’s largest breach, so I was right in the center of that whole situation, I would say. But it was a great learning experience because how often do you get to see that happen live, right? So I was part of the Blue team there doing instant response for Nsax. I spent two years there and then I moved to Google Security. So Google has detection response, which is their larger organization. So I’ve been since then at Google.

I’ve worked in different initiatives, obviously. Recently I moved to so I spent four years doing detection response in different areas, and then I recently moved to, you know, securing the enterprise infrastructure protection that has specifically do with cloud. So think of the whole detection and prevention as two sides of the same coin, right? So you’re detecting and the other side of preventing, which I’m sure we’ll talk about a lot today. But that’s a quick intro. So I love working with people and making impact that I can get up in the morning and be excited about. Okay. What I did today touched a lot of lives. I think that’s pretty key.

Host: So talk about timing with Yahoo. Like when you joined Yahoo. Right? But yeah, I’m pretty sure you must have learned a lot. So I’m looking forward to like, learning some of that from this as part of this conversation. Right. So let’s start with the blue team. Right?

So there are a number of difficult challenges that are like number of difficult challenges in running a successful blue team or the defensive team. And Blue teams typically spend a lot of time looking at different types of alerts. Right?

So according to you, how does members of Blue team work with these challenges?

Karan: Yeah. And that’s a great question. So this is very typical, right? Like, I would say there’s a bunch of challenges. I’ll touch upon a few major ones, and I’m sure I’ll miss a few because there’s so many, right? But very typically there’s always a constant challenge of how do you prioritize your detections, how do you prioritize your response? Because it’s literally impossible, I would say next to impossible to detect and respond to every single thing. So when you have too many threats, you have to write logic detection threats against them. And so idly, if you ask me, Idly, the best thing is you have a threat model and you’re like, okay, this informs me of all of the risks that my organization has, and at this point, I’m not even talking about detection person, I’m talking about risks in general and then you stack rank them and you say, look, here’s my top five, next three and bottom two, and then you walk your way from the top till the bottom and you figure out whether you can prevent it, avoid it right away, mitigate it through some methods. And then finally, if you cannot do anything in that area, that’s when you go and think about, can I now detect this? Because that’s like, okay, if something happens I know.

So there are some you just accept some organizations to do that you cannot always mitigate or prevent or detect. Like, okay, this is fine for us, but privatization coming back is, I think, one of the key challenges. I’m speaking from experience, by the way, it’s nothing to do with one or by sharing or the other, but yeah, that’s number one.

I guess number two is, I guess manual toil, if you want to call that, because a lot of people think this is very difficult. A lot of people think a detection response is a room where you sit with a bunch of monitors and you monitor the lines and they turn red and somebody does something, it’s like although that would be super cool, I know that something places may have that, but it is similar, but not quite right. Like you have a way to look at what’s happening in your organization through some sort of alerting mechanism, I would say, ideally. So this leads to twelve, right? So it’s obvious that if a human is involved, there’s manual work. You can automate a lot of things, sure, but like triaging the alerts, analyzing the alerts and then going figuring out what’s happening, what other data do you need? How does this tie up? That’s literally human manual work, right? So that toil is constant and a Blue Team actively has to figure out where they are putting their time and what can machines do instead. So it’s everywhere, like there’s manual work in prioritization, there’s manual work in actually doing the work. There’s only so much that machines can do. So I would say that’s like pretty high. The pro of that the positive side of it, it helps you build some unified tooling, right? You can say, look, here’s my logs, here’s my detection way of detecting stuff. I’m talking very generally here. So here’s some input, here’s some way to analyze them and here’s some way to prioritize them in a nutshell. And then you go about, okay, now that I prioritize them, what can I do to automate myself away in that analysis piece and where should I stop? That’s very key. Where do you stop and at what point do you make those decisions yourself? So that boils down to how do you escalate and stuff like that. So follow up triage, right, is a lot of it manual. So again, you can also measure impact, I would say by our saved per analyst. Sometimes people are not incentivized to work on, hey, I’ve just like reduced oil. I didn’t analyze alerts. You can incentivize engineers to say, look, you saved X hours per person on the team and you can translate that to dollars. And that’s pretty straightforward.

That’s I think, second thing on my list, I would say it’s pretty obvious. But the third thing is burnout. So you have so much things happening. You have radiation, you have toy that will lead to burnout for the team. And this is stocked less, in my opinion, in the industry than it is prevalent. Like I myself have been on the other side where I have told people I am burnt out. I’m going to take like a week or two off.

And that’s not for vacation. That’s to reset myself on the team. And I would say management and people responsible should actively work to figure out the load of the team proactively. You watch out for it distributed across time zones. There’s so many ways to do this. I’ve done in my life, night shifts, I’ve done weekend shifts. You name the time, I’ve been awake on that shift.

So I’ve seen so many variations across the board and it is not just talked about so much. So top three, these are the top three in my list, I would say.

Host: Okay, I liked a few things that you highlighted. One is most organizations do not say that, hey, we will accept some issues or some threats, right? But maybe that’s the right thing to do. Depending on how many threats you are dealing with based on your threat model, does it even matter, right? So based on that, maybe you should accept some of the threats. And the other thing that you highlighted is the burnout, right? That makes a lot of sense. And particularly during the COVID time when everybody was working from home, that was a major challenge, right, that everybody was going through.

So a follow up question to that is we highlighted the challenges, right? Like you highlighted the challenges. How would in that case, the blue team define what success for them and how will they keep track of their progress.

Karan: Yeah. And so it was down to again a number of things I would say and I’ll touch upon the obvious but also nonobvious. So the most obvious ones is hey, your day to day is to detect and successfully stop intrusions and attempts of intrusions to keep the company safe, period. If that’s a one liner mission that I can write, that’s what I would write first. But there’s a lot to it.

It’s not just external, there’s nuances there. And an obvious metric is like have you successfully, a number of times you have successfully prevented or detected and stopped it right away. How many have you detected and stopped red teams and purple teams and other teams that actually emulate external attackers? How many alerts are you triaging analyzing and mitigating within some Slo that you have? Slo is again, organizational thread dependent. I would even say a number of alerts analyzed and the severity.

So are you always looking at low severity ones or are you actually doing the high severity ones faster over time? Again, I’m going a little bit nuanced there, but what I would love to see is the team reducing toil and increasing automation over time so they can look at higher priority alerts, high severity alerts faster than they were doing a month ago. Right? And this can be team level metrics. I’m not saying this is like board level thing that’s going up, it can go up in some shape or form. But if you define the core metrics at the team level and you track them then I think it’s easier to derive other metrics, like some derivative metrics.

Host: Makes a lot of sense. And two things that you highlighted, right? One is the other teams either internal which are like red or purple team or external, they sort of create more problems for blue team, right. Because they are either attacking the system, they are taking offensive role. Right.

So I want to touch on that a little bit. So generally red teams are like counterparts, right? And they’re attacking the system.

So what steps should be taken to identify that it’s a red team activity and how can their access or something can be blocked?

Karan: I would first say that they are not adversaries, they are partners. I think that’s a huge distinction. They’re adversaries in the sense on a technical level, yes, they might look the same or similar as external attackers but they’re partners. Honestly their job if you ask me is to help the blue team just do better. Literally they’re on your side. Right? So I would say the steps are very subjective. If you’re trying to identify how to identify them, it’s subjective based on what TTP exists, like tactics, techniques and procedures. Like what are the specifics? I would say it was very based on that. But like the goal of the blue team in this case, I would say is to have enough coverage of those high severity, high priority techniques, tactics and procedures to be able to say oh, we have caught them early enough and early enough is subjective, right?

So you might say look, they ran as can be caught them two, they were about to get root access and we just caught them. There’s a huge chain of different in the kill chain, it’s going forward and so where you detect them is a way to think about how efficient you are and how you have been about it because techniques of detection vary, right? I would actually add you had talked about a little bit how to define success. There’s so many metrics you can do there, you can say hey, coverage by operating system, coverage by, as I said, TTP itself, time to detect response and mitigate, right? Like there are different times and you can actually use them the same as external, as the team or purple team.

All of this counts as goes into the steps. So you actually build a cohesive blue team program based on your risk and based on your threads and the steps won’t be any different, but how they move and what they do changes. Look, they’re on your side though, they’re not going to cause at the end, they’re not supposed to cause massive damage. It’s all approved and stuff, hopefully, but their outcome should be shared with you in a room and say hey, look, we did this exercise, you caught us here, but you didn’t catch us here, so go to this. So it feeds back into your prioritization challenge which I talked about, go prioritize this instead.

Host: I like how you highlighted as a first sentence to the response that they are not your adversaries, right, they are your partners in a way. They are helping you as in the blue Team get better, right? So that you can have better coverage of risks or coverage of the threat model and stuff like that. So the activity that the red team performs, should that be treated differently than an external attacker?

Karan: Not very much. I wouldn’t treat it very differently because at the end of the day they are trying to simulate so I wouldn’t treat them differently, I wouldn’t bank on being kind.

I would actually treat this as a challenge where failure is helping us grow just like anything else, right? Yeah, I wouldn’t treat them any differently but also I would watch out for places where they have more access or they use something that external attackers may not know because there’s also a knowledge gap. Internal folks know a lot and they might try to in their attack simulation, use some of that. So you have to be careful of when you are a blue team and digesting information from the red team.

Look at where the internals lie and can an external attacker get the same information that they have or access that they have and ideally focus on the parts that anybody could do. Like any external attacker could do a great recipe. Always be very close to an external attacker. They will not try to use anything like, I would say that they know all they will try to figure it out if I miss it.

Host: Yeah, makes sense. Because at the end of the day, we are trying to, as you said, right. Red team is trying to simulate as an external attacker, the closer they are to the external attack spectrum, the better it is for the Blue team to improve the defense mechanism. Right.

So let’s say as part of the work, the Blue team that they do, how do they collect let’s say they throw traffic data or the forensic data so that they can analyze and test and get better.

Karan: Yeah. And it really depends on the environment. So there’s so many tools out there, I don’t want to name any specific ones on purpose because it depends on what you use, I would say. But in general, if you ask me, how do you go about collecting evidence? It depends on the type. So let’s say you’re trying to understand, okay, if I want to figure out what’s happening on my network, I have several ways to go about it. I can look at IDs. If I have I can look at IDs, I can look at something on the edge router. If we have logs on the network side, see if we have not the full packet capture, because that’s too much sometimes. Just look at flow logs.

If you have them, if you’re collecting them, how you do it, how often you collect them, how long do you keep, again, organizational dependent. Right. And so, as you’ll realize, if an attack happened two weeks ago and you just don’t have the logs, you lack the visibility to detect it. Right. And so that becomes a logging issue. So it’s very nuanced. And that’s what I love about it, because there’s so many multi dimensional challenges involved in successfully driving a Blue team.

I would say, for remote forensic, that’s a new, I guess, exciting thing. Been going on for a while, I would say. But if you look at tools like GRR, GRR, it’s an open source tool, but Gur allows you it’s fantastic because it allows you to collect data from remote hosts so you can have agents and you can pull it out the moment they’re available. Right. And so you don’t have to wait for a machine to come online and stuff. Okay. There’s a bunch of open source tools out there contributed by different companies or organizations or individuals. Right.

But nothing really beats Forensically sound collection done locally on a machine. So I’m like, I’m sitting in front of a machine, I can put the right in and collect the hard drive as nicely as I can in my own leisure time. I can collect it without any network issue without anything else bothering me. That’s like the best case scenario. I’ve done that so many times in my career. But with everything these days, remote collection has become very prevalent. So, yeah, to answer your question, it depends on the type of logs.

It depends on what agents you have, what configurations you have, how long you keep things. But like, you can pull logs from the system. You can put system logs or specific application logs. You can pull hard drive memory depending on where you are, like physical architecture in front of the machine. That’s awesome because you get the latest and greatest, I would say, right? Yeah. But yeah, there’s a lot there’s so much advancement these days and tools.

Host: So one thing that you highlighted, the flow logs, right? And I believe all the clouds recommend that you enable flow logs so that you can deal with things like this, right? You can look at your network traffic, you can run some analysis and helps with your threat detection and stuff like that as well.

But it also comes with additional overhead in terms of a lot of data, as you highlighted. Right. You have to analyze a lot of data or it has cost impact as well, right, sometimes because you have to store that so that you can do analysis or you need to have a tool so that you can analyze it, and often that comes to budget. Right. And in an organization, security is often looked at like a last priority when it comes to budget. And threat hunting is even low priority when we talk about budget. Right.

So how should organizations or the security teams deal with these challenges? Budget constraints or threat hunting purposes?

Karan: Yes, and I will tie back up to what I said earlier. Remember, I talked about prioritization.

Think about budget constraints as you have a certain amount of money that you want to put towards solving problem X, which in this case is mitigating or tackling risk. Right. If you have a prioritized list of I want to do this and I’m okay with not doing something at the bottom, that’s what you need. So invest in the right places. Right. And look, sometimes it actually makes sense where you store a log for six or three months or six months, whatever is legally allowed or by regulation or something like that, and that would be fine. But sometimes you’re okay with just having a month because you know what, there might be some other log type that you can join and that may be suffice, that may just work for you.

So you have to figure out this tiny details and see, okay, I want information X to detect Y. How do I get X in the most efficient manner so that I can confidently trace back? You need a lot of engineering, I guess, brain power in this because you need to understand each field in the log honestly and say I’m getting value here and not here. So can we just store these five things and store these six things here and join and we’re done. Because that means the budget. But hopefully it’s not very granular. The budgets don’t work on a thread by thread basis. I’m just sort of exaggerating to drive home the point that you can actually go, if you like, go granular and actually figure out. But retention is a big thing. I think most if you look at data storage, that’s where the costs are along with the product that people offer. So Bluetooth has to work hand in hand with people who are funding and say, look, if you give us this or we need this to give you this, that’s what your money buy. Not a lot of conversations happen so openly in that area, I would say. I think it’s upon the tools to drive that with leadership.

Host: So two things I could understand out of it is one is you need to absolutely understand that you cannot fix everything. Right. You have to have that prioritization so that you can tackle the highest impact items and have a clear conversation with other stakeholders, other teams or the person who is writing the check, right. So that they understand the impact of it and then support you in these areas. Go ahead.

Karan: I was just going to add a lot of leaders when they climb up the ladder, they already have worked so they already have the contact. It’s not like they have to sit with analysts and stuff all day long. But it just drives up the point that those decisions should be informed by data and you should know what you’re buying at some high level.

Host: Yeah, absolutely agree. One thing that you highlighted in the last answer is that the logs or the data that is needed for analysis is very important. Right.

For the Blue teams, what steps need to be followed to prevent that there is no loss of that data before it comes to the forensic experts?

Karan: That’s a good question. I think it boils down to reliability if you ask me. But if, let’s say you’re collecting something manually, I would say just become first. And that’s not even a technical advice. That’s advice coming from somebody who has been in incident response and has stayed and has gotten up from sleep and responded to something urgent right away and your brain may not work that time. So you need to have what I’m getting at is you need to have good playbooks. You need to be able to say when emergency hits, here’s what we do when emergency does not hit, we are calm.

The world is okay. We go and figure out what are the best, most sound ways to collect data and of a certain type and we write that down in exhaustive detail and we practice it. So if you’re talking about collecting logs from a machine that’s remote here’s the steps. Click these buttons, do this, automate this, you’ll get it here, it will be in this file format. And then you plug it into this tool to analyze it. It should be so clear, it should pretty much be like a human can just do it even if they have asleep. So remain calm and don’t make those mistakes. Because most people want to rush through it, but realizing that a lot of data is volatile. So let’s say you’re collecting memory and you’re panicking and you’re clicking a bunch of buttons. Well guess what? You’re creating more processes. You’re mangling the memory that’s already there, that may have some evidence, right? So you have to be very diligent on what you do.

Avoid starting up new processes. As I said, when you do machine is compromised. A lot of people just want to turn it off. They’re like, okay, we’re done. But realize you just lost data. Like so valuable data, right? If you already have playbooks and on collecting it, avoid turning it off abruptly. If you have inhouse forensics expertise, that’s amazing because they can go and collect something in that moment, hopefully.

If not, then close. And then you can take mitigation steps. Because you know what, when you do that, you let the other side know who’s in your systems that you are on it. So it’s always a cat and mouse game at the end.

The same thing is with when you’re trying to so let’s say you’ve collected, right? You have playbooks and you have a sound way of collecting, you know, local data as well. The next thing is the chain of custody, right? So let’s say I collected evidence today. Idly I would fill out a form that says my name Karan. I collect this evidence, this date, this time. I am giving it off to legal now or somebody else for doing X. And that’s recorded. Because tomorrow if there’s litigation, you can prove that data was not mangled. It has integrity. So as I said, the first step come. You have to remember these steps. You have to follow the process and playbooks. If you don’t have build them, because it’s pretty critical. Because if you cannot attest to the fact that data has not changed, or you can just say, oh, we don’t know, it may be changed, guess what, the facts don’t line up. Right? That’s where it has consequences. So you lose that authenticity and trust on that data set, right? In a way, yes. And you can’t build your case or whatever you’re trying to prove. But let’s say you’re trying to prove a timeline of X thing happened, then Y happened, that led to Z. If you can’t prove that the data didn’t change or somebody didn’t mess up by accident, also you lose that trust. You’re just like now guessing or inferring, which is not really great. In when you’re forensically analyzing something, you need to have hard core facts.

Host: That makes a lot of sense. Yeah, that makes a lot of sense. So I have one follow up question on this. So nowadays there are more like attackers have more ways to attack and for stakeholders of security stakeholders or others in the organization, they want to speed up the process, right? So that you can preserve the data, you do analysis quickly.

What’s your recommendation on that?

Karan: I’m sort of very cautious with saying do this fast. I would probably say do this the right way. Because as I said, if you don’t follow your playbooks, you may mess up data, you may mess up the chain of custody, you may not collect the whole thing. You will just lack the data you really need to speed up. Sometimes going fast is actually going slow in this case. So that’s something I learned is like yes, going fast and achieving things or doing things quickly can work. But it’s a big asterisk because you’re losing quality somewhere.

You’re compromising that or you are, you’re like an expert and you can do it faster because you have already done it. Guess what? You have already done it 10,000 times. So there is that I would caution people who are saying let’s go fast just because of going fast, go fast in the right way. I would modify that advice. Use software, use process that are approved by your legal teams, that are accepted by the courts. There are some software that have been accepted and said okay, this works because we have talked to this team and we accept this. Go and figure that out and use that instead. That’s what gets you speed. Not let’s just get it out of the way so you can do something else.

Host: Yeah. So the message that I’m getting from your response is that do it properly and have the automation or process in place so that you can move fast but not at the cost of compromising the data quality or the evidence that you are trying to collect and the process that you’re trying to follow.

Karan: Yeah, exactly.

Host: Makes a lot of sense. So I see that you have a lot of experience in like you joined Yahoo at the sort of right time in a way where you could learn a lot.

So let’s say somebody is starting their career in threat hunting or blue teaming or red teaming or purple teaming. Where should they start from?

Karan: If they’re talking about starting career? A lot of people want to get a hold of really what’s happening on the ground. A lot of engineering analyst roles are sort of stepping stones and they still are. It’s been true for a decade and still true today. But that analyst role has morphed into more of engineering because again, automation AI a lot of assistance, right? So it’s now become the person looking at alerts and just clicking buttons to now has become more off.

I would say analyzing it and figuring. Out what’s happening. So to get back to your question where they should start from, I would say there are, in My opinion, there’s like three different pillars that one should build. And I talk about this when when I I give university talks or something else in my mind. Three pillars, one, knowledge. Make sure you know your concept. Like understand systems operating system concepts, network concepts, application Concepts

Get that right. And Then you build a layer on top of It, which is Security Concepts. So you insert security at each layer. How does operating system security work? How does network security work at each OSI layer? Figure that I’ll read through it, spend days on it until you get it, because tomorrow you will use one of those fields and one of those protocols somewhere that will change the game of the analysis. Right. And the last thing I would say, the layer on top of that in the knowledge space is Risk and Impact. So then you look at the entire organization. That’s a knowledge pillar.

The second pillar, I would say, is skills. So there’s something you do. I would say if you’re starting out, go learn about CTFS, capture the Flags competitions, and it’ll help you. Like you have an environment. You are given a puzzle. Solve this, you will use similar tools. It may not be the real, obviously attack, but you learn.

Go do some automation using Python. There’s so many code labs and I guess courses these days out there. Spend time building that skill, that muscle memory. When I was working in IR, like Playbooks were in my head, I could go execute the commands I had shortcuts for most of the commands I used to run. I run four of them and we’re done. So reach that maturity, I would say, in your Skills. And the last is, which cannot be replaced is experience.

So on the ground, real world experience is what really gets you that confidence. In Blue Team, I would say you can read all the books, you can do all the code labs, but if you have not faced an incident, you’re not going to have that experience, I would say. So look for like if you’re starting out, look for internship, look for part time even it’s volunteering, it’s fine because people need people to work. And you can start off with that. And guess what? People Will Be happy to pay you later because they can see the quality of your work and See you’re a team player and stuff like that. Do open source projects. So many out there. Great ways to build your resume.

So it’s a myth that, hey, I need to have some experience to get a role. No, you just have to build all these three pillars. Right?

Host: Yeah. Makes a lot of sense, especially the one around Skills. Right. Most of the folks, what they do is they difference between theory and practicals. Right? Doing practicals, they just read books and they’re like, yeah, I know. Or they have done some certification and they feel like they’re ready for it. Right. But it’s the time that you put in to do it actually that helps you.

So on that front, any reference materials like blogs or podcasts or videos that you would recommend?

Karan: Yeah, right. Besides, we have a bunch of books. But that’s things I read. But to start off, if you’re asking still, the question is about somebody starting out for operating systems.

Look at this bunch of books out there. I would pick anyone out there that explains the concepts, right. For infosec, there’s also Infosec Handbook. I think it’s called Introduction to Information Security ( https://www.amazon.com/InfoSec-Handbook-Introduction-Information-Security/dp/1430263822) . Pick that one out. I think you can find it on Amazon somewhere. For Blue Team specifically. There’s Blue Team handbook (https://www.amazon.com/Blue-Team-Handbook-condensed-Responder/dp/1500734756) . I would really recommend that one. It’s a small guide. It’s literally this much, right? I have it right here. And it was funny because I picked it up in my first year when I started working and I found an error in the book and I ended up emailing the author and his name is Dan Murdoch, or Don Murdoch, excuse me if I’m messing that up. And guess what he responded.

He’s like, actually yeah, that’s right. I’m going to update this. And he sent me a signed copy of his office next book. I still have it right besides me here. And you network this way and you learn more and you get plus one from somebody who has written a book. It has an evening actually. It happens, right? And I was like, you know what, this person is super receptive to feedback.

So I’m going to convey and publicize this book out of my own.

I’m not incentivized by him or anybody else. But I love the idea that the author was willing to take feedback and actually do something about it. He shipped me for free like that book. So go out there and find books like this. I have a bunch that I use.

There’s a bunch of forensics books I use. One of the books is by Brian Carrier, if I’m remembering his name correctly. He has a book that talks about how to do forensics on disk images. So he talks about file. I think his name is File system Forensics (https://www.amazon.com/System-Forensic-Analysis-Brian-Carrier/dp/0321268172

) . That’s Books name and file system forensics is a masterpiece. Literally.

I have read that book like n number of times back to back. Because the way Brian has described each file system is amazing. Like he can break down fat Ntfs partition by partition, bite by bite. And you can look at it on the screen. Really recommend all those stuff.

Host: Okay, so thank you for sharing those. What we’ll do is we’ll make sure to tag them when we publish the video so that our viewers can go and read those books as well.

So that’s a great way to end the security section.

Host: Let’s go to the rapid fire section.

Rapid Fire:

Host: So the first question is what advice would you give to your 25 year old self starting in security?

Karan: I would say to myself probably start networking early and often because I feel like even though I did that, but not to the extent I should have. And I picked that up in the last few years quite a bit. It is something you are doing in parallel. Remember we talked about the knowledge, skills and experience things you do networking in parallel. It’s a parallel thread that you run and the network effects compound over time. Just like knowledge, just like I build a connection with an author randomly, just by a cold email, he has a network of authors. They are second degree, third degree connections. But until you have that first, it’s hard to get a hand of hold of the others. So I would just say that it makes a lot of sense. That’s how you assimilate knowledge that somebody else has and you grow right.

Host: Makes sense. The second one is a one liner code that keeps you going. So this is a little bit funny, but also I don’t want to sound negative.

Karan: I always remember like life is short and it’s not because we’re just going to vanish one day. It helps me really prioritize things. It helps me drive clarity on what I want to do on a yearly basis, daily basis, in a decade from now. Am I focusing on the right things in personal life and career and my team and what’s happening there? It drives so much and like people fret over things like oh, they’re really bothered by something. I’m like, will this matter in five years or ten years or 15 years? If not, then don’t worry about it. So it’s just that three words is sometimes more than enough to drive that for me.

Host: That’s lovely. Makes a lot of sense. Also, what’s the biggest lie you have heard in cybersecurity? I can see a few coming, actually.

Karan: Yeah, I’ll start with one. So maybe this is the biggest one. I feel job postings, right? And I’m not targeting any company or anything. This is within the industry. A lot of times people get the impression and this may be the way it’s written or not, or maybe the way it’s interpreted is people feel they need to meet all their criteria for applying for a job, for applying, not qualifying. And I browse just to look at what people are, how people are writing. And they have a list, a huge list. We need five certifications. We need X amount of experience. And guess what? People are trying to apply because they’ll self reject themselves even before they hit the button. And I’d rather get an email that says, okay, you’re not the best fit because of why than me self rejecting myself. But that’s just me, like, how I’ve trained myself and I’ve learned. It’s the biggest lie, in my opinion, that’s really fueling the shortage we are having in the industry. There’s so much demand for people and people are just stopping themselves from applying. Or we should do a better job at writing these postings, obviously.

Host: Yeah. And I can relate to it. I’m pretty sure a lot of folks can relate to it. Right? When we go through any job posting we see and we’re like, okay, I qualify for these five, but I do not qualify for these. Then there is a section of preferred versus mandatory. It becomes very confusing. So.

Yeah, I love that. Yeah, I’ve had my fair share of frustration with that. And I’m like, how can we improve this across the board? How can we do this better or solve this problem better? Because it’s a problem.

That’s a great way to end the episode. Thank you so much, Karan, for joining us. It was a fun discussion to learn about Blue Team and how they work, how they work with others and stuff like that. So thank you for coming to the show. I really enjoy talking to you.

Karan: Thanks so much for the insightful questions. It’s hard to memorize any answers. A lot of it is just ad hoc based on what you ask. And so it’s a lot of fun to have this discussion with you. Thank you.

Host: Yeah, absolutely. Thank you so much. And to our viewers, thanks for watching.

Hope you have learned something new. If you have any questions around security, share those at scale to zero. We’ll get those answered by an expert in the security space. See you in the next episode. Thank you.