| Home President's
NSTAC Meetings March
2002 Creating
a Cyber Interagency Working Group
NSTAC XXV Meeting - March 2002
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.
Questions or comments
concerning this site? Please contact the webmaster.
Privacy
Policy |