[0:14] Welcome everyone to our webinar, “Building Security In: The Journey to Secure by Design in a Dynamic AppSec World.” Before we get started, a quick privacy notice: as this webinar may involve the sharing of sensitive information, we kindly ask all participants to respect the confidentiality of the information presented. Please do not record,...
[0:14] Welcome everyone to our webinar, “Building Security In: The Journey to Secure by Design in a Dynamic AppSec World.” Before we get started, a quick privacy notice: as this webinar may involve the sharing of sensitive information, we kindly ask all participants to respect the confidentiality of the information presented. Please do not record, distribute, or use any part of this webinar without explicit permission from the organizers and presenters. My name is Boaz Barzel, I’m the field CTO at OX Security, and we are fortunate to have a panel of industry experts with us today: Vikram, Lakshmi, and Curtis, who will introduce themselves later. They all bring diverse perspectives on what it means to build security in and the journey to make it successful.
[1:22] Let’s get real. Security is everyone’s responsibility, but in practice it sometimes seems like it’s nobody’s responsibility, especially when developers want to code fast, security teams want zero risk, and leadership wants the next release shipped yesterday. So today we’re going to challenge the status quo. We’ll ask hard questions: can security ever be truly built in, or is it just a checkbox we slap on the SDLC to feel better? “Secure by design” sounds great on paper, but reality looks very different. Breaches caused by application vulnerabilities still dominate the headlines, because despite all the tools, processes, and best intentions, security is usually seen as a blocker, not an enabler. Our discussion today will cut through the fluff and get to the heart of the matter. We’ll explore cultural tensions, process pitfalls, inconvenient truths, and the tools we rely on, and most importantly we’ll ask: are we really addressing the evolving threat landscape, or just running in circles? We’ll talk about culture and accountability, tooling versus talent, and threat-landscape myths, and we’ll take your questions live, so please write them in the Q&A. Now I’m excited to get our panelists to introduce themselves. Vikram, let’s start with you.
[3:41] Thank you, Boaz, and thank you for the invitation. I’m Vikram Barate, based in Pune, India, and I work as VP of engineering at GS Lab | GAVS, which provides product engineering services targeted toward the high-tech technology industry. I come from an engineering background, from development into product engineering and releases, specifically in the domain of telecom, networking, and network security. I’ve worked on product lines including page firewalls, SOHO firewalls, IPS/IDS, signaling firewalls in complex infrastructure, as well as network security including pipeline security using encryption and authentication technologies. That’s my background in short.
[4:40] Fantastic, thank you very much, Vikram. Lakshmi, over to you.
[4:45] Thank you, Boaz. Good morning, good evening everyone. I’m Lakshmi. I represent an organization called Intellect Design Arena, though I’m here in my personal capacity, and I’ll share my experience from the industry. I have more than two decades of experience in information security. Currently I’m VP and CISO for Intellect Design Arena, a fintech organization based in India and headquartered in Chennai. We’re a global product organization servicing larger banks and insurance sectors.
[5:28] Thank you very much. And Curtis, over to you.
[5:36] Hey, good afternoon. Thanks Boaz, and thanks to my fellow presenters and everyone listening. I’m Curtis. I’ve been in security for a little over 20 years, doing everything from high-tech to banking and insurance, open source, and even a little startup here and there. I’m currently the head of application security for Gen Digital, and I’ll be surprised if you’ve heard of us; most people haven’t. I like to describe us as the alphabet of security companies, because you’ve heard of our products: Norton, Norton LifeLock, Avast, AVG, and CCleaner are our biggest. My job is to make sure that every product we put out, every backend service, every bit of connecting software, is as secure as we can possibly make it, to deliver on our promise to keep our customers secure. I’m an American who happens to live in Amsterdam, one of those weird expat people.
[6:43] Let’s start talking about whether security is a blame game between developers, security, and leadership. Lakshmi, let’s start with you. Developers are often unfairly blamed for security issues; is it their responsibility to fix vulnerabilities in their code?
[7:13] Boaz, in your introduction you mentioned security is a shared responsibility, so there can’t be one single answer. Management will always expect developers to get it right the first time; it’s a question of quality and productivity. That said, there are multiple factors that contribute to a developer’s success. Fundamentally, the cultural fabric of the organization is an essential element, and more importantly, what is their awareness level, are they adequately equipped to deliver in a secure way? Another important contribution is the support system available to them: a security champion, a security team, or a go-to person who can guide them whenever they’re stuck on their development journey. In a less process-centric organization, security discovery tends to happen at the back end of a project, or even once the system goes live. That’s where people look for a single role player who can be given accountability. It has to be fixed whether we like it or not, and the developer does have a share to take on their shoulders.
[9:13] Exactly. And this is important, because when we talk about shift-left, it can become a mantra where we dump responsibility and accountability onto developers without always giving them proper support. Curtis, I’d like to hear from you: is it really just a mantra, or is there something else you’ve been doing within your company that gives them proper support?
[9:51] If shift-left is a mantra, then it’s a failed mantra, because the idea of shift-left isn’t just that something is being done, it’s that it’s being done early. This is where it ties into what you’re asking: it shouldn’t be a blame game. Developers, in my opinion, do bear responsibility for the code they write; we as security practitioners bear the responsibility for informing them how that code performs. Shift-left done correctly is about giving developers information early, so they can address the problem when it’s easiest and cheapest to deal with. When I talk about this with our development teams, I’m usually talking about how I give them the best information I can, as early as I can, in the IDE, every time they check in code, and every time they build. The other part of shift-left is a serious conversation about quality bars, so everyone is on the same page about what they need to do to move forward in the pipeline. Shift-left is really about setting it in security practitioners’ minds that we need to be a partner with the development organization, doing it early and often, and giving them high-quality information so they can decide: do I write this new feature now, or fix this security issue? If security issues are properly communicated and prioritized, development teams have plenty of time to make those decisions and ship high-quality software.
[11:40] Vikram, what’s your recommendation? How do organizations balance the pressure between delivery and security practices?
[11:52] That’s a long-time challenge almost everyone has faced. In the product engineering life cycle, security issues are often not given much weight because they don’t contribute much visible impact. If you’re delayed on a feature delivery, that has a visible, immediate impact, whereas security features don’t give that visible impact at the engineering stage, so there’s a struggle. But there are very standard practices defined for security, principles for secure by design that need to be followed, and tools already available, so you don’t have to spend a lot of effort to get the right implementation. To give basic examples: use the right coding language, like the latest version of C++ which has a lot of vulnerabilities already handled, the right version of open source, the right tools available in the market. The right seriousness about using those needs to be there. To date, security is considered a non-functional requirement, so I’d say it needs to be converted into a functional requirement, and only then will it be taken seriously. Having it as a functional requirement can make a big difference compared to treating it as non-functional.
[14:05] That’s very good. And one point that becomes clear is that if we want to make it functional and ensure we have developers’ attention, getting KPIs or measurements that everyone shares is key, so we’re not looking at separate developer, security, and business measurements that are all different. One way I’ve found from working with many customers is the same measurement: everybody is measured on the same thing, and once we measure the same thing, we create a shared language, shared accountability, and we all work toward the same goal rather than each team toward different goals.
[14:51] Adding to that, one of the other ways to think about it is as a quality metric. The reality is, lots of teams want security to be an add-on, or it ends up being late. But if we think about it as a quality metric and how it affects the package and product we’re putting out, it becomes easier to sell internally. If I’ve got a race condition in my software package, I’ve got a performance problem, but it’s also a security issue. If someone can subvert part of the system in an authentication problem, that’s also a quality problem, because user data is put at risk. So if we can speak the language of quality with teams, speak the language they’re in, maybe that’s a functional requirement, maybe not, I think we get a better foothold for that discussion.
[15:48] Exactly. Lakshmi, what do you think are the biggest cultural challenges getting in the way, beyond the metric you just talked about?
[16:06] From a cultural perspective, it’s very important that the team gets the required support from management: arrangements around timelines, tools, education, and empowerment, all of these are the cultural fabric. On the blame game where developers take the larger share for security issues, the significant contributors are organizational culture and how it influences them. In most cases, it’s either because of a very stringent timeline they’re expected to deliver in, or a lack of awareness, not letting them know the actual baseline, or not giving the right priority and weight to security adoption. At times it’s seen as an overhead by the team. So culturally, these things need to come together, and the more stakeholders, the more coordination it requires. My take is: set the baselines, give clarity to people, equip them with the right frameworks, guidelines, and tool sets, give them the right time to work on these things, and have expert intervention whenever needed. Once you have this kind of fabric, the cultural adoption follows and the outcomes become much more certain.
[18:08] Curtis, a bit about the tools. You mentioned Norton, Avast, CCleaner. Do you think we’re spending too much on tools and not enough on training developers how to write secure code?
[18:25] I think that depends on the organization; they’re two sides of the same coin. My application security team actually owns both at Gen. We don’t just own tools, we own the security training, and I position us as trusted advisers to the engineering and CTO organizations, so they can come to us and ask questions. We also run the bug bounty program, which gives us a really good all-around view of what we’re doing and how it’s working. If you’re not using that information to create training, you’re missing out on some of the best parts of the tools you’ve got. I’m a big fan of saying, hey, here’s a great thing we saw out of our bug bounty program, let’s talk about it at a brown bag with our developers, because there’s a good chance it isn’t isolated. Or we can take the data out of our SAST tool, see the most common written vulnerability, and have pointed training to help teams avoid it. So those two things go hand in hand, and when done well they become a pair that accelerates what you’re doing in security.
[19:46] Vikram, how do you ensure security tools provide insights without overburdening developers?
[19:57] The main purpose of getting security tools in place is to report the overall vulnerabilities found in the project, the code, and the design. But the tools’ output is mixed: some is relevant, some may not be, some is critical, some is generic, and developers get pushed through all of it. The right approach is to identify the right threats being reported and address those, much like we report the critical, relevant bugs for the application. Just running a generalized tool, getting a report, and asking developers to fix everything isn’t enough. If you can make customized threat models for the application being developed and design the tools to work that way, it gives a better impact. Many times issues are reported but developers aren’t aware of the threat models or the impact, so if alongside the issue you report exactly what to fix, developers are more willing to accept it; they won’t see it as just something to fix, they’ll see it as a feature or a critical bug to fix, and how to fix it. These tools and their output should be used as a training ground for developers to learn the security threat models.
[21:49] That’s fantastic feedback. I’d like to connect this into the triangle of people, process, and technology. On people, we have developers and security teams; on technology, every team uses a different set of tools, so we also need to talk about how we connect between them from a process perspective. As you mentioned, threat modeling is something we usually hear is just what security teams do. When we talk about secure by design, we need to understand the role of threat modeling and how we make it more approachable to developers. Lakshmi, share a little from your experience.
[22:47] Threat modeling is a very important aspect, though the concept has existed for two-plus decades. In the SDLC, a proper threat model, using the right methodologies and tool sets, can give significant value to the whole ecosystem. The first and foremost aspect is deriving the possible attack surfaces. The moment you’re aware of the appropriate attack surface, it uncovers your blind spots and helps you plan better from a countermeasure perspective, whether within the code, with complementary tool stacks, or additional security components added as a tier in your deployment architecture. Most importantly, threat modeling gives clarity to people and brings a lot of alignment, so teams can look at security needs better and early in the SDLC. It derives a lot of value, especially when designing a larger system from scratch.
[24:26] May I add: when we talk of shift-left, we often stop at the requirement. If you look at it as a value chain, we need to go even further left. Developers get trained on security, how RSA works, how the handshake works, how authentication works, but they’re not getting trained on threat modeling, because how threat models work is knowledge that mostly resides with experts like Curtis and Lakshmi. When developers get trained on how to think in threat models, it gets ingrained across the whole engineering value chain.
[24:59] That’s true. I read something interesting, I don’t remember where, about a team that shifted left so much they started planning a year and a half before they even started development. This is also a way to start thinking ahead of time. If we’re planning a service or a new application and we know the content, from encryption to a web UI written in a specific language, or that we’ll process PII or sensitive information, we can start raising questions about where we’re going to deploy it and what other security measures are needed, even before we start developing. These areas are especially important because they help developers start thinking that way. If I’m deploying in the cloud, processing sensitive information, and using a database, then the database should be encrypted, and what type of encryption? You start thinking about what will be done and what the case will be. Now, Lakshmi, even as we do threat modeling and think ahead, we still have applications deployed with vulnerabilities, including critical ones. So how do you prioritize the vulnerabilities you have to deal with right now, especially when developers are constantly submitting new code and we need to release?
[27:19] Fundamentally, threat modeling is associated with design-level planning, whereas vulnerability management is associated with operations. Vulnerability management requires a lot of planning and has to integrate closely with standard processes: change management, patch management. As Vikram said, context is very important. There are many zero-days and critical advisories getting released, so there’s no need to panic for everything. It’s very important to associate the vulnerability with the context of our system, apply due diligence on how to prioritize, do impact analysis, and plan carefully. There’s a lot of coordination and project management involved, especially with system downtimes, approvals for moving between environments, and sanity checks. It’s very important that it’s a gated process with the required focus and the right stakeholders aligned, especially in a complex ecosystem like banks and larger industries.
[29:13] That raises an interesting point for both of you. What we’re getting at is that this is a unified thing; there’s a tendency to think of these security activities as siloed, but in well-run places they’re coordinated efforts that feed on each other. One area I’d point out: I really like to use threat models to look at how we affect other parts of our software build system. A threat model can say, here are things I need to think about at a design level, but it can also affect downstream things. You can say, I have this section of code I’m worried about from the threat model, and I have a good SAST tool that can address the threat I see here, great; there may be other threats it can’t, so hey red team, when you do your assessment, focus on this area because my tools don’t cover it well, or let’s write an automated test run regularly to make sure we’re implementing a security feature and haven’t reintroduced a bug. And lastly, if you’ve got a bug bounty program, you can give trusted testers a beta version and ask them to go after a particular section. When you think of it as a coordinated system, you get much better results. The danger at complex companies is thinking in silos; we have to get away from that and think of it as a super-connected system that feeds back to the different parts.
[31:15] The reason I said vulnerability management is more operational is because at the design level it’s more of a prototype, where you still have the option to bring in the right components and versions and remove obsolete elements known to be vulnerable. Of course, your point is very valid.
[31:42] I largely agree. Vulnerability management sometimes gets thought of as a secondary child to software development, but the reality is, once you release something you’re still responsible for it; you’re probably going to put out a new version unless you end-of-life it, which is a whole other problem in itself.
[32:04] The way I sometimes see it is like a funnel, like in sales. You do threat modeling and secure by design, and the better you do it at the top, the less comes into the funnel, which means your security tools and assessments become more accurate, because you’ve tackled the big issues and don’t have to redo them. Curtis, you talked about unification; what are the essential tools you see as most important in the CI/CD process, as you build and release the application and then move into vulnerability management?
[33:02] That varies a bit by market and sector; web development teams will have a very different focus than teams like me still doing a lot of client development. For me, the first and most essential thing is training, and I don’t just mean how to write a threat model or secure code, I mean what does our security pipeline look like? If your developers don’t understand how your security practices fit on top of what’s happening, you’ve missed a golden opportunity to have them input into it. There’s a great saying that the first weapon is the mind; if people aren’t trained to think and reason about it, they won’t do anything else. After that, I’m a big fan of SAST, DAST, and SCA tools because they give a vast amount of data, but that’s also the danger, they can give you too much data. So it’s important to understand the story you want to tell out of the system to help developers understand what’s happening, and you need to tune, care for, and feed all of those. After that, you get more complex, and complexity only comes with maturity; everyone wants to be a super-mature organization, but it takes time. The next most essential thing is to learn from what you’ve done, having a feedback loop that helps the organization understand where its next threat might be. So the essentials come down to the data I need, how I think about it, and how I learn from it.
[35:09] Vikram, where should we really focus our effort, as a recommendation to the people watching?
[35:39] This problem has been discussed for ages, yet there are basics that aren’t getting followed, and that’s where tools come in: if you’re not doing it, make the tool do it, and rely more on that. Now new tools are coming, like copilots, so we can tune these tools to rely on them more. These tools provide a vast amount of data and know a vast amount of vulnerabilities. If you’re breaching an open-source license unknowingly, the tool, with its large data, can immediately tell you something is wrong. These tools also come with plugins, and the best part of tools like these is that you can write your own plugin, so for the kind of application you’re building you can plug your own threat model into the copilot, and those will be taken care of during the development cycle. So more reliance on the upcoming technologies and tools, and more utilization of them, can definitely help.
[37:24] I really agree, not because I’m from a security company, but because as the industry constantly evolves there are new tools and new ways to attack year-old problems. If we had to deal with a Log4j today, it would take us a few minutes, whereas three or four years ago it took months. That advancement is a great point: as you build your people, process, and technology, constantly ensure you know what the latest technology can provide and how it can improve everything else. Let’s jump forward to two connected topics: compliance and AI. Lakshmi, are compliance frameworks actually improving security, or is it just an illusion, and where does AI come into play?
[38:36] I think it’s both. Whether compliance improves security or is an illusion depends on the organization: are we implementing the controls in spirit, or is it seen as a tick-in-the-box exercise? In many cases the interpretations are left to the implementers; there’s an overarching framework or guidance, but largely it’s not prescriptive. It’s up to the implementer and the context of the organization to do a thorough validation, and if done appropriately there’s certainly value, it improves the overall security posture and the intent of the compliance is truly achieved. On AI, it’s inevitable and everywhere. The AI-embedded element is something we’ll have to live with, and it’s a boon in a larger sense, eliminating time and effort, but we need to tread with caution. From a compliance standpoint, global and regional regulations around AI are coming up; in some parts of the world they’re already there, so industry is catching up. It’s rapidly evolving and will be a complementary factor for security professionals.
[41:09] Exactly. Compliance is a good baseline and a good way to compare security baselines between companies, but it’s definitely not something to rely on today. Curtis, is the industry overestimating the risk that AI or AI-driven attacks pose, or are we not there yet and shouldn’t worry too much?
[41:46] I think we’re just seeing the tip of the iceberg. Our threat intelligence team at Gen is very interested in what’s happening with generative AI, largely around the social engineering associated with it, because it lets attackers create much better attacks and use larger sources of information to trick users. A great example is what happened to the casinos in Vegas last year, and that was before generative AI: an American gang doing the language, a Russian gang doing the technology, and they used it very successfully to take down very large corporations and walk away with a lot of money. AI largely allows smaller organizations to do that much more successfully. When we look at it from an application security angle, the threat model changes: did we accidentally just put open-source software in our code? You get a great copilot, but what was it trained on, and when you asked a question, did it spit back a function literally from an open-source package? By copy-pasting, just like we all do from Google, if I let the AI do it directly, who’s overseeing that? Those are really interesting questions we don’t quite have answers to yet. But AI is here to stay; its ability to help people do their work faster and better is real, and if you don’t learn to use AI prompts effectively you’ll get left behind. We do need to be cognizant of what it means for organizations. Gen even has an experimental app called Genie designed to help people see if they’re being defrauded; you can put in a text or email and Genie tells you things about it. So we’re just at the beginning of something really interesting for the industry.
[44:12] That’s great. There’s something we like to use called “man in the middle,” where with all the feedback loops through AI, from training models to prompts to outputs, companies are starting to use that to validate they’re training on the right data and that prompts return valid answers rather than hallucinations. As we’re at the tip of the iceberg, we’re moving from a human in the middle to another AI that inspects the AI, learning and developing quickly, on both the attacking and defending side. I think we’ll see acceleration where the technology changes on a weekly basis, and we’ll probably use AI to catch up because we as humans won’t be able to do it ourselves.
[45:30] Like any new technology, there’s a lot we just don’t know. You can see that in the fun attacks you can do with AI; during the early parts of Genie, one of our guys got it to talk like a pirate, and the next thing we knew it was talking like a pirate to other people. There’s a lot going on with new technology, and I want to be cautious without being alarmist about how we deploy it. You can’t just throw an LLM at something and expect it to be great the first time.
[46:14] Vikram, do you want to add something?
[46:20] Just a small point. We work with multiple customers, and there’s a trend to force engineers to improve their productivity by a certain percent using AI tools and copilots. What I think is that AI tools can really help improve the efficiency of the code, not the productivity of the engineer. For example, identifying open source, finding the vulnerability at the right time, the effort saved that could later be very costly. If the real use of AI is in the effectiveness of the code being generated, that’s more valuable than how much time people save writing the code.
[47:18] Now I’d like to take a few questions from the audience. First: in each of your opinions, how early into a project or development does your security team get involved, and can you give an example?
[47:47] I think the earlier you can get a security team involved, the better. In my experience at Microsoft, at Gen, and where I am now, we get involved as early as “I have an idea.” We really value an open-door policy so people can throw ideas over the wall. We purposely sit our desks near the CTO organization so we can have those conversations: hey, we have this interesting idea, here’s how we think it can go wrong. A big part of that is understanding what the business wants to achieve. So get security involved early and often, make sure they know how to contact you, and be trusted partners to be effective.
[48:38] To add to what Curtis says: in our case, if it’s a product being developed and we’ve discussed threat modeling, the early blueprint stage is where things come together from a security perspective. If it’s more of a customer-centric delivery, it starts from requirements gathering through delivery and post-delivery support, with the security requirements integrated, and the role of a security champion is critical, integrated into all phases. As long as the stakeholders know the role play clearly, when to reach out and where to seek help, the program will be successful.
[49:40] That’s very good. We’re also seeing companies use security champions, and across different industries you want to get resources closer to the people working in the field, we sometimes call them focal points, someone who can be an immediate way to get an answer even though they’re not the expert, because they work closely with the experts. There’s another question, coming from the AI and machine learning topic: how do we make sure we’re using these technologies safely and not creating new problems while solving old ones?
[50:38] I think Curtis answered that well already. There are a lot of benefits, but we need to be careful; the technology is here to stay, so go with the flow, adopt it, but be careful. The same question came up in my team: a tool can tell you whether you’re breaching open source, and there are commercial tools that are very costly to do that, and now you can get it for free, but what’s the source behind it? We need to use the technologies but be a bit careful. Even when the technology is free, we rely a lot on open source, where the benefit is it’s open, we know what’s there, even the vulnerabilities are available to us. But this is more of a closed technology: it’s available to us, but what it’s using and what it’s pointed to is closed to us.
[52:05] I’d also add: experimentation is a good thing. There’s a reason we build prototypes and alphas. As mentioned earlier, if you’ve got a bug bounty, releasing early to them means they’ll know stuff you don’t; don’t expect to be the expert right away. But be cautious about what you hook it up to, don’t just take the latest LLM and hook it up to your customer database. Experiment, take time to get to know it, review the documentation on how to make an LLM hallucinate, try the “hack me” games out there, but be prepared for it to fail. It’s new, it’s not perfect, and we have a lot to learn.
[53:00] To add to Curtis: if it’s something we’re doing from a learning perspective, it’s very important what data we feed it, and if we can host those LLMs locally rather than leveraging SaaS-based LLMs, you’re covering the organization and the data set you’re using. Those guardrails are very important in adopting LLMs or AI models.
[53:44] Before we conclude, I’d like each of you to give one best practice or recommendation as people build security in. Lakshmi, let’s start with you.
[54:02] For me it’s about understanding the context of each role and how they contribute from a security perspective. If the KPI can be made very clear to all stakeholders early on, and you align them with best practices and enable them with the right documents, tools, and expert access, that’s the best thing. It’s not just about questioning them at a later stage, it’s about enabling them at the right time. If that’s done, it will always enrich the culture.
[54:53] Vikram?
[54:59] I’ll answer with an analogy. When we create highways, we create them with security in mind; we create cars with security in mind. Those are the tools available to you, all the practices are there with security in mind. But finally, it’s up to the driver how they drive the car, and that’s exactly where the training, culture, and enablement come in, the parts that came up a lot in our discussion. Those are the key things to make sure the right culture is already ingrained in engineers.
[55:46] Curtis?
[55:48] If I give anyone advice in security, the first thing you need to do is understand what your business wants to do. If you don’t understand the goals of the business or company, you’ll have a tough time swimming upstream. But if you understand what they’re trying to achieve, it lets you do two things: align your security program to the business goals to get supercharged, and understand the threats that matter to the business. You never want to walk in and tell them about something terribly scary that they just shrug at; if you can walk in and say, I have a threat that directly relates to this business outcome for the feature you’re building, they care about it a lot more. So get your mindset as a security practitioner into the mindset of the business.
[56:49] Fantastic advice. With this I want to extend a huge thank you to our panelists for the candid insight and fresh perspective. I know it will resonate with our audience, because today all companies experience complexity, no one is safe. When we look at building security in, helping from a cultural perspective, collaboration, and understanding that we’re all in this together, eventually every technology and process we create comes back to the people who take accountability and ownership. Today the status quo is challenging, and what we were here to do is challenge the status quo. So thank you, Lakshmi, Vikram, and Curtis. From secure by design and threat modeling to building innovative applications, we’re taking a step further into the future through AI and the technology we talked about, while making sure to watch ourselves. Thank you to all the audience listening. We look forward to hosting more discussions like this, so follow OX Security on LinkedIn and stay up to date with upcoming webinars. Thank you everyone, and let’s rock.
[57:53] Thank you, Boaz, really fun.
[57:58] Thank you Vikram and Lakshmi, it’s great meeting you. Thanks for moderating, Boaz, good interaction. Thank you.
