Max Discusses Authorization Boundaries with Naveed Mirza from Okta

Max Aulakh: [00:00:00]
Welcome to Reckless Compliance Podcast, where we learn about unintended consequences of federal compliance, brought to you by ignyteplatform.com If you’re looking to learn about cyber risk management and get your product into the federal market, this podcast is for you. Or if you’re a security pro within the federal space looking for a community, join us. We’ll break down tools, tips, and techniques to help you get better and faster to get through the laborious federal accreditation processes. It doesn’t matter what type of system or federal agencies you’re dealing with. If you’ve heard of confusing terms like ATOs, FedRAMP, RMF, DISA, STIGS, SAAB, SARS, or newer terms like CATO, Big Bang, OSCAL, and SBOMS, we’ll break it down all one by one.And now, here’s the show.


Max Aulakh: [00:00:48]
Hi, everyone. Thank you for chiming in to Reckless Compliance, where we talk about public sector compliance and the unintended consequences of compliance. Today’s episode is really interesting. It’s actually one of the fundamental episodes. It’s about authorization boundaries or scoping in the commercial compliance. Sometimes we’ll refer to SOC 2 as scope statements or statement of applicability from the ISMS systems. But in the government side, this is all known as authorization boundaries or an ATO boundary. So, with me, I’ve got a pretty amazing individual with the right kind of background. His name is Naveed. He works for Okta now. But Naveed, tell us a little bit about yourself, your history. I know you were an instructor, but for the audience who don’t know, who don’t know who you are give us a little bit of background.

Naveed Mirza: [00:01:39]
Thank you for having me, Max. So just a little background. I worked in the compliance arena directly for close to 20 years. The majority of that time I was a government contractor supporting the U S Marine Corps. During that time, I had one AO that I worked with. I mean, this guy was there forever and a day. Fantastic human being. So you know, we got along great and we’re able to kind of create some you know, what I like to think of as maybe some common sense policies. And about 2021 I got the you know, everybody was just sitting around their houses you know, during COVID and I got the bug to maybe try something new and I went to Okta. The identity and access management company. And I’ve been here as a solution architect ever since.


Max Aulakh: [00:02:33]
Awesome. Yeah. Common sense policies. That’s very much needed in the government. And for those of you who are listening, AO authorization official, kind of the top dog, Navid, right? Wouldn’t you say in terms of who’s actually going to approve and. And essentially take on the, the proposition of risk, if, if any, on, on accepting the system.

Naveed Mirza: [00:02:53]
Yes, yes, and in some cases that AO is also the person who designs the actual policy and the processes to do that. 

Max Aulakh: [00:03:03]
Yeah, the AOs are pretty powerful. I think, I think one of our episodes, we actually had an AO on here, which was fantastic, so. Very interesting, very interesting job that they have, right? They’ve got to somehow basically take on risk on behalf of the government when it comes to cyber security. So definitely a compliance, and now you’re at Okta, which is fantastic. I know Okta’s one of the, you know, cutting edge products for IAM, identity access management and whatnot. So let’s get into, to the, you know, the boundary authorization. What is it? So Naveed, let’s start with that. So. For people that are listening who have never experienced anything with the government and you know, let alone Marine Corps, just, just the government, what is the authorization boundary? How is it formed? And what’s the importance of it?


Naveed Mirza: [00:03:50]
So I, I like to do things in analogies that some folks can maybe understand. So let’s do this. If I’m building a new house. The authorization boundary isn’t the house, right? Because I am getting the house approved. I’ve got state local government coming in there, checking to make sure everything in the house is built. But what about the groundwork around the house? What about the, you know, the sloping so that water doesn’t kind of, you know, ingress back into the basement where the electrical, you know coming into the, to the site and things like that. So your authorization boundary is bigger than the thing you’re building, but it’s really Yeah. The composition of the system and all of the supporting pieces that are required to make that system work on. Then what you do is you wrap that all up in an engineering document and called a system security plan, which doesn’t sound like an engineering document, but it kind of is. And then show that authorizing official the form, fit and function of the system and what the security you know, test and eval looks like for it.


Max Aulakh: [00:04:52]
That’s a great way to put it. I’ve actually never heard that analogy. I think it’s fantastic because when we look at authorization boundary diagrams, right, you’re, you’re talking about all the circuitry that might be coming into the house. It’s a very different way to think about it from traditional ISMS compliance, ISO compliance, where we might be thinking of the scope as just some loose statements. But here, if we put an engineering view into it, it’s really anything that’s coming into the house, anything that’s going out of the house. Almost sounds like a schematic of some sort. Did you ever have to draw those crazy, we call them cartoon diagrams, the authorization boundary diagrams?


Naveed Mirza: [00:05:33]
I’ve had to draw many of them, you know, when I was supporting different programs as the assistant security engineer. And I’ve had to review countless of them. When I, you know, supporting the AO as one of the assessors.


Max Aulakh: [00:05:49]
Yeah. I think, there’s no perfect way to do it, you know, I’ve seen it, I’ve seen it done a hundred different ways. And a lot of times, what I’ve learned is that, you know, my narrative and how I draw the diagram, it really is, is not just engineering, but it’s also serves as a communication piece. Because if my AO is so far away from technology, somehow I need to pare it down. I don’t know if you came across that, and that’s why we sometimes use the term cartoon diagrams, even though it’s not, you know, it doesn’t, at the end of it, it doesn’t resemble me. An engineering drawing. I don’t know if you ever came across that.

Naveed Mirza: [00:06:26]
Yeah, they’re not formal engineering drawings. They’re not, and I’m only going to say this term once because I don’t like it. Dodef. But they’re not but my favorite explanation for them is, I don’t know art, but I know what I like as an engineer, as the system security engineer, I need to put enough context into that diagram. So that somebody who has a rudimentary understanding of security and may not understand my technologies exactly can understand what I’m attempting to accomplish.


Max Aulakh: [00:06:59]
Yeah, that’s a, that’s a great way to put it. And I don’t like that term either, right? DoDAF. That’s, that’s a crazy ball of wax that I hope we never get into on this podcast, but I have a suspicion that we. That’ll be another, that’ll be another topic, but yeah, I think I think you’re right because I’ve seen the FedRAMP diagrams out there and they try to put specifications into exactly what they want, but when you actually match that up against the system, let’s say even Okta, which might have thousands of boundaries or any system, any DevOps system that might have thousands of interconnections. Sometimes when you look at the spec of what you’re supposed to do, versus the reality, it just makes it so complex, and it’s not even worth it, right, where you then have to abstract, and essentially, maybe not even abstract, but hey, what’s the best way for me to communicate? What is it that I’m trying to, you know, certify and whatnot, you know, did you guys have some of those kinds of things in the Marines or wherever you did this work?

Naveed Mirza: [00:08:03]
Yeah, I mean, and not just, you know, supporting the Marine Corps, but with some other customers as well, you know, as an analyst, one of the first things that I always wanted to do was sit down with a security manager and their engineer. And really sit down face to face, you know in the days before zoom and like, Hey, tell me what you’re trying to do. And I’m going to tell you if I don’t understand something, all right. Like, let’s face it. I might be brilliant. Just ask me, but you know, I don’t know everything. And so I will have to go do some research. The first time I ever looked at a DevSecOps pipeline was an eye opening experience for me. It really was, but as the analyst supporting the AO, I knew it was my job to kind of learn from the folks who are, you know, building it. So I always kind of treat it as that. Teach me so I can help you.


Max Aulakh: [00:08:54]
Yeah, that makes sense, especially DevOps and the DevSecOps world. There’s like a thousand different ways to do things, right? There’s like Terraform, there’s Kubernetes, there’s containers, Dockers. And yeah, I think compliance people, we always kind of sometimes get behind, but we all, we always got to learn and and I would, I would agree. I think the other side, even the DevOps people, they’re continuously learning as well.


Naveed Mirza: [00:09:18]
And the interesting thing here is, is that the government from an engineering, well, the government from an I. T. practice standard normally lags years behind, right?


Max Aulakh: [00:09:31]
I mean, yeah, that’s where we’re really starting behind.

Naveed Mirza: [00:09:34]
You know, so cloud hit me when it was really a mature thing. So I got to miss a lot of the infancy of cloud. I got to see the t shirts. It’s not a cloud. It’s just somebody else’s computer. You know, those kinds of things for the first 10 years, laughed at it and said, well, we’ll never go there. And then one day we go there, but by then it’s a little bit more mature. So the learning curve is I’ve got to learn a mature technology, but if I actually have someone developing a new system, using those technologies. I thought somebody to ask, just don’t be afraid to ask.


Max Aulakh: [00:10:04]
No, that’s the key. I think a lot of people in the compliance side of the house, we tend to know what these things are, but then how it applies to real world systems. I feel like we’re, we’re severely behind talking about the dev ops environment. Have you had the opportunity to kind of participate because a lot of things, you know, it’s really hard to. figure out how to do a boundary. So for those that are listening, right, Naveen, let’s say that we, they don’t even know what goes into it. So what, what do you, what typically goes into this boundary? And then let’s figure out like, where does it apply in terms of DevOps and the cloud, those kinds of things. In your experience, what are some of the key things that you cannot leave behind when it comes to a boundary?


Naveed Mirza: [00:10:47]
Okay, I’m going to answer this in two parts. So the first part is that DevSecOps environment itself. So that’s all of your development tools, the environment that you’re developing the code in the practices that you are using to develop that code part of that boundary, right? You know, so all of that kind of goes in there. So you were talking about Kubernetes and you know, and all those different tools down to what development languages are being used. And if you really want to get down into it, what approved libraries are being used and how those are being managed, because at the end of the day, the whole idea of a DevSecOps pipeline is to build secure applications and then minimize the authorization process for those. So instead, it may take you a year to build the pipeline and get it accredited, but those applications should come out the end already being accredited. And that’s kind of the goal is I can build that speed line for the applications that I need to build because I’ve done all of that work up front. So for a DevSecOps environment, it’s all of the tools, all of the processes have to be kind of covered in that boundary. Is it going to be a diagram? I can’t put the processes on a diagram. I can do process diagrams, I guess, but it’s part of that boundary, and it’s part of the discussion that needs to happen when I’m really talking about how I’m ensuring that I’m building secure applications, you know, through this thing.


Max Aulakh: [00:12:22]
Yeah, that makes sense. And I think that’s that’s important because at the end of the day, it’s really about trying to bake in security, you know, in different ways. And the diagram might just be the output that, that we need to help somebody understand, but I’m, I’m glad you mentioned you went all the way down to like S bombs, you know, the, the software bill of material, the libraries, things like that, because I don’t think a lot of people realize that doing this authorization thing or the boundary is not, I write a couple of statements and then I’ve formed it, you know, it, it’s getting down to the nitty gritty of how the system works, but to your point, you mentioned, hey, I gotta sit down with their systems engineer or their security engineer and really understand the inside of it. So, with the DevSecOps What I find really difficult to grasp is that the notion of boundary is kind of like okay We have a boundary and things are supposed to stay in that boundary and if they go out We’re supposed to be able to document it But man, it just seems like the pace of the software and how fast we’re moving It kind of breaks the entire paradigm of a boundary.

Naveed Mirza: [00:13:30]
It does because just the word boundary itself Is the castle moat, right?

Max Aulakh: [00:13:36]
That’s right.

Naveed Mirza: [00:13:38]
And, we still use the term, but I think it’s changed. It has to evolve. Or we just go back to on prem networks with firewalls, you know? So it’s why I keep going back to part of your boundary is the business processes used to manage your environment. If you have an AWS account, you’ve got business processes on who can manage it, how they manage it. You know, things that they are allowed to change, things that are not allowed to change, and that’s part of the boundary, because at the end of the day, your boundary is a virtual demarked zone in somebody else’s computer.

Max Aulakh: [00:14:10]
Yeah, and you know, one of the other paradigms that I’ve been seeing out there is that you’re accrediting the process. I don’t know if you’ve heard of that term. Hey, we’re accrediting the process, not the stuff in it, the stuff that comes out of it. Well, this software factory, whatever, yes, that’s secure because we baked in the secure software development, but really, we’re trying to accredit a process on how people

Naveed Mirza: [00:14:31]
Exactly that, that is, and I didn’t know this when we started down this way, we were building a, the Marine Corps first DevSecOps pipeline and  I was learning as I was going and writing policy as I was going so that was kind of an interesting time. But, you know, just had a good group of people who were everybody was just willing to kind of, you know, help the security guy understand help the compliance guy understand. But also part of me. My job was to take those compliance requirements. And figure out when they should and shouldn’t apply. Compliance is fantastic if I’m dealing with a, you know, a Windows server. Compliance really is not fantastic when I’m dealing with, you know, a container.


Max Aulakh: [00:15:20]
Yeah, talk to me about that, Naveen. Like, how does it, like, in your mind, right, how does, how is that? Changed, you know, because I agree with you. We struggle a lot in just the whole boundary. Just that word alone. It’s a terrible word, but that’s what it is. That’s really what it says, right? Can’t argue what it says. But how is that changed in your mind?


Naveed Mirza: [00:15:40]
Well, so like, let’s go back to the DevSecOps, you know, answer our example. Maybe what I’m fielding, you know, and I’ll make this really simple is a platform as a service. Application on, you know, type of a system where, you know, it’s got its own high level logic code that somebody can come in there and develop an application, push it to the server. We won’t even get into containers and that application runs within the context of the server. The server itself. All of the development practices are part of that DevSecOps pipeline. I know that that server or server stack is accredited. Security is being properly maintained. Somebody’s monitoring, doing all those things. So now I’m just worried about the data and business processes that are in that application.


Max Aulakh: [00:16:24]
Yeah, the way I see it is like. You know, that makes sense. I mean, on the traditional side, we used to call them, I think, general support systems or something, and then we’re just, you know, like, pushing them, like, everything underneath it. So, like, the platform as a service is accredited, but then everything you push on top of it, you know, it kind of becomes its own boundary. I hate to use that word, boundary. But I feel like,

Naveed Mirza: [00:16:49]
But they are,  they are very much. It has a different owner, right? I’ve got the app guys who may own the stack, but the application that I’ve written different owner, different data set, you know, maybe a different AO, depending on the branch of service here in you know, From that platform.


Max Aulakh: [00:17:12]
Yeah. That’s a, that’s a whole, another ball of wax, man. Inheritance, you know, that’s like,

Naveed Mirza: [00:17:19]
But it’s the crux of the whole thing. Right. If I define my boundaries, like there’s two modes of thought. Mega boundary where I put everything in one big boundary and I can do everything other than maintain the accreditation every three years because I’ve got 200, 000 line items to test to run every three years and it’s all one group of people, but that doesn’t work in the modern and I’m not kidding. I’ve actually seen a data center that had 200, 000 line items in its test plan.

Max Aulakh: [00:17:48]
In their plan. That’s break it down.



Naveed Mirza: [00:17:51]Yeah, Stig’s. Exponentially increase the number of security checks you have to do, you know, so, break it up into manageable chunks and then you reuse things. So, you know, now I’ve got that application service provider that may support five different application owners. They all have very small ATO packages under that old GSS major and minor application.


Max Aulakh: [00:18:19]
Yeah, I remember their minor applications. Yeah, no, you’re right. And, and I think that’s the, that’s where we should go, but man, did you ever feel like everybody wants to shove everything into the boundary because they think they’ll get an ATO for everything? Trevor, you ever come across those kinds of?


Naveed Mirza: [00:18:34]
I have seen people do that. And a lot of times, and there’s a balancing act. Like I I’ve looked at one, you know, major data center and I was like, Hey, if I split this up into three accreditation boundaries. A year or two years from now when you want to build the second data center, I can reuse some of this and you have a much more streamlined authorization path instead of two big ones here. I make one big one here. Make it reusable. Make that inheritance model work. So if you break off the management piece, right? So your control plane, your management plane, if it’s going to be the same between the two, break it out. So I have two data centers and one control plane. It looks, I’m managing three packages instead of two, but I’m only managing the control plane once instead of twice.

Max Aulakh: [00:19:20]
Wow. Yeah. No, I think that’s what we’re trying to do with a lot of people, right? But I’ve ran into challenges where the AO or the program office, you know, they just want to do a single ATO and it’s a giant boundary. They just want to shove everything in. So I say the politics get in the way of, like, good sound engineering or, and architecture practices.

Naveed Mirza: [00:19:41]
Yeah. So having been the guy on the other side of the fence you know, I’m sure that there are probably people who are going to watch this DeVene made me do something, you know, and maybe there’s a mea culpa moment here in that the AO, personal belief, I don’t believe that the AO or SCA should force somebody to follow a particular accreditation boundary the way they see it. You’re not the system owner. You don’t own it. You can give advice. And you can give strong advice like, Hey, by the way, this will be easier. And then if they don’t take your advice and they come back six months later and say, this is too hard, you can then do the, I told you so dance. And that would be fun. But I just don’t feel that you should force somebody to follow a certain boundary unless, here’s specific policy that says they cannot do what they’re doing.


Max Aulakh: [00:20:34]
Yeah. And I am a hundred percent agree with that because the people that are closest to the system that really understand it, I think those are the people that are actually going to understand how to do the security of it. Now, the compliance is another piece, but yeah, that’s how I always kind of, you know, that’s how boundaries are typically formed in the government is like, Oh, there’s a program record. Great. That’s a program. And what ends up happening is that we end up stifling innovation. I know we’re supposed to be talking about the boundary, but when innovation always comes in like small chunks, right? Like, hey, there’s this, there’s this nice little software. Let’s build it. There’s a nice little library that plugs into multiple softwares, right? That’s, that’s what’s happening. And I feel like this whole boundary notion is against that innovation to some degree, but breaking it up is the key if we can get, if we can get other people on board, I guess you could say, because that I don’t know if you ever felt that, but when you’re on the other side, like on the government side, whether you’re a contractor or civilian, you have a lot of say in terms of how somebody is going to do something in it. It could be the wrong way to do it altogether.


Naveed Mirza: [00:21:51]
Yeah, and that’s, you know, so a little bit of a soapbox you know when, when I first started, I was in my early twenties, no, my boss said we’re going to do it this way and we’re going to do it this way. And then after a while, you kind of just learn to sit down, have the conversation. Try to figure out where you might be wrong. Again, I’m brilliant, just ask me. But, I’ve been wrong before. I’m married, trust me, I’ve been wrong before. You gotta kinda have the dialogue, figure out, like, you know, it’s your system, I can give you recommendations, I can tell you what the policy is. I can tell you how I would do it, right? And if you choose to wrap everything in one big program of record package, you know, boundary, then by all means carry forward and do great things.


Max Aulakh: [00:22:43]
Yeah. I’ve seen a lot of people accrue. We call it compliance debt, right? Like, oh, man, shouldn’t have done it that way. But you’re right. Some of this stuff within the boundary can be totally abstracted out like management controls, things like that, which is nice. You know, I did a LinkedIn post on this Naveed and we’ve got some interesting responses from a lot of different people. John Allison. I think he’s been in the community for quite some time. He’s a prior Air Force guy. He’s working at Checkmarx, the source code analysis tool of Brian. Who’s we’re at Tanium. One of the things you mentioned is. Hey, this is very similar. It’s got a, it’s got some relationships to systems thinking and, and, you know, a bit of like design and, and systems. And so tell us about that. What do you, what did you mean by that? And how is that related to this?


Naveed Mirza: [00:23:33]
So there’s the older concept of systems and systems of systems. Right, and really, at the end of the day, that’s kind of the boundary, like you know, I’ll be very D. O. D. for a moment. A system has a mission, and what it, all of the components it needs to accomplish that mission should be part of its system. Now, Does that mean that they’re not broken up into systems of systems? You know, maybe, like I said, the control plane might be a subsystem you know, the you, I, user, you know, input side might be another system so you can, you can break those things on to those logical, those logical bit buckets. And if you can break those on the logical bit buckets now, it’s really just a matter of does each bit bucket become its own boundary. Can I do sub boundaries in there? One of the things in the Marine Corps that we really tried to tackle when we built our GRC tool. So the Marine Corps, for those of you who do DOD, everybody uses E mass except for the Marine Corps. And and, and when we designed our tool, we tried to build in the capability to do essentially like metadata tagging. So these components are part of this subsystem. So then that way I could do some neat things. Like if I were going to. Swap out everything as part of one subsystem. I had a way to do that and sort of semi containerize it within the one boundary. So we tried to build in that capability. Again, the more capabilities you add to something, the harder it gets for the end user, so your mileage may vary there.

But we did try to build that in so that I could then take maybe an entire base. And I could do one boundary for a military base. Okay, but now, that military base is composed of, you know, the cable plant, the network. But it’s also composed of the telephone system, which may be on its own network. Or what about all of the facility control systems that may be on their own network. Well, those are all part of the base, but are they subsystems? So, and it depends now, if all of those things are owned by the same organization at a particular base, roll them all together and tag them as subsystems. If they have different owners, make three different packages and inherit controls from each other.

Max Aulakh: [00:25:48]
Yeah, I see what you’re saying. Like, in terms of creating a bunch of subsystems, and I’ve used another, I’ve heard another term like sub SSPs and things like that, but. Man, looking at the same controls, I think we gotta get better at interpretation of the controls, because once we get down to it, my administrative policies are all taken care of by the base, or my physical security, right? There’s literally a guard fence. Like, don’t even show me those controls in my little tiny boundary that I’m dealing with. Because somehow, you know, this whole ATO thing takes a long frickin time.


Naveed Mirza: [00:26:23]
One of the hard problems and this is, by the way, this is a database problem. Okay, this is a database data management problem that you’re bringing up right now. But it is one of the really big areas where I think the 853 controls And some of the other NIST guides for how to apply those controls are kind of broad strokes right now. So I define a system and I get 400 controls. So that means 400 controls across this system. It doesn’t mean that each component has all those controls. It doesn’t mean that each subsystem needs all those controls. So how do I then, if I’m breaking something up into a subsystem, Or, you know, a set of subsystems. How do I apply controls logically to that? How do I make sure that the server in a closet somewhere doesn’t have a gates guard gun requirement on it that’s already being met by the base? And that’s kind of where. Doing a subsystem design and trying to really figure out that inheritance model comes in really handy.


Max Aulakh: [00:27:25]
Yeah, I agree. So I’m reading another comment is this guy. I can’t pronounce his last name. It’s a Polish last name, Brian. I’ve talked to him before. He’s a really smart guy over at Tanium cloud. He said, honestly, it was far easier to have an ATO package as a DOD and fed versus FedRAMP where everything is kitchen in the sink. And I think what he’s getting at is because. A lot of the FedRAMP systems, their boundaries, right, at Okta, I’m sure it’s the same kind of thing. You’re dealing with so many different cloud systems that are coming in, and you know, when you try to interpret that control, that technocratic control, that could mean both Policy and technology, man, I think it’s just like, super challenging for a lot of people who are not in the D.O. D. You know, and they’re trying to work with the D. O. D. And the FedRAMP Heisman is what they got to face, right? They’re like, ah.


Naveed Mirza: [00:28:21]
It’s, oh, yeah. So, one of the interesting things, and because there is a kitchen sink paradigm, but there’s a kitchen sink paradigm for a good reason. If I’m bringing a system into a Marine Corps owned and operated clowned environment or physical data center, who is my cybersecurity service provider? Well, it’s whoever that the branch of service is currently using. You know, maybe, maybe you’ve got, you’re, you’re an army system and it’s, you know, armies, you know, I can’t remember their name now all of a sudden, maybe it’s the McCog if you’re in the Marine Corps, right. And, you know, the developer stock operations group and they’re acting as your, your CSSP. I’m Okta, who’s my CSSP. Well, it’s Okta. So now I have to feel all of those controls. I don’t have anything I can inherit. I can hear it. Some of my boundary protections from my cloud service provider. I can hear, you know, from other providers out there. If I’m using their tools, maybe I can inherit some stuff from them. But largely, I’m taking everything from platform and sass, right? Paz and sass. And I’m doing it myself.

Max Aulakh: [00:29:25]
Yeah, I think it’s harder. It’s way harder. It’s way harder, especially when you, when you put it in the, in that sort of context with you know, with what’s going on with, with Octa and stuff like that. And man, I feel for you guys.


Naveed Mirza: [00:29:38]
You know what? I think the more you get beat up, the bigger you are, right? So, maybe it’s a good sign.


Max Aulakh: [00:29:45]
It maybe, maybe so, maybe so. But, but yeah, I think kind of back to the, you know, the point of this discussion is trying to help people understand what is a boundary. And I think we’ve done that in this short segment in terms of, it’s a lot more granularity and detail than just your simple SOC 2 controls, right? A lot of people are like, oh, I got my SOC 2, I’ll just take the description there and call it my boundary. But it’s far more detailed than that. And then, you know, in terms of trying to figure out how to leverage systems engineering practices, I think that’s the key. That’s the key. You,  we’ve got to break this down into smaller chunks to make it manageable because without it sounds like it’s nearly, it’s going to take a year, no matter what we do.


Naveed Mirza: [00:30:34]
Now soapbox time, but you know, you hit the nail on the head earlier when you said bacon security, and we’ve always said that, but then we always said, well, it takes me a year to get my ATO. Well, it should have taken you a year to build the system and the ATO should have been. Being developed at the same time that ATO package, that boundary, that system security plan should have been developed as part of the systems engineering effort, not the afterthought. And, and so a lot of folks, and I always catch people, myself included, like, what might take a year to get the ATO? Well, did it take a year to build the system? Because I should have been the same year.


Max Aulakh: [00:31:11]
Yeah, I agree with you largely, but man, there are systems that are coming online so fast. Especially SaaS environment, right? Like, if you got a platform, an infrastructure, a large application, it’s gonna take some planning and planning.

Naveed Mirza: [00:31:28]
Absolutely. And especially for those of us in the commercial industry that are trying for that FedRAMP or, you know, the analogous on the, the on the DoD side, which is the, the cloud security requirements grant, the cloud SRG, you know going through that we, we’ve already got a developed stack. We already have a developed system. We’re just trying to expand to support a new type of customer. And so now we definitely, we baked in security. We didn’t bake in DoD standards.


Max Aulakh: [00:31:57]
Yeah, that’s right.

Naveed Mirza: [00:31:58]
And so now we’re going back and we’re retrofitting to bake in those DOD standards and that’s going to take at least a year.


Max Aulakh: [00:32:06]
Yeah. That’s the reality. People don’t like hearing that, but that’s really what, what it is.


Naveed Mirza: [00:32:13]
One of my things I get a lot of friends, you know, a lot of my friends are in security, obviously, and in the commercial sector now, and the one piece of advice I always tell anybody is, Oh, you’re going to go work for a startup. Yeah. What are you using for security requirements? You know, some industry best practices. Hey, how about you open up this 853 and go ahead and figure out what security controls you need to me and start there? Because one day, if you are successful, you will want to service government customers you’re recession proof.

Max Aulakh: [00:32:41]
They are. And, and hopefully we change that one day, but for the long haul, it’s just, it’s there. It’s not, it’s not going to change. 

Naveed Mirza: [00:32:50]
Well, folks don’t want to hear that when you tell them, Hey, just started on this day, 153.


Max Aulakh: [00:32:55]
No, they’re like, get out of here. They’re like, what are you, what are you talking about?

Naveed Mirza: [00:32:59]
Hyper growth tech companies. We don’t need to fall. Okay.


Max Aulakh: [00:33:02]
Yeah. I mean, if you, if you look at the real hyper growth tech companies, they’ll grow and then they’ll do it or they’ll do it. From the get go right like I think if we look at Okta story the same thing they grew but then they said okay we want to work with federal you had to do it they weren’t like well now we’re just we’re super big we’re super massive we don’t have to do it now you. You may hack the process once, but to, to build a sustainable business as a SaaS firm, it’s one of those things you got to do. 

Naveed Mirza: [00:33:35]
And you know what we found though that was really interesting? So I wasn’t on the compliance side at Okta. But you know, so what we found is that the government is actually there to help like they want commercial vendors to meet their requirements. So, you know, it really does feel like, you know, all the different agencies that are working towards like FedRAMP. You know, certifications, things like that. They want us there, they wanna help and, and they want to make it, less difficult. You know so it’s, it’s not the, did you fill out the ID 10 T form? It’s like, Hey, just provide me this data.


Max Aulakh: [00:34:16]
No. Especially with you guys, I think, I mean, look, it’s credentials, right? Like , it’s necessary. And I, and would hope that they wanna be helpful when it comes to like, identity management, you know? It’s super critical and you’re 100 percent right. It’s, you know, no matter, you can’t even outsource the cybersecurity watchdog truly because it’s, it’s all coming out of your business application, your logic, and they’re not going to understand it. It’s not traditional SIM data that you can look at and correlate. So, Very interesting boundary for sure. Very interesting boundary. So. Well, man, I really appreciate you coming on the podcast. I think for those that are listening in that have never experienced what a boundary is. I think this is going to be one of the fundamental. Kind of lessons that we put together, but any parting thoughts anything else you’d like to mention for those that are just kind of maybe Listening to this and they’re understanding the concept of a boundary for a very first time.


Naveed Mirza: [00:35:18]
So for the new practitioners that are kind of, you know, you’re hearing about this for the first time, maybe definitely learn that process like, you know, I kind of hate saying pick up 837 and read it because That you’ll fall asleep. It’s a big boy, but understand what the steps are. Therefore, it’s very easy to get caught up in the Oh, my goodness. This is just paperwork. But if you actually look at what each step of that process is trying to do, it’s actually trying to do something important. So if you understand those steps. Then you really can kind of, you know, separate the fluff from the important stuff, you know, it’s not always about filling out the ID 10 T form. Oh my goodness. Do I need another MOA you know, to cover, you know, do I need another agreement with somebody else to do this thing, or can I just really look at what the data is and decide, is this security relevant or not?


Max Aulakh: [00:36:13]
Awesome. Well, with that, Naveed, will you. Appreciate your time.

Naveed Mirza: [00:36:16]
All right. Well, thank you, sir. I Appreciate you.


Max Aulakh: [00:36:18]
Thank you for tuning in. If you enjoyed the podcast, head over to ignyteplatform.com/reckless  You’ll find notes, links, and additional content head over to iTunes to subscribe, rate, and leave a review.