Securing Custom Software: Documenting Software Security Controls for CMMC Compliance

[00:00:01] Hello Climbers and welcome to Season 3 of Climbing Mount CMMC. Welcome back Climbers, today we're joined by Kyle Lai. Kyle, thank you so much for coming back on our show. In case you all haven't noticed, Kyle was on our Season 2, right Kaylee? Yeah, yeah. It's been a while now. So thank you for joining us today, Kyle. Yeah, absolutely. Really glad to be back.

[00:00:27] Now, we're recording on Easter, Good Friday. Yeah. Yeah, so we're doing Good Friday, so I'm not exactly sure when the episode will be released. So thank you for even on a holiday appearing to come on the show. We really appreciate it. Yeah. And because it's a holiday, we're together. So we're on the same screen. Right, yeah. So you may notice that like, I can, yeah, I can... We're on the same screen. We're on the same screen. Although, audio-wise, if you're listening on Spotify, you may not be able to. But trust us, we're in the same room. Yeah. Right.

[00:00:58] I'm excited. I can see you both. Yeah, yeah. So one of the reasons why we wanted to have you back on the show, Kyle, is to have a better idea of what you're seeing in the ecosystem. But before we do that, I would like to ask you, I just tend to want to know this for anyone that starts a C-3PO, like what made you, what possessed you to start your C-3PO?

[00:01:20] Because that's a tough challenge doing that. Because it, the ecosystem is still in its infancy. And it's very challenging for C-3PO's to navigate that, being the fact that it's in such an infant state. Like, can you share about why you decided to do that? Sure.

[00:01:37] Earlier in my career, I was a third party. I was doing a lot of third party security risk management assessment. So I actually built up the third party risk management program for Fidelity Investments back in the mid-2000s. So I have really enjoyed doing the assessment. And the CMMC, if you think about it, is not really different from conducting the third party because these are the supply chain, right?

[00:02:04] The supply chain risk management. And I really enjoy being able to do the assessment, identify if there are some gaps and to help companies just do better on their security.

[00:02:16] So I've been doing this since about 2006 until now. Back in 2009, 2010, I was at DISA as an operations manager, as a contractor. So that's how I got into the DOD side of the business. And I really feel that there is a niche that I will be able to contribute. So that's why I got into the CMMC and decided to become a lead assessor and also a C-3PO.

[00:02:45] Yeah. And I mean, for those people that may not know, like there was a lot of still undefined things for C-3PO is when they're stepping into the space. How do you feel now that audits are happening? Are you starting to see more light at the end of the tunnel around those types of things?

[00:03:02] I think there are still some processes are still being refined as we go, but yeah, things are getting better. At least we have the CyberAB and the DOD. We have the process, right? I mean, there are still some backend stuff that people usually don't see like a DOD E-MAS. The DOD and the CyberAB, they're still refining it. So there are still some work to do, but a lot better than before.

[00:03:28] Well, I mean, I guess like part of the surprise with 32 CFR is that you had to have two CCAs involved, at least at a minimum. Two CCAs. You know, and that was a bit of a surprise until the final rule that C-3PO's weren't quite expecting. Yeah. Actually, we need to have three because we need to have the QA. Right. Yeah. So yeah, QA, they don't do the assessment, but yeah, you need to have at least two assessors to do the assessment.

[00:03:54] Yeah, very challenging. A lot of risk involved with C-3PO's. Speaking about the risk, let's talk about false starts for those that may not know what that means. Basically, there's two big phases at the very beginning of the assessment. There's phase one, which the organization will sit down and go around scoping and they present the evidence and they talk through things with the auditor and the C-3PO. And then phase two is when you actually start going through all of the 320 assessment objectives.

[00:04:20] But the false start, what we refer to is they don't get out of phase one where they kind of they're in such a state, the organization getting assessed that they can't proceed because they don't have maybe an SSP or their SSP is just rudimentary at best. How are you seeing, Kyle, the ecosystem with audits that are happening? Are you seeing false starts where organizations are coming to you and they're just not ready? Like, are you can you give us a bit of a pulse about what you're seeing there?

[00:04:47] Yeah. So right now, because we are still in the very early of these assessment. So people that tends to start the assessment right now, they have been ready for a while. So we don't see too many of a false start and they probably have been ready for a few months. They're just waiting for the time to start. So all the ones that we have assessed, they are ready.

[00:05:15] So they actually all passed and they already got their final status certificate. You know, once we are done with the certification assessment, the actual completion of the assessment, if there are any gaps or deficiencies or anything that's trending not met, the OSC, they will have 10 business days to address these type of deficiencies, providing that they are not impacting other controls.

[00:05:44] Right. So one of them does did have did have to go through that. But otherwise, yeah, they have been pretty smooth. You know, and I didn't really pay attention to that 10 day period. And as we started coming in for the landing for our audit and start, you know, I started rereading through 32 CFR because, you know, we did ours in January and the final rule hit in December. We were like, oh, man, these 10 days, this is a big deal.

[00:06:09] This could be a huge saver for some people that could be the difference between having to go back and see you in, you know, a few months versus finishing their assessment and getting a certification. And that's a lot of money on the line there. Right. But the devil is in the details. The detail is that, yes, you can remediate some of these deficiencies, providing that that deficiency is not impacting other controls.

[00:06:37] Right. So it's like, oh, we haven't implemented change control. You're like, no. You can't fix that in 10 days. Yeah. So, yeah, there are some caveats to that. But I think what is really the frustrating thing about CMMC in a lot of ways is there's. When it was first sort of looked at, the human factor didn't seem to be part of the equation that people are going to make mistakes. There's going to be problems. And it just seemed like there was almost such a drive for perfection that was almost unfair.

[00:07:06] But when you have situations like you've got the 10 days now, you have, you know, some poammable items as well. Well, there's some elements in there that if you fall into the human bucket, that if you have a valid system, you spent the time and the due diligence are required and you just made a mistake like anyone could. You can work your way out of it, assuming you haven't just been negligent. Yeah.

[00:07:31] And if there are some kind of like a documentation, just need to update the documentation, spelling errors. Those are just minor. They were able to correct some of those deficiencies or mistakes during the assessment. That assessment usually runs one week, so they can make those changes during that week. But for something like, yeah, we're missing like a change management control or something that's bigger configuration changes.

[00:08:00] You know, configuration was mistakenly changed to something else. And yeah, that type of deficiency may not be able to change during that 10 days. And they have to go to poammable condition. Yeah. That's a huge deal. That's such a good point. The people that have taken it very serious and spent a significant amount of time trying to be ready should be able to pass. Yes.

[00:08:24] And usually it's good to just walk through right before the actual assessment, have your internal or have somebody to do the mock assessment. That's always a good way to prepare for the actual assessment. Let's talk about a topic that I think is near and dear to your heart, and that's software development because of your history and past. You know, you've had a lot of experience in working in the software development industry.

[00:08:48] This is an area that I don't think gets enough light shined on it, given the fact that if you have data that software that you may have developed or have a hand in developing touches, it could get really interesting. And so we wanted to spend a little bit extra time today to talk about that and about some of the pitfalls around it and to try to shine a brighter light on that topic. Yeah. Yeah.

[00:09:12] But one of the things that I think is super scary to kind of like start the conversation is the echo chamber factor, that if and when you're working on your journey for CMMC, many organizations, because they're all working on their internal staff or whatever, they're all looking at it, they'll miss pieces because of that, yeah, yeah, we're right, we're right.

[00:09:32] Having that external person to kind of look at it, to catch those echo chamber problems where you kind of information bias yourself and believe that you have that. How would you recommend organizations that are trying to go through to get ready for level two certification? What are some ways that you would recommend that they kind of validate themselves so they don't get into that situation where they believe they're ready when they're not?

[00:10:01] Can you make some suggestions about how that they can try to protect themselves from that? First of all, I think you need to make sure that, I mean, it's just a reality that you have an IT group and they're a software group and they're a software security group. They usually don't talk to each other, right, unless you make them. And that is the problem in these organizations.

[00:10:25] When you have an IT, yeah, we will do the network diagram, we create a network diagram, but where's the software security or software architecture, right? Where's the software infrastructure? It's not there. So I think the software development or software management, software production group has to work with IT in order to come together and discuss, like, hey, what do you do?

[00:10:49] And when you are coming to the documentation, you need to take all that into consideration. So make sure you have somebody who actually see the bigger picture, like, you know, the architect, right? The enterprise architect that be able to see the entire picture and be able to pull, like, hey, IT, okay, we have this on our network diagram,

[00:11:12] but we need to have the software security or software group actually draw out that part of the infrastructure and include that into the network diagram and the scope. Because when we talk, when we are going through the assessment, right, and what we see is that the network diagram is missing,

[00:11:34] or when they are including people, they're answering questions like, oh, software, we didn't know you need to talk to the software people, right? Because we're asking some questions about, okay, so how do you do the software development, right? If you have API, do you have API and IT group that cannot answer those questions, right?

[00:11:58] So you need to have the software people come in, and some of the infrastructure are not managed by IT, right? Web application firewalls, for example, API managers, you know, WAF, or some of the, some of like the Azure DevOps, if they are using the Azure environment, those are not managed by IT. So, yeah, so you need to get these groups together, so they will be able to talk and they'll be able to include,

[00:12:27] especially when you're developing SSPs, controls, yeah, IT, they document all the controls beautifully, right, for all the controls, all the hardware and software they know. But the other side, all the support infrastructure, web application firewall, web servers, load balancers, those are in your environment, but those are not documented.

[00:12:51] So you need to work together to get those documented as configurations and network diagrams. Is there, like, is there reason that this is happening a lot? Because a lot of companies are trying to separate those development teams and not successfully doing it? Or where is that kind of disconnect happening?

[00:13:15] Software developers, they don't speak, I mean, software developers, they do speak some IT, but for their own bubble, right? But IT, they don't speak software development. What language do you use? What open source? What vulnerability scan? Those are all managed by the software. When you talk about software, that's all managed by the software security software team. Yeah, so that is very, very different.

[00:13:44] So unless you get them together, IT, they just assume software group, hey, you guys do your own thing. You know what you're doing, so you manage your own. And sometimes the way that happens is that software development group or software group, they do have privileged access to their own environment.

[00:14:08] So they can do their own configuration, but they just usually have their own separate environment. They just don't talk to each other unless they have to. Yeah, I've noticed that a lot. And when we go sometimes to come in to start doing consulting, there's almost like, you know, left hand, right hand. Yeah. Through the IT department is kind of staring down the development department. They're like, all right, what do you absolutely need?

[00:14:36] And then you give them what they need, and then it's like, now leave me alone. Yeah, I feel like you're even farther away than a left hand or right hand, because they're like, they're doing something over there, and they're working, but I don't know what they're doing. That's a common thing that we hear. And so I guess to hopefully not try to put words in your mouth, but trying to make sure that you pull all the parties together so that you can high level, make sure that there are things that aren't going to be revealed during the audit because you have the experience to ask the right questions that they didn't,

[00:15:06] and you don't want that coming out in the audit. How about having, you know, a third party organization look at that? Yeah.

[00:15:43] 3.13.2, right? Right. 3.13.2, they talk about, yeah, do you have the software or system development lifecycle? Yeah, that's just one control. But when we're looking at these, when we're looking at the controls, say, do you have the software infrastructure? Yes, we have software that's running, that we actually provide API, right? So, okay, now we're looking at the API and your API manager, your web application firewall,

[00:16:11] your web server, load balancer, everything, right? Now, how do you actually secure these? What is the access control? Who have access? What are the authorization, right? What are the IDs? And that all span across a lot of different security requirements in the CMMC, right? In the state 100-171. It's not just that one control. It's many controls. So we really have to plan and document.

[00:16:41] You know, when we're looking at the API, you know, API is one of the software. Who have access? Okay, is that internal or external? Okay, if you assign these accounts to the external users, okay, now you're exposing to the external users. How do you manage that? So there are a lot of controls. Now we are getting to 3.1.20, the CY flow. How does that flow?

[00:17:06] So, yeah, so you need to have somebody who understands software and the CMMC in order to help you. And, I mean, there are different ways of charging for these consulting firms. So I cannot really say how much it will cost. But, yeah. But I think there are definitely some good, you know, consulting firms that are specialized in this.

[00:17:32] One thing that we've seen that's been helpful is if you do a lot of the laid work when you get a consulting organization involved, you can really reduce the cost and present the right information so you can get a good, relevant response in a shorter period of time. Here's what I mean by that. So what if you took your whole architecture of your development, your software plan, your architecture,

[00:17:59] you spent the time and mapped it all out, and you talked with the different parties, and that's all something that an organization should be capable of doing, right? They should know all of that. Have that documented out. Then you pull in a consultant. Yeah. To then at that point have relevant discussions about how your architecture works and what you're thinking about your scoping.

[00:18:22] You know, that could then be, you know, a half a day conversation, not weeks of conversations of where do you have here? What do you got there? Like if you do all the legwork and you put them together, you know, that can be a very effective half day to a full day money spend. Yep. And you can get a really good idea if you've been echo chambering yourself into a lot of trouble. Yeah, absolutely.

[00:18:45] Yeah, and usually before you get the consultant in, that's a good point because I also want to suggest that if you are going to get a consultant in, make sure the software development group or software production management group, they have what they call the software requirements specification, right?

[00:19:07] Documentation that usually specify what is the ID requirement, access control, encryption, all these. Where are the data? What the data type is going to be? They have a lot of these already defined in the software requirements specification document, right? SRS document. And also they usually have something like a software reference architecture that tell you,

[00:19:33] basically specify all the infrastructure, web server, or what other components you actually need within the software, right? To support the software, to make the software run. And these are the components that will be drawn out and you know how the CY, how the data flow through the software. So that is very important. And if you have those, I think that will really help when you are going through the documentation,

[00:20:01] the actual documentation of your SSP because they actually just go across a lot of different domains, different requirements within the CMS. I mean, it's a lot easier for organizations once they kind of see what right looks like, at least a version of it so they can kind of go, okay, well, now I can work on it myself and make something similar that's relevant to me to do those. So that's very helpful.

[00:20:27] So like IT, you know what the IT diagram, network diagram look like. But usually what's missing is like, oh, one section. If you do it right, there's one section that's like a software, right? Software. And then we have these specific software that's running or actually a development environment. If the source code is part of the CY, you have the development and the production. And then what's it look like?

[00:20:53] Yeah, you have the drawing of the web server, get the repository or the source code repository with different components all within the box. That's what's missing usually. Yeah, that makes sense. Let's dive into that development part that you were talking about because you touched on that. Let's dive deeper on it. What are some ways that people can know whether the software that they're developing or the data that they're using,

[00:21:21] the software they're developing is CUI? Like, how do they know how to deal? I mean, because that is just a big iceberg for people to start kind of wrapping their head. Can you provide some guidance so they can start thinking about that? I know it's a big ask to magically know all of it, but just maybe provide some insights. Yeah.

[00:21:41] So if the development environment, is it CUI or not, I think that all has to be specified by the contract. Gotcha. So usually the contract should specify what type of information within the contract is considered CUI. If they say source code, yeah, then development environment, because you are developing it, developing the source code,

[00:22:08] that environment will be considered as CUI. So when we're going in to assess, we'll assess your development environment as well. And when we're talking about development environments, that's your source code repository, like a Git or GitHub or a Git repository. Right. And also your development, your pipeline, if you are using the DevOps methodology.

[00:22:34] And usually there are like, if you are using Azure, what's your Azure DevOps look like? What's a pipeline? If you are using others, but that's fine. We just want to look at the pipeline. How do you actually go from development to test to production? What does that pipeline look like? And how do you do the release and the deployment of the code and the to production? What's the change management process look like? Because that is very important.

[00:23:03] These days, if you are using pipeline, once you're authorizing the change, then it's automated. You go to the production. So it's very important to actually get that change management documented. And we're going to look at the change management and make sure that the pipeline is actually working as advertised. And the authorization, you know, your change management approval process is solid.

[00:23:31] Now, as an auditor, you're not correct me if I'm wrong. I could be making an assumption or be wrong. You're not being you're not expected to know that you're expecting the client, the person that you're assessing to. They should. Right. Oh, yeah. Because you're not looking at the page code to know that. We are looking at the documentation, their process. Right. We're looking at their process.

[00:23:52] But their process, it's just like you have to know the software in order to know the software development process and the software cycle in order to know that OSC is actually documenting things that's properly. Right. So, yeah, it's important to especially when you're selecting a C3 PAO and also somebody consultant that's helping you make sure that they have the background.

[00:24:22] If you're a software development organization, there's these people that are doing the assessment also have that background. Because otherwise they'll be asking the wrong questions. Speaking of that, what has been the most challenging part about assessing kinds of organizations like this that have software development side to it?

[00:24:49] What has been the most challenging part of that in your eyes, in your perspective? Yeah. So, I think these are not really frustrating, but sometimes they don't have the right people in the room. Yeah. And I think it's all – sometimes they are a little bit surprised that we are asking them about the software.

[00:25:18] It's like, yeah, software is – yeah, it's in scope, but it's not within our responsibilities. Like, yeah, but it doesn't have to be your responsibility, IT's responsibility, but we still need to assess. Yeah, so we need to talk to the software development group, right, or software management group. But when they are in to talk with us, they have a lot of knowledge.

[00:25:42] But sometimes it will also be a little bit interesting is that you have the API. Then they start describing the API, how the API authorizes, authenticate it. And sometimes in one case, that particular API is provided to the customer. So they are actually assigning access to the customer.

[00:26:10] So they have a certificate, the tokens to access the API. So in that case, we have to dig a little bit deeper because now we have to make sure that the access is possible to outside. Yeah, so those are a little bit challenging because we don't – sometimes we're just like, oh, that's actually a lot more information than what we actually got, right? Right. Within the SSP or within the network diagram because it's not there. Yeah.

[00:26:39] So there are just a little bit surprises. Yeah. And also when we get into the configuration, one of the companies have to take 10 days is that when we're looking at the configurations, like, okay, so you have API, but where is it? It's not documented anywhere, right? So now – In that situation, are you going to give them a little grace to try to pull that documentation out or find it to provide that in the audit?

[00:27:07] They do have the controls in place. It's just not documented. Right. Yeah. So they do have the controls. Yeah. So they're not documented anywhere. So it's like, you know, where is this configuration? So can you provide it? Yeah. But when we actually did the test, yeah, it's there, right? The configuration is good, but it just – they are not documented.

[00:27:30] So we have to dig a little bit deeper during the assessment, but we always wish we can do a lot more homework before the actual assessment. No, absolutely. Yeah. I mean, you talked about API keys. You talked about certificates and, you know, APs and things like that. What – when you're working with companies that have, you know, that incorporated is – I mean, this is coming from a very naive perspective, so I'm just trying to understand.

[00:27:59] And with your system security plan, are there – is there things that should have been put into there that would help, you know, you and your assessment fast track that to not be like, oh, the dev team just came in and then all of a sudden there's a bunch of new things. Like, should that be mapped out somewhere inside of the system security plan to be able to understand and comprehend even beforehand? Yes. Yeah, absolutely.

[00:28:29] So I would say when we are assessing the configurations, for example, right, when we're assessing the asset, if there are access control in place, we're going to look at the access control for all the components, all the system tools that you have that have the ID and the authorization.

[00:28:50] So if you're using web application firewall, you know, web server, key vault, Git repository, we're going to look at the access control, right? These are going to look at the access control, right? These are going to be just another asset. Okay, you have all these components. Show us your access control, identity authentication, because, yeah, you still need to log into these systems to actually perform the development or the deployment, right?

[00:29:19] So we still want to, so, yeah, don't treat it as like it's a software component, it's something special. Treat it as just like it's another asset, right? Yeah. When you are doing the SSP, yeah, just make sure you, you know, if it's applicable controls in place, then just document it. Yeah.

[00:29:39] Well, I don't want to put words in your mouth, but it sounds like what you would want to see is like, for example, when you go to AC, you're going to want to see access control and IAM information about the software side of things. I do. Yeah. I would want to say even the software you create, right? Even the software you create, it will, you know, most likely there are going to be ID and passwords.

[00:30:08] If it's not, if it's not API, right? There are ID and passwords, maybe, right? And that you, do you need to have the two-factor authentication? Most likely you do too. So the software that you develop in production, yeah, we are going to take a look at that too. Vulnerability management, how do you manage the vulnerability? How do you do the vulnerability scan of your software when it's running, right?

[00:30:32] So those are going to be things just treated like another system, another tool, another asset. So when you're going through these, you know, these controls, yeah, just make sure you answer the questions as another asset. Yep. Our website. I'm not going to do a background check on it, but you definitely are going to do vulnerability scans on it, right? Vulnerability scan.

[00:30:58] And, yeah, and, you know, you define your frequency of how often you scan. Usually the software security, software vulnerability management, vulnerability assessment, scanning, they're a little bit different than IT, right? Because they need to do statical analysis. That's when you're scanning your source code.

[00:31:22] But when your production, when your software is running, they'll be scanning to see if there are any software-related vulnerabilities when the software is running, right? Cross-site screening and those type of... And chances are it's going to be different people, right? The IT department is going to be doing vulnerability scanning of the switches and the firewalls and the other pieces.

[00:31:46] But the vulnerability examination of the software development lifecycle is probably going to be somebody perhaps in the software side that might do that. Yeah. Obviously, it all depends on how the organization is set up. Right. But vulnerability scanning, just that scanning process, it may be done by IT, but the results might be just sent to the application.

[00:32:11] So you talked about, I love this, so you listed, we need to have the right people in the room. That has to do with including the dev team, you know, and they need to, the IT team and the dev team need to talk before this happens to know what's going on. Have the right people in the room.

[00:32:30] And then also treat the development side, you know, assets, you know, just like any other asset in your organization and list it out in your SSP just like you would any other asset. Are there any other things that you can think of that also have to do with this software development side when handling an assessment or, you know, an SSP or something like that? Yeah.

[00:32:55] So when, I mean, we're looking, when you're developing the software, modern software, they use a lot of open source, right? So open source components, open source packages, there are very few, if any, source code, modern software development, they are using, develop everything in-house.

[00:33:16] Because there are a lot of, you know, if you're using Python, there are PyPy, there are, you get, there are different open source packages that's already been developed. And nowadays, the developers, they assemble all these open source and, you know, just write a little code, but they have to know how to assemble these together. Right. But now you have to make sure now you monitor the vulnerabilities of these open source components, right?

[00:33:46] So now it's not only my vulnerabilities, it's all the open source vulnerabilities. So those, I mean, usually they are combined into the, they are combined to the source code scanner, right? They are secure code review, you know, statical analysis type of tools.

[00:34:10] They already included those in there, but that is something that software developers, they have to know that, yeah, that is something that you need to. Wow. Yeah. It's like, they all are walking on the same bridge to get there, but they're different, they're different things and different tools that you need to make sure are good to go. Right. So they cross over into your world. Yeah, no, that's huge. And is that something that goes with what you talked about before of the software development side of like what they have written down and what they have assessed on their side?

[00:34:40] Yes. Yeah. This is the vulnerability. Yeah. So when they're going to the vulnerability, how do they manage the vulnerabilities? Right. Vulnerability scanning, vulnerability management. How often do they scan? May not be on the source code, but on the production side, how often do they scan? Yeah. So that's, yeah. So those are important secret. There are, I mean, there are, one of the big thing is the secrets.

[00:35:10] So keys, API keys or certificate or whatever, right? There are secrets. Obviously, hopefully your statical analysis tool will pick up if you accidentally or really, you know, put your secrets into the source code. Yeah. No, no.

[00:35:33] So obviously you want to make sure that you have those type of source statical analysis, be able to pick up these type of vulnerabilities, critical vulnerabilities. Kyle, what are some things that people could do to try to reduce their risk around the software development side?

[00:35:52] I'd perhaps like, you know, we talked about how if someone was using Power BI that, you know, you could leverage the inheritance aspect of the fact that you're using Power BI, which was developed by Microsoft. And you can try to, yeah, it, you know, it could be part of the package that you would want to try to inherit at least as much of the components. Are there some tricks and things that you would see, not really tricks, I guess that's a bad word to use, but, you know. Buy the book. Yeah, right. Is there some underhanded shady stuff?

[00:36:20] No, I mean, like, are there some things that people could do that is to their advantage to help limit the scope or try to make it to where when they're doing software development, they're making life easier on themselves, especially when it comes to the audit? Yeah. So if you are talking about like a Power BI or like SharePoint, these platforms, some of them, I don't know the detail, but, you know, if they are all, all have the FedRAMP moderate authorized.

[00:36:50] Because if they are Microsoft, I know SharePoint, most likely they are already FedRAMP moderate. I'm not sure about Power BI, but if you can confirm they all have a FedRAMP moderate and a GCC or GCC high, the government cloud for Microsoft, for example, then yes, you will be able to inherit a lot of controls.

[00:37:12] You develop on SharePoint, there are some SharePoint applications or Power BI scripts or something that you develop, but underlying the platform, right, is already FedRAMP moderate or higher ITO authorization to operate. So you will be able to inherit a lot of controls. So, yeah, there's a lot of benefit of using platforms if it's already.

[00:37:39] And like also if you're using third-party cloud repositories or, you know, change management, you talked about DevOps and things like that. So if you're able to try to keep it, and then even better, what if you're leveraging single sign-on perhaps to your intra so that now you're getting all the SEM information that you're doing for your logging and management of it, you're able to grab, you know, you're centralizing. I mean, there's definitely some smart things that you can do.

[00:38:06] Yeah, so if you're developing within Azure, AWS, or Google, yeah, that environment, most likely they're all FedRAMP moderate or FedRAMP high already. So there are a lot of controls you can inherit. So you don't have to worry about. But if you start grabbing a lot of these other cloud options, that's all getting pulled in then if you start doing those types of things. Yeah, you just have to worry about the tools that you use.

[00:38:34] You don't have to further document the controls because they're inherited. Yeah, interesting. Well, thank you, Kyle, for your time, sir. I really appreciate it. Is there anything else that you feel you'd like us to cover? Yeah, so one of the questions that you mentioned that, you know, what kind of controls that should be documented? So our website, klcconsulting.net, you can go there and there is a resource. You can drop down the resource.

[00:39:01] There are a few security development principles. And also there is a spreadsheet documenting the application security related CMMC controls. So you can take a look. I mean, that's not considered consulting because it's just a template.

[00:39:19] So you can use that as a starting point to modify and tailor to your own principles and procedures. Yeah. So I think the big thing is that, yeah, IT and the software, security people, they just have to work together. They need to talk. That's all. Just talk. Hug it out. Yeah.

[00:39:47] But once they talk, you collaborate, and it will make the SSP a lot easier to document. That's awesome. Kyle, how can people connect with you to know more about you? Perhaps if they were wanting to get assessed and they, you know, maybe they have software development and they'd want to make sure that they're using a C3PO that understands those concepts. How can they reach out to you? Yeah. So me personally, it's, I'm on LinkedIn.

[00:40:12] Or they can just go to our website, klcconsulting.net, and yeah, you can just contact us from there. Awesome. Well, thank you so much for taking time out of your day, sir. I really appreciate it. Great. Thank you so much. Well, everybody, this was just a really good one, right, Kaylee? I mean, we, there's so many things. You know, I'm not really a software type person, but we run into it all the time. Potential clients, a lot of clients that we have that do this.

[00:40:41] So it's really cool to hear that perspective for sure. Yeah. And I think, again, like I stated at the very beginning, this is, I think, a topic that hasn't really had as much light shined on it that you really do want to pay attention because these types of things you don't want cropping up during your assessment when you're not expecting it. You want to make sure you're accounting for these things, that you are properly treating them like assets and process them completely with your SSP and you're handling them all appropriately. Yeah.

[00:41:09] So thank you so much for sharing your wisdom, Kyle. Absolutely. Yeah. We hope you guys enjoyed today's episode. Tune in next Thursday for another episode of Climbing Mount CMMC. But until then, guys, keep on climbing. See ya. All right. Take care. Make sure to follow us on LinkedIn and YouTube to stay up to date on the latest CMMC news. We hope you guys enjoyed today's episode and listen out for the next one. But until then, keep on climbing.