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.

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.

Unless the IPsec protocol is used, tracing the source of any network transmission is usually difficult because the header data in a conventional IP packet (e.g., IPv4) can very easily be fabricated or altered. A few substantial advances in “source determination,” i.e., pinpointing the origin of network traffic, have surfaced at several research institutions. These advances are, however, still largely experimental in nature. All things considered, IPsec is thus still the best way to trace the origin of any packet sent from a source outside one’s internal network. Ironically, however, the fact that the IPsec protocol is so conducive to security has resulted in its being largely avoided by the black hat community. Tracing attacks thus remains a very difficult problem.

I have no particular gripe with dshield.org or any other site or organization that tries to do the Internet community a favor by providing information about potentially malicious IP addresses. My gripe is instead with amateur intrusion detection analysts who “blow the whistle” on IP addresses they believe to be malicious without investigating more thoroughly, people who take malicious IP address lists such as dshield.org’s at face value, and conference speakers who mislead audiences into believing the identifying malicious IP addresses is as simple as going to a site such as dshield.org.

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.

The next consideration is the number of vulnerabilities that surface in each type of browser. Because Chrome is so new, little data concerning vulnerabilities in this browser are currently available, and Safari is not used all that much. Let’s therefore just compare IE and Firefox. At first IE had far more vulnerabilities than did Firefox, and then this trend reversed itself for a while, but now the number of vulnerabilities that surface in each is approximately the same. The same is true for the potential seriousness of the vulnerabilities that have been identified.

Another important consideration concerns how secure each browser is right out of the box. The answer appears to be about the same, although obtaining data concerning this issue is complicated by the fact that vendor releases over the course of any year tend to tend to not be 100 percent identical. How about the potential for tightening security in these browsers? Among other things, both support encrypted sessions, warnings for suspicious sites, and the ability to clear sensitive and/or private data. All things considered, saying that one browser has better settings would thus be unfounded. A few things about IE make me nervous, however. One is its propensity to cache information; another is its ability to capture and save keystrokes. And although the ever dangerous ActiveX can be disabled in IE, the fact that so many IE-based Web transactions rely on ActiveX is not particularly comforting from a security perspective, either.

All things considered, therefore, I would give Firefox a slight edge over IE when it comes to security. But stopping here would be to miss the real point. Because so much of security in software depends on how the software is maintained and upgraded, no matter what browser you use, your diligence in maintaining and patching the browser will make far more difference in the browser’s security than your choice of browsers. Security is not something that you just set up once and leave alone, and browsers are no exception to this principle.

Additionally, the area of competitive business intelligence is a good example of a yet largely untapped opportunity for information security practices. Information that reveals critical aspects of virtually any company’s profit status as well as business direction is generally freely available on the Internet. This information unquestionably comprises intellectual property, but too often senior management is not aware not only of the nature of such information, let alone how easy it is for the public (competitors very much included) to access. Internet-accessible information about potential purchases of real estate can, for example, reveal intentions of a retail chain to expand its presence in certain geographical locations, something that can tip off competitors and allow them to adjust their business strategies accordingly. Similarly, a training organization’s announcements of training courses on the Web can reveal information such as course fees and the maximum enrollment allowed, thus enabling competitors to estimate the gross yearly income of that organization. The possibilities are almost endless.

Competitive intelligence is a game that has both an offensive and a defensive side. What I fail to understand is how little organizations understand concerning the kind of information freely available on the Internet that allows their competitors to gain a competitive advantage against them. Given that the goals of information security include the protection of the confidentiality of information, the fact that more information security practices are not involved in this side of competitive intelligence is simply amazing to me. Alignment with business drivers, something that should characterize every information security practice, is not always an easy task. Competitive business intelligence stands in stark contrast, however. Suppose that information security functions started to identify intellectual property related to their organization that is freely available on the Internet, communicate the findings to senior management, legal, and others, and offer recommendations for mitigating the business risk exposure that the intellectual property’s unrestricted availability poses. I predict that the results would be dramatic—information security managers who attempted to help the business in this regard would not have to struggle so hard to obtain the funding and high-level management support that they need to fulfill other mainstream information security-related functions.

I have just scratched the surface of issues related to intellectual property. Stay tuned—more will follow in the future.

Fortunately, organizations do not have to fight to preserve intellectual property alone. The World Intellectual Property Organization (WIPO), an international intergovernmental organization, was established to guard the rights of intellectual property owners. WIPO’s Trade Related aspects of Intellectual Property (TRIPs) provides minimum standards for intellectual property protection and enforcement. TRIPs requires that every nation provide a minimum level safeguarding of intellectual property based on standards that are for the most part aligned with current international agreements. Additionally, laws in various countries such as the Digital Millennium Copyright Act (DCMA) in the US provide certain protections to copyright holders. Unfortunately, WIPO, TRIPs, and national laws alone are not anywhere nearly sufficient to provide the level of legal protection that intellectual property owners generally require.

Please recall an earlier blog posting of mine in which I argued for the need for a broader view of information security, one that views information security transcending IT security. Information security must recognize and mitigate not only conventional IT security risk, but also risk related to an organization’s information, regardless of the particular form (electronic, printed, spoken, and so on) in which that information exists. As most organizations’ ability to create and suitably handle intellectual property goes, so goes the organization. Intellectual property needs to be recognized and protected, and no function within any organization is more suited to do both than is information security.

The bottom line is that recognition of and protection of intellectual property represents a great but, unfortunately, until now mostly unrecognized area of opportunity for information security. Senior management of organizations would very much value a systematic effort to identify and safeguard information that fuels the business. I suspect that the reason that most information security practices have not immersed themselves in this endeavor is the widespread perception both within and outside of the ranks of information security functions that information security deals only with passwords, firewalls, system audit output, and policy. Information security functions could not only break away from this stereotype, but also greatly endear themselves with senior management by squarely taking on the issue of intellectual property protection.