The Modern CTO Toolbox: Building Your SecOps RFP | SecOps Vision 2024

Hey everybody. Welcome to SecOps Vision. Been a great session today so far.

Uh, more to come. I'm here today to talk to you about completing your SecOps RFP. My name's Andi Mann.

I am from Sable, an independent analyst firm. And we're gonna be talking today about building your modern CTO toolbox. So look, this is gonna be a little bit dry.

I'm going through an RFP. It can't be super interesting every time, but we're gonna try and make it good for you. So let's get into it.

Um, so what I'm gonna be talking about today, you know, just quickly about me, um, I'm not gonna talk much about me. I'm a global technologist. Uh, I work with technology innovators and consumers.

I've got over 25 years, I wanna tell you how many years over 25 in enterprise technologies. Um, I've been ACTO of public company. I've worked out companies like Splunk, uh, ca, technologies, BMC before that with people like Exxon, Prudential, NatWest, where's pac?

Lots and lots of experience in the IT ops space. I'm now a global CTO and founder of Sable. Um, we'll talk about that later.

An independent analyst, firm advisor. Um, I just wanna point out, I'm not a cso, I'm not a Chief information security officer. I'm ACTO, I'm a chief Technology officer.

I have to cover the whole gamut, right? Um, I have written, reviewed and responded to thousands probably of RFPs. I put hundreds 'cause yeah, let's be conservative.

Uh, look, my pain is your gain. Uh, let's go through it. So the way I'm gonna present today is through this lens of an enterprise CTO, responding to an RFP.

We get these all the time, right? You've got a, a new client, a new customer, a new partner. Uh, you have to sign a new MSAA master services agreement with a new client.

Uh, there's all sorts of reasons we have to respond to the security section of an RFP. And sometimes it's tough to understand what it is and how to do it. Um, but what I'm gonna do is go through RFP statements.

I'm not gonna show you the whole RFP, I wouldn't, I wouldn't do that to you. Um, but we're gonna look at a sample at some, not all, not even close to all of certain SecOps requirements that I see in RFPs over and over again, and see how we can get to yes on some of that. Um, and deliver really safe and secure software without necessarily spending a lot of money, buying a lot of tools, doing a lot of training, changing a lot of process.

Um, so I'll look at some broad solution categories. Uh, I'll look at the role of policy. Really important.

We'll get to that and we'll resolve some of those RFP killers where you can't get to. Yes, we'll talk about that too. So let's get going.

Um, so let's start off with some sample clauses. This is what I'm gonna do for you today, is go through some of these sample clauses. Um, and so look, what, what do we got here?

Code quality service security. So we wanna have information security testing, right? We wanna have a framework.

This is an interesting one that pops up. Industry, good practice. There's a lot of English language words we'll have to interpret here.

Um, an accurate and thorough assessment of risk. Okay? That seems reasonable.

We can do that. Uh, code analysis. Oh my goodness, that sounds like tools, doesn't it?

Uh, vulnerability assessments, penetration tests. But now we've got some very specific requirements too, right? So the OSS top 10 SANS and sis top 25 vulnerabilities.

So we're doing scanning of code before release. Now, you know, is periodic penetration testing performed, you know, applications, servers, networks, the whole lot, uh, and network vulnerability scans with remediation. So don't just tell me do something about it.

So, you know, the bottom line here, I'm looking at a lot of policy change. I'm looking at release management policy. I'm looking at my risk management policy.

A lot of this is covered in policy assignments to your team. How do you work? What does your code look like?

What does it mean to release good code? You know, I'd start here at release because, you know, we all know that's where DevOps ends, right? Release into product.

No, uh, throw it over the wall. So I'm starting here because this is where SecOps starts releasing code, working with your development peers in a SecOps mode to make sure you're releasing good code, secure code. So yeah, there's stuff you can need to do here with policy release management policy, risk management policy, you know, things like, yeah, have a defined document, established security testing framework.

Framework does not have to be software. It can be a framework of policy. You've gotta enforce it and all that sort of stuff.

We'll talk about policy in depth a little later on. Um, but there's also actual tool stuff here. Pen testing.

You can do that through process procedure, you can do it through outsourcing. There's lots of way you can achieve a pen test. A lot of that's gonna be code-based code scanning.

You know, if you wanna extend, you get into this static and dynamic analysis, um, vulnerability scanning tools, um, at enterprise scale, you might get even further. So this is where I'm gonna try and take you through is how do you solve some of these problems? As I said, a lot of it's gonna be policy based, right?

Um, you'll get extended capabilities if you go further, you, you know, for a smaller organization for maybe a, a single site, maybe a, a small SaaS business policy and pen test is gonna be a pretty good answer. Uh, but you probably wanna do some actual work doing code scans, vulnerability assessments, code quality scanning, code security scanning. Um, so I'm not gonna endorse any brand names here, but you can guess some of the names that I'm thinking of.

You know, things like sonar q go in here, fortify. Um, but then you wanna see things like continuous testing if you're gonna go to enterprise grade, uh, uh, uh, a code and service quality if you are going to deliver at scale, ah, having this human stuff is really hard. It's not, you can't achieve it through policy, but you're gonna have a much better time at scale if you put really quality enterprise tools.

So they're continuing te continuous testing tools like tricentis or Source Labs, right? Uh, SCA software composition analysis, if you are using any open source tools. So you might wanna use like a black dark or something like that.

Um, um, in their, uh, sonotype for example. Um, you know, look, if you are really into this idea of watching your code release, chaos engineering feature flags, there's a lot of things you can do here to make sure you've got that well-defined documented process, uh, and a framework for secure code rulers. Okay?

So this is how I'm gonna try and take you through most of the rest. It's gonna be actually on SecOps. Let's go there, shall we?

So we need to protect access. Look, of course we do. Everyone knows we need to protect access, right?

You need authentication and authorization. Understand the difference. Authentication is who I am.

Authorization is what I'm allowed to do. These are actually different things. Um, you need unique access credentials.

Ensure they're not shared. This is pretty standard SecOps time stuff. It should be documented in your information security policy.

Uh, so here's where we get to some interesting stuff again, right? We must meet industry standard complexity and lifetime rules. Okay?

So to start with first, why I'm reading that we need to have rules, okay, that's fine. Password rules, complexity rules, you know, lowercase, uppercase, you know, these are not necessarily high security things. You can we in debate on password formats versus changing passwords versus password lockers versus tokens.

But, um, the other thing that I'm reading here is though these terms come up all the time, industry standard, what does that mean? So this is where you just need to look at people like NIST for example, and understand what their password guidelines are. Have a look at the NIST standards.

NIST have a whole lot of sample documentation around building and information security, policy building and access and authorization policy. There's some very positive documents. There's a lot of different organizations who can provide that.

SANS is another one by the way. Uh, providing these policy documents that help you understand what is industry standard mean, um, and other terms too, right? Principle of least privilege.

You will see this in RFPs all the time. Uh, it's related to zero trust. It's about this idea that you should only give people access to the systems they need when they need them, and no more than they need and take it away when they're done.

In actual fact, RFPs will say revoke or modify when they no longer need access. Could be when they're terminated or when they change departments. This is actually something you need to follow up in policy.

But I'll, I would also encourage automation. Um, I would also by the way, encourage cloud services. 'cause they'll take so much of this away from you.

I'll talk about that. Um, if a password has been compromised, we have to change it. That is absolutely a policy thing.

You know, you can do automatic password changing, but you can't ever really know in code if you suspect a password is compromised. This is something your people have to do. So this answering the SecOps RFP, you definitely have to come down with people and training and human management.

Uh, a a policy-based guidance as much as you do with tools, tools, you can achieve a lot of these guidelines with tools, but you need to have the human side manage it as well. Um, and you know, there will be technical requirements that you'll see in RFPs. You know, a federation against a trusted authentication store, multifactor authentication.

Here's another one, right? Complex password. Again, check out ni check out sans check out your local body, uh, your recommendation body, your standards body, your, your your computing society perhaps.

But what is a complex password? What is a standard in your industry? Because it does change across industries, by the way.

Um, so how do you answer all this? Look, it's, it's, again, we can do a lot of it in policy. We can't do all of it, but we can do a lot of in policy.

My recommendation to you, and this is what I did as ACTO at Kumu, is just use cloud services. Goodness gracious. Uh, so it's not always possible for everyone.

But if you can use cloud services for the majority of your internal work and internal IT systems, I'm talking about productivity, email, uh, uh, uh, uh, service desk, all of this sort of stuff. Um, if you can use cloud services, you are getting authentication, access management authorization levels, you are having that managed for you. And you get to tick that box on the RFP really easily.

I cannot tell you how positive it is to have cloud partners to do things like hosting your services, hosting your email, and your document sharing and collaboration site, hosting your chat and other things. Look, some of you don't have the choice, but if you have the choice cloud first, um, password policy. Again, I can't necessarily know if, uh, someone suspects their password is being leaked.

So I've gotta put this in policy and say, look, if you think this has happened, you are responsible for making the charge. Um, I'm gonna talk a little bit about settings. You know, look, I'm gonna say group policy.

I, the last time I put hands on keyboards as an IT support professional was probably 30 something years ago. And I say something, uh, then, uh, literally when I was doing it, everyone used one computer. I kid you not.

It was literally one computer. We shared it. Uh, nowadays, mostly Windows.

So I'm gonna talk about group policy. I know you can use cloud-based, uh, active directory services. People like, uh, JumpCloud, for example, managing settings across multiple platforms and systems.

I'll talk about group policy. I know it's a Windows thing, but there's equivalence in other areas where you can control access and authentication and user ID complex passwords. You can put in these settings and rules without necessarily needing additional expensive tooling.

Um, I will say though, once you get to a certain size and a certain complexity, you're going to want an identity access management solution. Um, and something a little bit more than just Windows active directory or, or LDAP server. Uh, you are go, you're going to want an actual system to manage user IDs and passwords and access and authentication at multiple levels in different groupings and so forth, right?

This is going to play into your idea of least privileged access or zero trust and get you to where you need to be to say yes. Um, when you get to a more advanced, or if the RFP demands it, and this is something we'll talk about this idea, you know, that your customers, your partners, your clients, others can demand your security. Yes, but also you can always say no.

So when they say you must have, uh, storage in an authenticated federated server, uh, maybe that's okay for you. Maybe you can't do that. But that's, you know, these are contracts.

You always can have a discussion. Don't forget that. Um, but you look, I would recommend you do things like single, single sign on, multi-factor.

This becomes really important when you get to remote work. And I'll tell, talk to a whole page on that in a moment. The idea that when you are in a remote situation, you need to have additional controls.

And one of them is physical multifactor. So something like a UB key for example. And I definitely believe in the self-service password reset.

Look, I think this is, this is triple value. This is meeting your policy requirements for individual users to be able to reset their password if they think it's been compromised. It's also delivering automation so that you can save time and money and not have humans involved in this manual password reset.

It's also a security and audit control because you can log who's resetting passwords, when and why. So look, an automated self-service password reset, in my mind, it's a no-brainer for pretty much any business. But certainly once you get to that enterprise scale, so, you know, we've gone onto authorization and now we need to manage these privileged users.

This is an extension of that same kind of technology and approach. It's just the more important user IDs in our environment. So for example, we'll see, we'll see requirements here like, uh, uh, restricting use of privileged access credentials, right?

Pretty straightforward, uh, prohibiting shared admin or super users, absolutely, uh, uh, appropriate authorization, right? For granting modify. It doesn't mean mean not everyone's an administrator.

Not everyone has ownership rights. Um, see more of this English language. You've gotta watch out for this strong controls.

What's a strong control? That's a challenge, right? So this is where you've gotta have a conversation with the people who wrote this document and try and understand what they're looking for and try and codify it or try and make a reference to a SANS or a NIST standard.

These are some things you can do. Um, but you've gotta have those controls over privileged system access. You've gotta attribute activities.

There's an audit control requirement and remove or rename defaults. So there's no admin password anymore, anywhere. This is all entirely reasonable.

Again, cloud and hosting services will help you with so much of this. Uh, you know, the idea that, uh, in a cloud service you can manage your users as individuals, but you are the administrator. This is a very standard way of work.

You do have to have a good access management policy. This has to be written down. People have to understand it, and you have to monitor and enforce it.

A lot of this is the sort of stuff that you can only do through policy. Ultimately, bad actors will do what they do. Uh, automation and tools will help you stop it.

But you need to focus on the human side and getting people to act positively with positive intent according to the policy that you have trained them on. And you'll get over a lot of this very easily if you have good policy in place. Again, group policy and settings are important and identity and access management.

But this is where we actually diverge a little bit from authentication and user normal, normal users in that we have privileged access management. This is the idea of fire call. Like when I was running the one computer, uh, we would literally, our fire call would be a password written down, you know, an envelope in the supervisor's desk.

We had to get the supervisor and the shift manager both keys. And that's how you got the super user password. If you wanna do troubleshooting in IT office, in prod, uh, again, one computer at the time.

So a very manageable system. When you get to enterprise scale today, it's thousands and thousands of individual systems each having super user and administrator accounts. So you really can't just manage this using policy.

Even with IAM systems, you really need A-P-U-P-M or a ppm, um, or for human to machine or machine to machine secrets management for crypto passwords, encryption keys, whole bunch of stuff. Now, speaking of which, what about machine to machine secrets? So this is why I said, you know, encryption keys, these are passwords that, uh, systems services use or passwords or, or, or, or key passes or rass, whatever.

It's that applications used to talk to each other within application, you know, by API to API I communication. So what we're saying here is key management lifecycle, right? What does that mean?

That doesn't necessarily mean a tool, does it? Again, we could have process here. This is about your access management policy.

Who gets access to when and why that doesn't necessarily apply only to humans. And this is a really important point for today's session. Part of the DevOps banter is this collaboration and communication.

We have to make sure that we're encoding these things early in the process so that when developers are creating code that gets put into prod as IT operations and security operations people, we have the right to go to them and say, Hey, you can't hard code that password. You can't have a, a unique crypto key. We have to manage that according to our process, our framework, maybe our tools.

This is where SecOps becomes real. Go to your development team and talk about the threat landscape. Talk about how you manage security keys.

Talk about the lifecycle of crypto man, crypto, you know, cryptographic key management and encode some of that. Look, you can do a lot of this in policy, right? It's even says it there formally documented.

It doesn't say it has to be instantiated in a tool. Um, you need to have individual custodians services and processes for management. So we're talking here, runbooks, do not underestimate the value of documentation in getting to yes on a difficult security requirement.

You'll always be relying on people to manage your important secure environments. Policy is critical. Tools will only take you so far.

Um, so look, we can do this. Here's another one we have to talk about segregation of duties. Look, I would always push back on this.

Now in a modern environment, I have remote workers, I have DevOps workers, my engineers are running code, my engineers are writing, testing, running. You build it, you run it right? So you can argue with Verna Vogels at Amazon.

Segregation of duties is a little anachronistic. We need to figure out ways we achieve the secure value of having trust but verify, which is what segregation of duties is really about. I can't put code into production after saying it's okay to go into production myself.

Someone else needs to help me there. So paired programming is a, you know, that's one way you look at segregation of duties in a modern context, in a cloud computing cloud native way, yes, you need some approvals, you need both, you know, more than one person to say, you know, new bank account in prod. I need someone else to approve that.

That's good, that's right. But you don't necessarily need tools and you don't necessarily need the traditional segregation of duties. Um, again, we've got the industry breast practice look for your standards bodies, um, managing and utilizing encryption keys, uh, deploying solutions to make sure the keys themselves are always encrypted and no one can discover what they are because you are encrypting them in rest and in transit.

Um, and you're only storing salt at hash. So this brings up to me access management policy, but also encryption. Look, you cannot in a modern world getaway without encryption, but encryption doesn't have to be hard, right?

So again, if you're using cloud services for email, for data storage, document storage and collaborations like AG drive, an outlook through 3 6, 5 0 3 6 5, you are getting encryption. You're getting SSL, you are getting a a, a PGP on your email. You are able to, to apply strong encryption throughout without necessarily having to spend on expensive tools.

But look, I would probably recommend as as you go forward, you're gonna want something a little bit more hardcore. Secrets management for those machine to machine cryptographic keys and passwords. For example.

Uh, you're gonna want actual data encryption technologies that are industry standard strong, right? Whatever that means today. And it does change, that's actually really important.

So the secrets management is actually super important for high scale as well as you extend managing encryption keys, recycling them, cycling them, uh, uh, making sure you know, even one-off passwords are available for fire call purposes and so forth. Um, I would say use process automation as well to automate some of these recycling and, and, and regular maintenance activities to make sure that your processes as documented are being executed. Um, and as you get advanced, obviously there's API to API security being able to make sure that they're talking, securing and recycling their passwords and so forth.

And even integrated with infrastructure as code. When I deploy a new server, I deploy all the secrets on that using my secrets management tool. That's one way to get to, yes, right?

So, um, what else have we got? Uh, look, data protection. I'm gonna rush through some of this because it's not, look, there's a lot of requirements, but we all know what it's about and it's about protecting data and that's not hard.

We all know what it means, right? We've got documented controls. Oops, lemme just go back.

So we've got those documented controls. They're important. Absolutely.

Um, strong encryption. We've talked about this. Um, all for all data transferred.

So we're talking about encryption in transit, not just at rest. So this is important characteristics of data protection that we have to deal with as CTOs. Um, and we also have to realize that some content is sensitive and some is not.

So I would always look for a classification regime. I don't want to have to protect my customer brochures. Anyone can read those.

But my strategy document I wanna protect very tightly, um, provide encryption on transfers. Um, see here's now where we start to get to specifics. Which type of encryption do you want?

What is your standard? Um, delete data and when it's not needed, uh, delete personal data when you're finished using it. Um, confidential data is used.

Must raise it with multi-step. Have you got like a dban or something? Something to do a multi-step Orion with zeroing out your hard drives before they're reused or maybe you're just gonna fully destroy them.

Uh, put a drill through the hard drive. Quite frankly, it's easy than running dand on every one of them. Storage is sort of cheap now, isn't it?

Uh, and then you've got physical data security. Look again, policy policy, policy, access management policy, data management policy, physical security policy, and of course encryption. But also, again, think of what your cloud and hosting services can deliver for you to get to.

Yes, on all. You don't necessarily need to put the tools in your own shop. I do like secrets management.

Uh, we were looking at that in my last role as CTO at Kumu. Uh, the idea of trying to manage this automatically based on our runbooks. So we didn't have the, honestly, the opportunity for manual error.

Most security breaches happen through manual error or inadvertent breach. So let's get rid of that. Let's use secret management tools to make that happen.

And this is where with an advanced organization, you're gonna need things like a content management system to manage content over its entire life cycle, delete it when you're done with it and so forth. Even things like user behavior analytics so that you know, when users are exfiltrating data, when they probably shouldn't be. These are advanced use cases, but for large enterprises, they absolutely make sense.

Uh, speaking of which audit and control, you know, we've gotta, we've gotta manage logging and monitoring. We've gotta record, oops, we've got to record things. Um, so you've gotta record audit trails.

Fair enough. Logging and monitoring procedures. But again, procedures, not necessarily tools.

Um, create audit trails. All identities must be recorded in the audit. It's not enough to say what you did.

You have to record who did it. Um, must archive them, make them searchable, review them. It's not, have you got a process to actually review your event logs?

It's not enough to just record them just in case. Um, you've gotta have a defined, documented, established continuous security monitoring program. Not a tool.

Tool's. Probably gonna make it easier though, right? Um, so again, with policy, but audit and compliance policy.

Make sure everyone knows it. Make sure they're following it. You've gotta have log management tools.

It could just be your event logs and your system log and your application logs. It's probably gonna be more like a log rhythm, uh, a gray log, maybe something as big as a Datadog or Splunk, but that's probably where you're gonna advance to a seam or a observability, AUBA or a a a, a threat detection platform like a Splunk or Sumo Logic Elastic, for example. Um, speaking of which, monitoring incidents response, you've gotta respond to your incidents too, right?

So using seem, you have to regularly monitor and respond. It's gotta be documented. Your documented plan, this is where runbooks come in.

Part of your policy should be how to respond. Your runbook can help you drive automation, but you've gotta write it first. You've gotta document those known good processes.

Um, prompt notification if you have loss of keys, loss of data. There are ways to do all of this in policy. Uh, but I love this look, and I actually love this as well, getting the right people on the right on the phone, on the slack, on the chat at the right time to solve the problem as soon as it happens based on automation, ah, that's, that's my happy place.

Um, at scale you can do other things like collaborative incident response and even emergency notification. Systems like Everbridge, for example, can come to play with notifying customers, notifying first responders if it's an real emergency security, physical emergency, um, and responding automatically with automation, which brings into physical security. Now let me just touch on this quickly as ACTO.

It's my responsibility. I work closely with my facilities team to deal with a lot of this stuff, but some of it's sort of weird. Um, sure.

Fire and smoke prevention, absolutely. Uh, access restrictions, hardware restrictions to limit physical access and a clean desk policy. Okay?

What's a clean desk policy? By the way, in this contract it was defined, get people to define their terms so you can know what you're agreeing to. Um, but look, I was running a fully remote team, some of this just didn't work.

So I just pushed back. I said, look, I can't do this. I can't do this monitoring and physical access by the way.

I personally can because I'm a geek and I've got cameras security guy, I love my Rio Links, it's connected my sonology nas. So I actually tick this box quite a lot on my own rfp. But you look monitoring Canberra for your workers at home, that's creepy and weird and you should not be accepting that as a term in your RFPs.

Get to it another way. You know, same with security guards. That can't happen.

You need to get to that another way. Policy will help you get there. Um, but there are tools, you know, we talked about physical key man keys, you know, UB keys.

So you've got that two-factor authentication of physical look. You can put a security camera outside someone's front door. You can't put it inside their house.

I don't, I don't think putting outside their front door is bit creepy. Gotta trust but verify. And that's what policy is all about.

Um, so when it comes to remote work, and this is where I'm gonna wrap, um, I have a couple of summary slides for you, but it's important to understand that this changes with remote work. Um, you can still do things like multi-factor authentication, right? Um, that's entirely feasible.

Uh, you can, you know, like I said, issue UB keys, right? Multi-factor physical key authentication. Great.

You can still do encryption, you can still do mobile device management. This is where I'd recommend you actually do get a tool. Some of this is included in oh 365, oh G drive, uh, Google Enterprise as well, by the way.

So again, look at the tools you already have to achieve the goals. Um, you know, then security patching. We all wanna do that.

But again, this idea of a clean room, define it. Maybe push back if you have to. This is one area I push back quite a lot.

No personal items capable of recording. But what about, you know, memory sticks, data transfers, these sorts of things. So again, allow cell phones.

My team used their cell phone to do incident response. How can I prevent them using a cell phone? So you've gotta do this in policy.

You can use MDM to do so. You can use encryption, you can use you a key type stuff, but you've also gotta verify and trust your people. So policy, policy, policy, policy, it's tools for breakfast.

Most SecOps RFPs, you can fill in a lot of it on policy, um, and hard work. It's not just writing the policy down. Tools don't replace policy.

Also, by the way. Um, they can help monitor, enforce, automate, do all sorts of good things, but if you don't have good policy, you're not gonna implement good policy regardless of how good the tool is. So I would say always start with policy.

Um, you've gotta trust but also verify. You've gotta monitor. The people are doing it.

You've gotta train them so they know what to do. And then you've gotta enforce it by encouraging and or reprimanding when they do or do not follow your policy. Um, segregation of duties is anachronism.

Physical controls are often anachronistic. Clean room is anachronism, you know, it doesn't work with remote work, with DevOps, with collaboration with you build it, you run it. So, you know, tools can help, but again, you're gonna have to rely on your people and their positive intent based on the education you've given them and the understanding that they will be monitored for compliance.

Um, so yeah, write your policies. It's a lot of critical elements. Finally, this is my last slide.

Look, answering an RFP is complex and time consuming. Look at those walls of text you just went through and that is literally like 16 different RFPs. Um, not everything is a new tool purchase and you don't always have to say yes.

Find ways to get to an agreement to do the right things, to protect your customers, your partners. Um, but you don't always have to agree to everything they ask. 'cause sometimes it just doesn't work.

Um, start with an acceptable use and information security policy. Fill in those gaps. Adopt cloud services.

It will get to yes, so many more times with so much less grief for you. Um, look at the gaps. Every individual team is gonna work well probably together.

But those gaps, those boundaries between dev and ops, for example, between QA and development, for example, between ops and security teams, that's where things get lost. Make sure you're covering that, not just with policy, probably with tools as well. Practice that.

Relentless automation, it gives you value, saves cost, gets faster, gives you audit, standardizes known good practices. It's all upside as far as I know. And absolutely manage the humans, not just the technology.

Look, you can answer a lot of this with technology. You are never going to get the high value security outcomes you want without having trained your people, given them standards to follow, monitor them and help them comply in every way you possibly can and make sure you are monitoring and, and, and responding when they're not complete very much a human issue. So with that, from Sable, from Andi Mann, I would love to talk to you more about SecOps and your SecOps vision, but I, that's at least all my time, if not more.

I appreciate you staying with me and I'm gonna be around for q and a. Uh, and I hope to talk with you soon, whether it's contacting Sable or in the q and a later today on SecOps Vision with Techstrong. Thank you so much for listening.

Been a hard slog, but now you've got some tips on how to deal with your security RFPs. Thanks. Bye-Bye.