On "Ransomware"

Forty years ago, my friend and colleague, Donn Parker, suggested that "employees" would use cryptography to hide enterprise data from management.  Employees because forty years ago only one's employees could send a message to one's systems.  I laughed.  It was obvious to me that such an activity would require both "read" and "write" access to the data.  I was so young and naive that I could not foresee a world in which most of those connected to enterprise systems would be outsiders, including sophisticated criminal enterprises.  Mostly, I could not anticipate a world in which "read/write" would be the default access control rule, not only for data, but also for programs.  

We are now three years since the first "ransomware" attacks.  We are still paying.  Indeed, a popular strategy is to pay an insurance underwriter to share some of the risk.  This is a strategy that only the underwriters and the extortioners can like.  While this was an appropriate strategy to follow early, it is no substitute for resisting and mitigating the attacks as time permits.  Has three years not been enough to address these attacks?  One would be hard pressed to make that case.  

The decision to pay is a business decision.  However, the decision to accept or assign the risk, rather than resisting or mitigating the attack, that is a security decision.  It seems clear that our plans for resisting and mitigating are not adequate and that paying the extortion is simply encouraging more attacks.  

By now every enterprise should have a plan to resist and mitigate, on a timely basis, any such attack.  If an enterprise pays a ransom, then, by definition its plan to resist and mitigate has failed.  As always an efficient plan for resisting attacks will employ layered defense.  It will include strong authentication, "least privilege" access control, and a structured network or end-to-end application layer encryption.  The measures for mitigating will include early detection, safe backup, and timely recovery of mission critical applications.  "Safe backup" will include at least three copies of all critical data, two of which are hidden from all users and at least one of which is off-site.  "Timely recovery" will include the ability to restore, not simply a file or two, but all corrupted data and critical applications within hours to days.  (While some enterprises already meat the three copy requirement, few have the capability to recover access to large quantities of data in hours to days, rather than days to weeks.)

One last observation.  If there is ransomware on your system, network, or enterprise, you have first been breached.  Hiding your data from you to extort money, is only one of the bad things that can result from the breach.  If one is vulnerable to extortion attacks, one is also vulnerable to industrial espionage, sabotage, credential and identity theft, account takeover and more.  The same measures that resist and mitigate ransomware resist and mitigate all of these other risks.

Ransomware attacks will persist as long as any significant number of victims choose to pay the ransom, as long as the value of a successful attack is greater than its cost.  The implication is that to resist attack one must increase its cost, not simply marginally but perhaps by as much as an order of magnitude.  Failure to do so is at least negligent, probably reckless.  Do, and protect, your job.  

On "Patching" III

One cannot patch to a secure system.

The rate of published "fixes" suggests that there is a reservoir of known and unknown vulnerabilities in these popular products (e.g., operating systems, browsers, readers, content managers). No matter how religiously one patches, the products are never whole.

They present an attack surface much larger than the applications for which they are used and cannot be relied upon to resist those attacks.  However, in part because they are standard across enterprises and applications, they are a favored target.  

They should not be exposed to the public networks. Hiding them behind firewalls and end-to-end application layer encryption moves from "good" practice to "essential."

Patching may be mandatory but it is expensive, a cost of using the product.  

The Universal Serial Bus

This weekend there was a report out of Mar-a-Lago that a Chinese national had been apprehended while trying to enter this resort while carrying a laptop, 4 mobiles, and a USB thumb drive containing malicious software.  While thumb drives are an efficient attack vector, where the attacker has physical access to a computer, we continue to hear reports of people surprised at how easy it is.  

It is important to decode, to understand, “USB.” It stands for “Universal Serial Bus.” “Universal” refers to the standard; thousands of different devices employ the standard for interoperability. It is a standard interface but it is more than that. It attaches to the bus of the host device as peer with processors, memory, and other external input/output devices. The standard provides for the device to contain executable software to facilitate its attachment to and interaction with the host device.  Think of it this way; any device attached to the bus is logically an internal, not external, device.  

Like many standards, this one is popular, in large part, because it is convenient.  It is an open interface for attaching cameras, scanners, printers, speakers, microphones, head sets, monitors, and storage devices.  As is often, not to say usually, the case, convenience trumps security.  Any control that limited the attachment, i.e., was more secure, would make it less convenient.

It is a privileged form of attachment; no authentication, no cryptography, no control. It is subject only to physical access control. Simply plugging a USB “thumb drive” into the bus of another device is sufficient to alter the fundamental operation of, not to say corrupt, that device in, perhaps, as little as tens of seconds. As we have seen, compromise of a single device on a network may reduce the cost of attack against all other devices on that network.

Since most, not to say all, personal computers expose their bus via the USB standard, it is essential to prevent unauthorized physical access to all such computers.   (Indeed the interface is so ubiquitous and so vulnerable that some security professionals advocate filling the port with superglue.  This measure should be considered for sensitive systems and applications and hostile environments.)  

  

Internet Vulnerability

On March 24, 2017 Gregory Michaelidis wrote in Slate on "Why America’s Current Approach to Cybersecurity Is So Dangerous."

He cited an article by Bruce Schneier.

In response, I observed to a number of colleagues, proteges, and students that "One takeaway from this article and the Schneier article that it points to is that we need to reduce our attack surface.  Dramatically.  Perhaps ninety percent.  Think least privilege access at all layers to include application white-listing, safe dcfaults, end-to-end application layer encryption, and strong authentication."

One colleague responded "I think one reason the cyber attack surface is so large is that the global intel agencies hoard vulnerabilities and exploits..."  Since secret "vulnerabilities and exploits" account for so little of our attack surface, I fear that he missed my point.

While it is true that intelligence agencies enjoy the benefits of our vulnerable systems and are little motivated to reduce the attack surface, the "hoarded vulnerabilities and exploits" are not the attack surface and the intel agencies are not the cause.  

The cause is the IT culture. There is a broad market preference for open networks, systems, and applications. TCP/IP drove the more secure SNA/SDLC from the field. The market prefers Windows and Linux to OS X, Android to iOS, IBM 360 to System 38, MVS to FS, MS-DOS to OS/2, Z Systems to iSeries, Flash to HTML5, von Neumann architecture [Wintel systems] to almost anything else.  

One can get a degree in Computer Science, even in Cyber Security, without ever even hearing about a more secure alternative architecture to von Neumann's [e.g. IBM iSeries. Closed, finite state architecture (operations can take the system only from one valid state to another), limited set of strongly-typed (e.g., data can not be executed, programs cannot be modified) objects, single level store, symbolic only addressing, etc.)]

We prefer to try and stop leakage at the end user device or the perimeter rather than administer access control at the database or file system. We persist in using replayable passwords in preference to strong authentication, even though they are implicated in almost every breach. We terminate encryption on the OS, or even the perimeter, rather than the application. We deploy user programmable systems where application only systems would do.  We enable escape mechanisms and run scripts and macros by default.

We have too many overly privileged users with almost no multi-party controls. We discourage shared UIDs and passwords for end users but default to them for the most privileged users, where we most need accountability. We store our most sensitive information in the clear, as file system objects, on the desktop, rather than encryptied, in document management systems, on servers. We keep our most sensitive data and mission critical apps on the same systems where we run our most vulnerable applications, browsing and e-mail. We talk about defense in depth but operate our enterprise networks flat, any to any connectivity and trust, not structured, not architected. It takes us weeks to months just to detect breaches and more time to fix them.  

I can go on and I am sure you can add examples of your own. Not only is the intelligence community not responsible for this practice, they are guilty of it themselves. It was this practice, not secret vulnerabilities, that was exploited by Snowden. It is this culture, not "hoarded vulnerabilities and exploits," that is implicated in the breaches of the past few years. It defies reason that one person acting alone could collect the data that Snowden did without being detected.  

Nation states do what they do; their targets of choice will yield to their overwhelming force. However, we need not make it so easy. We might not be able to resist dragons but we are yielding to bears and brigands. I admit that the culture is defensive and resistant to change but it will not be changed by blaming the other guy. "We have seen the enemy and he is us."

The Role of Risk Assessment in Digital Security

The very idea of Risk Assessment has always been controversial.  I have been engaged in the controversy for fifty years. My ideas on the subject are well considered if otherwise no better than anyone else's.  I record them here.

I attribute the application of this idea to what was then called Computer Security to my mentors, later colleagues, Robert H. Courtney, Jr. and Robert V. Jacobson.  They did it in an attempt to rationalize decision making, more specifically the allocation of scarce security resources, to the then nascent field.  They did it in response to their observation that many, not to say most, security decisions were being made based upon the intuition of the decision maker and their belief, and a tenet of this blog, that security is a space in which intuition does not serve us well.  They wanted to bring a little reason to the process.

They could not possibly have known that in a mere fifty years that the resources applied to this effort would grow to the tens to hundreds of billions of dollars, that the safety and liberty of the individual, the health of public and private enterprise, the efficiency and resilience of our economy, and the security of the nations would turn on how effectively and efficiently we used those resources.  

So, at its core risk assessment is a decision making tool.  It is a tool that we use to answer the question "where to spend the next dollar of our limited resources?"  Courtney's Second Law says one should "Never spend more mitigating a risk than tolerating it will cost you." We will, do, make this decision, with or without tools.  We make it intuitively or we make it rationally but we do make it.  

At its most elaborate risk assessment is a very expensive tool requiring significant knowledge, skill, ability, and experience to use, more than most of us enjoy.  It should be used only for expensive decisions, decisions that are expensive to reverse if we get them wrong.  At its simplest, it protects us from making decisions based solely upon the threat, attack, vulnerability, or consequence de jour.  It protects us from intuition, from fear.

All that said, few of us are confronting expensive or difficult decisions, decisions requiring sophisticated decision making tools, risk assessment or otherwise..  We have yet to implement all those measures that we know to be so effective and efficient as to require no further justification.  They are what Peter Tippett calls essential practices.  Anyone can do them, with available resources, they are about 0.8 effective but work synergistically to achieve an arbitrary level of security. They fall in that category that we call "no brainers."  All we need is the will.  

Exploiting the Rational Attacker

Attackers are often portrayed as irrational, fundamentally evil, or even demonic. They do what they do without regard to the damage that they may do. This is particularly true of amateurs doing mischief. They are simply unable to appreciate the value of public trust and confidence and the cost of the damage that they may do to it.

However, while one would not argue that rogue hackers understand that even they have an interest in an orderly world, one may argue that, at least collectively and across time and events, even they are rational. In the short run, they may underestimate the cost of attack and over-estimate the value of success, they may spend more than they gain. However, they will not do so over and over again. While an angry individual may deliberately spend more to damage another, than any psychic value to himself or even the cost of the remedy to his victim, there is some cost that will deter him, that he is unwilling or unable to pay.

Given two attacks to achieve a particular value of success, at least collectively, attackers will choose the cheaper of the two.

None of this is to suggest that the rogues are any better at estimating cost and value than any of the rest of us. They make their decisions in a "market" like the rest of us. However, within our tolerance for risk, our estimates of his cost of attack and value of success provide us with a guide for our spending on security. To the extent that we believe that his value of success is higher than his cost of attack, we should increase the cost of attack. We call that "security."