Network Security Consulting Blog

News of RIM’s apologies concerning the multiple-day outage of its services beginning Saturday morning October 8 illustrates a very important point. At the retail level it may be okay to remain silent or mumble about the circumstances of an outage (as my cell provider did in this case).  However, when dealing with enterprises which purchase services in mass quantities as part of a broader strategy of delivering services to their customers through a well-equipped employee base the reverse is true.  RIM had remained silent for five days about the details, causes – and most importantly – the estimates for remediation of this outage. This is inexcusable for anyone offering an enterprise class product.

A company that understands the process of maintaining its systems and services and guaranteeing the reliability of those systems and services (and the revenues they support) will over-communicate about the circumstances of any unplanned outage.  By over communicating about an outage, the company shows the extent of its understanding, preparation, and detailed response plans. Obviously, developing incident response in a professional way is time-consuming and requires a great deal of maturity on the part of the company.  After all, you might never need these procedures and processes.  Most companies discover that developing incident response processes, tests, metrics, and plans is in and of itself a developmental activity for any large organization. These benefits can take many forms but two that are relevant here are: (1) improvements in the processes that underpin reliability itself such as reliable systems and applications development and (2) improvements in the incident response process such as better root cause analysis.  A company that can discuss these issues openly with its customers can subtly communicate that it has already brought a high level of professionalism to the problem and is in a position to leverage that professionalism for the benefit of its customers and for the reputation of the company. No amount of promise making or apologizing can substitute for this.

RIM did not do this and apparently cannot do it.  In the absence of communication during an outage, one of two explanations can be considered. The company either cannot figure it out (the most generous explanation) or they know the answer but the answer is so ugly they cannot afford to tell their customers the truth. No matter how heartfelt the apology, RIM’s enterprise customers don’t want or need apologies. What they need is information, substantial and detailed assurances about future support and possibly refunds. In a sense the damage to RIM is done. Emails were dropped and the corporate processes they supported were let down in a very public way. This debacle comes at a critical and unfortunate moment for RIM in light of iPhone and Android successes. As the outage unfloded, many people were already questioning RIM’s competitiveness and the longevity of its product line.  While it is true that no other provider even comes close to the quality of RIM’s product and service design and specifications for mony corporate procurement officers, the execution in this case shows that RIM is not able to walk the talk. This brings into question the true definition of “enterprise class.” And the tide of “bring your own device to work” is coming in inexorably and threatens to isolate RIM on a shrinking island of customer loyalty.

I can’t think of a worse time for RIM to be facing serious questions about its product and service reliability. In 30 years of professional information security practice, I have often observed that ways can be found to cut corners when it comes to the security of information systems and “bring your own device to work” is a perfect example of this. However, when it comes to reliability enterprise buyers stick to their guns and insist on the contracted reliability or else take their business elsewhere. I wonder what deals RIM has cut over the past weeks for aggrieved companies who were harmed by RIM’s outages.  Since I am a retail, second tier customer, I have been offered “free premium applications” by RIM.  What a scream! It might be more successful to take out an ad in the Wall Street Journal apologizing for RIM’s lame offer of compensation.  I probably spent four hours trouble shooting the problem at the time.  Oh, well.   It would also be interesting to see how many inquiries have been received by insurers lately about the availability of insurance against an outage of RIMs BlackBerry enterprise service. Not a good sign for RIM in the future.

DR. GENE SCHULTZ WILL TEACH A NEW SANS INCIDENT RESPONSE MANAGEMENT COURSE OCT. 14-15 IN BALTIMORE

Dr. Gene Schultz, Emagined Security’s Chief Technology Officer, will be teaching a new SANS course, Incident Response Management, October 14 – 15 in Baltimore, California. If you are an incident response or information security manager or are involved in highly related functions such as business continuity or disaster recovery management or IT audit, there is a good chance that this course is for you! Its course content is as follows: Read more…

A few days ago I discovered a Web posting with a fascinating title, “A short history of hacks,” on the Computerworld site. A nicely written piece, it covered events such as the Morris and ILoveYou worms, as well as the distributed denial of service attacks in February, 2000 that ended up being so costly for companies such as ZDnet, Amazon, e-trade and eBay. Amazingly, however, this history did not mention two of the most dramatic and severe series of cyber attacks that have ever occurred, the Operation Desert Storm/Desert Shield attacks against the US military in 1990 and 1991 and the widespread Internet sniffer attacks between 1994 and 1996 (to be covered in the my next blog entry).

The Operation Desert Storm/Desert Shied attacks occurred at a time when the Internet was still very young and not all that widely used. You may recall that soon after the Morris Worm struck in 1988, the US Department of Defense (DoD) split the Arpanet into two separate networks, the NSFnet (later to be called “the Internet”) and the Milnet. The DoD’s motivation was to protect the military’s main unclassified network from events such as widespread worm infections originating from the public network. At the time, the NSFnet the Milnet were only two of a number of wide area networks used for long haul communications. Among the other networks that existed at the time were NASA’s SPAN network, IBM’s BITnet, and the Department of Energy’s ESnet, The DoD did not want to totally isolate the Milnet, however. Accordingly, gateway machines that enabled traffic to get to and from networks such as ESnet were put in place. What the DOD did not anticipate was the possibility that attackers might be able to gain unauthorized access to hosts in other networks and then go right through the gateways to gain unauthorized access to Milnet hosts.

The first indications of the widespread break-ins into Milnet hosts were from log entries in Department of Energy (DoE) machines. The attackers broke into DoE machines using what now seems like very rudimentary attack methods, including password guessing (or sometimes even using null passwords), exploiting a VMS vulnerability in the SYSMAN utility, exploiting trust relationships between hosts, and a few others. Once they gained access to a host, they often already had super-user privileges, but if they did not, they exploited other vulnerabilities to take complete control of the victim systems. They then installed back doors. By breaking into hosts at DoE sites such as Los Alamos National Laboratory, Lawrence Livermore National Laboratory, Fermi National Laboratory, Sandia National Laboratory, and Brookhaven National Laboratory, the attackers had more than enough springboards from which they could launch attacks against Milnet hosts at military centers such as US Navy Headquarters, the Pacific Fleet Command,, Rome Air Force Base, Kelly Air Force Base, the Pentagon, and many more, which they did successfully day after day for well over a year.

Once the attackers broke into DoD hosts, they used commands such as grep in Unix systems to discover files that contained the information they desired: information about military equipment, weapons systems, troop and warship movements (especially in connection with Operations Desert Storm and Desert Shield) and much more—they often even searched for “nuclear!” The attackers stole so much information that they quickly filled the hard drives of their own machines. They then resorted to downloading huge amounts of information onto systems at the University of Chicago and Bowling Green University.

Incident response was a very new function when these attacks occurred. The DoE’s Computer Incident Advisory Capability (CIAC) first noticed the attacks and reported them to officials at both DoE and DoD. CERT/CC also received reports of attacks with similar patterns from Internet users. At one point the DoD, DoE, U.S. Navy’s incident response team, the National Security Agency, the US State Department, the National Institute of Standards and Technology (NIST), the Central Intelligence Agency, the Air Force Office of Special Investigations, Army Intelligence, the Federal Bureau of Investigation, CIAC and CERT/CC were involved. Cooperation and coordination were extremely difficult to obtain, but despite many obstacles (most of them political and bureaucratic in nature), these entities managed to conduct reasonably successful investigation efforts.

The gang of attackers was led by a rather harsh ringleader who taught his understudies how to hack into systems in return for his receiving the information they were able to glean. I knew the names of all the principal attackers, and because of a successful CIAC effort to tap their electronic talk sessions, I even learned where they lived at the time. The attacks, which originated from the Netherlands, were ostensibly financially motivated. The ringleader wanted to find a buyer for the information, but to the best of my knowledge he was never successful in doing so. The State Department pressed the Netherlands to charge the identified individuals, but this country declined to do so on the basis that at the time, breaking into systems was not a against Dutch law. To at least some degree, however, justice was served—the ringleader reportedly ended up going to prison for credit card fraud.

The news of the attacks did not reach the public until John Markoff of the New York Times published a front page story describing the attacks in the fall of 1990. How he pieced together the bits and pieces of information that he had amassed was simply amazing. Additionally, about the same time ABC News ran a lead story about the attacks. Later, NIST had me publish an unclassified account of the attacks.

In all, little changed as a result of the attacks. The DoD and DoE did not really improve their cyber security, nor did US legislators propose or pass any national legislation that required better security within the government. As you undoubtedly know, cyber security within the government has improved somewhat over time, but it still has a long way to go. If powers-that-be within the US government had taken the lessons learned from the Desert Storm/Desert Shield attacks more seriously, however, the government would without question be way ahead of where it is now.

At a conference last week I heard a speaker talk about a network security methodology in which IP addresses known to be associated with attacks are used to set up special protections for critical assets. The speaker said that in this methodology sources such as dshield.org and CERT are used to identify malicious IP addresses. After the end of the presentation I expressed doubt concerning the validity of such IP addresses. Surprisingly, he countered that he had a high degree of confidence in them.

Over the years I have learned a few principles regarding IP tracebacks that are nearly always true. One is that unless network traffic consists of IPsec packets, the source IP address of this traffic must be viewed with considerable suspicion. Why? The main reason is the prevalence of IP spoofing in Internet attacks. Another is the emergence of mobile bots, bots that inhabit hosts for a while, then leave and take over other hosts. As such, determining which particular IP address is malicious at any time is nearly impossible. Well-intentioned but mistaken reporting of malicious IP addresses on sites such as dshield.org is still another reason. Too often users of intrusion detection tools such as Snort take output at face value instead of further investigating exactly what has occurred by collecting and analyzing additional information such as packet dump data. I remember many times when I worked at Berkeley Lab how someone posted a Berkeley Lab host IP address on dshield.org. Many times investigations of supposedly malicious hosts there showed that no malicious activity whatsoever had originated from them; their IP addresses had simply been used in spoofing attacks. Read more…

Which Web browser is the most secure? The answer to this question could easily trigger a “religious war,” something that I have no intention of doing. Yet because so many of today’s attacks target browsers, there is value in looking deeper into this issue, provided, of course, that facts, not presuppositions, are used to address this issue.

Because the most used products and tools generally tend to be the biggest targets of attacks, it is important to know how frequently each type of browsers is being used today. According to w3schools.com, in January 2009, IE7 had 25.7 percent, IE6 had 18.5 percent, and IE8 had 0.6 percent of the browser market. The total among all three versions of IE is 44.8 percent, nearly identical to Firefox’s 45.5 percent. Chrome was a distant third with 3.9 percent, and Safari had 3.0 percent. What is perhaps most striking about these data is that only a few years ago, IE was completely dominant in the Web browser arena with well of 80 percent of all browsers used at that time being IE. To say that the use of Firefox has grown substantially over the past few years is thus a gross understatement. But the bottom line is that based on usage statistics, IE and Firefox should be about equal in their attractiveness to would-be attackers, whereas Chrome and Safari should not be so attractive in this respect. Read more…

In my previous blog entry I raised the issue that intellectual property is the “bread and butter” of most businesses and that many information security practices have could add considerable value to the organizations they serve by stepping in to better identify and safeguard such information. Despite the importance of intellectual property to businesses, information security practices’ strategies, policies and standards too often omit any specific mention of intellectual property and the need to safeguard it. Don’t get me wrong—terminology such as “proprietary,” “sensitive, and “confidential” information runs rampant, but such terminology misses something that is very important, namely that some kind of information (intellectual property) is the company’s life blood. I thus highly recommend that information security practices initiate concerted efforts to locate such information, wherever it exists, and to initiate efforts to create and assign special levels of protection for it. Creating a special “intellectual property” classification for such information would serve as an excellent start. Read more…

Intellectual property in loose terms means the output of original thinking. Intellectual property thus (among many other things) includes inventions, engineering, industrial and other types of designs, research data, artistic and literary works, symbols, designs, images, and names that are used for business purposes, and patents, copyrights and trademarks. From a practical perspective, intellectual property is any type of information that may prove of benefit to a company, but that is also likely to attract the interest of and potentially prove of benefit to that company’s competitors. Read more…