 And we are back and now it is my pleasure to introduce you to Adam. Thanks, mate. Hey, good afternoon, everyone. All right, this is on. Good afternoon, everyone. This talk is about how we as engineers can reach out to a number of colleagues in a traditional federal, like, defense contractor to really help wrangle compliance in a reasonable manner. It's a dawning task, a war on two fronts, at least. But what we'll see is that a lot of organizations already have the fundamentals already in place. Once that's understood among or across the organization, I think some documentation, a little bit of process improvement here and there, and metrics can exceed compliance and even make security a business enabler. It's security to make the CFO happy. I don't think it would be a DEF CON talk without some colorful language, so I'm going to hit you right up front. There it is. So just by a quick show, yeah, look at that. That is some raunchy technical gibberish there. So real quick, I'm sure most of you are familiar with some of these terms, but a line by line, so basically the top one, security controls. The next one is DoD standards for training. The next one is how organizations are supposed to protect controlled, unclassified information. The next one is how the Department of Defense has so many DEF CON groups that they go with entire phone numbers, just not the trunk. Just kidding. That DFAR clause is what folks in our contracting departments, or maybe even legal, are going to use the trace win standards actually go into contracts as they go out to the federal contractors. And then last, we have two maturity models from the kind of the origin as the Software Engineering Institute in Pittsburgh, Pennsylvania. They are the capability maturity model integrated, and then the cybersecurity maturity model certification, which is currently in development. So whose ears are burning? Who would be offended by that technical gibberish? Well, it's the entire DoD supply chain for starters, and as you can see, that's quite a few companies. We're here at Hacker Summer Camp. So folks that live and breathe business efficiency in companies, to them, the Department of Defense is the advanced persistent threat, and they are a tough and determined enemy. It's Hacker Summer Camp, so let's do some threat modeling. And we'll start out with our targets, or maybe our potential victims, subjects to attacks from this APT. So business side, we're going to see business development folks. So these are the capture leads trying to capture new business and new customers. And then there's program managers who execute existing contracts. On the internal support functions for a company, we're going to have finance, quality assurance, IT managers that are going to be targeted by these new standards and things. All right, so threat vectors. What forms do the threats come in? So for the business side, we're going to look at data calls, which are from other companies that want to partner on efforts. We've got requests for information or requests for proposals coming in from customers, and we've got statements of work and supplier statements of work. On the organization side, we have certifications that they may choose to go out and try to get approval for. And then audits from folks like the Defense Contract Management Agency. The third one is kind of a catch-all, and it can hit both the support functions and the business, and that's the questionnaire. So why is it so scary for these company leaders, so these department heads and business directors? Why would it make the CFO unhappy? And these are a list of pain points. So poor communication, possibly from business project to business project, as well as poor communication between the customer, so the DOD customer and the business. The reason for that is it's simply a lot of times it's a flow-down issue from the DOD to departments and agencies and so forth down our program office, and they really don't know how to communicate that to the contractor. The second thing is the security language. I think literacy is a big issue when we look at the security controls in the NIST Special Publications and kind of map that to what we do to provide services and systems to the government. Security that comes in at the end, I would argue, is the classic example of unplanned work if you're familiar with that term from DevOps practices. And lastly, a lot of these mandates and requirements, they kind of run counter to traditional contract execution work, cost schedule and performance count, but there's no real way to measure how well you did security, right? So they tend to get dropped. And fortunately that security is changing with this CMMC, which we'll cover again. So we've seen some potential victims in our organization. We know what the threats are. So what can we do to help out? Well, first of all, this is supposed to be a picture of, we're going to teach the victims how to out swim the shark for one. So how do we do security in our process faster and more efficiently, right? Because that's how we know how to do business, is to do things on time and on budget. It's just familiarity. Secondly, I would argue that really wrangling the compliance, not just taking the standards at face value with written form, but finding out how they apply to us and how we can tailor them to our processes that we have already, how we do things. To be a good lifeguard in your business, you have to enjoy working with other people across the organization, especially if there's few security folks in your group. But swimming preferred, but not necessary for this job. We've got a lifeboat. So training is a factor in this talk. One point that I wanted to make is this is kind of the view of security right now to a lot of people. You get this one piece of paper, this authority to operate, this certificate, and people think you're done, and then you move on and forget about security. So if it's not clear by now, we kind of need to train up to these business leaders to say, this milestone that we're going to have this compliance fire drill, that's not the end of the day. We want to do this easier the next time and get better and better at it. So there are many maturity models. This one is mine. There is no settled on cybersecurity maturity model yet for the CMMC. There are some out there, but this one's mine. So I already argued that level one is awareness. Security is the thing. And I think most people achieve that because they're afraid of it. Number two is the literacy. So really understanding the documents. Once we understand it, we can engage both tactically with our customer and really help them understand because sometimes we may be ahead of the curve in kind of knowing, you know, it's our systems, the things that we build. We should know how to put security in the right way and then strategic. So interacting with things that are ongoing, like the cybersecurity maturity model certification, which I think we all just missed a listening session hosted by NIST like on Thursday. So there's another three or four sessions. If you look at the CMMC website, you'll see their schedule. They have what they started this summer. Lastly, for our purposes, security needs to be a measurable cost. And this is a playoff. The CMMC, their kind of bumper sticker is security. They want to make security an allowable cost, which is a change from the past. So I say we make it a measurable cost. A history lesson. We are not going to be the first techies to have to work across the company to kind of satisfy process improvement or certification. Just a quick reference. This is the information assurance baseline. When we look at the 8570, 8140, this is a matrix of various technical and managerial roles and security-specific roles. I put this up here. I wanted to show that, well, generalist certifications get a bad rap. If you don't have a well-defined security group yet, the generalist certifications give you a lot of bang for your buck to kind of start wrangling compliance. One in particular is CISSP. I'm not endorsing that one. I'm just saying it's in a lot of boxes. Next to that, you have Security Plus. And I'll also point out real quick if you can see anyone of the Security Plus Network Plus. You also have the CE. That's for compute elements. The point there is that technical proficiency matters, and as we go to 8140, it seems like it's going to matter more. So how do we get the best value out of our training dollars? So we've been talking about roles in our company, and they tend to be senior, at least senior to me, a mid-level engineer. In triaging security control, traceability to various projects. I like to line up what I call compliance dominoes. So if we know the milestones that our customer expects, and we kind of go to the higher-ups, the business directors who have visibility across the company, let's line up these milestone dates that the customer has with our existing program schedules, right? Too many times I've seen security come in at the end, and it's kind of like getting T-Bone in a car accident. The schedules are orthogonal. They're not in lockstep. Once we do that, we're definitely going to be more efficient in executing on these security tasks, whether it's a technical hardening effort to fix a web server, or to answer a question or something like that. The next bullet, maximizing existing contracts. I would say that's both maximizing the resources we have from our customer. We may have to pull on them rather strongly, maybe even reach through the customer to their next level up, but they're going to provide valuable guidance, whether they know it or not, on how we can do things efficiently. Secondly, there's our vendor relationships, and that brings me to some of the relationships we'll see on the ground in our company. So the first one is purchasing. So I know in my case, initially purchasing with the people that maybe I make a purchase request for some software and maybe have to wait a long time and eventually it gets approved. And then when I go install the software that I just got approved for, I get to a certain point and ask for a license key. And then I have to go back to that person too because they got the email with the license key. So the purchasing folks are more than that. They have the contact with our vendors. They're going to help us maximize that relationship to get the most out of our SIM or vulnerability management vendor in terms of training and technical support and things like that. They're also going to have visibility on what other programs or what other groups are actually using the same software, right? Because they've got basically high level visibility into all the purchases in the company. That's going to save us from making painful decisions about buying a new or opening a new account so we can just get maybe an entitlement with an existing account that we already have. And one last thing about purchasing, it is a central point of having good supply chain risk management plan. So I would argue that the purchasing folks, a lot of successful SCRM, which is really about what the CMMC and some of these standards are about is protecting the supply chain. A good program is going to ride on their backs and those folks are already doing some good work. It's just a matter of them maybe adding a little bit there. But they're going to help us a lot. The second relationship, it should be pretty obvious, but engineering and IT, that's two technical groups, should be working together. We might have different tech stacks, but otherwise this relationship should make sense. And the security focus of it, I would say if we can focus on getting together for some CIM training, for that vendor we haven't really maximized that relationship, that's a really good idea because one, we're going to have more folks to consult on when we're troubleshooting problems with our CIMs. And the other thing that's just going to bias, if we don't have a CIM yet and we don't really do metrics really well, the CIM is going to be that data aggregation platform to get metrics. And frankly, as an engineering group, yet it's going to help us up level to like a level in terms of the capability maturity to like a level four if we're at a level two or three previously. The third relationship is human resources. I think there's plenty of ways that this one could go. For me personally, what I saw was this kind of value thread here which is up on the screen now. I had a situation at work where the data call came in from another partner. The Senior Business Director saw it. He kind of put out an email with HR and some of the cyber people. And HR could kind of figure out who had the right cyber search or experience. It was kind of like a company resume to be frank. HR now has that. They can develop some kind of talent database so the next time the next data call comes in, it doesn't have to be an email exercise. They can also start tweaking their education reimbursement policies to include cyber training. That's a win for HR because now they have one more perk to attract new talent. And it's a win for us because it's a way for us to basically with new talent, we get new allies. And if you're the one engineer that was doing security, now you have folks that can help you with that. Just a quick summary. The CFOs, they're about, I would say, time is money, that will cliche. I would say that security literacy saves time. Security, especially organizational security, is going to be team effort. Don't throw the baby out with a bathwater. So our existing groups are probably already doing a decent job. It's just about documenting that and maybe refining it to the engineering process that we're already doing. And then lastly, where you want to get to is that security enables quality. Security for its own sake, but there are many practices, good security practices that are going to make your engineering process stronger. And that's it. So like they say, you really do zip through the slides fast and live. So open up to questions now. Any relationships that people want to work on a little bit more? Not personal relationships. Oh, that's good. Yeah, so physical security. So when I'm doing security controls like the NIST 800-53, when I say disaster recovery and business continuity, that might be the CISSP term. But you know what I mean? To me that seems like that says facilities, right? And then facilities is going to work with IT because if power goes out, what kind of apps are they running and stuff like that? So yeah, that's definitely a relationship that's going to extend out. And then with the supply chain on the extending relationship, manufacturing or shipping and receiving is definitely going to factor in the supply chain relationship. Say the last part. So one thing I think disambiguing IAM is information assurance manager, not identity authentication management. I hope that was maybe not clear. Does that make sense? So one thing I have to abandon is a security minded person. Sometimes it helps to be just being aware and literate of the security requirements that come down the pipe or these compliance things. You know, it's something to show like, hey, you know, we have programs A, B, C and D and we know that we have engineers that touch the systems that require those kind of certs. So one is showing that official compliance. Now, you know, if you want to hear a weird thing about those DOD 8570, that baseline matrix comes from that, but the new standard is 8140, which is not quite done, but it's re-labeled 8570 cube to cover 8140. So dealing with those lags sometimes, that's why I say those DFARS clauses matter, because that's when the rubber hits the road for when you actually see new security language in like contract documents. Well, that's it. Thanks everybody for coming. I appreciate your time.