Home   President's NSTAC    Meetings    March 2002   Creating a Cyber Interagency Working Group

Creating a Cyber Interagency Working Group.
Remarks by Howard Schmidt, Vice Chairman, President’s Critical Infrastructure Protection Board, before the Business Session of the President’s National Security Telecommunications Advisory Committee (NSTAC), Washington, D.C., March 13, 2002.

Thank you very much, and thanks for the opportunity to be here. And I feel bad that my first discussion in a new role with the NSTAC is a tasking of a magnitude of something we've never seen before either in private sector or in Government, and that's the needed creation of the Cyber Interagency Working Group.

A quick history on this, there's a protocol out there called ASN.1, Abstract Syntax Notation One, that's been a fundamental piece of computing protocols for time immemorial. I once asked a very distinguished developer about this protocol, and he told me two things: One -- it's everywhere. It's in soda machines that send information back to tell you when it's time to be refilled. It's in satellite communication systems. And the second thing he told, it's the same basic piece of code used over and over and over because it's such a difficult piece of code to write, it's easier to recycle in all these other pieces.

So, with that, I just want to take a few moments and tell you where we are on it, and what the situation is that's created this.

Last year, a Finnish university did some research on different protocols and identified a vulnerability in the ASN.1 implementation -- not the code itself, but the implementation -- that allows some things to occur. First and foremost, if the specific number of data strings are assigned to it, it would crash the system. That's the good news.

The bad news is if a greater number than that would be assigned to it, it gives you the ability to run arbitrary code -- conceivably, a Trojan program, a Worm, or something else like that -- that could actually give someone control of one of these systems in which ASN is implemented.

And here is the background. ASN is, indeed, a standard syntax that defines many of the protocols that are in use today. Because of its great flexibility, it's widely used in many things that we do -- for messaging in the Internet, intelligent networks, cellular telephones, ground-to-air communications, interactive television, intelligent transportation system, public switch telephone network call routing and other communication systems.

Dan [NSTAC Chairman Daniel P. Burnham, Chairman, President and CEO of Raytheon Company] had mentioned a moment ago about SNMP, the simple network management protocol, and that's one of the things that we've seen most prevalent in the past month that we've been working this issue found ubiquitously across our networks.

It was originally developed in 1984, but because of its complexity and with the growth of Internet protocols, it's more widely used than ever. The International Standards Organization, ITU [International Telecommunication Union] adopted it in 1998, in S.208.

It basically identifies or is a function in the application layer of the OSI model, and each communication system contains a subset of the ASN.1 encoding-decoding scheme written in the language of that particular system. Before the system sends data basically it looks at this ASN code to send that data out there. When the second system receives it, it again looks at that ASN.1 code to decode the information that it's received. So you can see it is widely used on both ends.

I want to take another moment and just give you an example of some of the protocols that we see today that are in use. Management of the SS7 [Signaling System 7] routing tables is accomplished by messages encoded using ASN.1. Eight hundred [800] number and local number portability routing information are retrieved using ASN.1 based on SS7 messages. ISDN [Integrated Services Digital Network] features, such as reverse charging and international calling card verification use ASN.1.

Every call placed on a cellular telephone in North America generates SS7 messages that are described using ASN.1 and encoded using one of its predefined encoding rules to establish and maintain that call. This includes AMPS [Automatic Message Processing System], TDMA [Time Division Multiple Access], CDMA [Code Division Multiple Access] and GSN [Global Satellite Network]. Voice over IP and Next Generation Networks [NGN] also use ASN.1 encoded messages.

The latest generation of air-to-ground and ground-to-ground protocols employed by FAA [Federal Aviation Administration] and the ICAO, International Civil Aviation Organization, also use ASN.1, including control information exchange between ground and aircraft flight control systems, as well as aviation ground-to-ground exchanges.

Electric and gas utilities rely on ASN.1 to control the latest generation of substations, transformers and other vital networks. And companies that traditionally used to be known as -- I've heard Craig Mundie [Senior Vice President and Chief Technical Officer for Advanced Strategies and Policies at Microsoft Corporation] say many times -- used to be known as trucking companies, now they are IT [information technology] companies with trucks. They also use ASN.1 to track their packages.

We discovered back in February -- we had a number of meetings on this issue -- that this was an issue that needed some resolution. We need to involve a vast number of people while at the same time keeping the issue as quiet as possible. When the SNMP vulnerability was announced February 12th, the intent was to focus as much of the work on the SNMP because that was the one that was most readily handled. We've been working with a number of the vendors to make sure that their patches were being worked on to deal with this.

The next phase of this, of course, was looking at the bigger picture. ASN.1 is everywhere, as I mentioned a moment ago. The group that we formed, which is up on the screen right now, involves many of the agencies within the Government that are part of a full-time working group that will be housed over at NCS, working with the Cyber Security Board to look at the issue across all the Government agencies as well as the private sector organizations.

The initial intent of the group is to make this a 120-day effort. We need to immediately identify the vulnerable protocols and products that are currently out there. We had a meeting yesterday, led by NCS [National Communications System], NIPC [National Infrastructure Protection Center], and Majorie Gilbert from our office, and the good news I have in this discussion so far this morning is at least we have identified that one of the key issues around CRBROS (phonetic) is not vulnerable to this, which was a great concern.

We also want to identify the critical systems and, as one would know, there's much more to a critical system than just having a box within your network. We have to identify those and see what level they are down in the system and what, if anything, we can do to fix them.

Obviously, we've had a number of briefings, and I thank the NIPC and the NCS for their work in the early stage of this, spending weekends involving the private sector -- IES [NSTAC’s Industry Executive Subcommittee] members, ISAC [Information Sharing and Analysis Center] members -- folks that were brought in on weekends to identify how critical this problem is and start to ask for industry's assistance in working on what we can do to patch these things.

And, of course, the other component of this is to prepare for a response. There has been a little chatter at this point that we've started to see some hackers talking about looking at ways of exploiting this. If you've followed any of the things that we've seen in the latter part of last year relative to Code Red and NIMDA, we found out there was a packaging of some exploits that would go out and look for these things, then hit the exploitation nature of those. That's the same thing we're concerned about now. If, indeed, it gets to a broader audience in the hacker community, we have to have a response plan in place.

What are the things we are looking at? First and foremost, we have to assist the appropriate policy authorities to distribute the guidance across their organizations and the industry sectors. That's the document we should have coming out shortly. We've got to make sure -- and that's why NSTAC is such a valuable partner in this -- that we are in lock-step with industry in trying to resolve these issues. Many of the systems we all depend on, not only that we create, we also depend on for our day-to-day activities are affected by this.

We've been working with our international counterparts. One of the early discussions we're engaging in with Canada, Australia, New Zealand, the folks that we have day-to-day relationships with at the JTF [Department of Defense’s Joint Task Force for Computer Network Operations], as well as other parts of the Government, making sure that they are very much aware of this and onboard with us.

There's a great inventory that needs to take place. This has been around, as I mentioned in an earlier comment, since 1984. There's a lot of pieces of hardware out there that some of us probably don't even know we have, which are vulnerable to this exploit, if indeed exploited, are the vulnerability.

We also have to look at the affected industries and build some consensus on what we're going to do, including public messaging. This has the potential to be very dramatic if we don't take the necessary steps. We also need to make sure that we don't lose the confidence of those in the public that depend on these systems.

Also, to encourage the correction of vulnerable technologies. Some of the systems that are out there, the companies are no longer available. We no longer have the ability to reach back to a major company, such as ones sitting around this table, and ask for some assistance in identifying fixes. We have to remediate on-the-fly in some cases.

Also, to encourage the development of the protection methods. One of the early pieces that came out from CERT-CC [Computer Emergency Response Team-Coordination Center at Carnegie Mellon University] was providing all the members here, as well as the other industry representatives, some mechanisms by which you can protect your systems, particularly ones that are Internet-based and obviously the most vulnerable.

And then, of course, for the law enforcement and the intelligence community, tracking the exploits and going back -- and I'll jump on Senator [Robert] Bennett's bandwagon as well -- the exemptions to FOIA [Freedom of Information Act], the ability for private sector to share with Government what exploits are taking place, as well as share with each other to help protect yourselves.

And, obviously, optimize the process for the potential managing a national cyber event.

Here's where we need your help, and I think once again you are uniquely positioned to assist us on this. These are four areas that the industry has a tremendous amount of expertise in that we need you to go back and help us identifying the expertise in your organization that can work with our technical committee in these particular areas here -- for the TMN, ISDN and Non-ISDN supplemental services, TCAP, and especially SS7.

So, as I said, this is an issue that we need everyone's help on. This is not something we can wait and see what may develop in the future. There's already been some discussions as well. It's been available for a month now, and we have not seen any exploits.

We've had buildings in New York for many, many years before we saw airplanes crashing into them. We can't wait for something to take place in this area as well. So, with that, Mr. Chairman, I thank you for the opportunity to give this information, and look forward to your assistance in helping to resolve it.

Published for internal information use by the National Communications System. Parenthetical entries are speaker/author notes; bracketed entries are editorial notes. This material is in the public domain and may be reprinted without permission.

Privacy Policy