Friday, December 05, 2014

Nothing Is Perfectly Secure

Recently a blog reader asked to enlist my help. He said his colleagues have been arguing in favor of building perfectly secure systems. He replied that you still need the capability to detect and respond to intrusions. The reader wanted to know my thoughts.

I believe that building perfectly secure systems is impossible. No one has ever been able to do it, and no one ever will.

Preventing intrusions is a laudable goal, but I think security is only as sound as one's ability to validate that the system is trustworthy. Trusted != trustworthy.

Even if you only wanted to make sure your "secure" system remains trustworthy, you need to monitor it.

Since history has shown everything can be compromised, your monitoring will likely reveal an intrusion.

Therefore, you will need a detection and a response capability.

If you reject the notion that your "secure" system will be compromised, and thereby reject the need for incident response, you still need a detection capability to validate trustworthiness.

What do you think?

Tuesday, December 02, 2014

Bejtlich on Fox Business Discussing Recent Hacks

I appeared on Fox Business (video) today to discuss a wide variety of hacking topics. It's been a busy week. Liz Claman and David Asman ask for my perspective on who is responsible, why the FBI is warning about destructive malware, how the military should respond, what businesses can do about intrusions, and more. All of these subjects deserve attention, but I tried to say what I could in the time available.

For more on these and other topics, don't miss the annual Mandiant year-in-review Webinar, Wednesday at 2 pm ET. Register here. I look forward to joining Kristen Verderame and Kelly Jackson Higgins, live from Mandiant HQ in Alexandria, Virginia.

Monday, November 17, 2014

Response to "Can a CISO Serve Jail Time?"

I just read a story titled Can a CISO Serve Jail Time? Having been Chief Security Officer (CSO) of Mandiant prior to the FireEye acquisition, I thought I would share my thoughts on this question.

In brief, being a CISO or CSO is a tough job. Attempts to criminalize CSOs would destroy the profession.

Security is one of the few roles where global, distributed opponents routinely conduct criminal acts against business operations. Depending on the enterprise, the offenders could be nation state adversaries largely beyond the reach of any party, to include the nation state hosting the enterprise. Even criminal adversaries can remain largely untouchable.

I cannot think of another business function that suffers similar disadvantages. If a commercial competitor took actions against a business using predatory pricing, or via other illegal business measures, the state would investigate and possibly prosecute the offending competitor. For actions across national boundaries, one might see issues raised at the World Trade Organization (WTO), assuming the two hosting countries are WTO members.

These pressures are different from those faced by other elements of the business. When trying to hire and retain staff, human resources doesn't face off against criminals. When trying to close a deal, sales people don't compete with military hackers. (The exception might be transactions involving Chinese or Russian companies,) When creating a brand campaign, marketing people might have to worry about negative attention from hacktivists, but if the foe crosses a line the state might prosecute the offender.

The sad reality is that no organization can prevent all intrusions. The best outcome is to prevent as many intrusions as possible, and react quickly and effectively to those compromises that occur. As long as the security team contains and removes the intruder before he can accomplish his mission, the organization wins.

We will continue to see organizations fined for poor security practices. The Federal Trade Commission, Securities and Exchange Commission, and Federal Communications Commission are all very active in the digital security arena. If prosecutors seek jail time for CSOs who suffer compromises, I would expect CSOs will leave their jobs. They already face an unfair fight. We don't need to add the threat of jail time to the list of problems confronting security staff.

Monday, November 10, 2014

Thank You for the Review and Inclusion in Cybersecurity Canon

I just read The Cybersecurity Canon: The Practice of Network Security Monitoring at the Palo Alto Networks blog. Rick Howard, their CSO, wrote the post, which marks the inclusion of my fourth book in Palo Alto's Cybersecurity Canon. According to the company's description, the Canon is:

a list of must-read books where the content is timeless, genuinely represents an aspect of the community that is true and precise and that, if not read, leaves a hole in a cybersecurity professional’s education that will make the practitioner incomplete.

The Canon candidates include both fiction and nonfiction, and for a book to make it into the canon, must accurately depict the history of the cybercrime community, characterize key places or significant milestones in the community, or precisely describe technical details that do not exaggerate the craft.

It looks like my book is only the second technical book to be included. The first appears to be the CERT Guide to Insider Threats.

I am incredibly thankful for the positive and thorough coverage of my newest book, The Practice of Network Security Monitoring (PNSM). It is clear Rick spent a lot of time reading the book and digesting the contents. Even the post headings, such as "Network Security Monitoring Is More Than Just a Set Of Tools," "Operate Like You Are Compromised: Kill Chain Analysis," "Network Security Monitoring as a Decision Tool, Not a Reaction Process," "Incident Response and Threat Intelligence Go Together," and so on communicate key themes in my book.

With his background at the Army CERT, Counterpane, and iDefense, it's clear Rick converted his experiences defending significant networks into a worldview that resonates with that in PNSM.

Rick also emphasizes one of the goals of the book, which is to get anyone started on the road to network instrumentation. I wrote the book, and teach a class -- Black Hat, 8-9 December, near DC -- for this very purpose.

I wanted to add a bit more detail to the last section of the blog for the benefit of those who have not yet read PNSM. Rick mentions some of the tools incorporated in Security Onion, but I wanted to be sure readers understand the full spectrum of SO capabilities. I captured that in Figure 6-1, reproduced below.

While I don't cover all of these tools in PNSM, as Rick wrote, I show how to leverage core SO capabilities to detect and respond to intrusions.

If you would like a copy of PNSM, consider buying from the No Starch Web site, using discount code NSM101 to save 30%. One benefit over buying from the publisher is getting the digital and print editions in a bundle.

Thank you again to Rick Howard and Palo Alto Networks for including PNSM in the Cybersecurity Canon.

Tuesday, September 16, 2014

We Need More Than Penetration Testing

Last week I read an article titled  People too trusting when it comes to their cybersecurity, experts say by Roy Wenzl of The Wichita Eagle. The following caught my eye and prompted this post:

[Connor] Brewer is a 19-year-old sophomore at Butler Community College, a self-described loner and tech geek...

Today he’s what technologists call a white-hat hacker, hacking legally for companies that pay to find their own security holes. 

When Bill Young, Butler’s chief information security officer, went looking for a white-hat hacker, he hired Brewer, though Brewer has yet to complete his associate’s degree at Butler...

Butler’s security system comes under attack several times a week, Young said...

Brewer and others like him are hired by companies to deliberately attack a company’s security network. These companies pay bounties if the white hackers find security holes. “Pen testing,” they call it, for “penetration testing.”

Young has repeatedly assigned Brewer to hack into Butler’s computer system. “He finds security problems,” Young said. “And I patch them.”

On the face of it, this sounds like a win-win story. A young white hat hacker does something he enjoys, and his community college benefits from his expertise to defend itself.

My concern with this article is the final sentence:

Young has repeatedly assigned Brewer to hack into Butler’s computer system. “He finds security problems,” Young said. “And I patch them.”

This article does not mention whether Butler's CISO spends any time looking for intruders who have already compromised his organization. Finding security problems and patching them is only one step in the security process.

I still believe that the two best words ever uttered by Bruce Schneier were "monitor first," and I worry that organizations like those in this article are patching holes while intruders maneuver around them within the compromised network.

A Brief History of Network Security Monitoring

Last week I was pleased to deliver the keynote at the first Security Onion Conference in Augusta, GA, organized and hosted by Doug Burks. This was probably my favorite security event of the year, attended by many fans of Security Onion and the network security monitoring (NSM) community.

Doug asked me to present the history of NSM. To convey some of the milestones in the development of this operational methodology, I developed these slides (pdf). They are all images, screen captures, and the like, but I promised to post them. For example, the image at left is the first slide from a Webinar that Bamm Visscher and I delivered on 4 December 2002, where we presented the formal definition of NSM the first time. We defined network security monitoring as

the collection, analysis, and escalation of indications and warnings to detect and respond to intrusions.

You may recognize similarities with the intelligence cycle and John Boyd's Observe - Orient - Decide Act (OODA) loop. That is not an accident.

During the presentation I noted a few key years and events:

  • 1986: The Cliff Stoll intrusions scare the government, military, and universities supporting gov and mil research.
  • 1988: Lawrence Livermore National Lab funds three security projects at UC Davis by supporting the Prof Karl Levitt's computer science lab. They include AV software, a "security profile inspector," and the "network security monitor."
  • 1988-1990: Todd Heberlein and colleagues code and write about the NSM platform.
  • 1991: While instrumenting a DISA location suffering from excessive bandwidth usage, NSM discovers 80% of the clogged link is caused by intruder activity.
  • 1992: Former FBI Director, then assistant AG, Robert Mueller writes a letter to NIST warning that NSM might not be legal.
  • 1 October 1992: AFCERT founded.
  • 10 September 1993: AFIWC founded.
  • End of 1995: 26 Air Force sites instrumented by NSM.
  • End of 1996: 55 Air Force sites instrumented by NSM.
  • End of 1997: Over 100 Air Force sites instrumented by NSM.
  • 1999: Melissa worm prompts AFCERT to develop dedicated anti-malware team. This signaled a shift from detection of human adversaries interacting with victims to detection of mindless code interacting with victims.
  • 2001: Bamm Visscher deploys SPREG, the predecessor to Sguil, at our MSSP at Ball Aerospace.
  • 13 July 2001: Using SPREG, one of our analysts detects Code Red, 6 days prior to the public outbreak. I send a note to a mailing list on 15 July.
  • February 2003: Bamm Visscher recodes and releases Sguil as an open source NSM console.

As I noted in my presentation,. the purpose of the talk was to share the fact that NSM has a long history, some of which happened when many practitioners (including myself) were still in school.

This is not a complete history, either. For more information, please see my 2007 post Network Security Monitoring History and the foreword, written by Todd Heberlein, of my newest book The Practice of Network Security Monitoring.

Finally, I wanted to emphasize that NSM is not just full packet capture or logging full content data. NSM is a process, although my latest book defines seven types of NSM data. One of those data types is full content. You can read about all of them in the first first chapter of my book at the publisher Web site.

Thursday, September 04, 2014

Bejtlich Teaching at Black Hat Trainings 8-9 Dec 2014

I'm pleased to announce that I will be teaching one class at Black Hat Trainings 2014 in Potomac, MD, near DC, on 8-9 December 2014. The class is Network Security Monitoring 101. I taught this class in Las Vegas in July 2013 and 2014, and Seattle in December 2013. I posted Feedback from Network Security Monitoring 101 Classes last year as a sample of the student commentary I received.

This class is the perfect jumpstart for anyone who wants to begin a network security monitoring program at their organization. You may enter with no NSM knowledge, but when you leave you'll be able to understand, deploy, and use NSM to detect and respond to intruders, using open source software and repurposed hardware.

The first discounted registration deadline is 11:59 pm EDT October 31st. The second discounted registration deadline (more expensive than the first but cheaper than later) ends 11:59 pm EST December 5th. You can register here.

I recently topped the 1,000 student count for my cumulative years of teaching my own material at Black Hat. Since starting my current Black Hat teaching run in 2007, I've completely replaced each course every other year. In 2007-2008 I taught TCP/IP Weapons School version 1. In 2009-2010 I taught TCP/IP Weapons School version 2. In 2011-2012 I taught TCP/IP Weapons School version 3. In 2013-2014 I taught Network Security Monitoring 101.

I have no plans to design a new course for 2015 and beyond. If you want to see me teach Network Security Monitoring and related subjects, Black Hat is your best option.

Please sign up soon, for two reasons. First, if not enough people sign up early, Black Hat might cancel the class. Second, if many people sign up, you risk losing a seat. With so many classes taught at this venue, the conference lacks the large rooms necessary to support big classes.

Several students asked for a more complete class outline. So, in addition to the outline posted currently by Black Hat, I present the following that shows what sort of material I cover in my new class.

OVERVIEW

Is your network safe from intruders? Do you know how to find out? Do you know what to do when you learn the truth? If you are a beginner, and need answers to these questions, Network Security Monitoring 101 (NSM101) is the newest Black Hat course for you. This vendor-neutral, open source software-friendly, reality-driven two-day event will teach students the investigative mindset not found in classes that focus solely on tools. NSM101 is hands-on, lab-centric, and grounded in the latest strategies and tactics that work against adversaries like organized criminals, opportunistic intruders, and advanced persistent threats. Best of all, this class is designed *for beginners*: all you need is a desire to learn and a laptop ready to run a virtual machine. Instructor Richard Bejtlich has taught over 1,000 Black Hat students since 2002, and this brand new, 101-level course will guide you into the world of Network Security Monitoring.

CLASS OUTLINE

Day One

0900-1030
·         Introduction
·         Enterprise Security Cycle
·         State of South Carolina case study
·         Difference between NSM and Continuous Monitoring
·         Blocking, filtering, and denying mechanisms
·         Why does NSM work?
·         When NSM won’t work
·         Is NSM legal?
·         How does one protect privacy during NSM operations?
·         NSM data types
·         Where can I buy NSM?

1030-1045
·         Break

1045-1230
·         SPAN ports and taps
·         Making visibility decisions
·         Traffic flow
·         Lab 1: Visibility in ten sample networks
·         Security Onion introduction
·         Stand-alone vs server plus sensors
·         Core Security Onion tools
·         Lab 2: Security Onion installation

1230-1400
·         Lunch

1400-1600
·         Guided review of Capinfos, Tcpdump, Tshark, and Argus
·         Lab 3: Using Capinfos, Tcpdump, Tshark, and Argus

1600-1615
·         Break

1615-1800
·         Guided review of Wireshark, Bro, and Snort
·         Lab 4: Using Wireshark, Bro, and Snort
·         Using Tcpreplay with NSM consoles
·         Guided review of process management, key directories, and disk usage
·         Lab 5: Process management, key directories, and disk usage

Day Two

0900-1030
·         Computer incident detection and response process
·         Intrusion Kill Chain
·         Incident categories
·         CIRT roles
·         Communication
·         Containment techniques
·         Waves and campaigns
·         Remediation
·         Server-side attack pattern
·         Client-side attack pattern

1030-1045
·         Break

1045-1230
·         Guided review of Sguil
·         Lab 6: Using Sguil
·         Guided review of ELSA
·         Lab 7: Using ELSA

1230-1400
·         Lunch

1400-1600
·         Lab 8. Intrusion Part 1 Forensic Analysis
·         Lab 9. Intrusion Part 1 Console Analysis

1600-1615
·         Break

1615-1800
·         Lab 10. Intrusion Part 2 Forensic Analysis
·         Lab 11. Intrusion Part 2 Console Analysis

REQUIREMENTS

Students must be comfortable using command line tools in a non-Windows environment such as Linux or FreeBSD. Basic familiarity with TCP/IP networking and packet analysis is a plus.

WHAT STUDENTS NEED TO BRING

NSM101 is a LAB-DRIVEN course. Students MUST bring a laptop with at least 8 GB RAM and at least 20 GB free on the hard drive. The laptop MUST be able to run a virtualization product that can CREATE VMs from an .iso, such as VMware Workstation (minimum version 8, 9 or 10 is preferred); VMware Player (minimum version 5 -- older versions do not support VM creation); VMware Fusion (minimum version 5, for Mac); or Oracle VM VirtualBox (minimum version 4.2). A laptop with access to an internal or external DVD drive is preferred, but not mandatory.

Students SHOULD test the open source Security Onion (http://securityonion.blogspot.com) NSM distro prior to class. The students should try booting the latest version of the 12.04 64 bit Security Onion distribution into live mode. Students MUST ensure their laptops can run a 64 bit virtual machine. For help with this requirement, see the VMware knowledgebase article “Ensuring Virtualization Technology is enabled on your VMware host (1003944)” (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003944). Students MUST have the BIOS password for their laptop in the event that they need to enable virtualization support in class. Students MUST also have administrator-level access to their laptop to install software, in the event they need to reconfigure their laptop in class.

WHAT STUDENTS WILL RECEIVE

Students will receive a paper class handbook with printed slides, a lab workbook, and the teacher’s guide for the lab questions. Students will also receive a DVD with a recent version of the Security Onion NSM distribution.

TRAINERS

Richard Bejtlich is Chief Security Strategist at FireEye, and was Mandiant's Chief Security Officer when FireEye acquired Mandiant in 2013. He is a nonresident senior fellow at the Brookings Institution, a board member at the Open Information Security Foundation, and an advisor to Threat Stack, Sqrrl, and Critical Stack. He is also a Master/Doctor of Philosophy in War Studies Researcher at King's College London. He was previously Director of Incident Response for General Electric, where he built and led the 40-member GE Computer Incident Response Team (GE-CIRT). Richard began his digital security career as a military intelligence officer in 1997 at the Air Force Computer Emergency Response Team (AFCERT), Air Force Information Warfare Center (AFIWC), and Air Intelligence Agency (AIA). Richard is a graduate of Harvard University and the United States Air Force Academy. His fourth book is "The Practice of Network Security Monitoring" (nostarch.com/nsm). He also writes for his blog (taosecurity.blogspot.com) and Twitter (@taosecurity), and teaches for Black Hat.

Thursday, August 21, 2014

Air Force Leaders Should Read This Book

I just finished reading The Icarus Syndrome: The Role of Air Power Theory in the Evolution and Fate of the U.S. Air Force by Carl Builder. He published this book in 1994 and I wish I had read it 20 years ago as a new Air Force second lieutenant. Builder makes many interesting points in the book, but in this brief post I'd like to emphasize one of his concluding points: the importance of a mission statement.

Builder offers the following when critiquing the Air Force's mission statement, or lack thereof, around the time of his study:

[Previous] Air Force of Staff, General John P. McConnell, reportedly endorsed the now-familiar slogan

     The mission of the Air Force is to fly and fight. 

Sometime later, the next Chief, General John D. Ryan, took pains to put it more gruffly:

     The job of the Air Force is to fly and to fight, and don't you ever forget it. (p 266)

I remember hearing "Fly, Fight, Win" in the 1990s as well.

Builder correctly criticizes these mission statements on multiple grounds, none more compelling than this: how are non-flyers supposed to interpret this statement? It's simply a reminder and reinforcement of the second-class status of non-flyers in the Air Force. Furthermore, Builder more or less also notes that "fight" is often eclipsed but non-combat missions, such as airlift or humanitarian relief. Finally, Builder doesn't ask the question explicitly, but how does one define "winning"? Would wars in Iraq or Afghanistan be a "win"? That's a demoralizing way to think in my opinion.

Builder offers a wonkish, but conceptually more useful, mission statement on p 284:

The mission of the Air Force is the military control and exploitation of the aerospace continuum in support of the national interests.

The author immediately notes that one Air Force officer criticized Builder's mission statement as too "academic," but I think this particular policy wonk is on target.

Curious as to what the current Air Force mission statement says, I checked the Our Mission page and read at the top:

The mission of the United States Air Force is to fly, fight and win … in air, space and cyberspace.

Wow. That's even worse than before. Not only does it still insult non-flyers, but now the mission involves "flying" in "cyberspace."

I strongly suggest Air Force leaders read Builder's book. It's as relevant today as it was 20 years ago.