Thursday, March 8, 2018

The Use of SMS for Strong Authentication

NIST and others have discouraged the use of SMS for strong authentication.  This is another case of the perfect as the enemy of the good. 

First, strong authentication using a one time password sent via SMS is dramatically more secure than a replayable password. Second, if you get a one-time password when you ask for it, you are safe.

The problem is not so much with SMS but with the (cell) phone number. There is a risk that an attacker can either change the number in your account, to which the one time password will be sent, to a number other than yours, or get the phone company to associate, re-assign, your number with their phone. In either case, you will not get the one time password when you ask for it. In the latter case, you will not even get phone calls. Whenever the cell phone number in your profile is changed, you will get an e-mail message asking you if you really did it.

Carriers have controls in place to resist fraudulent reassignment of numbers to new phones.  However, the large number of agents and their desire to be accommodating, makes them vulnerable to ”social engineering” attacks. 

The difference in risk between a one-time password sent to your phone and one generated on board is small, particularly when compared to the difference in risk between either and a reuseable password.

In certain circumstances, the difference in convenience may be great. I have ten different accounts associated with my cell phone number. If I get a new phone, all my accounts continue to work as they did on the old phone. The number has moved to the new phone. If I used an on-board password generator, not portable to the new phone, I would have to register the new password generator with each of the ten accounts. I have to do that by calling support, authenticating myself, and registering the new generator. Until I have done that, I cannot logon to or use the account.

If you think about it, the real risk is in provisioning of the phone number or the registering of the on board generator (e.g., VIP Access, Google Authenticator, RSA SecurID Software Token). 

Wednesday, February 21, 2018

Law Enforcement vs. Security and Privacy

A recent report quoted the Director of the FBI as complaining that he had more than 7000 mobiles for which he has established probable cause to believe contain evidence of a crime, but that their security is so good that he cannot be sure.  Well, perhaps his emphasis was different than mine but you get the gist.

Of course, a decade ago he did not have any.  The modern mobile has given him a rich source of evidence that he has never had before.  Instead of saying ”thank you,” he complains that the source is not even richer than it is.  He neglects to say how many mobiles that he has opened while finding the few that he cannot. He neglects to address what percentage of those contained useful, much less admissable, evidence of crimes, a number that might give us some idea of any probative value of the contents of the 7000.

What he is really complaining about is that the default security of these devices raises his cost of investigation. He does not even speak to the resistance to crimes against the tens of millions of legitimate devices, users applications, data, and information that that security provides. Therefore, he cannot even get to the idea that in the absence of such security, there would be fewer devices, users, and applications, much less that his rich source of evidence might not even exist.

He argues that, in order to reduce his cost, the default security of the devices should be reduced.  In spite of all the testimony against this proposition, and the absence of any in its favor, he argues that the purveyors of the mobiles can reduce his cost while maintaining the security against all others.  Without specifying what would satisfy him, he argues that this is simply a small technical problem that the industry can solve any time it wants to.

While the Director talks in terrms of  ”capability,” that he does not have, I talk in terms of  ”cost.”  I assert that if one has a cryptogram, the method, and the key, all of which are on the mobile device, then, at some price, one can recover the clear text. Depending upon the design of the device, the cost may be high but it is finite.  The Bureau demonstrated this for us in the San Bernardino case. After asserting that Apple could, but that they could not, they turned to the Israelis, who for a  million dollars, recovered the data.  Incidentally it proved to be worth considerably less; it provided neither evidence nor intelligence. On the other hand, on a wholesate basis, the cost per device would be significantly less.

One problem is that, whatever the cost, the Bureau prefers to transfer it to the purveyor and the user than to just pay it. It hopes to do this by sowing enough fear, uncertainty, and doubt that a law and order Congress will pass coercive legislation forcing the uninvolved and unwilling to become arms of law enforcement.  If the purveyor is coerced into reducing the security, i.e., a value, of his product, he will lose sales and profit. Remaining users will lose security and privacy, experience costly breaches, and incur costs for compensating controls. 

The net is that, while the Director may not be able to read every mobile for which he has a warrant, he can read most of them.  While he knows what he cannot read, he bears the burden of proof that reading it would yield evidence or intelligence; he has the data, he must share.  We are not talking about cryptography in general but only about the security of mobile devices.  We are not talking about capabitlity but cost.  Not so much about how much as about who will pay; will we pay by taxation on all or coercion of a few?  The Director may have a case, but he has not made it yet.

Tuesday, February 20, 2018

Budget for the Cost of Losses

One idea of security is to minimize the total of the cost of losses and the cost of security measures.  However, it is easier to measure the cost of security measures than that of losses.  This may make it difficult to justify the cost of security measures.

While historically we have had only anecdotal data about losses, thanks to our rapidly increasing scale, laws requiring disclosure of breeches, and open source intelligence reports like the Verizon Data Breech Incident Report, we know a great deal more. 

I had one Fortune One Hundred client that budgeted for losses at the level of a line of business.  While the first year was little more than a guess, a decade later they have confidence in their numbers and have pushed them to smaller business units.  Just putting the line in the budget has caused the collection of actual data. 

The security staff uses the budget and actual figures to justify the cost of security measures.  Performance against budget allows them to assess their risk analysis and management program; losses are inevitable but are they greater or less than our expectation. 

Business unit managers use the numbers to make decisions about security measures and to negotiate with information technology.  They manage the cost the same as any other.  As with any other expense, the budget tells them the level of losses that higher managment has accepted. 

Budgeting for the cost of losses makes this expense peer with other expenses and subject to the same effort and control as other expenses.  It puts the responsibility on the line of business where it belongs,  It moves us one step closer to professional security based on data rather than on intuition. 

Wednesday, November 29, 2017


In 2008 the ACM sponsored a Workshop on the Application of Engineering Principles to Information System Security.  Participants were asked to submit brief notes as seed material for the Workshop.  Far and away the most useful paper submitted to the workshop was by Amund Hunstad anJonas Hallberg of the Swedish Defence Research Agency entitled “Design for securability – Applying engineering principles to the design of security architectures.” This original paper points out “that no system can be designed to be secure, but can include the necessary prerequisites to be secured during operation; the aim is design for securability.” That is to say, it is the securability of the system, not its security, which is the requirement. We found this idea to be elegant, enlightening, and empowering. Like many elegant ideas, once identified it seems patently obvious and so useful as to be brillant.

One cannot design an airplane to be safe, such that it can never be unsafe, but one can, indeed aeronautical engineers do, design them such that they can be operated safely.  Neither IBM nor Microsoft can design a system that is safe for all applications and all environments.  They can design one that can be operated safely for some applications and some environments.  As the aeronautical engineer cannot design a plane that is proof against ”pilot error,” so IBM and Microsoft cannot design a system that is proof against the infamous ”user error.”  One cannot design a plane that is proof against terrorism or a computer that is proof against brute force attacks.

In the early days we talked about the properties of secure systems, Integrity, Auditability, and Controllability, and we told product managers that the properties, features, and functions of the product must be appropriate for the intended application and environment of the product. 

Integrity speaks to the wholeness, completeness, and appropriateness of the product.  One test of Integrity is predicability, that is the product does what, and only what, is expected.  Note that very few modern computer systems meet this test, in large part because they too complex. 

Auditability is that property that provides for relative ease in inspecting, examining, demonstrating, verifying, or proving the behavior and results of a system.  The tests for Auditability include accountability and visibility or transparency.  The test of accountability is that it must be possible to fix responsibility for every significant event to the level of a single individual.  The test of visibility is that a variance from the expected behavior, use, or content of the system must come to thattention of responsible management in such a way as to permit timely and appropriate corrective action. 

Controllability is that property of a system that enables mamnagemrnt to exercise a directing or restraining influence over the behavior, use, or content of the system.   The tests are Granularity and Specificity.  The test of granularity requires that the size of the resource to be controlled must be small enough to permit management to achieve the intended level of risk.  Specificity requires that management be able to predict the effect of granting any access to any resource, privilege, or capability from the meta-data, e.g., name, properties, of the resource, privilege or capability. 

Note that these properties compliment one another, indeed are really simply different ways of looking at the property of ”securability.”  However, they may be achieved at the expense of other desiderata of the system.  How to achieve the proper balance is the subject for another day. 

Monday, October 23, 2017

Security as Infrastructure

When I began in computers it was really fun.  I was hired as a "boy genius" at IBM Research.  We had the best toys.  I had my own IBM 650.  I was paid to take it apart and put it together again.  How great is that?  I got to work with Dr. Albert Samuels who was programming the IBM 704 to play checkers.  My colleague, Dick Casey, and I programmed the 650 to play Tic-Tac-Toe.  We had to use it on third shift but we even had a third of an IBM 705 where we installed the first Autocoder in Poughkeepsie.  I drove my transistor radio with a program on the IBM 1401.  

That was just the beginning. For sixty years I have had the best toys. I have five PCs, I am on my fifth iPhone, and my fourth iPad.  I carry my sixty years of collected music and photographs, an encyclopedia, a library, and dozens of  movies in my pocket.  It just keeps getting better. It is more fun than electric trains.

One of my favorite toys was the IBM Advanced Administrative System, AAS, five IBM 360/65s and a 360/85.  It was so much fun that I often forgot to eat or even go home at night.  However, on AAS one of my responsibilities was to manage the development of the access control system.  It was great fun to do and fun to talk about.  Serious people came to White Plains to hear me.  I was invited to Paris, Vienna, Amsterdam, London, Helsinki, and Stockholm to talk about my fun and games, about how we provided for the confidentiality, integrity, and availability of our wondrous system.  

However, as seems to happen to us all, I grew up, and finally old.  My toys, fun, and games became serious.  Some place along the way, most of the computers in the world were stitched together into a dense fabric, a network,  into a world-wide web.  While still entertaining, this fabric had become important.  It supports the government, the military, industry, finance, and commerce.  

Without any plan or intent, driven mostly by a deflationary spiral in cost and exploding utility, the fabric had become infrastructure, part of the underlying foundation of civilization.  It had become peer with water, sewer, energy, finance, transportation, and government.  Moreover, it had become THE infrastructure, the one by which all of the others are governed, managed, and operated.  

We build infrastructure to a different standard than toys or anything else not infrastructure.  Infrastructure must not fall of its own weight.  It must not fall under the load of normal use.  It must not even fall under easily anticipated abuse and misuse.  In order to prevent erroneous or malicious operation, the controls for infrastructure are reserved to the trained operators and from the end users.  

No special justification is required for this standard. The Romans built their roads, bridges, and aqueducts, such that. with normal maintenance, they would last a thousand years.  And so they have.  The Hoover Dam and the Golden Gate Bridge were built to the same standard.    With normal maintenance, and in the absence of unanticipated events, they will never fail.  (They may be decommissioned but they will not fail.)  No one quibbled with Henry Kaiser over the cost or schedule for the dam.           

However, our fabric was not driven by design and intent but by economics.  No technology in history has fallen in price and grown in power as fast as ours.  While we tend to think of it in terms of its state at a point in time. it continues to grow at an exponential rate.  Its importance can hardly be appreciated, much less over-stated.

Given the absence of design and intent, it is surprisingly robust and resilient.  While not sufficient for all purposes to which we might wish to put it, it is sufficient for most.  With some compensating design and intent, it can be made sufficiently robust for any application.  

One word on "easily anticipated abuse and misuse."  On September 12, 2001, what could be easily anticipated had changed forever.  

As security people, we are responsible for the safe behavior, use, content, configuration, and operation of infrastructure.  As IT security people, we are responsible for the only international infrastructure, the public networks.  As users, we are responsible for not abusing, misusing, or otherwise weakening it.  

Note that ours is the only infrastructure that, at least by default, contains weak, compromised, or even hostile components and operators.  It is the only one that, by default, has controls intended for the exclusive use of managers and operators right next to those for end users.  Our infrastructure also, by default, connects and exposes the controls of other infrastructure to most of our unprivileged users.  It is our job to compensate fro and remediate these conditions.

Our roles, responsibilities, privileges, and special knowledge give us significant leverage over, and responsibility for the infrastructure of our civilization.  Everything that we do, or fail to do, strengthens or weakens that Infrastructure.  That is why we are called professionals and are paid the big bucks.  

Friday, October 20, 2017

MasterCard to Eliminate Signatures

MasterCard has announced that in the US and Canada, it will no longer require signatures on credit card transactions.  (PINs will continue to be required on debit card transactions.)   MC says that this will be more convenient for the customer and that it will rely on other (unnamed) mechanisms and processes for security.  Let us look at some.

First, many issuers use computer aided mechanisms to detect fraudulent use by looking at such clues as location and other patterns of use.  Most of us have had calls from our banks checking on the legitimacy of activity.

In theory, the required signature resists fraudulent use of lost or stolen cards.  In practice, not so much.  Even when clerks reconciled the signature on the check to the one on the card, it was an imperfect mechanism.  In modern systems, where no one really reconciles the signature, the best that the mechanism can do is to permit the consumer to recognize disputed items that he really did sign. However, for the most part, issuers simply accept the word of the consumer that a transaction is fraudulent.  The signature does not come into play. 

The best way to resist the fraudulent use of lost or stolen cards is to check that a proffered card has not been reported lost or stolen.  This works well in the US and Canada, where most transactions take place on line.  In countries where many transactions take place off line, PINs are used. 

American Express CEO, Kenneth Chennault told President Obama that Am Ex detects many fraudulent transactions within 60 seconds by sending a notification of use to the consumer’s mobile or e-mail in real time. 

Bank of America and others resist fraudulent use by permitting the consumer to turn the card on and off using an app.  Again, works well where most transactions are on line. 

Android, Apple, and Samsung Pay resist fraudulent use by simply taking the card out of the transaction and substituting a digital token for the credit card number.  Lost mobile phones resist fraudulent reuse with PINs for security and biometrics, e.g. facial and fingerprint recognition, for convenience. 

On line merchants have never had the benefit of signatures but  can resist fraud by using PayPal or other proxies instead of accepting credit cards at check out.  Where the merchants cooperate and the consumer uses √Āmerican Express at checkout, AmEx will prompt the user for a one-time-password sent to the users mobile.  This protects the merchant, the consumer and AmEx.  All of these resist “card not present” fraud. 

Only the brands and issuers really know how necessary and effective signatures and PINs are: they take the risk when they are not required.

The fundamental vulnerability in the retail payment system is the credit card number in the clear on the magnetic stripe.  Remains a risk to merchants and issuers but is only a nuisance to the consumer. 

In short, the future is mobile, tokenized, cordless, contactless, signature and Pin less, and secure. 

Wednesday, October 18, 2017

The Internet as Infrastructure

Today, when one connects an application, system, or network to the public networks, one is adding to the "system of public works," that is to "infrastructure," of the nation and the world. 

The standards for building infrastructure, such as bridges, tunnels, and dams, are different from those for other artifacts.  Infrastructure must not fall of its own weight, it should not fail in normal use or under normal load, and must resist "easily anticipated abuse and misuse."  A suspension bridge must not fall because a driver falls asleep and an eighteen wheeler goes over the side.

Notice that the abuse and misuse that can be easily anticipated today, is much worse than when we began the Internet.  Were it not so, we might have done many things differently.

We call the resultant necessary property of infrastructure resiliency, rather than security, but the properties are related.

For any artifact, there are limits to the complexity, scale, load, and simultaneous component failures that the mechanism can be expected to survive. How many simultaneous sleepy drivers and plunging eighteen wheelers must a bridge be designed to survive.

When those limits are reached, what we want to happen is that the mechanism fail in such a way that damage is limited and the mechanism can be restored to operation as quickly as possible.

The three Great Northeastern Blackouts, of which August 14, 2003 was the latest, are examples. It is interesting that engineers see these blackouts as successes while the public and their surrogates, journalists and politicians, see them as failures.

All three were caused by multiple simultaneous and cascading component failures under conditions of heavy load. In all three cases the system failed in such a way that it was restored to a ninety percent service level in a day. While all three were spectacular and exciting, the damage was not nearly so severe as one might expect from a major ice storm.

This is the way that we would like the public networks to fail. In fact, so far, that is what we have seen. We have had massive local failures of the PSTN where it took days to weeks to restore to a ninety percent service level. Most of these were fire related and local. We have had one that was national and caused by a software change. We recovered from this one in hours.

To date, we have had a number of local failures of the Internet, all man-made (mostly caused by the infamous "cable-seeking backhoes or boat anchors"); most were accidental. We recovered from all of these in days. SQL/Slammer was man-made, malicious, and software related; it caused a noticeable drop in service for hours. However, there was not really a discontinuity of service.

It should be noted that SQL/Slammer was a homogenous attack.  That is, every instance of it looked the same.  This made it relatively easy to construct and deploy filters that would resist its flow while not interfering with normal traffic.  However, it is fairly easy to visualize a heterogeneous attack that might overwhelm this remedy.

So, there is wide-spread concern that there might be a malicious software-based attack that would bring down the entire Internet. To some degree this is angst, an unfocused apprehension rooted in intuition or ignorance.  However, it is shared by many who are knowledgeable.  Their concern is rooted in the (often unidentified and un-enumerated) facts that:

* the Internet evolved; it was not designed and deployed
* switching in the network is software-based,
* operation of the components is homogenous
* operation of network management controls is in-band
* users often have default access to management controls
* the topology is both open and flat
* paths in the network are ad hoc and adaptive
* connection policy is permissive,
* most of the nodes in the network are un-trusted and a large number are under malicious control.
* access is open and cheap
* identity of both components and users is unreliable
* ownership and management is decentralized
* other

If the impact of these things on the resiliency of the Internet were as obvious prospectively as it is retrospectively, we might have done things differently.  On the other hand, we might not have.  A little discussion is in order.

Unlike the PSTN, the Internet is packet, rather than circuit, switched.  The intent of this was to make the network more resilient in the face of node or link failures.  

The routers and switches may be software running on von Neumann architecture general-purpose computers.  This may make the network more resistant to component failure while making the components more vulnerable to malicious attack.  

We have become accustomed to the idea that software processes are vulnerable to interference or contamination by their data, i.e., the software in the switch can be contaminated by its traffic.  This exposes us to attacks intended to exploit, interfere with, or take control of switches and routers. 

This may be aggravated by the fact that so many routers and switches look the same.  While there are hundreds of products, most of them present controls that are operated via the Border Gateway Protocol (BGP).  An attack that can take control of one might be able to take control of many.   

Even most non-switch nodes in the network look the same, that is, like Windows or Unix (rather than, for example, MVS or OS/400.)   These two operating systems are open, historically broken, and have a commitment to backward compatibility that makes them difficult to fix.  Historically they have shipped with unsafe defaults and have been corrupted within minutes of being connected to the Internet.  The result has been that there are millions of corrupt nodes in the Internet that are under the control of malicious actors.

Operation of the routers and switches (and other network nodes) is via the network itself; they can be operated from almost any node in the network.  Many are hidden, if at all, only by a password, often weak or even default.  Thus, it might be possible to coordinate simultaneous mis-operation of many nodes at the same time. 

The Internet is open as to user, attachment, protocol, and application.  The cost of a connection to the Internet is a function of the bandwidth or load but the cost of a relatively fast persistent connection is in the tens of dollars per month, about the same as a dial connection a decade ago.  

While one must demonstrate the ability to pay, usually with a credit card, the credit card may be stolen, and, depending on the provider, the name in which the connection is registered may not have to be the same as that on the credit card.  In short, almost anyone can add a node to the Internet with minimal checks on their identity or bona fides.  There will be bad actors. 

The only thing that is required to add a new protocol or application to the Internet is that at least two nodes agree on it and that it can be composed from IP packets.  Use of load-intensive protocols and applications for streaming audio and video were added to other protocols and applications with no changes to the underlying infrastructure.  We have seen DoS attacks that relied upon minor changes to protocols and their use.

At least in theory, the topology of Internet is "flat," as opposed to structured or hierarchical.  That is, at least in theory and with few exceptions, any node in the Internet can send a packet to any other node in the Internet.  The time and cost to send a packet between any two nodes chosen at random is roughly the same as for any other pair of nodes.  

Said another way, both the time and cost to send a packet are independent of distance.  One implication of this is that attacks are cheap, can originate anywhere, and can attack anything attached. 

Paths in the Internet are determined late, possibly on a packet by packet basis, and adapt to changes in load or control settings.  The intent is that there be so many potential paths between A and B that at least one will always be available and that it will be discovered and used.  While the intent is to make the network resistant to node and link failures, an unintended consequence is that it is difficult to resist the flow of attack traffic. 

The original policies of the Internet were promiscuous (as opposed to permissive or restrictive); not only was any packet and flow permitted but there were no controls in place to resist them.  This was essential to the its triumph over competitors like SNA and may have been necessary to its success.  

While controls have been added as the scale has grown, the policy is still permissive, rather than restrictive, i.e., everything is allowed that is not explicitly forbidden.  

Said another way, all traffic is presumed to be benign until shown otherwise.  Attack traffic can flow freely until identified and restricted.

Finally, while most of the nodes in the Internet are un-trusted, and we know that many are corrupted and under hostile control, all are given the benefit of the doubt.  To date there has been little effort to identify and eliminate those that have been corrupted.  Therefore there remains a possibility that these corrupt systems can be marshaled in such a way as to deny the use of network to all, or some targeted group, of users. 

The Internet is robust, not fragile.  It is resistant to both natural and accidental artificial events.  However, To the extent that the above things are, and remain, true, the Internet, and indirectly, the nations, economies, institutions and individuals that rely upon, it are vulnerable to abuse and misuse; concern is justified, if not proportionate.  

While these characteristics are pervasive and resistant to change, while they were often chosen for good reason, they are not fixed or required and can be changed.  Understanding them and how they  might be changed is key to making the Internet as resistant to abuse and misuse as it is to component failure or destruction. 

It suggests that the network must become both less open, not to say, closed, and more structured. The management controls must be protected and taken out of band.  The policy must become much more restrictive.  We must identify our users and customers and hold them accountable for their traffic.

To bring the Internet to infrastructure standards, we must overcome not only inertia but also culture.  Each of us must exercise our influence on our  employers, clients, and vendors to move the Internet to the same standards that we expect of skyscrapers, bridges, tunnels, and dams.  Since there is no one else to do it, we are called professionals and are paid the big bucks.