SEC Guidance Is a Really Big Deal

In November I wrote SEC Guidance Emphasizes Materiality for Cyber Incidents, my thoughts after reading an article by Senator Jay Rockefeller and former DHS Secretary Michael Chertoff. They explained why the CF Disclosure Guidance: Topic No. 2, Cybersecurity issued by the SEC in October is a big deal.

Since then I attended a conference on Director's and Officer's insurance in Connecticut, and spoke on a panel about that SEC guidance. During the conference I learned that the SEC guidance isn't a big deal -- it's a really big deal. We're talking a game changer, potentially on three fronts. Here's what I heard at the conference.

1. First, lawyers who read the language in the SEC guidance treated it as a "stop whatever you're doing and read this" moment. The lawyers I spoke to said the SEC guidance absolutely defined new reporting duties for companies, despite talk of it being merely a "clarification" or restatement of existing guidance.

   Clients bombarded insurance firms asking what language they should use in their SEC disclosure documents. They asked "what are other companies saying? What should we say?" The firms noted similar boiler plate shared among clients, most of which insufficiently met the SEC's requirements.

   One lawyer I spoke with said she expects the SEC to give publicly traded firms a "one year pass" before bringing enforcement actions against them for insufficiently outlining digital risk, pre- and post-breach.

2. Second, the SEC language will encourage shareholder lawsuits against companies by disgruntled parties who believe boards are not disclosing risks and actual breach details to investors. This will probably not be the primary cause for a suit but it will likely be one of other factors a shareholder action uses to show that a board is not fulfilling their duties to investors.
3. Third, the SEC language may prompt whistleblower reports from dissatisfied IT and security staff to organizations like the SEC Office of the Whistleblower. (That is a real organization!) In the seven weeks beginning with this new office's launch in August 2011, parties reported 334 tips from 37 states and 11 countries, with successful enforcement actions in up to 30% of cases.

   Although it doesn't appear that this new office has paid any whisteblowers yet, it is apparently gearing up to do so. Imagine a case where security staff believes that management is not treating a breach as the staff thinks it should be treated, and decides to report the incident to the SEC -- with the possibility of a payout waiting!

Right now Congress doesn't seem to think that the SEC rules are working. Joe Menn reported in Hacked companies still not telling investors the following:

At least a half-dozen major U.S. companies whose computers have been infiltrated by cyber criminals or international spies have not admitted to the incidents despite new guidance from securities regulators urging such disclosures.

Top U.S. cybersecurity officials believe corporate hacking is widespread, and the Securities and Exchange Commission issued a lengthy "guidance" document on October 13 outlining how and when publicly traded companies should report hacking incidents and cybersecurity risk.

But with one full quarter having elapsed since the SEC request, some major companies that are known to have had significant digital security breaches have said nothing about the incidents in their regulatory filings.

Now Senator Rockefeller is taking a closer look as reported by Jennifer Martinez of Politico this week:

Senate Commerce Chairman Jay Rockefeller thinks the SEC needs to ensure hacked companies are adequately informing their investors about when they suffer a security breach or cybersecurity risk that could jeopardize their financial standing.

The West Virginia Democrat wants the full commission to issue guidance for companies — right now they only have staff-level instructions — on when they have to report cyber breaches or threats and what steps they’re taking to minimize the risks.

“It’s crucial that companies are disclosing to investors how cybersecurity risks affect their bottom lines, and what they are doing to address those risks,” Rockefeller said in a statement to POLITICO.

Rockefeller will soon introduce an amendment that calls on the SEC to issue interpretive guidance on when companies must disclose cybersecurity risks and intrusions. Staffers for the Commerce Committee are finalizing the amendment and aim to introduce it before Sen. Joe Lieberman’s (I-Conn.) cybersecurity bill goes to the floor.

This is the sort of activity that I think is going to mark a sea change in digital security over the coming years. I don't expect engineering or technical developments to have anywhere near the same level of impact as issues that involve legislators, lawyers, insurers, and financiers. Stay tuned!

Tweet

Clowns Base Key Financial Rate on Feelings, Not Data

If you've been reading this blog for a while, you know I don't think very highly of mathematical valuations of "risk." I think even less highly of the clowns in the financial sector who call security professionals "stupid" because we can't match their "five digit accuracy" for risk valuation. We all know how well those "five digit" models worked out. (And as you see from the last link, I was calling their bluff in 2007 before the markets imploded.)

Catching up on last week's Economist this morning I found another example of financial buffoonery that boggles the mind. The article is online: Inter-bank interest rates; Cleaning up LIBOR -- A benchmark which matters to everyone needs fixing:

It is among the most important prices in finance. So allegations that LIBOR (the London inter-bank offered rate) has been manipulated are a serious worry.

LIBOR is meant to be a measure of banks’ own borrowing costs, and is used as the foundation for a host of other interest rates. Everyone is affected by LIBOR: it influences the payments made on mortgages and personal loans, and those received on investments and pensions.

Given its importance, the way LIBOR is calculated is astonishingly flimsy. LIBOR rates are needed, every day, for 15 different borrowing maturities in ten different currencies. But hard data on banks’ borrowing costs are not available every day, and this is the root of the LIBOR problem.

The British Bankers’ Association (BBA), responsible for LIBOR, gets around it by asking banks, each day, what they feel they should pay to borrow.

So LIBOR rates—and the returns on $360 trillion of financial contracts related to them, five times global GDP—are based on best guesses rather than hard data.

Let that sink in and forget about what you learned in business school or economics classes. LIBOR isn't based on actual rates; it's based on feelings!

The next part of the article talks about suspicions that banks manipulate this broken process to the advantage of the financial sector.

The remainder offers recommendations for improvement:

[T]he BBA should revamp LIBOR to ensure it is simple, transparent and accountable. These principles suggest LIBOR should be based on actual inter-bank lending, with any gaps filled in with the help of statistical techniques. Banks’ own guesses should be used as a last resort, not the first.

And regulators should collect data that could help spot LIBOR cheats: banks should be required to submit information on other banks’ borrowing costs, as well as their own. Regulators could cross-check submissions against hard data on banking-sector risk, and publicly report LIBOR abusers.

Keep this system in mind the next time a so-called "master of the universe" offers a lecture on measuring risk in digital security.

Tweet

Salvaging Poorly Worded Statistics

Today I joined a panel held at FOSE chaired by Mischel Kwon and featuring Amit Yoran. One of the attendees asked the following:

At another session I heard that "80% of all breaches are preventable." What do you think about that?

My brief answer explained why that statement isn't very useful. In this post I'll explain why.

The first problem is the "80%." 80% of what? What is the sample set? Are the victims in the retail and hospitality sectors or the telecommunications and aerospace industries? Speaking in general terms, different sorts of organizations are at different levels of maturity, capability, and resourcefulness when it comes to digital security.

In the spirit of salvaging this poorly worded statistic, let's assume (rightly or wrongly) that the sample set involves the retail and hospitality sectors.

The second problem is the term "breach." What is a breach? Is it the compromise of a single computer? (What's compromise? Does it mean executing malicious code, or login via stolen credentials, or...?) What is the duration of the incident? There are dozens of questions that could be asked here.

To salvage this part, let's assume "breach" means "an incident involving execution of unauthorized code by an unauthorized intruder" on a single computer.

The third problem is the word "preventable." "Prevention" as a concept is becoming less useful by the second. Think about how an intruder might try to execute malicious code against a victim. Imagine a fully automated attack that happens when a victim visits a malicious Web site. An exploit kit could throw a dozen or more exploits against a browser and applications until one works. Are they all non-zero day, or are some zero day? Again, many questions beckon.

To salvage the end of the original statement, let's translate "preventable" into "exploitation of a vulnerability for which a patch had been publicly available for at least seven days."

Our new statement now reads something like "In the retail and hospitality sectors, 80% of the incidents where an unauthorized intruder successfully executed unauthorized code on a single computer exploited a vulnerability for which a patch had been publicly available for at least seven days."

Isn't that catchy! That's why we heard shortcuts like the original statement, which are basically worthless. Unfortunately, they end up driving listeners into poor conceptual and operational models.

The wordy but accurate statement says nothing about preventability, which is key. The reason is that a determined adversary, when confronted by a fully patched target, may decide to escalate to using a zero-day or other technique for which patches are irrelevant.

Tweet

Inside a Commission Hearing on the Chinese Threat

This morning I testified at the U.S.-China Economic and Security Review Commission at a hearing on Developments in China’s Cyber and Nuclear Capabilities. In the picture taken by Mrs Bejtlich (thanks for attending!) I'm seated at the far right. To my left is Nart Villeneuve. To his left is Jason Healey.

As stated on their Web site, the U.S. Congress created the U.S.-China Economic and Security Review Commission in October 2000 with the legislative mandate to monitor, investigate, and submit to Congress an annual report on the national security implications of the bilateral trade and economic relationship between the United States and the People’s Republic of China, and to provide recommendations, where appropriate, to Congress for legislative and administrative action. The Commission holds hearings to solicit testimony from subject matter experts and builds on those hearings to produce an excellent annual report.

You can access the 2011 report on the Commission Web site, and even request a printed copy if you'd prefer to read paper.

A few weeks ago the Commission staff requested that I answer a set of questions, and I provided a draft response last Monday. When I testified each of us had seven minutes to make a statement, after which the Commissioners asked questions. The testimony posted online is the "extended" version of my remarks. I used an abridged version when speaking today, but didn't read it verbatim.

After we each made a seven minute statement, the Commissioners asked a round of questions. Each received about five minutes. We tried to keep to the rotation, which as you might expect was tough. Several questions were fairly complicated (like discussing the costs and benefits of "the cloud") so it was difficult to be anything near complete when responding. A few Commissioners were interested in supply chain questions and the problems posed by Chinese made telecommunications equipment.

I expect an audio recording of the event to be available at the Commission Web site within the next few weeks. Once that is posted I'll review it and share a few more thoughts on the Mandiant Blog.

In addition to my wife, thanks also to the members of the local computer network defense and intelligence communities who attended the briefing and said hello!

Tweet

Impressions: Fuzzing

Fuzzing by Michael Sutton, Adam Greene and Pedram Amini struck me as a good overview of many types of fuzzing techniques. If you read the Amazon.com reviews, particularly the verdict by Chris Gates, you'll see what I mean. For my purposes, the degree to which the authors covered the material was just right. If you're more in the trenches with this topic, you would probably want more from a book on fuzzing.

I liked the following aspects of the book: integration of history, real examples, diversity of approaches, case studies, and examples. I thought the book was easy to read and well presented. Paired with more specific, newer books on finding vulnerabilities, I think Fuzzing is a winner.

My only real dislike involved the quotes by former US President George W. Bush at the start of each chapter. I thought they were irrelevant and a distraction.

Tweet

Impressions: Hunting Security Bugs

I don't hunt security bugs for a living, but I've worked on teams that do and I find the process important to understand. A defender should appreciate the work that an adversary must perform in order to discover a vulnerability and weaponize an exploit. That is the spirit with which I read Hunting Security Bugs by Tom Gallagher, Bryan Jeffries, and Lawrence Landauer. When the book was published in 2006 all the authors worked at Microsoft and Microsoft Press published the book. (Yes, I did wait a long time to take a look at this title...)

Despite the passage of time, I thought HSB stood up very well. Most of the problems discussed in the book and the techniques to find them should still work today. The targets have changed somewhat (XP was the target in the book; Windows 7 would be more helpful today -- thought not everywhere).

Again, this is an impression and not a review, so I only offer thoughts and not opinions or judgements on the text. From what I saw, the book appears well written with helpful diagrams and screen shots. It covers a lot of surface area and ways to exploit it.

One note for the history buffs: the foreword says:

When Jesse James, the famous outlaw of the American West, was asked why he robbed banks, he replied, Thats where the money is.

I'm sure most of you think that Willie Sutton said that, not Jesse James. According to Snopes neither of them said it:

While lore would have it that the bank robber replied "Because that's where the money is" to that common question, Sutton denied ever having said it. "The credit belongs to some enterprising reporter who apparently felt a need to fill out his copy," wrote Sutton in his autobiography. "I can't even remember where I first read it. It just seemed to appear one day, and then it was everywhere."

But back to the book -- should you buy it? If your job involves finding vulnerabilities in Windows software (and this book does have more of a Windows slant), I would take a close look at it.

Tweet

Impressions: The Web Application Hacker's Handbook, 2nd Ed

In late 2009 I reviewed the first edition of The Web Application Hacker's Handbook. It was my runner-up for Best Book Bejtlich Read 2009. Now authors Dafydd Stuttard and Marcus Pinto have returned with The Web Application Hacker's Handbook, 2nd Ed.

This is also an excellent book, although I did not read it thoroughly enough to warrant a review. On p xxix the authors note that 30% of the book is "new or extensively revised" and 70% of the book has "minor or no modifications." I was very impressed to see the authors outline changes by chapter on pages xxx-xxxii. That is not common in second editions, in my experience.

The book is very thorough and introduces technology along with attacks and defenses. Their "hack steps" sections provide a playbook for assessing Web applications. Some sections even mention logging and/or alerting -- I'd like to see more of that here and elsewhere! The book also includes end-of-chapter questions with answers posted on the book Web site, mdsec.net/wahh.

Speaking of the Web site, the authors also post source code, links to tools, and checklists, plus labs costing a $7/hour fee. That is a new approach I haven't seen elsewhere, but I think it's an interesting idea.

At 912 pages WAHH2E offers a ton of content written in a clear and convincing style. Great work guys. My only concern was their refusal to cite sources. That makes a real difference in my mind; give credit where credit is due in the third edition.

Tweet