Experi-Metal vs. Comerica Bank

Last week we talked about the Patco vs. Ocean Bank dispute that arose from a "corporate account takeover." Incidentally, the media calls these ACH fraud but the role that the ACH plays is limited. While it speeds up the fraud, its rules provide for reversibility of transactions by default. The real problem is S.W.I.F.T. where the rules do not provide for reversibility by default. ACH works like checks, S.W.I.F.T. like cash.

We were hardly off the air before reports began to come out about a decision in Experi-Metal vs. Comerica Bank. While some of the facts are similar, in this final judgment, the court found for the customer. As the decision is different, and while last week's lessons still hold, there are new lessons here. We might as well, we might do well to, get them on the record.

In this case, the court has come down firmly on the side of the common law principle that banks are responsible for ensuring that transactions are properly authorized and to bear the cost of fraud.

However, what is important to us is that the trial rips open the kimono. We get to see the forensics. We get to see what we can never see in any other context. We get to see which controls were in place and which not. We get to see which ones worked and which ones failed.

As in Patco, Experi-Metal's banking credentials were compromised. However, in this case their machine was not compromised. Rather an officer responded to a bait message that appeared to come from Comerica, led them to a counterfeit of Comerica's web-site, where they compromised their credentials by using them to log on to the perpetrators system.

At one level this was simple a spoofing attack. It is not quite a man-in-the-middle attack but we have seen these. It was also a replay attack. Replay of the credentials would have been resisted by the token-based or out-of-band authentication that we discussed last week.

Press reports suggest that the criminals immediately began to transfer money, via Comerica's correspondent, JP Morgan Chase, to accounts in Russia and Estonia. After about four hours, Chase had identified the transactions as fraud candidates and notified Comerica. Comerica then disabled the compromised credentials but failed to terminate the continuing on-line session so the transfers continued for another two and a half hours.

Now, contrary to the popular and journalistic view, it is not only permissible but efficient to rely upon the controls of third parties to detect anomalous, not to say, fraudulent, activity. However, if I were the judge in this case, I would surely have asked myself why Chase was the first to recognize this activity as fraudulent.

In the early days of on-line banking, banks did not permit same-day transfers to arbitrary accounts. The destination account had to be setup in one step, confirmed in-band to the destination account, and out-of-band to the origin. Only then, perhaps several days later, could the transfers take place.

I was reminded of this while at Deloitte. A client, a private bank in Bermuda, questioned this control. The question was referred to me. It seems that some of the large depositors of this bank were asking to be able to make same-day transfers to new accounts. The bank wanted to find a way to accommodate them.

I suggested to them that there were alternative or compensating controls that they could employ, rather than the one that was then standard. For example, when a customer wanted to make a same-day transfer, the bank could involve an officer to approve and permit the transaction. The officer could confirm the transaction with the customer, out-of-band, by phone, e-mail, fax or combinations thereof. Because this is an expensive control, I suggested that the bank might want to have thresholds below which the control would not be invoked. However, clearly they should be invoked for the top ten percent of all transactions.

Indeed, if one is to believe the reports of this case, there were at least half a dozen things about this fraudulent activity that might have triggered alarms. The transactions were both numerous and novel, more than 90 transactions against an account that usually had a zero balance and had not had any in more than a year. They were same-day transfers to unconfirmed accounts. They were made using credentials that had never been used for that activity before. They represented a material portion of Experi-Metals deposits, and indeed of their net worth. They generated $5million in overdraft charges. The judge took that last one as evidence that the bank was not acting in good faith.

Part of what Chase picked up on was that, while the transactions into their accounts were Automatic Clearing House, ACH, transactions, funds for which Chase's customer was liable. Chase's customer was then forward wire transferring the funds, via S.W.I.F.T. , to foreign banks, from which recovery would not be automatic, perhaps not easy or even possible. It is not clear whether Comerica would have permitted transfers direct to such banks.

Last weeks lessons are still necessary but not sufficient. What are the new lessons here?

New lessons for the customer include always initiate connections to your bank in the same way, never by clicking on a link in an e-mail message. Always satisfy yourself that you are connected to your bank by recognizing your balance and recent activity. Be sure that the connection is properly encrypted by checking the browser "lock," the url, and, at least now and then, the SSL certificate.

An analyst at the Gartner Group has suggested that while bank controls are better now than in 2009, there is still room for improvement. New lessons in this case for banks should focus on policy, we protect and inform our customers, and back-room controls, the ones the have proved so successful in detecting credit card fraud. Their policy and controls must be based upon the assumption that, even with the best of intentions and training, some of their customer's credentials will be compromised.

We do not know how many successful corporate account takeovers have occurred, nor how most have been settled. What we do know is that more than half a dozen have resulted in suits against the banks. Perhaps that there are only a few such disputes can be taken as evidence that we are doing a better job for others than we have done for Patco, Experi-Metal, Ocean Bank, and Comerica but I would not bet on it.

We should not be as concerned with how the courts rule on these disputes, law and precedent will not make on-line banking safe, as with how well we serve our clients. It is no excuse to say that "we told them but they did not listen;" the failures in every profession say that. It is our job to ensure that our principles, banks or their customers, are not involved in such losses.

If we are to be worthy to be called professionals and get paid the big bucks, it is our job to recommend the appropriate controls and convince our principals to use them. In our professional development, we must work as much on our communication skills as on our technical ones.

Patco vs. Ocean Bank

The closely watched case of Patco vs. Ocean Bank is working its way through the courts. The most recent public event in the case is the recommendation of a court-appointed magistrate. If, as seems most likely, the court adopts the recommendation, it will be very good news for the banks and bad news for small business.

Patco was the victim of a Trojan Horse attack using software called Zeus. The attack enabled the perpetrators to compromise the Patco's banking credentials and re-play them to transfer Patco's funds to themselves and even to draw funds against Patco's line of credit with Ocean Bank.

The fundamental common law principle is that banks are responsible for ensuring that transactions are properly authorized and that they must stand the cost of fraud. As individuals, we all rely upon this rule. So far, at least for consumer on-line banking, the banks have honored this obligation both for deposit and credit card transactions.

However, over time this principle has been eroded and limited by legislation, regulation, and contract, designed to encourage responsible behavior on the part of bank customers, particularly business customers.

Patco argues it did not authorize the transactions in question and that the bank should reimburse them for the losses. The bank argues that Patco's credentials were used for the transactions and that, therefore, under its agreement with the bank, Patco is liable.

Patco argues that the security mechanism offered to it by Ocean bank was inadequate for the application and environment. It seems clear, both technically and from the events in the case, that the mechanism failed. That is not in dispute. Patco argues that stronger, if more expensive, mechanisms are available, that they would have protected Patco, and that Ocean bank should have used them.

However, the magistrate finds that the mechanism chosen by the bank, i.e., UID and password with challenge-response based on three shared secrets, complies with regulation, is widely used and was agreed to by Patco. The magistrate finds that, as a matter of law, banks are not required to provide the best mechanism.

The regulation in question requires "two-factor" authentication. While this includes token-based or out-of-band authentication, which clearly resist the replay of the customer's credentials, it also includes weaker mechanisms such as challenge-response based on a set of shared secrets.

Note that challenge-response does provide some resistance to re-play, at least until all the shared secrets have been compromised. The findings suggest that the bank increased the likelihood that all three secrets would be compromised by lowering the threshold for invoking them to $1-.

Moreover, a decision that turns on Patco's agreement to the mechanism assumes that it, or any bank customer is in a position to judge whether or not the offering is secure for his purposes. I would assert that that is unlikely, that it is far more likely that the customer relied upon the bank.

There is nothing in the report to suggest whether or not, in choosing its method, the bank contemplated a key-logger attack as was used here. It is far more likely that, as Patco relied upon the bank, the bank relied upon its service provider.

As in most disputes, in this case there is plenty of blame to go around. The bank chose a weak security mechanism. Then, relying upon intuition, rather than knowledge, weakened it further by lowering the threshold. Patco did use a Zeus-contaminated machine. While the bank clearly wants its customers to resist contamination, it should have assumed that across all of its customers, at least some would be compromised.

Bad cases make bad law. I hope that this case will be settled, rather than appealed, so that it does not establish an anti-customer precedent. The common law principle is well-founded and we have an interest is preserving it.

An update to the Federal Financial Institutions Examination Council authentication guidance is expected shortly. Leaks suggest that, while the guidance will encourage improvements, banks will continue to enjoy wide latitude, including the continued use of challenge-response. Rather than looking to the FFIEC for guidance on how to improve their security, most banks seem to be hoping that whatever they are doing now will continue to be permitted.

We should not be surprised that banks want to transfer to the customer as much of the responsibility for secure on-line banking as possible. Neither should we be surprised that they prefer regulations and standards that reserve to them the greatest possible flexibility and choice. The banks should not be surprised that we will use them and their services only to the extent that we believe that we are safe when we do so.

As security professionals, we should be advising our small business clients to 1) resist Trojan Horse attacks by using a dedicated and locked-down machine for banking, 2) resist re-play attacks by preferring banks that offer either token-based or out-of-band authentication, and 3) use on-line banking to their advantage by reconciling their accounts and activity daily.

We should be advising our banking clients that they can improve both their competitive and security postures by employing token-based or out-of-band authentication. In a world in which all adults and many children carry mobile computing devices, the convenience of these mechanisms is improving and the cost is falling.

Neither Patco nor Ocean Bank were well served by the security profession. We must do much better if we want to be called security professionals and get paid the big bucks.

Get Out of Jail Free

Would you like a "get out of jail free card" for security professionals? It is called the risk acceptance document.

The responsibility for the protection of enterprise assets lies with line management, not with the security staff. This is essential. The discretion to allocate and use a resource comes with the responsibility to protect it. The result is that line managers have the responsibility, not to mention the budget, but the security staff may have the knowledge.

When inevitably they disagree, the line manager usually does, and ought to, win. When inevitably things go wrong, the security professional takes the blame. The risk acceptance process establishes a more appropriate balance of power.

Additionally, security managers often complain that they are unable to get management to focus on what they consider to be critical issues. Sometimes, not to say, often, it is because the security staff has not yet articulated the options in a way that management can appreciate.

The risk acceptance process is a method to get the necessary focus. In it we simply ask management to "accept the risk," to sign a document that says that the staff has presented them with the risk and that they have elected to accept it rather than to mitigate it.

The security staff gets to write, or at least negotiate, the content and language of a

risk acceptance document. They describe the exposure, i.e., the threat, the vulnerability, and the consequences. They describe all the alternatives that were considered, including the one that they recommend, and that of doing nothing, i.e., accepting the risk. Management either mitigates or accepts. The line manager or executive gets to make the decision but also has to accept the responsibility. The process and the document ensure that the decision is memorialized.

Doing nothing, that is, accepting the risk, is only one of the alternatives. In many cases, after reading the risk acceptance document, the business executive will elect to accept the recommendation of the security staff instead of signing the document.

One effect of doing the necessary work to write the document is to ensure that the security staff has really considered all of the significant alternatives. Another is to focus the attention of the executive on the decision that only he can make.

When is a risk acceptance indicated? One answer is any time the security staff wants line management to make a decision. However, risk acceptances may arise in the context of a change in threat, a new technology, or a new application. For example, the enterprise wants to bring a new application on line in order to exploit a new technology or business opportunity. The developer and the security staff disagree on the quantity or quality of testing.

Another context in which risk acceptance may arise is that of a decision to deviate from regulations, policy, standards, or guidelines. To some extent regulations and policy, but particularly standards and guidelines are made to be broken. However, whenever for business reasons, a decision is made not to conform, the decision should be memorialized in a risk acceptance.

Finally, risk acceptance should be used to document residual risk. Since security is never perfect, there will be breaches and losses. For example, there is the risk that a user will take bait and contaminate the network, that a privileged user will go rogue or be suborned, or that the maximum number of simultaneous component failures will be exceeded. All of these should be documented If only to protect the management of fhe application and the security staff from charges of imprudence, residual risk must be documented.

Risk acceptances should be done before, rather than after, the auditors come. Auditors tend to treat any and all variances as of equal severity. Moreover, audits are as of a point in time. Once the auditors show up, it is too late to get out of jail free.

Recently, after mentioning risk acceptance as an essential security practice, I was challenged by a professional to give examples of language for describing the risk. After agreeing to try to provide examples in this week's talk, I realized that the language is the language of risk analysis or business impact analysis, language that we should all already be skilled in using.

The expression of the risk to be accepted is that of the relative risk between the recommendation and that of doing nothing, for example, between implementing early with one level of testing and cost and implementing late with more testing and other cost.

Of course, part of the cost in both cases, is the cost of losses. As always, these costs are difficult to predict with any precision. However, executives are accustomed to making decisions with imprecise data. Doing so is a necessary skill of all executives. When doing so, it helps to know how good or bad the data is.

What the executive asks of us is to carefully document our assumptions. Of course they want an annualized loss expectancy (ALE), but they also want to see the underlying assumptions about threat rate, vulnerability, and consequences. They understand that these numbers are difficult to arrive at but they can work with them as long as they understand how you got to them.

A risk acceptance has a limited life. It dies either with the expiration of one year, the tenure of the signing executive, or some agreed to but shorter period of time. At the end of a year, the decision must be revisited. If the signing executive moves on, all of the risks that he accepted must be submitted to his successor. The new executive may follow the lead of his predecessor or may not. Often, the risk may be accepted only for the period of time required to implement an alternative.

It is not always clear which executive should sign the risk acceptance. To some extent this is a matter of enterprise policy or culture. For example, some mature enterprises have strict limits of financial discretion assigned to levels of management. In others, the discretion of a manager may be established by his budget. In some, a manager may sign anything that she is willing to take the responsibility for. I recommend that a risk can only be accepted by an executive that has the authority, discretion, and resources to implement the alternative, that is to say yes, as well as no, to your recommendation.

Said another way, a manager may not accept a risk simply because he has no other choice. By definition, he who has no other option is not the right manager..

Note that this is just the way that staff works. No one has to authorize staff to present alternatives to management; that is what they are paid to do. They do not need any special authority to ask an executive to acknowledge that they have done so. Every now and then, an executive may simply refuse to sign the document. It really does not make any difference. One simply notes when and what options were presented to whom and puts the record in the file. If he does not mitigate, by definition, he has accepted.

This brings up the idea of "completed staff work." This is the idea that says decisions are presented to executives in a document that is so complete as to be self-implementing. The alternatives are so well described that when the executive signs it, without any further staff work, everyone knows what they are expected to do.

Writing risk acceptances is difficult. If often involves negotiation to arrive at language that all can agree fairly describes the choices and their associated risk. It may involve compromises to decide who should sign. That is why we are called professionals and are paid the big bucks.

On Trusting Systems

The idea of trusted systems is almost as old as shared resource computing. In fact, it arose in that context. It was all about being sure that data did not leak from one user to another or one class to another. Contamination of one user or process by another did not occur to anyone until we realized that preventing it was essential to preventing leakage. The story we told was how Roger Schell installed a Trojan Horse in Multics.

Today one issue is preventing leakage from one system to another. Our systems leak, at least in part, because they become contaminated. Contamination requires that the system do something, execute something, a program or a command. Sometimes they do this automatically as with a worm or virus. Sometimes because a user tells them to.

Another is preventing the exploitation of lost or stolen mobile devices. Of course, one way to do that is not to put sensitive data on mobile devices in the first place. On the other hand, there are applications where it might be nice to be able to put sensitive data on a mobile device if one had confidence that if it were lost or stolen the data would be safe.

What does it mean to say that a system is trusted? For a few decades I have cautioned people not to trust systems that they cannot carry and to prefer those they can put in their pockets. That recommendation relied upon the fact that such devices were shallow and simple. Ken Thompson, who received the Turing Award for writing Unix, asserted that unless one wrote it oneself, one cannot trust any computer system. Courtney argued that the question was only meaningful in the context of a specific application and environment. Peter Capek and I argued in a paper for the Irish Computer Society that, Thompson notwithstanding, we do in fact trust our systems.

I would argue that one useful test of trust is that of predictability. If for every input to the system, one can predict the output, for both the case when the system is performing correctly and the case where it is failing, that is a very useful test of trust. Of course, the more general, flexible, and functional the system, the more difficult the task of predicting. The issue is not so much a problem of getting the correct results as expressing and reconciling the prediction.

My favorite example of a trusted computer is Pac-Man. The owner of the system can trust Pac-Man. The user can also trust Pac-Man. It is single-user. It is single-application. The program is simple and obvious as to its intent. The behavior, use, and content of the machine is predictable. It is not user programmable. It is closed. The file system is hidden from the user. The operating system is hidden from the user. The user cannot insert arbitrary data or cause it to be executed. It is not connected to any network. It does not have any exposed input/output such as a disk drive or a thumb drive. It does not even have a key-board. As a result, it is stable. It does not get into unusual states. It does not have to be constantly maintained or "patched."

In computer science terms, the arcade game is an "object," an artifact that encapsulates and hides both its data and its methods.

Compare Pac-Man to your typical personal computer. Not the owner of the system, not the user, not anyone can predict what it will do, much less that it will not do forbidden things. The question is how much can we relax the properties of the arcade game before we loose trust? How much must we restrict the personal computer before we obtain necessary trust?

I trust my iPad and my iPhone. I trust iOS devices in ways that I do not begin to trust Windows systems or even OS X. First, it is an application-only machine. It is true that it can perform multiple applications but the abstraction, the "app," is of a single application at a time. Apple assures me that data cannot leak from one app to another and that an app cannot contaminate or interfere with another app.

Said another way, an app looks to me like the arcade machine. It is single user. It is simple and obvious as to its intent. The behavior, use, and content of the app is predictable. It is not user programmable. It is closed. The user cannot insert any arbitrary data, much less cause it to be executed. While the app can see its portion of the file system, it can see only its portion. The file system and the operating system are both hidden from the user. They are hidden beneath an owner chosen collection of apps, chosen from among a growing population of more than 300,000. Moreover, all of these apps and changes to them come to me from one place, a known source, Apple, in temper-evident packaging.

Unlike Pac-Man, the app can be connected to the Internet, at least as a client, but not as a server. However, the app can only access the network via an Apple provided application program interface or API. Unlike Windows or OS X, the iOS network policy is restrictive rather than permissive; one does not need an add-on firewall.

One might suggest that my trust of iOS and my iPhone or iPad relies heavily upon a trust of Apple, a level of trust that few of us have of Microsoft, IBM, or any other vendor. To some extent that is true. However, whatever trust I may place in Apple, is corroborated by four years of experience in which not one among tens of millions of users has reported a malicious program, leakage of data from one app to another, or contamination or interference of one app by another. Perhaps not quite as good as Pac-Man but sufficient for most of my purposes.

Like Pac-Man, and unlike other tablets, my iPhone and iPad do not have slots for SD storage cards or USB Ports, in part to resist data leakage or device contamination. While there is an SD card reader that can be attached to the proprietary Apple connector, its use is limited to importing photos.

Many of my peers, colleagues and contemporaries, clearly prefer more open devices. They want swappable storage. They do not want to be restricted to a single source of programs. They want to be able to write and execute their own programs. Openness has a value and some will choose it in preference to trust. To that class of users, Steve says "Get a Mac; get an Android. However, I will stick my neck out and predict that most new users will prefer trust.

Unlike Pac-Man, the iPhone or iPad can be lost or stolen. While no one wants to loose a $500 device, property loss is a measurable and acceptable risk, one that money will fix. Data loss is a different matter. Therefore, these devices have a passcode that must be provided by the user to access it. To resist brute force attacks, the passcode must be provided in ten tries, otherwise the data will be erased.

Increasingly iOS machines will be chosen by the enterprise. Apple provides features to transfer the trust from the user to their management. These include the ability to control what applications can be used and to restrict the way some, e.g., browsers, are used, by means of Encrypted Configuration Profiles. The enterprise owner may have requirements that the owner user may not. Therefore, Apple provides features like hardware encryption, remote and local wipe, encrypted backup, two-way SSL, crypto APIs, and VPNs.

I have three Windows systems. One is configured as a typical personal computer. It is configured to be used only by me, usually as an unprivileged user so as to resist unintended changes. I use it for many sensitive applications. Therefore, in order to protect myself from leakage of sensitive data, I must hide it from the Internet using a hardware firewall, resist leakage using a software firewall, and resist contamination using antivirus and anti-spam software and services.

One of the other two is configured as a file server. It is not connected to the Internet. It has no applications. The last is configured as an Internet client. It has browsers but no other applications. It has some sensitive meta-data used by the browsers but no other data. An unprivileged user cannot change any programs or store arbitrary data. Needless to say, I trust the latter two systems more than the former.

It is not by accident that Windows and Unix are our most popular operating systems. Popularity leads to low unit cost. They are open to an arbitrary number of users, device types, and applications, including legacies. This means that they have a mammoth attack surface. In order to have trust in them we must configure them in such a way as to limit that surface.

These system share the von Neumann architecture. This means that by default processes include the capability to alter their own methods, procedures, and programs. Moreover, outputs are a function not only of inputs but also of the state of the system. This makes demonstrating the system difficult. We do have other von Neumann architecture systems that are more trustable, including versions of Unix, and alternative architectures like AS/400.

We can have the trust in our systems and devices necessary to the application and the environment. We can tune trust. However, it is not free. It is achieved at the expense of openness, generality, flexibility, freedom, function, application, and programmability.

Programmability is the ultimate in flexibility. A few years ago I attended a presentation by Fred Cohen in which he pointed out that in a world of "application-only" computers, we would enjoy most, but not all, of the benefits of the general purpose computer. After thinking about it for a while, I decided that even if we could complete get rid of it, programmability is so valuable that some SOB would just invent it all over again. On the other hand, as computers get smaller and cheaper, we will decide that we do not have to have it everywhere.

Of course, trust is never absolute. I teach at the Naval Postgraduate School. It would be fair to describe NPS as a "trusted system program." However, the course that I teach is specifically about managing a population of untrusted systems. This is the job that most of us really have. We are the ones responsible for recommending the level of trust required by our applications and threat environment and identifying the strategy and architecture to achieve it. That is why we are called professionals and are paid the big bucks.

FBI Take-down of Coreflood Bot-net

The week before last the FBI announced that they had taken down the Coreflood bot-net of perhaps 2 million systems by taking over the command-and-control system.

This was a major event. It demonstrated that we do not simply have to tolerate the existence of hostile networks of compromised systems. It also demonstrated that law enforcement can be effective in the Internet.

Executive Assistant Director of the FBI’s Criminal, Cyber, Response and Services Branch, Shawn Henry. said, “These actions to mitigate the threat posed by the Coreflood botnet are the first of their kind in the United States and reflect our commitment to being creative and proactive in making the Internet more secure.”Communications.

Although most people were happy to see the Coreflood bot-net go, some have expressed concern about the tactics used in its recent take-down. They are concerned that these may be seen to legitimize behavior that, after decades of debate, have finally been seen to be illegitimate.

Federal prosecutors obtained a temporary restraining order allowing them to replace several identified Coreflood command-and-control (C&C) servers with their own servers, which were then used to send shutdown commands to the Coreflood malware.

One colleague responded by saying "Remote administration without permission is 'hacking.'" I will grant him his semantics without granting him his point.

The first time I said that, and I may well have been the first to do so, I said it in response to the clever child who had created an "anti-virus virus." Of course, the same things are wrong with the idea of an anti-virus virus as with any other virus. First, like any virus, the anti-virus would not have the permission or knowledge of the target system owner.

The real problem is that, independent of the intent or motive of the author, he cannot know enough about the network to predict how his virus will behave. It is difficult enough for him to predict the behavior of his program in a single system that he controls. It is almost impossible to predict its behavior in a population of hundreds of thousands of systems connected in an arbitrary network.

The Electronic Frontier Foundation technology director, Chris Palmer, said the method "is not a safe way to go about [disabling malware] and it's divergent with standard practice."

The "standard practice" that he defends is to simply take down the command-and-control servers, while leaving the bots active. This non-standard practice may not meet Mr.Palmer's test for "safe" but it meets mine for "effective."

We rightly fear the awesome power of government. The preservation of Liberty requires constant vigilance against the abuse of that power. Our colleagues who have questioned this action are right to do so. However, the existence of the question does not imply, nor should we infer, the obvious answer.

Note that in this case, the FBI did not initiate communication with arbitrary systems. It waited until the compromised systems came to it. It did not send a program. It simply sent a command in response to a request. It sent the most conservative command, that is, "shut-down," do nothing.

It is this act which offends my friends, the purists. They are offended, in part, because the executive branch has not been explicitly authorized by the legislature to so act. However, one suspects that if the executive had asked the legislature for this authority, the same, or other, "purists" would have opposed it.

Public Safety, like information security, often involves difficult ethical choices, the lesser of evils. Sometimes it even involves the use of coercion or force. Note that government is the only institution in our society that is empowered to use force.

In this instance the executive did not act unilaterally; the FBI did get a court order. These are not vigilantes. Moreover, if they can be entrusted to use force, they can be entrusted to act in the Internet in ways that are forbidden to the ordinary citizen. That the police do something does not give the citizen license to do the same thing.

I invite my anxious colleagues to rest easy. The Internet is safer and the FBI has not gone rogue.

A final word of caution. One should not infer that all bot-nets can be brought down by the same method. Those networks that use the same collaborative protocols that are used by the file sharing programs (e.g., bitTorrrent) and do not rely on out-of-band command and control will not yield to this method.

Those charged with protecting public safety and those protecting the information infrastructure will continue to be confronted with difficult ethical choices. That is why we are both called professionals and are paid the big bucks.

One More Lost Laptop

Recently an employee of British Petroleum reported "one more lost laptop." In this case the laptop contained records on 13000 victims of BP's oil spill. One does not have to be an application genius to figure out how complete and sensitive those records are or how much work they encapsulated.

Let's consider the possibility that that copy of those records was the only copy. Without even considering any damage that might arise from the disclosure, the loss of those records could be catastrophic to the subjects.

A current search of the web shows that a typical business laptop comes with 250GB of secondary storage (or 128GB of solid state storage for $150- premium). We used to run whole enterprises on that much storage.

Moreover, for $100, one can buy 4 times that much storage to carry in one's shirt pocket; that's right, one terra-byte, $100-. The cost of storage is halving every twelve months. Parkinson's Law of Storage says that data expands to fill the storage available to hold it.

The processor power of these devices is 1000 times what it was a decade ago and increasing exponentially. While "experts" have been predicting the knee in the Moore's law curve for a generation, we continue to push it out.

I now have three old laptops stacked one on top of another that I use for application and storage servers. I have three TBs of storage in my living room network. Daily I operate this network from mobile devices, one, called an iPhone, that I carry in my pocket.

Even in the office there is now a preference for laptops over desktops. Outside there is movement to more, and more mobile, devices, laptops to notebooks to netbooks to tablets to "smart-phones." Note that the only reason we continue to refer to these mobile computers as "smart-phones" is because we buy them from the phone company.

This is only likely to get better or worse, depending on your point of view. The cost per cpu cycle and per bit of storage is likely to fall by a factor of four in 3 to five years. As the price falls the number of devices sold increases and the absolute number of applications grows and the number of applications per device increases. Even the cost of software is falling as the number of copies that can be sold increases.

Five years ago we could not have imagined the applications that we use today. No more so can we anticipate the applications of five years, our planning horizon from now.

Come on guys. The risk is not about laptops. It is about CD Roms. It is about thumb-drives. It is about GBs, and then TBs on one's fingernail. It is about users who have never used a computer they could not carry. It is about powerful computers in one's pocket. It is about what one can buy for a $100-. it is about new use, uses, and users on a barely imaginable scale. All of this involves, not to say invites, risk on an a scarcely imaginable scale.

Consider the bad things that can happen to mobile systems, applications, and data that is less likely to happen to others. First, while robust, these devices can be dropped, broken, or can suffer mechanical or electronic failure. They can be lost or left. They can be stolen, usually for the property value but sometimes for the contents.

Recently we learned that ICE, Immigration and Customs Enforcement, is examining and impounding mobile devices at the borders. Ostensibly this is to look for "contraband" data, specifically child pornography. The courts have consistently held that this kind of search is "reasonable" enforcement of the borders and does not violate the Fourth Amendment prohibition against "unreasonable searches and seizures." In the twenty months of the program, ICE has "examined" more than 6000 systems.

For most of us, and while it is a growing one for frequent business travelers, this risk is dwarfed by the other risks of mobile devices. Like those, it is one to which the same applications and data are not vulnerable when done on stationary systems. It is addressed by some, but not all, of the same security measures.

For example, while loss and leakage are addressed by encryption, ICE will simply demand the key. More over, encryption offers no protection against the far more likely threat of failure or breakage.

On the other hand, not taking data or applications addresses everything except property loss. I now carry a sterile MacBook Air when I travel. No enterprise, client, personally identifiable information, intellectual property, payment system, or other sensitive data.

* Consider the following policies and practices:
* Store sensitive data only on enterprise servers.
* Prefer remote access to enterprise servers to personal, local, or portable copies.
* Save new work on mobile devices to stationary servers
* Permit portable copies only with specific management approval.
* Any portable copies on devices with full-device encryption.
* Any portable copies in encrypted file systems or databases.
* Prefer mobile devices (e.g., Blackberrys, iPads, iPhones) with remote location and remote erasure capabilities.
* Prefer client-server object-oriented databases (e.g., Lotus Notes) with end-to-end encryption by default.

Keep in mind that these are risk mitigation, not risk elimination, policies. Leakage from mobile devices is a fact of life. We cannot solve the general problem but we can address it for ourselves and our enterprises. Note that they do not mitigate the risk of loss or breakage of property.

Of course, even justifying, much less implementing, these policies and practices will not be easy. That is why we are called professionals and are paid the big bucks.

Near Field Communication (NFC)

There is a new communication standard on the horizon. It is called Near Field Communication, NFC, ISO-18000-3, and you might want to spend a few minutes with the Wikipedia article on it. It has all sorts of wonderful applications. It has a number of security applications and, of course, security limitations and implications.

NFC is intended for use on mobile computers, such as "smart-phones" or PDAs, that the user will be likely to carry, like keys or a wallet, most of the time. More than a dozen implementations, mostly smart-phones, have been shipped or announced by manufacturers including Benq, Google, LG, Motorola, Nokia, Samsung, and others. Applications await sufficient numbers but payment application trials are planned for San Francisco and New York.

Proposed applications include mobile payment, smart card emulation, including EMV, transportation and theatre ticketing, electronic keys, identity documents, cryptographic key management, and dozens of others. Of course, while not requiring NFC, these same devices can be used to implement both token-based and out-of-band strong authentication.

One application of NFC is as a reader of passive RFID tags and passive emulation of RFID tags. For example, eCLOWN is a program for a Nokia NFC phone to read the RFID information on an e-passport.* As you are probably aware there is significant opposition to any use of RFID from those who fear that the value likely from such applications will not justify the leakage or other unintended consequences. This opposition is likely to include NFC. (That the ability to read this information might marginally reduce the cost of forging an e-passport is sufficient reason for some to resist the use of the technology altogether. This, in spite of the fact that an e-passport is much more difficult to forge than an ordinary one.)

The name derives from the inductive effect of the "near field," i.e., within two wave-lengths distance, of the antenna. The reliance of the technology on this effect limits its effective range to about 4cm but the "far field" effect of the antenna might leak information beyond the effective range, perhaps at a distance of a few meters. Because, unlike Bluetooth, NFC does not provide encryption, for some applications encryption such as SSL or Mime, might have to be implemented at a higher layer

NFC is low-power, 15ma, as well as near-fieled inductive, and consequently relatively low speed, 421 kbps. This is fast enough for security and financial applications but much too slow for streaming video or even surfing the web. However, it has one great advantage over competing technologies, i.e., connection setup time. While Bluetooth may take seconds to establish a peer-to-peer connection (after "pairing"), NFC takes less than a tenth of a second. (One proposed application of NFC is for pairing of Bluetooth.)

As with any technology that is vulnerable to eavesdropping and replay, NFC is weak, that is, "one-factor," authentication. Most of the security applications will require strong authentication, at least two factors and resistance to replay. To the extent that NFC is implemented on hand-held computers, a wide variety of authentication schemes will be open to application designers.

NFC signals via amplitude modulation; its ability to resist a the modification of a bit is a function of the strength of the modulation and the coding used. However, some NFC applications may have to provide encryption to resist data modification attacks.

Because NFC is low power, electronic jamming will be relatively easy. Of course, the same is true of Bluetooth. The experience with Bluetooth suggests that this is a vulnerability without a problem. However, NFC may not be suitable for applications where ultra-high availability is a requirement.

NFC devices are vulnerable to loss, along with any credentials, privileges, and capabilities associated with them. Applications should resist the use of lost devices by implementing lock-words for use of the device, remote disabling and erasure, and other security mechanisms. Abandoned NFC connections might be vulnerable to exploitation until and unless they time out. Therefore, devices and applications should be designed to time out in the minimum time adequate for the application.

Those of you that are followers of IGTV or of my blog know that I am a long time critic of the use of mag-stripe and PIN for our point-of-sale payment system. Outiside the US, EMV cards are being used to improve the system. However, progress is limited by implementations that are backward compatible with mag-stripe and PIN. Perhaps this is to be able to process the cards carried by American travelers.

Although there are trial EMV cards and merchants prepared to accept them in the US, there are no plans to deploy them widely, much less pervasively, or exclusively. This is in part because of the cost of cards and readers, and in part because they do not solve the "card-not-present" problem. It is in part because transiting the intervening payment card service providers is difficult.

Not only can NFC devices both emulate and read EMV cards, these smart devices can address the card-not-present problem for mail-order, phone order, and Internet commerce. Moreover, hand-held devices can emulate multiple cards and accounts, functioning as e-wallets and reducing the number of credentials and tokens that a consumer must carry.

Like many such technologies, Near Field Communication is inherently neither secure nor insecure. It is proposed in good faith and with high hopes for legitimate applications. However, I have now lived long enough to expect poor implementations, inappropriate uses, and unintended consequences for any novel technology. I am not without sympathy for those who fear technology in general and RFID in particular. I will be surprised if NFC is not chosen for some applications for which it will not be secure and for others where, as with mag-stripe and PIN, it will survive long after use has stressed it to the breaking point.

The "securability" and reliability of NFC applications will depend in large part on the devices on which they are implemented, that is, in the ability of those devices and their operating system software to resist application-to-application data leakage and interference. These mobile devices are already being used for financial transactions over the Internet and using graphical readers for bar codes or QR codes. However, it is clear that these systems will vary greatly in their ability to protect their applications and will rely to some degree upon their users and vendors to keep them sanitary and current. We must be prepared for the NFC technology to be blamed for any compromise with which it is even remotely associated.

Still, I am hopeful that NFC will find many security applications and "securible" implementations. I particularly hope that it will find application in the payment system, and, for example, by emulating EMV, encourage its adoption. We must design and chose carefully and apply and use conservatively. We should err on the safe side. We have to prepare diligently and advance cautiously. It will be difficult and risky and it will challenge our knowledge, skills, and abilities. That is why we are called professionals and are paid the big bucks.


* Step 2 of the instructions for using eCLOWN is "Insert the passport (crypto) key." It is silent on where to obtain this key. However, because there are many copies of the key, that will be, at best, difficult.