[00:05.600 --> 00:11.860]  Hello and welcome to Checklist for Aviation Vulnerability Disclosure, Don't Go It Alone.
[00:12.240 --> 00:17.060]  Before I dive into the talk, I first off would like to thank the Aerospace Village for allowing
[00:17.060 --> 00:22.400]  me to come speak today. They've been a great partner with CISA over the past year and I
[00:22.400 --> 00:26.720]  really appreciate them allowing me to come and chat with you for a few minutes.
[00:28.180 --> 00:36.080]  So, I am with the Cybersecurity Infrastructure Security Agency, commonly referred to as CISA.
[00:36.400 --> 00:44.700]  You may know us from some of our previous branding such as US CERT, ICS CERT, NCIC, or even NPPD.
[00:44.700 --> 00:49.960]  All of those functions, brands, and identities have been rolled up into a single agency within
[00:49.960 --> 00:57.800]  the U.S. Department of Homeland Security. So, what do we do? We essentially function as the
[00:57.800 --> 01:04.440]  nation's risk advisor. We do national risk management for cyber and physical infrastructure.
[01:06.640 --> 01:15.400]  So, kind of to break down, how do we do this? We leverage four major program areas. First,
[01:15.400 --> 01:21.780]  federal network protection. We augment the protection of the .gov web space, infrastructure,
[01:21.780 --> 01:26.980]  resilience, and field operations. If you're in the U.S., you may have crossed paths one time or
[01:26.980 --> 01:33.590]  another with our CSAs or PSAs, our cybersecurity advisors and protected security advisors.
[01:34.340 --> 01:40.760]  And we also have emergency comms. This group supports the COM ISAC and the critical PSF2
[01:40.760 --> 01:46.540]  function. And most importantly, the final group that I skipped is the comprehensive
[01:46.540 --> 01:52.700]  cyber protection efforts. This is where I fall among the many functions in this group.
[01:52.700 --> 01:57.660]  I facilitate the disclosure of industrial control system vulnerabilities.
[01:58.920 --> 02:04.960]  So, and to kind of sum up all of this part with who I am. So, I am Jay Angus. I'm the federal lead
[02:04.960 --> 02:11.660]  for the industrial control systems vulnerability disclosure program. Since 2012, we've been
[02:11.660 --> 02:19.140]  disclosing on average about 700 to 800 industrial control system vulnerabilities per year. And these
[02:19.140 --> 02:26.380]  vulnerabilities impact vulnerabilities across all 16 critical infrastructure sectors. We try to
[02:26.380 --> 02:32.600]  provide timely, actionable information to remediate these vulnerabilities in as public a manner as
[02:32.600 --> 02:41.480]  possible. So, we're going to kind of level set here. We're going to start off with what is a
[02:41.480 --> 02:47.280]  vulnerability? What do I consider a vulnerability? And I pulled this from the internet engineering
[02:47.280 --> 02:55.450]  task force. According to them, through their RFC 4949, it's a flaw or weakness in a system's design
[02:55.960 --> 03:01.400]  implementation for operation and management that could be exploited to violate the system's security
[03:01.400 --> 03:08.540]  policy. I kind of generalize as a risk that can be exploited by a threat actor such as an attacker
[03:08.980 --> 03:13.780]  to perform unauthorized actions within an information system.
[03:17.170 --> 03:22.890]  So, we break this down generally into two different categories from my perspective.
[03:22.890 --> 03:29.670]  We have our zero days. These are unintentional vulnerabilities. They're risks previously
[03:29.670 --> 03:36.530]  unknown to anyone and typically require intervention from the vendor for remediation.
[03:36.530 --> 03:43.690]  Whereas, we also have misconfigured devices. This is intentional or accidental. The risk is
[03:43.690 --> 03:51.610]  commonly introduced by the asset owner and it requires changes to the configuration on the device
[03:51.610 --> 03:58.250]  or the architecture surrounding the device. Either way, zero day misconfigured device.
[03:58.250 --> 04:02.400]  This is dangerous information in the hands of the adversary.
[04:06.400 --> 04:11.960]  And to continue this level setting, what do we consider a coordinated vulnerability disclosure?
[04:12.100 --> 04:16.700]  Just to kind of read the slide here, it's an effort to verify that accurate information
[04:16.700 --> 04:22.080]  is being openly disclosed on a vulnerability so that it can be addressed accordingly.
[04:23.220 --> 04:29.600]  I kind of use the airplane analogy at times. Much the way a vulnerability is found, a plane takes
[04:29.600 --> 04:36.140]  off and hopefully they both will make it controlled, safe to sit, you know, back to
[04:36.140 --> 04:44.820]  whether it's a public disclosure or a receiving airport. My team works to make disclosures of
[04:44.820 --> 04:50.740]  vulnerability in a safe, controlled manner. There's no guarantee that every disclosure
[04:51.660 --> 04:58.660]  will be smooth, but as for the aviation sector, as they begin to handle more disclosures,
[04:59.600 --> 05:08.420]  I think this is going to be much easier. And this will be an issue that we won't be as
[05:08.420 --> 05:15.600]  concerned about as time and effort continues to grow in this area. So to kind of help
[05:15.600 --> 05:23.920]  frame this conversation today, the aviation sector loves checklists. It's a very common
[05:24.560 --> 05:32.880]  approach to managing safety and risk within the sector. And one of these checklists could make,
[05:32.880 --> 05:38.000]  you know, disclosures easier whether you're a researcher or a vendor. And I kind of wanted
[05:38.000 --> 05:49.480]  to pull from the form published by the FAA, the FAA Form 7233-4. So if you're a pilot,
[05:49.480 --> 05:54.640]  you're probably very familiar with this, but it's the pre-flight pilot checklist.
[05:54.640 --> 06:01.440]  Looks like it collects a lot of information prior to takeoff. And hopefully I won't get
[06:01.440 --> 06:05.860]  too lost in the jargon here, but I'm going to break some of this down, compare it to
[06:05.860 --> 06:11.520]  vulnerability disclosure process, and see if we can find some parallels.
[06:14.660 --> 06:19.720]  So the first thing I noticed that this report is very interested in the weather.
[06:20.580 --> 06:25.440]  And what does the weather have to do with vulnerability to disclosure?
[06:26.400 --> 06:34.120]  To me, it has a... appears to have the primary effort to document what the pilot has no control
[06:34.120 --> 06:42.460]  over, which I found to be ironic. As vulnerability disclosures, there are multiple parties coming
[06:42.460 --> 06:51.380]  together of significant influence that typically have no control or direct control over each other.
[06:51.380 --> 06:57.400]  They can certainly cause buffeting of each other during the course of disclosure.
[06:58.240 --> 07:05.160]  And kind of... so as the researcher starts down the aviation research goal process,
[07:05.840 --> 07:13.400]  what is their end goal, right? Typically, their findings are focused on safe and more secure
[07:13.400 --> 07:20.220]  aviation. For the researcher, I cannot stress enough, but know the company that you're dealing
[07:20.220 --> 07:26.900]  with, as back to the idea that you can't change them. I have no doubt that you know how to
[07:26.900 --> 07:32.940]  manipulate their products and work with them very aggressively, but know the culture of the company.
[07:32.940 --> 07:37.740]  Depending on the company, it could be difficult for you to get your report in front of the right
[07:37.740 --> 07:45.020]  person. And similarly for vendors, you can't control researchers, but you can help guide
[07:45.020 --> 07:52.000]  them down a safe path so that you both have a controlled disclosure and sharing of information.
[07:52.320 --> 07:56.540]  And for the vendor, the first step is going to be that vulnerability disclosure policy.
[07:57.400 --> 08:02.320]  And for vendors and researchers, as I said, you can't change one party or the other,
[08:02.320 --> 08:07.380]  but you can certainly create opportunities to facilitate a controlled disclosure.
[08:10.410 --> 08:13.050]  So as we continue down the checklist...
[08:14.790 --> 08:21.650]  Wins Aloft. So this is the part of the flight that should be the most straightforward. Cruising,
[08:21.650 --> 08:26.710]  we're cruising. Systems are communicating as intended and parties have acknowledged each
[08:26.710 --> 08:32.090]  other's presence. The researcher has begun divulging to the vendor their findings and
[08:32.090 --> 08:37.810]  the vendor is reviewing the information. But we won't be here forever at this altitude.
[08:37.810 --> 08:42.750]  As the exchange of information progresses, researchers and vendors need to be open about
[08:42.750 --> 08:51.190]  their intentions and capabilities. Researchers need to be open of what they intend to do
[08:51.190 --> 08:57.590]  with their disclosure. Maybe they're going to take this to a talk at a conference.
[08:57.830 --> 09:02.390]  Maybe they're just doing this as an act of goodwill and don't require public acknowledgement,
[09:02.390 --> 09:10.330]  such as CVEs or press releases. Whatever the case may be, the party should be open about their
[09:10.330 --> 09:16.170]  tolerance for attention during the process. We want to keep the flight moving, keep the disclosure
[09:16.170 --> 09:24.170]  moving along as smoothly as possible. To keep this portion of the disclosure smoothly moving,
[09:24.170 --> 09:33.810]  vendors need to be more open about their product development life cycle,
[09:33.810 --> 09:40.290]  offer up realistic timelines for remediation. Simply ignoring the researcher first off doesn't
[09:40.290 --> 09:46.310]  buy you more time and at times can make the researcher make a less informed decision about
[09:46.310 --> 09:53.390]  how they want to proceed in a disclosure. Sometimes we don't need to dive into long
[09:53.390 --> 10:02.630]  protracted timeline for disclosures. And we kind of want to break that down a little bit
[10:02.630 --> 10:10.510]  into two different types of disclosures here. So for misconfigured devices, frequently focus
[10:11.380 --> 10:16.550]  on leaving the information with the vendor and a lot of times the asset owner under the
[10:16.550 --> 10:22.110]  expectation they'll remediate the finding. It's likely this type of disclosure, straightforward,
[10:22.110 --> 10:30.170]  relatively quick to resolve, and there's no space for a CVE assignment. But that being said,
[10:30.170 --> 10:34.810]  if you are having trouble getting someone's attention, we can help it sizzle with that
[10:34.810 --> 10:39.610]  and making sure that the information is put in front of the right person and I'll have my contact
[10:39.610 --> 10:47.590]  info later for that kind of disclosure. And then so second, the other type of disclosure we're
[10:47.590 --> 10:55.170]  seeing for zero days, you can expect that kind of a long protracted disclosure timeline for these.
[10:55.490 --> 11:02.610]  We've seen anywhere from 45 days for a typical IT vulnerability and at times to a couple of years
[11:02.610 --> 11:08.810]  for operational technology. Try to find a happy medium here. Researchers should acknowledge the
[11:08.810 --> 11:14.550]  amount of time that they spent finding the vulnerability and expect lag and remediation
[11:14.550 --> 11:21.150]  from the vendor. It's particularly for aviation systems as they have a much longer remediation
[11:21.150 --> 11:27.890]  process. A quote I hear sometimes from the aviation sector is it costs a million dollars
[11:27.890 --> 11:35.210]  to update a line of code. Whether or not that's true, recognize there's great efforts that could
[11:35.210 --> 11:45.650]  be required to remediate a vulnerability. So here we are. I think one of my more important
[11:45.650 --> 11:53.310]  points for this discussion today, who are you working with? So first off, I'll go ahead and
[11:53.310 --> 12:00.170]  list my favorite option, CISA. Our ICS vulnerability disclosure program has been in place for eight
[12:00.170 --> 12:06.090]  years now and we've assisted with disclosure of thousands of vulnerabilities across all critical
[12:06.090 --> 12:13.850]  infrastructure sectors. Most importantly, as a CNA, we can assign CVEs to new vulnerabilities,
[12:13.850 --> 12:20.610]  assuming it's within scope, and doing so will assist with better identifying vulnerabilities
[12:20.610 --> 12:27.810]  in the future. So, and I've listed multiple entities here. All of these entities are more
[12:27.810 --> 12:34.050]  than happy to work with researchers and I've seen them do so in good, definitely good faith.
[12:34.490 --> 12:41.450]  But, and for vendors, who are you working with? It's important that you have a relationship with
[12:41.450 --> 12:47.090]  the national search. You want to have that relationship ahead of time. And especially
[12:47.090 --> 12:51.550]  if you have a product security team, that they're in a perfect position to be building
[12:52.170 --> 12:59.650]  those contacts and reaching out to these, the national search to build the relationships in
[12:59.650 --> 13:07.870]  advance. So, and also we can kind of talk about here, when should an additional party be brought
[13:07.870 --> 13:15.130]  in to assist with a disclosure? And I definitely believe for all disclosures, anytime it's crossing
[13:15.130 --> 13:21.250]  international boundaries, I think it's, that's a great time to engage an external third party
[13:21.250 --> 13:27.230]  to assist with communicating with other entities and making sure your information is put in front
[13:27.230 --> 13:35.290]  of the right group. And, and the other situation, obviously for this discussion, aviation disclosures
[13:35.290 --> 13:41.310]  should always have a trusted third party involved. I think these third parties add some oversight
[13:41.850 --> 13:47.410]  and an additional party to make sure that the correct stakeholders and asset owners are being
[13:47.410 --> 14:00.110]  notified. So, hopefully as we discussed earlier, we've kind of talked around the factors. What does
[14:00.390 --> 14:06.450]  a landing look like for an aviation disclosure? Researchers, from my experience, want to
[14:06.450 --> 14:13.670]  acknowledge, want to be acknowledged publicly, privately, and want to see a fix for a
[14:13.670 --> 14:21.810]  vulnerability. At times it is just that simple, especially for misconfigured devices.
[14:21.810 --> 14:26.990]  Many times vendors struggle with their own bureaucracy and lose valuable time arguing
[14:26.990 --> 14:33.430]  points of a disclosure rather than focusing on remediation. My opinion is we do not see
[14:33.430 --> 14:39.150]  enough aviation specific vulnerabilities with CVEs being assigned. While I can appreciate the
[14:39.150 --> 14:44.590]  sensitivity of the sector, that this quiet disclosure process can create digital debt
[14:44.590 --> 14:50.690]  that can come due over and over again as more researchers enter the sector and continue to have
[14:50.690 --> 15:00.090]  similar findings. While the quiet disclosure is a useful alternative, it will come with
[15:00.090 --> 15:14.770]  consequences over time. So, airspace restrictions. Make sure you're clear to do the work that you're
[15:14.770 --> 15:22.230]  doing. This should go without saying. Please, please do not do cyber security research against
[15:22.450 --> 15:29.170]  a system that is not yours or you do not have clear written permission to have access to.
[15:29.190 --> 15:34.310]  If you have a question about the legality of your work here in the U.S., I encourage you to
[15:34.310 --> 15:42.450]  check out the DMCA. There is space for cyber security research specific to aviation devices.
[15:43.030 --> 15:52.850]  You just, it needs to be in your possession, in your property. To be clear, while I do work
[15:52.850 --> 15:58.550]  for DHS, I am not law enforcement or sector regulator. I can't put anyone in jail and I
[15:58.550 --> 16:04.290]  certainly can't force anyone to fix a vulnerability. That said, as a federal employee, I do have
[16:04.430 --> 16:10.990]  a certain obligation to report suspected crimes. Remember, I can definitely help researchers amplify
[16:10.990 --> 16:16.370]  their messaging around a vulnerability and I have a team of really awesome vulnerability assessors
[16:16.370 --> 16:22.110]  that can assist vendors with researchers, assist vendors and researchers in describing
[16:22.110 --> 16:27.470]  the vulnerability and suggesting mitigation strategies. But I have to have that information
[16:27.470 --> 16:33.810]  put out in front of me and it has to be in a very legitimate, legal format.
[16:37.000 --> 16:43.840]  So as I'm trying to sum this up, don't go it alone. I think that's one of the most important
[16:43.840 --> 16:51.380]  parts here. Be prepared beyond the vulnerability. So many times I've seen researchers that know
[16:51.380 --> 16:56.560]  systems better than the manufacturer, but the researcher is completely unprepared to acknowledge
[16:56.560 --> 17:04.480]  that they're working with a business that operates nine to five. Vendors, I can't help but push this
[17:04.480 --> 17:11.000]  message over and over again. You've got to have a public vulnerability disclosure policy. It makes
[17:11.000 --> 17:17.280]  it easier for researchers and vulnerability coordinators to put information in front of you.
[17:17.700 --> 17:25.580]  If you have a public policy, make sure you have an internal policy and staffing to support it.
[17:26.340 --> 17:29.900]  You need a team to manage these types of risks.
[17:30.160 --> 17:34.880]  It's great that you want to take responsibility, but you must have accountability for these
[17:34.880 --> 17:42.380]  processes. And for both parties, be honest about timelines. I know it's hard. You can't take this
[17:42.380 --> 17:55.190]  process personal. One item that I'd like to see more of is I think tabletop exercises specific
[17:55.190 --> 18:00.590]  to your organization's business model are important. They can help identify responsible
[18:00.590 --> 18:05.810]  personnel and develop policy in advance of a disclosure. And a great way to
[18:07.710 --> 18:13.430]  create a scenario that's more realistic is to maybe bring in a researcher that you've worked
[18:13.430 --> 18:20.450]  with in the past. They probably have experience doing disclosures in a way that could be difficult
[18:21.070 --> 18:24.750]  for their experience. And bringing them in and seeing their expertise
[18:24.750 --> 18:29.070]  would be a huge opportunity for your organization to grow.
[18:30.750 --> 18:34.790]  So researchers and vendors, while you're working together,
[18:34.790 --> 18:39.430]  you need to be honest, again, about these timelines and plans for vulnerability.
[18:40.030 --> 18:44.510]  I really don't enjoy seeing researchers dropping zero days to the internet,
[18:44.510 --> 18:48.870]  especially in the aviation sector, without a reasonable attempt to contact the company.
[18:50.610 --> 18:56.670]  But, you know, that just really doesn't build trust between the two parties in the long
[18:56.670 --> 19:01.970]  run. And I don't believe that it serves the greater good. And the same goes for vendors
[19:01.970 --> 19:08.190]  ignoring researchers. The lack of engagement doesn't build trust and at times causes these
[19:09.570 --> 19:18.230]  uncontrolled disclosures to happen. Finally, have a plan tailored to your goals,
[19:18.230 --> 19:24.030]  vendor or researcher. Both parties in this disclosure should have a plan in place for
[19:24.030 --> 19:30.610]  the disclosure. And as always, CISA is here to help. We have a great deal of experience with
[19:30.610 --> 19:38.630]  this. We partner regularly with SEI, CERT CC. We have direct access to the FAA. We've partnered
[19:38.630 --> 19:45.150]  with the Aviation ISAC. We also have our ACI program to support with disclosures.
[19:46.910 --> 19:53.790]  So, if you have questions about disclosures, here's my contact information. Feel free to
[19:53.790 --> 20:01.970]  send me an email and I will be in the chat box here after the presentation answering some
[20:01.970 --> 20:08.310]  questions. If you have anything, I'd love to support your disclosures. Thank you.