NEWS AT SEI
This article was originally published in News at SEI on: December 1, 1998
Richard D. Pethia is manager of the SEI Survivable Systems Initiative and first manager of the CERT® Coordination Center (CERT/CC). In this interview, Rich looks back at the past 10 years and discusses topics that include
Bill Pollak (interviewer): Tell me how the CERT®Coordination Center (CERT/CC ) began.
Rich Pethia: We started the CERT /CC in November of 1988. At that time the SEI wasn’t doing any work in information security. There were only about 88,000 computers connected to the Internet.
BP: How about now?
RP: There are an estimated 50 million users on the Net, doubling in size every 10 to 12 months. On November 2, 1988, there was a graduate student at Cornell University who let loose a "worm" on the Internet, and it basically crippled the network. If I remember correctly, it was released at night, and people began to see some strange things happening by the next morning. Systems all over the place were failing to operate because the Internet was clogged up with pieces of the worm sending messages to other pieces of the worm. It basically used all the bandwidth of the Internet. There were a lot of people who tried to solve the problem. The Internet has no formal structure, but research scientists at Berkeley, MIT, and Purdue, some of the people at the Defense Advanced Research Projects Agency (DARPA), some of the people on campus here at Carnegie Mellon, some of the computing facilities people here at the SEI, and people at a number of other schools around the country all began to try to understand what was going on. They started informally communicating with one another, captured a piece of the worm, and then began to reverse engineer it. All told, it took a couple of days to understand what was happening and get corrections out to the world so that they could get this thing out of the network.
BP: So this happened on a grassroots level; there was no organization to the response.
RP: Exactly. Then there was a series of meetings later in Washington, DC. They were called by the National Computer Security Center (NCSC), a public arm of the National Security Agency (NSA). They called together a lot of participants and asked for ideas on what might be put in place so that if this kind of problem ever happened again, the response would be more effective.
BP: Did they contain the problem in a couple of days?
RP: Yeah. It’s pretty amazing; people really worked effectively together to contain the problem. There was lots of debate in Washington as to whether or not there should be a centralized approach or a decentralized one, and if industry or government should do it. And finally, the director of DARPA, Craig Fields, said "Well, in lieu of all this discussion, which may never end … let’s just do something." So they called up Larry Druffel, who was then the director of the SEI, and said, "We want to start a computer emergency response team." We talked to them for a couple of days, so by this time it was the middle of November--November 17, 1988.
BP: At this point, what were you doing at the SEI?
RP: I was beginning to put together a customer service group and helping put some more structure into the way we went about marketing the SEI’s products and services. When Larry got the call from DARPA, he called together his managers and tried to decide whether or not the SEI should do this. There was a lot of internal debate; a lot of people thought that this type of function didn’t belong in an R&D facility. But he decided to go ahead with it. Somehow, my name was tossed onto the table as the person who ought to start it. So I met with Larry, got myself unhooked from other activities, formed a small advisory group of people inside the SEI as well as a small group of people outside the SEI, and over the next two weeks, we put together a strategy on how we would start such a center. Larry and DARPA had a handshake over money, and on December 7, 1988, DARPA sent out a press release that announced our existence. The phone rang for the first time that night. We had six hours of idle time before we got the first call!
BP: What was the first call?
RP: The first call was from some folks at a research lab on the West Coast that had a hacker in their system. They were trying to trace him back to wherever he was, they were getting very little support from anybody, and they needed some help.
BP: What were the other options available to an organization like this at the time?
RP: They were trying to call the investigative organizations--the Secret Service, the FBI--and they couldn’t find anybody interested in what was happening to them. And that’s really all they could do. At the time, there really was no place else to call. So we ended up working with this guy for the next two weeks, until we effectively got to the point where it didn’t look like--because the hacker was offshore and no investigators were interested--anyone would be able to make an arrest. But we finally talked him out of beating up the systems on the West Coast.
BP: So you actually got on the phone with him?
RP: Yeah. In the early days, we did a lot of that, because nobody would investigate. So the best we could do was to try to convince these people to stop breaking into the systems in the U.S.
BP: Are there now better laws in place than there were then?
RP: There are currently better laws in place and more legal precedent as well. And that’s true both nationally and internationally. There has been legislation that has laid down law in this area, and the investigative organizations have built up their capabilities as well.
RP: So that’s how we got started. We didn’t really have a good feeling for what we would do up front. But there were a couple of principles that we put in place early on that we still hold to today. One of them was the principle of confidentiality: When people call us and tell us about their problems, we promise them that we won’t divulge that information to anyone else without their permission. The only exception to this is if we get a subpoena, which of course we honor. Another principle was that we didn’t want to set ourselves up to be the organization that would solve all these problems, but rather the organization that would facilitate the response. And that’s why we called ourselves the CERT® Coordination Center.
BP: By "facilitate," you mean to help people to help themselves?
RP: Yes. We recognized the excellent work that was done in resolving the problem of that original Internet worm. We didn’t want to cut out big pieces of the community whose talents were obviously important in solving these kinds of problems. So we tried to be very careful to work with the technical community--technologists and researchers--and with the vendors, rather than to set ourselves up as an organization that would somehow replace them. I think that’s another principle we’ve held to, and it’s served us well ever since. We tried to keep a focus on the technical issues rather than get stretched out into investigations and law enforcement, and all the other things that go along with this problem. We were concerned that we would spread ourselves too thin. Very early on, we decided that what the country really needed was a distributed approach, that there need to be multiple response teams, each one focused on a particular community of interest. If you look across the whole Internet and you think about all of the different organizations that are connected, you realize that government or military organizations are very different from universities, from for-profit corporations, and so on.
BP: So your principle was that the incident response teams had to map to these domains?
RP: Right. To give effective response to a particular domain, you really have to understand it, its culture, and the laws and regulations that govern how it operates…
BP: Now, is that, in fact, what distinguishes the various incident response teams?
RP: To a large extent, yes. Many of the teams are focused on individual organizations. Penn State has an incident response team for just Penn State. Boeing has its own team too. Some of them have a national focus; there’s an Australian team, a Japanese team, a German team, and one in the Netherlands. We had originally thought that some of them might be focused on a particular class of technology--one for Unix systems, one for IBM mainframes, and so on--but that never really happened. What’s happened instead, however, is that the product vendors are now participating. So, for example, Sun Microsystems and Cisco each have response teams that address their internal corporate security needs, plus they each have a team that addresses security vulnerabilities reported in their own products.
BP: This whole issue has been raised into the public consciousness. You see it increasingly in TV commercials: the IBM commercial about the hackers who break into an organization and find the payroll records comes to mind. It seems that the world is coming around to something you have been concerned about for many years.
RP: Yes, in a big way, especially in the last couple of years. From our perspective, that’s kind of heartening. Others are now beginning to look at these problems as something they really need to pay attention to.
BP: How do you account for the growing interest in these kinds of problems?
RP: I think there are several factors that are driving the increased awareness. One is organizations like ours, who have been out trying to raise awareness of such issues. In fact, raising awareness was one of the things initially identified in our charter with DARPA. DARPA wanted us to spend a significant amount of time getting this problem out from under the table and putting it out where people could see it.
BP: This relates to your education and training activities?
RP: Right. And at all of the conferences we go to, we give presentations and birds-of-a-feather sessions. We’ve worked to cultivate a relationship with the media. Another thing, I think, is that, as people have begun viewing the Internet as more than just a hobby, but as essential to the way they conduct business, they’ve suddenly begun to realize that they are putting real business assets online. That’s increased the awareness of security risks dramatically. Within the Department of Defense (DoD), about 95% of the network traffic goes over the Internet. The DoD has become very dependent on the Internet and has become very aware of what the risks are, through both a series of attacks that have been launched at them from the outside, as well as their own internal exercises to gauge their own vulnerability. Over time, the importance of these issues has been going up the management chain, so now the most senior levels of the DoD and other parts of the government really recognize this as a problem. I think there are two other things that are going to drive this. One is the potential for liability, the other is the insurance industry. We haven’t seen a lot of major lawsuits yet…
BP: So the insurance industry has a lot of interest in network security.
RP: Yes. The insurance companies--and we’ve talked to several of them--are now beginning to see this area of insuring intangible information assets, or the integrity of the computer operation, as a new area of business. Historically, they spent a lot of time insuring equipment, but not so much time insuring operations or data. They’re now beginning to see this as a new opportunity. As they begin to get involved in this area, they start to set rates based on some assessment of risk. I think that management is going to start to pay attention to security because their business insurance is going to cost more if they choose to ignore it. I think that will motivate people as well.
BP: Tell me about the intruders that you’ve seen. How have they changed? First, let’s start with the original guy who made the worm. What happened to him?
RP: A jury found him guilty of violating the 1986 Computer Fraud and Abuse Act and sentenced him to three years of probation, 400 hours of community service, a fine of $10,050, and the costs of his supervision.
BP: Was he just fooling around, or were his intentions more sinister?
RP: I think he was just experimenting. There’s lots of speculation on what he was trying to do. He certainly wrote a program that was designed to spread itself around the Internet by exploiting vulnerabilities. I think some speculation is that it was a research project that got out of hand. I also think that he may have wanted to prove a point, that he had been telling people for some time that this network was very vulnerable, and the worm was a demonstration of how vulnerable it was. Also, it’s believed that the impact was as broad and as noticeable as it was because of a bug in the code, not by design. So his original intent may have been to demonstrate something, but because of this bug, the program propagated itself all over the place.
BP: In a way, we should probably be indebted to him that his intentions were as benign as they were, right?
RP: I hate to say that anybody ought to be able to break the law for any reason. But it certainly was a wake-up call, and it got a lot of people’s attention. Some of the other incidents that occurred over the years have done the same--in some cases, because they were large incidents with widespread impact, and in other cases because they caught the attention of the press.
BP: What percentage of incidents can be attributed just to smart kids who are fooling around?
RP: I think a lot of it is that. My guess is that 80% of what we see, if not more, is from the "recreational hacker," people who are out there testing their skills, trying to explore networks with no real malicious intent in mind other than seeing how far they can go and what they can get away with. The problem is the side effects that can occur that can accidentally cause a lot of damage. There are some trends in the incidents that we’ve seen, in terms of skill level and sophistication of the hackers. Over time, the attacks have become more and more sophisticated. The hackers understand more and more about operating systems, networking software, and network topology.
They have really investigated the network protocols and have taken advantage of the flaws in them; they’ve learned how to "chain" vulnerabilities together. If they can’t get from where they are to where they want to be in one step, they’ve learned how to take multiple steps to get there. And they’ve automated their attacks. When we started, we saw a lot of people typing in commands on the keyboard; now, almost all the time, we see things written up in scripts or pieces of software that execute the attacks. This gives hackers a lot more leverage. We’ve seen more and more use of network scanners, which will basically scan through a whole series of systems on the Internet looking for those that are vulnerable. We’ve seen more use of network sniffers--planting a piece of software in some system on the network where there’s a lot of traffic going by to capture information. Even today, a lot of the logons happening on networks are still going through clear text with no encryption. The system ID, account name, and password are all traveling through clear, plain text. Sniffers can just grab that information; people are giving away the keys to their systems. On the other hand, given the widespread ability of these tools …
BP: Because they’re all available on the Net?
RP: Right. You can get a nice burglar’s toolkit right off the network without working very hard at all. A few Net searches, and that’s that.
BP: And that’s legal?
RP: Right. Nothing illegal about it. But because of that, there’s a whole new generation of not-so-sophisticated hackers who can simply use the tools and see how far they can go just by pressing buttons. And that just raises the annoyance level. We now get about 35 reports each daythat are real incidents, because so many people are out there probing systems, and so many more people are out there not protected. So these guys are being successful.
BP: A lot of this seems to me to be like the natural escalation of a game--like chess or any other game--in which over time, the players develop expertise. It seems that this escalation has no limits. As you get better at your responses, the hackers get better at thwarting your responses.
RP: It’s going to keep escalating. I think that’s exactly right. And I think what the good guys have to do is understand that they can’t depend so much on the static kinds of defenses they used in the past. Their protection strategies are going to have to be much more dynamic. They’re going to have to realize that any defense they put into place is going to degrade over time, because the hackers are going to find a way to penetrate it sooner or later. And so defensive people are going to have to counter that, and be much more dynamic in their responses than they are today.
BP: Let’s for a minute put aside the recreational hacker and talk about the real bad guys.
RP: Over the years we’ve seen much more theft of intellectual property and valuable information. Industrial espionage. People stealing things of value that they can go and make a buck with. Extortion is on the rise too. We’ve seen more denial-of-service attacks, especially over the last two and a half years, where it seems pretty obvious that someone is either trying to put someone else out of business or to do some serious damage to the business. A lot of these attacks are aimed at Internet service providers (ISPs) to put their systems out of commission for some number of hours or days. You can really hurt an ISP’s business that way, because the customers are going to go someplace else. We have seen much more of that. Certainly there have been some big notable things in the news, like the Citibank case a couple of years ago, where a couple of million dollars was lifted out of the Citibank vaults by electronic funds transfers. All but a couple hundred thousand of that was recovered, but that’s still a very big deal. Those things make the news periodically. The suspicion is that there’s a lot more of this that goes on that people aren’t willing to talk about, although there is little hard data to support that. We’ve seen attacks that could be potentially life threatening, as people have begun to attack hospitals and clinics. The case we often bring up in this regard was the one reported by New Scotland Yard several years ago, where a hacker broke into a medical facility and changed the test results on cancer tests from negative to positive, so that for several days, several women thought they had cancer when they didn’t. Another case was where a hacker broke in and changed data in a CAT scan. Scans had been done that were to be used for brain surgery, and the surgery had to be postponed until the system was rebuilt. As organizations put more and more of this sensitive information online, they’re putting whatever’s attached to the information--like people--at risk.
BP: This brings us to critical infrastructure protection. Can you talk about what’s going on with that, and what the SEI’s role is?
RP: The Presidential Commission on Critical Infrastructure Protection was established about two years ago to assess how vulnerable the United States was to terrorist attacks.
BP: And a potential target of terrorist attacks is the critical infrastructure.
RP: Yes. The commission itself had a broad charter to look at all forms of terrorism, not just information infrastructure security … I think their study lasted about 18 months. The report that they produced is out there on the Web.We sent them a white paper, as did many other people. It was interesting that the area that they finally focused on was primarily information security. They found that the problem was pervasive throughout the eight critical infrastructures that they looked at. They found that the information infrastructures were becoming increasingly interconnected, and that an attack against any one of them would potentially have a ripple effect on the others. And for the most part, with the exception of the financial community, the infrastructure operators really weren’t all that aware of their potential vulnerability or the seriousness of it. The commission recommended that a number of things be put in place, and some of that is actually on its way in the federal government right now. One of them was the establishment of the National Infrastructure Protection Center (NIPC), which is now part of the FBI. As part of their charter, the NIPC has an incident response and an investigation role, and also a preventive role. In fact, we’re meeting with the FBI to see how we can work with them to support their effort. There is also something called the CIAO (Critical Infrastructure Assurance Office), which was established by Presidential Decision Directive 63 (PDD-63), and they are responsible for coordination of the infrastructure-assurance activities across the federal government.
BP: What else is the government doing to protect the infrastructure?
RP: Each federal agency is required to have a plan for how it is going to improve its security, and those plans are due right about now. The idea was that the federal government would take the lead in trying to mount a national effort to improve security, and one way is by improving itself. The second way is that one federal agency has been assigned for each of the critical infrastructures, to work with that industry group to help improve the information-security aspects of that industry. For example, the Department of Treasury has been appointed to lead the financial sector, the Department of Transportation has the transportation sector, the Department of Commerce has the telecommunications world, and so on. Each of the lead agencies, in conjunction with industry leaders from each of the industry groups, is tasked with putting together a strategy for how that critical infrastructure is going to work with the federal government to improve. I have yet to see any outputs from any of those efforts. I think that discussions are underway, but it’s too early to tell where all of that is going to go.
BP: It sounds a bit top-heavy given the requirements of the situation.
RP: Well, my concern is that because it’s been spread across so many agencies, it may start to lose focus.
BP: What sort of coordination is there?
RP: That’s what the CIAO is there to do; to keep all of those efforts coordinated.
RP: The other activity within the federal government is the proposed increase in R&D in information security. There was a significant research component to the agenda as well. And we’ll have to see what Congress decides. Our participation in this so far has been working with the FBI at the NIPC. In fact, we have one activity with them now to look at ways to analyze incident data, to try to spot trends. We have been working and have had several discussions with Jeffrey Hunker, who’s the director of the CIAO. He’s been talking to us about R&D agendas as well as awareness and training. How can you build an understanding of this problem, but also, how can you begin to build skilled practitioners who are capable of working within these problem areas? That’s one area that we’re especially concerned about. Over the years, as we’ve talked to people on the phone, our perspective is that the average level of ability of system administrators has been declining, given the explosion in the use of the technology.
BP: That’s understandable.
RP: A lot of people are being pressed into service as system administrators who don’t really have the technical foundations.
BP: And modern systems make it a lot easier to hide the user from the implementation details of the system. You lose that deep technical expertise.
RP: I have a chart that relates that information. The top chart is the growth of the Internet, and the bottom chart is the number of people getting Bachelor’s and Master’s degrees in the information sciences over the same period of time.
RP: What’s interesting to me is looking at this gap, which is getting wider over time. To me, that means increased vulnerability. I think that’s what we’re seeing out there right now. This whole area of training--not just awareness, but building real skills--I think is critically important. The systems today aren’t any easier to administer than the systems of 10 years ago. But yet, we’re asking people with less and less technical skill to take on that task.
BP: Is there now more security built into systems?
RP: Yes and no. At the architecture and design level, I think many systems are better… I hate to make this broad generalization, but I think there’s more attention at the architecture and design level being paid to security than there was 10 years ago. The problem that I see is that at the implementation level--the code that’s going out today is just as buggy as the code that went out 10 years ago. About 90% of the vulnerabilities we see aren’t caused by errors in design, but by weak implementation. And that’s not getting any better at all; in fact, I think it’s getting worse. Vendors are being driven by the marketplace. Time to market is critical for them: "Get the product out the door, and if it’s accepted, fix it later, and if it’s not accepted, forget the product and go with something else." I think we’re seeing that in many of the products.
BP: So the software problem hasn’t disappeared.
RP: No. It’s just gone to a different place.
BP: What would you recommend for a company to do to help itself? A company that has very sensitive data in its system, for example.
RP: Oh, a couple of things. First of all, I’d encourage them to take several views of the problem. One of them is to just assume that sooner or later, they’re going to have a problem, and to get ready for it. They need to have their own policies, procedures, and incident-response capabilities in house. If something happens, who are you going to call, what are you going to do? Are you going to decide to investigate or not; if so, what law-enforcement organization are you going to call in? What senior management officers are going to be notified? What authorizations do system administrators have so that they can begin to immediately investigate the problem? Does that include the ability of the system administrator to look at any piece of data on the system? All those decisions need to be made in advance, so that when something does happen, the response can be quick. Incidents tend to get worse over time, so the longer an intruder has access to a system, the more deeply and broadly the intruder can penetrate an operation.
You want to be able to deal with it quickly, and that means having things in place ahead of time. The next area is prevention: beginning to develop real strategies and putting things in place to help prevent these incidents before they occur. We’re currently working on a security self-evaluation method that we hope to have available to customers in a year or so. It will give them guidance on how they should think about the problem, how they should analyze their own operations … A lot of this involves understanding what’s important to them. We see a lot of people who do get interested in security who make the mistake of trying to do "all or none." Typically in most organizations, it’s only a small percentage of their operation or a small percentage of their data that’s critically important. We encourage people to understand what that is, and to invest a lot of time and energy there and not so much in other places. People should also get plugged into information sources like the CERT®/CC and CERT® advisories, and other things on the Net, so that they can stay current on vulnerabilities and threats. They also need an active program to fix systems when vulnerabilities are found …
BP: Before something happens.
RP: Right … Understanding the kinds of defensive things they can put in place--firewalls, policies, procedures--that will give them protection against at least everyday hackers, and in those critical areas, protection against people who will invest more time and energy trying to get access to that data. As part of that, we encourage people to not think of intruders in only one way--to think about different kinds of intruders who would be interested in them for different reasons. The recreational hacker who manages to stumble across you while searching the Net might be interested in you because you’re somehow highly visible to them and "look juicy"; the criminal is interested in you because he or she is trying to make money by stealing information from your organization or by putting you out of business; and the terrorist wants to make a big political statement and is looking for a place to have a big, visible impact. Putting defensive strategies in place is another important thing that we think those organizations should do, and making sure that they have at least some of their staff focused on that problem, rather than having it be assigned as part of a secondary or tertiary duty, which we see happening in a lot of places.
BP: Is the SEI an example of an organization that "looks juicy" to a recreational hacker?
RP: Certainly. The CERT® /CC gets pounded on all the time. People have been trying to get into our systems for years. So we’re under a sort of constant attack. I think any organization that’s publicly visible, certainly any organization that’s visible and claims to do security work, is an interesting target.
BP: Where do you see the Internet going in the next 10 years?
RP: Much of traditional information security is based on a model of a bounded system--a system where you have defined who has access to what, where the endpoints of the network are, and what’s attached to the endpoints. For every person who uses the network, you have some way to authenticate who they are and know where they are. Traditional security depends on having this very structured network. The Internet, on the other hand, looks less and less like this every day. It has been growing at a furious pace, and I think we’re going to see this network continue to grow dramatically in both size and function. Low-cost network-access devices will make access affordable to almost everyone, and almost everyone will want to use it because of the applications that the network will support. For example, there will be a blurring between the Internet and the cable networks--entertainment over the network or networking over the cable systems; they will eventually be integrated. More information will be available to more people, and there will be no need for people to identify who they are. There will be more electronic commerce, and there will be some fundamental changes in the way we do business. For example, real-estate brokers will behave very differently in a world where buyers have quick, direct access to property listings and to the sellers themselves. We will see a demand for the equivalent of cash transactions over the Internet--transactions where it's not important that the buyers and sellers authenticate themselves to each other, only that there is a fair exchange of value.
So a lot of concepts that we’ve used for years won’t apply as the networks evolve. You’re seeing more and more use of various kinds of networking techniques to make it less and less possible to know who you’re dealing with. It’s currently easy with today’s protocols to simply "spoof" the protocol, to disguise your point of origin and make it look like you’re attacking from someplace you’re really not. Wireless networking will just exacerbate that. In fact, I saw a neat little gadget last week. It’s a cellular modem, about the size of a cell phone, plugged into the back of a portable PC, and there’s a parallel cell phone system that’s exclusively for these devices. So now you can go anywhere in the country...
BP: And put a modem on one of these.
RP: Yes. And remotely get access to anything from anywhere. So the whole concept of being able to identify who this person is, being able to track them back, is just going to be more and more difficult to do. I think that’s one of the problems we will face in the future. Another one is that I expect to see more and more real full-scale network computing; more cases where the application depends on the network being in place. In fact, the application is distributed broadly across the network.
BP: The Java model.
RP: Right. And so, this whole idea of being able to say, "I can restrict my organization so that only certain people or systems have access to my computers, and have the people in my organization restricted to only having very limited access to external computers," that’s beginning to go away. And with that, the whole concept of a firewall begins to disappear, because the firewall is nothing more than a filter that enforces the policies for restricting access that you build into it. And as those policies break down, the whole concept of the firewall goes with it. The problem is, we don’t have anything in place to replace those concepts, and that’s going to be one of the next big challenges. In this world of truly distributed computing, with things ubiquitously available, with a lot of anonymous people running around, what are the security models we will need to have in place to deal with that world, and then what technology are we going to need to support it all?
BP: That seems like an entirely new frontier for security.
RP: And I think a lot of people are concerned about it.
BP: It sounds as if you will be very busy in the next 10 years.
RP: I don’t see any end in sight. It’s going to continually be a challenge to keep things updated. Again, as any sort of defenses are set up, the bad guys are going to be right there. It’s going to be a footrace. One side is battling against another. But then on top of that is this whole changing technology that is going to drive an endless series of new business opportunities and new online applications that allow people to do business in new ways. And each of those changes is going to require a change in security, policy, and technology.
BP: What about the problem that so many organizations are having these days finding qualified professionals to staff their needs?
RP: There is a critical need for more people who are skilled and work in the area of information security, especially at the technical level. The other big need that we see out there is for organizations that provide training and education. If you look at the number of schools in the country that have anything that’s in any significant way focused on information security … there are only a handful, maybe five or six. Given the need for these people out there, that’s nowhere near enough. The job market is just tremendous in this area for people who have strong skills in technology.
BP: Is it difficult for you to find qualified staff members?
RP: It’s very difficult. And everybody who I know of working in this area is trying to increase their staff. The private sector consulting firms are trying to grow in major ways to keep up with the increased demand. I hope that the universities pay attention to that, because there’s going to be an increasing need from government and industry for trained professionals in this area. Even junior colleges, to help some of the younger folks aim in the right direction, would be a step forward.
The other issue that’s going to be kind of nasty to deal with over the next few years is that, given this big increase in demand on the one hand and a lack of qualified professionals on the other, the marketplace is going to be susceptible to a bunch of snake-oil salesmen. I think we're going through a risky period right now, where some of the organizations and people who offer security products and services don’t really understand the security issues or technologies, they take a surface-level look, and I don’t think they know enough to know that the services that they’re offering aren’t sufficiently robust.
BP: And decision makers under pressure are susceptible to taking actions that are ultimately not in their best interests.
RP: I think the market has to be very wary of that for the next five years, until this balance between demand and trained professionals settles out. I’m really worried that a lot of people are going to invest a lot of money and time in the belief that they’re going to implement real solutions, when essentially they’re just as vulnerable as if they had done nothing.
Richard D. Pethia manages the Survivable Systems Initiative at the Software Engineering Institute (SEI). The Survivable Systems Initiative is focused on improving trust in network-connected systems by: developing and transitioning system administration tools and techniques that improve the security of existing systems; exploring, developing, and transitioning software engineering practices that lead to systems with improved security characteristics; and, through the CERT Coordination Center, conducting security incident-response activities and fostering the development of incident-response infrastructures that lead to rapid correction of vulnerabilities and resolution of incidents.
Before coming to the SEI, Pethia was the director of engineering at Decision Data Computer Company in Philadelphia, Pennsylvania, where he was responsible for engineering functions (software engineering, hardware engineering, mechanical engineering, drafting, and documentation) and resources (engineering laboratories, engineering systems, and development tools) required to support new product development. The product line of this company is personal computers, workstations, printers, and high-performance telecommunications controllers. Pethia also was manager of operating systems development for Modular Computer Corporation in Fort Lauderdale, Florida. Product development focused on real-time operating systems and other system software to meet the needs of industrial and government clients in the application areas of industrial automation, process control, data acquisition, and telecommunications. Pethia has additional experience in the areas of time-sharing system development, telecommunications, and networking. He has 30 years’ experience in both technical and managerial positions.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.