FFIEC Authentication Guidance

The Federal Financial Institution Examination Council, the FFIEC, has finally passed its long-awaited "new" Authentication Guidance. It was hoped that this guidance would address the account take-over attacks that have resulted in both losses to, and disputes between, the banks and their customers. Those security professionals that had hoped that the guidance would address the credential re-play that is at the heart of this problem can only be disappointed. Indeed, almost everyone is disappointed with the exception of the banks and the regulators themselves.

The language is someplace between "wishy-washy" and largely "content free." For example, it says that "institutions should use effective methods to authenticate the identity of customers and that the techniques employed should be commensurate with the risks associated with the products and services offered and the protection of sensitive customer information."

On the other hand, it is silent on the relative effectiveness of measures and makes no recommendation among them.

It dismisses token-based strong-authentication on the basis that it might be vulnerable to man-in-the-middle attacks. While that may be true, we are not seeing any such attacks. On the other hand it is resistant to the re-play attacks that we are seeing.

The Guidance suggests that we need better questions in challenge-response systems. Of course, the problem is not the resistance of the questions to guessing but how many questions there are and how quickly they leak to a key-logger. Again, it is as if the authors do not really understand the attacks.

If there is anything in the Guidance that I agree with, it is the idea of layered security. The idea is that we should not rely exclusively on the authentication, regardless of how good we think that it is. We should have policy, application controls, monitoring, timely confirmations and reconciliation, Patco and Experi-Metals both could have been a lot worse without these controls. That said, these controls mitigate the fundamental problem of credential re-play, they do not compensate for it. Moreover, the document is labeled "Authentication Guidance;" we have a right to expect that it will speak to that.

Part of the problem is that the agencies do not want to preempt the responsibility of bank management. Thus, they emphasize "risk management." They even acknowledge that the risk has changed since they published their original guidance. Banks have the fundamental responsibility to protect the customer.

Part of the problem is that the FFIEC is made up of the five Federal agencies, Office of the Comptroller of the Currency (OCC), the Federal Deposit Insurance Corporation (FDIC), The Federal Reserve Bank (FRB), The National Credit Union Administration (NCUA), and the new, Consumer Financial Protection Bureau. Each has different constituents and interests. The purpose of the council is to promote uniformity in regulation and limit institutional shopping among the regulators. Perhaps it is a little much to expect that five government agencies would ever arrive at strong guidance on anything.

However, the result is to set the bar at the lowest of all the agencies. As one of the authors put it, "The Guidance provided minimum (emphasis mine) supervisory expectations for effective authentication controls applicable to high-risk online transactions involving access to customer information or the movement of funds to other parties."

As I read the Guidance and the commentary on it, I kept coming back to the same question: "What part of 're-play' do they not understand?" Finally I scanned the document. The word does not appear. They do not understand any of it.

When they are criticized for not addressing re-play, their response is, "placing so much emphasis on what's 'missing' from the guidance detracts from regulators' intent." Perhaps. Perhaps they simply do not get it. Perhaps it is not even their job. Perhaps we expect too much of them. Perhaps it is our job.

Our job is not to debate whether or not guidance from the regulators is correct or complete. In fact, we have known since shortly after Sarbanes-Oxley that "security by compliance" encourages minimalist, not to say weak, security. No bank is going to have to change what it is doing to meet this "new" Guidance. Hopefully they will meet the requirement in spite of the Guidance, if not because of it. The Guidance sets a low bar but does not forbid high clearance.

Indeed, our job, without regard to the guidance, is to keep our principals out of the debate and to be sure that bad regulatory guidance is not used to justify weak security.

The good news is that we did not really need the Guidance to tell us what to do and now we can stop waiting for its magic. The bad news is that some management might decide to use it to justify continuing whatever they are already doing. It is our job to see that our principals do the right thing, whatever the Guidance says. It is for that that we are called professionals and are paid the big bucks.

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.