Network Security Consulting Blog » Dr. Eugene Schultz, PhD, CISM, CISSP

The Changing Nature of Incident Response: Part 3

Dr. Eugene Schultz, PhD, CISM, CISSP — Sun, 30 Oct 2011 20:30:24 +0000

The ultimate test of the value of an incident response team is how that team handles crises. Crises are generally not everyday occurrences. In fact, most issues with which an incident response team must deal are not of a bona fide emergency nature. That is why from the very onset of computer incident response teams I have objected to any incident response team name that includes “emergency” or “crisis” in it, because these terms represent little more than massive embellishment of the true nature of most of their activities.

At the same time, however, an incident response team must be prepared to deal with genuine emergencies. The first such emergency that the CIAC team that I then managed encountered was less than a year after the team’s having gone operational. The WANK (Worms against Nuclear Killers) worm infected one VMS host after another on what was at the time the DECnet. Given that the Department of Energy (DOE) and NASA computing communities depended heavily on VMS and the DECnet, the worm comprised a genuine crisis.

The CIAC team had some technical expertise in VMS, but not as much as was needed to deal with this nasty worm. Fortunately, several VMS experts, most notably Kevin Oberman of Lawrence Livermore National Laboratory and Ron Tencati of NASA’s NASCIRC team, did far more than their fair share of reverse engineering and making recommendations for containing infections. CIAC team members were constantly on the phone with Kevin, Ron and other people from DOE and other sites. At the same time, they valiantly struggled to write worm-related updates and bulletins that were quickly disseminated to the computer protection program managers (CPPMs) and other key personnel at these sites.

Murphy’s Law has stood the test of time better than virtually any other human-derived axiom, and once more the truth of Murphy’s Law became evident when a massive earthquake hit the San Francisco Bay Area right in the middle of the rapid spread of the WANK (later to become the WANK/OILZ) worm. Telephone communications in the Bay Area were out, severing the major link between CIAC and its constituency. Back in late 1989 when these events occurred, the Internet (which at that time was actually the ARPAnet) was comparatively small and insignificant compared to what it currently is. Many CPPMs and other significant security players within the DOE community did not use the ARPAnet. Consensus among them favored FAX-based communications, but because such communications depend on telephone lines, no FAXes could be sent. ARPAnet-based communications were also temporarily disrupted. Reaching CIAC’s constituency for a period of nearly 48 hours was thus impossible–a worst case scenario for an incident response team.

After three weeks, the WANK (and later the WANK/OIL) worm finally slowed to a crawl, giving CIAC and the rest of the incident response community time to catch their breaths. Firsthand accounts of disruption and stories related to this worm’s temporary “reign of terror” started coming in, the most amusing of which was from a Japanese researcher who expressed gratitude to the worm for being so kind as to honor his country with its “visit!”

Several extremely valuable “lessons learned” emerged from the events that transpired:

Cooperation is everything. No incident response team was or is an island, and the cooperation between the teams that did the most in dealing with the WANK – WANK/OILZ worms proved invaluable. At the same time, resources from outside of the response team community proved to be at least as if not more helpful, showing that no matter how technically proficient it is, the response team community needs to fall back on other resources and expertise sometimes.
Out-of-band communications needs must be anticipated, designed, implemented and extensively tested long before situations in which they will be needed occur.
Training for incident response team members must include how to deal with crisis situations as well as other situations. Emphasizing the need and how to escalate critical information during emergencies needs to be one of the most fundamental parts of such training.

Again, however, incident response today is different from how incident response used to be. The Internet community’s response to the various versions of the Conficker worm lacked the kind of extensive involvement by incident response teams that the response to the WANK – WANK/OILZ worms did. Technical staff from Microsoft, Symantec and other companies that had a vested interest in countering worm outbreaks as well as researchers from organizations such as SRI International instead led the way in responding to the Conficker worm. Today’s incident response teams are still important, but given the greater availability of knowledge and capabilities within the Internet community, each such team is more likely to serve a specific purpose or set of purposes for the specific organization for which it has been created

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

Dr. Eugene Schultz is the CTO at Emagined Security, an information security consulting practice based in San Carlos, California. He is the author/co-author of five books, and has also written over 120 published papers. Gene has been the editor-in-chief of two journals and is currently on the editorial board of three journals. He is also a SANS instructor, member of the SANS NewsBites editorial board, co-author of the 2005 and 2006 CISM preparation materials, and is on the technical advisory board of three companies. Gene has previously managed an information security practice as well as a national incident response team. He has also been professor of computer science at several universities and is retired from the University of California. He has received the NASA Technical Excellence Award, the Department of Energy Excellence Award, the ISACA John Kuyers Best Speaker/Best Conference Contributor Award, the Vanguard Conference Top Gun Award (for best presenter) twice, the Vanguard Chairman’s Award, and the National Information Systems Security Conference Best Paper Award. A Distinguished Fellow of the Information Systems Security Association (ISSA), Gene has also been named to the ISSA Hall of Fame and has received ISSA’s Professional Achievement and Honor Roll Awards. He is currently a member of the accreditation board of the Institute of Information Security Professionals (IISP). Dr. Schultz has provided expert testimony before committees within the U.S. Senate and House of Representatives on various security-related issues, and has served as an expert witness in legal cases.

The Changing Nature of Incident Response: Part 2

Dr. Eugene Schultz, PhD, CISM, CISSP — Wed, 26 Oct 2011 20:27:43 +0000

Perhaps the biggest single step in the life cycle of an incident response team is going operational. The major problem with getting the Department of Energy’s incident response team operational was that there was nothing–no policies, no standards, and virtually no procedures concerning incident response at that time. The CERT/CC team claimed that it was operational at that time, but if that were true, there would have been some kind of indication that operations were taking place, and there was no indication whatsoever. One of the best ways that my management ever helped at that time was to inform me of other emergency response teams and to try to get me in touch with people who managed such efforts. One such team was the Nuclear Energy Search Team (NEST) at Lawrence Livermore National Laboratory. Discussions with the manager and some of the more senior staff members of this team helped me better understand the kind of procedures that would have to be performed, the kinds of communication that would have to occur, and how action priorities would have to be determined. Still, the nuclear arena is not all that closely aligned with the information security arena, and after I was finished meeting with NEST members I developed a kind of sinking feeling that there was much more to do than I had ever imagined. And at the time the team I managed consisted only of myself.

I was allowed to do some hiring, and my first inclination was to turn to a friend, Unix guru and former grad student at UC Davis, Ana Maria de Alvare. Additionally, I turned to another friend, technical guru, and then current grad student at UC Davis, Tom Longstaff. With these two excellent people aboard the team, we were able to better define and prioritize team goals and to start thinking about what we would do once we had to go operational. Back in those days (in early 1989), there was no SecurityFocus or bugtraq–in fact, the Worldwide Web did not even exist then. So we decided that one of the best things we could do was to offer a vulnerability notification service to the DOE sites, all 78 of them at the time. We figured that if people at least patched their systems and applications, they would be far less likely to have incidents, and preventing incidents altogether seemed better than experiencing incidents and then having to devote time and effort in responding to them. So we did our best to learn about vulnerabilities and then distribute them to the security managers (called computer protection program managers or CPPMs) at the various DOE sites.

Our first few bulletins were pretty pathetic. We neglected to determine what the format and content of bulletins would be, and our having failed to do so showed in the quality of the bulletins. But after receiving some flak from disaffected recipients, we started to get the hang of it. CERT/CC has started to issue bulletins about the same time, and it did not take long to realize that the CERT/CC bulletins were not meeting the needs of system administrators in that they were too high level. So we decided to devote the first part of our bulletins to a kind of high-level summary of each vulnerability and then the rest to what often amounted to detailed procedures for installing patches and/or workarounds. The result was very gratifying–we started to win the hearts not only of CPPMs at DOE sites, but also of rank and file system and network administrators at these sites, as well as others to which our bulletins had been forwarded.

As our constituency warmed up to us, we found them increasingly willing to share vulnerabilities they had discovered with us, and we soon were in the position of having to play middleman between technical people in the field and vendors. This was an awkward position, as vendors in that day were with a few exceptions incredibly uninterested in hearing about, let alone fixing vulnerabilities in their products. The worst was Sun Microsystems, which eventually let us know that their people were committed to dealing only with CERT/CC. Apparently, some kind of exclusive relationship between the two had been set up. This was unfortunate given that it became very apparent very early in the life of the DOE CIAC team that in wanting to be the only power player in the response arena, CERT/CC was not cooperating much with other teams. In some cases, CERT/CC team members were even playing dirty tricks against other teams, CIAC very much included. But that is another story.

Back in the late 1980s DOE sites were under no coercion from DOE headquarters to install patches to fix vulnerabilities described in DOE bulletins. Years later, things changed, and sites were required to install patches. But then not long afterwards, individual department and agency teams started to be phased out. After producing almost nothing for well over a decade, CIAC was phased out a little over three years ago in favor of a Las Vegas-based team that cost far less and produced far more. NASCIRC, NASA’s incident response team, fell by the wayside in favor of the U.S. CERT. And CERT/CC no longer issues vulnerability bulletins, nor is it involved in incident response operations any more. Additionally, vendors are doing a much better job getting information about vulnerabilities in their products to their customers. Furthermore, powerful and efficient patch management tools are now widely available. With a few exceptions, incident response teams no longer spread the word about vulnerabilities. So we are in many ways much better off than we were in the late 1980s, even if many of us are not very diligent in patching vulnerabilities in our systems and applications. Meanwhile, incident response teams are now freer to engage in other tasks more centrally related to incident response support.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

The Changing Nature of Incident Response: Part 1

Dr. Eugene Schultz, PhD, CISM, CISSP — Sat, 22 Oct 2011 20:25:12 +0000

I’ve been affiliated with incident response in one way or another since 1988. I am not saying this boastfully, as I’ve made many mistakes both in responding to incidents technically and in managing incident response efforts. At the same time, however, when I first entered the incident response arena, there were no policies, standards, and procedures, and not really any requirements, either, to guide incident response efforts. Everyone who played in this arena originally had to use a combination of intuition and learning from mistakes just to get by.

Contrary to what the Software Engineering Institute’s (SEI’s) Computer Emergency Response Team Coordination Center (CERT/CC) says, the beginning of incident response as we know it today was at the University of California’s Berkeley Lab. Dr. Cliff Stoll, an astrophysicist who ran out of research funding took on system administration work there just to keep his time card filled. He noticed a slight discrepancy in computing time charges between a Unix host’s built-in accounting function and a home-grown accounting program that ran on that host. His scientific curiosity aroused, Cliff looked into the matter and found not only that someone had tampered with the host’s accounting function, but also that there were unexplained connections from unlikely places. You’ll have to read The Cuckoo’s Egg, Cliff’s best-selling book, to learn the whole story. Suffice it to say, the most significant impact of Cliff’s story from an incident response point of view is that the break-ins, which ostensibly were financed by the Soviet Union’s KGB, showed that some kind of organized and systematic response effort was needed to deal with what was then becoming an increasingly serious problem of remote intrusions into systems.

Because Berkeley Lab was and still is a Department of Energy (DOE) laboratory, officials within the DOE decided that this department needed a DOE-wide response team. Long before anyone even thought about starting CERT/CC, they solicited proposals from DOE labs; Los Alamos National Laboratory (LANL), Oak Ridge National Laboratory (ORNL) and Lawrence Livermore National Laboratory (LLNL) responded. LLNL’s proposal was accepted, and because I had written the final version of this proposal, somehow I became the project manager in an area about which I knew virtually nothing.

Meanwhile, an LLNL employee leaked the news that the DOE was forming an incident response team to a friend who worked at the SEI and suggested that an Internet-wide incident response team be established. Several SEI staff members acted on this suggestion and requested and obtained funding from the Defense Advanced Research Projects Agency (DARPA) before the LLNL incident response project received its funding from the DOE. What still amazes me is that CERT/CC claims that it was created in response to the Morris Worm of 1988, when in reality people who became members of this team had applied for funding and had defined their proposed team months before.

Anyway, when the Morris Worm made its debut on the evening of November 2, 1988, both CERT/CC and the precursor to the DOE’s incident response team had virtually no positive impact whatsoever. While members of both teams flailed, largely due to a lack of procedures, academics at the Massachusetts Institute of Technology (MIT) and Purdue University led the way in reverse engineering the worm code and providing help and advice to the then ARPAnet (shortly afterwards, the NSFnet, and then later the Internet) community. But in the long run, the Morris Worm was an extremely beneficial event for the development of incident response in that it showed the fledgling incident response community just how big the task at hand was. It also helped make government bureaucrats and others who had money and power aware that relying only on preventative and detective controls was grossly insufficient.

Oh by the way, I mentioned that when I first entered the incident response arena, I knew absolutely nothing about incident response. Just a few weeks after the DOE response team became operational, I was regularly contacted by writers for Government Computer News, the Federal Computer Week, and other media outlets. After writers had interviewed me, they would run stories with captions such as “Government security expert says that…” Funny–I knew a lot about MIL-STD 5200 then, but to call me an expert was really stretching it! It all goes to show that you cannot believe everything you read…

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

To Share or Not to Share, That Is the Question

Dr. Eugene Schultz, PhD, CISM, CISSP — Tue, 18 Oct 2011 20:21:38 +0000

The Obama Administration (and in particular the U.S. State Department) continues to take the heat for the massive leakage of U.S. government documents courtesy of WikiLeaks (and allegedly originally because of the actions of PFC Bradley Manning). The volume of vitriol directed at President Obama and Security of State Hillary Clinton is astounding; members of the information security community have contributed more than their fair share of it. How could the U.S. government, they say, have been so negligent regarding access control that even a lowly private in the U.S. Army could allegedly gain access to these documents?

Before I go any farther, let’s look at access control from an information security point of view. There are four major models of access control, discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and ruleset-based access control (RSBAC). In DAC, users can set whatever access control they want. In MAC, users cannot set access controls, nor can system administrators, for that matter. Access controls are instead under the purview of a security administrator. In RBAC, users are assigned job function-related roles that are then mapped to information access needs; entitlements to access any information depend on whether a role requires access to that information. In RSBAC access controls are set through rules such as ingress and egress traffic filtering logic in firewalls.

The massive document leakage was from the State Department’s Net-Centric Diplomacy system. This system was originally built exclusively (or nearly so) for access by State Department employees and contractors. An event that occurred on Christmas Day 2009 led to a change of decision regarding who is allowed to access this system, however. Umar Farouk Abdulmutallab, more frequently known by the unsavory nickname of the “underwear bomber,” allegedly attempted to blow up Northwest Airlines flight 253 from Amsterdam to Detroit, Michigan that day. Fortunately, this attempt was unsuccessful, but disturbing information concerning warnings about this person that had not gotten to organizations that could have stopped this person from being able to board the flight started to circulate. British intelligence had, for instance, informed the U.S. that a man named “Umar Farouk” had vowed to support jihad in a conversation he allegedly had with Anwar al-Awlaki, a Muslim extremist leader in Yemen. Abdulmutallab’s father in Nigeria had alerted the U.S. embassy there that his son may have been involved in Muslim extremist activities in Yemen, something that caused his son’s name to be added to the National Counterterrorism Center’s terrorist watch list. Somehow, however, the younger Abdulmutallab’s U.S. visa was never checked during the flight boarding process. Furthermore, his name was never added to the FBI’s Terrorist Screening Database. U.S. Immigration and Customs and the Transportation Security Administration had no clue that a potentially dangerous person was coming to the U.S. on Christmas Day 2009. The right hand had no idea what the left hand was doing, so to speak.

One of the “lessons learned” from this ugly set of events is that information about potential terrorists and other serious threats needs to circulate more freely with U.S. government circles. Consequently, access controls for the Net-Centric Diplomacy system as well as other U.S. agencies’ systems were relaxed to provide more widespread and easier access. Months later, the massive leakage of documents occurred, and the finger pointing intensified.

What really amazes me is how so many people do not understand the tradeoffs between access control and ease of access. Before sometime shortly after Christmas Day 2009, access to a vast array of U.S. government information was very limited, presumedly to individuals who were in a limited set of role classifications and security clearances. The information was more secure, but at the same time those who needed the information for endeavors such as identifying potential terrorists did not get it, as in the case of tracking (or the lack thereof) the alleged “underwear bomber.” Critics howled and complained. Afterwards the U.S. government opened up access. You might ask why the U.S. Army was granted access to the State Department system. The reason is that the Army is fighting terrorists in both Afghanistan and Iraq, and intelligence concerning the activity and plans of terrorist groups can easily make the difference between victory and defeat. But then when so much information was leaked, critics howled and complained.

My message should by now be clear. When it comes to information sharing, you really can never clearly win. Restricted sharing results in a lower number of unauthorized data leaks, yet it also raises the likelihood that those who have a bona fide need for the information will not be able to access it. Allowing greater access to information increases the probability that those with a genuine need for it will be able to access it, but also increases the risk that the information will be accessed by unauthorized persons. Which of these alternatives is more favorable depends on an organization’s mission and its business and/or operational objectives.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

A DLP Success Story

Dr. Eugene Schultz, PhD, CISM, CISSP — Fri, 14 Oct 2011 20:15:45 +0000

Those of us who are information security professionals know all too well that success stories in our arena are too few and far between. When we hear of one, we thus need to savor the moment. This kind of moment recently occurred within Nationwide Insurance, which not too long ago had implemented a data loss prevention (DLP) tool enterprise-wide. The DLP tool issued an alert that a Nationwide employee had sent a spreadsheet from his personal email account to his Nationwide email account. A follow-up investigation revealed that the spreadsheet contained information such as credit card numbers, Pay Pal and eBay account names, and bogus identity information, prompting an investigation by Nationwide officials who contacted law enforcement soon afterwards. The FBI Cybercrime Task Force and the U.S. Postal Inspection Service launched an investigation and ultimately determined that Bi was copying computer games to CDs and then selling the CDs for a greatly reduced price. Between 2005 and late 2009, Bi sold more than 35,000 copies valued at $700,000 on eBay and using the eBay and Pay Pal account names he had stolen as well as his own account.

Last July Bi pleaded guilty to one count each of copyright violation, mail fraud, and aggravated identity theft. He could have received a sentence of as much of 20 years in prison, but because he pleaded guilty, his sentence was for only two and a half years of imprisonment and two years of probation, one of which will be home confinement. He also must pay a yet unspecified amount of restitution and must give up what he gained from his crimes ($367,669), a Lexus SUV, his house, and his computing and electronic equipment.

Nationwide was both smart and fortunate. This company was smart in that powers-that-be within approved the purchase and installation of a DLP tool. DLP technology is by no means any kind of panacea, but it can and does identify anomalous user actions related to copying and sending sensitive and valuable information. DLP, not intrusion detection, was the correct choice. Whether or not we realize it, intrusion detection technology as we currently know it is dying a slow but sure death.* The gap between the state-of-the art within the black hat community and the state-of-the-art for intrusion detection technology has already grown out of control. But more importantly, intrusion detection, even if it were more proficient in detecting incidents than it currently is, does not really deliver the results that we need most. An intrusion detection system may inform us that someone has broken into a system. There is some value in knowing this–based on this information, we can send technical staff to clean and restore the compromised host and also to determine whether the compromised host has been used to attack other systems. But today the bottom line for organizations is intellectual property (IP) or its equivalent and our ability to protect it. The value of organizations is increasingly being linked to the value of the intellectual property they possess and their ability to create it. So if a perpetrator breaks into a host, but no IP is stored on it, the break-in has far less negative impact than if a naïve company employee sends a critical business document to someone who works for a competitor. And that is exactly where DLP technology comes in. Sooner or later, someone who attempts to engage in unauthorized activity involving sensitive and/or proprietary information will not only trigger a DLP alert, but (provided the DLP tool is sufficiently proficient) will be unable to carry out the intended copying or transfer of files. And stopping deliberate perpetrators as well as naïve users from engaging in actions that can result in IP being compromised is likely to make an enormous difference in an organization’s bottom line.

Nationwide was fortunate in that its own proprietary and other personally identifiable information that it stored and used was not involved in the incident being discussed here. At the same time, however, Bi’s moving such information to Nationwide machines could potentially have opened up this company to numerous lawsuits based on downstream liability. In a nutshell, you need to not just worry about your own information on your own hosts, but you must also worry about other information that is not intended to be stored and processed on your own hosts.

And, oh by the way, think of all the trouble that could have been prevented or at least stopped shortly after it started if the U.S. State Department had deployed DLP technology on its Net-Centric Diplomacy system from which so many sensitive documents were leaked to WikiLeaks.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

* – I still nevertheless recommend using intrusion detection systems as part of a defense-in-depth scheme–they may be able to identify incidents and anomalies that might otherwise be missed.

- – - – - – - – - – - – - – - – -

2011: A Better Year for Information Security?

Dr. Eugene Schultz, PhD, CISM, CISSP — Mon, 10 Oct 2011 20:12:13 +0000

The year 2010 is behind us; a new year is beginning. Last year will not go down in history as a particularly good year from an information security perspective. Attacks funded and initiated by countries (particularly the Peoples Republic of China) continued to occur frequently. So many denial of service (DoS) attacks came from China that domain name registrars began to distance themselves from entities in this country. The Stuxnet worm, which surfaced last year, proved for the first time that a virus or worm could actually cause physical damage to SCADA systems and, unfortunately, was almost certainly only the harbinger of a new, more formidable generation of malware. Data security breaches continued to occur at an astounding rate, as exemplified by recent statistics from the Privacy Rights Clearinghouse–nearly 600,000,000 pieces of personally identifiable information have fallen into unauthorized hands since this organization began counting in 2005. No one could have guessed the amount of information leaked to the wikileaks.org Web site, allegedly because of the actions of Private Bradley Manning of the US Army. And nobody would have imagined the ferocity of the DoS attacks that wikileaks supporters launched against Visa, MasterCard, and other credit card companies after these companies quit allowing their credit cards to be used for contributions to wikileaks. U.S. Government security efforts continued to flounder haplessly, and no major federal cybersecurity-related legislation was passed in the U.S. last year. Efforts to get a global treaty on cybercrime in place failed. Crime rings operating in Eastern Europe, Brazil, and elsewhere continued to rake in large amounts of money through a plethora of computer crime methods.

Will 2011 be a better year for information security? I do not think so. Why? Information security is for the most part still not a board room issue, so to speak. The economic downturn over the last two years or so is a major reason. Companies that are fighting for survival are not likely to increase information security budgets. Government agencies have often faced the same types of issues, and, oddly, despite having initially expressed strong support for improving cybersecurity in the U.S. government, President Obama has largely focused his attention on other issues. Despite laudable efforts to fight cybercrime by law enforcement and investigatory agencies around the world, the global nature of computer crime continues to create significant barriers against bringing computer criminals to justice. Software vendors continue to produce bug-riddled products, and systems and applications continue to have many unpatched vulnerabilities. Even if organizations and individuals are conscientious with respect to installing patches, zero-day vulnerabilities continue to surface, resulting in outbreaks of new, previously unforeseen and successful attacks. An increasing proportion of malware writers are working co-operatively with others and are well-financed by nation states bent on achieving world dominance and crime rings motivated by financial reasons.

What can change things for the better? As I have said before, it is difficult to appreciate how serious a threat fire is until one gets burned. The same applies to information security. Just look at what having experienced such a massive data security breach did for Heartland Payment Systems security. Heartland is now a poster child for information security. Many of the organizations that were victimized by the Aurora attacks less than two years ago have also improved their security posture considerably, albeit still not adequately. Ultimately, major information security-related incidents serve as the best wake-up call for information security. So if 2011 becomes a better year for information security, it will be due more to organizations that have been burned getting more serious about information security and implementing security measures that are appropriate to the risks they face.

I also think that if improvements in the state of information security occur this year, they will in part be due to compliance-related pressures. As imperfect as it is, the PCI-DSS standard has resulted in improved security in many organizations that are subject to this standard. And although FISMA has not really improved security in U.S. government circles, FISMA 2 promises to have a more positive influence.

Let’s hope that I am wrong and that 2011 is a banner year in the practice of information security.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

In Memory of Justin Peltier and Fred Villella

Dr. Eugene Schultz, PhD, CISM, CISSP — Fri, 07 Oct 2011 00:43:11 +0000

In many ways 2010 was a good year, yet in many ways it was a bad one. Part of the bad side was the loss of two standouts in the information security arena, Justin Peltier and Fred Villella.

Justin was one of the brightest and most energetic information security professionals I have ever known. He had an enormous aptitude for the technical side of information security, and not long after his entrance into information security, he started sharing his aptitude, talents, knowledge and skills with others through all the teaching, lecturing and writing that he did. Although young, he soon became a standout, and the name Justin Peltier drew crowds at classes, conferences and other professional events. All the while, he did not let his success get to his head, but instead conducted himself as if he did not think he was anything special. I also admired the way Justin and his father, Tom Peltier, and he were able to work together so effectively in activities such as teaching courses and presenting Webcasts. Justin would cover technology-related issues, and Tom would cover the administrative/management issues–one of the most effective “tag teams” I have ever seen.

Justin’s dream was to become an FBI agent; I remember one conversation with him in which he described his plan to become get hired by the FBI and what he would do once he started with this agency. Then MS struck him, making him increasingly weaker. He was the editor of the Year in Review series in information security, and after I wrote a chapter for the 2008 edition, I didn’t hear anything more from him. A bit later Tom told me that Justin was losing strength, making him unable to finish the task of editing that edition. At that point I knew that something was really wrong, and when mutual friend Brad Smith told me last October that Justin had departed from us, in a way I was shocked, but in a way I was not. All that I can say is that all that all that Justin accomplished during his rather brief stay on this earth is truly amazing, and he is sorely missed.

Fred Villella was also an amazing person. The first part of his career he was an officer in the Army, and apparently a very good one, as he received promotion-after-promotion until he retired as a Lieutenant Colonel. His military career is probably best remembered for his leadership of Army troops in Oxford, Mississippi shortly after a federal judge had ruled that the university there had to be desegregated in 1962. Angry students and White supremacists started a riot during the middle of one night. Captain Fred Villella’s Army unit, Company A of the 503rd Military Police Battalion, was one of the first to arrive at the scene to keep order. Although pelted with everything from rocks to cherry bombs, somehow Fred was able to keep his troops from causing trouble to escalate–they did not fire a shot, even though at some points their lives were ostensibly threatened. More than one book about this riot has commended Fred for keeping cool, thereby greatly lowering the potential for escalating violence. After retiring from the military, he worked for the U.S. Government, rising to deputy assistant head of FEMA (Federal Emergency Management Agency) in the Reagan Administration. Afterwards, he started providing training for NASA and other government agencies, and that is how I met him.

Fred was a visionary with a strong proactive focus when it came to security awareness, education and training. He was one of the first to ever use the now well-accepted method of “attack-counterattack” in the courses that he developed and put on for government agencies and others. He felt that without hands-on experience, course attendees would not develop a very deep understanding of the issues and knowledge at hand. He also believed that the content of security awareness, education and training needed to be carefully structured pedagogically, and he incorporated this belief into all the courses that he developed and taught. He also plunged into the security software arena, and was the CEO of several software companies that developed highly useful software such as HIPAA compliance software. Above all else, however, Fred was a man of honesty and integrity. I am confident that for every dollar of government and other money that he took in, he delivered one dollar of value. And he always seemed to be interested in others and their welfare. He, too, is solely missed.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

Agile Security

Dr. Eugene Schultz, PhD, CISM, CISSP — Mon, 03 Oct 2011 00:40:08 +0000

How should we practice information security risk management? Numerous methods, models and approaches abound, one of the foremost of which is the information security governance approach. This approach in essence says that to have a successful information security risk management effort, an information security manager must plan, strategize, organize, and establish and maintain relationships not only with executive-level management, but also with other closely-related functions such as audit and physical security as well as with key stakeholders.

One of the aspects about the information security governance approach that impresses me most is that it is so systematic. If an information security governance effort is planned and implemented correctly, there is a high likelihood that many details that might otherwise “fall through the cracks” will be covered. Most importantly, however, information security will be aligned with business and operational drivers.

As appealing as it is, the information security governance approach has its fair share of critics. Some claim that although this approach will produce some benefits, trying to implement information security governance in an organization that lacks enterprise governance is futile. Others point out that engaging in all the activities involved in designing and implementing information security governance is excessively costly and time-consuming. Some question the value of a top-down approach. One of the primary slogans of those who advocate a top-down approach is “tone at the top.” Accordingly, information security governance efforts are likely to be only as successful as the level of support from executive-level management, which is typically not pre-inclined to support information security governance efforts. Furthermore, critics point out that information security practices that are based on the information security governance approach move forward slowly–too slowly for today’s danger-filled world.

The last criticism of the information security governance approach is particularly salient when currently massive security breaches occur so quickly and regularly. Critics are quick to point out that adversaries are very quick and adept in designing new attacks and then carrying them out in a manner that altogether escapes the attention of or at best surprises the information security community. According to this line of reasoning, the information security governance approach is too top-heavy and too slow to allow practitioners to keep up with the fast and furious rate of change in an arena characterized by constantly emerging threats, vulnerabilities and risks.

I would not like to be on record as siding with the critics of the information security governance approach, yet at the same time I feel that they are making a very valid point. Agility and resilience are terms that are missing from the information security governance approach. This approach advocates starting with an information security strategy, then developing one or more action plan(s), then creating an information security policy and standards. A risk analysis based on asset valuation, vulnerability analysis, and threat analysis must be performed, followed by controls evaluation, selection, implementation and testing. This is all fine and dandy, but performing all these activities that are part of this approach requires a cyclic approach, and the length of cycles we are talking about here are not short. For example, most organizations do not perform a risk analysis more often than once a year. Yet threats, vulnerabilities and risks keep changing. So what we need is more agility. We need to adopt a strategic approach such as the information security governance approach, yet allow for frequent “interrupts” that temporarily take the “big wheel in motion” offline to address suddenly emerging threats, vulnerabilities and risk. In effect, information security practices need to more closely emulate incident response efforts that can quickly and efficiently detect, provide triage and mitigate incident security breaches. Being systematic must not squelch agility.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

Smart Objects: The Next Pandora’s Box?

Dr. Eugene Schultz, PhD, CISM, CISSP — Thu, 29 Sep 2011 00:37:15 +0000

The world of technology is changing so fast that keeping up with it is a nearly impossible task. The same applies to the information security arena, where new technology and new ways to attack technology are being developed at an astounding rate. It is easy to overlook emerging technology developments, many of which promise to introduce numerous new vulnerabilities that ultimately lead to new risks. One such development is smart object technology.

Smart objects are tiny objects that have a sensor or actuator as well as a communications device. Most often implemented as minute RFID chips, anything with a power source is a candidate for smart object technology. These objects can be placed within frequently used devices such as light switches, refrigerators, thermometers, garage door openers, automobile engines, light switches, and temperature control systems. So, for example, people can use smart objects to turn on heating or cooling in their homes from far away or to make their electric garage door openers unopenable while they are away from home.

Smart objects are also already being used in industrial settings more often than you might imagine. For example, smart objects are now being embedded in assembly line components. Smart objects are also used in power grids to balance power between plants and substations, substations and lines, lines and transformers, and transformers to home electrical systems.

We all know that IPv4 addressing is dead. People currently often say we are running out of IPv4 address space, but they are wrong–we ran out of IPv4 address space years ago. IPv4 addressing provides only 2 to the 32nd power total addresses. Right now we are virtually “limping by” through the use of RFC 1918 addresses and Network Address Translation (NAT) in our internal networks. The limited amount of address space that IPv4 provides has also been a hindrance to the growth of smart object technology. The world will soon turn to IPv6, however, and when it does, there will be so many addresses (2 to the 128th power) that every human being on the planet will be able to have 100,000s of addresses if desired. When IPv6 comes into its own, assigning addresses to a myriad of smart objects will become trivial. Home owners will have networks of smart objects, and smart objects will become as common a part of everyday life as smartphones currently are.

But as previously mentioned, new technology breeds new security problems, and smart objects are no exception. The amount of processing power in a single smart object is impressive, but numerous significant limitations that very negatively affect security come with the miniscule size of the chips used to implement this technology. Smart objects can be dedicated to encryption-related tasks, but building in encryption into smart objects designed for other purposes is not always practical from a chip manufacturing standpoint. IPv6 has an impressive variety of security mechanisms that can be implemented, but the current generation of smart objects is not capable of utilizing many of them if these objects are designed for non-security related functions.

Additionally, the inevitable proliferation of smart objects will also provide a very target-rich environment for attackers. Home users typically cannot secure their own computers, so how likely are they to secure their home smart object networks? Imagine a scenario in which a jilted lover breaks into the smart object network of the “jilter” and turns off heat in the dead of winter or makes the garbage disposal run continuously. Similarly, a denial of service (DoS) attack in a smart object-dependent home could cause havoc. And now also imagine a nation state-initiated massive DoS attack on the increasingly smart object-dependent electrical power grid.

Smart technology will be dominant in only a few years from now. Information security professionals need to quickly come up to speed regarding this technology and then start thinking how security policies, standards and procedures must be changed to mitigate the risk that this technology introduces. Being proactive is everything, and “he who hesitates is lost,” as the saying goes.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

The 2011 National Defense Authorization Act: Another Setback for Cybersecurity

Dr. Eugene Schultz, PhD, CISM, CISSP — Sun, 25 Sep 2011 00:34:59 +0000

The U.S. House of Representatives recently passed H.R. 6523, the latest version of the 2011 National Defense Authorization Act, which will next go to the Senate. This act, which is passed every fiscal year, defines the Department of Defense’s budget and spending level. The previous version of this bill contained several cybersecurity-related provisions such as establishing a White House Office of Cyberspace with a cyberspace director who would require Senate confirmation, requiring government agencies to perform continuous monitoring within their IT environments, and requiring software acquisition processes that would help assure that purchased software is secure. These provisions (as well as one that would remove the “no ask, no tell” policy concerning gays in the military) were deleted from the final version of the bill that the House passed because opponents of the bill argued that these riders were irrelevant to the national defense.

Would an Office of Cyberspace and a director confirmed by the Senate make a difference for the military? I honestly doubt it. Top-level military brass appear to make decisions based on their military experience and instincts more than on “voices in the wilderness” (such as some new cyberspace security director) telling them what they should do. The generals and admirals who call the shots in the military have my utmost respect, but they appear to have fallen prey to the same misconception that top-level management in the civilian world has, namely that information security is some kind of abstract entity, and that security-related incidents are neither really all that tangible and costly. Besides, they say, “some really bad cybersecurity incident could never happen to me.” (Perhaps the ugly Wikileaks fiasco is forcing some of the top-brass to re-think their viewpoints.) But I am also confident that having any person within the government with a title that includes any word such as “cybersecurity” spells doom for that person. Face it, of all the individuals who took on the role of national security czar over the years, Richard Clarke has made the biggest positive impact. His title was “National Security Advisor,” not “National Cybersecurity Advisor” or something similar. The former title provides much more leverage–national security is something in which almost everyone is seriously concerned. The same cannot be said for cybersecurity, at least currently.

Another provision, the requirement to continuously monitor the IT arena, would have had a huge positive impact upon cybersecurity in government circles, including the defense arena. The myriad of cybersecurity threats that seem to constantly surface in the government and defense arena dictate a much stronger operational security effort than is currently occurring. And, contrary to what the opponents of this provision had said, if government agencies and departments would boost their level of security, there would be fewer incidents that would start in these agencies and departments’ networks and then spread to military networks.

Would requiring processes designed to assure that security software is purchased within government circles have helped cybersecurity within the government? The answer is “of course,” but there is a catch. The Klinger-Cohen Act was passed for the same basic reason. Honestly, has Klinger-Cohen significantly improved the security of software that the government buys? A few individuals might think so, but I suspect that the majority would be skeptical. Little truly secure software is available for purchase. If it is difficult to find secure software, statutes designed to force agencies and departments to purchase this kind of software will have little impact.

So once again, despite the fact that every day enemies of the US find ways to steal critical information from U.S. government and military computing systems, a setback for cybersecurity has occurred. And it is noteworthy that Congress has not passed any significant cybersecurity legislation in the last two years. The proverbial patient is bleeding badly while the doctors are standing around and focusing their attention elsewhere.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

The Wikileaks Fiasco

Dr. Eugene Schultz, PhD, CISM, CISSP — Wed, 21 Sep 2011 00:31:19 +0000

To be completely candid, I have been frustrated concerning my inability to write about the Wikileaks drama until now. I felt very strongly that once I had started the series on Bluetooth security, I should finish it before moving on to something else. Besides, Bluetooth security issues are really quite interesting. At the same time, however, there is a conflagration that is still burning, and this conflagration centers around Julian Assange and Wikileaks.

To put it bluntly, both Assange and Wikileaks are in a world of trouble–but for different reasons. Assange, the head of Wikileaks, elected to post volumes of U.S. government classified documents provided to him by a lowly U.S. Army private in Afghanistan. Assange’s directing that these documents be posted is one thing, but seeing him engage in behavior that can be described as little more than outright grandstanding is downright disgusting. True–Wikileaks posted classified documents, helping Wikileaks achieve one of its goals of exposing deceit and treachery on the part of governments. But much to Assange’s discredit, the documents appear to be neither all that valuable nor damaging to the U.S. government. Come on–should we really care that the Desperate Housewives television show creates a positive image for the U.S. in the Middle East? People who sense that they have power often become fiends, and Assange has increasingly acted accordingly.

I first virtually met Assange when I headed the U.S. Department of Energy’s incident response team. His site, suburbia.lacc.net, was then the foremost site dealing with cybersecurity-related legal issues. He did an excellent job in making information about computer-related laws and rules available to the then cybersecurity legal naive masses. I also appreciated his willingness to reply to my questions very courteously and also with extremely useful information. So until recently, my opinion of him was very positive.

What is truly frightening about the ongoing Wikileaks is that U.S. government officials and media staff are claiming that the Wilileaks disclosures border on Armageddon itself. How inane can they be? The Chinese have repeatedly rifled their way in and out of U.S. government and commercial systems, stealing vast amounts of highly classified and commercially proprietary data. I am quite sure that Chinese officials just laugh at the hysteria surrounding the exposure of information posted on Wikileaks. The Chinese, not Wikipedia, own the real goods…

Then several credit card and payment companies quit accepting donations to Wikileaks. Wikileaks supporters retaliated by flooding the Web sites of these companies for a few hours. Because denial of service attacks are usually so “sloppy,” I suspect that a number of the attackers will be identified and brought to justice–just like the head of Wikileaks appears to also be.

Then acrimony within Wikileaks started to skyrocket. This kind of thing invariably happens when top-level leadership of an organization becomes a demagogue. One of Assange’s right-hand men quit when Assange pressed him too hard concerning leaks of information related to Assange himself. Hmmm, Does Assange really think that it is o.k. to leak information about anyone but himself? Then others within Wikileaks have started to defect, going to the less renowned openleaks.com. In short, an organization built on sand will not endure, and if I were a betting person, I would not bet on Wikileaks surviving all that much longer.

Assange is likely to get prison time somewhere for changes completely unrelated to posting classified information, and so be it. But what really troubles me is how Wikileaks has sold out the private who furnished so much information to this organization. The Wikileaks top brass has showed almost total indifference to this person’s plight (especially in comparison to how they have almost canonized Assange), and please do not think that I am in any way saying that Manning was an innocent bystander. I seriously doubt if anyone within Wikileaks advised this private of the risks of providing the kind of information that he gave. My prediction is that PFC Manning will be tried on the grounds of treason, and he may possibly face execution if he is found guilty. Will Assange care? Will the top brass within Wikileaks care? I completely doubt it. And regarding the alleged $50K that Wikileaks raised for Manning’s defense, it suddenly disappeared. There is something very wrong here, and Wikileaks and Assange are at the center of it.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -

Bluetooth Security: Part 4

Dr. Eugene Schultz, PhD, CISM, CISSP — Sat, 17 Sep 2011 00:26:24 +0000

In my last blog entry I started to cover the kinds of tools that are available in attacking Bluetooth devices. I discussed Bluescanner and Bluesnarf and said that these are only two of the surprising large number of such tools. Now I’ll cover the remaining Bluetooth attack tools of which I am aware:

A.I.O. Bluetooth Hacking Tools. These tools are downright scary. They allow someone to read Bluetooth messages and contacts on another phone, change another phone’s profile and/or ring volume, make someone’s phone restart, switch off or ring (even if the phone is in silent mode), play songs on another phone (imagine the shock value of this!), and more.
Btcrack. Btcrack allows an attacker to make phone calls on another phone with any charges billed to the owner of the other phone. This tool also cracks Bluetooth PINs and attempts to reconstruct the pass key and the link key, both of which are captured during the pairing process that was discussed in part one of this series.
BlueSniff. This one finds discoverable and hidden Bluetooth devices. One of the major advantages of this tool is that it has a very intuitive graphical user interface (GUI).
Btcrack. As its name implies, Btcrack cracks Bluetooth PINs. It also tries to reconstruct the pass and the link keys during the pairing process.
BlueSniff. Blue Sniff, like other, similar tools finds discoverable and hidden Bluetooth-enabled devices. It also features a very easy-to-use GUI.
BlueBug. This tool tries to gain unauthorized access to phone-books, call lists and other private information in remote Bluetooth devices within the discovery zone.
Bluediving. This one is highly useful because it consists of a Bluetooth penetration testing suite, thus making obtaining and running each tool contained within unnecessary. Instead, it provides a menu that allows users to run each tool and function whenever they want. It contains Bluebug, BlueSnarf, BlueSnarf++, and BlueSmack. It also provides additional functions such as address spoofing, packet forging, connection resetting, and many others. If I were allowed to have only one Bluetooth attack tool, there is no doubt in my mind that I would choose this one.

In short, attacking Bluetooth devices has become rather easy because of a variety of tools designed specifically for this purpose. The widespread availability of these tools and the fact that most of them are free raises the risk level in Bluetooth environments considerably. Information security professionals need not only to know how these tools work, but they also need to use them in their vulnerability assessment programs. Auditors also need to learn about these tools, which can also be very useful when audits are being conducted.

–Gene Schultz, Ph.D., CISSP, CISM, GSLC

- – - – - – - – - – - – - – - – -