GOTD - Shanief Webb
===

Speaker 2: [00:00:00] Welcome to Guardians of the Data. I'm your host, ward Balza. Each episode will explore the passions, expertise, and real world experiences of security leaders who are helping the future of data security and governance. Guardians of the data is made possible by support from Centro. To learn more about our AI powered data security platform, please visit sentra.io.

Let's dive in.

Ward: Welcome back to another episode of Guardians of the Data. My guest today has over a decade of experience in cybersecurity. He's an executive leader. Unlike many who came from the risk and GRC side, he came from exploitation, reverse engineering, and digital forensics. Currently the interim CISO and leader of security engineering at a digital healthcare organization, Shanief Webb, thank you for joining.

Shanief Webb: Hi, Ward. Thanks for having me on the podcast

Ward: Oh, really good to have you here. So, Shanief, in your professional opinion, what's the biggest challenge organizations are facing with data security?

Shanief Webb: [00:01:00] Great question. I think a lot of organizations have some problems that are rooted in people. So when there's, institutional knowledge that leaves the organization that has a lot of context and understanding about the data that is collected and stored, um, when there's a lot of reorganizations and, you know, turnover, that knowledge gets lost. And details about what actual data is being collected and harvested and stored and, uh, processed and, you know, transmitted to other third parties, for example, um, that context also gets lost. Um, so the problem is that understanding of the data, the contextual understanding, but also then the volume of data that is getting collected that's always growing. and then we-- that-- those two component together create a kind of perfect storm of, you know, when something goes wrong and you don't have that perfect understanding of what is, uh, impacted in that thing that has gone wrong, like a breach or [00:02:00] outage, um, requires someone to ramp up on really the, the really intricate details of what type of data is being stored and who does it belong to.

Do we have to notify, you know, this person or that regulatory body? You know, things like that. Um, so I think those two issues component together, people and, and context and, and understanding the data is, is really key or, or a big problem for most organizations.

Ward: I like that answer. You know, that's, that's something unique that we haven't heard, um, you know, word for word yet. You know, the whole idea of the tribal knowledge problem. Um, you know, I think for many years folks thought that was a way to, like, keep their job secure, right? If I know these things and nobody else knows these things, I'm important.

And, uh, you know, the problem as, as you laid it out is, uh, when, not if, but when someone leaves that has that tribal knowledge, oops, now you have a problem. So what's, what's the best way to solve that? What are-- what do you [00:03:00] think? What-- how, how should organizations tackle that problem?

Shanief Webb: Um, so definitely knowledge sharing, documentation, um, data catalogs, data inventories, um, making sure that you have a record of what type of data is being stored, um, whether it's sensitive or not, and making sure that you understand if that data's ever impacted, you know who to notify, um, if it is. Um, so keeping it out of people's minds, um, and into some shared repository where everyone can, uh, go to it as a source of truth to understand more about it would be the long-term solution to that.

Ward: So I'm hearing one of those evil words that a lot of cybersecurity folks don't like, which is documentation, essentially. Is that, is that what you're promoting, more documentation?

Shanief Webb: Documentation and/or product, but yeah. Uh, um, I think, I think that's necessary to make sure the data, the info doesn't stay siloed. Um, how else do we keep information shared across different people [00:04:00] systems?

Ward: Absolutely. So how... I, I've dealt with this too, and I'm totally with you. Documentation's super important because, I mean, I was reading something today, you know, the average tenure these days in any cybersecurity job's about three years is, is what they're saying, which a little bit shocking. I guess I shouldn't be surprised, but, you know, three years, um, you can do a lot in three years, and then certainly if it's all in your brain, you know, other people might not know what it is.

So I've had that problem too, where I try to tell my teams, "Look, guys, we need to document, right? For, for all those that follow, we need to make sure it's there." But I always got, you know, pushback and not like, "No, we're not going to do it," but, "Oh, it's too tough and it's too time-consuming," and all that. So how, how do you deal with that pushback for folks that, again, most people do not like doing that type of work?

Shanief Webb: I agree. It's an administrative burden, and sometimes it doesn't move the needle in terms of, uh, [00:05:00] making impact. But it becomes really useful and needed when, again, something goes wrong and when you don't have the documentation, or even if you're going through an audit and you don't have the documentation to support, um, that as well. Um, you then have to scurry together to get that documentation together. But I think in this current era of AI, it makes it a lot easier to produce documentation, um, at scale that-- than, than before. So I think we're in a better place now to do that, um, a, in a way that is not a, a burden on people.

Ward: I do agree. You know, certainly a, uh, good that has come out of the day and age of AI. You no longer have to spend, you know, hours or days, you know, producing that, that, that documentation. You hit on something interesting though, and again, something else that was always a bane of my existence being in the enterprise, audits, right?

Auditors always come knocking, either internal or external. And again, most security folks love to [00:06:00] hate auditors, and love to hate, you know, producing audit documentation. My question to you isn't, 'cause you already hit it, right? Create the documentation, AI can help. How about keeping it from getting stale or from being inaccurate over time?

'Cause a lot of organizations, not all, a lot, it's kind of a one and done exercise or it's an as-needed ad hoc exercise. What do you think folks should do around keeping their documentation up to, up to, you know, accuracy essentially?

Shanief Webb: I've seen different approaches at, um, at solving for that, and that's when people are onboarding to the team, so new hires are joining or someone may be transferring from another team. Um, as they onboard, they review documentation to ramp up, and they might identify things that are, um, not one-to-one with what's the current state. And so they are also tasked with keeping the documentation up to date as they onboard, um, to help them get a better understanding of what, you know, they'll be handling going [00:07:00] forward. But, um, that, that cannot be scalable sometimes if you're not hiring all the time or, you know, doing internal transfers all the time. So there also needs to be periodic reviews of your documentation, particularly if it's gonna be used for audits. So there are annual audits typically where you might be required to look at the documentation and verify that it is, um, accurate and current to, to what is being audited.

Ward: How about, so, you know, a thought that occurred to me, we- we've danced around it, actually you said it, AI helping with documentation. How about documentation helping I- AI? How about the inverse? You know, kind of onboarding a new agent and, and using that to, uh, you know, using the documentation, um, maps, whatever, to kind of train it.

Uh, are, are you seeing that be successful as well?

Shanief Webb: That can probably work depending on the organization and maybe the type of data that is flowing through the agent and what's being accessed. It gives me pause working in an org that handles, you know, HIPAA protected data. Um, but maybe at, you know, other [00:08:00] organizations where data may be less sensitive, that could be something that's very feasible to, to do and, and even a scalable preferred approach.

Ward: and, and you mentioned, you know, highly regulated environment, specifically HIPAA for yourself being, being in healthcare. Uh, going back to the whole documentation piece, do you see any, like, additional pressures from, you know, being highly regulated and needing to keep really good up-to-date documents?

Shanief Webb: Absolutely. Um, because we, we, uh, we go after certain or different certifications or audits, uh, every, every year, iTrust, SOC 2, Type 2, um, Cyber Essentials Plus. Generally, that requires some documentation that shows, you know, you do-- you are doing data recovery exercises on a regular cadence and, you're stepping through each process of that and finding things or gaps and solving those gaps. Um, which is not necessarily just documentation that, that's you kind of describing, you know, e-exercises that you work through and like end to end. But other [00:09:00] documentation, like how a process might work or procedure or policy, um, might also need to be up to date and current as well. As contacts change in the organization, you need to make sure that list is, you know, up to date and current as tooling changes, like how you might page a team. Um, that needs to also be current and updated so that people know to use the right tool, um, or email address list change, uh, in the or- in the organization as well. So you want to make sure all those things are current because when something goes wrong, people can, you know, assemble very quickly to the, the incident or whatever the outage may be, um, and work toward resolution very quickly. Out of date documentation will, will slow you down. And so we see that come up in, um, the, the regulatory context, in the audit context, and even in our own outages, uh, day to day outages that we have

Ward: I like it, I like it. I wanna ask you a question. I was, I was re- looking at your, your LinkedIn profile a few times and, and folks, if you haven't, uh, you know, if you're listening, you know, definitely go out [00:10:00] and check out, uh, Shanief LinkedIn and his experience here. But there was a line in there that I wanna ask you about.

I think it, it relates a little bit to what we're talking about, documentation, and you mentioned onboarding and stuff. And, and the line that I really liked, I'm gonna find it again. I'm gonna read it word for word 'cause man, was it powerful. It was... Oh man, now we're live and I cannot find it. There it is. It says, "I build generalists who work across specialties, not specialists locked into one."

It's a super powerful line. I love that. Tell us more about that whole mentality and, you know, maybe how that relates back to what we're talking about with documentation and all those other pressures

Shanief Webb: maybe not to me, in my mind when I wrote that it wasn't about documentation, but it really is more about how I came up into, uh, security as a professional. Um, and even before [00:11:00] security, working in fast food even, um, going from being a specialist in one as a carver at Boston Market to being cross-trained in marketing multiple positions as a cashier, um, to get more hours and, and get more-- make more impact. But, um, the reason I like to develop generalists is because a lot of the work we do transcends across one vertical. Um, you might ha- work in a security operations center, and you might see an alert, but that alert might come from a system that's for application security or might come from the Bug Bounty program or the insider risk, um, vertical, right? these things start to cross paths and translate and intersect, and we need people that understand how they all intersect, and that requires you to have knowledge ad-- across different domains, not just one that you're working in day-to-day. Um, and in my career, that has benefited me because I've learned...

I started with reverse engineering malware as a computer scientist at the FBI and did a lot of coding and scripting on my own [00:12:00] to help with the reverse engineering work, um, and also to help with moving cases forward too. Um, and then as I moved throughout my career in different organizations, I landed in different positions that built upon my experience to allow me to add value in different ways.

Um, and at Google as a sec-security, uh, analyst, uh, or security engineer, sorry, in the security operations center at Cox as the IR lead. So going from detection and, and automation, automated SOC, to helping the teams respond to incidents at scale, to being a threat hunter at IBM in a MSSP context, um, a lot of just different perspective and different views of how to how my work impacts other teams, other people, even clients, and really make better decisions on how I build things and, and how I solve solut- how I solve problems and how I document things, how I communicate, things like that.

Ward: So how has that been for, for you actually building your, your teams? [00:13:00] 'Cause I've, I've also struggled with this too, right? As, as I would build out a data security org, I may have a need for a specialist, right? I got a tool, I need someone who kn- knows that tool, that, that knows that tool already, right? To come in, help implement it, whatever.

But then it's like, "Hey, cool. You know this thing, now I need you to know the other things." Ki- kind of a little bit what you're saying, but you're almost saying the inverse. "I wanna bring someone in that knows," or build up the generalist, right? Knows all the things, and then they start to, to learn. So how has that worked for you in, in building out teams?

Shanief Webb: I think that's worked well. Um, it might seem overwhelming at first, but I d- I like the approach of can they learn? And that's how I, and that's how I look for, what I look for in interviews. Um, can you show that you can learn and adapt and be flexible? 'Cause that's the kinda, that's the key indicator that shows that you'll be successful as being a generalist. Um, so maybe someone has a lot of experience in detection engineering, and they want to expand into another vertical like incident response or vulnerability [00:14:00] management or cloud security. Well, if you are in a security operation center or triaging alerts that come from your SIEM, those alerts come from all different types of systems. And you have to go and do research and dig and understand the context around the alert, not just what it, what was detected, 'cause you're trying to discern whether something's true or false positive. Um, you may also be building things in the systems that are generating the alerts as well to make them more high fidelity or to give more signal or preventative controls to prevent them from firing in the first place. Um, and so having a generalist in the team, maybe starting with one specialty, but learning how to, you know, develop other skills in those other domains g- by giving them projects to work on. They create RFCs, they align with teams, they discuss them, and then they build out the project and, you know, execute, you know, over a half or a quarter. Um, that gives them that experience in those other domains that they may not have had before. And over time, they become generalists because they [00:15:00] start to touch on these different areas, um, around security, not just this one thing that they would do day-to-day uh, positions.

Ward: I li- I like that way of doing things. And, you know, kind of bringing it back to the data security topic, uh, that- that's something that I've tried to, you know, tell my own folks for a while as well. It's like, yes, you, you are in data security. Yes, you're gonna be doing, you know, things with DLP or maybe insider risk management or whatever, but guess what?

Data is everywhere, so it's highly likely you are either going to work with other teams, right, like crazy, um, but you're also probably gonna need to understand, um, this is almost like technical generalist. You're gonna have to understand how certain solutions work, databases, file repositories, all of that.

So you, you mentioned, uh, security generalist, but how about the IT generalist type things? Is that what you try to instill as well?

Shanief Webb: I, I don't lead an IT organization, but I would recommend IT, um, engineers or generalists as well. Um, so [00:16:00] maybe having understanding of the help desk, understanding of IAM tooling, understanding of endpoint management, so I think they're called CPE teams, client platform engineering, um, all the different things that are needed to kind of run that, the enterprise IT, uh, space and make them successful. think having just the general knowledge for you to float around and be able to make impact where you need to, to keep the lights on or to move the needle are, are essential

Ward: So going back to challenges in data security. So you mentioned documentation. You also mentioned another part. Can you remind us what the other challenge you said was?

Shanief Webb: Um, I mentioned people and I mentioned, um, the context around the data and volume

Ward: So vol- volume, right? That was, that was what I wanted to hit on. Vol-- I mean, I talk to a lot of organizations and, and y- and you, you may have experienced this too, like you talk to organizations, and one of my first questions from like a data security audit, um, is around data [00:17:00] retention, right? Do you have data retention policies?

Do you know what they are? Do you follow them? And usually once I hit that, "Do you follow them?" I get a chuckle or a laugh, and it's like, "Well, no." Um, and in a lot of organizations I worked for, they had way too many years' worth of data. All right, it compounds. You go from gigs to, you know, you know, now we have terabytes, petabytes, whatever out there.

It's crazy. So what are your thoughts for the organizations out there? 'Cause you hit on two, two key pieces, context, you know, huge, but also just amount of data is, is crazy these days. So what, what should organizations do with that?

Shanief Webb: I think that still goes back to the people and having good understanding of the data. When there's someone that really owns the understanding of the data, they really start to own the downstream things like retention. Should we still be keeping this data? Um, or, or, you know, are we classifying it this [00:18:00] way? Uh, and just making sure things are, are kind of compliant with the policies. And even including those in the scope of audits sometimes can be helpful as well, just to make sure that, uh, those things stay current if you don't have anyone that is singularly owning the, the life cycle of data, if, if you will

Ward: You know, there's a lot of organizations, and this term is typically used with vendors, right? The term FUD, fear, uncertainty, and doubt. And, and, and I've s- I've, I've seen that in the enterprise as well, specifically around data retention, where there's fear, uncertainty, and doubt. Like, "I don't wanna delete it 'cause maybe someday I'll need it," or, "I'm not really sure if there's a legal hold," or, "I'm not really sure if there's a regulatory thing that I need to follow."

So you're shaking your head. I'm sure you deal with that as well. Like, like how do you deal with that as, as a leader?

Shanief Webb: Again, I think we're just, I think we're tying back to the people aspect of the problem. You, you need someone that owns that [00:19:00] understanding of the data. So when, if we don't understand it, then you're afraid to make decisions around it, right? You're afraid to remove it 'cause you think it might impact something. But if someone actually understands the data day-to-day in detail, they can help you decide, make an informed decision on whether it should be offloaded or, you know, maybe put into cold storage and then later, you know, sunset or, or deleted

Ward: I like it. I like it. Learn the data, make sure you have good documentation. Two, two very good high-level tips for, for our audience. So, Shanief, you, you gave us a little bit of a teaser on your background, but really curious. So today you're, you're an interim CISO, uh, and, you know, on, on top of that, y- you're, you're leading a, a security engineering function.

How did you actually get to that part in your career? What, what was that journey like?

Shanief Webb: so I began as a computer scientist at the FBI, uh, right out of grad [00:20:00] school at Carnegie Mellon. Um, I had a lot of opportunities to put into the work what I wanted to get out of it. Um, my boss was a special agent, so they didn't really know the computer science, writing code, scripting, um, engineering side of things.

I had to kind of m- teach myself, um, on the job how to reverse engineer sophisticated malware that we got from another agency and, um, how to take those findings and communicate them to intel analysts and special agents to help drive investigations forward, um, and all those things. But I think it also helped make me a better engineer because I learned how to communicate to different types of people who were not technical. Um, and I think that helped serve me well in my, in my career going from the FBI. So I did that for a few years, and then I joined Google as a security engineer in their security surveillance team, where a lot of the work was around, um, trying to automate [00:21:00] a SOC, essentially.

Mm-hmm.

Um, so detections, of course, you know, SIEM and SOAR and, uh, having automations that kind of run through playbooks to triage alerts quickly a- and all those things and helping with some of the M&A, uh, context around how do we get M&A organizations into our alerting and monitoring funnel. I did that for about a year, and then I joined, uh, Cox Communications as a, uh, incident response lead in Atlanta, Georgia. Um, and really kind of helped the onshore and offshore teams, uh, identify a North Star around the best practices of, um, security operations and monitoring, threat detection, identifying what tools help them move at scale, um, and all those great things. So at, like at this point, I'm developing reverse engineering skills, communication skills, uh, the SOC an- analyst skills, reviewing detections, triaging alerts with automation, um, and then also helping build incident response [00:22:00] and detections with teams onshore and offshore. And then I joined, uh, IBM as a threat hunter ag- in the MSSP context as well. And so I got to be more custom- customer facing, um, while also being technical, so doing threat hunting for clients, uh, having conversations around what they cared about in terms of what they wanted to, um, target in their threat hunts, um, and then providing reports and going through the findings with them to help them identify what they should, uh, or improve in terms of their posture, uh, based on what we had found. Did that for a while, and then I joined Slack, and this was during COVID, so a lot of opportunities at this time became, uh, remote.

Mm-hmm.

Um, talked to Slack before, and they wanted me to relocate to Denver, and then when COVID happened, I got to stay in Atlanta and, and join the work from Atlanta. I joined Slack, and, um, I joined as a software engineer, um, but in security.

So I got to learn a little bit more [00:23:00] about, uh, the security-- the software engineering principles that support security functions. So thinking about, like, detection as code and CI/CD pipelines and, uh, Chef and Jamf, um, how to manage infrastructure, uh, with automation basically, but in code. So I did that, uh, for a while.

Then they got acquired by Salesforce, and I decided to join Dropbox, who at that time was rebuilding their security engineering team. Um, I joined there, and they also were kind of adopting a lot of those same skills I had just learned at Slack,

Mm-hmm.

Uh, detection as code using Panther, um, and a lot of other tooling.

So I, I did that for a while, and then I joined Okta as a principal security engineer. Um, and from there, I began moving into the, the leadership role. And I started making that pivot because I had always wanted to be a, um, an individual contributor that was very proficient in my work. Um, but I had a leader who inspired me to, uh, explore the [00:24:00] people leadership, uh, area.

And so I did that, and my team needed it at the time, and it just-- it was, it was the right timing for that. So I entered that space, and I really enjoyed helping develop people and developing teams, um, pouring into them. And I think I had a unique background in that I had done this work, um, in so many different areas of the work that I could develop generalists.

And so that's what I, that's what I currently do. Um, I had joined Okta as a principal security engineer. Then I joined Meta as a security engineer, after becoming a manager at Okta, and then I joined Headspace after leaving Meta, uh, to join someone I had worked with in their organization, um, leading security engineering and cloud operations. Um, and I still lead those functions, and I'm also the interim CISO,

Ward: Wow. Uh, I, I always have to ask this question of folks that, you know, background like yours, right? Highly technical that then moved to people leadership. Any regrets? Any regrets on, on [00:25:00] that path?

Shanief Webb: it, it can be a lot, but I think it's worth it. I think you're scaling your impact by helping other people grow, um, I think it's-- When you look at it that way, it becomes more valuable and more helpful. Um, any situation though, I feel like I leave every company better than I found it, so never any regrets there

Ward: That's awesome. That's awesome. So if you could go back in time, knowing what you know today as, as a people leader, as interim CISO, and give yourself some advice, a, a younger yourself, what, what would you say?

Shanief Webb: Stop and smell the roses sometimes. Uh, there, there can be a lot that's going on in, in different, so many different areas, and it's hard to be in every place at once. Um, but it does help to just slow down and appreciate the, impact that you've made, the growth you've made, even the challenges that you've had to work through that's helped you grow

Ward: I think that's really good advice, especially, you know, given your background, you've been grinding clearly by, by everything [00:26:00] you've done, everything you've built. Stop and smell the roses. I like that one for sure. Um, Shanif, if, if folks want to connect with you, you know, follow you, what's the best way to do so?

Shanief Webb: Um, you can definitely follow me on, uh, LinkedIn. Uh, have my LinkedIn URL. I don't know if it'll be maybe in the

description We will put it. Yes, I also have a website, uh, shanif.com. It's just a blog, so if you want to read those blog posts. Um, but yeah, LinkedIn and my website

Ward: Awesome. Well, Shanief, thank you so much for joining today. It's been great insight into data security and leadership

Shanief Webb: Ward, thank you for having me again, and have a happy Friday

Ward: Absolutely. And big thank you to the audience. Really hope you enjoyed the episode and learned something. Please tell others in your network to follow and listen. This has been another exciting episode of Guardians of the Data. See you next time

Speaker: That's a wrap on another episode of Guardians of the Data. Thanks for tuning in for show notes and more Visit Guardians. The data do show Guardians of the data is made [00:27:00] possible by support from Centro to see how we help organizations discover and classify all of their data accurately and automatically while quickly achieving scale data protection without the fuss, please visit sentra.io.

Catch you next time.