Monday, May 31, 2010

National Security Strategy is Empty on "Cyberspace"

The new National Security Strategy (.pdf) says the following about "cyberspace":

Secure Cyberspace

Cybersecurity threats represent one of the most serious national security, public safety, and economic challenges we face as a nation. The very technologies that empower us to lead and create also empower those who would disrupt and destroy. They enable our military superiority, but our unclassified government networks are constantly probed by intruders. Our daily lives and public safety depend on power and electric grids, but potential adversaries could use cyber vulnerabilities to disrupt them on a massive scale. The Internet and e-commerce are keys to our economic competitiveness, but cyber criminals have cost companies and consumers hundreds of millions of dollars and valuable intellectual property.

The threats we face range from individual criminal hackers to organized criminal groups, from terrorist networks to advanced nation states. Defending against these threats to our security, prosperity, and personal privacy requires networks that are secure, trustworthy, and resilient. Our digital infrastructure, therefore, is a strategic national asset, and protecting it — while safeguarding privacy and civil liberties—is a national security priority.

We will deter, prevent, detect, defend against, and quickly recover from cyber intrusions and attacks by:

Investing in People and Technology: To advance that goal, we are working across the government and with the private sector to design more secure technology that gives us the ability to better protect and to improve the resilience of critical government and industry systems and networks. We will continue to invest in the cutting-edge research and development necessary for the innovation and discovery we need to meet these challenges. We have begun a comprehensive national campaign to promote cybersecurity awareness and digital literacy from our boardrooms to our classrooms and to build a digital workforce for the 21st century.

Strengthening Partnerships: Neither government nor the private sector nor individual citizens can meet this challenge alone — we will expand the ways we work together. We will also strengthen our international partnerships on a range of issues, including the development of norms for acceptable conduct in cyberspace; laws concerning cybercrime; data preservation, protection, and privacy; and approaches for network defense and response to cyber attacks. We will work with all the key players — including all levels of government and the private sector, nationally and internationally — to investigate cyber intrusion and to ensure an organized and unified response to future cyber incidents. Just as we do for natural disasters, we have to have plans and resources in place beforehand.
(emphasis added)

*Yawn*. What a disappointment. So, we're going to "secure cyberspace" through "investing in people and technology" and "strengthening partnerships." Lame. Weak. I'd go so far to say irresponsible. It's clear that the national digital security policy situation has degraded since the President's speech on cyber security last May. That's right, it's been one year and all the President has to show on this is... Howard Schmidt, who is mostly famous for saying "There is no cyberwar" because "There are no winners in that environment." He also said:

"A cyberwar is just something that we can't define," he said. "I don't even know (how a) cyberwar would benefit anybody. Everybody would lose. There's no win-lose in the cyber realm today. It affects everybody; it affects businesses, it affects government, so number one, there's no value in having one."

What a disappointment.

Sunday, May 30, 2010

Digital Security Is Not Just an Engineering Problem

Recently I participated in a small meeting involving a cross-section of people interested in digital security and public policy. During the meeting one of the participants voiced the often-repeated but, in my opinion, misguided notion that the primary problem with digital security is "design." In other words, "the Internet was not designed to be secure." If the Internet was not designed to be secure, all applications are "built on a foundation of sand" and therefore can never be "secure."

This is a typical "engineering" mentality applied to digital security. I do not agree with it. You might think it's because I'm not a "professional engineer." Strangely enough, at USAFA I took classes in chemistry, physics (two courses), math (calc III and diff eq), thermodynamics, and five pure engineering courses (electrical, mechanical, civil, aeronautical, astronautical) plus the dreaded Academy "capstone" course -- all of which would qualify me for a minor in engineering at a "normal" college. Still, I do not think digital security is an engineering problem.

My opinion does not mean that engineering has no role. On the contrary, good engineering helps reduce vulnerabilities and exposures. Unfortunately, that focus only affects part of the risk equation. Focusing only on engineering completely ignores the threat, which in my judgement is the biggest problem with digital security today.

You know what prompted me to write this post? It was Security Engineering Is Not The Solution to Targeted Attacks by Charles Smutz, a professional software developer who creates custom security tools for a large defense contractor. Charles wrote:

[B]laming security engineering for the impact of targeted attacks is [a] herring as red as they come. A world where security engineering actually tried to solve highly targeted and determined attackers would not be a fun place in which to live. In absence of other solutions, an intelligence driven incident response model is your best bet.

You know I agree with that.

Charles wrote his post to refute Security engineering: broken promises by Michal Zalewski. Michal is a really smart security researcher but I agree with Charles that Michal has also fallen for the "security as design problem" mentality.

If you want to know what I think works, please consult my 2007 post Threat Deterrence, Mitigation, and Elimination.

Saturday, May 29, 2010

"Privacy" vs "Security" or Privacy AND Security

Perhaps I'm alone on this, but I may not think of "privacy" and "security" the same way as some readers of this blog. It's common to hear that there is a tension between these two ideas, but I consider them to be very different, at least at the enterprise level.

Privacy is primarily concerned with protecting customer data, often called Personally Identifiable Information (PII). Lawyers are typically the dominant players. This field is heavily regulated, with laws requiring disclosure when "records" are lost. The costs of an incident are borne primarily by the individuals whose PII was stolen.

Security is primarily concerned with protecting intellectual property, often including trade secrets. Security professionals are typically dominant players. The field is less regulated, since a company loses its own IP. The costs of an incident are borne primarily by the enterprise because they become less competitive.

In this sense, an enterprise seeks to preserve both privacy and security: protect customer data and company data.

Of course, there are plenty of "privacy advocates" who concentrate on "protecting" the activities of anyone who interacts with an enterprise, whether customers or employees. My problem with these sorts of privacy advocates is that their laws, tactics, and worldview are often detrimental to the privacy and security I defined earlier.

For example, intruders know that it can be difficult to instrument and monitor activity in countries with "strict privacy laws" (hello .eu). As a result, intruders prey on organizations operating in those countries, knowing that it is rough for CIRTs to detect and respond to intruders. The result is that customer and enterprise data is at greater risk thanks to "privacy laws."

In terms of my last post, More Evidence Military Will Eventually Defend Civilian Networks, the focus is clearly on security as defined in this post. I could see Cyber Command helping American companies protect intellectual property. Secretary Lynn clearly said he is not trying to aid consumers losing their credit cards to online thieves.

More Evidence Military Will Eventually Defend Civilian Networks

In my Predictions for 2008 I wrote Expect greater military involvement in defending private sector networks. About one year ago I wrote NSA to "Screen" .gov Now, I Predict .com Later. Now thanks to a new article by Noah Shachtman titled Cyber Command: We Don’t Wanna Defend the Internet (We Just Might Have To) we read the following:

At a gathering this week of top cybersecurity officials and defense contractors, the Pentagon’s number two floated the idea that the Defense Department might start a protective program for civilian networks...

“I think it’s gonna have to be voluntary,” he added. “People could opt into protection – or choose to stay out. Individual users may well choose to stay out. But in terms of protecting the nation’s security, it’s not the individual users [that matter most]. I mean, they have to worry about their individual [data], their credit rating, and all that. But it’s the vulnerability of certain critical infrastructure – power, transportation, finance. This starts to give you an angle at doing that.”


How? Kim Zetter's article Pentagon: Let Us Secure Your Network or Face the ‘Wild Wild West’ Internet Alone explains:

Defense Deputy Secretary William Lynn III, speaking at the Strategic Command Cyber Symposium in Nebraska, said we need to think imaginatively about how to use the National Security Agency’s Einstein monitoring systems on critical private-sector networks — such as those in the financial, utility and communication industries — in order to protect us.

“Operators of critical infrastructure could opt in to a government-sponsored security regime,” Lynn said. Otherwise, “individual users who do not want to enroll could stay in the wild wild west of the unprotected internet.”


I've written about Einstein before. However, I am dismayed to continue reading commentary like the following by Secretary Lynn:

“You’re starting to anticipate intrusions, anticipate threat signatures, and try and preventing things from getting to the firewalls rather than just stopping at the firewalls.”

Please. I've been hearing these sorts of ideas since the late 1990s, and no one can do it. As long as the adversary maintains the initiative and operational security, no defender is going to "anticipate intrusions," or "anticipate threat signatures."

Still, I expect Einstein to start appearing on private networks, probably in 2011. I doubt when it happens anyone will be able to talk about it, due to some kind of legal construct the government will devise and CIOs will adhere to.

Thursday, May 27, 2010

SANS WhatWorks Summit in Forensics and Incident Response

I wanted to remind everyone about the SANS WhatWorks Summit in Forensics and Incident Response in DC, 8-9 July 2010. The Agenda looks great. I will offer the "Expert Briefing: CIRT-level Response to Advanced Persistent Threat" and participate on the "APT Panel Discussion."

This IR event is a great precursor to my next SANS WhatWorks Summit in Incident Detection and Log Management in DC, 8-9 December 2010.

Monday, May 24, 2010

Forget Pre-Incident Cost, How Much Did Your Last Incident Cost?

I just read this great post by Rich Mogull titled FireStarter: The Only Value/Loss Metric That Matters.

His basic argument, or at least the idea that I derived from it, is the following (all in my own words).

So-called "risk managers" spend a lot of time imagining they can determine "annualized loss expectancy" by predicting how much an incident will cost. Forget all that nonsense. Before imaging what a future incident will cost, figure out how much your last incident cost.

This is brilliant because it is so simple yet drives straight at the heart of the problem. We work incidents all the time and I can't tell you how much they cost. Think about all the factors to consider:

  • Value of professional time of everyone who detected and responded to the incident

  • Value of computing resources affected by the incident

  • Value of data affected by the incident, whether disclosed, degraded, or denied

  • Value of brand, reputation, and other "goodwill" items

  • What else can you imagine?


So, think about answering these questions for a really good recent interest before wasting time imagining costs of future incidents. I think what you will find is that this can be a really difficult exercise. However, if you can derive some general guidelines, it's worth it.

More on Black Hat Costs

About a year ago I wrote Black Hat Budgeting, explaining how an offensive security team might spend $1 million. I said

"I submit that for $1 million per year an adversary could fund a Western-salaried black hat team that could penetrate and persist in roughly any target it chose to attack."

Tonight Jeremiah Grossman asked via Twitter:

jeremiahg@taosecurity regarding black hat budgeting, does defense-in-depth exacerbate the value cost inequity for defenders http://is.gd/cnGW9

I was tempted to squeeze some sort of reply into less than 140 characters, but decided to answer here instead.


  • First, vulnerability research is not free. Funny enough the No More Free Bugs movement is about one year old now. Charlie, Dino, and Alex are right -- it costs real resources to find vulnerabilities in software, with the level depending on the target.

  • Second, exploit development is not free. It is not trivial to devise a reliable, multi-target, stealthy-if-necessary exploit for a discovered vulnerability. Projects like Metasploit have made it a little easier since the days of one-off code for every proof of concept. Still, professional exploit writers still spend a lot of time on Metasploit, commercial alternatives, or their own mechanisms.

  • Third, victim management is not free. Everyone likes to talk about "risk management." Let's flip that notion around and think from the intruder's perspective. One of the features separating amateurs from professionals is the degree to which the intruder can manage his or her presence in the victim enterprise. The greater the persistence of the intruder the more professional the intruder, almost by definition. It takes a decent amount of work to stay present and/or undetected in an enterprise, depending on the defender's capabilities.


So, black hats have a lot of costs to manage, beyond those in my original post. I can pretty confidently argue, however, that intruder costs are dwarfed by defender costs. To the extent that "defense in depth" (DiD) applies additional costs yet do not meaningfully reduce exposure and vulnerability, DiD does indeed "exacerbate the value cost inequity for defenders."

Aside: a quick way to identify ineffective DiD is to review network diagrams showing "firewall stacks." I mean, seriously, in 2010, who needs more than one "traditional" firewall on a network segment? 10 or more years ago I remember network security people thinking you needed multiple different firewalls to they would each "catch something different" or cover for errors. These days everyone lets 80 and 443 traverse the firewall so malicious traffic just uses those services. How much money is wasted on these "traditional" designs?

Saturday, May 22, 2010

Watch Your WHOIS Entries

Thanks to sites like the Sucuri Security blog, domain name administrators should be learning that it is important to watch for updates to WHOIS records. Companies like Sucuri offer such a service free for one domain but charge for additional domains while providing extended services. If you'd just like to monitor your own WHOIS records using a simple script, you can be inspired by last year's article Network-based integrity monitoring keeps website hacks in check by David Davidson.

I decided to create the following simple script to watch two of my domains.

richard@macmini:~/check$ cat check.sh
#/bin/sh
/usr/bin/whois bejtlich.net > /home/richard/check/bejtlich.net.whois.new.txt
/usr/bin/whois taosecurity.com > /home/richard/check/taosecurity.com.whois.new.txt

/usr/bin/diff -u /home/richard/check/bejtlich.net.whois.old.txt \
/home/richard/check/bejtlich.net.whois.new.txt | mail -s "bejtlich.net whois check" taosecurity@gmail.com
/usr/bin/diff -u /home/richard/check/taosecurity.com.whois.old.txt \
/home/richard/check/taosecurity.com.whois.new.txt | mail -s "taosecurity.com whois check" taosecurity@gmail.com

mv /home/richard/check/bejtlich.net.whois.new.txt /home/richard/check \
/bejtlich.net.whois.old.txt
mv /home/richard/check/taosecurity.com.whois.new.txt /home/richard/check \
/taosecurity.com.whois.old.txt

Is this the world's greatest shell script? No, I wrote it in 60 seconds to make my point. Feel free to create something uber-cool and post it here. :)

Next I created empty files:

$ echo "" > bejtlich.net.whois.old.txt
$ echo "" > taosecurity.com.whois.old.txt

Finally I ran the check:

$ ./check.sh

Checking my email, I got two. Here's the one for bejtlich.net:

--- /home/richard/check/bejtlich.net.whois.old.txt 2010-05-22 20:52:58.000000000 -0400
+++ /home/richard/check/bejtlich.net.whois.new.txt 2010-05-22 20:53:05.000000000 -0400
@@ -1 +1,106 @@

+Whois Server Version 2.0
+
+Domain names in the .com and .net domains can now be registered
+with many different competing registrars. Go to http://www.internic.net
+for detailed information.
+
+ Domain Name: BEJTLICH.NET
+ Registrar: GODADDY.COM, INC.
+ Whois Server: whois.godaddy.com
+ Referral URL: http://registrar.godaddy.com
+ Name Server: NS18.ZONEEDIT.COM
+ Name Server: NS8.ZONEEDIT.COM
+ Status: clientDeleteProhibited
+ Status: clientRenewProhibited
+ Status: clientTransferProhibited
+ Status: clientUpdateProhibited
+ Updated Date: 22-may-2010
+ Creation Date: 01-jul-2000
+ Expiration Date: 01-jul-2011
...truncated...

As you can see it's "all new" because the old file was empty.

When I run the check again, I should get no significant changes via email.

--- /home/richard/check/bejtlich.net.whois.old.txt 2010-05-22 20:53:05.000000000 -0400
+++ /home/richard/check/bejtlich.net.whois.new.txt 2010-05-22 20:55:28.000000000 -0400
@@ -19,7 +19,7 @@
Creation Date: 01-jul-2000
Expiration Date: 01-jul-2011

->>> Last update of whois database: Sun, 23 May 2010 00:52:33 UTC <<<
+>>> Last update of whois database: Sun, 23 May 2010 00:54:20 UTC <<<
- Hide quoted text -

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is

You could argue not to use diff -u to simplify the output. Sure, you could. I just prefer seeing some context when changes do occur.

Now I'm going to add another DNS server to my WHOIS record and see if my script catches the change.

Reading email...

--- /home/richard/check/bejtlich.net.whois.old.txt 2010-05-22 20:55:28.000000000 -0400
+++ /home/richard/check/bejtlich.net.whois.new.txt 2010-05-22 20:58:09.000000000 -0400
@@ -10,6 +10,7 @@
Whois Server: whois.godaddy.com
Referral URL: http://registrar.godaddy.com
Name Server: NS18.ZONEEDIT.COM
+ Name Server: NS5.ZONEEDIT.COM
Name Server: NS8.ZONEEDIT.COM
Status: clientDeleteProhibited
Status: clientRenewProhibited
@@ -19,7 +20,7 @@
Creation Date: 01-jul-2000
Expiration Date: 01-jul-2011

->>> Last update of whois database: Sun, 23 May 2010 00:54:20 UTC <<<
+>>> Last update of whois database: Sun, 23 May 2010 00:57:09 UTC <<<

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
@@ -103,4 +104,5 @@
Domain servers in listed order:
NS18.ZONEEDIT.COM
NS8.ZONEEDIT.COM
+ NS5.ZONEEDIT.COM

There it is -- ns5.zoneedit.com. If I hadn't made that change, then I would know someone has compromised my account.

The next evolution of this script is to run it from cron, and better yet modify it so I only get an email if there is a change. For now, I have a simple way to watch for changes. Again, Sucuri should take credit for bringing this to people's attention during the last 2 years or so.

Sunday, May 16, 2010

Review of Masters of Deception Posted

Amazon.com just posted my three star review of Masters of Deception by Michelle Slatella and Joshua Quittner. From the review:

Masters of Deception (MOD) by Michelle Slatella and Joshua Quittner tells the tale of the self-proclaimed Masters of Deception, a phone phreaking and proto-computer hacker crew from the early 1990s. This was one of several books on the 1980s-1990s hacker scene that I recently read, but thus far I consider it the weakest. Initially I found it interesting, but as the book progressed I found the characters increasingly boring and shallow. Overall I felt the authors glamorized the lives of kids who expressed their teenage frustrations through digital means. The MOD story may sound novel to some readers, but having lived through the period in the book I can say this is one story of many that could be told.

Review of Cyberpunk Posted

Amazon.com just posted my four star review of Cyberpunk by Katie Hafner and John Markoff. From the review:

Cyberpunk is a unique exploration of three distinct digital security stories. Authors Katie Hafner and John Markoff describe the histories of Kevin Mitnick and friends, Hans Heinrich Hübner and the Hannover hackers, and Robert T Morris and family. This approach is interesting because all three tales are told independently, yet key events occur within a few years of each other and some overlap...

I don't usually include material beyond the first paragraph from my review announcements, but I loved these excerpts:

I'd like to conclude by citing some of my favorite excerpts. First, when describing Digital's Palo Alto security, the authors write:

"[I]n recognition of the open-mindedness back at corporate headquarters, the computer scientists in Palo Alto took great care to operate their precious gateway responsibly. To give the best possible oversight both for maintenance and security, Ph.D's in computer science took turns poring over daily log files... So it was only a matter of hours after the intrusions into the Palo Alto computers began that the gateway watchers there noticed something amiss." (emphasis added) p 118

Second, when expressing frustration with Digital's inability to counter the intruders, the authors quote "one irate Digital employee":

"We seem to be totally defenseless against these people. We have repeatedly rebuilt system after system and finally management has told the system support group to ignore the problem... I want to make sure someone at network security knows that we are being ***** (censored) in broad daylight. These people freely walk into our systems and are taking restricted, confidential, and proprietary information." (emphasis added) p 120

Third, nothing changes:

"Digital might be reluctant to press charges... [F]ew of the computer crimes detected were ever reported to the police and still fewer were made public through criminal charges... [C]ompanies worried about having their vulnerabilities publicized." p 125

Though nearly 20 years old, Cyberpunk still shares many traits with the modern digital security world.

Review of The Hacker Crackdown Posted

Amazon.com just posted my five star review of The Hacker Crackdown by Bruce Sterling. From the review:

Bruce Sterling's book The Hacker Crackdown (THC) captures the spirit and history of the "hacker scene" in the late 1980s and early 1990s. Having lived through that period with my C-64 and first 386 PC, I thought the author accurately describes what it was like for computer users during that era. THC is one of my favorite books on hacker activity because it combines a narrative with the author's accounts of interactions with key individuals. THC expertly tells several stories from multiple perspectives -- hacker, law enforcement, security professional, telecom operator, even homeless man-on-the-street! The author also manages to not offend technically-minded readers while describing material for non-technical audiences.

Saturday, May 08, 2010

Everything I Need to Know About Leadership I Learned as a Patrol Leader


This post is outside the digital security realm, but I know a lot of my readers are team members and team leaders in their technical shops. I thought it might be useful to share a few thoughts on leadership. I don't claim to be the world's best leader but I've been thinking about the topic recently.

I've participated in a lot of "leadership training" over the years, in and out of classrooms. A few examples: I've attended classes at GE's Crotonville, earned a master's degree from Harvard Kennedy School (supposed home to future political leaders), led a flight in the AFCERT, served as a cadet flight commander at USAFA, and captained my high school track team. As the years have progressed I find fewer of these experiences, especially formal training, to be novel or particularly helpful. For example, I believe the approaches I brought to my USAFA experience had less to do with USAFA and more to do with what I already knew. Tonight I decided to think back to where I first learned my "leadership style."

I realized that everything I needed to know about leadership I learned as a Patrol Leader, as a Boy Scout. Patrols are the core unit of the troop; they are the unit within a troop that can conduct independent activities, although they collaborate with other patrols during troop-wide events. I spent about 10 years as a Scout (starting as a Cub) and finished (barely) with my Eagle award a few months before I turned 18. My troop first nominated me to become a Patrol Leader when I was about 12.

I distinctly remember being a Patrol Leader twice. I led one patrol for my normal troop when I was younger, and then I was nominated to be a Patrol Leader for a regional troop from Massachusetts that attended the 1989 Scout Jamboree when I was 17. I cherished this second experience, because I was basically inactive during the ages of 15 and 16, due to high school. In both cases my patrol probably consisted of no more than 12 kids, usually younger but not always.

So what did I learn as a Patrol Leader? Check out these Ten Tips for Being a Patrol Leader from Scouting.org:

  1. Keep Your Word. Don't make promises you can't keep.

  2. Be Fair to All. A good leader shows no favorites. Don't allow friendships to keep you from being fair to all members of your patrol. Know who likes to do what, and assign duties to patrol members by what they like to do.

  3. Be a Good Communicator. You don't need a commanding voice to be a good leader, but you must be willing to step out front with an effective "Let's go." A good leader knows how to get and give information so that everyone understands what's going on.

  4. Be Flexible. Everything doesn't always go as planned. Be prepared to shift to "plan B" when "plan A" doesn't work.

  5. Be Organized. The time you spend planning will be repaid many times over. At patrol meetings, record who agrees to do each task, and fill out the duty roster before going camping.

  6. Delegate. Some leaders assume that the job will not get done unless they do it themselves. Most people like to be challenged with a task. Empower your patrol members to do things they have never tried.

  7. Set an Example. The most important thing you can do is lead by example. Whatever you do, your patrol members are likely to do the same. A cheerful attitude can keep everyone's spirits up.

  8. Be Consistent. Nothing is more confusing than a leader who is one way one moment and another way a short time later. If your patrol knows what to expect from you, they will more likely respond positively to your leadership.

  9. Give Praise. The best way to get credit is to give it away. Often a "Nice job" is all the praise necessary to make a Scout feel he is contributing to the efforts of the patrol.

  10. Ask for Help. Don't be embarrassed to ask for help. You have many resources at your disposal. When confronted with a situation you don't know how to handle, ask someone with more experience for some advice and direction.


You don't need a MBA now, aside from some classes on financial statements. I'd also venture that many MBA classes don't cover these 10 points.

I remember being particularly keen on patrol spirit:

Patrol spirit is the glue that holds the patrol together and keeps it going. Building patrol spirit takes time, because it is shaped by a patrol's experiences—good and bad. Often misadventures such as enduring a thunderstorm or getting lost in the woods will contribute much in pulling a patrol together. Many other elements also will help build patrol spirit. Creating a patrol identity and traditions will help build each patrol member's sense of belonging.

I remember working on our patrol flag and being proud of our new identity. Never mind that we were "Wolverines" (yes, straight out of Red Dawn) but our flag had a panther or cougar on it. (Blame the T-shirt shop for not having a "wolverine" transfer.) We put our patches and name on that thing and that's all that mattered.

When I was about 14 my troop nominated me to become Senior Patrol Leader, which is the top boy leader. Unfortunately, it's like a management position, because while you lead the troop most of the activities happen at the patrol level. You end up being more of an intermediary between the adult leaders and the Patrol Leaders. It's an important job but I remember missing having my own patrol. That's one reason I was glad to get a Patrol Leader job with the regional troop attending the Jamboree in 1989.

My take-away from this post is to remember the 10 points outlined above when I work with my current team. It's been over 20 years since I left Scouting, but the lessons I learned there have proven to be timeless and enduring.

Papers Not PowerPoint, Plus Tips for Improvement

Recently I railed against PowerPoint. In this post I'd like to congratulate Black Hat and some of their Briefings speakers for submitting white papers, not just PowerPoint presentations.

This evening while cleaning out a tmp directory I noticed a copy of a white paper by IBM's Tom Cross from Black Hat DC 2010 titled Exploiting Lawful Intercept to Wiretap the Internet. The paper describes Tom's analysis of Cisco's implementation of CALEA for law enforcement-directed wiretaps. The paper is 18 pages, but the last 3 are basically citations. It's a great piece of work which I wish I had read earlier.

For me, this paper emphasized how much of a failure it is to try to deliver complicated information in PowerPoint form. I got more out of taking 20 minutes to read Tom's 15 pages of material than I could have trying to make sense out of his 41 slides. Tom is a good writer whose paper delivers solid arguments. Rather than just praise the paper and slam the PowerPoint, I'd like to show how Tom did use PowerPoint well so that I keep these ideas in mind when I need to brief audiences.

A speaker I listened to earlier this week said you can't expect an audience to take away more than one point from any slide, so why bother? In fact, if you adapt the ideas of the great Tufte, you should use PowerPoint only as a delivery mechanism for charts, diagrams, and other visuals.

Using this approach, the figure at right which appears in Tom's PowerPoint deck for Black Hat is just the kind of material that should appear in a PowerPoint presentation. You could imagine this diagram being in a handout given to the audience, but during the briefing Tom would no doubt want to point towards specific elements of the diagram while the audience watched. This justifies displaying the figure via PowerPoint, because it is the most effective medium for communicating the information.

I think the SNMP MIB extract displayed at left, also from Tom's PowerPoint, is justified as appearing in a slide. Tom isn't asking the audience to pay attention to every line on the slide, like someone might expect an audience to do with a slide full of bullets. Rather, Tom has highlighted two important excerpts, showing them as proof that within this MIB there are two elements which expose information to attackers. This information could also appear on a handout given to the audience. However, here I like seeing the information to prove Tom's point. It's almost like a "technical figure" for me.

On a related point, I did not see any PowerPoint posted for HD Moore's talk Metasploit and Money. However, HD posted a great 9 page white paper, which is archived. I think I already mentioned via Twitter that I enjoyed this paper, and I wonder if no slides were presented?

To summarize, if you're presenting complicated material, slides are generally not an effective delivery mechanism. At best they can supplement a briefing by being a vehicle for displaying figures or other visuals, but bullets are generally a waste of time. For details why, please see my posts on PowerPoint.

Friday, May 07, 2010

Bejtlich to Speak at SANS Forensics and Incident Response 2010

I am pleased to announce that I will return for the third SANS WhatWorks Summit in Forensics and Incident Response in DC, 8-9 July 2010. Rob Lee sent an email stating I would be on the Advanced Persistent Threat Panel with Chris Glyer and Mike Cloppert, so I'm looking forward to participating. I might also have a solo presentation, but I haven't seen the agenda yet. This IR event is a great precursor to my next SANS WhatWorks Summit in Incident Detection and Log Management in DC, 8-9 December 2010.

Update: Agenda is posted. I will participate in two panels (Network Forensics, APT) and provide one briefing (CIRT-level Response to Advanced Persistent Threat).

The Face of Information Warfare

When information warfare happens, it's possible the victims will not recognize it as "warfare." I was reminded of this yesterday during the market selloff, which may have been caused by an error in trading. I'm not saying that the market selloff was an information attack. Rather, what we saw yesterday (an example appears in the screen shot -- Proctor and Gamble down 32% in the blink of an eye) reminded me of what an information attack might look like.

The NASDAQ is "recovering" by cancelling trades. However, how sustainable is that incident response? Are those who placed trades going to accept that response? In the future, what happens when traders can't trust what their systems display?

I'm looking forward to seeing the outputs of any investigation into this incident.