Archive for the 'Doing it Differently' Category

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.

For Blog/Twitter Conversation: Can You Defend “GRC”?

Published by alex on December 15, 2009 in Doing it Differently, Science of Risk Management and argument. 15 Comments Tags: , , , , , , , .

Longtime readers know that I’m not the biggest fan of GRC as it is “practiced” today.  I believe G & C are subservient to risk management. So let me offer you this statement to chew on:

“A metric for Governance is only useful inasmuch as it describes an ability to manage risk”

True or False, why, and what are the implications if true or false.

Please discuss.

#newschoolsecurity

Engineers vs. Scammers

Published by Chandler Howell on December 5, 2009 in Doing it Differently, Reports and Data and Uncategorized. 0 Comments

Adam recently sent me a link to a paper titled, “Understanding scam victims: seven principles for systems security.”  The paper examines a number of real-world (i.e. face-to-face) frauds and then extrapolates security principles which can be applied generically to both face-to-face and information or IT security problems.

By illustrating these principles with examples taken from the British television series The Real Hustle, they provide accessible examples of how reasonable, intelligent people can be manipulated into making extremely poor (for them) decisions and being defrauded as a result. Perhaps you’re thinking, “That’s all well and good, but what do I care about other people getting scammed due to behaviors that I would like to believe I would never engage in?”

It’s a nice idea, and while it may hold true with some of them, such as the Dishonesty Principle (“It’s illegal, that’s why you’re getting such a good deal.”), many of these scams work not because the person is trying to do something sneaky, because they’re either trying to “Do The Right Thing,” e.g. The Social Compliance Principle, just get the job done, such as the Distraction Principle, or just plain get fooled, e.g. the Deception Principle,

So, like it or not, the paper would seem to tell us, you’re Damned if You Do, Damned If You Don’t, and eventually you’ll let your guard down at just the wrong time. The sub-title of the paper might as well have been, “Why your security system will eventually fail, no matter how good it is.”

So what’s the point of trying?

Well, first off, because all hope is not lost—even if you don’t read the paper, there are a number of points to consider, two of which I want to call out because they are essential to designing or analyzing a security system (or, really, a system which requires a degree of security):

• Identify the cases where the security of your system depends on an authentication task (of known people, of unknown people or of “objects”, including cash machines and web sites) performed by humans.

• Understand and acknowledge that users are very good at recognizing known people but easily deceived when asked to “authenticate”, in the widest sense of the word, “objects” or unknown people.

By understanding how and why systems fail, we can design them in such a manner as to avoid the failure. For example, never forget that authentication is really a two-way street, even most people are generally bad (at best) and oblivious (in general) to their role in the problem.

In the case of an ATM, the traditional security efforts are around protecting the ATM from malicious users. The fact that the users must also be protected from malicious ATM’s never seems to come up. Likewise, phishing and other forms of credential harvesting depend on the victim being unable to accurately authenticate the requester of their credentials, whether due to falling prey to Distraction, Deception, or Social Compliance.

By understanding this and explicitly forcing that problem to be considered “in-scope” by the system designers, we accomplish two important security goals. First, we address the fact that authentication is a two-way street, even if only it only a formal process (e.g. logging in) in one direction. Second, we expand the pool of people working on solving the problem and thus potentially creating a valuable innovation which can be applied across that problem elsewhere.

What we can’t do is take the easy way out and “blame the users.” In fact, the authors even close their paper by reminding us of this fact:

Our message for the system security architect is that it is naïve and pointless just to lay the blame on the users and whinge that “the system I designed would be secure if only users were less gullible”; instead, the successful security designer seeking a robust solution will acknowledge the existence of these vulnerabilities as an unavoidable consequence of human nature and will actively build safeguards that prevent their exploitation.

While Adam, Alex and I were discussing the paper, Adam took the bold step of declaring that,

The principles that tell an engineer what to do are better than those that tell a scammer what to do.

Personally, I’m going to confess that while I don’t disagree with his statement, I don’t think it matters, either. Engineering principles can help us make better decisions and design better systems, but unfortunately, they don’t let us make perfect decisions or design perfect solutions. Fortunately, even if they did we’d still have innovation elsewhere to create new and interesting problems which people would employ us to solve.

Regardless, there will always be an interplay of innovation and reaction on both sides of the equation—for scammers or attackers and for security engineers or defenders*. The attackers find a hole, the defenders find a way to close it or render it ineffective. So the attackers find a new hole, ad infinitum. The hole can be a weakness in an IT system, a business process, or, as is the case in many of the examples in Part One, the human brain.

Here’s where it gets tricky, though. Most defenders work for Someone Else. By that, I mean that they are employees of, either directly or by contract, of some other entity who is in the business of Getting Something Done. The entity is typically not in the business of Securing Things. Thus, the Distraction Principle is already working against us before we ever even get to work in the morning.

Next, once the asset is not something obviously valuable, such as money, people’s ability to recognize it as such fails rapidly, especially when they interact with it on a day-to-day basis. This is especially true when trying to protect trade secrets and other Intellectual Assets. I have been in meetings where Very Senior people were asked to identify the critical secrets in their branch of the organization and they were unable to do so. It’s not that they didn’t have any, it’s that they couldn’t pick them out of the crowd of their responsibilities because everyone they dealt with was also authorized to see them, so they had no recurring reminder or other filtering mechanism.  This is one of the reasons that Top Secret documents are stamped “Top Secret.”

In the examples from the paper, scammers utilize the opposite form of this problem in their principle of Deception, by convincing people that valueless things are actually, in fact, valuable—fake diamond rings, TV boxes with rocks in them, etc. In the corporate world, people don’t know, understand or remember what’s valuable, and thus are unable to properly prioritize protecting it among their other responsibilities (the Distraction Principle again).

Thus, I would argue that the issue is that people are just bad at accurately assessing value; that their ability to do so degrades over time; and that their ability is further weakened when scammers manipulate them.  Call it the Valuation Principle. This, in turn, makes them more vulnerable to a variety of ways of losing their valuables, be it cash, a car, or a Trade Secret, by application of the other Principles in the paper.

The challenge is that while it’s irrational to protect everything if only a small portion of the assets need the highest level of protection, most people (and thus, their organizations) are really bad at determining what level of security an asset actually requires (even with tools like classification and risk assessment).  Cost-effective Information Protection is as much about determining what to protect as ensuring that it’s protected.

* I assign these roles under the assumption that the defender holds an asset that an attacker wants to access or possess.

Less Is More

Published by David Mortman on November 25, 2009 in Doing it Differently. 2 Comments

Great post today over on SecureThinking about a customer who used a very limited signature set for their IDS.

Truth of the matter was that our customer knew exactly what he was doing. He only wanted to see a handful of signatures that were generic and could indicate that “something” was amiss that REALLY needed to be looked at. Not that something was a quasi attack or could be successful if only that OS was running this configuration of application X — just the nuts and bolts fundamentals of good ‘ole fashion network monitoring. His SNORT’s ran fast, faster than any other IDS of the same hardware investment, because pattern matching was reduced to a handful of rules.

I’m a huge fan of this sort of setup and something that I’ve promoted within the companies I’ve worked with. Why bother looking for something you know you aren’t vulnerable to either because you’ve patched it, configured around it or don’t have that issue at all? Furthermore, if you have signatures installed that you don’t care about, you are just creating noise that is hiding the stuff you really care about.

This does assume that you have a certain level of maturity and actually have the asset, patch and configuration management issues more or less under control. If you don’t, then this like many other problems remain intractable.

If you have a disciplined mature organization, you can largely, if not completely (depends on how complex your company is) move to only uses signatures to tell you when something out of the ordinary is going on and it doesn’t take a complex piece of software, such as Cisco Mars or Maltego to warn you. Instead, you configure just signatures for things like too many of certain classes of events coming from a certain machine:

Error 404: A client has requested something from my webserver that it does not have, or does not have at the location some client was looking for. When a high number of distinct web servers report 404 to a single client host, that host is not up to any good.

Or use of IP space you should never see on your internal network:

DARKNET: There was some IP traffic (ICMP/TCP/UDP doesn’t matter) from an RFC1918 (private) host that we didn’t allocate, or just don’t know about. This is the equivalent of the Police “running” a license plate, and the response coming back “not in system.” How many police would consider that a routine false positive and let the driver go without further questioning?

Alternately, you can look for events such as machines serving up DHCP who shouldn’t be or the sudden appearance of web servers on subnets that didn’t have them in the past.

I like to call this sort of configuration, “Signature Based Anomaly Detection.” It’s not fancy and it’s not complex, but it will tell you when something weird is going on. It may turn out to be a security issue, a misconfigured machine or someone violating change control, but regardless, it’s a great way to actually make your IDS useful and not just something you have to do because an auditor says you have to.