Welcome to the Quick 10 Podcast brought to you by Quick Track, focusing on all things
FedCon and cyber defense from different perspectives and different personalities, all in 10 ish
minutes.
Here's your host, Derek White.
All right.
Thank you, Alex, for joining us today on episode two of the Quick 10 Podcast.
How you doing?
Good, great.
Thanks for having me.
Good, man.
Good seeing you again.
Hope all is well.
As we kick this podcast series off, it's exactly what it is.
It's 10 ish minutes talking about a specific topic that we dive right into.
And today we're going to get into the world of ITAR and CMMC, which is what your specialty
is.
And we have today's Alex Trafton from Ankura.
So one of the best, I believe, on the LinkedIn side of the world, if you're a LinkedIn user,
first thing you need to do when you're done with this podcast is go follow Alex.
Alex has great digestible content that he puts out on a regular basis.
I highly recommend that people go do that.
But from your experience, we're going to get right into it.
And there's a large misconception that, quote, because we're compliant with A, we're therefore
pretty good with B. I know you guys hear that a lot.
We hear that a lot.
Talk about ITAR regulations and the misconceptions that come with that when people also have
requirements and regulations like CUI protection around the CMMC side, NIST 800 171.
And where you see that from your guys' side.
And share what people should know about that a little bit.
Yeah.
I mean, I do think that's a very common misconception.
And I think it comes down to a conceptual issue in companies that they view ITAR as
a regulatory issue.
And so it sits with a legal function.
And they view CMMC and CUI as a cybersecurity function, which typically sits in the technology
focus, like with the IT or cybersecurity, and that they don't speak well to each other.
But yeah, that's a common misconception.
And for defense contractors, certainly if they have defense contracts, if they're producing
manufacturing items that are controlled under the ITAR, and they're providing that to the
US Department of Defense, that ITAR data will also be CUI.
And so in that case, those are co-terminates.
But companies can make products, and a lot of larger companies do this, where they have
both commercial and defense businesses.
And the technology can originate with or without defense funding, could be ITAR, and they could
be selling it commercially.
And then it could also be part of an acquisition contract for the DoD and the CUI.
They could also have CUI that's controlled under the Commerce Department's Export Administration
regulations, this dual use that the government might be acquiring, which is a separate regulatory
regime.
So those aren't necessarily the same thing, and they don't have all of the same requirements.
And so I think that the ITAR data is definitely ITAR.
It is something that is controlled under the ITAR by its very nature.
The existence of that thing as that thing is making it ITAR.
But a CUI is really driven by whether the Department of Defense has technical rights
to the data that it paid for under an acquisition contract, which is the DFAR's language.
And so that's really where you can start to kind of see those roads divide.
If this is proprietary data we developed, then the DOD doesn't have rights to it.
We could even be providing it to the government, but if it doesn't have rights to it, it's
not CUI, but it could well be ITAR.
And the requirements are very similar in some ways.
They're both data protection requirements, but the ITAR is really focused on its origination
was a nonproliferation regulation.
And it's evolved and they update it.
But for the most part, it's focused on sovereignty of data and making sure that foreign persons
don't access data without a license so that the US government can control who has access
to items which are covered under the US munitions list that they're in use military items.
And that's a regulatory regime, where a CUI is contract-driven.
So there's a diverse sense of requirements, right?
And it relates to a number of factors.
You can have CUI programs.
There's no sovereignty requirement or no foreign person access restrictions on CUI.
Now the Department of Defense can mark it as no foreign persons access, and they can
mark it as what functionally makes it export control.
But it's very nature is an export control, right?
And there's many of the defense acquisition programs that have global supply chains where
CUI data flows globally.
It might be ITAR data, but those companies have to manage ITAR requirements, right?
But the CUI doesn't make it so.
And I think one of the big items where there's divergence and it's worth understanding is
protection of the data with encryption, right?
So if you look at CUI requirements in this 800.171, this is a requirement for any federal
agency encryption standard, is that there's a requirement to use FIPS validated encryption,
right?
And the language in the ITAR is FIPS compliant encryption, right?
And that's the difference between the CAVP, the cryptographic algorithm validation program,
and the CMVP at NIST, which is the cryptographic module validation program, right?
And I tend to think that there was a mistake when they wrote the ITAR regulation and they
met validated, but they used compliant.
But that's here and there.
So that's a remarkably different standard, right?
Whether or not you have to maintain validated, FIPS validated modules versus algorithms, right?
Which is much lower standard, right?
Because most strong algorithms are going to be approved for use in cryptographic module
validation programs, right?
And FIPS modules.
So those are differing requirements.
One is far more onerous, right?
So the other thing is the degree to which encryption is a protection under the regulation
or under the contract.
I hear in the CMVP world a lot, people saying, well, if I just encrypt with FIPS validated
modules, my data is fine.
I can send it out.
That's not true under the ITAR, right?
So in the ITAR, there's a section of the 22 CFR, part 126.1, which is a restriction on
export of even encrypted data to certain countries.
And so those countries include Russia, they include North Korea, China, and a few others
that exist on the sanctions list, right?
That data, even if it's encrypted with FIPS validated or compliant encryption, data can't
go there, right?
So the notion that I think a lot of CMVP thought leaders have taken is that if I just use encryption
to the standard FIPS validated, so I can just send ITAR where I want, sorry, I can send
CUI where I want.
Well, if that data is also CUI, you have to have some controls over where it goes with
both.
And that's a big one.
And I think the other thing is, like most companies are struggling with cloud services
and sovereign cloud services, right?
Using GCC versus GCC-HI and Microsoft, you have to pay close attention to who's accessing
that data under service contracts, right?
So dumping your data into a federate authorized cloud environment, it's not necessarily sufficient,
right?
You have to follow the CUI rules, but you have to ensure that that company, if that
data is also ITAR data, which a lot of defense data, especially in aerospace and defense
manufacturing, right?
Yeah.
Typically, most of it's going to be ITAR.
That the cloud service provider is ensuring not only that your federate authorized controls
are implemented, but also that anyone who may access it, right?
Or the sovereignty of that data itself resides within the US and is only accessed by US persons,
right?
So those are things that you want to consider, right?
And again, companies tend to kind of view those things in silos.
And I really encourage them to, if you have in-house counsel or an external counsel who
specializes in international trade controls, that you engage with them when you're going
through these CUI processes, right?
Your self-assessments, DIPTAC assessments, CMC assessments, right?
Policy design and how you scope your policies, right?
Because a lot of companies will say, well, I'm going to apply your policies enterprise
scale or I'm going to apply them at an enclave, a CUI enclave scale.
Your policies need to account for all of your regulatory requirements.
That could extend beyond ITAR as well.
It could extend into privacy.
You could have EAR data, dual-use commerce control data.
And so those policies need to be appropriately scoped and include the appropriate requirements,
right?
And a lot of that's on how you screen individuals, right?
How you screen your visitors.
One issue we've run into is that companies will build their visitor management system
around the ITAR requirements, which is like, hey, if they're a US person, I don't need
to escort them.
They can access the facility.
But under CUI requirements, they need to be escorted at all times, right?
So an ITAR program, typically companies will be, ITAR has been around since the 80s, right?
And they'll have built an entire compliance program around the ITAR.
So it's been there for a long time.
And then when they get the CUI contract requirements, after all the DFAR saga was complete, then
they're saying, well, we already have a visitor management program that addresses ITAR.
So we're fine.
Well, no, there are those nuanced differences between ITAR and CUI, which is really in the
ITAR.
Once you're a US person, they're like, State Department is kind of hands off about that,
whereas the CUI requirements are not.
So that's really some of the things to think about when you're dealing with data that's
covered under both requirements, right?
One, the beauty contract requirement, and the other is the ITAR regulation, right?
And then establishing controls around end use.
If you're an exporter of that technology, I think it's a little more nuanced than we'd
want to discuss today.
But those are some of the big ones that I see commonly with respect to test contractors.
Yeah.
And that's well said.
And I think with that misconception side too, you nailed it.
When you get into defense manufacturing, aerospace, the companies that have really put their emphasis
either internally or with external resources on ITAR and export control data, they tend
to do better for sure on when it comes to data protections and control information because
they understand origin of data, where it's flowing, who's got access to it, who do I
need to be authorizing and paying attention to, how we authorize, et cetera.
So the unfortunate side, obviously for most of the defense industrial base when CUI and
ITAR and different regulations are coming around is they do tend to have a lack of internal
resources.
And if they do have it, it's a smaller team.
So obviously highly recommended that external resources like yourself that are experts and
stuff is to engage with that.
And that kind of rolls into kind of my other question I wanted to ask you is we can kind
of wrap up with this is if someone wanted to learn one thing from you like today, like
short term, maybe it's been off the radar, maybe it's been something that just hasn't
been because of lack of resources, something that they've been able to grasp.
If they hear one thing from you today on what they can do right now in the short term to
help them get down a path where this is going to end well for them, what would that be from
Alex's standpoint?
Yeah, I think know where your data is.
That sounds always cliche.
And you can leverage these programs to work together to do that.
So if you look at the guidance from the DOD, that's the 5230-24, which is the distribution
statement markings, that's a document that's been revised year in, year out since ITAR
and DOD contracts were around.
And so if you go back to the first document from 1984, if you look at the first type of
sensitive data that the DOD is talking about, it is really they're talking about export
control data.
Like they're saying we're really worried about ITAR data.
And so a lot of that data is going to be similar.
It's going to be technical documents.
So understanding that, what they mean, if you look at control technical information,
that type of CUI that constitutes covered defense information in DFAR 712, that's application
and military and space technology.
That's the ITAR definition.
So what I would say is one way to kind of to not have this be a problematic issue is
you can start to look at it.
You have like a robust ITAR program and typically people have one because they've been doing
it for a long time.
You have a training program and you have an identification and marking program.
If you can start using that and associating those, like if you have ITAR category 11,
you're a satellite, just like that.
And you know that you have space contracts with Space Force DOD, right, identifying your
ITAR and then finding out which programs are associated with it.
Right.
So is that a government defense program?
You can start to leverage your ITAR program, which a lot of companies have to your point
in better form than they do their CUI programs.
And so they can start to use that to help identify where their CUI is.
Right.
And getting it marked and controlled and then looking at those policies and saying, okay,
well, do we have enough governance in place to kind of effectively control this data to
both standards?
And typically you're going to end up taking the higher watermark standard, right, which
is validated encryption, your CUI standards.
But never neglecting some of those nuanced ITAR requirements.
So I would encourage trade controls, international trade controls experts to get in and read
DFAR 7012, to get in and read the special publication 8171.
And I would equally encourage cybersecurity experts who are focused on CUI and CMMC to
go and read the ITAR and watch the webinars and read some articles on that and really
start to understand how you can be a resource to your broader governance of enterprise data
and find ways to commonly solve these problems.
Because while they're different, they're the same in a lot of ways, which is really that
control of technical data.
Yeah.
That's great.
Obviously, we could sit here and talk about this for a week if we wanted to.
And hopefully people would listen.
You're again, you're a great resource for this topic.
This is not one of those topics you want to be wrong on.
You can put a lot of focus on half of the conversation today on, let's say, CUI, CMMC,
and the 171 and in with on the ITAR stuff down the road without even realizing it.
So very, very important topic.
Thank you, Alex, who is the senior managing director at Incura.
I didn't even mention that at the beginning.
So thanks for joining.
Where can people find more information from you if they want to reach out and look at
using you as a reference here?
Yeah.
I think you said already my LinkedIn is probably the place where that gets consolidated from
all the different avenues.
I'll publish our practice thought leadership there.
I post there frequently on matters of national security, specifically ITAR to CUI, and also
artificial intelligence and trade controls.
So if those areas are interesting to your listeners, I think coming to my LinkedIn,
you can always message me there.
I respond quickly.
So I think that's probably the best place to find me.
Perfect.
Well, perfect.
Well, thank you, sir.
I'm looking forward to next time we have you on because we'll probably want to tackle some
of the stuff you just said in a little bit more detail.
And thank you so much.
And if anybody has any other questions or topics you want to submit, please subscribe
to the podcast.
Check out quicktrack.com for any information from the QuickTrack side and happy to connect
you to whatever resources we can.
But again, thank you, Alex, and we'll talk to you next time.
Thank you.
Thank you for listening to this episode and make sure to subscribe to the Quick 10 podcast
wherever you get your podcasts and check us out on YouTube as well.
For more information about QuickTrack, visit our website at www.quicktrack.com.
It's C-U-I-C-K-T-R-A-C dot com.