Business as Usual........

......no longer cuts it.

The cost of attack against targets of choice has fallen close to that of targets of opportunity. Patience helps and may even be necessary but not much work or access is required; the necessary special knowledge is available as a toolkit for tens of dollars. Attackers are in different legal jurisdictions and may even be agents of foreign nation states; they do not, and need not, fear detection or identification, much less prosecution.

The value of a successful attack is too high and rising. Compromised credentials may result in losses of hundreds of thousands of dollars, expensive to the banks, but a threat to the health and continuity of a small business customer. Compromised systems may result in the loss of intellectual property that threatens the health, competitiveness, and continuity of the enterprise. Can you say Google? RSA? Can you say Sony?

Too many web facing applications have unchecked inputs making them vulnerable to SQL injection and buffer overflow attacks. These attacks are resulting in the compromise of personally identifiable information (PII) and payment card information (PCI). They have become so common that many no longer make news.

While we still see bait on web sites and some spam, the most efficient bait is crafted to appeal to identified individuals and is delivered by e-mail. For many enterprises a crafted bait message may be sufficient to compromise their whole network. The bait messages that used to appeal to fear, greed, or lust now appeal to curiosity. One report had it that the bait messages addressed to RSA were labeled "2011 Hiring plan."

Accepting the bait may compromise the user's credentials, as we saw in Patco and Experi-Metals, facilitating re-play attacks. Alternatively, it may compromise a system, providing a tunnel through the perimeter and an agent on the network, as we saw in RSA.

The net of all of this is that "Business as usual" will not cut it. We must raise the state of the practice closer to the state of the art. We must raise the cost of attack and lower the value of success. We must raise the bar across the board.

Since e-mail is proving to be such an efficient attack vector and involved in so many compromises, it is a good place to start.

Awareness training is necessary but not sufficient. With a sufficiently large population of users, it is inevitable that one or more will take the bait. It is not stupidity or even carelessness. Rather it is simply human nature.

Upgrade or outsource your e-mail. Use a restrictive e-mail policy; that is, accept messages only from known sources. Ninety percent of all your traffic comes from such sources and they are limited in number. Quarantine or "red-flag" everything else. Be sure that the "from address" agrees with the origin address.

Encourage users to have personal e-mail addresses that they can access from their own mobile devices or kiosk machines provided for the purpose. Yes, it is a change in culture but not as expensive we pretend that it is.

Since unchecked inputs is obviously part of the problem, address them. Checking inputs is much harder than it looks, beyond the training, knowledge, skills, and abilities of most application programmers. That is why this problem, identified forty years ago, still persists. Therefore, application programmers should all be trained and required to use the OWASP Enterprise Security API.

Most of us still use M&M security, crisp on the outside, soft and mushy on the inside.

Assume that there is no perimeter or that there is an agent on the inside. The NSA behaves accordingly. If one has, or assumes that one has, untrusted machines on one's network, one must place place firewalls between all systems and their networks. These must implement a restrictive policy; only that traffic explicitly permitted must pass.

We must have strong authentication, credentials that cannot be re-played raise the cost of attack and reduce the value of success. More on this next week when we talk about the "new" authentication guidance from the Federal Financilaal Institutions Examination Council.

Servers must talk only in secret codes, VPNs to clients, VLANs to one another. Terminate VPNs on the applications, not on the perimeter, not on operating systems. Applications should talk only in secret codes, only to those who have the key.

Lock down every system that you can. Restrict "write" access to programs. Part of our problem is that the population of systems that can be compromised is ten times the size it needs to be. Most users do not require the discretion to execute arbitrary programs or even to install applications. Most users could get along with thin clients to apps running on servers. If a user takes bait but his system resists compromise, then no permanent harm done may be done.

Configure access control on database servers. We are relying on application servers to protect the database servers; they are not up to the task. Use a restrictive policy; even these will leak but they will raise the cost of attack over permissive one's. Most application data, personally identifiable information, payment card data, and intellectual property must be stored on object-oriented, database servers, not in flat files, not on personal systems.

We must have stronger application controls. It is absurd, for example, for an application to permit 92 transactions in a day, for hundreds of thousands of dollars, using credentials that have never been used for that purpose before, against an account that normally had a zero balance, and against which no more than one or two transactions had ever been made in a day. In addition to checked inputs and database controls, we need controls specific to the application. Application controls raise the cost of attack and reduce the value of success.

Do you really believe that your security is that much better than Sony's, that you could resist the same kind of attack? If compromised in the same way, do you have a plan to return your network to a known and trusted state? Note that this requires rigorous separation of data and programs so that you can restore programs without the loss of data.

Let me not forget monitoring, measurement, and reporting. Turning on logs is necessary but not sufficient. If one waits until after something goes wrong and looks at them only for forensic purposes, it is too late. There is software for integrating logs and for using them pro-actively to identify and resist attacks before, rather than after, they succeed.

Restrictive policies, even for e-mail, least privilege, even for users, strong authentication, stronger applications, encryption by default, and better monitoring, measurement, and reporting all round. It is time to get serious.

Many of these measures are counter-cultural. They will have some influence on the way people do their jobs. They will generate some resistance and even some resentment. We will have to change attitudes. Notice that they do not require new tools so much as changes to how we use our tools.

These are just tactics but a change of this magnitude is strategic. It is ambitious. It will require leadership, commitment, and planning. It will take time, of which we have little enough. If we are to continue to be called professionals and to be paid the big bucks, we must be able to look back two years from now and measure a marked improvement in our security posture. If you are not up to the challenge, perhaps you should update your resume. On second thought, perhaps you should consider a change in career.

RSA SecurID Update

I continue to believe that the public relations surrounding the recent breach of RSA's systems is the worst since Watergate. In any case, it is far worse than the breach. Every pronouncement on their part to make it better has only raised more fear, uncertainty and doubt.

I would like to try to distill some signal from all this noise.

Let me say from the start that the sky is not falling. Fear is not justified. Strong authentication is not falling apart. SecurID is not broken. While the cost of attack for one adversary, perhaps a nation state, against some targets of choice has fallen marginally, for most SecurID users, their risk is approximately the same today as it would be had their been no breach.

As I noted in my first report on this subject, I am glad that RSA is not my client. They are truly between a rock and a hard place and the water is rising.

So there are all sorts of good reasons why RSA is less than forthcoming about their breach. First, they probably have limited knowledge about what actually happened. They do not want to compromise the investigation. They do not want to leak any information that might be useful to the perpetrator in exploiting the product of the breach. They do not want to do anything that might make a bad situation worse.

However, their lack of candor has done just exactly that.

[Of course the perpetrator of the breach probably knows what he got and how to use it. After all, RSA was a target of choice, not opportunity; if the attacker had not known what he was looking for and what he would do with it if he got it, he would not have bothered.]

The lack of candor of their customer, Lockheed-Martin, only added to the FUD. What evidence did Lockheed have that it was under attack? What evidence that it was related to the RSA breach? What was the method of attack? To what extent was the attack successful? Security professionals would like to know. Instead, after all of this, the only thing that we know with confidence is that RSA was breached by a resourceful and patient adversary. Almost all else is speculation, not to say hype.

Given the little we know, what should we do? Which among us should do it?

If you are not already using strong authentication, start. Can you say "replay attack?" Account takeover? Identity fraud? Zeus? SpyEye? Start with privileged users. Start with users at systems that you do not control. Can you say customers? Trading partners? Home workers?

While I still have a high regard for EMC and RSA security, needless to say, it is diminished. So, if you want to use token-based, you may want to consider a different vendor. I am increasingly a fan of out-of-band. I like the use of mobile devices, devices that people carry anyway, for both token-based and out-of-band. I use my iPhone for token-based with PayPal.

If you are the average SecurID user, do nothing. Your risk has not changed enough to justify the cost of any changes, let alone the cost of distributing new tokens, even free ones.

Any attack exploiting the leak and that does not involve the use of a known token ID, or at least a user ID and PIN, will be noisy. Therefore, risk averse organizations may wish to:

1. Listen. Monitor your ACE server for failed logon attempts.

2. Resist bait attacks and other "social engineering attacks seeking token IDs, user IDs and PINs. (See rule 1.)

3. Resist exhaustive attacks against PINs, for example by increasing the content. However, since the most efficient attacks against PINs will involve "social engineering," see rule 2.

The Canadian Cyber Incident Response Center published "advice," this week, further muddying the water. Their advice included a target list in the context of the RSA breach.

· high-profile international events participants (e.g., Olympics, FIFA)

· legal organizations, namely those involved in international contracts, mergers and acquisitions (e.g., Clifford Chance)

· organizations involved in international affairs, economics and finance (e.g., IMF, World Bank)

· security and defense organizations (e.g., Lockheed-Martin, Northrop-Grumman)

· natural resources and energy sector organizations (e.g., FMC, Exxon-Mobil, AramCo)

· research and development organizations (e.g.,

· information management / information technology organizations (e.g., Intel, Apple, IBM, EMC, Verisign,

· political activist groups (e.g., ACLU, the RNC)

While these are all high value targets, taken collectively, their risk did not change as a result of the RSA Breach. The list is too long and embraces far more enterprises than even a resourceful adversary is capable of getting to. For most on this list, there is safety in numbers. Having drawn the list and thereby suggesting that all on it are peer targets, the CCIRC stopped short of recommending that they all issue new tokens. Government, in an abundance of caution, has cast its net so broadly that no recommendation is possible.

You should issue new tokens if, and only if, you might be a target of choice for those who breached RSA and attacked Lockheed-Martin. You should know who you are. You do not need the CCIRC to tell you. Your risk may have changed enough to justify issuing new tokens. Expect RSA to pay for them. Still in doubt? Call me.

Whoever you decide that you are and whatever you decide to do, write it down. Professionals document their decisions and communicate them to their principals. Be prepared to be second-guessed; it goes with the job.

We need to watch for any evidence that those who breached RSA have been successful in exploiting it. One way this will show up is as evidence of efficient attacks; we should watch for this. Another way that it will show up is in sale of RSA intellectual property to others; these transactions will probably take place on the Internet and we should watch for them.

Discerning intelligence, information that we can act on, from all this noise is difficult. That is why we are called professionals and are paid the big bucks. Fortunately, for most of us, the default, doing nothing, is the right choice. Write it down.

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.