The Jericho Forum has eleven “Commandments”, the third of which is “Assume context at your peril.”

For example, The Concorde doesn’t have locks on its doors. Nor does the modified Boeing 707 which served as JFK’s Air Force One. Neither plane needed them since, it was assumed, they would always be surrounded by the protective perimeter of airport security and/or the US Secret Service.

Today, however, both of these jets are protected by nothing more than a low chain link fence, security cameras and the guards across the street in the Museum of Flight. The vast majority of the protections which once ensured the integrity (and to a lesser extent, the confidentiality and availability) of these two airplanes are gone. Sure, they’re decommissioned so the pure asset value is reduced (and the cost of protecting them should decrease as well), but both planes still posess significant intangible value as pieces of avaiation history.

I can think of any reasons why the designers wouldn’t have put locks on the plane, such as ensuring that the doors couldn’t be accidentally locked during an emergency, but it still doesn’t change the fact that the plane assumes its environment will protect it from a breach.

Assume context at your peril, indeed.

I have to say that I think last week’s open meeting of the Jericho Forum was the best one yet. I’d like to claim some small credit for that, since I led the first morning’s discussion session on Client Security in a Deperimeterized World (my my slides), but the reality of it was that we had a room full of smart, eloquent people consistently challenged themselves and each other to extend and refine their thinking. Ian Dobson, the forum’s Director, asked for “stimulating” and I told him that I was aiming for “lively.” I think I succeeded and the momentum carried over into the the rest of the sessions as well as the breaks, meals, and drinks.

The official notes aren’t out yet, but the key take-aways that I observed from the participants were. Please correct any mis-perceptions or items I overlooked in the comments. I wasn’t able to take notes since I was busy working the room.

1. Users do not feel that loss of control/functionality for enhanced protection of (corporate) information/resources is an acceptable trade-off. They still want to have their cake and eat it too.
2. People are not sold on DRM. People almost universally felt that it’s still extremely immature and will only be applicable for limited use cases for some time to come. Still, people are not giving up on it, but rather taking a wait-and-see approach There was agreement that data needs to be able to “defend itself” and we can’t count on the client to provide a secure environment, including TPM. There was also some discussion (but no clear agreement) as to how much this is a People Problem and how much is a Technology Problem, and where the point of diminishing returns on efforts to tackle either problem will eventually settle.
3. NAC is not the answer. If anything, it’s the anti-deperimeterization.
4. Microsoft-y protocols are sill hard (Domain traffic, NetBIOS, etc). Some of the MS people disputed this, but about half of the MS people in attendance agreed that, even if it’s possible (with lots of ISA servers & effort), protecting the traffic is still too hard for general IT use.

In general, I’m seeing a growing awareness of deperimeterization in both the IT and business worlds today. With growing frequency, when I talk to people about their information security issues, they’re now aware that those issues are often related to the eroding perimeter, they just didn’t know it had a name. This is a big change from a year ago, when most people I spoke with still weren’t even aware there was a problem.

I’ll be attending the next open meeting of the Jericho Forum in Seattle, Washington next Thursday and Friday. Feel free to join us if you’re in the area and interested in attending. Our generous hosts at Boeing (who are very involved in the Jericho Forum) have even arranged access to the Museum of Flight, which I’m told is a Good Thing if you’re even a little bit of an aviation geek.

Also, I’ll be giving a presentation on “Client Security in the Deperimeterized World” and facilitating a discussion session on Thursday morning. Hopefully I’ll have good insights to report back with afterwards.

I want to pick back up on the discussions from a week or two ago about what threats authentication can protect against. The driver for two-factor authentication to protect on-line banking from phishing attacks is that it makes phishing harder, but this has already been broken up to and including Secured Hard Tokens.

As I see it, this should really be a wake-up call that the security industry’s authentication strategy needs to say (among other things), it’s time to get over the obsession with authenticating the User and focus instead on the actual threats. First, we should be deploying & using mutual authentication. The reason that Man-in-the-Middle attacks work is because it’s easy to impersonate a server

Overcoming this inertia is going to be hard, because there are a lot of vendors making a lot of noise about how all we need is stronger authentication, by which they usually mean moving away from free credentials (passwords) to expensive credentials (tokens, biometrics, or commercially-issued certificates) which they, of course, would like to sell us.

That’s not to say that there’s not a lot of value in the second factor, but more in some cases than others. Two-factor, combined with pre-shared keys to perform mutual authentication provides excellent protection for VPN connectivity. But in phishing, Two-factor only raises the bar for an attacker, and only to the extent of filtering out the dumb ones. Even they will get toolkits in six months or so, though, and fraud will return to “normal” levels.

Unfortunately, the reason that free credentials seem to be failing is generally because people lack the necessary sophistication to protect them, not because they’re somehow inherently weak. Application vendors are trying to solve this problem (Both Firefox 2.0 and IE 7 are both going to have anti-phishing features). This may help, but only by minimizing the impact of the weakness between the keyboard and the chair, not the client and the server.

The best way to tackle this problem is to minimize the reliance on the weakest link (the user). I don’t claim to have a solution (other than pre-shared keys or some sort of meaningful large-scale PKI, and anyone who reads this ‘blog probably rolled their eyes as soon as they read those words), but If we can get general agreement that there is a problem, then there will be demand (paying customers) for a solution and one will turn up sooner than later.

Personally (and I know I have a bit of a bias here, being a big de-perimeterization fan), I think that another problem we should be taclking is the that endpoint location should be irrelevant. Within the corporate world, we operate under the paradox that we don’t consider “somewhere you are” to be an authentication factor, then structure most of our risk and security assumptions around which network the endpoints are on (Internet, Intranet, DMZ, etc.). I know it will take significant architectural changes to get to an endpoint-agnostic model, but every journey begins with a single step.

Finally, I believe we should apply security as close to the data as possible, which is fairly congruent to “Location should be irrelevant.” How does stronger authentication move security closer to the data?

As to what we can do about it, I think that promoting protocols which support Mutual Authentication (and using them) should be a key tactical goal for the security profession. This is something we can do today which would will put us ahead of the game longer-term as the security assumptions inherent in “somewhere you are” evaporate.

Eventually, we will be forced by events to secure both high-value transactions and high-volume micropayments (think vending machines). We need to be ready for either or both of those, and the current obsession with stronger authentication isn’t going to get us there.

So here are some Real World goals I suggest we should be looking at.

1. Improved authentication should focus on (cryptographically) strong Mutual Authentication, not just improved assertion of user Identity. This may mean shifts in protocols, it may mean new technology. Those are implementation details at this level.
2. We need to break the relationship between location & security assumption, including authentication. Do we need to find a replacement for “somewhere you are?” And if so, is it another authentication factor?
3. How does improved authentication get protection closer to the data? We’re still debating types of deadbolts for our screen door rather than answering this question.

It’s not as fun to read as Dr. Seuss, but in October 2005, the FDIC declared single-factor authentication inadequate for online banking authentication:

• Single-factor authentication methodologies may not provide sufficient protection for Internet-based financial services.
• The FFIEC agencies consider single-factor authentication, when used as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
• Risk assessments should provide the basis for determining an effective authentication strategy according to the risks associated with the various products and services available to on-line customers.

IanG at Financial Cryptography recently noted and added valuable commentary to a WashingtonPost.com blog entry about how phishers have already adapted to this countermeasure WaPo sets it up:

The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit — a tactic used by some security-savvy people — you might be fooled. That’s because this site acts as the “man in the middle” — it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real.

But IanG adds the value:

More bad news for suppliers of 2-factor tokens and also US Banks which got a quasi-recommendation to implement something like this. I say, quasi-something, because the FDIC carefully did not recommend any specific technology, choosing instead to recommend that banks carefully review their _risk-based exposure_. The banks themselves may have assumed tokens or similar, for whatever reason.

(emphasis mine)

Of course, you would never know that the official guidance specified only that the bar had been raised (no more single-factor), not what it had been raised to (Buy two-factor authentication products!) unless you went and read the guidance document itself–not a difficult task since it’s only one page long and it’s the first result if you google for “fdic authentication”. (The Account Hijacking page is the second link, btw)

Also interesting, though, is that the FDIC did recommend two-factor authentication–in December 2004! If you look at “Putting an End to Account-Hijacking Identity Theft, an allegedly consumer-targeted page (but which talks a lot about things like log analysis and infrastructural analysis opportunities), they say:

Financial institutions and government should consider a number of steps to reduce online fraud, including:

1. Upgrading existing password-based single-factor customer authentication systems to two-factor authentication.

Of course, that report also speaks well of SenderID, so we would all be well-served to remember what become of that Silver Bullet.

Personally, I agree with IanG. It’s not the FDIC’s place to provide prescriptive guidance in this situation. It’s one thing to provide a common problem statement, “Single-factor authentication is not adequate.” Unfortunately, the people least likely to understand that there are many ways to provide a second authentication factor besides hard tokens are also the ones most likely to fall for the vendor pitch that some sort of hard token is the only second factor.

I will never know why the FDIC decided to pull back from “upgrade…to two-factor” to, “Risk assessments should provide the basis for determining an effective authentication strategy,” but I strongly believe it’s the appropriate approach to the problem. Banks do a lot of things, some visible and some not-so-visible, to reduce the risk of a successful breach (successful probably being defined as funds successfully transferred beyond recovery or large-scale enough to make the press). Since no two banks have the same set of risks and countermeasures (remembering that risk is the combination of asset value, threat & probability along with varying opinions of what is or is not an externality), no two banks should come to the same exact solution set, even if their risk position seems identical to an outsider.

Maybe someone pointed out that they guidance would remain and still be adhered to by the less-informed long after it had been overtaken by events. To reinforce that argument, on October 12th, 2005 (the same day that FIL-103-2005 was published), the Register had a story about phishers successfully compromsing a one-time/scratchpad system in Sweden. Perhaps a coincidence, but it would have been a bit ironic if the FFIEC had issued prescriptive guidance at the same time as that guidance (in the absence of other compensating controls) was shown to be inadequate.

John Quarterman at Perilocity has now picked up on this, as well.

Updated: Fixed the missing link, added a title and intro tie-in

Maybe it’s because we’ve been hiding behind oceans for the past few hundred years, or maybe it’s because we’ve never gotten to experience fixed fortifications failing in practice, but I would say that America is generally lagging Europe in thinking about deperimeterization.

Yesterday was another Jericho Forum meeting, this one in Chicago. Nowhere near as much attendance, although part of that was almost certainly the fact that it was not in close physical and temporal proximity to a major security trade show.

Jericho is going to have a major presence at Black Hat, including a half-day session as part of the training courses. I don’t have any more information than that, but I’m interested to see what the interest level and turn-out look like there.

Also, in late September, Boeing will be hosting a Jericho meeting and work session in Seattle, Washington and at least the first day of it will be open to all interested parties, meaning you have plenty of time to convince your boss to approve travel.

No great quotes this time around, but I’m starting to feel like I have a pretty firm grasp of what enterprises reasonably can and can’t expect to accomplish at both the business and technical levels around deperimeterization at this time.

I’m also noting a couple of trends that I’m seeing play out, both in my own efforts as well as at other companies. These are based on some work sessions held before the main meeting as well as lunch/drinks/dinner conversations over the past few days.

Things we can do:

• Protect an application’s infrastructure by applying the principle of Least Privilege at the network layer.

  This is done at the perimeter today with the granularity pretty much being “in the building or possessing a VPN account” and “everyone else in the world.” This is a level of granularity historically chosen because anything more complex was unmanagable (see “Things we can’t do”).

  Diana Kelly of the Burton group referred to this as “Deep Perimeterization” last year, referring to the fact that in its crudest form, it’s just sticking a firewall between the application and the internal network. I agree that’s a part of it, but only a small part.

  Firewalls were a stop gap until secure protocols were developed twelve years ago, and they still are today.

• Protect applications, even insecure and poorly-written applications. This is where application layer gateways and protocol-aware inspection comes to play.
• Utilize secure (Confidential, authenticated, integrity maintained) protocols (i.e. ssh over telnet) or wrap less secure protocols to achieve an acceptable level of security (i.e. tunneling things inside SSL), even without ubiquitous authentication or robust applications.

Things we can’t do:

• Pretty much any of these things cheaply or without exotic (start-up) technology
• Manage access effectively. This problem will only be solved once we’re able to provision access based on structures that are meaningful to The Business. This will be a painful process, but it’s do-able.

  For example, all provisioning of user privilege within my corporate financial systems is performed by “Functional,” not IT people. It works because Oracle defines roles (”responsibilities,” in Oracle-speak) which are meaningful to those functional people. The responsibility is something like “Accounts Payable Approver,” not GRANT EXECUTE ON PROC ORA_FIN_P.AP_APPROV TO howellc–that’s the magic of provisioning (along with approval workflow, unified views of access, and lots of other neat bits, but what people care about is that good provisioning systems mean they don’t have to know what they need to get what they want).

  Identity Management is expected to be the silver bullet to solve these problems, but it still doesn’t change the fact that someone will still have to determine what “Provision New User->Finance->AP Approver” translates into as a set of network ACL’s (Open access to Oracle Financials), host security controls (SMS push of full-disk encryption software and a PGP plug-in for outlook), and accounts and responsibilities within the Oracle App itself.

• Protect information from abuse by end-users.
  Technologically, this is the realm of DRM and I just posted my thoughts on that separately

There are a lot of smart people doing a lot of good work to tackle all of these problems, most of them in the Real World rather than on paper. The next Jericho meeting will be next month in the England and I’ll have my next update then.

As Saso pointed out in one of his always-appreciated comments on deperimeterization,

What I find quite remarkable is our inability to learn from other people’s experiences. Take castles as prime examples of how layered security should work. Those that were built by masters of their art are still around (if they weren’t used later on as source of building stones for houses around the area, that is), to show how a good defense in depth works. There’s the perimeter layer, a hard-to-pass (unnoticed) area; then there’s first perimeter, with strong defences; then there’s second perimeter, in case first gets breached; … and all that is usually overseen by corner towers that can only reached via a staircase that winds clockwise, to hamper attacker’s sword wielding.

Alas, many took the “we have a firewall, we’re secure” approach and then shot holes right through their perimeter walls. :-)

Personally, I dislike the whole castle analogy. As soon as you expand it beyond the idea of an outer curtain and inner keep, the whole analogy breaks down.

What’s the analog to the towers? IPS? That would only be the case if archers were blind and half of them were firing indiscriminately into the courtyard.

But as it is, I agree that the best analog we have is that we’ve already used the stones from the outer curtain to build our businesses and punched windows through the walls of the keep so we can see out and let light and fresh air in.

If I actually had some good analogs to boiling oil or a cavalry counterattack, I might be on-board with the whole castle analogy. But as it is, I’m just reminded that for all their effectiveness in preventing an attack, a defensively-sound castle is a dark, smelly, cramped and generally miserable place to live. If you’ve ever lived behind an “effective” firewall, your IT experience was probably quite similar.

Image of Middleham Castle courtesy of flickr.

Alex Hutton just asked me an interesting question in comments:

Do you specifically separate Information Security and IRM? Why and how?

I know plenty of people who will argue that Security is more than what I’m outlining, but I’ve found that in practice, this generally seems to be the boundary around the thought processes of those practitioners I know who self-identify as “Information Security” as compared to Risk Managers (of which there are numerous flavors).

Short Form: Information Security locks up information to keep it safe, whether or not that’s the best thing to do with it. Information Risk Managers figure out the best way to preserve the value of the information, which may or may not include locking it up.

To me, though, Security is a subset of IRM. There are many things you can do to preserve information’s value that have nothing to do with securing it, such as Transferring or Accepting the risk.

Long Form:

Information Security is the practice of designing and implementing countermeasures and other preventative (usually technical) controls on information. Security experts tend to understand the nuances of their tools, but all-too-often fall prey to the adage that, “When your only tool is a hammer, ever problem begins to look a lot like a nail.”

Information Risk Management (IRM) is the practice of determining which Information Assets need protection and what level of protection is required, then determining appropriate methods of achieving that level of protection by understanding the applicable vulnerabilities, threats and countermeasures.

To practice IRM successfully means understanding not just the technologies that enable communication but also the business that the communication enables, the applicable regulatory environment, how information is utilized, the circumstances under which it might have value to an attacker, and how to balance those variables based on the risk appetite and cost-consciousness of the business.

Note: Before anyone breaks out their asbestos keyboards, please recall that these are my definitions. If you don’t like them, feel free to try something non-’Net-like, which is to say constructive ;-), and add a comment with your own definitions.

Finally, now that I’ve written my defnitions, here are Wikipedia’s Information Security

Information Security deals with several different “trust” aspects of information. Another common term is information assurance. Information security is not confined to computer systems, nor to information in an electronic or machine-readable form. It applies to all aspects of safeguarding or protecting information or data, in whatever form.

The U.S. National Information Systems Security Glossary defines Information systems security (INFOSEC) as:

the protection of information systems against unauthorized access to or modification of information, whether in storage, processing or transit, and against the denial of service to authorized users or the provision of service to unauthorized users, including those measures necessary to detect, document, and counter such threats.

Most definitions of information security tend to focus, sometimes exclusively, on specific usages and, or, particular media; e.g., “protect electronic data from unauthorized use”. In fact it is a common misconception, or misunderstanding, that information security is synonymous with computer security—in any of its guises: computer and network security, information technology (IT) security, information systems security, information and communications technology (ICT) security. Each of these has a different emphasis, but the common concern is the security of information in some form (electronic in these cases): hence, all are subsets of information security. Conversely, information security covers not just information but all infrastructures that facilitate its use—processes, systems, services, technology, etc., including computers, voice and data networks, etc.

and Risk Management pages

Generally, Risk Management is the process of measuring, or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments. Intangible risk management focuses on the risks associated with human capital, such as knowledge risk, relationship risk, and engagement-process risk. Regardless of the type of risk management, all large corporations have risk management teams and small groups and corporations practice informal, if not formal, risk management.

In ideal risk management, a prioritization process is followed whereby the risks with the greatest loss and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled later. In practice the process can be very difficult, and balancing between risks with a high probability of occurrence but lower loss vs. a risk with high loss but lower probability of occurrence can often be mishandled.

for comparison.

I just wrapped up the day at the Open Group’s Jericho Forum Annual Meeting.

Lots of good work has been going on within the Forum’s working groups. Unfortunately, other than attending the meetings and carrying the deperimeterization torch back in the office, I haven’t done anything to advance any of it. Many people I speak with looked at the forum’s work early on and wrote it off. I strongly suggest that you take another look if this is an area that interests or affects you.

I think my favorite quote of the day came from Nick Bleech, CSO of Rolls-Royce, who said, “Deperimeterization is happening. It’s not a strategy, it’s an ‘-ization.’ It’s like globalization–it’s happening.”

In the corporate environment, assets can be protected at various levels, ranging from an individual column of a database all the way up to the entire company. Traditionally, IT assets have been protected from outsiders at the network perimeter by firewalls and at the host or application level with passwords.

If perimeter firewalls are the Maginot Line, then most of us are still in the Sitzkrieg, waiting for the killer app or killer business change that’s going to fly over or roll around the perimeter firewall like it’s not even there.

Did you laugh the first time you heard HTTPs referred to as, “Universal Firewall Bypass Protocol?” If so, then you should realize that the waiting is over, you just haven’t noticed it yet.

The good news is that the frameworks and architectures necessary to move this from users “self-enabling” to something that the company can actually manage are about ready. Most of the “hard” problems seem to be well-enough under control from a technical perspective, meaning it’s time to see what happens at the business layer.

And that where the real fun begins. What are the implications of eroding perimeter controls to the business? What new risks are emerging that are not currently being identified, measured and managed as a result? What opportunities are also emerging, and what are the tradeoffs between the two going to look like?

Consider the outsourcing arrangements this makes possible if you can now offer technical controls to (you think) adequately protect your data in an outsourced environment. But how do you either make sure that your lowest-cost provider isn’t going to re-outsource your work to someone else in turn or manage the increase in risk incumbent in doing so? How much of a premium are you willing to pay the outsourcer for that extra restriction? How much should you be willing to pay?

Deperimeterization is increasing volatility in the business world. Businesses need to decide how they’re going to manage the increased risk that comes with it. Will they attempt to mitigate the risk and put the genie back in the bottle? That may work for a while, but only until someone else accepts it, takes bet and wins. At that point, those who chose mitigation are no longer competitive and it’s game over for them. Now that is truely “Security as an Enabler.”

What a great time to be in the Information Risk Management business.

John Pescatore breaks down phishing, pharming, spam, viruses, and the rest of the social engineering-related Badness starting with his generation and working his way down, finally thinking about the children.

As today’s 9 year olds start using the web, they will be even more suspicious of what they see on their always online PC screen.

This could mean that 10 years from now, as today’s 19 year olds become tomorrow’s 29 year old office workers, that viruses and phishing attacks will be so over - routinely ignored by the targets. Or it could mean that Moore’s and Metcalfe’s laws will give the attackers more ways to create more clever attacks and fool the next generation.

I’m betting on the latter - and not just for job security. Think about the advertising market - they basically have the same problem the online criminals do. They have to try to drive your behavior by showing you a billboard, a TV or newspaper or online ad, or having you listen to an audio ad. They have to trick you into believing that their toothpaste is different than the other 92 brands or that their lite beer will cause Baywatch babes to mudwrestle at the next table over.

I’ve been using email for since I got started with FIDONet over a Hayes Smartmodem 300, or about 70% of my life. I’m in the missing generation of John’s post, which means that I got to see all the Bad Things that could happen even without widespread access to IP networks or the Web.

This includes fun things like having to virus scan a thousand floppies to make sure that you wipe out the office’s Stoned outbreak.

It’s too bad I didn’t have a blog at the time on which to complain about it. Ah, what posts those would have been…
(more…)