Name: How Indeed Customizes Security Services To Meet Unique Needs
Uploaded: 2026-03-24T18:16:00.258Z
Duration: 39 min 32 s
Description: How Indeed Customizes Security Services To Meet Unique Needs

Transcript for "How Indeed Customizes Security Services To Meet Unique Needs": Hi, everyone. Thanks so much for joining us for this webinar on customizing security services to meet unique needs. My name's Martin Sanchez. I'm a member of the marketing team here at Cloudflare, and I'm really, really excited to be joined by Harshad from Indeed, who's gonna be telling us a little bit about his and his organization's experience dealing with this sort of need. Here's what we'll cover today. I'll start by setting a little bit of context about the need for bespoke security services, touching on some of the common situations and reasons why organizations might find themselves in this sort of situation. The bulk of our time here today will be a conversation with Harshad about how Indeed, again, thinks about this problem and some, experience that he's had building really cool custom security tools. And then I'll wrap up with a little bit of final thoughts from the Cloudflare perspective and sharing us some resources that you can use to learn more about this topic. So with that, let's dive right in. So there's a lot of reasons why organizations might find themselves in the need for some sort of unique security capability or a service that goes beyond via capabilities of their existing stack. Often this comes up during various types of digital transformation. And so obviously digital transformation is a really broad topic. So you could read that as like security transformation, security consolidation, introducing new types of business models or security services or things like that. Let's walk through a few possible examples. So often when you are thinking about things from an architectural perspective, you might find that if you are launching a new technology or introducing a new security service or migrating some sort of data or workloads onto a new cloud, that suddenly a piece of your infrastructure doesn't necessarily work with that new technology or security services or cloud. This is obviously a problem because you don't want to just, you know, often buy something new out of the blue, but you also just can't, like, deprecate that thing or let that gap, whether it's a visibility gap or a policy gap, go unattended. Another common reason why this tends to happen is for regulatory reasons. So maybe, again, you're onboarding a new technology, onboarding a new security service or a new cloud or a new multiple selections of clouds, and you find that suddenly the data that you already are working with, that's customer data or corporate data, can't go into one of those things for regulatory reasons. I'll give an example of that in a second, but this is something that we know a lot of organizations, whether they're in a very regulated industry, whether they're operating in certain regions or even expanding into certain regions tend to run into these sort of situations. So other situations still can be policy based. So maybe you are again onboarding a new security service or implementing a new type of technology that demands a certain level of policy granularity. But unfortunately, the security service just isn't technically capable of enforcing that. Or maybe, this new technology that you're implementing demands, like I said, a type of policy that your existing security stack just can't enforce, and you don't necessarily just wanna turn around and spend a bunch of money buying an entirely new stack or an entirely new service if you're otherwise happy with, you know, the service you're using. Or maybe even all of the available service or security services that you're finding aren't able to do that. So it's not a question of just that particular vendor, but it's like an overall market problem. And then a final common example of this is just organizational issues. Like you might find that there's a certain type of new, you know, technology that you're implementing, a new business model that you're implementing, a new, security need that is emerged in some way that just spans multiple teams who aren't really used to working together. So it's less of a question of like, can the security service technically do this thing and more of like, are the right people able to access it or are the right people willing to access it? Does it require too much coordination between teams that aren't just used to working together in that service or together in general? So again, these are just a variety of reasons, kind of general ones, but I'm sure a lot of you listening are finding some things to maybe grown or feel sympathetic about in terms of why you might need to be building some of your own or wish you could be building some of your own customized functionality. I do wanna dig into a couple of these examples in a little bit more detail, to again, add some color to this before we get to Indeed and Harshad's experience. So, and one really common example is that in a company that's trying to simplify its security stack to meet a smaller group of cloud native services. This is something we know a lot of organizations are planning, doing, or at least thinking about right now in order to save money, improve efficiency, and just kind of better align with a perhaps more cloud focused future. But the problem when you're doing this is that maybe, for example, some of these security services are based in specific countries by which I mean the infrastructure that they're running on, maybe be it that a cloud provider or an owned data center is based on a specific company. And then if you, as a company, you're operating in certain regions that might have data locality regulations that determine where logs or other types of metadata can be stored, then all of a sudden it becomes really hard to use this smaller set of security services that you really want to be using. So you have this situation where, in general, you are happy with the direction that your security stack is going in, but then you're kind of running into this obstacle, you know, two immovable forces meeting each other, and you don't really wanna have to make a compromise. So this is a situation where a lot of companies might be thinking, god, if only I could just, like, customize or, like, adapt the security use my security stack or certain services in order to give me more flexibility around where data, where metadata, where logs live. Just one example of many. Another possible example is around AI security. Now we know that, of course, a lot of organizations are you know, thinking and working on AI right now. And also, we know that because of that, it's hard to attend a security webinar right now without somebody mentioning AI at some point. But that is a really good example of this sort of challenge or need that we're talking about here. So one possible example of that could be that developer and web teams are just piloting a variety of customer facing AI services. Maybe they're rolling out more broadly some generative AI services and even starting to pilot some agentic services that are able to act more autonomously rather than generating output. But the problem here might be that securing and analyzing all the various types of traffic to these services demands kind of level of integration and threat intelligence that your existing security service just may not be able to provide. A lot of people who are experimenting or rolling out AI will know this already, but AI tends to attract different types of or newer types of traffic from perhaps unfamiliar places, can kind of strain at the capabilities of an otherwise very capable security stack. So again, this could be a situation when the organization might wish, God, I wish I could just adapt what I have, kind of build my own thing without having to go out and buy something entirely new. So with that, that's a really good time to bring in Harshad. He's a member of the security engineering team at Indeed, and he faced, among other situations, this exact sort of example. So he was able to come up with some really, you know, unique and and kind of homegrown solutions to this in a very integrated way. So with that, yeah, Harshal, come on in. Hey. Hi. How are you? Good. How are you? Well, look. Thank you so much for joining us today. Maybe just to start us off, could you really quickly introduce, tell maybe tell us a little bit about Indeed as an organization and then a little bit about what your role is there. Yeah, sure. Happy to start there. So, is world's number one job site and our core mission is simple. We help people get jobs. That's basically the mission statement which resonated me back in the day when I was looking for the job and it even resonates with me now. Now, have been with Indeed for almost a decade now. I started as one of the core network engineers in Indeed and moved into engineering leadership and today I work as a senior infrastructure security engineer focused on zero trust and platform security. My work today basically sits at the intersection of access identity platform and emerging AI driven workflows. So, that mindset of engineering and business, I think that's something which I go by. So, I still think like an engineer, but I think that business lens adoption, cost and operational impact, that's something which has basically shaped my overall journey in security engineering today. So, yeah, that's basically my role at Indeed at this point. Well, awesome. Thank you most so much for that context. And I love how you said that you were trying to be a kind of a security leader who thinks like an engineer. I think we'll see some really good examples of that in just a sec. You know, I think that this like I said, there's a lot of reasons why companies might find themselves with the need to kind of customize or build on some of their existing security functionality. But I think when we were talking before, you said that one of the the the big reason why you find yourself in that situation had to do with AI. So, just for context setting, could you tell us a little bit about where Indeed is at in its own AI journey? Sure. So, Indeed, very much, I think it's out there in the world, we are AI first company. But the most important thing for us in our AI journey is we are centered around helping people but not replacing them. So, by combining the power of AI with like, you know, over two decades of hiring expertise, Indeed is basically transforming the job industry by making the hiring process simpler and faster. So, the way we use AI is to make hiring faster and more effective. So, that would basically mean better matching, less repetitive work, smoother workflows, things like that. But at that same time responsible AI is a big focus for us. That's where the security engineering comes in. So, we have basically built in the guardrails, transparency and human oversight. It's the philosophy where like you don't just deploy and walk away from it. It's something you keep on refining as both the technology and the risk evolves and that balance is really something which really matters in Indeed at this point. So, I would say the right AI strategy for Indeed is just not about speed and scale, but it's about overall making sure that we are enabling human connection when we are matching job seekers with employers at that point. Okay, awesome. I mean, sounds like a really exciting and a very intense process at the same time, I'm sure. Like you mentioned AI guardrails. That's something we're hearing from a lot of companies right now. So it totally makes sense that you'd be thinking about that as well. I do wanna get into the technology side of that in a little bit, but I think, you know, I mentioned earlier the organizational side. I know you said that there was some relevance to Indeed's experience too. So, like, specifically, we hear that, especially in some larger kind of enterprise companies, that it's possible for the various teams who are responsible for building and implementing and securing AI, to kind of get siloed sometimes. So, was there ever a point at which Indeed was dealing with that? Yeah. I think that's honestly a very real risk. I think any large organizations in general. So, what I have seen and I think everyone will kind of resonate with this is like AI teams tend to move really fast and experiment a lot, right? And security transformation is more like methodical and it needs to move in a very systematic way. So, if like both parts are not aligned and if you drift apart, will either slow down the innovation or you will create blind spots. So, what really happen helps, I feel in this situations for large organizations is like you should be bringing security thinking in the design stage itself and not basically adding it later. I think that cross team collaboration, I feel is very important when you are trying to adopt AI at like, you know, light speed. So, lot of, as I said, like a lot of my independent research prototypes actually came from studying what was really happening in the broader ecosystem, not just within India but even in like the larger organizations which are like, you know, adopting AI at a huge scale. So, what I actually saw like was like a pattern where like, you know, new recurrences and access patterns were emerging and I realized that you know how like to meet these patterns in zero trust environments. It's very important that defenders need to start adapting to the situations and start building something more passive rather than you know more reactive. So, that you don't slow down the innovations. I can share a little bit about that in a moment, but in a principle way or like in a nutshell, I would say security shouldn't be your last reviewer. They should be someone you should be involving as your early design partner in the org. If you don't want to get siloed like the broader scheme of things. Yeah, think that's so well said. I mean, think that's such a good recommendation in terms of just how to of bring the security thinking into the design stage. But I also think you made such a good point about why those silos can come up. It's not just people being irresponsible or bad at their jobs. It is kind of more of like a structural philosophical problem where you have one group of people who's incentivized to move fast and the other that's kind of incentivized to move slow. And I think that can definitely be reflected in like how the tools and systems kind of work together or don't sometimes. So, you know, yeah, I mean, you you mentioned the technology and I think this might be a good time to bring up that because, you know, the the sort of situation describing, I think matches really closely some of those types of examples that I was mentioning earlier. A situation where you have, a business need to move fast and roll out AI, but then some problems are emerging maybe, or some needs or traffic patterns, I guess, your case are emerging that the existing stack isn't really set up to to to handle necessarily. And so, you did a great job of kind of building a custom solution. So could you tell us a little bit about, like, some of the tools that you built? I guess, specifically, like, you know, what was the specific problem? And then, you know, how did you go about kind of creating your own solution for that? I think, yeah, I'm really happy to kind of talk about that. I think Cloudflare kind of played a huge role over there. So just to kind of set some context, basically I can kind of talk about more like the independent research prototypes, not specific company implementations. So, that anyone out there can actually experiment with them and these are basically the projects which I build on Cloudflare Workers to explore the emerging AI patterns which I was seeing out in like, you know, out in the wild and how can you start experimenting with it like more in a safe and a controlled way. And I think Cloudflare Workers played like a huge role in that. So, the first project in that domain was like an MCP Threat Trap, which is now evolved into an incubator. But origin of MCP Threat Trap was actually pretty organic. I was seeing developers were experimenting with MCP style connectivity and the usage was exploding in the ecosystem as well as it within my org. And then being the part of platform security that immediately kind of caught my attention and especially from the deception engineering lens. Now, deception engineering is something which is like very old practice, but it's a very powerful practice and you have to be very careful when you are implementing Deception Engineering because you can get into trouble if you don't implement it, right? Because you might reveal blind spots to the attackers which might not be visible before. So, what I kept noticing with this MCP style interactions and as AI security was evolving was enterprises were wiring AI agents and this tool based interactions into their workflows and then defenders like me like, you know, were like buried in noise with the sea of logs and huge volumes of telemetry which was basically not giving any meaningful early signals. So, a lot of this reconnaissance style behavior could easily blend in and go undetected. That's where the idea actually clicked of instead of trying to detect this bad behavior in a later stage of an attack flow. Why don't I build something which is more passive and it could detect the intent of this agent early on. So, that's how the birth of MCP Threat Trap happened. So, the concept was simple over here. Instead of basically blocking attackers, what you do is you give them realistic but fake surfaces to interact with, believable tools, helper functions, credential artifacts very similar to what you would be actually doing in your real environments but having it on the workers at the edge that just keeps it more isolated at that point. So, if agent or actor touches them, you kind of get a very high confidence low noise signal at that point and that early signal is a real advantage for security teams like us because then it kind of gives you that early signal where you can start investigating and make real progress at that point. What I want to say basically around this is like that intent the patterns which were like emerging from that intent, right? So, recon looks very different than human recon and that's basically an emerging attack pattern which was like which was very easy to kind of get that from the worker at the edge and you could start gathering that Intel and start feeding it into your SIMs basically to get that early telemetry. Now, a very interesting fact, the inspiration I think came from I think Cloudflare early roots as well. So, Cloudflare actually had a honeypot style research with project honeypot. So, building deception experiments with workers, it seemed like a very natural fitting platform for experimenting with agentic deception. I think that's where like Cloudflare worker played like a huge role in the compatibility of the solution and making that experimentation really easy for me early on. Yeah, go ahead. No, that's great. I mean, just for if anyone who's listening or watching isn't familiar with cloud their workers. That's our serverless development platform. That's part of the broader top or developer platform. And you know, Harshad mentioned that if you can essentially build and run run serverless functions that run at the edge. Yeah, I just wanted to, I guess, clarify on that quickly. I mean, Harshad, so I think it's obviously, you know, I kind of have a reason for saying this, but I do think it's cool that you were able to be, you know, running some of the security services and building entirely new tools kind of in the same place. Like, what was the experience of building that actually like from a development perspective? I think it was really humbling and exciting as well for me. I had kind of started learning about the remote MCP servers. It was a really interesting way of like, you know, integrating that into the workers. Now security as I said is a very broad field and many times you are kind of restricted to experiment only within certain domains, which is understandable, but it actually slows down the rapid prototyping. I think even the second project as I said like this MCP Thread Trap led me to look at like a very different project later on which was like a FlareGuard Edge, which again I build on the workers and it's basically a generic YAML baselines that actually evaluates your findings against the Cloudflare configuration patterns and it helps you map those expectations with like the frameworks like NIST. So, the goal of this project was to map and control coverage across zero trust fleet. So, teams can actually be prepared for future AI and security audits. Now, from the building process point of view, right? I mean, you are always going to run into these obstacles and things where like, you know, rapid prototyping is something which becomes a challenge for you. But with the worker nodes, I think it became very easy for me to start experimenting with it. What helped me was like the feedback I was getting early on that was very easy for me to incorporate as I was rapid prototyping. And the second thing, the biggest lesson was like you don't have to over engineer your solution on the day one. When you're building tools like this, custom tools like this, it's very easy for you to get into a rabbit hole of trying to get to the perfection, but that actually slows down what you're trying to do. So, I would say like, you know, getting that early signals of like validating quickly and then taking that real behavior and feedback can be really helpful for someone who is building something customized for their environments and having the tools which don't kind of come from the you know, come with like the traditional security mindset basically. Yeah, that's I mean, I love that advice because I think it's not necessarily every single person who would have either the experience or motivation like you do to kind of bridge the gap between these different disciplines like that. So I think that's really cool. I guess I am wondering also, you know, because is there any advice that maybe you would give security and engine leaders? I guess particularly security leaders who want to be kind of fostering this type of innovation and cost collaboration on in their own teams? Yeah, I think that's like I really like that question. So, my biggest advice would be very simple create the space for experimentation. Now, small proof of concepts can I feel like an unlock big ideas and can turn into huge proof of values? You don't need to actually have perfection on day one as I said, let the teams explore, test and learn as they go. I think indeed hackathons kind of helped me a lot in this scenario. That actually helped me broke a lot of silos as we were talking before and sparked a lot of my creative solutions. When I feel like when people are given the freedom and the trust, innovation shows up naturally at that point and honestly, would say like, you know, a big part of this comes down from the leadership culture in Indeed. When leaders actively support experimentation with and cross team building with like, you know, projects like hackathons and cross team collaboration, the work starts becoming more like, you know, organic. It starts feeling like the experimentation starts like, you know, accelerating and that's when I feel the best outcomes come from. So, that would be my advice for someone who is like really experimenting with such things in the org. Awesome. And then maybe from a technological perspective, you know, we've been talking again about this use case of like securing AI, this kind of bridging some of these traditional boundaries in this in security and engineering. Like, was there any benefit and like what benefits did you get from kind of having some of the existing security services and then that developer platform kind of intertwined and working together? I think, for me, I was like an SME for the zero trust SASE side of the things. So, when I was actually like learning about this developer platform series, I think Cloudflare has a lot of suite of products. So, when you start experimenting with these things, that business mindset of like how you can tie down these technologies together that kind of played like a huge role in coming up with these solutions. Because now you are not just thinking in one ecosystem, but you are thinking from like a broader security aspect of like what are the gaps you see in the larger scheme of things and how can you start you know, tying those things down into a whole workflow to build like an end to end solution, which basically can help you catch, like, you know, catch the intent early on in like the AI driven workflows. Yeah. I think that's such a good point about looking at it kind of from the perspective of the business rather than the perspective of the technology or the security stack. I know that that's something that we've certainly heard not all over because it's a, I think, relatively advanced and innovative mindset, frankly. But I do think that's really cool and kind of yeah. It's just really resonating when you talk about thinking about it from the perspective of the business and the kind of ultimate experience of how the technology fits together rather than just in terms of what existing capabilities you have. So I think that's a really good point. So you mentioned a couple of these custom tools that you've built. How have they been working? What's been the result of those being implemented now? Is there anything we learned from them? Yeah, I think that's like a great question again and I want to be very transparent over here. We are still in like a pre production state, but like the early testing has been really encouraging. So, what I've realized is like when you have control setups like this, right? You start seeing the behaviors and interaction patterns that traditional tools just don't show you. So, I think the MCP Thread trap as I told you it's kind of turning into incubator and that is built on the MCP server portal which is again a Cloudflare like technology for the MCP gateway style of pattern. So, when you start experimenting with tools like this, it kind of gives you a way of like you know some emerging technologies which are still not out there at this point and running this deception based experiments within that portal environment has given me some early bird threat intel signals which basically were not there before and were not reported before on like external threat feeds like virus total and abuse IPTV. So, you start seeing patterns of like, you know, emerging AI agents who are using new attack vectors and that's something you can actually like that is the information which you can start gathering and giving it to your business to create a business case for making this like go big in a huge way. So awesome. I mean, that sounds really exciting. I look forward to hearing what else you learned from this down the road. But before I let you go, is there anything else you want to add? Any, you know, other like details that you feel like people might want to know about some of the stuff or any other lessons that you just have taken away from this whole experience of kind of building your own custom security stack? I think the biggest lesson for me is like always look out for the education which is kind of out there because like, you know, there are more smarter people around you who are building cool things and how you can actually take that as an inspiration and motivation to build something of your own. I think that would be a huge takeaway for me. I've been like in a very active reader around like what's happening in the Cloudflare ecosystem as well as like other ecosystems and using that to build something more custom your stepping stone to get into building something like this for your own org. Awesome. Harshad, thank you so much for sharing all of this. I am very excited to see what else you build and the results of all of this. I'm sure a lot of other people are too. So hope to have you back some here back here sometime soon to kind of show us what else you've been able to come up with. Yeah, no, thanks Martin. Thanks for having me over here. Awesome. Okay. Wow, I learned a lot from that. I don't want to take up too much more of your time, but I just want to share a little bit of kind of closing thoughts on maybe the technological side of this, because obviously a big part of being able to accomplish what Harshad accomplished. It comes from having a person like him who has that kind of kind of cross functional and cross collaborative mindset and has the right resources and knowledge to be able to kind of tackle that problem, think about it in a broader way. And also, like he said, having kind of a supportive environment, all very, very important for the ability to kind of build out some of your own tools. But there is obviously a technological side of this as well. He was talking about it a little bit, and we have perspective on that. And it kind of starts with our platform, which we call a connectivity cloud, though the name doesn't really matter. But essentially, it's this unified platform of connectivity and security and developer services that are all powered by a single programmable global network. You know, when I talk about that kind of variety of services, I really do mean a very wide variety of services. Don't worry, won't read every single thing listed here, but I just kinda wanna make the point that this connectivity cloud, this platform, unites a bunch of these disparate services together that have traditionally existed in different parts of the stack, you know, ranging from SASE and Workpaces security to app and API security and app kind of delivery and performance developer services, which Harshad was talking about a lot obviously, and even some kind of cloud networking and hybrid networking services. So this is just one example of what happens if you combine some of these SASE and workspace based security things with some of these developer services, in in kind of unique ways to to to meet really unique use cases. And I think that's really possible if you only have, like only possible if you have all of these different things kind of living and running in the same platform. Of course, it's not just about having the right services in one place itself, but kind of how you're able to use them. And one really important aspect of our platform, that connectivity cloud, is the ability to customize those services for really a variety of use cases. Harshal talked a lot about being able to use Cloudflare Workers, which is again our service development platform to let you run serverless code that runs in the same network, the same servers, the same data centers that all of those security services are running in, which allows you to kind of, like you heard from him, customize those services, customize policy enforcement, customize kind of process workflows and reporting and logging, or even build your entirely own new services all in the same platform, all running on the same network. But it doesn't even just stop there. You know, we let you use your own, keep your existing IP range, which kind of again unlock some interesting customization options. And then we also allow you to to limit data processing and logging to very specific countries, regions, even specific data centers and regions, which is another common reason that I talked about before, why a lot of companies may know reason why they might wanna be customizing some of their security functionality. And then of course, it's really helpful to be able to manage all of this from the same place, from that kind of single pane of glass that people often are striving for. So Cloudfloods, you manage all of this, all of those services, all of that kind of customization functionality, either from across your entire digital environment of workspaces, apps, network infrastructure, clouds, etcetera, etcetera, AI services, certainly all from either a single UI or from a single API if you want to be managing some of this stuff in an existing kind of development pipeline or deployment pipeline. So again, not just about being able to have all of those services in one place, not just about being able to on a single network, not just about being able to customize, adapt them to those kind of unique use cases, but also the ability to have all these different teams, all these different people seeing it all in one place. I wanna quickly wrap up just with a couple of other examples. Neither is gonna be nearly as illustrative as what Harshad said, but Carrefour, which is a really large retailer operating in Europe and elsewhere, uses some of the same development, serverless development functionality that Harshad was talking about to write custom scripts that allow them to automatically implement security protections whenever they push out a new website or a new webpage or a new application. Common situation, if you have developers who are innovating really quickly, they aren't always thinking about or aren't always incentivized to think about how can I make sure that I am implementing consistent security protections in front of everything I'm building? But if you're able to write that own custom script, you know, build that own kind of serverless function that automatically implements some some of those serverless some some of those security services whenever that new feature is rolled out, kind of gets rid of that debate between speed of innovation and thoroughness of security. So that's just one example. Another example kind of more on the data locality side is from Doctor. Lib. They are a large and rapidly growing e health organization based in France. Obviously, you know, being based in France and operating in multiple companies in Europe, they're subject to the GDPR, which has very, you know, stringent requirements about where data or where customer data, where metadata is allowed to live. And so they use some of our customization features around data locality, the data location, the data localization suite specifically to allow them to make sure that certain Cloudflare functionality is only happening like traffic inspection, like decryption, is only happening in specific regions in Europe rather than globally, which would, you know, contravene the some of those GDPR requirements. So just another example of how organizations are using Cloudflare to customize security functionality without having to either limit the choices they have or go out and buy some new complicated thing. I wanna close quickly just with a couple of resources. We'll follow-up with these as well. So you'll be able to get the links here. But just, you know, some resources to learn more about modernizing apps with cloud flare, which talks about some of this custom gets in some of these issues with customization. And then also would encourage you to learn more about the conflict developer platform, which allows you to build all of the sort of things that Harshad was talking about. All the sort of other examples you've seen here and kind of whatever comes to mind. So with that, I just want to thank again Harshad so much for sharing his time with us and his advice with us and his experience with us. Thank all of you for, you know, listening. Hopefully you've learned something and hopefully we'll see you again soon. Thanks so much.