ISACA Podcast: Why You Should Use the F Word More

Anecdotes is the leading enterprise agentic GRC platform built for organizations that refuse to compromise. With comprehensive solutions across governance, risk, and compliance, deep customization capabilities, and AI agents that run on an audit-grade data infrastructure, Anecdotes enables the world's top enterprises to manage GRC programs as unique as their businesses. You can learn more about our efforts at www.anecdotes.

ai. you're listening to the isaka podcast this episode is sponsored by anecdotes i'm excited today to be joined by Jake Bernardes, who's CISO at Anecdotes. So a few weeks ago, you presented a session titled, You Should Use the F Word More at the ISACA North America Conference. You were talking about FedRAMP 20X.

One of the things you said in your presentation was that compliance is broken. Can you elaborate a little bit on that? Gosh, that, yes. I've written on a lot of places, a lot of invariants, but I'll give you the most condensed version.

I think compliance is broken from every direction. I think if you look at how we came to a compliance journey, really, SOC 2 was written in the late 20 noughties. It was like 2008, 2009. And it was built for a time when we had DCs, like corporate infrastructure.

We deployed and maintained our applications. We had perimeters. That was what we were doing. We were containing and maintaining our own data, and therefore, we were almost trusting ourselves.

And then we saw this world where it jumped into SaaS and cloud and big data right through the 2010s. And suddenly what changed is how we consume software and how we consume products. We went from having our corporate infrastructure we deployed onto to trusting vendors who would use their corporate infrastructure or cloud environments, we deployed our data into them or our users' data. So suddenly we had to start going, well, I don't have to trust myself anymore.

I've got to trust you. And I can do that in contractual form, but how else do I get some kind of assurance around that? And so we looked at moving SOC 2 from being specifically to a very niche federal market to being basically usable by every vendor. And with it came the ISO certs, and then you've got HIPAA for healthcare and PCI for payments, and the list goes on run.

And then that one, what you saw is that we had this very broken approach where an audit came in and it assessed a point in time status. They asked me for screenshots. They asked me to do walkthroughs. They asked me to explain things.

They did interviews. And on that day, they assessed based on a sample, so a subset of data to provide a limited assurance based on that sample. having scared it up and why I told them that I was secure. Now, we know there's a lot of reality issues in that statement because a lot of vendors who have been breached, in fact, basically every major company that's been breached in the last 10 to 20 years had SOC2 and ISO and HIPAA and PCI and all these things.

So it doesn't really reflect security. And the reason is that I can curate the story I tell you. I can sort of control the sample. I can definitely control the narrative.

I as a CISO and as a technical professional can explain in a technical way that you as an auditor can't understand. So compliance is always broken. And it was based on data sets that were screenshots, right? A screenshot you can take and then you can change it tomorrow.

It's the same as a photo. I take a photo of me smiling, I'm smiling. And two seconds later, I'm not smiling anymore. We all know Instagram is a fake version of reality.

There's people who are depressed that smile in every photo. And the same thing is true in compliance. So what we saw is over time, we've seen this journey from point in time, static screenshot-based compliance to data. AniDose is one of those platforms.

We're not the only ones. There's AniDose, Drada, Levanta, Hyperproof, you could name a ton of them, right? They all flow data in. And they basically say, don't take a screenshot of AWS or any cloud config, like attach it via API and pull the data so it's real time and it's continuous.

Good. We've started to fix broken compliance, but it's not enough, right? It's still broken and it's still broken because of the way it's built. You look at SOC 2, the questions they ask.

If you look at ISO, the questions they ask. If you look at Even modern AI regulation, it's written and it's outdated before it's published. It's archaic in many ways. I gave a talk at ISACA, Philadelphia this year, and I showed 12 points across four different AI frameworks.

They're the point of publication. Their statements were outdated and impossible. But it didn't change them. So compliance is broken because the people regulating it and certifying it are regulating and certifying for a historical reality or for a fake reality.

The people in the chairs who are evidencing their posture are naturally inclined to want to pass because they're required to pass audits. So they're presenting a fake version of reality in as much as is possible to an auditor. And then the tools, while we've moved on massively and anecdotes is a great advancement in using data and actual AI, they're still limited because of who consumes them. If I say I want to push my entire data flow via API in JSON format to you, I want to have a look, they can see how secure they think anecdotes are.

No one's ready to consume that. So compliance is broken end to end from the people obsessing it to the people doing it to the people regulating it. All of those things are broken. And that was the premise for the talk I gave on why I think Pete Waterman and FedRAMP20X is a movement which is really progressing it because exactly my last statement is what they're doing.

They say, we want a window into your compliance structure. We want access to your cloud security logs, your app testing logs to your identity environments. We want to know in continuous real time to be able to pull via API and JSON format and ingest that data to have to see and make an assessment not based on your SOC 2, not based on your pen test, not based on your policies, but based on the reality that is in the data that you can't hide. And then we will build real trust and meaningful kind of relationships based on the fact we accept that it okay to have non because that the reality of the world right We just saw the GitHub breach another variant of Shai Halud Miasma And that highlights, again, massively.

So many of those companies have wonderfully well-built development environments, yet so many of them got pinged by this because this is complex and sophisticated and it doesn't show that you're failing. It just shows the reality of this is what happened. This is what we did. This is why that's the best approach.

I know I went on a soapbox there for a while, but you asked me very much of a soapbox question, I'm afraid. No, we appreciate it. And, you know, you were just touching on this, but could you give us a little bit more detail on FedRAMP 20X? What is it really doing differently?

And then why should people who are listening to this be thinking about this compliance overhaul? So FedRAMP traditionally was probably the most archaic of all the archaic programs. heavily paper-based, based in security deliverables that include poems and large-scale regulatory documentation. It was really old-score, really regimented, really rigorous control sets.

And it also had two fundamental problems. One is you required a government sponsor to get into the program. So if you're a starter, Elon Musk didn't do many things right in government, in my opinion. This is not a view by SACA.

But one thing he did do is he disrupted who the government could buy. And 20X is part of that wave to a large extent. So we're a startup. I can't go and get a government customer because they will say to me, do you have any other government customers?

And I'll say, no. They'll say, well, you can't be a government customer. We can't buy you then. And I'll say, but I need you to get FedRAMP authorized to get otherwise government customers.

Well, I'm sorry, until you're on the list, we can't buy you. So there's this weird catch rate too where you could never get into the game. So the government was forced, the federal government was forced to buy old school archaic technologies because the new disruptive, future thinking ones couldn't get into the supply chain. Problem two was the sheer cost and period of time.

Like FedRAMP traditionally was an outlay of between two and five million. That is a massive outlay for most startups whose revenue mark between five and 50 million ARR. That's a massive outlet. But it's a bet.

You don't know how many customers you're going to get, so you are betting. And the same is how long it took. So you then say, well, I go to my CEO and say, I want to spend two to five million dollars to speculatively try and go some government customers that I don't know we're going to win. I don't know how much they'll pay us.

and also by the way just as a just as a sideline it'll take us 24 to 36 months try explaining that to a startup they think you're mad right so that was the problem you never got new tech into the chain because they couldn't so Pete Waterman came who is a maverick he looks like a maverick when you really talk about government federal workers the guy turns up with his big beard and his orange sunglasses his braille orange hoodies and his shorts he doesn't look like he should represent the government's federal security agencies right but he came and said thing which was refreshingly real.

He said compliance is an engineering problem. That's a statement he's put in multiple places in multiple different versions of phraseologies. And what that means is actually compliance is technical, right? It's cloud environment conflicts.

It's app set processes. It's identity management. It is everything else in between that you can see in data. So he said, well, why don't we get to a world where actually you can automate this stuff, automate 80% of the controls in FedEx.

Show us what you're doing and show us the truth. He's a big proponent for show us the truth. I don't want to know your clean curated report. I want to see what goes wrong and how you deal with when it goes wrong, because that's part of reality.

And that's what governments want to build trust, not based on that one point in time, but based on a genuine flow of things. So I think that was the first real move. And the second is getting rid of the problems. So FedRAMP20X will not cost you $5 million.

it will cost you an auditor fee, which is probably between $100,000 to $200,000. And you might need to do some software changes. So historically, you had to update every single software component into FedRAMP-A5. Now, if you look at a backend database like Snowflake, well, Snowflake will double your price for FedRAMP.

Wiz will double your price for FedRAMP. GCP is an anomaly, but if you're AWS or Azure, you need a whole separate platform to be FedRAMP compliant. So these costs can stack into the millions quickly. The other thing he says is you don't need a sponsor.

You build and get yourself compliant and we will then enable you to sell into the agencies. So you don't need that past 22 problem. You don't need that $5 million problem. And you can actually get to a point where compliance is way more technical and way more based in reality.

So that's what it is in a nutshell. Why I think it's important, I think from different angles, it's important for different reasons. Historically, there's three parts to this chain. There is us, the compliance vendor, so I'm direct to the federal government.

Never a chance before as a startup. Now a chance exists. From the other side, the federal government can now buy new and disruptive technologies, which it couldn't before. But now they'll be able to get into the supply chain.

It can buy the things it wants, not the things it's forced to buy. And the last one in that middle is a really interesting piece. So if you're a CSP already selling to the federal government on traditional FedRAMP, your Rev5 or maybe your DoD IL5, right? Well, historically, you have to go and get a platform, a compliance platform that could be FedRAMP authorized.

And that was a problem because none of what we explained before as a new wave of data-led, AI-driven compliance platforms were FedRAMP authorized. So you were forced to use our K-8 platforms. So now the CSPs, we used Snowflake before, the Snowflakes, the Elastics, the Databricks, whoever of the world can now use modern compliance platforms to support their traditional old-school FedRAMP Rev5 and salespeople government. So it interests everyone from us as vendors to the buyer to the federal agencies.

Everyone is benefiting. It's a good thing. Now, I want to talk a little bit about key security indicators. This sounds like a great buzzword, but what are they actually measuring?

And then why is this kind of automated validation better than traditional documentation? Okay, let's get backwards from that. So traditional documentation is broken because of exactly the statement you made is traditional documentation. A policy or a document saying something is far less meaningful than technical evidence And that the reality of how we live in a world right now right If I gave you let talk I was just on the phone this one about cars If I give you a report and say, this car can go this fast, you'll know that's great.

But if I put you in the car and show you the car going that fast, your perception and your attachment to the statement I've made is completely different. And this is the same. If I write I am secure and I sign the document, someone goes, that's great. But if I go, here you go, here's the data in real time.

Here's an API secured endpoint that I'll connect you to and I'll flow my data into you all the damn day if you want. You stick it into a secured, individualized, flawed environment. You analyze it. You do what the hell you want with it.

You tell me what questions you've got about my data. That's different. That's me putting you in the car and showing you how it feels to go fast. So I think that's the key point is it's different because it gives you a different sense of trust and a different sense of relationship.

If you go back one point to the previous question, which is very much like, what is a KSI? I'm at the automator. KSI's are effectively similar to anything. They're a control-based statement.

They are a statement that says, we want to look at this indicator, whether that has to do with how much people have trained, to how you secure a supply chain, to how you use a secure development environment, to how you complete penetration testing. All these kinds of things roll into KSI's of some form in some language. The automation of that is based on the statement that says, actually, you can automate anything. So if I want to go and look at secure development environments, let's say there are several components to that, right?

Let's say that I'm going to have to do SAS, so it's a static analysis of my code. I'm going to have to ensure that I have pinned packages, maybe, so I don't update to malicious or infected packages. I'm going to make sure there's manual code reviews happening, and I'm going to make sure there's a limitation on the hand that can push the prop. Those four things might roll up into a KSI, where I'm automatically pulling that data from GitHub or GitLab or Jenkins, wherever it is, and I'm demonstrating live in real time in a continuous fashion that I'm meeting that KSI.

And again, to my current analogy, that is far more convincing than me saying, yes, my environment is secure and my approach is secure. Here's my signature on a letter. Now, the idea of something taking weeks rather than months for authorization sounds incredible, but maybe not super realistic. But can you tell us a little bit, what's it actually going to take for organizations to pull this off?

Yeah, so let me talk about the journey we went on as anecdotes and say how it was. So there was obviously, we're in pilot phase of federal analytics right now. There was a low pilot, which we elected not to go into. And then when we decided we thought about it, it was probably late.

We entered the moderate pilot, which then initially was meant to happen in Q3, Q4 last year, which it couldn't because there was a federal shutdown, you might remember, and everyone stopped working. So suddenly the federal agencies couldn't do anything. So we engaged in January and submitted for FedRAM compliance, initially at low and now working towards moderate. And we did that within about a six-week period prior to audit.

The audit period was about three weeks. And that shows you what's possible. That is a hell of a lot of work. But because we're now focusing not on processes or procedures or workflows or documents, we're fixing on actually how do you connect and flow data that already exists.

It's a very different world. You can do things in a far faster fashion, but also in a much more robust and, to be honest, much more reassuring fashion. Like the assurance levels I would get from FedEx 20X as an auditor, I think are way higher than what I'd get from National Red 5. Now, that's my opinion.

The industry and many agencies disagree, but I think this stuff is way higher degree of assurance because there's no more sample. This is complete data sets, right? A sample is fundamentally broken because I go to 100 people and I ask 10 of them, what color is this? right what color is my is my sweatshirt and 10 and go it's red right they've colluded whatever right they've just another colorblind i pick 10 backs and they're colorblind and i then scale up and say jake's sweatshirt is red my sweatshirt is obviously not red it's black but because i only asked 10 people i don't know that small sample now that's the same problem in security you pick a jml process join a move believers you pick the last 10 that you did they might be fine but the 11th?

The 11th, you forgot to grow access. And by the way, that guy's got access to prod without requiring a VPN and his creds just got comped. But now if I flow you the entire data there, you see that one, you query it. And I said, this is what happened.

And this is how I remediate it. And maybe that gives you confidence. But the reality is you're then getting reality. I think that's the big difference for me.

Yeah. So it really sounds like FedRAMP 20X is forcing GRC platforms to evolve or just kind of fall behind. Can you tell us a little bit about how Anecdotes specifically is approaching it? We have a big leg up in this game.

There's a reason we're big fans of 20x, and it's because 20x is based on data. And where Anecdotes is different is we rely and obsess over data. If you look, there's two ways to run a compliance automation platform, and there's not a wrong or a right. I mean, I simply explain the two ways, because I think that's the most interesting way to show it.

One is by a binary call and one is by a data flow. The first is a call where effectively you're connecting an API. Let's use my example before of AWS. And let's say that you want to show that in the simplest form, you encrypt all data at rest, right?

That is literally a tick box inside of the admin console. That's really what that means. There are three, the oldest form fashion, when I went to that page as an admin, which you had to be, I took a screenshot and I gave it to the auditor. The next wave is by what's called a binary API call.

Now, that API is connected to AWS environment. So now this is in real time and it's continuously checking, but it's running a test. It's Boolean. It's saying, is that box ticked effectively?

And it will come back with yes or no. And the light will go green or red. And you've probably seen that in some of the compliance tools. They go green light, red light.

Right? It feels a bit like some kind of game show. Let go back right And the other way is to flow the data through So what that means is instead of actually asking the question and giving you an answer green or red I going to bring all the data in And in doing that I going to show complete variance So I going to show that yes, it's encrypted. But by the way, six weeks ago, there was these seven VMs that weren't encrypted.

I don't know why. Or maybe I do know why. And you can show in that data, you can give a lot more clarity. So when you talk about 20X being all about the data and the underlying data, then the reason Agnes loves it is we are the latter.

So we rely on full data transparency. We don't rely on running Boolean tests. So at any point in time, I don't just need to say, yes, no, it's working, which is problematic because that's, well, that might meet FedRAMP. It's not really what they're looking for.

What I can do is say, here's the whole data set. Here's it in JSON, connect via API, ingest the whole lot, do whatever the hell you want with it. All right, come back and ask me questions. That is a massive advantage.

When 20x is pushing people to think more about data and less about yes or no from an automation stance, and it plays into our hands. So naturally we're big fans of this because it plays more to how we think about compliance. And I think that's the right way to think about compliance too. And what advice do you have for people who might be listening whose organizations haven't even started preparing for 20X just yet?

Well, I think firstly you can't right now because it's still in pilot phase until it gets published. But I think it's worth, you know, what you're trying to achieve. It's who are you selling to? If you are going directly to the federal government, then make sure that the agency that you're going to sell to isn't a doctor of 20X, because not all of them are.

Some of them are still stuck in the past, in my opinion. They would say they're relying on traditional methods. If you're selling to CSPs, so cloud service providers, other software companies, then this is the best way for you possibly to go. I think in terms of preparing for it, it's understanding it.

So there is a bunch of rules set. It's coming out soon, the CR, the rules set, which will give you guidance on how to actually apply 20X almost as a control set. start to understand where you stand against that as an organization start to a kind of gap assessment it's publicly available so i can look at what you might need to build or do to get to a point of being compliant because i can almost guarantee as soon as they open it for public applications especially for fedrat moderate there will be an actually astronomical number of applications uh particularly in the startup world so i think getting ready to know that you can say straight away look if you let me and i can already do 80 now and here's demonstrations here's evidence.

I think that's the best way to go. So start understanding what the requirements are and start plotting your gap analysis against them would be my free guidance. Now, one of the things you said in your presentation was that FedRAMP is the future. How so?

And what might you see some of the impacts specifically of 20X being widespread? So I think, let me give out some clarity, FedRAMP's approach is the future. So I think we look at the future of SOC2, of ISO, So PCI of HIPAA, they're still pretty fundamentally based in documents, screenshots, and static evidence. Even when we're automating it, they're still pulling subsets and samples.

I think the future of compliance is based on this. It's based in full data, so complete and accurate data sets, continuous, real-time, accessible via some kind of trust center, which isn't presented with documents or a repo, but a trust center is providing an API that you connect to and pull the data from. I think the future is where a world in which we will build trust by connecting to each other and letting people see into our entire security and compliance tag. I don't need an ISO or a SOC 2 or even a FedRAM control set.

I just need to say, here's all my data. Tell me if you're comfortable. If you have questions, you can feel free to ask me. And then before we wrap up, is there anything else you want to share with our listeners that we haven't had a chance to discuss yet?

I think there's two pieces. I think we started on talking about the journey with FedRAM. I think the one that's relevant right now is AI. And I touched on it from talking about Isaac of Philadelphia.

And I think when you look at the governance and compliance on AI right now, it's fundamentally wrong. It needs to be more continuous. It needs to be more risk-based. It needs to be taken in-house because regulators and lawyers can't write fast enough.

And the second piece is leveraging AI in compliance. One of the benefits, 20X is teaching us to build automation where automation doesn't exist. I think those can help you with lots of things, but we can't solve every problem. So I think starting to understand with a GRC engineering, which is another buzzword in the moment, GRC engineering mindset, how you can leverage AI and agentic tech to automate areas and parts of your compliance and security journey becomes so important right now in hiring the right people.

So if you're a CISO or a compliance head looking for how do I get better right now, I'd say go and find some software engineers, bring them into your org, look at what your outcomes are and say, how would I get there in your mind and let them go away and actually build an engineer a solution using a lot of what's now available through things like codex or code code that allow you to write and accomplish things that you couldn't write and accomplish even a year ago. So I think that's my other part is like, now is the time to go back to the eight-year-old.

I would say that I was using my eight-year-old daughter, Isabel, as an example. Like she sees the world and where I wish I still did, where she still thinks unicorns can be real and she can accomplish anything she wants to be, right? Her backup plan, if she's not Taylor Swift, is to be a professional gymnast. We get older and we're forced into the probable, not the possible.

I think right now under AI and Agenda, particularly in compliance and GRC, where we are so old school compared to most domains of security and of technology, let's believe again in the possible. Let's turn the eight-year-old back in and say, you know what? I could probably do that. I should have to build this, this, and this, and that's probably buildable.

That's fantastic. What a great note to end on. Thank you so much for joining us. And we again want to thank Anecdotes for sponsoring this episode of the podcast.

That's all we have time for in this episode. If you'd like to hear more, be sure you're subscribed to the ISACA podcast.