Listen to Tanium’s podcast to discover how your organization can strengthen IT management, improve audit readiness and achieve CMMC Level 2 certification.
[Anthony Jimenez]
Welcome back to CarahCast, the podcast from Carahsoft, the trusted government IT solutions provider. Subscribe to get the latest technology updates in the public sector. I'm Anthony Jimenez, your host from the Carahsoft production team.
On behalf of Tanium, we would like to welcome you to today's podcast, focused around CMMC Level 2. Director from Georgia Tech Research Institute, Wes Hogarth, and Group VP from Tanium, Ryan Endorfer, will discuss practical strategies for managing compliance across complex distributed environments.
[Ryan Andorfer]
Hey, everybody. I'm Ryan. I've been with Tanium for right around 10 years, which seems crazy.
Time flies very quickly over here. At Tanium, I'm the Group Vice President. That's a fun title.
I'm responsible for all of the platforms, everything from how client-server protocol works to our cloud offerings, Tanium Cloud, Tanium Cloud for U.S. government. I had the privilege of starting both of those. Tanium Cloud for U.S. government is probably the background that brings me to this conversation today. I'm excited to chat with all of you and talk with Wes. Wes, how about you?
[Wes Hogarth]
Hey, thanks, Ryan. Good morning, everyone. Nice to see you all today.
I appreciate the honor. It's a privilege to be here. Wes Hogarth, I'm the Director for Information Systems here at Georgia Tech Research Institute.
We're the non-profit applied research arm of Georgia Tech. GTRI is what's known as a UARC, a University Affiliated Research Center, and our primary sponsor for work is the Department of Defense. About 90% of our funding comes from the DOD.
So we not only have to work with state regulations because we're a state entity part of Georgia Tech, we get our own funding, like I said, we're not affiliated with campus from a funding perspective. We get our own contracts and contract vehicles, but we also deal with defense and federal regulations as well. So we both environments are great, great fun to be a part of.
It's a very complex and challenging and rewarding environment for many reasons. I've been at GTRI just over 18 years. Actually, this year is my 18th year and have some time in industry as well in a different sector.
My IT career has spanned anything from systems engineering, systems administration, IT operations, enterprise applications, virtualization, storage, leadership, touched a lot of different things in the IT field. It's very nice to talk with Ryan today and looking forward to great discussion from the audience and happy to be here. Thank you.
[Ryan Andorfer]
So why don't we like start from the start. How did you get tricked into working in highly regulated environments and like what has been your journey for actually like operationalizing CMMC in level two? Like walk me through that.
[Wes Hogarth]
It's a great question. So I started here at GTRI in 08 when I was a co-op student. That was way, way back before CMMC was even probably a glimmer in someone's eye.
But regulatory environments with defense data and sponsored data is critical. So I've been ingrained in this environment ever since my first role in college when I was a co-op student. And then Katie Arrington and others in the defense sector, you know, they came up with this concept of CMMC.
And it's really important. Other organizations and other business sectors have PCI and the ISO certification is 27,001, 9001, a bunch of other different types of regulations. So it's really important to protect the data, but also trust and verify that what you're doing on your systems is accurate and have someone audit that because our warfighters and our sponsors need that data protected in order to feel confident, comfortable that we can deliver the solutions that we say we can about protecting data integrity.
So, you know, when the DIMCAC had its first, you know, iteration of audits back in the day prior to CMMC version one, you know, been part of that and then CMMC version one with five different levels there. And then CMMC version two kind of condensed all those five levels down into three. And so I've just been walking through this organization in different ways, helping to protect our organization in a couple of different capacities.
So I didn't get tricked in. It was by choice. But it's a lot of fun.
[Ryan Andorfer]
It's great fun. Yeah, I would agree. I'll actually say I kind of got tricked into it.
So, you know, I had the privilege of starting Tanyan Cloud and, you know, I've always cared and we have always cared deeply about security and compliance. We started a commercial cloud offering first and about, I don't know, six, nine months after it launched, our CEO, Ryan, came to me and said, hey, we've got a few federal customers. Why don't you go figure out this FedRAMP thinning?
And at that point, I knew nothing about NIST 800-53, 218, like any of these things. None of all y'all's like interesting acronyms. And I just was bright eyed like, sure, I'll figure all this out.
What could be so hard? Like, it turns out a lot. It turns out there's a lot to this.
And even if you care deeply about security, these security frameworks are in depth, which is nice. They force you to think about not only what do you obviously think about after you go through commercial certifications, but just a whole lot of additional control control enhancements. So growing up sort of in this environment, like if you were starting over again, and had to learn all of this stuff, where do you start?
[Wes Hogarth]
That's a great question. And I would take multiple different approaches based upon what comfort level I had of either IT or security. Starting off, like I said, my background was in IT operations and systems administration.
So I'm a hands on person by trade, right? So learning Active Directory, learning group policy, learning RBAC, what that is, learning why that's important. So starting hands on, getting familiar with those underlying principles that make up kind of the foundations of why the S8171 and all the CMMC, you know, common controls, you know, exist nowadays.
So starting to get hands on keyboard that way. And then I'd take a secondary approach, I would go partner with some really good GRC people, and people that have walked through audits before, that can kind of show me the ropes about what an auditor might look for, or maybe what an SSP is, if I didn't know what an SSP was. I would get familiar with what an SSP is.
Really quickly, if I didn't know one, if I'm starting off from scratch, start my journey over again, I think that's very critical there. Because an auditor is going to look for, you know, what your SSP says, and then want to see evidence that you're actually doing what your SSP says. And that's very, very vital to the whole verify and validate, you know, proof that you can, you know, protect CUI and, you know, go through all these certifications and validations and the C3PO audits.
Like I said, once I'd partnered with a GRC person, then I also kind of think about, okay, got the technical requirements here, I've got the all the paperwork requirements for what the audits auditors look for, like, what does that look like from an application and actual implementation perspective, right? Looking at DISA STIGs, you know, DISA STIGs sometimes break things because it locks things down pretty tightly. So you have to, you know, default deny everything and then just allow exceptions in some cases.
And then I would kind of continue that path. Another thing you could do is if you have a really, really in-depth security mind and want to think more like an auditor, go take a CMMC auditor course. And that way you can kind of get a frame of reference point about what a C3PO auditor would look for when going to audit environments that are getting ready to go for CMMC.
But if I were starting off as a pure technologist and a pure technical person, hands on keyboard and go figure out what the, you know, what some of the basis and underpinnings are. You can also look at cloud providers like AWS or Microsoft and go read their, you know, their baselines for the United States 100-171 and also go look at the United States 100-153, as Ryan mentioned, that's really big in terms of the number of controls that you and the number of things you've got to implement to make, you know, get an environment ready for that. So there's many different avenues you can take there.
[Ryan Andorfer]
Yeah, I think one of the first things I did was went and pulled down Microsoft and Amazon's SSP and just read, what would you say you all do for all of these things? And that was extremely enlightening. It turns out this whole community is actually pretty close.
So beyond just talking about like getting friendly with your local GRC resources, which is great advice. I think just getting friendly with other folks who own information systems. And we're really working to develop a community here because we all talk with the government and like are a part of how all of this goes.
Because at the end of the day, these are risk management frameworks that we all work inside of and ultimately have the goal of just making this as secure as feasible, which is, which is really interesting. The other thing that I found extremely reassuring is the concept of an authorization boundary. Like when you think about all of these controls, like, oh my gosh, everything kind of like everything that is in the boundary and like how you draw the boundary, how you think about the boundary becomes incredibly important.
So like drawing the boundary, understanding everything inside of it, understanding all of the system interconnects, I think is a way to stay kind of sane in my opinion here.
[Wes Hogarth]
Talking about boundaries, the CMMC version two has got this concept of enclave versus enterprise. So it's very important with organizations that are going through something like this. So enterprise, imagine like a big old box and that's everything under the umbrella is in the enterprise.
If you're going through for an enterprise scope for an assessment, that's one thing. If you're going to section off and do a bunch of smaller enclaves and have enclaves audited, you know, for just CMMC, you know, that's a different way to think about it. As Ryan mentioned, you've got to look at the, where the boundary exists for those smaller enclaves and what does not touch your enterprise, you know, when it sits inside of an enclave.
And then you also have specialized assets that the, that the DOD has defined. And those things, you know, cannot meet the full set of controls that are required. And you've got to actually document, verify, and validate as to why those assets cannot meet the controls and regulations for CMMC.
And then you've got to prove evidence on that to your GRC team and to a C2PO. So that's also very interesting.
[Ryan Andorfer]
It's always fun looking back with rose colored glasses about everything that went right. But I think a lot of the learnings come from what went wrong. So what's a roadblock that you hit now when you're moving in this direction?
What'd you learn from it?
[Wes Hogarth]
There is a lot of technical debt that exists in every organization. And it's really good to reduce your technical debt as quick as possible before you're going through a major, major audit. And one piece of advice I would say on the flip side, when you're going through an audit, I would strongly encourage you not to make major infrastructure or enterprise wide technology changes during an audit, because you're going to submit a body of evidence based upon, you know, this tech stack.
And then, you know, that's going to, you're going to get maybe a POAM after that, after you have your visit. And then if you do something, a major technology change, while you're trying to do your POAM, and your C2PO comes back and it's like, this looks drastically different. What the heck happened?
That could be a problem. So my recommendation is eliminate your technical debt quickly, but also hold any infrastructure, major application or major infrastructure organizational wide changes until your audit is done. And then it's really important to have solid change management through this entire process.
So that's change logs, that's if your organization is robust enough to have a CAB, a central authorization, or a review board for IT changes. It's documentation about what the change is, a back out plan, the people that were involved in executing, you know, a system change or a patch or an application update. You've got to really nail down your change management, because that's a big thing in CMC is that audit trail, what exactly happened on systems.
[Ryan Andorfer]
We met for the first time about a week ago, and we were getting to know each other. And we both sort of identified with the fact that we're change people. I'm a big fan of like understanding how change gets into your environment, how that changes your inventory, how that either positively or negatively affects your attack surface.
And yeah, if you can control change, and you can control human access, a lot of this becomes a lot easier to manage.
[Wes Hogarth]
Speaking of access, the principle of least privilege is very important. And that's very helpful. It's hard to do in a research environment, because by nature, research, R&D, a lot of times cutting edge technologies, a lot of things that may be required to run as root or run as elevated privileges, because that's just the way either the vendor built the application and shipped it to an institution, or maybe it's something that was custom built inside and it requires elevation out of the box, because that's the way it was written from a software architecture perspective.
But the principle of least privilege is very important. And an auditor is going to want to see that. And an auditor is probably also going to want to see, you know, how often access to certain systems applications is reviewed, and how access is privileged and granted and who grants access and privilege to systems and why people need access to systems and privileges to perform certain functions.
[Ryan Andorfer]
Yeah, that's actually a really interesting one that we haven't touched on. Like, least privilege is just one of those wild controls of like, least privilege. And then it's left up to the reader and implementer to figure out like, how to do how to define like, how did you actually like, think about least privilege?
And like what that actually means for your organization?
[Wes Hogarth]
Fortunately, I had the principle of least privilege drilled into me during my IT undergrad. So it's something that I've just done from scratch. How did I think about it?
Well, we just, we just, I walked into my first, first couple weeks of work back in 08, and was told a long time ago by my first manager, he said, I do not want to give anyone more privileges than what they need to be able to do their job. And I said, sounds good. I'm very familiar with that concept from school.
And he asked me, what does it mean to me? And I told him he said, that sounds great. Of course, there's always give and take for business case, but there's things you can do.
If you're a tanium customer, you can use certain modules to help you out with that. You can, you can have your ICD, your ICD or GRC team or your SOC team kind of look for audit logs. You can look at your application administrators and get them to pull up the access list for the applications every so often do like a quarterly review.
You can also speak with project directors or division chiefs or individual researchers about what the pain points are, like why they need access to things. You know, I'm a very, very interested in finding a way to say yes, but also there are times where we know we're not going to give carte blanche, you know, full scope to anybody to do everything at the drop of a hat just because someone says so, like you need a verified and valid business case. And going back to what Ryan was saying about risk, you've got to mitigate your risk.
If you have a thousand people in your organization and 500 of them have unfettered full access to do anything, right, that's 500 risk points, you know, from a person, human perspective, right? All it takes is one. There's one nefarious actor that's either an insider threat or a person that's from another entity that's trying to do nefarious harm, either exfil data for the purposes of intelligence gathering or to cause system damage.
And all it takes is one. One incident can bring down your entire network, can put your sponsor base at risk. But also, it's good cyber hygiene, IT hygiene, just to not give full carte blanche, full reign to everything.
[Ryan Andorfer]
Yeah, we actually, I'm not sure how to back into this. Now, if I was starting from a brownfield deployment, we had the privilege of starting our cloud offering in a greenfield fashion. One of the first things, one of the first principles we did wasn't even least privilege, it was no privilege.
So we actually started from the concept of, there will be no human standing access to our boundary, period. And every request for access will flow through an internal lockbox service, where justification must be had, full audit of what occurs during that, whether it's like collecting the cloud trail logs, or actual host base logs for every command executed, so on and so forth, with an approver, and a review process. And that really forced us to care a lot about change management, because human access became, by design, onerous.
So everything is code driven, everything goes through an internal promotion process. And it's actually been fun, like as technology has developed, we've actually brought that product to market, it's called JumpGate, it's entertaining now, but we actually have gone further, and actually taken LLMs now to automate the review of what was done during those sessions. One of my pet peeves, to be super honest, about like all the AU kind of controls is, almost all the time, they're used sort of like, oh no, something really bad happened, like why did it happen?
They're not super used in a proactive sense, because there's just too much going on, right? You can use them to replay things, but like too much going on. So one of the things that we've actually done now is like, as sessions are open for human access, we actually watch, or I shouldn't say we, we have an LLM watch what was actually occurring there, and tracking it against like well-known behaviors, good behaviors, and the actual request definition.
We automatically alert our security team if there is any deviation. And the beautiful part about like this sort of just-in-time and just-enough access system is, we can be very cautious, which means like it's very easy for us to cut off sessions, and completely drop like a network layer, that connectivity. So it's really, really interesting, and like being able to, again, I'm not sure I would back into this in a brownfield, but like starting from there, I think it's caused us to have really clean operations.
[Wes Hogarth]
That's a, you brought up three great points there, talking about cutting off network access. Network isolation for something that is anomalous is critical, especially if you're dealing with defense data, or really sensitive data, CUI data. You know, one thing I would say, you're talking about controls and change.
Automation is very important. So if you've got the opportunity to use something like Terraform, or Ansible, or something that, another type of IAC language to, I don't want to use the word automate, but to turn something that a human does X amount of times, and write a playbook, and you know, have that action repeated multiple times in a scheduled, automated fashion is super critical. And it's really important too, if you're going to automate something that you look at your automation, the output of it to ensure that that's what your expectation is.
And then don't forget to go back and every so often just verify the automation is working. You can't just sit and forget it like a Ronco Showtime rotisserie, you know, top of the day, like you need to be able to ensure that, you know, what is being output is accurate, but also go back and ensure maybe your automation needs change, you know, in day zero, you have this, you know, X, Y, Z need, and you automate, you write your playbook that way, six months later, your needs change, you need to go back and rewrite your your code, you know, in order to change up the way your automated output is. And you can't just, you know, expect that six months, you know, from now, it's gonna be the same as what it was a year later, you know, what starting with your needs are.
So go back and, like I was talking about going back and automate access to audit access to systems and audit access logs, and do quarterly reviews of business needs as to why people need to access certain things. Do do some sort of cadence review of your audit project for your infrastructure as code to make sure it's still valid for your business.
[Ryan Andorfer]
I couldn't agree more. Like we talk a lot about shift left, or it's like, make sure that's before deployment happens, like it's not going to affect control implementations, or dot dot dot dot, like all those sorts of things, like, privilege of like, everything is code base, so we can do a bunch of that scanning. But like, it turns out with complicated systems, there's layers of things that get applied.
So not only is scanning left of deployment important, but it's also important to scan the real stuff, actually know what real configuration and the resultant set of all these different configurations actually is to understand that sort of drift. And that's one of the places, one of the nice parts about like working for team is I've actually just gotten to create a product to solve a lot of my problems, which has been a joy. Now, but we do exactly that.
So like, we do, like progressive deployments with code, and we'll use tanium really to check like, in the real world, am I actually doing what I said I was was doing and trigger off not automated changes, but like tickets, if there are things incorrect, so we can fix the roots and then get patches out very, very fast. And that's sort of like constant feedback and like being able to check all stages, super important, super important.
[Wes Hogarth]
Talking about stages, you know, touch a real bit on the SDLC portion here, shift up mentality is critical. I've also been into DevSecOps, and that concept has been around for quite a while. And if you can have security baked into your software architecture systems architecture early and often, it's better than the traditional waterfall method, because if you know, you get past all your stages, at the very end, you do your security, and there's a darn good chance if you haven't thought about the security architecture, certain controls that you're going to hit down here, when you implement them, it's going to break everything, or not everything, if not everything, a darn good amount of what was built. So that's why if you look at your security requirements early and upfront, you know what the expectation is to finish the line once your systems or software is ready for deployment.
[Ryan Andorfer]
Yeah, and that like just so ties back into my naivety when I started doing this, Brad Bush did, of course, it's all going to be easy. Then you start to think about like how to actually do validation of like, AC controls, is this actually enforced? I like all these sort of things.
And like, you don't want to just have to manually generate evidence all the time. Like how can you automated, in an automated fashion do that? And it, it takes effort.
Like, it takes effort, but like the results, I think, are really good. So now all these frameworks have sort of two sides to them, there's a whole bunch of technical controls, which are super, super important. And often as a technical person, when I when I think about a lot, and there's also a huge amount of like, policy procedure, like organizational human controls.
And those often require like outside of just outside of just the technical teams to talk a little bit about how you all like organize like as a larger organization.
[Wes Hogarth]
Yeah, it's a great question. So, like I said, Gtry is the primary nonprofit research on Georgia Tech. So we're a subpart of Georgia Tech, but we operate off of our as our own entity.
We have just under 3000 employees. And we got by an early, our executive leadership, you know, our, our Gtry director, you know, our executive leadership, you know, believed in this, and, and why it's important, and because our sponsors required it. And that's our primary business model is DoD, right?
So we knew this was coming, and we got ahead of it. And, you know, we're, we're stepping through it. You mentioned change several times, we mentioned change several times.
Change is hard for people. And the human element is critical. A lot of humans don't like change, and introducing something new to someone is very hard.
You've got to ensure that you tell the people of the business like what what we're doing and why you're like, hey, we've got this external requirement. Here's the reason why. Because our contract language is now going to require X type of, you know, contract clause or default clause or FAR clause or whatever, or CMMC attestation, you know, where people can go query, you know, what organizations have a CMMC Level 1, Level 2, Level 3 certification.
And, you know, if organizations don't achieve that, you know, that's the primary business model, then the business is at risk, right? You've got to find another customer base. But getting that buy-in early and often from your business for your business verticals is critical.
And if you don't have the buy-in, it's gonna be really hard to be successful. And I see the results here, the lack of visibility in the QE assets, resource staffing constraints, budget constraints, 100%. I agree, the biggest barrier to even some of this.
It's interesting. There's lots of budget pull from so many different places, especially if you have inference costs from all these, these AI and these LLM things. And then you've got, you've got infrastructure costs out the wazoo with RAM and hard drives going up, because the chip sets prices are going up, because the supply chain is all whack.
So you have all these budget constraints and all these competing priorities as to why it may be hard to go get this, you know, this authorization or this compliance or this, you know, this attestation, you know, that you are protecting this. You've just got to really think about digging with your finance team and your executive leadership, like, hey, you know, what does, what does our organization want to be? Do we want to be at the same, you know, award level we've been?
Do we still want to, do we want to grow? You know, what type of areas of the business do we want to grow in? Do we want to grow in our cybersecurity departments?
Do we want to grow in our IT departments? Do we want to grow in our engineering departments that are doing hands-on work? Do we want to grow in cutting-edge research?
Do we want to go, do we want to grow in the legacy sustainment engineering arm of our organization, right? There's so many different areas that are competing for budget. But I think if you as an IT leader have got to sit down with your finance team and your CIO and your cybersecurity leadership and your senior leadership that are serving, you know, other cross-departmental business and just hear from them what their vision of success looks like for the organization.
And then you have got to, as an IT and cybersecurity leader, partner together and work with people that can help you get to that, right? And you've got to believe in your mission. You've got to believe in what your organization is going to achieve.
I find it hard, like if you yourself don't believe in something, it's really hard to sell it. And it's really hard to be excited about coming to work or executing that function. So you've got to really make some peace with yourself.
And if you don't like the way the organization is going, then speak up. And, you know, we've all heard the phrase, see something, say something. That's really true.
And not just personal safety, but in organizations as they navigate different areas of the business.
[Ryan Andorfer]
Yeah, I think you hit on something extremely important, especially with processes like CMMC and FedRAMP. And that's like, one, they're not cheap. And two, although a large amount of the implementation is shouldered on folks like you and I, like this really is an organization or business level decision that's made.
So having a very close relationship with your finance department and others, I think is critical here. And like you said, selling into it for a lot of us, I wouldn't even say it necessarily is needs to be thought of as selling as much as just partnership, like, like you guys are required. This is law.
And this is like what you do. And I'm so a fair amount of this is a partnership, a discussion about like, Hey, here's how we think we're going to approach these different controls. Here's what this is actually going to impact.
And what I've found working, we have a wonderful finance department, but working with finance and legal and compliance. And when you take that sort of tact of like, we've made this decision as a business, we're all working together to try to optimize how this, what the outcomes here are. And if you can get everybody on the same side of the table, things go a lot smoother.
[Wes Hogarth]
Yep.
[Ryan Andorfer]
Yeah. Because it's like all of us working together towards this goal, not like, Hey, can I have some budget? Like, Oh no, like the, the business has already decided that we're doing this.
Like, here's my proposal for like, how we can do this. Let's talk about how, not if.
[Wes Hogarth]
Right. They get all cross-border stakeholders, a seat at the table early and often, and I've come to a common sense, like this is what we're doing. This is why we're doing it.
This is how we're going forward. Right. And this is, this is an existential risk to the business if we don't get this, you know, but also our spot, like you said, it's, it's in the federal register, it's the law.
And so if we want to, we and other organizations that protect Cooey want to still protect Cooey and still do work, like we, we've got to get this. And, and, you know, the finance industry has this, you know, type of regulations and other organizations that have to follow ISO certifications. They have their, maybe their yearly or quarterly or, you know, every six months ISO audits.
Right. And if some of those audits go bad, then that's loss of reputation loss of work, loss of funding and maybe business shutdown because people can't follow the rules.
[Ryan Andorfer]
Yeah. And like, to be honest, like both of us have responsibilities for really protecting a lot of other folks, right? Like there's, these aren't just for kicks and giggles ideas, right?
Like we actually are protecting important, critical infrastructure and important critical data here. And as well, like we can think of this as a annual audit that we got to check the boxes and select the controls for them. Like I would actually posit that that is a really bad way to look at this.
Like, these are, these are thoughts for how to build like a secure, as secure as we can, right. Operating environments and really like try, like, I'll be very honest. Like I actually read every single control I wrote and I plan to never write again.
Many of our original policies, procedures for how we actually implemented this. And it was a fascinating process that I think made me a better security leader. Like actually just thinking about all of the different controls and how they fit together, or sometimes don't fit together.
But struggling with what that meant and like how to actually run an information system in a continuous fashion. So like, I know you also think of things in that sort of fashion, but like, if we don't think about this just as a floor, but like, if you don't think about this as the seat, but as the floor, like, I think that's important.
[Wes Hogarth]
Yeah, agree 100%. And we talked about earlier, and you mentioned a couple times and mentioned too, saving, you know, saving lives, right? You know, the defense industry saves lives of, you know, our, our nations, you know, war fighters and our allies.
And we protect against, you know, enemies that are, you know, all around the world. And that's why, you know, I'm here because I, you know, feel like I'm helping out, you know, this, this type of industry. I love IT and I love people, but also feel like a mission focus, right?
I think a lot of people on the call from our participant list and our audience, you know, are mission focused, right? And it's really important that we continue to put our best foot forward, not just in words, but in our actions to ensure that we are protecting the data that we are entrusted to protect from our sponsors at whatever university or, you know, defense contractor that's represented on this, you know, call today. You know, we're charged with, you know, doing these things by design because that's what our organization is.
And that's why we exist as a, you know, as humans in, you know, in this company to ensure that we can work with people to solve business objectives and to protect data. All it takes is one, one nefarious actor or one misconfiguration. And then you have an incident and then lives could be lost because of that.
[Ryan Andorfer]
How did like, really, if I boil this down, like, how does Mythos change everything that we're doing or thinking about? And I'll answer that in hopefully a reassuring way for everybody. Like it certainly does, right?
It's like frontier models have shown themselves to be very good at finding new flaws in software packages or novel ways to chain together a number of different flaws into very meaningful attacks. And if we look at the next, I don't know how long it's going to get spicy. Like there's going to be things that have patches that you can apply quickly.
And there's going to be, to be super frank, a lot of things that you cannot patch super frequently, like definition of zero day. And to be honest, for important environments, that's actually not the largest change. And if I think about my own career and I rewind for a bit, it seems like it's fallen out of favor a bit.
But I remember, I don't know how long ago, like assume breach was the term of the day. And for a lot of us, I think we have never sort of lost that idea of like, you should be assuming that everything has a flaw, hopefully not at the exact same time. But you should be assuming that there are flaws inside of your environment and working to understand defense in depth.
Or like, if this piece has a flaw, what would that actually mean? And how do I continuously test against that? And there's various things depending on how large your organization is and how many resources you have.
Like we are privileged enough to have like always on red teams that go out and create both internal testing tools and partner very closely with our defenders to do continuous testing from various different points of real flaws and assumed new flaws. But also like we've talked about just taking, there's places we're taking tooling and trying to do that helps a lot. But I would say that at the moment, keeping up to date with what is being released, what is being talked about, working to apply that to your environment, just like we do all like information that comes in from information sharing partners, really, really important understanding how to quickly operationalize that intelligence.
But also in the gaps, as we currently have them of time between those, like really getting to know your environment and understanding like what difference controls you have, where and how to operationalize them and how they all fit together is really important. Like if you've, if you followed, like I come from to 853, like a FedRAMP environment. If you follow these sort of pieces of advice, you will have a lot of defense in depth, whether it's host-based controls, network-based controls.
I like all of these sorts of things. And it's one thing to have them. It's yet another to really understand how they should be working together to mitigate your overall risk.
I think right now, that is what I would be doing. I'd be working hard to understand my control environments and we're auditing some theoretical tests to see how I respond and how my partner teams respond.
[Wes Hogarth]
That's all great advice. I would agree with that, Ryan. So one thing you mentioned, you know, zero days and the rise of AI, supply chain attacks are very real.
And I think supply chain attacks will continue to get more prevalent over the coming years because of the powerful ability of some of these, I'm putting in air quotes, AI tools that exist out there. So hallucinations are a real thing in the AI world and the LLM world. But also, it could be as simple as an insider getting into a software stack, upstream provider, and dropping in a nefarious file with what looks like a valid signature.
And then that gets applied out to its downstream customers. And they can bring customers to, you know, to a crawl or to its knees or locked out of systems because of that. So that's where I think what Ryan was talking about, knowing your environment and knowing what controls apply to your environment and knowing the normalized behavior pattern of your network traffic, your application traffic, having a good group of people that you can either internally rely on or externally partner to rely on to watch your environment for any anomalies and be able to respond, like talking about my network application layer to cut that off if there's a problem quickly, is very critical in the rise of all these powerful AI tools, air quote.
[Ryan Andorfer]
Yeah. And even to think about like, if you haven't, I highly recommend folks go and read up on like the social engineering that went behind the Axios attack. Or that's like, it's getting wild, like how well social engineering is going and how targeted towards maintainers, large projects, like, like that is, that's a scary sort of thing.
If you think about like the juxtaposition, like you, you want to be patching things that are security relevant quickly. But you also need to like ensure that what you're rolling out as the patch isn't actually the problem. Right.
And we've thought about like static code analysis and dynamic code analysis. And that's like ingrained in all of these as things that you should be checking. But I'd actually throw another one in there, especially as like we think about integrating open source software packages into our, into our stack that are like, you have the same advantage as attackers, or you could have the same advantage of attackers, you know, which is like applying these models towards the change that was introduced and actually understanding what that is.
And now I know everybody can't do that because it is an expensive thing, but it is certainly worth considering, especially if you think about like your responsibility as an information system owner that is integrating not COTS, but open source, like you are ultimately responsible for that outcome. So I think it is actually our responsibility to use all, all options at our disposal, both traditional and new ones to really understand, like, if I do this deployments, even if it looks benign, like I should be really thinking about it before I go. I think that's going to be one of the things that we all just look back and we're like, how were we doing that?
Right.
[Wes Hogarth]
Yeah, agree. The open source software is massive, because of the open source communities has grown over the years. And a lot of great innovations come from the open source community.
I'm not saying anything bad about that. But you know, to that same point, SCAS and static code analysis, but also knowing the upstream providers of the dependencies, like for NPM attacks are getting, you know, pretty big now, and other things like that. So if you're building a solution, if you're ingesting something from this source to this source to this source, right, you bring it all in, and you're putting your own secret sauce and making you're producing this deliverable, right?
If you know that deliverable is still part of your enterprise boundary or enclave boundary, right, you've got to ensure that there's, you know, a, an SBOM, software build materials, or maybe what I call an HBOM, a hardware, a hardware build materials, right? If your sponsor is required, not, not, you know, not only for you to have CMMC certification at, you know, level one, level two, level three, but maybe your contract clause requires you to produce an SBOM upon deliverable or an HBOM upon deliverable, you've got to be able to show that, you know, whether that's through your CICD process, whether that's through something like a SCA, or a single source of truth, like a binary repository, or through something like Tanium, maybe, you know, the same object that exists, you know, to provide an SBOM upon deliverable and output after scanning certain hosts. Those are all very critical. And that's all great evidence to show an auditor, especially as the controls for CMMC continue to evolve.
And as far as the evidence that may, maybe you have to show to meet current, you know, auditable controls and objectives, right? It's, it's better to have that at the ready, than to not have it and to be caught like, oh, crap, I've got to have this. And I have no idea what this is.
Like, I'm in, I'm in trouble here.
[Ryan Andorfer]
Yeah, a hundred percent. And like, that's another one of those that I'd encourage people to tabletop or actively test. Go through the process of assuming some upstream dependency is compromised and got deployed.
Could you tell where it got deployed? Would you know what it was doing? Was it calling out to C2s?
Was it beaconing? Was it stopped at your proxy? Was it stopped at the host?
Like what, what actually happened? And then really, what would you do? Right?
Like there's like this idea that like containment is the answer. Containment might be, you know, like shutting off like the C2, like outbound traffic, certainly. Hopefully you get all of that, but really you've got to also, like the actual information system, largely be able to understand what either rolling back or rolling forward means rapidly to remove these sorts of things.
So again, like we all have time right now. Hopefully none of us, we're all on this call. So I assume none of us are under an active breach, which means you've got time and there are known things that will happen to all of us and taking this time to really test out what your procedures are, I would say is time very well spent right now.
[Wes Hogarth]
Tabletops. I want to harp on tabletops. It's very important, right?
Simulated tabletop and do a tabletop exercise to simulate something, simulate an allergy, simulate an application tax, simulate a system outage, a compromise of some sort. And that way your incident response and your information systems team can be ready. And, you know, just like sports teams practice and people that are on, you know, law enforcement or military teams, they practice tactics and they practice going over the procedures and going over, you know, situations, putting themselves in uncomfortable situations so that when an uncomfortable situation in production does manifest itself and realize you can be confident and ready and trust your response to be able to get yourself out of a sticky scenario, as Ryan mentioned, either roll forward or roll back.
[Ryan Andorfer]
Yeah. I flip it back a little bit to mythos. A lot of times, a lot of times we think about like, what are the negative consequences of AI?
And there aren't a lot. But the other thing I'd leave you all with on that topic is if you haven't, I highly encourage you to engage with the tooling in your professional lives. There is a lot that it can do.
I'm really thinking about not only how to respond to attacks that are driven or made available by these things, but how you can leverage them to make your own tasks easier, faster, and to make your own environment more secure. Like there are so many things where none of us have the human power to do all of the things. And there is a huge amount of benefits that these tools can bring to actually make a lot of things you never thought you'd have time to do actually achievable.
And I think that is exciting.
[Wes Hogarth]
Having partners that you trust and having teams of people, there's no better time to test and there's no better time to plan and prepare than right now. And as we're upcoming on the deadline to be CMMC certified, it's going to be crunch time for people that are going through this now or maybe are just starting to go through and start trying to wrap their head around what's required. Going back to the question from the audience earlier, start having those planning conversations early and often.
And as Ryan mentioned, if you're having struggles to try to come up with what is needed to get your environment ready, go partner with a trusted integrator or third party helper, do a C3O to get to help you or someone like Kerasoft or another company to go partner with you and to walk this journey in preparation with you to get ready for that. And when you choose application partners and application integrators into your environment, talk with your security experts. Wow, that was a bad way to say that.
Experts and get them to walk them through from their perspective, like how their application stack is secure and how they can be a trusted partner and provider with you on this journey into CMMC land. It's great fun.
[Ryan Andorfer]
Yeah, personal-ish question. What are you doing the week before audit?
[Wes Hogarth]
Making sure I get my sleep. My biggest thing is if I have to change and scramble something or I have to work with my executive director or my team to change and scramble something the week before, then I failed myself and I failed my team. It's business as normal from my perspective, making sure I hang out with my family, get enough sleep, make sure I get the proper nutrition.
That's about as personal, authentic answer as I can give. Because like I said, if the only time I'm scrambling or my team is scrambling, if there's like a fire or if there's something that we absolutely missed, but since we have been talking and prepping for us for a long time, we've got enough under the covers, peaking as to know what we're dealing with. We've got well enough in advance notice of what we need to do.
But yeah, me, just like I said, getting sleep and make sure I'm on proper nutrition.
[Ryan Andorfer]
Cool customer. You can tell you've done a number of these. I think that that is actually the answer I was hoping from you, because that's actually the advice that I give all of the folks at team who are going to be going through their first audit, right?
We call on information, like we have lots of components to our cloud operating. There's changing faces all the time of who's going to talk to auditors. And often there's people who this is the first one they've gone through.
And that advice is so critical of like, it's going to be okay. Take care of yourself. Know what your information system actually is and how you respond to these things, but take care of yourself and realize that it's risk management framework.
And your goal here is to be wildly truthful, have a discussion and make the system better. Like an audit is just the audit. And like, it's a chance for everybody to review all of the things really as a partnership, to be honest, like things that will go on the plan.
It is okay. And we move forward with life. We close risks.
And it's important for us to identify what the risks are moving forward. So yeah, like the week before, you're not changing anything, please, gosh, don't change things. It shouldn't be a scramble.
Business as usual, a little bit of prep for like how to actually show where, make sure you know where your evidence is gonna be collected from and calm.
[Wes Hogarth]
Yeah, calm. And also knowing where evidence is collected, but also having your teammates just prepping them and ready on standby and just be like, you know, let's say your audit, I'm going to use a random, random day of the month, first day of the month, because it's easy for me. Let's say your audit starts July 1.
The last week of June, just like I said, business as usual, just stay calm and go over to the team like, look, the audit starts July 1. It is here for four, it's here for X number of days. All I ask is, you know, this would have gone on email a while ago prior to this, you know, all my executive director and I ask is that you be ready and available in case we need to call you during X amount of time during the sessions with an auditor to just verify and validate something for evidence as we met it.
Just go over just one quick swoop, the plan of action, and that should have been already been rehearsed a long, you know, long time prior to that and just keep it calm and business as usual and keep the anxiety as low as possible because audits are very, answer the question that's asked, be very direct, be transparent, but also don't start opening up doors to your answers, right? Be direct with your answers. Think about, like, as they go and, you know, think of it as you're going to, you know, answer someone at the bank.
They're asking you a question, you give a very quick answer or, you know, like you're going to, you know, talk to someone who, you know, may be selling something door-to-door or may be walking around the neighborhood you've never seen before. If you don't want to talk to them, you can just walk away from a door-to-door person, but also, like, you cannot just walk away from an auditor. You have to answer the questions that they ask and answer the questions that they ask very specifically and if they want to see more information or ask more information, they will, but don't feel like you have to overshare in your answer, but be truthful.
[Ryan Andorfer]
Yeah, a hundred percent. There's a lot to get through, you know, being precise, important, and let them drive. Like, you can be precise, you can explain, but, like, answer the question and then go quiet and let them ask more.
Like, Wes, I think you and I could just, like, keep talking for a long time. I've really enjoyed this. It's been fantastic.
It's been a lot of fun.
[Anthony Jimenez]
Thanks for listening and thank you to our guests, Wes Hogarth and Ryan Endorfer. Don't forget to like, comment, and subscribe to CarahCast and be sure to listen to our other discussions. If you'd like more information on how Tanium can assist your organization, please visit www.Carahsoft.com or email us at Tanium@Carahsoft.com.
Thanks again for listening and have a great day.