Episode 150: Is OSCAL the Future of Security Documentation

Guest: Kenny Scott

Bio: 

Kenny Scott is the Founder and CEO of Paramify, a groundbreaking platform that simplifies and streamlines compliance reporting for cloud service providers. Kenny’s mission is to streamline compliance documentation processes for GRC (Governance, Risk Management, and Compliance) and cyber security professionals through Paramify. 
 
Kenny, with over 18 years of experience in information security and IT audit, helped to pioneer the Adobe Common Controls Framework, is proficient in compliance frameworks such as FedRAMP, StateRAMP, TX-RAMP, CMMC, SOC2, ISO27001, and GDPR, holding CISSP and CISA credentials. His expertise extends to business strategy, investing, and programming, demonstrated through managing a closed fund for investors and founding a consulting practice for security programs. Outside of work, he is married to Angie Scott, a father of 5, and enjoys music, playing the guitar, snowboarding, and surfing when near a beach. 

Summary: 

In this episode of the Virtual CISO Podcast, John Verry speaks with Kenny Scott, founder and CEO of Paramify, about the challenges of cyber risk management and the potential of OSCAL (Open Security Controls Assessment Language) in simplifying compliance and documentation processes. They discuss the importance of structured digital communication in security, the complexities of FedRAMP, and how OSCAL can streamline the documentation process, ultimately reducing costs and improving efficiency in security programs. In this conversation, Kenny and John discuss the challenges and strategies for adopting OSCAL (Open Security Controls Assessment Language) in organizations. They explore the importance of understanding data flows for compliance, the role of AI in streamlining compliance processes, and the potential for OSCAL to transform how organizations manage security and compliance documentation. They also touch on the future of OSCAL and its relevance in various compliance frameworks beyond FedRAMP. 

Keywords: 

Paramafy, OSCAL, Cyber Risk Management, FedRAMP, Security Controls, Compliance, Automation, Risk Assessment, Documentation, Security Standards, OSCAL, compliance, AI, FedRAMP, CMMC, data flow, risk management, automation, security, documentation 

Takeaways: 

• Paramafy aims to make risk management accessible to all. 

• OSCAL is a structured language for security documentation. 

• Digital descriptions of security controls are more efficient than traditional methods. 

• FedRAMP presents significant documentation challenges for organizations. 

• OSCAL can help reduce the overwhelming nature of compliance requirements. 

• A cohesive way to describe controls is essential for effective risk management. 

• OSCAL enables digital transformation in security programs. 

• Automation can significantly reduce the cost of compliance audits. 

• The adoption of OSCAL can lead to more consistent and error-free documentation. 

• Collaboration and understanding of data flows are crucial for effective security management. Understanding OSCAL is crucial for effective adoption. 

• Data flow mapping simplifies compliance processes. 

• AI can significantly reduce the time and cost of compliance. 

• Organizations need to focus on the fundamentals of data management. 

• Compliance should be viewed as a validation of security efforts. 

• OSCAL can automate the generation of compliance documentation. 

• The future of OSCAL looks promising with increasing interest from companies. 

• Effective compliance requires both technology and skilled professionals. 

• Organizations should not rely solely on tools for compliance success. 

• The integration of OSCAL with existing frameworks can enhance risk management. 

Kenny (00:00)
Alright, perfect. Awesome.

John Verry (00:02)
All right, here we go. Hey there and welcome to yet another episode of the Virtual CISO Podcast with you as always, John Verry your host and with me today, Kenny Scott. Hey, Kenny.

Kenny (00:12)
Hey, sup John.

John Verry (00:15)
Nice to meet you. I always like to start simple. Tell us a little bit about who you are and what is it that you do every day.

Kenny (00:17)
Likewise.

Yeah, I’m Kenny Scott. the founder and CEO of Paramafy. I’ve been in this security space for almost two decades now. But essentially what we do at Paramafy is we want to make great risk management accessible to anyone. And cyber risk management in particular, that’s where we’re focused right now. It’s incredibly challenging for companies. The core aspects are planning, implementation and execution on the

John Verry (00:29)
you

Kenny (00:54)
on the implementation side of risk management. And then on the other side, it’s planning, execution and reporting on the assurance side. And so there’s not that we found a one-stop solution that handles all of it. And we’re not trying to be that. What we do is we help professionals build solid plans using their existing stack. So there are people, places, things, people, process, technology, whatever it is, and automates the required deliverables for managers, assessors, customers.

And where there’s gaps, we connect them with great partners and great tools and excellent deliverables in a very short time. So to use an analogy, it’s kind of like, I tell this to my team all the time, any math equation that starts wrong, it’s always going to be wrong no matter the gymnastics you do in between. And so our ambition is to be the risk management software that ensures we’re good at each step. So for the most complex problems from setup to execution.

and then you’re showing your work the whole way. that’s what I’m doing all the time, building software with my team. Love it.

John Verry (02:02)
Awesome,

awesome. Before we get down to business, what’s your drink of choice?

Kenny (02:10)
It’s Mountain Dew, Zero Sugar, Spark. They don’t make it anymore.

John Verry (02:17)
Okay, you’re

doing a lot more coding than you let on then. I mean, you know, where you come out of a coding background because there very few people in the world that I know that drink Mountain Dew except for people who code.

Kenny (02:30)
Well, I have I, haven’t checked in code in a long time, though. I do a lot of prototyping, but yeah, my background is in audit. And then I do code. Yeah. So, so much that I lost feeling in one of my hands completely at the very beginning of parameter. I had to get surgery. was anyways, I could less now, but I still love Mountain Dew. I liked spark, but they don’t make it anymore. So Baja blast is fine.

John Verry (03:01)
That’s funny. All right. So, so, uh, you know, uh, the, way I ended up stumbling into, uh, this conversation, uh, was, uh, uh, paramafy is an interesting product and we had reached out to you guys to ask some questions with regards to it. And I’ve been looking for someone to come on the podcast and talk about Ascal. And you guys started talking about Ascal during the, during the discussion. And I was like, a second. I found that I found somebody who can talk Ascal.

So, you know, OSCAL is kind of fascinating to me in this concept of automation, you know, has just an amazing potential, you know, to reduce complexity, reduce time to target, et cetera. So that was why I wanted to chat with you on this stuff. let’s start again, let’s start simple. What is OSCAL?

Kenny (03:24)
So

like your word, the potential. but

Oskal is the open security controls assessment language. That’s what it stands for. It’s basically a more structured Jason. It could be used for describing components within an environment in a, in a digital way. Right. So when I think of anything from a security perspective, it always starts with data. Where does the data go? Where is it stored?

What are the people that interact with that data? What are the technology, the compute or whatever the components that you’re using that process it and then where is it stored? What are the procedures around handling that? So people process tech and, and Oskal is basically a more structured JSON that can be used for describing that. Right. And then you can also tie it to both the implementation side of security and

the assurance activities that go along with that. So we really like Auscal’s potential and we’ve been using it for a long time. And I’m really excited about where it will be in the future. It’s still got a long way to go though, for sure.

John Verry (05:04)
Yeah. So, um, would it be fair to say that it’s effectively a markup language for security documentation? like we were going to have a password policy that if I looked at a OSCAL representation of that, you know, it might have a hashtag kind of thing that says, you know, policy, and then it might have guideline and it might have control and it might have methodology or whatever those defined tags are. You know, I would be basically

writing my documentation or translating my documentation into that context. And then that would be then machine readable by somebody else. So, you know, if someone, if I was sending some of my policies from a vendor risk management perspective, as an example, and they were in OSCAL, they could just read those policies and they could have like automated checks built in. So like you could use OSCAL theoretically to simplify vendor risk management, right? If you received all your documentation in OSCAL. Basic idea.

Kenny (06:01)
Yep,

that’s the idea. Ascal out of the box doesn’t do any of that. It’s just a standard, which is what

John Verry (06:07)
No, I gotcha.

Kenny (06:09)
which is what I really love about it.

John Verry (06:11)
It’s an enabling technology, right? Just the same way HTML in and of itself does nothing, but with a web browser and a website, magic kind of can happen. Okay.

Kenny (06:14)
Mm-hmm.

That’s exactly right. That’s perfect analogy. use a lot HTML, which is absolutely ubiquitous now. Oskaltate is far from ubiquitous, but it has potential to be a lot further along.

John Verry (06:41)
Well, so let’s talk about that potential. why do you, you you guys have, it seemed like you’ve pushed a lot of your chips into the middle on Ascal. You know, why is it, you know, why, why is it important for business? Why is it important for a security professional?

Kenny (06:55)
Yeah, I just liked it because it was a standard, honestly. I do risk management in my own way and it’s been working really, really well for me and for my teams and for now my customers. We try to make it as simple as possible. The reason that people need to, it’s important for them is it’s just better to describe things digitally.

rather than the traditional methods, Of, you know, word documents, spreadsheets. It’s better to think in terms of capability and Oskow provides a way to do that. I’ve always, before I found out about Oskow, I was doing, I was doing things for, for clients in, how I handle risk solution, like risk solutions, are capabilities, right? So a capability could be something really complex like,

or technical like a sync between your Active Directory and your SSO solution. It could be something like that, or it could be something that’s less technical, like some sort of HR background check procedure. And so how do you describe those things? And that’s what gets mapped to all of the requirements, the cloud security requirements that they have for questionnaires, like you mentioned, or…

It looks like we’ll talk about it later, some of the other compliance regimes, but it’s better to think in terms of capability and describing that in the most concise way, just getting that inventory of capabilities down to the smallest possible number. That way it’s not so overwhelming for you to manage it. Oskow provided a way where I could take that capability and then it’s kind of a middle man to say, hey, here’s the standard for

how you like describe controls and it does have everything on the security planning side. The execution of that plan and then the reporting, has all the elements that you need. And so that was great having all of that. And then from there, I could produce any kind of deliverable that’s needed, whether that was a full on FedRAMP ATO package, which we do, or a full on.

you know, a SOC 2, Section 3, Section 2, all of that, you know, can be described from the same base set of how you implement security. So that is what is so powerful about, OSGAL as a standard. And I think, it will get, you know, it will get more and more adopted, but still people want things presented in the way that they expect to see them. And I don’t think that’s going to change in the next 10 years.

We’re not going to get everyone to agree. yeah, this is how we want it to look. Always all the same across every regime. That’s not going to happen. So we just use Oskow. It’s just a benefit for us. nobody’s going to go, yeah. Anyway. Yeah.

John Verry (10:02)
Well, I mean, isn’t it part of a broader consensus that a common structured way of communicating something has a tremendous number of benefits to parties on both sides of communication with regards to that. So as an example, under a NIST 800-218, right? You know, the idea of an SBOM, secure software bill of materials being digital, right? Machine readable. I forget the name of the format.

that they use for that. But a machine readable, you know, SBOM has a lot of value, you know, to both the party that produces it, right? Because once we’ve gotten to a point where we can produce it, we can produce it repeatedly, consistently, without error, without flaw. Updating it, you know, doesn’t take an engineer a few hours. It takes, you know, somebody pushing a button or a script that runs automatically.

Kenny (10:33)
Mm-hmm.

.

John Verry (10:58)
And it just happens, you know, automatically, right? So to speak. And then on the flip side, you know, it builds trust in the marketplace because you can actually provide that. And then to the entity that’s receiving it, you know, if they have the, if they have the capacity to read it digitally, right? That simplifies their side. Again, someone doesn’t have to sit there and go through this, you know, for a complex application, you know, dozens and hundreds of pages of information say, Hey,

wait a second. You’ve got a, um, uh, a librarian here.

that has a particular concern relating to our particular infrastructure. No, I mean, you would know that you could just flag that,

Kenny (11:34)
So cool. Yeah, I’m really excited. In terms of, yeah, the SBOM, that’s a huge opportunity. I think it’s great. Just getting everybody to agree with.

John Verry (11:45)
And OSCAL is kind of an analog, right? mean, it’s an analog

for information security communication with regards to your information security controls that are in place,

Kenny (11:57)
That’s exactly right. Yeah. So there’s lots of options there. It is cool.

John Verry (11:59)
Yeah, that’s, that’s, that’s going be really cool. So you mentioned, know, you

mentioned, yeah, you mentioned an hour, our conversation with your team, uh, you weren’t on it, uh, was, um, was specifically with regards to FedRAMP. So I, you know, I think FedRAMP is a very unique beast relative to most, um, call them attestation frameworks, uh, in that, um, you know, it’s an onerous level of documentation.

Kenny (12:13)
Mm-hmm.

you

John Verry (12:29)
Um, and you know, at Primify, you’re trying to figure out how to use OSCAL to, um, reduce the time and effort necessary to both, think initially produce and then maintain that documentation on a go-forward basis. Why don’t you talk a little bit about that and, know, and how that works and how people would use it and what the benefits would be, uh, for them.

Kenny (12:30)
Mm-hmm.

Yeah. Yeah, that’s a, that’s a great, yeah. FedRAMP is a beast. It’s, but it’s really, really an important framework and I think it needs more and more adoption. FedRAMP is very comprehensive. When you think…

What is my cyber risk? What are the cyber risks that I need to consider? They’ve gone way ahead and said, like, we already know what those are. We know what the cyber risks are. If you’re an infrastructure as a service, if you’re a platform as a service or software as a service, or if you’re even in a self-hosted software, we know what those risks are. You don’t have to reinvent the wheel. We know what they are and we know the things that you should implement. And they make it.

particularly flexible with, you know, parameters that, know, certain expectations that you have to hit. Sometimes it’s not risk-based. Sometimes it’s like, you just have to do it. We’re handling the risk. This is how we want to do it. And it becomes very, very overwhelming for folks to do that because let’s look at a, with rep five, the FedRAMP high package as well over 800 requirements that have to happen within the controls appendix a.

We’re not talking about the 400 controls per se, but there’s, if you look at AC2, it’s A through L in terms of requirements and those have parameters that need to be set. That in and of itself, right? Tell somebody, hey, I need you to understand all, you know, 827 of these requirements and I need you to set the parameters correctly.

And I need you to map those to the capabilities that are in your environment and also how are you handling your data? It just gets overwhelming really fast. And so again, I just go back to it takes, it takes a village to raise a security program. You need to understand what are those data flows that come into your environment? And so we, before Oskow made it really, really simple way for describing that.

And what was so cool about OSCAL is it was that intermediary. our goal is not to deliver OSCAL. Our goal is to help people manage risk accordingly, to have a really strong inventory of their capabilities within their organization. And OSCAL is just that kind of enables that. So again, back to the FedRAMP question, it’s a really

honor us thing to do if and you need help almost you can’t do it alone. It’s going to take a lot of people moving together. So with Oscar, you have the opportunity to describe something one time. So I told you in the very beginning, I gave an example of like SSO sinking with your with your identity source, right? So that that’s really important. And that ties to so many controls from a course grain perspective.

Because if you’re able to tie your Active Directory to your HR system when someone’s terminated, well, then all of their permissions can be revoked when that person is removed, Versus if it’s not connected, well, there’s a lot of manual efforts that have to happen. So when you’re going through a FedRAMP process, it’s going to ask you how many…

How do you do, how do you revoke access for your employees in different aspects? Like it’s going to ask you that throughout the whole document, especially in AC2, also with identity controls and, and elsewhere. And so if you have to talk about that, you know, 65 times within a whole like appendix A and then it changes.

then you have to go update everything 65 times in the appendix A and then in appendices A through R, right? It’s just, that becomes really overwhelming. And that’s why the cost has been traditionally so high because I get why that reporting needs to be in place. Risk management has two sides. It has implementation, which is, you know, building the security and then it has assurance and you have to, it’s

It’s two sides of the same coin, right? And you need to be kind of, you have to have a cohesive way to describe to your auditor what your controls are. And if you’re doing it manually, the chance for error is really high and that’s why the costs go so high. And that’s why you have so much burnout. And so Oskow is simply a digital trans, it gives you a chance. If you implement it right, it gives you a chance to have a digital transformation.

of your security program, which is really the exciting thing.

John Verry (17:54)
Right. So, so, so first off, I mean, most people don’t might not know this, right? But like, as an example with FedRAMP, I mean, FedRAMP, it’s not unusual to have 600, 800, a thousand pages of the 1200 pages of documentation, right? mean, just even a typical system security plan is in the, you know, 500, 600 page range, right? So, so, you know, that’s the, that’s the magnitude. And like, you know, if you go to a traditional generation of said documentation,

Kenny (18:10)
That’s right.

Yeah.

John Verry (18:23)
You know someone is literally taking a template. Typing that information into one place and then they go into the next control and then three controls later like yeah, I could I could steal the language from there and they go back cut and paste that and they put it there. But now they’re talking with somebody and they change that version. OK, but now they went back and copied the wrong version from over here. But then later on they recopied it, but they copied it from that one and then and then that changes again because they changed their multi factor authentication provider to Okta.

because they didn’t realize that it was an on ATO. And this is where we get into this endless challenge of maintaining and generating that documentation, both the original

Kenny (19:01)
Unless.

John Verry (19:01)
set and then keeping it. OK, so to simplify a thought process for people here, because this is a little weird, Askel’s kind of a phrase you never heard. It’s almost as if you went into a database and you asked me 100 questions. What do do here? What do you do? What do you do? do you do? Tell me about this. Tell me about this. Tell me about this.

And then you have a template over here of what the SSP is going to look like. And you hit the button and the template is going to pull all that information. It’s like a fancy find and replace in a weird way. We’re

Kenny (19:26)
Mm-hmm.

John Verry (19:27)
sort of using OSCAL in the same way. We’re defining it once over here. And then what we’re being able to do is then say, okay, when, you know, when I click this button, I want to generate a word document that is going to leverage the information that I have in my OSCAL library.

Right in my oscale xml, json file, yaml, think you support your oscale sports, right? I have this file over here and it’s literally just always pulling it over. So if I maintain my one set over here, which is just like the bare minimum definitions that I need, generating I can generate documentation dynamically, right? That’s is it. Isn’t that the quote unquote value prop of a product like Primify? OK.

Kenny (19:58)
100%. Yeah.

Yeah. 100%. Yeah. You need to, yeah, to, to adopt Oskow, right? You know, you need some sort of tool to do it. Right. and, there’s a lot of people making a lot of efforts to make it simpler.

if I could just really explain kind of something basic in terms of what Oscar did just for your listeners. So, Hey, what did you learn about Oscar? this one is really important. so NIST 800-53, that’s what we call in Oscar. That’s a catalog of controls, right? There’s over 1300 requirements in there and it’s supposed to be,

you can tailor a NIST 800-53 to your organization. Fizma has what we call profiles within that catalog. So profiles implement that catalog and those profiles have parameters. They can alter some of the control language if they need to. And so that’s really what it is. So there’s a NIST 800-53.

John Verry (21:18)
ODPs,

right? Isn’t that the term? Organizational Defined Parameter, ODP, I think it’s the…

Kenny (21:23)
That’s right.

Yep. That’s what, and that’s what they’re called in Oskow. That’s right. the ODP is right. So you can have that. And sometimes that’s determined by FedRAMP, right? FedRAMP will say, Hey, you have to do this annually, for FedRAMP high, right? Procedures need to be reviewed, you know, annually or policies annually, for FedRAMP high, where it might have a different parameter for FedRAMP moderate, right? Every three years or something like that. Right. So,

Yeah, there’s those, those change in, Oskala allows for a lot of flexibility there where you can mix and mingle different catalogs. we had like, so for example, we use for our IL five, IL six stuff we have. IL six is also a similar profile, but what that’s going to do is you’re going to have the NIST 800-53 catalog over here. And then you’re going to,

to create like the paramify profile, what’s that’s going to do is it’s going to take the required controls from for IL-5 or IL-6. And then it’s going to also have the required controls from FedRAMP. And so there’s going to be 50 from the 50 from the or so I’m not saying exact, right? But there’s going to be 50 or so controls from the IL-5 that are also going to mix with

some of the FedRAMP ones. And there’s also going to be modifications to some of the FedRAMP controls for IL-5. Okay. And on top of that is they’ll have general readiness requirements as well, which is a whole other catalog. And so pulling that together digitally, like in a platform is way better than a Word document. like even, you know, the agencies themselves, when someone say, Hey, give me, give me a template, fill out this template of ours.

And that will be fraught with theirs because it’s copy pasted right into a Word document. They’ll say like, Hey, this is control. I don’t know. I’m not saying specifically, but this is like a SR two, but it will be the language from AC two. You know what I mean? And so you’re, it’s just, it’s just too difficult. It’s not really anyone’s fault. It’s just a lot. And those controls are ultimately really important.

John Verry (23:34)
yeah, absolutely.

Kenny (23:45)
And so you understand, yes, you need to do it, but it’s just so hard to do because of the mechanisms we’ve been given. Right. So I don’t know if that was too technical, but I think that’s just like an example of how it goes. Right.

John Verry (23:58)
No, no, no, no. Yeah.

I think it gives people an idea of like what Oscar. Now one other thing too is then correct me if I’m wrong on this. think one of the other drivers to this and one of the other benefits to using us cow on the front side, not only are we saving time, energy, effort, reducing errors, but isn’t the intention of the FedRAMP PMO to reduce the cost? mean, FedRAMP is ridiculously expensive, right? As well. mean, you know,

Depending on who you talk to, would be unlikely someone would tell you your Olin cost is less than 400. You’re going to hear people tell you. And for some organizations, the Olin cost is a million, which is just unacceptable, especially now with CMMC. And CMMC is driving more FedRAMP interest because we’ve got on the flow down the FedRAMP moderate or equivalent requirement.

Kenny (24:39)
way over that sometimes. Yeah.

John Verry (24:55)
So the government’s looking at this and going like, we gotta make this less expensive for people to do. OSCAL’s a way of doing that. a big part of that cost is the cost of the three PAO to conduct the audit. So a FedRAMP moderate audit, ballpark cost quarter million dollars, you kind of agree with that. And then 150,000 a year probably. And they’re sitting there reading your docs.

Kenny (25:01)
That’s right.

John Verry (25:20)
You know, if we can actually, if that’s machine readable and they have the capability of machine reading it and doing checks and then only having to look at things which deviate from what expectation, let’s say, is an example. And that propagates all the way up to the agency ATO office as well. That’s a win for everybody, right? You know, it’s less

Kenny (25:37)
100%.

John Verry (25:39)
painful for the three PAO. Their bill goes down, but their profitability probably doesn’t. And it’s better for the ATO because their level of effort to get someone to support.

And ATO is a lot less, right? So, I mean, this is kind of like

Kenny (25:52)
yeah.

John Verry (25:53)
win, win, win if we can get Askel working the way that whoever was smart enough to think about this from the beginning envisioned.

Kenny (26:02)
Yeah, it’s really great. In order for an organization to adopt OSCAL, it’s also kind of a challenge, right? So how do we get there, right? You really need to understand OSCAL to adopt it. And so you need to have engineers that understand it. And it’s going to be a lot and it’s ongoing because OSCAL is now perfect. There’s a new foundation group that is focused on making

John Verry (26:08)
Mm-hmm.

Kenny (26:29)
helping the Oscar kind of get more widely adopted and more standardized. but you really need to understand it. there’s, there’s efforts to make it more accessible, but our whole like, you know, parameter, I mean, I mean, shameless plug, right. But our whole goal is like, how do we get you adopting Oscar right away? Right. So taking your manual compliance documents and doing that within a few getting it.

John Verry (26:51)
Mm-hmm.

Kenny (26:56)
and OSGAL representation of your security functions within a few hours, which is…

John Verry (27:00)
So real quick there,

that sounds fascinating. So I’m assuming in my head, right, that what you’ve got then is some mechanism by which I’m going to hand you hopefully a well-structured set of policies. And what you’re going to do is you’re going to ETL import whatever the right word we want to use. You’re going to parse that. And you’re going to put that into an OSCAL format, regurgitate that back to us to make sure. And then obviously there’s going to be some cleanup necessary like there is with any type of data import process.

Kenny (27:19)
Mm-hmm. Mm-hmm.

Yeah.

John Verry (27:30)
we go through that process, perhaps iteratively once or twice, then we’re to have an OSCAL representation. Once I have the OSCAL representation cleaned up, I can then click a button and I’m going to regenerate a set of Word documents in a standardized format that are now being driven off this OSCAL data. So now I’ve accomplished that task of update once over here. And if that information is in my system security plan, if that’s in my rules behavior guide, if that’s in my appendix, what, A through L, right? There’s 13, 14.

Whatever it is now in the new Fed rep A through R. Yeah. Okay. So that you know, so what is that 20 ish documents you got to generate and a lot of that information flows into different documents. So you literally could click a button and generate all of those documents from that OSCAL structured data file.

Kenny (27:59)
A through R, A through R, yeah. Yeah. Yeah.

That’s right. Yeah. Garbage in garbage out. Right. So if it’s really bad, which is the expectation because of the structure that has been given to them, it’s not their fault. Right. It’s like that’s you’re talking thousands of pages. Right. So yes, if it is structured, that’s awesome. But usually what we do is we ultimately go back to data flows.

John Verry (28:18)
Yep.

Kenny (28:39)
Right? You don’t need a tool to really, you can use something as simple as Google Sheets or SharePoint and Excel just to map out what are the data flows? Where’s the data? Where’s my authentication? How does that happen? Well, yeah, like, so what’s the authentication process? Well, first I need DNS resolution. And so that’s over here at Route 53. And is DNSSEC implemented there? Yeah, it totally is. Okay, great. So that’s a component.

And then from there, where does it go? Well, it to the application load balancer, and then it goes through a firewall, and then it goes through engine X and then it goes to the app. Right. And so that’s how you kind of discover it. And then finally, you’ll get into the risk management questions, which is, Hey, where are all the logs going for these components? And how do they get to your Sam? And where’s that? And is that FedRAMP authorized? And really, we try to make it really simple first. And that tends to be.

The result tends to be even better than legacy documentation. so people go, yeah, I did this SSP and I’ve spent like, well, there’s well over seven figures into this SSP. it’s like, great. Yeah, we can, we can import it and we can use AI to help it. But ultimately you can’t advocate security to anybody. There’s no magic bullet that’s going to say, yeah, now I’m perfectly secure. And I’m describing it exactly right. You just, it just doesn’t exist. Ultimately, you’re going to have to.

understand what are those data flows. so yeah.

John Verry (30:06)
Yeah. Yep. I always say, I, I’m

sorry. Sorry to interrupt you. We got a little lag. Um, I always say, I always, you know, we walk into the same type of situations. Well, I’ve got, I’ve got an SSP. We did it a couple of years ago. And you’re like, out. know, we’re not going to put all this time, energy and effort in until we know the ladders against the right wall. Right. So get the ladder against the right wall and let’s climb it. So if you don’t go back, if you don’t get down to the fundamentals, what type of data you’re processing,

Kenny (30:27)
I love that.

John Verry (30:35)
I don’t give a crap what standard it is. You can do store process transit, right? There’s PCI, whether it’s CMMC, that’s CUI data, right? What’s CUI relevant? How do we establish the scope? If you don’t understand how that data flows through its whole life cycle, what third parties are touching it, what are the laws and regulations that govern its operation? What are the client contractual obligations and expectations? What are the cyber liability insurance? If you don’t understand all of that stuff, then I don’t give a crap about anything until I understand that.

Kenny (30:48)
Okay.

John Verry (31:04)
And then we can, because half the time, you got, I mean, you’ve probably experienced this, right? You got people that are like, we’ve gone into CMMC work and you’ve got people and they’re like, we got the SIM all set up, you know, and it’s, and it’s like, and

we’ve got every system reporting into it and this and that. you’re like, okay, well, let me see your SSP scope. Well, we, haven’t gotten to the data flow. Well, let’s, let’s do that. And okay. Well, guys, you’re, you’re, you have, you have five, you have five CUI relevant assets. If we, if we architect your enclave this way.

Kenny (31:15)
You gotta start there, otherwise you’re screwed.

John Verry (31:33)
those are the only ones that you actually need your Sim to talk to. What? Like we just went out and bought Splunk and we just spent $100,000 with the team engineers and you’re like, you didn’t need to do that. Or you migrated to Microsoft 365, GovCloud and didn’t need it. Or you didn’t migrate to GovCloud and you did. Like guys, start at the beginning, right? Get the ladder against the right wall. So you guys follow that same process. Let me ask a question there as well. And this gets really interesting to me. So one of the things which like we’re working with a client right now,

TextRamp, they have an AWS GovCloud environment, know, goals for to be TextRamp, Sieges, GovCloud, know, excuse me, FedRamp. A lot of times we’re spending like an AWS security hub and looking at, you know, the implementation of the controls, it’s nice to have the benchmarks and you can see how you’re matching up. Is there a way that you’d be able to, we need this from AWS and if they’d done this yet, would AWS be able to give us sort of like a machine readable format output of like,

Kenny (32:12)
Yeah.

John Verry (32:32)
that control implementation, like verifying as an example that the encryption format, the encryption on this S3 bucket is FIPS 140.1 level

two valid. Is there a way to machine read that? And that sort of becomes part of that documentation in OSCAL?

Kenny (32:52)
Yeah, yeah, well, there absolutely is. And that’s we strive to be that platform, right? That can actually provide that. So we have all that information in our platform. So when you do an intake, right, you can say like, hey, where are you deployed? And you say, well, we’re in a garage. Okay, well, that’s a problem.

I cried off the bat. know a lot of issues, but if you’re deployed in GovCloud, we know a lot about you already, right? We know what gets taken care of. And we, yeah, we have, we have Oskow profiles for, for all of the components, right? Yeah. So it’s pretty sick. Yeah. So we can automate this CRM and the CIS. Yeah. We already know you do need to, like, there are things that

John Verry (33:12)
You

So you can read that? You can read that? that’s cool.

that’s pretty cool. So you don’t even need me to tell you, yeah.

Kenny (33:38)
you need to happen, right? You need to actually enable the encryption, which I think can be just a default setting, you know, within GovCloud. I think that’s what it is, right? So those things are enabled, right? But yeah, we know which those, you know, what the, you know, the CMDP references and all those things. So if we know the data flows, guess what we know how to do. We know how to fill out the whole appendix queue, which is usually

takes people like two weeks to do it and then they’re still going back, back and forth, back and forth. Like on the merry-go-round, like you said, and it’s not merry, right? It’s suck. It’s terrible work, right? To go back and forth, right?

John Verry (34:17)
Yes, it’s unrewarding

and it’s unrewarding. know, the people that you and the worst thing is you’re paying people like, mean, you know what cloud engineers cost this day, hundreds of thousands of dollars for a really good cloud engineer. And you’ve got this guy doing busy work effectively. I mean, he’s only one who can do it because he’s the only one who really understands the diagram. But I mean, it’s ticking and tying and checking and validation and he’s not enjoying it and it’s costing you fortune. So I’m just curious, have you guys ever figured out like

Kenny (34:30)
Mm-hmm.

Ahem.

John Verry (34:46)
If you can use this stuff effectively, right? You know, I understand this and if, but if you can use the stuff effectively, right? And like, for example, for Paramify doing what you’re doing, do you think you would, you would cut the cost of doing the FedRAMP consulting side, right? Because you’re not yet on the ATO on the, on the testing side. I understand that, but that’s a future potential, right? When they implement that side, but on the prep side, let’s call it. And then the ongoing maintenance side. Well, let’s just talk about prep, right?

Kenny (35:08)
Yeah.

John Verry (35:16)
You know, have you done any benchmarks as to we reduce the time by X percent and the typical consulting costs by Y percent?

Kenny (35:27)
my gosh. Yeah. Well, first off, I do believe that AI and tools like Paramafy are super important, but they are the, the analogy I use, John is like, Hey, this is the, this is the Iron Man suit for Tony Stark. So I do think that consulting organizations that are premier are going to stay premier. They’re going to be using tools. we have partnered with the biggest names.

right in the industry, they’re using Paramafide to fulfill their engagements and we get excellent feedback from them. And so it’s just getting better and better. Right. So I do think that there’s a place for them to use it and they are way more profitable and they’re able to charge less to their clients. had an example of a, here’s like to your example earlier of like garbage in garbage out. So we had a customer that was really, really excellent.

John Verry (36:12)
you

Kenny (36:22)
right, at FedRAMP, but they needed to migrate their SSP documentation, which was manually done, right, in a Word document, and they needed to get to Rev 5, right? They needed to get to Rev 5. And so ingesting all those capabilities is right away in Paramify, but we were just with the squad of like seven different people on Zoom, you know, had the security engineers, had the CISO, had all the people.

We’re filling in out and we had an oscale representation of their, of their SSP. and this is, this is crazy, but it was four hours when we were done with everything. Right. And this was a enterprise software that was going to lose their ATO. They were with the jab at the time, which is not the, not the case anymore. They were going to lose their, their status. say, Hey, we need you to, you stopped. They had lost their whole team.

Right. Cause you know, they got paid a lot of money to go to other places and they were in a place where like, here we have this manual documentation and we have no way to do this by Wednesday. And so someone, you know, that knew us said, Hey, can you do this? And I said, absolutely. You know, we can. And so we were able to do it. So it can be done. It can be done faster than you think. it doesn’t mean that we implement.

we’re going to be like a magic bullet. There still needs to be great security engineers. There still needs to be the advisors, right? That are that know how, like you said, perfect example, guys, you could have five components here in your enclave and that’s all that has to be CMMC, right? That’s That’s like, just be smart about it. So you still need that. If, customers are looking for an easy button for FedRap or they’re like, Hey, let me just abdicate this to someone. Guess what? You’re going to get a mediocre result.

But the excellent people are going to be using advanced technology, right? They’re going to be using things that can leverage Oskal for your benefit.

John Verry (38:26)
Right. I mean, you still need the look. mean, it’s like anything else. just because you dropped off a plan and all of the materials, the deck, the wood, the hangers, the tools in my backyard, that doesn’t mean I can build a deck. Right. You know, so you, you still need to have the smart people, you know, that understand like how to put this together. But what we’re talking about doing is removing some of the error prone.

Kenny (38:42)
That’s right.

John Verry (38:54)
more drudgery oriented tasks off their plate, which is going to reduce time to target and is going to reduce cost obviously as well.

Kenny (39:03)
100 % I love it. Yep.

John Verry (39:05)
Okay. All

right. Beyond, so FedRAMP is the obvious. mean, I’m guessing that FedRAMP is your biggest target. That’s probably where you know, because I can see where that, you know, it’s the most expensive, most documentation laden spot. And that’s what you helped to solve. Do you guys do much with CMMC or any other frameworks?

Kenny (39:25)
Yeah, a hundred percent. already have customers that are using it for their CMMC implementations. We partner with big names. I mean, if you like search CMMC, you’ll see a couple partners and they’re using us, right? To fulfill their engagements. Cause it makes it just so much easier. So yeah, absolutely. CMMC, anything risk management, our world is risk management. So.

SoC 2, we’re working with our auditors for that, helping using Paramify to do it, both on the implementation side and on the assurance side.

John Verry (39:58)
Gotcha.

Are any of the mainstream GRC tools yet OSCAL, I don’t know the right word, compliant, OSCAL supporting?

Kenny (40:11)
not that we’ve seen and for them it’s really FedRAMP authorization, right? That is the challenge for them. And so if they’re doing, So we’re in a new space. We’re in a good spot strategically. It’s just ripe for this to happen. So I think there’s going to be a lot of people solving this and there’s not going to be just one winner here, but we’re really excited about our place. I don’t know.

about off-scale adoption for the other tools. I do know that a couple of them that are trying really hard and they’re part of the foundation group, know, trying to define it and everything.

John Verry (40:50)
Yep.

All right. then, so, you know, one quick question. So in prep for the podcast, I was doing my research and, know, the one thing, you know, should I read anything into the fact that the NIST OSCAL website hasn’t been updated in 18 months?

Kenny (41:07)
Yeah, I think, yeah, it’s just a funding issue. So there is a new Oskow Foundation that’s trying to solve that. So there’s a big committee and all that stuff. So they’re all good people. They’re all trying. And to me, Oskow is already useful as is. And if it makes changes and improves, great. I love it. Right. And I do think that I do think that

Michaela Yorga, who’s like at, at NIST, right? her team has done incredible work in getting it to where it is. And it’s very usable for us right now. Right. It’s very usable. It’s just the tools to adopt it. And so that’s what we’re trying to do. Right. Yeah.

John Verry (41:52)
Gotcha.

And then if I asked you to look into your crystal ball, what do you see for OSCAL in the next three to five years?

Kenny (41:59)
I think that it’s here to stay. It’s a little bit murky, right for me. But I do think that it’s here to stay. There’s enough money and companies that are interested in it, companies like GitLab and all of our customers, right? So they’re very interested in Ascal. On the audit side, they still prefer reading things in a

in a general format, right? In like a, in a word format. So that’s fine. if you do Oskow correctly, that’s, that’s not a problem, right? You can just produce whatever you need to produce in any way, shape or form. Yeah.

John Verry (42:40)
Gotcha.

It, listen, it makes, it makes too much sense to me that, you know, that it isn’t going to happen. Right. I mean, like, like, you know, why wouldn’t you want machine readable policy procedure documentation? that, you know, like it’s just like, makes, it makes no sense. mean, every, every element, you know, on the production side, it has value on the utilization side. has value on the.

Kenny (42:49)
Mm-hmm.

John Verry (43:09)
you know, third party sharing data. I mean, like right now, like if you think about like, I remember talking to one of the big banks and I think they had 67 people in third party risk management, you know, and those are all high paid individuals. And you think to yourself like, okay, what percentage of the time are they sitting there, they’re reading a SOC 2 report, they’re reading, you know, they’re sending out a, you know, a security questionnaire of some sort. Maybe they’re trying to normalize it into a, onto a platform like Prevalent or something of that nature.

But at end of the day, people are typing in different things, they’re using different terminologies, the data’s not normalized, the data’s not structured. mean, if you could create a standard and then no one has to read that, that’s all being interpreted, like it just makes way too much sense for this not to happen. So I’m there with you, dude. I think five years from now, it’ll be common. It just doesn’t matter what does that arc look like and how does AI impact that, I think is another question as well.

Kenny (43:54)
Yeah. Yeah.

Yeah.

Yeah, mean, AI needs structure. AI needs good data. AI needs like in order for it to work. And so we’re very excited about the future. I think it’s going to work itself out through like, there’s just a lot of people trying to solve this. Yeah. For others that want to just churn butter by hand, great. You know, go ahead if you want to. We want to help solve the problem and get to actually

to a spot where compliance, it’s like security is the mission and compliance is the outcome. That is everything we’re about.

John Verry (44:40)
Yeah,

well compliance is the validation of security. I don’t think it is right now. I compliance and security are different. In a weird way, OSCAL would make it easier to equate security and compliance. That’s kind of cool idea.

Kenny (44:45)
That’s right, I like that even better.

Yeah, yeah,

I do like that. That’s good. Okay. All right.

John Verry (45:03)
Yeah, listen, you’re not allowed to use that. I mean, I’ll tell you what, I’ll license it to you. yeah,

I’ll have our attorney reach out to your attorney and we can discuss a reasonable fee for using that, right? We beat this up pretty good. Did we miss anything?

Kenny (45:14)
Perfect. Perfect.

I don’t think so, man. Thanks, John. It’s really awesome.

John Verry (45:21)
Well, thank you.

Yeah, this was fun and I would love to see this really, There’s too many good reasons that we shouldn’t as an industry find a way to make this work. If somebody wanted to get in touch with you, you understand what Paramify does, talk further about something, what’s the easiest way for them to do that?

Kenny (45:41)
Yeah, so I’m pretty active on LinkedIn and on the social platforms. Kenny Scott, Kenny G Scott on LinkedIn and you can find me there. Also, granfi.com, right? Come visit and see if it’s right for you.

John Verry (45:59)
I’d

leave the G out because Kenny G is another, another whole thing, which I’m sure you’ve.

Kenny (46:07)
You don’t like the dentist office? I’m working on it. Working it. Yeah, no. Alright, brother.

John Verry (46:08)
You don’t have the right hair to be Kenny G. I’m old enough to remember when Kenny G was like somebody that people were like, oh, he’s really good. All right, was nice to meet you.