Welcome back to the deep dive, everybody. Today, we're going deep, really deep into the weeds of something that's a a bit of a must know if you're dealing with Department of Defense contracts. Yeah. It can be a bit much. Right? Yeah. We're talking about, DFARS clause two five two point two source seven zero twelve, which is, quite a mouthful. A real mouthful. It's all about safeguarding, you know, keeping safe that cover defense information and, what to do if something goes wrong, specifically cyber incident reporting. Exactly. And we're looking at the most up to date version, the May '41. So this is your, kinda your survival guide. Right? It is. Yeah. Survival guide. To navigating the world of cybersecurity when you're working with, sensitive information, you know, for the DOD. We'll break it down, make it clear, you know, so you know what you need to do. Absolutely. So, I mean, this clause, it's dense. It's packed with, with a lot of details. We're gonna try to pull out the really important stuff, the key definitions, the things you absolutely have to know about security, and, walk you through exactly what to do if a cyber incident, you know, if that actually happens. We want you to have those moments where you're like, okay. I get it now without, without getting too lost in all the technical details. Right. Practical, actionable insights. That's what we're aiming for. Exactly. Exactly. So let's jump right in. First things first, we've gotta, we've gotta sort out some of the language, the key terms that are used in this call. So you see things like adequate security thrown around. What exactly does that mean, you know, in practical terms? So adequate security basically means, you know, you have to take protective measures. Right? But they have to be appropriate to the potential harm that could happen if the information you're protecting, if it gets lost, misused, or someone gets to it who shouldn't. And you also have to consider how likely that is to happen. So it's not just about checking boxes on a list. It's about being smart and really assessing the risks you're facing. So a small business working with, like, less sensitive information might have different security measures than a big contractor handling, like, the really top secret stuff. Exactly. Different situations, different risks, different measures, but all still adequate in the eyes of the class. Makes sense. Now another one that pops up is compromise. That sounds pretty serious. What does that actually involve? What falls under that category? Yeah. Compromise is a big one. It means, essentially, that information has been disclosed. You know, it's gotten out to someone who shouldn't have it or that the rules the security rules of the system have been broken. This can happen in, in a couple of ways really. It could be intentional like a hacker breaking in, or it could be a total accident like an employee emailing the wrong document to the wrong person. And it covers a lot of ground. Unauthorized access, modification, destruction, loss, even just copying something you're not supposed to. Even a little slip up could be a compromise in the eyes of this clause. So anything that puts the security of the information at risk, whether it's intentional or accidental, falls under compromise. Yeah. Exactly. Got it. Then we have contractor attributional proprietary information. A bit of a mouthful, but what kind of information are we talking about here? What fits into that category? Yeah. That one's a tongue twister. It's basically any information that could identify your company. Alright. Right? Could be direct, like your name, location, or even information about your facilities. Or it could be indirect, like a bunch of different pieces of data that when you put them together could lead back to you. It also includes things like PII, personally identifiable information about your employees, trade secrets, any commercial or financial data that you wouldn't just, you know, share publicly. Think of it as the information that makes your business your business. So the information that distinguishes you as a contractor, how you operate, all of that. Precisely. Okay. Next up, we've got controlled technical information. This one sounds pretty specific to the defense world. What's the key takeaway here? This is technical information, you know, blueprints, designs, that sort of thing, that has a direct military or space application. Because of that, it needs to be controlled, you know, who can access it, use it, copy it, all of that. And the key thing is, if this information were to get out without those controls, it would meet certain criteria laid out in a DOD instruction, specifically distribution statements b through f. But it's important to note that if the information is already publicly available legally without restrictions, then it doesn't fall under this category. Mhmm. So think, like, detailed schematics for a fighter jet, but not general knowledge about aerodynamics that anyone can find in a textbook. Yeah. That makes sense. So it's that specific controlled technical data, not general knowledge. Now where is all this information typically stored? The clause talks about a covered contractor information system. What is that exactly? Basically, it's any unclassified IT system that your company owns or operates or that someone else operates on your behalf that handles, stores, or transmits covered defense information or CDI, which which we'll talk about more in a minute. So it's your computers, servers, networks, the whole IT infrastructure where this sensitive data lives. It's the digital space you need to secure. Okay. So it's the digital environment where CDI is handled. Right. And speaking of CDI, let's get to that. What exactly counts as covered defense information? So CDI has two main parts. First, it's that unclassified controlled technical information we just talked about, that really sensitive technical data. Second, it includes other types of information that are listed in the CUI registry, the controlled unclassified information registry. You can find that list online at archives.govcareerregistrycategory-list.html. Basically, it's a big list of unclassified information that the government considers sensitive and wants protected. So it's either that specific military or space related technical data or other sensitive but unclassified information that's on this official list. Exactly. And that there's a really important point here. You know, how do you know if something is CDI? It's CDI if it's marked or identified in your contract and given to you by the DOD or on their behalf. But it's also CDI if you, the contractor, collect, develop, receive, transmit, use, or store that information while you're working on the contract. So it's not just about what the government gives you. It's also about the sensitive information you handle as part of your work for them. That's a crucial point. It's much broader than just government furnished data. Right. Now even with the best security, things can go wrong. That's where cyber incident comes in. What does that term mean in this context? A cyber incident is any action that happens on computer networks that leads to a compromise, like we talked about earlier, or that has a bad effect, whether it's actual or just potential on an information system and the data it holds. It's a pretty broad definition. It covers everything from a small glitch to a a full on breach. So it doesn't have to be a total system failure. It's any event that negatively impacts security or or data. The clause also mentions forensic analysis. What would that involve if an incident occurred? Forensic analysis is the process of collecting, preserving, and examining computer data for an investigation. The key is to do it in a way that doesn't change the data so it can be used as reliable evidence. It's like a digital crime scene. You need to be careful not to contaminate the evidence. Yeah. Maintaining that digital chain of custody. Okay. We also have the term information system. Seems pretty straightforward, but what's the specific definition here? It's any organized set of resources, you know, hardware, software procedures that are used to manage information, collecting it, processing it, storing it, using it, sharing it, transmitting it, even disposing of it. It's the whole system that handles data within your organization. Okay. Then we have malicious software, which I think most people have an idea of what that is, but what's the official definition we're working with here? Malicious software is any software that's designed to do something bad, you know, something unauthorized that negatively impacts the confidentiality, integrity, or availability of an information system. This includes viruses, worms, Trojan horses, spyware, even some types of adware. It's anything designed to cause harm or gain unauthorized access. Okay. So anything with harmful intent or unauthorized access capabilities. Got it. The clause also refers to media. What does that encompass in today's digital world? Media here refers to any physical thing that CDI is stored on. Think tapes, disks, hard drives, memory sticks, even printouts. It's any tangible form where that digital information can be held. So even physical copies fall under that definition. Exactly. We also see the term operationally critical support. Why is that specifically called out in this clause? This refers to supplies or services that the government has identified as essential for military operations. You know, things like deployment, transportation, logistics. If a cyber incident disrupts your ability to provide that support, it triggers specific reporting requirements because it could have a serious impact on national security. So it's about the services that are vital for the military, especially in critical situations. Exactly. Okay. And then we have rapidly report. How fast is rapidly in this context? Rapidly report means within seventy two hours of discovering a cyber incident that meets the reporting criteria. So you don't have a lot of time. The DOD wants to know about these incidents as soon as possible. Yeah. That's a tight time frame. Definitely emphasizes the urgency. Definitely. And lastly, we have technical information, which seems to tie back to controlled technical information. How should we understand this term? Yeah. Technical information is a broad term. It means any technical data or computer software, and the clause points you to another DFARS clause, two five two point two two seven seven zero thirteen for the full definition. It includes things like research data, designs, specifications, manuals, reports, even the software code itself. Basically, all the detailed information that underlies the technical work you're doing. Okay. So it's the detailed technical information whether it's controlled or not. Right. That gives us a pretty good handle on the key terms in this clause. Now let's move on to the practical stuff, the actual security requirements you need to meet. The clause talks about providing adequate security. How do you actually go about doing that? Okay. So the specifics depend on whether you're using IT services provided by the government or if you're using your own systems. If it's a government run system, especially for cloud computing, there's a whole other clause, two five two point two three nine seven zero ten, that deals with cloud security. For other government operated IT services, the security rules will be spelled out somewhere in your contract. So if the government is providing the IT, they set the security standards. Exactly. Now for systems that you operate yourself that aren't on behalf of the government, you generally have to follow the security standards outlined in this special publication eight hundred one seventy one, which is called protecting controlled unclassified information in non federal information systems and organizations. The version that applies to your contract is the one that was in effect when the government solicited bids for the work or is authorized by the contracting officer. You can find the whole document online at csrc.nist.gov publications s p 800. It's a detailed set of security controls you need to put in place. Okay. NIST eight hundred one seven one. That's a big one. When were contractors originally expected to have these controls in place? For contracts awarded before 10/01/2017, you were supposed to have all the NIST s p eight hundred one hundred and seventy one requirements employed as soon as possible, but no later than 12/31/2017. If you hadn't done that by the time of the award, you had to notify the DOD CIO within thirty days. Okay. So that deadline has passed. What if a contractor thinks a specific security control in NIST eight hundred one seventy one doesn't apply to their situation? What can they do? You can submit a written request to the contracting officer asking to deviate from that specific requirement. The contracting officer will then send your request to the DOD CIO. If the DOD CIO agrees that it doesn't apply or if they approve an alternative security measure that they think is equally effective, then you don't have to implement that particular control. And if you've already gotten approval for a non applicable requirement or an alternative measure on a different contract, make sure to give a copy of that approval to the contracting officer. So there is a process for seeking exceptions or alternatives, but it has to go through the proper channels. Right. Now what if a contractor uses a cloud service provider to handle CDI? Are there any specific rules for that? Yes. If you're using an external cloud service provider for CDI, they need to meet security standards that are at least as good as the FedRAMP moderate baseline. FedRAMP is the federal risk and authorization management program. You can find info about it at at fedramp.gov documents dash templates. And on top of that, the cloud provider has to agree to comply with the specific clauses in DFARS two fifty two point two zero four seven zero twelve that deal with cyber incident reporting, malware, media preservation, forensic access, and damage assessment. So it's a two part requirement. So it's not just about meeting a general federal standard. They also have to specifically adhere to these DOD cybersecurity rules. Yes. What about if a contractor wants to go above and beyond NIST eight hundred one seventy one and implement even stronger security measures? Is that allowed? Absolutely. The clause specifically says you can put in place extra security measures if you think they're needed to provide adequate security, especially given the constantly changing threat environment. So for example, you might need enhanced security for specific devices on your network, or you might temporarily implement stronger measures while you're fixing a known vulnerability. Just make sure to document any additional measures in your system security plan. So the clause sets a baseline, but it encourages contractors to be proactive and enhance their security as needed. Exactly. Now let's talk about what happens when, despite all these precautions, a cyber incident does occur. What triggers the reporting You have to report if you discover a cyber incident that affects a covered contractor information system, the CDI, on that system, or if the incident affects your ability to fulfill the contract requirements that have been identified as operationally critical support. So it's not just about data breaches, it's also about incidents that could disrupt essential services you're providing. And once you discover an incident that meets those criteria, what actions do you need to take? First, you have to do a thorough review to see if any CDI has been compromised. Look at all the affected systems, data, and user accounts. This review should include not just the systems directly involved in the incident, but also any other systems that might have been accessed as a result. The goal is to find any CDI that might have been exposed and to see if your ability to provide operationally critical support has been impacted. Then you need to report the incident to the DOD as quickly as possible. And rapidly report means within seventy two hours. Right? Seventy two hours. Where do you actually submit these reports? Reports? All cyber incident reports have to be submitted through the DIBnet website, https.divnet.di.mil. That's the official channel for reporting these incidents. And what information do you have to include in the report? The cyber incident report is considered information created for the DOD, and it has to include certain specific details. You can find those details listed on the DADET website. Make sure you familiarize yourself with those requirements so you can provide a complete report. To submit the reports through DIB Net, do you need any special credentials? Yes. You or your subcontractor, if the incident happened at their level, need a DOD approved medium assurance certificate to report incidents through DIB Net. You can find information about getting one of these certificates at hetps.public.cyber.milica. So there's a level of authentication required to ensure security. Makes sense. What about malicious software? If you find malware related to an incident, what do you do? If you find and isolate malware related to a reported incident, you need to submit it to the DOD cybercrime center or DC three. Follow the instructions they provide or the instructions from your contracting officer. Don't send the malware directly to the contracting officer. It has to go through the proper channels. So there's a specific process for handling that kind of evidence. What about preserving other evidence related to the incident? As soon as you discover an incident, you need to preserve images of all the affected systems, including monitoring data and network pack it captures, you need to keep this data for at least ninety days from the date you reported the incident. This gives the DOD time to request the data for further investigation or to tell you they don't need it. So that's a pretty significant data retention requirement. What if the DOD wants to do a deeper investigation and needs to conduct a forensic analysis? What's your role in that? If the DOD asks, you have to give them access to any information or equipment they need to do a forensic analysis. This ensures they have everything they need to understand what happened and gather evidence. Cooperation is key here. And what happens if the DOD decides to conduct a full damage assessment? If they do a damage assessment, the contracting officer will ask you to provide all the damages assessment information you've gathered. So the data you've been holding on to becomes really important. So it sounds like there's a lot of emphasis on collaboration and information sharing after an incident? Yes. Definitely. The clause also talks about how the DOD will handle the information they receive from contractors, especially that contractor attributional proprietary information we talked about earlier. What protections are there for contractors? The government knows that you're sharing sensitive business information when you report incidents. The clause says that the government will protect this information from unauthorized use or release. You're supposed to clearly mark your attributional and proprietary information as much as possible to help with this. And if the government has to release this information for an authorized purpose, they'll try to minimize the inclusion of your specific business details. So there are safeguards in place to protect your sensitive information when you have to share it. What about sharing this kind of contractor information that wasn't originally created for the DOD outside of the DOD? What are the rules there? The clause lays out specific situations where this type of information can be shared outside the DOD. This includes sharing it with entities whose missions might be affected, with organizations that can help with incident response, with law enforcement or counterintelligence agencies, for national security purposes, and with certain support service contractors. It's all about sharing with those who have a legitimate need to know. So it's about sharing with trusted partners for specific purposes. What about contractor information that was created for the DOD, like the incident reports themselves? Are the rules for using and sharing that information different? Yes. For information created for the DOD, including those incident reports, the authorization for use and release outside the DOD is broader. It covers all the purposes we just talked about, plus any other lawful government purpose, as long as it's consistent with applicable laws and regulations. Okay. So the government has more flexibility with information it created or requested. Right. The clause also has a section about complying with laws and regulations. What's the main takeaway there? Basically, it reminds you that everything you do under this DFARS clause has to comply with all applicable laws regarding electronic communications and data. Mhmm. You can't use this clause to justify breaking any other laws. Right. So you still have to follow all the other rules and regulations. Exactly. Does this clause replace any other cybersecurity or reporting obligations you might have under your contract or other government regulations? No. It doesn't. This clause adds to rather than replaces any other obligations you have, so make sure you're aware of all the applicable requirements. So you need to have a comprehensive understanding of your cybersecurity responsibilities when working with the DOD. Finally, let's talk about subcontracts. What are your responsibilities as a prime contractor when you have subcontractors working on a DOD contract? As a prime contractor, you need to include this entire clause, including the section about subcontracts, and any subcontract you issue for work that involves operationally critical support or CDI. This even applies to subcontracts for commercial products or services. You have to figure out whether the information your subcontractor will be handling counts as CDI and needs protection under this clause. If you're not sure, talk to your contracting officer. So the cybersecurity requirements flow down to the subcontractors. What specific obligations do they have? If they wanna ask the contracting officer for permission to deviate from NIST eight hundred one seventy one, they have to tell you when they submit that request. Also, if they have a cyber incident and report it to the DOD, they have to give you the incident report number as soon as they can after submitting the report. Okay. So prime contractors need to make sure their subcontractors are following the rules too. Well, that was a pretty deep dive into DFARS clause two five two point two zero four seven zero ohms. What would you say are the the absolute key points for our listeners to remember? The big takeaways are the importance of safeguarding CDI, using at least the NIST SP eight hundred one seventy one security controls, and the strict seventy two hour reporting deadline for cyber incidents. Remember, you need a medium assurance certificate to submit those reports through Deep Net. Also, make sure you're preserving evidence, understand how the government can use and share information, and remember that these requirements apply to your subcontractors too. So whether you're a big prime contractor or a small subcontractor, understanding and implementing this clause is crucial for working with the DOD. It's about protecting sensitive information and ensuring the cybersecurity of the defense industrial base. Right. It's much bigger than just checking boxes. It's about national security. Exactly. And for our listeners, understanding this clause gives you a glimpse into how seriously the DOD takes cybersecurity and the detailed framework they've created to address it. Yeah. It's a complex world, but the DOD is trying to be proactive and collaborative in tackling these challenges. That brings us to our final thought for today. We've seen how the DOD is handling cyber security with this clause with its focus on strong security measures, timely reporting, and collaboration. Do you think these principles could be applied to other sectors that handle sensitive information even outside of defense. What can we learn from the DOD's approach, and how can we adapt it to protect data in a world where cybersecurity is becoming increasingly critical? Something to think about. Thanks for joining us for this deep dive. Thanks for having me.