Mike Rothman is skeptical that there will be a “security industry”, and I don’t disagree with him.

I think there will be 0 security professionals in 2012. That’s right, ZERO. I think there will be network folks that specialize in security, and also some data center folks and even more application folks that are security specialists. OK, these are word games and a bit of semantics, but I think it’s an important point. If anyone thinks their only job is going to be security in 4 years, I suspect they’ll end up as a petroleum product sooner rather than later. OK, maybe not 2012, but I’m with most of the big mouth security pundits in saying security as a business will be going away within a reasonable long term planning horizon (7-10 years).

Of course, this leads me to wonder who, exactly they think is going to do security work. And by “security work,” I don’t mean running Anti-Virus or pleading with sysadmins to patch their boxes. That’s Console Jockey work and it will go the way of all other Run jobs–overseas and down to helpdesk pay levels. When I talk about Security Work, I mean the job of determining the appropriate level of risk for the organization, then defining the mix of controls and tools across people, process and technology to actually achieve it.

Senior Executives don’t know. They just want to know that they’re not having to explain incidents to the press and that I’m still pushing back on every task because my budget is stretched (their measure of whether or not I’m “appropriately funded”).

IT doesn’t know either. If anything, I’m seeing the competence trend running in the other direction in terms of what it’s reasonable to expect an “IT Person” to know about the technology they’re responsible for. More and more, it’s getting harder to even find anyone who actually does the work of touching the technology. I can find Project Managers, Relationship Managers, Program Managers, Application Managers, Support Managers, and every other kind of manager under the sun. What I can’t find are SysAdmins, DBA’s, Developers, or Engineers, and I find this disturbing.

For example, in a recent discussion of what should be the required fields in our application inventory tool, the question came up as to whether or not the data center where the production environment resides should be required. The answer was, “no,” because apparently that’s too much for a system owner or application support person to know–what building their app’s servers sit in. I wish this were an anomaly, but I’ve seen a steady increase in incidents like these, and not just at my current company, either.

And what tech talent do see, I increasingly wouldn’t bring back from the phone screen if I were the hiring manager. I’ve seen Web developers who didn’t know the difference between the corporate LAN and the Internet from a network visibility/connectivity perspective. I’ve seen support leads who didn’t know how to connect to the application they supported. I’ve seen DBA’s who didn’t know what an index was! These people don’t even understand fundamental aspects of their own core competency and we think they’re going to absorb a volume of knowledge and skills that most specialists can even seem to master?

So who’s going to do this work? The applications aren’t going to secure themselves. This is a simple fact, and even if the application can somehow be declared “secure” (which is to say, “secure enough”) in a vacuum, as soon as it starts interacting with users and other applications, all bets are off. Once again, someone has to decide how much security is enough for those interactions, either by declaring a standard or doing a risk assessment and determining what’s acceptable and what’s not.

While there might not be “Network Security” or “IT Security” as we know it today, I firmly believe that there are still going to be Information Risk and Information Protection specialists at all levels of the organization. Just because we’re going to either evolve beyond the world of Console Jockeys or get a job with Rothman at Dairy Queen doesn’t mean that Security Professionals are going away–quite the opposite, they’re going to have to actually become professionals.

So is all hope lost? Not necessarily. Clay Shirky had some really interesting observations on social surplus which apply here as well. Social Surplus is time that a society no longer needs to spend on some activity. For example, people worked fewer hours in the second half of the 20th century, leaving time that had to be filled. In response, the United States came up with things it sitcoms and yardwork.

So if you take Wikipedia as a kind of unit, all of Wikipedia, the whole project–every page, every edit, every talk page, every line of code, in every language that Wikipedia exists in–that represents something like the cumulation of 100 million hours of human thought. I worked this out with Martin Wattenberg at IBM; it’s a back-of-the-envelope calculation, but it’s the right order of magnitude, about 100 million hours of thought.

And television watching? Two hundred billion hours, in the U.S. alone, every year. Put another way, now that we have a unit, that’s 2,000 Wikipedia projects a year spent watching television. Or put still another way, in the U.S., we spend 100 million hours every weekend, just watching the ads. This is a pretty big surplus. People asking, “Where do they find the time?” when they’re looking at things like Wikipedia don’t understand how tiny that entire project is, as a carve-out of this asset that’s finally being dragged into what Tim calls an architecture of participation.

Now, the interesting thing about a surplus like that is that society doesn’t know what to do with it at first–hence the gin, hence the sitcoms.

(if you want to know where the gin comes in, go read the essay–it’s well worth the time)

But consider that if we switch the scale & topics from “The TV Watching of Population of the United States” to “the use & maintenance of IT,” and then swap Wikipedia with “IT Security,” then other than the scale of it, the same opportunity is out there, if we can figure out how to drive it.

But is it possible to create a Social Surplus within (Enterprise) IT that would be devoted to both improved excellence and ensuring security, rather than just chopped off as cost reduction?

If “elite” military intelligence officers can’t keep from leaking secrets, what hope is there for those of us trying to herd our corporate cats toward improved information protection?

Israel has sentenced a soldier to 19 days in jail for uploading a photograph taken on his military base to the social networking website, Facebook.

The Israeli military declined to comment on the nature of the image, but said the soldier was serving with an elite intelligence unit.

…

The review has found that some troops had posted detailed pictures of air bases, operations rooms and submarines.

Just asking.

Courtesy of Micheal O’Hare are some observations about the Dutch attitudes toward bike theft:

The Dutch are also prosperous, and they have a strong engineering and technology culture, so I was surprised on two visits in the last few years to see that their bikes are all junkers: poorly maintained, old, heavy, three-speeds. The word I used was all: browsing through many hundred bikes in several rack areas, I did not see a single respectable piece of two-wheel gear, just jalopies locked up with hardware a bit more deterrent than a shoelace. I can understand commuter-design bikes with few gears, medium tires, and high handlebars for daily use in a super-flat landscape, but surely some of them would enjoy their commuting time more if they had a good one? And a few jocks would rather zip around on a real road bike than plod on these jeeps?

I asked about this and everyone immediately said “if you had a good bike it would be immediately stolen.”

He’s not convinced, himself:

I think I’ve come upon a national urban legend illusion, perhaps initiated with facts before the era of proper locks, but maintained only by oral tradition and lack of data. I admit I would be a little nervous being the first one putting a nice bike into one of those parking areas, imagining it radiating concentrated “steal me!” homing signals to every malefactor within blocks.

How many security practices and how much opposition to risk taking are resisted in IT because of what are effectively “urban legends?” I can think of lots of them, especially conventional wisdom of what will or won’t improve security, generally formed by either taking a legitimate control or countermeasure and then removing dependent context or ignoring inconvenient facts.

For example:
- Tightly configured firewalls are essential to protect information — Information protection is more of a cultural and domain issue than a technology problem–technology can enable and provide mature/consistent/automated controls, but they only work if the people are making the effort to protect the information. And let’s not begin to discuss the ongoing and growing mis-alignment of network to business boundaries.

- SSL protects information — SSL protects information in transit, but not in-use or at-rest. This is good if you’re trying to protect credentials and adequate if you’re trying to protect, say, your email or credit card number in a vulnerable transport medium such as wi-fi, but beyond that, not so much.

- Compliance makes us secure — I tell someone at least once a week these days that “compliance is an attribute, not a goal.” We don’t do things to be compliant, we do them to be secure and then measure how well we actually did the work to determine compliance. When compliance is the goal, then the floor for effort also becomes the ceiling.

- the legitimacy of most enterprise threats. Sure, there are both external and internal bad actors, but unless you’ve got information with an exchangable cash value (think credit card numbers or enough personal details to access someone’s line of credit), your information is much more at risk

- Pretty much anything related to airport security or “the war on terror” — No one wants to be “the one who relaxed a rule and was wrong,” so the tolerated level of absurdity, doublespeak, and abuse never ceases to amaze me.

Ed Skouris also had searchsecurity article on Worst Practices this week that has some similar thoughts, some of which I even agree with.

I know it’s Friday and my brain is already trying to shift into weekend mode, so what are a few more examples?

The Register had a nice article about a real-world demonstration of why biometrics aren’t the security panacea that so many security practitioners (and vendors) would like to believe.

They start with the the question of who does Wolfgang Schauble call to get his fingerprint reset?

A hacker club has published what it says is the fingerprint of Wolfgang Schauble, Germany’s interior minister and a staunch supporter of the collection of citizens’ unique physical characteristics as a means of preventing terrorism.

As has been debunked more times than I care to link to, terrorists are pretty much never anonymous, but rather tend to be “sleepers” until they act. That’s irrelevant here, though, because I want to look at the inherent weakness of fingerprints as an authentication mechanism:

“The whole research has always been inspired by showing how insecure biometrics are, especially a biometric that you leave all over the place,” said Karsten Nohl, a colleague of an amateur researcher going by the moniker Starbug, who engineered the hack. “It’s basically like leaving the password to your computer everywhere you go without you being able to control it anymore.”

Today, fingerprints are sold to the world as “strong” authentication, but only because no one has really begun using them for value-added activities. Just like the now-infamous Social Security Number, which was simultaneously a semi-public personal attribute and the password for accessing a person’s potential lines of credit, so will the fingerprint die a similar death if it ever begins to gain acceptance as an authenticator for financial transactions.

Going back into history, Once upon a time, A man’s word was his bond. More recently, a signature, usually combined with a belief by the lender in the character of the borrower, was adequate to borrow money. That standard, in turn, went by the wayside as the FICA score took hold. Now, we live with a world filled with identity theft/fraud-by-impersonation driven by automated “instant credit” for anyone with a state ID card and the matching social security number.

The fingerprint will be next, once the value is there. The problem here is the over-reliance on authentication and ignoring the potential for additional compensating controls in the process, such as out-of-band confirmation of the request and the same degree of reasonableness checking. For instance, just as credit card issuers perform to identify potentially fraudulent transactions, why would it make sense to approve instant credit at a Best Buy in Chicao for someone who lives in Texas? (And maybe this is done today, but it wasn’t when I used instant credit to buy appliances during a move a few years ago. It didn’t set off alarm bells when it should have)

Pay-by-Touch, the company that was trying to use fingerprint authentication for point-of-sale transactions has failed because of (I suspect) poor user acceptance–all their scanners had hand-written “no longer available” signs taped over them at the grocery store last weekend.

Now does that mean that we should abandon fingerprint readers entirely? No. It’s potentially-useful in many ways, I just don’t think that this is one of them.

Instead, let’s think about the risks that are mitigated and created by using a fingerprint as authentication factor, given their aptly-noted characteristic that, again, “It’s basically like leaving the password to your computer everywhere you go without you being able to control it anymore.” We tell people, “Don’t write your password on a sticky note and leave it on your computer,” yet with fingerprints, they do exactly that all day, every day, by virtue of using the device.

The effectiveness of biometrics to mitigate authentication risk can be down into two factors, proximity and selection. An attacker remotely and randomly “rattling doors” looking for weak authentication mechanisms (e.g. blank, trivial, or default passwords) is going to get stopped by a biometric authentication system. But, let’s be honest, he’s also going to be stopped by some basic good security practices such as a password complexity requirement and changing all default passwords. So the incremental benefit here is pretty much zero for what’s still a fair amount of effort (although this will continue to drop over time).

Now, let’s consider the opposite case, an attacker in physical proximity to a targeted user. That’s the high-impact scenario, and the one which CCC effectively simulated–and highlighted the weaknesses of fingerprints as a biometric authenticator. In this case, the effective countermeasure–wearing gloves at any time except when authenticating–is not feasible. So the risk will be accepted. There is no other option.

We may understand that a fingerprint may be better than a password alone when it comes to protecting a low-value resource, but worse-than-useless (because of its immutability) when protecting a high-value target where the effort is worthwhile. Unfortunately, this distinction will be swept under the rug by vendor hype as they attempt to maximize the potential market for their products. And when that happens, we will all lose.

I only wonder whether the fingerprint will die a deserved death as an authentication mechanism before or after it’s widely-enough adopted to have allowed significant damage.

As an afterthought, consider the implications once someone takes a fingerprint card and converts that image into something that will fool a scanner–assuming it hasn’t already been done. Think about the millions of people who have had their fingerprints taken, and they tend to be the tails of the population distribution along the security/risk axis–people with criminal records at one end and people with clearances at the other. I’m not going to ponder the implications of that right now, since it’s more of a social and civil liberties issue, only note the possiblity.

I’ve been pretty busy lately, which has impacted, among other things, my time and energy for blogging. I don’t know when I expect this to materially improve, so I’m going to fire these thoughts out before I run off to my next meeting even though they may still be a bit partially-formed.

Lately, I’m feeling that there are two fundamental problems with risk and security metrics.

The first, which I’ve written about previously, is that they don’t scale the corporate ladder well. The second, and perhaps more serious from an industry perspective, is that the metrics which do scale the corporate ladder well don’t compare well across industries or even within industries. Thus, there seems to be a paradox here: the more business value a security metric represents, the less either generic or share-able it will be.

For example, take metrics related to policy compliance, one of my KPI’s. I assume that policy (or lack thereof) is an expression of or proxy for a company’s tolerated level of risk. Given that no two companies have the same policies (unless they both cribbed them whole-cloth from SANS), the risk measurement is going to be inherently different between companies. Throw in the fact that most companies won’t be willing to share this data in anything but a tightly-controlled forum, and you’ve got a real problem.

Nevertheless, I’d still be pretty happy if we could get general agreement (or even understanding) across so-called risk managers that, like it or not, policy effectively defines organizational risk acceptance. With that starting point, we might then actually be able to begin doing meaningful comparisons of different policy/control sets (e.g. does CObIT+SoGP produce better compliance (as measured through audit findings & exceptions) than CObIT+ISO-27001? *That* would be an interesting and worthy research project, IMHO), although the vested interest factor could definitely hurt the effort.

And one final piece of the puzzle (and this is probably too much to even dream of, but keystrokes are cheap) would be to then correlate these measures of relative compliance to operational metrics. While correlation is not causation, we still might then be able to begin using compliance as an attribute to describe our accepted level of risk rather than as an end unto itself.