Archive for the 'Doing it Differently' Category

New low in pie charts

Published by adam on August 6, 2010 in Amusements and Doing it Differently. 5 Comments

It’s not just a 3d pie chart with lighting effects and reflection. Those are common. This one has been squished. It’s wider than it is tall.

CenzicPieChart.png

While I’m looking closely, isn’t “input validation” a superset of “buffer errors” “code injection” and “command injection?”

You can get the “Application Security Trends report for Q1-Q2 2010” from Cenzic. I’ve been generally impressed by the founders and other work I’ve seen for a long time, and I look forward to beautiful and effective data presentation in their future reports.

How to Get Started In Information Security, the New School Way

Published by adam on April 24, 2010 in Doing it Differently and careers. 6 Comments

There have been a spate of articles lately with titles like “The First Steps to a Career in Information Security” and “How young upstarts can get their big security break in 6 steps.”

Now, neither Bill Brenner nor Marisa Fagan are dumb, but both of their articles miss the very first step. And it’s important to talk about that first step when talking about first steps in a career:

Do something useful.

Some ideas:

  • Write a new tool
  • Add an awesome UI to an existing tool
  • Break something interesting and responsibly disclose it*
  • Get more data out there
  • Analyze existing data in a new and thought-provoking way

We have enough people in infosec who are famous for being famous, or famous for being controversial. If you want to stand out from the pack, do something to move the field forward. Share useful work.

You’ll stand out a lot better than people adding to the chorus.

* You want to disclose it responsibly because it avoids a whole silly debate which detracts from attention to your work.

Lessons from Robert Maley’s Dismissal

Published by adam on March 22, 2010 in Doing it Differently and disclosure. 0 Comments

A bit over a week ago, it came out that “Pennsylvania fires CISO over RSA talk.” Yesterday Jaikumar Vijayan continued his coverage with an interview, “Fired CISO says his comments never put Penn.’s data at risk.”

Now, before I get into the lessons here, I want to point out that Maley is the sort of enthusiastic guy who used vacation time to speak at RSA. If you’re looking for a CSO or a leader, you should get in touch.


I think there are two important things to notice here. First, when you’re specifically asked not to speak, don’t speak: “I was specifically asked not to talk about anything in Pennsylvania without explicit permission and to have everything that I would say to be completely reviewed before I said it.” Regular readers know this pains me as an advocate of openness. However, it’s not your data, it’s your employer’s data. Treat it with discretion.

The second, and more interesting thing is that the firing is news. Things that happen regularly are only news on the Weather Channel. So can we jump to “someone is getting fired for speaking up is actually rare?” Job loss is one of the more challenging questions that I regularly hear. It’s scary, doubly so in today’s fiscal climate. Firing is personal. And we don’t really know how often it happens. A lot of the anecdotes are simply inaccurate. Getting data involves a lot of manual effort and the accuracy is low. I’ve done some of it, digging into web sites and archive.org, looking at profiles on LinkedIn, and seen very little evidence that breaches or breach disclosures lead to firings.

I can see three somewhat distinct hypotheses here:

  1. Firings are rare, and thus news
  2. Firings of executives is rare, and thus news
  3. Firings are usually covered up, and thus when they’re not, it’s news

Note that 2 (execs) is strictly a subset of 1 (all firings), and thus less likely as an overall explanation, but firing rates probably differ for execs and staff.


I would be great to have data to help us distinguish, but for now, I consider advocating for #1 a best practice.

Why I’m Skeptical of “Due Diligence” Based Security

Published by alex on March 17, 2010 in Doing it Differently, Science of Risk Management and argument. 10 Comments Tags: , , , .

Some time back, a friend of mine said “Alex, I like the concept of Risk Management, but it’s a little like the United Nations – Good in concept, horrible in execution”.

Recently, a couple of folks have been talking about how security should just be a “diligence” function, that is, we should just prove that we’re doing best efforts and that should be enough.  Now conceptually, I love the idea that we can prove our “compliance” or diligence and get a get out of jail free card when an incident happens.  I always think it’s lame when good CISO’s get canned because they got “unlucky”.

Unfortunately, if risk management is infeasible, I’ve been thinking that the concept of Due Diligence Security is complete fantasy.  To carry the analogy, if Risk Management is the United Nations, then Due Diligence Security is the Justice League of Superfriends.  With He-Man.  And the animated Beatles from Yellow Submarine.  That live in the forrest with the Keebler elves and the Ewoks and where the glowing ghosts of Anakin, Obi-Wan and Yoda perform the “Chub-Chub” song with the glowing ghosts of John Lennon and George Harrison. That sort of fantasy.

DUE DILIGENCE BASED SECURITY IS AN ARGUMENT FROM IGNORANCE

Here’s the rub – lets say an incident happens.  Due Diligence only matters when there’s a court case, really.  And in most western courts of law these days, there’s still this concept of innocent until proven guilty.  This concept is known as the argument from ignorance in logic and it is known as a logical fallacy.

Now arguments from ignorance are known as logical fallacies thanks to the epistemological notion of falsification.  Paraphrasing Hume paraphrasing John Stuart Mill – we cannot prove “all swans are white” simply because we’ve observed all white swans -  BUT the observation of a single black swan is enough to prove that “not all swans are white”.   This matters in a court of law, as your ability to prove Due Diligence as a defendant will be a function your ability to prove all swans white – all systems compliant.  But the prosecution only has to show a single black swan to prove that you are NOT diligent.

Sir Karl Popper says, “Good luck with that, Mr. CISO”.

IT’S A TRAP!!!

The result is this – the CISO, in my humble opinion, will be in a worse condition because we have a really poor ability to control the expansion of sensitive information throughout the complex systems (network, system, people, organization) for which they are responsible.  Let me put it this way:  If information (and specifically, sensitive information) operates like a gas, automatically expanding to where it’s not controlled – then how can we possibly hope that the CISO can control the “escape” or leakage of information 100% of the time with no exceptions?  And a solitary exception in a forensic investigation becomes our black swan.

And therefore…   When it comes to proving Due Diligence in the court of law  – Security *screws* the CISO.  Big Time.

Everybody Should Be Doing Something about InfoSec Research

Published by adam on March 10, 2010 in Doing it Differently, argument and data. 8 Comments

Previously, Russell wrote “Everybody complains about lack of information security research, but nobody does anything about it.”

In that post, he argues for a model where

Ideally, this program should be “idea capitalists”, knowing some people and ideas won’t payoff but others will be huge winners. One thing for sure — we shouldn’t focus this program only on people who have been “officially” annointed by some hierarchy, some certification program, or by credentials alone.

I agree that a focus on those anointed won’t help, but that doesn’t mean it’s easy to set up such an institution.

The trouble with the approach is that we have such institutions (*ARPA, venture capital) and they’ve all failed for institutional reasons. However high their aspirations, such organizations over time get flack from their funders over their failures, their bizarre and newsworthy ideas and the organizations become conservative. They trend towards “proven entrepreneurs” and incrementalism. The “Pioneer Fellows” idea does not overcome this structural issue. (There is an argument that the MacArthur genius grants overcome it. I’m not aware of any research into the relative importance of work done before and after such grants, but I have my suspicions, prejudices and best practices.)

Of course, I might be wrong. If you have a spare million bucks, please set this up, and we can see how it goes. An experiment, if you will.

Experiments are a big part of why Andrew and I focused on free availability of data. With data, those with ideas can test them. There will be a scrum of entrepreneurial types analyzing the data. Fascinating stuff will emerge from that chaos. With evidence, they will go to the extant ‘big return’ organizations and get funding. Or they’ll work for big companies and shift product directions.

That is, the issue in infosec is not a lack of interesting ideas, it’s the trouble in testing them without data. We need data to test ideas and figure out how they impact outcomes.

Howard Schmidt’s talk at RSA

Published by adam on March 2, 2010 in Book and Doing it Differently. 0 Comments

The New York Times has a short article by Markoff, “U.S. to Reveal Rules on Internet Security.” The article focuses first on declassification, and goes on to say:

In his first public speaking engagement at the RSA Conference, which is scheduled to open Tuesday, Mr. Schmidt said he would focus on two themes: partnerships and transparency.

I’m very happy that in a little under two years since we published the New School, transparency has taken a role on center stage. Obviously, I wouldn’t claim all the credit for that. At the same time, I’m happy that we’ve contributed to re-orienting people and accelerating this important change.

Human Error

Published by Chandler Howell on February 22, 2010 in Doing it Differently and research papers. 1 Comment

In his ongoing role of “person who finds things that I will find interesting,” Adam recently sent me a link to a paper titled “THE HUMAN FACTORS ANALYSIS AND CLASSIFICATION SYSTEM–HFACS,” which discusses the role of people in aviation accidents.  From the abstract:

Human error has been implicated in 70 to 80% of all civil and military aviation accidents. Yet, most accident reporting systems are not designed around any theoretical framework of human error. As a result, most accident databases are not conducive to a traditional human error analysis, making the identification of intervention strategies onerous. What is required is a general human error framework around which new investigative methods can be designed and existing accident databases restructured. Indeed, a comprehensive human factors analysis and classification system (HFACS) has recently been developed to meet those needs.

Consider that pilots, whether private, commercial, or military, are one of the more stringently trained and regulated groups of people on the planet.  This is due, at least in part, to the history of aviation.  As the report notes,

In the early years of aviation, it could reasonably be said that, more often than not, the aircraft killed the pilot. That is, the aircraft were intrinsically unforgiving and, relative to their modern counterparts, mechanically unsafe. However, the modern era of aviation has witnessed an ironic reversal of sorts. It now appears to some that the aircrew themselves are more deadly than the aircraft they fly (Mason, 1993; cited in Murray, 1997). In fact, estimates in the literature indicate that between 70 and 80 percent of aviation accidents can be attributed, at least in part, to human error (Shappell & Wiegmann, 1996).

One upon a time, operating an airplane was so dangerous that only highly-skilled experts could do it, and even then the equipment would get out of their control and crash.  Later (yet still almost twenty years ago), the equipment improved to the point that equipment failure no longer overshadowed operator error, but planes still get out of control and crash.

Other than the fact that pilots are almost universally still highly-skilled and/or trained operators, this doesn’t sound all that different from the evolution of computing.

Flight has obviously never really had the adoption rate explode like PC’s in the Age of the Web, but there is still a strong parallel between aircraft accidents and Information Security failures.  This assertion becomes even more true once the paper gets into James Reason’s “Swiss Cheese” model of understanding root causes of aircraft accidents.

Reason identifies four factors that interact with each other increase accident rates, which I’ll paraphrase as:

  1. Unsafe Acts — This is the cause of the active failure (i.e. crash), such as a poor decision or a failure to watch the instruments or otherwise recognize the unsafe situation was forming or occurring
  2. Preconditions for Unsafe Acts– Situations that increase risk of an accident, such as miscommunication between aircrew members or with others outside the aircraft, such as air traffic control
  3. Unsafe Supervision– failures of management or leadership to recognize when they are, for example, pairing inexperienced pilots together in less-than-optimal conditions
  4. Organizational Influences — Usually business-level decisions, such as reducing training hours to reduce costs

How familiar does this sound?  If you’ve ever read an IT Audit report, this should seem painfully familiar, even if only analogously.  The paper provides a strong taxonomy within each area, and I could easily drill down at least one more level into each one.  Read the paper to learn more and become a better professional problem solver, security-related or otherwise.

For example, using a real-world case I dealt with recently.  This is an easy example which ties the four levels together more neatly than many, so consider it an “Example-Size Problem” and extend as you see appropriate.

The incident was the loss of sensitive business information, which I personally believe hurt the company in a negotiation:

  1. Unsafe Act:  The VP left his unencrypted laptop unattended while at a meeting — this was the Active Failure/Unsafe Act that led to the Mishap
  2. Preconditions:  The VP assumed that others were watching his laptop, but did not explicitly confirm this fact
  3. Unsafe Supervision:  Despite knowing that Executives are high-risk users with regards to sensitive information on their laptops, the IT Executive Support Team had recommended against deploying Full-Disk Encryption on executives’ laptops because they feared being held accountable if an executive lost information due to an encryption system failure
  4. Organizational Influences:  While a Laptop Encryption Policy existed and specified that the VP should have been encrypted for multiple reasons, the policy was widely ignored, there was no cultural pressure to ensure that mobile information was protected, and thus compliance was unacceptably low.  No pressure to comply was generated by Executive management because the cost associated with doing so was considered to be prohibitive.

In this case, the damage (opportunity cost) of lost revenue due to that single lost laptop was many multiples of the complete cost of deploying a Full-Disk Encryption system.  Unfortunately, in the absence of a comprehensive analysis of the series of failures leading up to the unsafe act, the real root cause of an incident may be ignored or mis-assigned, leading to either an incomplete or unsustainable remediation course.

When incidents occur, it’s rare to see a true and honest assessment not just what went wrong, but why.  Too often, in fact, the culture seems to be to put it down to, “nobody could have predicted it.”  Reject these assessments.  To improve an organization, we must refuse to accept these explanations.  Instead, find the root cause–all the way up to the Organizational Influences–and then Fix It.

Best Practices for Defeating the term “Best Practices”

Published by adam on February 12, 2010 in Amusements and Doing it Differently. 15 Comments

I don’t like the term “Best Practices.” Andrew and I railed against it in the book (pages 36-38). I’ve made comments like “torture is a best practice,” “New best practice: think” and Alex has asked “Are Security “Best Practices” Unethical?”

But people keep using it. Worse, my co-workers are now using it just to watch get me spun up. My continued snark is clearly a Best Practice because I keep doing it despite evidence that it doesn’t work.

I’d love to hear your experiences. What are proven or effective practices for getting people to stop using the term?

Doing threat intelligence right

Published by Russell on January 18, 2010 in Doing it Differently, Links and Science of Risk Management. 2 Comments

From a great article by Robert Jervis, professor of international politics at Columbia University:

The problem isn’t usually – or at least isn’t only – too little information, but too much, most of it ambiguous, contradictory, or misleading. The blackboard is filled with dots, many of them false, and they can be connected in innumerable ways. Only with hindsight does the correct pattern leap out at us, and to fix what “broke” the last time around only guarantees you have solved yesterday’s problem.

Far more important, and useful, is to address the flaws in how we interpret and use the intelligence that we already gather. Intelligence analysts are human beings, and many of their failures follow from intuitive ways of thinking that, while allowing the human mind to cut through reams of confusing information, often end up misleading us. This isn’t a problem that occurs only with spying. It is central to how we make sense of our everyday lives, and how we reach decisions based on the imperfect information we have in our hands. And the best way to fix it is to craft policies, institutions, and analytical habits that can compensate for our very understandable flaws.

[...]

The first and most important tendency is that our minds are prone to see patterns and meaning in our world quite quickly, and then tend to ignore information that might disprove them. Premature cognitive closure, to use the phrase employed by psychologists, lies behind many intelligence failures.

[...]

Second, people pay more attention to visible information than to information generated by an absence. In a famous Arthur Conan Doyle story, it took the extraordinary skill of Sherlock Holmes to see that an important clue in the case was a dog not barking. The equivalent, in the intelligence world, is information that should be there but is not.

[...]

Third, conclusions often rest on assumptions that are not readily testable, and may even be immune to disproof.

I’ll add a fourth — ignoring threat intelligence all together or treating it as taboo.  This may take several forms: ”it’s beyond our control”, “we don’t have good data”, “it’s too hard to quantify”, “we aren’t paid for guess-work”, “we rely on vendors for that”, “everybody knows what the threats are”, “if we bring it up, we will get too many questions we can’t answer”, or other excuses.  (See Josh Corman’s post on the folly of relying on security vendors for your threat intelligence.  Vendors only have incentive to inform you about threats they can mitigate.)

If you want a good methodology for threat intelligence, look at Intel’s.    It was adapted for use by the Information Technology Sector Coordinating Council in their risk assessment for critical IT industry infrastructure.

As good as it is, it could even be better if they had some systematic methods to actively seek out contradictory information and contrary hypotheses about threats.  One simple way to do this is to create a “Mental Model Red Team” whose primary job is to disprove everything you think you know, or at least generate and validate contrary hypotheses.  (For social and cultural reasons, you should probably rotate your staff through this team rather than keeping the team membership fixed.)    Formal methods exist, including “Analysis of Competing Hypotheses” (slides).  (I’m in the process of evaluating a tool for this called SHEBA.  I hope to have a demo read for Mini-metricon, something like this.)  Another possible method is prediction markets, but I’ve never seen them used for this purpose.

How not to do security, Drone Video Edition

Published by Chandler Howell on January 4, 2010 in Doing it Differently. 3 Comments

This is probably considered to be “old news” by many, but I’m high-latency in my news at the moment.

Much was made of the fact that the US Military’s enemies are now eavesdropping on the video feeds from US Drones on the battlefield using cheaply available commercial technology.  But it’s OK, because according to the Military, there was a Good Reason why it wasn’t encrypted:

The reason the U.S. military didn’t encrypt video streams from drone aircraft flying over war zones is that soldiers without security clearances needed access to the video, and if it were encrypted, anyone using it would require security clearance, a military security expert says.

I can only hope that this is not really what passes for logic among the security decision-makers in the U.S. Military and their contractors.  There is additional information in the article which tells us that they at least performed a risk assessment, but the assessment seems to have been flawed.

It’s always easy to second-guess decisions in hindsight, but if the rationale given is even minimally truthful, then what they have essentially said is, The video feed was not encrypted because the policies which would have then applied would have been too onerous.

That’s not to say that my summary of the rationale is not sound in certain cases–after all, the processes necessary to comply are part of the cost of a countermeasure.  But in this case, the policy was clearly flawed  Who wants to bet that the same un-cleared soldiers never have access to encrypted radio links, or that they use military Web sites encrypted with SSL?

Access to (shared or symetrical) encryption keys probably does (and probably should) require a clearance, but claiming that requirement would extend to utilizing the encrypted link as rationalization for not doing so strikes me as a bit absurd.

Similarly, this justification:

…the video information loses its value so rapidly that the military may have decided it wasn’t worth the effort to encrypt it. “Even if it were a feed off a drone with attack capabilities, and even if the bad guys saw that the drone was flying over where they were at that moment, they wouldn’t have the chance to respond before the missile was fired,”

also fails to pass muster.

A key element of insurgency and counter-insurgency is the hide-and-seek aspect of it.  The initial value of drones was their ability to monitor large areas in real time and loiter on-scene for much longer (and more cheaply) than conventional aircraft.   As a result, drones are a huge force multiplier for the US and its allies in counter-insurgency operations.  If the insurgents are able to determine where the US forces are looking for them, that is extremely valuable intelligence to the insurgents, since they can then identify which logistical routes or encampments are potentially compromised and re-route forces accordingly.

Using drones as a delivery platform for munitions, on the other hand, is relatively rare and was not, in fact, even in-scope for the drones when initially deployed.

As a general rule, justifications for risk acceptance based on exceptional cases should be taken as evidence that the  decision was bad.  This is not an exception to that rule.