AES is Broken!

That is the headline. What does it mean? Should you care?

What does it mean to say that a cryptographic algorithm is broken? Does it mean that the cost of recovering the clear-text without benefit of the key has suddenly fallen to zero? Well, that would qualify, but no, crypto does not fail that way. Does it mean that the cost has fallen to be equal to that of encrypting with the key. Clearly that would qualify, but no, it does not mean that either.

Well, how about the cost has fallen to be equal to the value of the data? How about the time required to recover the clear-text has fallen to less than the life of the data? Well, if either of those had happened, even I might agree that the algorithm was broken. However neither of those has happened either.

For a "standard" algorithm, one might claim an algorithm was broken if the cost of attack was lower than that claimed by the standard.

For example, for the Data Encryption Standard, the DES, the claim was that the cheapest attack was an exhaustive attack against the key, on average, half the time required to try all possible keys. By that standard, the DES is still not broken, low these thirty-five years later. It is true that using a bot farm, one can do a brute-force attack in days. However, for many applications, the life and value of the message are such that no one would spend even that much.

For RSA, the claim is that the cheapest attack is a function of the cost to find the factors of the product of two large primes. While finding the product of two primes is trivial, finding those two numbers knowing only the product is a problem that has challenged mathematicians for a long time.

The time required to try all the DES keys falls as the power of computers goes up but we always know what it is. Similarly, the time required to find the factors of the product of two large primes goes down as computers become more powerful. It might even get cheaper as mathematicians get smarter, but it is unlikely to drop suddenly.

AES is not a standard in the same sense as the DES or RSA. No claim is made for its strength. Rather it is a standard because an authority, NIST, says that it is. It's strength is what it is. We know that the most expensive attack is a brute force attack, but not only has no one ever asserted that there is not a cheaper attack, it has been demonstrated, at least mathematically that there are.. Said another way, by definition, one cannot ever say that it is broken. The best one can say, is "I can find a key this fast."

While some claim that ""Broken" in cryptography is the result of any attack that is faster than brute force"" that simply justifies the claim of the headline. It is not a definition that is meaningful in any sense that a laymen, or even a security professional can understand or use.

By one estimate, the time to brute force a 256 bit key is 5 x (10 )^56 years. What the authors of the paper claim is that they can do it in a mere (10)^51 years. While that may be an interesting improvement, certainly worthy of a paper, even a headline, it does not justify the use of the word "broken" in any practical sense, whatever the authors and headline writers might claim. These authors have simply established the new "standard" cost of attack for the AES.

This is a mathematical assertion that defies any other demonstration. Such an attack, begun at the big bang, would not have completed yet. We call that "strong enough" for security work.

I like cryptographers. Most are very nice people. However, like many such guilds, including security professionals, they have their own special jargon. I appreciate the fact that they do all of these heady calculations for me. However, their security advice is on a par with their medical and legal advice.

Creating a cipher that you yourself cannot break, is relatively easy. All the work is in learning enough about it to be able to predict how much work it would take a body of experts to break it. We call that effort "standardization."

Does all of this mean that our cryptography is "safe," that even nation states cannot read our encrypted data? Not. It has always been my assumption that nation states in general, and the US and Russia, in particular, can read any traffic that they wish.

I am reminded of three colleagues: Phil Zimmerman, who wrote PGP and called it "pretty good;" Adi Shamir, one of the authors of RSA, who wrote, "People do not break crypto, they bypass it;" and Brian Snow, who spent a career at NSA, and who said, "At NSA we spend as much resource on systems as on codes and ciphers."

Algorithms are the strong part of our systems, orders of magnitude stronger than we need them to be. People are the weak point and implementations are in the middle. While it might take the life of the universe to try all possible keys, one might brute force the eight character lock-word used to hide it in a day. Failing that, attackers might bug your systems, suborn your associates, or break your fingers, one after another..

Life would be wonderful it our security was determined by the height of our walls rather than by the guards at our gates, by the strongest link in our chain rather than the weakest. On the other hand, then we might not need security professionals or pay them the big bucks.

Tearing off the PCI/DSS Band-aid

More than a quarter of a century ago, while I was still at IBM, I had discussions with staff at Sears, then the nation’s flagship retailer, about their forthcoming credit card. I tried to convince them to take the opportunity to force the industry to replace mag-stripe cards with smart cards. They were Sears, they had the clout, they could make it happen. They didn't and the rest is history.

Now, the nation's new flagship retailers, Wal-Mart, Target, CVS, and McDonalds are making it happen. Sears and K-Mart will come along.

Partly in response to these forward leaning merchants, Visa has announced that it will expand its Technology Innovation Program (TIP) program to the US. They will begin transitioning to EMV standard cards and infrastructure.

Some of you are aware that I have been very critical of the payment card industry for continuing to use the broken mag-stripe and PIN system. By doing so, they have put the necessary public trust and confidence in the retail payment system at risk. I am torn between "what took you so long" and "better late than never."

The EMV (EuroCard, MasterCard, and Visa) technology that Visa plans to use has been in use in the rest of the world for years. It uses a contact-less smart card, and optionally, a signature or PIN. It is already deployed in the US in some markets and the leading retailers already mentioned.

Here is an American Express EMV card that I have had for a couple of years. For reasons of backwards compatibility, it also has a mag-stripe. That is good because I can use it in EMV mode in only a limited number of places. Those places include McDonalds, CVS, Target, and Wal-Mart. it is bad because the vulnerabilities of mag-stripe and PIN will persist for years.

Many of the users of the EMV/POS readers deployed by these flagship merchants are foreign travelers to the US. These retailers have bitten the bullet but they cannot get all of the return on their investment until Americans carry EMV cards.

Therefore, these retailers have been a source of public pressure on the payment card industry to deploy this technology. Wal-Mart has been castigating the payment card issuers for more than a year now for "blocking" the use of this technology. Google Wal-Mart EMV and you can see for yourself.

Of course, "blocking" is stronger rhetoric than I am prepared to use. There is history here and business reasons why the issuers have not used EMV in the US. For example, the reason that Sears did not deploy smart cards was that the barrier to entry was too high; it was far cheaper to exploit the existing infrastructure than to replicate it.

While I understand those reasons, and to some degree am sympathetic, I have argued for some time that we cannot continue to rely on a broken technology for the security of our retail payment system. In the presence of cheaper counterfeiting technology, we have strengthened our currency, and even checks, to the point where cards are now the weak link in our system.

Notice that the merchants in this list are all nation wide chains that operate their own systems for authorizing payments. Part of the resistance in the US is rooted in the fact that most of our small and medium-sized merchants use third-party card service providers to accept card payments. These third-party providers enable them to accept any issuer;s card without having to have a separate agreement with and connection to that provider.

While it is an industry standard, EMV is also proprietary. The issuers share the exact workings, under contract and non-disclosure agreements, only within the industry. The important thing for you and I to know is that the card "signs" the transaction, without disclosing its own identity, the "credit card number," to the POS device. EMV resists skimmers and rogue or compromised POS devices. It resists replay attacks and card cloning attacks.

As with mag-stripe, in some, but not all, transactions, EMV will use PINs and signatures to resist the fraudulent use of lost or stolen cards. Because, the primary protection against the use of lost or stolen cards is disabling it after it is reported lost or stolen, PINs and signatures will not be required for all small value transactions.

For example, when I buy a Big Mac, I simply touch my card to the POS device and check the display and receipt to satisfy myself that I was charged the correct amount. No signature or PIN. If I use the same card to purchase an HDTV, I expect to enter a PIN or sign a transaction slip.

One interesting feature of EMV is that a card can be limited in the number of PIN-less transactions that it can do. An internal counter keeps track of the number of PIN-less transactions. The count is reset to zero for every PIN transaction. If the count reaches the threshold, the next transaction must involve, will prompt for, the PIN.

Because the POS device cannot capture the EMV card number, it is safe to enter a PIN into it. The PIN is only useful with the card or card number. I have long argued against "debit" card transactions where both the card number and the PIN appear in the clear at the point of sale. These are the source for many counterfeit cards.

While it is now relatively cheap to clone a mag-stripe card, knowing only the public number, this is not sufficient to clone an EMV card. Putting aside the fact that it is more expensive to write chips than stripes, cloning the EMV card requires knowledge of its secret token. It is secret for a reason, a security reason.

Another reason the issuers have resisted EMV in the US is that it does not solve the fraudulent "card not present" problem, those on-line transactions where the rogue has the card number but not the card. Most solutions to this problem involve a display and power, expensive, though not impossible, to put on a card.

Oh, I almost forgot about the PCI DSS, the Band-Aid that the issuers have been relying upon to hold their broken system together. Visa has announced that after October 1, 2012, merchants who have 75% or more of their transactions originating on EMV equipped terminals, will be exempt from compliance with DSS for any year for which that is so. This is a big incentive to those third-party card service providers, who have been one of the problems, for whom DSS compliance is so expensive. Their participation and cooperation in EMV is essential.

Some have suggested that merchants will resist replacing their POS devices. Probably true but "resist" only means that they will take their time. McDonalds did not replace their terminals, only added the EMV reader to the top. Check it out, but unless you know that you are looking for a red semicircle at the top of the device, you might miss it. The expense was not so much in this part as in installing it.

While we think of them as capital equipment, POS devices are actually consumables with a life measured in months to years. One can buy the latest feature-rich model, with built in WiFi or cellular communication, for hundreds of dollars. Most merchants buy their POS device from the card service provider who will be motivated to see them upgrade.

I wish I could tell you that everyone is going to love this technology as much as I do but I cannot. In fact, you can expect to hear all kinds of slurs about its security. After all, anything built by man can be broken by man.

For example, two weeks ago, at Black Hat, an NVP (We do not mention the names of NVPs; it feeds their narcissism.) was quoted as saying, "We think an EMV skimmer poses a serious threat, due to ease of installation, and is very difficult to detect." (Sic) First, a skimmer would be a tool, not a threat. Second, it might be easy to build and conceal, but the issue is getting the card to cough up its secret token. There is no command to ask it to do that. A cryptographer will tell you that one could simply ask it to authenticate a lot of transactions, a few million might do it, and then solve for the secret. A security person will tell you that "that will take a long time." it will take so long that it is not practical, much less efficient.

When you read these "expert remarks," remember two things. First, this is a mature technology, used and tested around the world. It is new only to the US market. Second, however vulnerable it may be, it is orders of magnitude stronger than the broken technology which it replaces.

Getting from our current system to EMV will not be without problems. Experience in Europe suggests that many problems will be related to the transition, in general, and backward compatibility to mag-stripe, in particular. Anticipating and mitigating these problems will not be easy but that is why we are called professionals and are paid the big bucks.

Mission Impossible

During my last years at IBM, Wjm Van Eck, A Dutch engineering student, published his paper about reading computer screens using TV receiving equipment. The press loved it. There were TV shows on the BBC demonstrating reading screens at a show and reading a document on a word processor screen from the Scotland Yard parking lot.

Van Eck's experiment was based in part on the following:

• All electronic equipment leaks
  
• CRTs are very noisy and leak a lot
  
• The screens of the day were character only
• The signal that they leaked mimicked that of broadcast TV

On his student budget, Van Eck simply cobbled together antennas, amplifiers, and receivers and displayed the signals on a standard TV screen.

I decided to see if I could replicate Van Eck’s results. I purchased from him a replica of his experimental rig. I gave it to two engineers, one senior and one junior, in the Raleigh lab, next to the plant that manufactured 3270 terminals. They assured me that it would be a piece of cake to reproduce the experiment.

It proved to be somewhat more difficult than they anticipated. On one trip to the lab, they did manage to show me a screen that lit up like their target. At a distance of two meters, it was clear that the image on the destination screen was related to the one on the target, but the content was less than readable. As often happens with engineers, these two lost interest in the effort after they were satisfied that, given enough time and resources, they could replicate the results but long before they had actually done so.

In the more general case, in estimating the cost of attack, engineers often discount the value of their own special knowledge and skills. They think, “Everyone knows (or can do) that.” They also tend to think that if an attack is feasible, it will be used. They tend to discount the difference between feasible and practical, effective and efficient.

These are the kind of esoteric attacks from which the drama in Mission Impossible is crafted. In fact, rather than fiction, one can expect an attack to be used only if it is efficient. The set of cases in the world in which such an attack is both suitable for the intended application and environment and cheaper than all alternatives is vanishingly small.

The leakage of information via electromagnetic signals is a vulnerability without a threat, a non-problem. Not all vulnerabilities are problems, not all problems are the same size.In the generation since van Eck published his paper and the press raised the alarm, such attacks have not ranked with our other security problems, not on our radar. The vulnerability is lower now than then and the cost of attack higher.

Today, while the attack equipment may be more efficient, the cost of such an attack is still higher. Screens are now bit-mapped graphics, not character. They are low-power, quiet, LCD displays, not noisy CRTs. Their emanations do not mimic broadcast TV signals. While they still leak, all electronic equipment does, they are much quieter than those of a generation ago.

One lesson that you should take away is that unless your applications are very sensitive, your adversary a nation state, and the rest of your security so good that this is your weak link, spend your scarce security resources elsewhere. Remember that "Mission Impossible" style attacks are undertaken only against those targets that are very sensitive and that have very good security.

Another lesson is that one should not take security advice from vulnerability pimps or the popular press. Rather, one should rely upon one's colleagues, professionals who are paid the big bucks.

Viruses, iOS, and Apple

About twenty years ago I used to do a presentation, based upon an early paper, in which I identified four conditions necessary and sufficient for the successful spread of a computer virus.
" A population of similar systems, capable of executing and replicating the virus;
" Sharing of vectors to carry the virus across the population;
" A way for the virus to replicate, i.e., to get itself executed, and
" And storage to hold the copy.
By restricting any one of these things, we could resist the spread of a virus. Of course, these things are all otherwise desirable. There is resistance to restricting them.

In the early nineties I attended a meeting at IBM Research. Fred Cohen, the godfather of all viruses, gave a presentation in which he observed that, in a world of application-only computers, we might still enjoy most, but not all, of the advantages of the modern computer.

I thought about this for a while. This was a way of looking at the third condition, the ability of the virus to get itself executed. The Windows operating system had a dozen ways for a program to be executed automatically. Even if we restricted all of these, the virus might still get itself executed by duping the user into "clicking on it."

We have had application-only computers for a long time. My favorite example is the ATM, the automated teller machine. I also like the arcade machines like Pac-Man.

One thing that distinguishes the application-only machine from the general purpose computer is programmability. The virus exploits the ability of the user to execute an arbitrary program of his own choice or even writing. After listening to Fred, I concluded that even if we could stamp out programming, it is so valuable that some SOB would just re-invent it.

Then, along came Apple with the iPhone and what we now know as iOS. At first Apple said "no user programs." Of course, they did not say that explicitly, They just did not provide any capability for creating one, importing it, or executing it. It did not offer an application programming interface, API, or a software development kit, SDK. Voila, an application-only virus-resistant computer.

Only a few geeks understood. Apple was offering a closed system while the geeks preferred, not to say demanded, open. Most of us did not realize that we were buying a "crippled" computer; we thought that we were buying a "smart" phone.

Gradually Apple has rehabilitated iOS. They have provided an API and SDK, both carefully crafted to maintain security. Applications run in an isolated compartment that Apple calls a "sandbox." Each application looks like an application machine to the user and hides the operating system, file system, and network from the user.

However, all four of the necessary conditions for the success of a virus are still restricted in some way or another. iPhones and iPads can be viewed as application-only computers.

Just as Fred Cohen promised, the tens of millions of users of iOS enjoy most, but not all, of the advantages of the general purpose computer. On the other hand, just as Fred predicted, they are pretty much virus free.

On the other hand, I was right too. The geeks are still trying to liberate, to "jailbreak," iOS, to restore to it all of the generality, flexibility, and capability, that Apple has "arbitrarily" denied to them, along with the inherent vulnerability from which Apple has protected them.

On July 15 Apple released an update to iOS, Version 4.3.4, to close a vulnerability exploited by the jail-breakers, one that could have been exploited by others. German authorities assert that this vulnerability had, in some form or another, existed for four years. Less than 12 hours later, a new jail-break was available. On July 5, 2011 Apple released Version 4.3.5 with a fix for that and 3 other vulnerabilities in other parsers

So far, Apple has patched the PDF parser half a dozen times. Each time the geeks have found another vulnerability. We call this strategy of late vulnerability detection and patching, the Microsoft strategy. It is likely to be about as successful for Apple as it has been for Microsoft.

All that is necessary to use this vulnerability to jail-break is to click on a crafted PDF on a web-page. How can it be that easy? It exploits an implementation-induced vulnerability, an unchecked input in the pdf parser within the Safari browser. While the jail-break PDF is overt, chosen by the user, and only Apple considers it malicious, the same vulnerability could be used to make more covert and malicious changes to an iOS device.

As we have noted here before, checking inputs is difficult. It is particularly difficult for a browser, where most inputs are legal and illegal ones difficult to enumerate. Therefore including a browser, Safari, in the operating system is inherently dangerous. Trying to parse PDFs in the OS is insane.

We have talked here before about how difficult it is to check inputs in modern systems. That is why we recommend the use of the OWASP Enterprise Security API Library for web servers. No such library exists for browsers or PDF parsers. Parsing PDF input appears to be so difficult that even adobe must issue frequent, not to say weekly, patches.

Eventually Apple is going to have to resort to a more fundamental strategy, like removing Safari from the OS. In the meantime, there are six alternative browsers for iOS. Unlike Safari, they all run as applications. Using one of these, running in its sandbox, a user could parse a rogue PDF safely.

Users who like the relatively sanitary environment of their idevices should care about a fundamental fix. Enterprises should care. Android is too open to ever be trusted. RIMM is struggling just to stay in business. On July 24, 2011 they laid off ten percent of their workforce.

The geeks will whine and complain about any fundamental fix. Steve will tell them that if they want an open system to buy a Mac, hell, even buy an Android. iOS is about as open as it is going to get. I am glad that there are more open alternatives to iOS but not nearly so glad as I am that iOS is closed.

So far this vulnerability has been used by geeks to jail-break. While it might have been used in a few narrowly targeted attacks, it has not been exploited by rogue hackers for widespread attacks.. It is a vulnerability without a threat, not a risk, not a problem. So far.

Until Apple does something more effective than patch, professionals that rely upon iOS to protect the applications and data of their principals must be on the alert for any emergent threat. While we are not happy about it, that is why we are called professionals and are paid the big bucks.

Phone Hacking?

Hey, guys! It's not "phone" hacking. It is "voice-mail" hacking."

How many, besides me, have been hooked this weekend by a headline about "phone hacking" only to say, "Oh, that's what they mean. That's not what I thought they were talking about." I am still doing it. I have done it twice since I got up. Even when I understand that they are simply talking voice-mail, my brain wants to interpret "hacking" as some sophisticated access to the mailbox from the computer side. This does not even involve brute force attacks against the password from the public switched telephone network.

Now you say that I only make this mistake because I am a geek. Perhaps. On the other hand, the average consumer of news may have even less of an idea what the term "phone hacking" means, much less what they ought to do about it. Parsing the words ought to get them closer to an understanding instead of further away.

The popular press does not serve us well when they do this. What language will they use when someone really hacks a phone, like "remote code execution," over the network?

We owe it to the innocent public to identify these attacks in a manner that informs them as to how to address the vulnerability.

"There is no such corrupting lie as a problem poorly named." Using the wrong words to describe something is counter-productive, not to say, destructive. Take, for example, calling cross-site scripting and buffer over-flows "vulnerabilities" rather than "attacks." The real vulnerability is "unchecked inputs." Perhaps one reason that these vulnerabilities are not only persistent, but growing, is that by naming them wrong we obscure the remedy.

Note that the voice-mail boxes are not being hacked via the application programming interface, API, but via the user interface, the UI. Our colleague, Brian Honan, reports from across the pond, that most of these "hacks" are simply using either the default password, or an easily guessed password. Can you say 1111?

We need to describe the vulnerability in a way that helps people protect themselves. I do not use 0416 because that is my birthday. I do not use your birthday either. I do not use any date because a "dictionary" of four digit passwords is going to contain those 365 numbers and will try them right after 1111, 2222,......1234, etc.

I do not do this because I think that a four-digit password is too short; for most people it is probably just fine. However, there are only ten thousand numbers in a four digit-lock-code; on average 5000 (automated) trials should be sufficient to find yours. For most of us, that is probably adequate. It helps if your carrier limits the number of trial.

For celebrities, four digits may not be adequate. As recent events demonstrate, any of us might become a celebrity at any time. Some of us may not want to use standard voice mail and some of us should not. There are viable alternatives.

While I an not a celebrity, I do not use my phone company voice mailbox at all. All of my phone numbers are forwarded to Skype-in. Access to that voice mail box requires a Skype client, my e-mail address, and my 9 character Skype password. Blackberry users can use longer lock-codes chosen from the full character set of the alpha-numeric keyboard. Longer lock-codes do not raise our work factor very much but they raise the cost of attack dramatically.

Four thousand victims of News of the World is a problem, a few of the victims even tragic. There are probably three or four times that many victims of less organized attacks. Good practice can eliminate a large percentage of these. For the rest, there are alternatives. However, the problem is likely to persist until we name and describe the problem in a constructive manner.

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.