Clive Robinson writes in comments, and I can do little more than post it as a special Friday 13th edition. Good luck: The problem of spend too little, get hurt, spend too much, waste resources unprofitably is older even than money. It is the basic problem with all defensive behaviour. If you go back to the times of the hunter-gather the gathers had an issue (as do all prey): if you put all your resources into gathering then you will not see the predator stalking you. If all gathers spend their time looking for predators, then no gathering will occur and they will starve. Thus there is some trade-off towards an optimum value of lookouts for any given predator, terrain or group size of gathers. Interestingly the optimum is usually less than four, for all predators and group sizes that fit within a moderate shout range in open terrain. For larger groups, it is usually the number of watchers that will go around the edge of the group and remain within moderate shout range in open terrain. In closed terrain it depends not on shout distance but visual distance. Which is why you get very large groups (antelope, etc) in the open savanna, but much smaller-sized groups (monkeys) in closed areas such as scrub and forest, etc. Now the important thing to notice is that the number of watchers goes up at a very very small fraction of the number of gathers. All of which is why traditionally we have looked at perimeter defence. However it has a physical assumption underlying it which is locality which further assumes visibility. In a network environment with 0-day attacks, everywhere that is connected is local. Thus perimeter defence only works with visible attack vectors (i.e. those that are known or exhibit behaviour that is sufficiently different from the norm to be detected). Thus there are three basic classes of attack vector, Known (i.e. known knowns). Visible (i.e. unknown knowns). Unknown (unknown unknowns). Within reason the Known Class can be correctly defended against with up-to-date Anti-malware, without effecting the day-to-day activities of a host (within the network perimeter). A simple http://en.wiktionary.org/wiki/measurandmeasurand for this class is the number of attacks stopped. Again within reason, the Visible Class may be mitigated against using various probabilistic techniques. This however may well involve considerable delay (with respect to attack time, not human time) and require isolation or quarantining hosts within the network perimeter which will usually negatively impact day-to-day activities of a host (within the perimeter). A simple measurand for this class is the number of events detected, a more difficult but more useful measurand is to distinguish between the positives (i.e. those that are seen and are proven to be attacks, those that are seen and assumed to be attacks and those that are seen and proven to be false alarms). At first sight the Unknown Class cannot be defended against because there is nothing to see thus detect. Therefore the only perimeter possible is a perfect air gap which in current times makes a significant impact on some day to day activities of the hosts on such networks. Because there is nothing to see it could be argued that there is no measurand. Setting the resource line should place it between the Visible and Unknown classes, but in most cases, resource restrictions actually puts it between the Known and Visible classes. The question then arises, is the Unknown class really unknown? The answer is probabilistic or a Qualified No. If an attack does not copy any host data and does not modify any host or its data and does not impact a hosts day-to-day activities, then its impact inside the perimeter is negligibly small at that point in time (it might for arguments sake use spare CPU cycles and memory to crack password files from another location). Such activity might be very difficult but not impossible to spot. Currently, with monolithic executable files and current operating systems, it is effectively not possible to spot. However there is a way that this problem can be resolved but it requires a different computing platform methodology both in hardware and software. At which point, Clive stopped, leaving us dangling :)...

35 posts remaining…

Samy is awesome. If you missed his preso at Blackhat and DefCon, you missed out. You should try to get the DVD just to hear him. It’s hilarious. I’m not just saying that because he was using me as a fake case study or anything, it really was hilarious. Anyway, we got to talking and it occurred to me that it wasn’t super easy to automate his PHP session ID attack because it requires some social engineering to get the IP address of the user that you want to hijack. Well, after thinking I think I came up with a way around that in some cases.

There are a ton of sites these days that use load-balancers in front of them. There’s a few ways they can be installed - completely transparent or acting more like a proxy. The proxy is the more common setup but it has one pretty huge negative side-effect, all the IP addresses come to the server as just one - the internal IP of the load balancer. Normally that’s not a huge deal because the load-balancer does the logging or it sets some custom HTTP header that is properly logged. But PHP doesn’t know about any of that - it’s dumb. It’ll take whatever value it sees as the IP address and apply it to the session ID algorithm. So now instead of having to guess the entire IP space of the Internet, you now have to just guess RFC1918 - and probably realistically a much smaller slice of that in most cases.

Although that setup is pretty common, there is still one drawback. For Samy’s exploit to work you need to know when someone logged in (down to the second, preferably) to remove enough entropy to make it worthwhile to attack. So this still isn’t easily turned into an automated exploit, but we’re slowly but surely getting there.

Another metaphor (I) that has gained popularity is that Infosec security is much like war. There are some reasons for this: there is an aggressive attacker out there who is trying to defeat you. Which tends to muck a lot of statistical error-based thinking in IT, a lot of business process, and as well, most economic models (e.g., asymmetric information assumes a simple two-party model). Another reason is the current beltway push for essential cyberwarfare divisional budget, although I'd hasten to say that this is not a good reason, just a reason. Which is to say, it's all blather, FUD, and oneupsmanship against the Chinese, same as it ever was with Eisenhower's nemesis. Having said that, infosec isn't like war in many ways. And knowing when and why and how is not a trivial thing. So, drawing from military writings is not without dangers. Consider these laments about applying Sun Tzu's The Art of War to infosec from Steve Tornio and Brian Martin: In "The Art of War," Sun Tzu's writing addressed a variety of military tactics, very few of which can truly be extrapolated into modern InfoSec practices. The parts that do apply aren't terribly groundbreaking and may actually conflict with other tenets when artificially applied to InfoSec. Rather than accept that Tzu's work is not relevant to modern day Infosec, people tend to force analogies and stretch comparisons to his work. These big leaps are professionals whoring themselves just to get in what seems like a cool reference and wise quote. "The art of war teaches us to rely not on the likelihood of the enemy's not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable." - The Art of War The Art of SunTzu is not a literal quoting and thence mad rush to build the tool. Art of War was written from the context of a successful general talking to another hopeful general on the general topic of building an army for a set piece nation-to-nation confrontation. It was also very short. Art of War tends to interlace high level principles with low level examples, and dance very quickly through most of its lessons. Hence it was very easy to misinterpret, and equally easy to "whore oneself for a cool & wise quote." However, Sun Tzu still stands tall in the face of such disrespect, as it says things like know yourself FIRST, and know the enemy SECOND, which the above essay actually agreed with. And, as if it needs to be said, knowing the enemy does not imply knowing their names, locations, genders, and proclivities: Do you know your enemy? If you answer 'yes' to that question, you already lost the battle and the war. If you know some of your enemies, you are well on your way to understanding why Tzu's teachings haven't been relevant to InfoSec for over two decades. Do you want to know your enemy? Fine, here you go. your enemy may be any or all of the following: 12 y/o student in Ohio learning computers in middle school 13 y/o home-schooled girl getting bored with social networks 15 y/o kid in Brazil that joined a defacement group ... Of course, Sun Tzu also didn't know the sordid details of every soldier's desires; "knowing" isn't biblical, it's capable. Or, knowing their capabilities, and that can be done, we call it risk management. As Jeffrey Carr said: The reason why you don't know how to assign or even begin to think about attribution is because you are too consumed by the minutia of your profession. ... The only reason why some (OK, many) InfoSec engineers haven't put 2+2 together is that their entire industry has been built around providing automated solutions at the microcosmic level. When that's all you've got, you're right - you'll never be able to claim victory. Right. Most all InfoSec engineers are hired to protect existing installations. The solution is almost always boxed into the defensive, siege mentality described above, because the alternate, as Dan Geer apparently said: When you are losing a game that you cannot afford to lose, change the rules. The central rule today has been to have a shield for every arrow. But you can't carry enough shields and you can run faster with fewer anyhow. The advanced persistent threat, which is to say the offense that enjoys a permanent advantage and is already funding its R&D out of revenue, will win as long as you try to block what he does. You have to change the rules. You have to block his success from even being possible, not exchange volleys of ever better tools designed in response to his. You have to concentrate on outcomes, you have to pre-empt, you have to be your own intelligence agency, you have to instrument your enterprise, you have to instrument your data. But, at a corporate level, that's simply not allowed. Great ideas, but only the achievable strategy is useful, the rest is fantasy. You can't walk into any company or government department and change the rules of infosec -- that means rebuilding the apps. You can't even get any institution to agree that their apps are insecure; or, you can get silent agreement by embarrassing them in the press, along with being fired! I speak from pretty good experience of building secure apps, and of looking at other institutional or enterprise apps and packages. The difference is huge. It's the difference between defeating Japan and defeating Vietnam. One was a decision of maximisation, the other of minimisation. It's the difference between engineering and marketing; one is solid physics, the other is facade, faith, FUD, bribes. It's the difference between setting up a world-beating sigint division, and fixing your own sigsec. The first is a science, and responds well by adding money and people. Think Manhattan, Bletchley Park. The second is a societal norm, and responds only to methods generally classed by the defenders as crimes against humanity and applications. Slavery, colonialism, discrimination, the great firewall of China, if you really believe in stopping these things, then you are heading for war with your own people. Which might all lead the grumpy anti-Sun Tzu crowd to say, "told you so! This war is unwinnable." Well, not quite. The trick is to decide what winning is; to impose your will on the battleground. This is indeed what strategy is, to impose ones own definition of the battleground on the enemy, and be right about it, which is partly what Dan Geer is getting at when he says "change the rules." A more nuanced view would be: to set the rules that win for you; and to make them the rules you play by. And, this is pretty easily answered: for a company, winning means profits. As long as your company can conduct its strategy in the face of affordable losses, then it's winning. Think credit cards, which sacrifice a few hundred basis points for the greater good. It really doesn't matter how much of a loss is made, as long as the customer pays for it and leaves a healthy profit over. Relevance to Sun Tzu? The parable of the Emperor's Concubines! In summary, it is fair to say that Sun Tzu is one of those texts that are easy to bandy around, but rather hard to interpret. Same as infosec, really, so it is no surprise we see it in that world. Also, war as a very complicated business, and Art of War was really written for that messy discipline ... so it takes somewhat more than a familiarity from both to successfully relate across beyond a simple metaphor level. And, as we know, metaphors and analogues are descriptive tools, not proofs. Proving them wrong proves nothing more than you're now at least an adolescent. Finally, even war isn't much like war these days. If one factors in the last decade, there is a clear pattern of unilateral decisions, casus belli at a price, futile targets, and effervescent gains. Indeed, infosec looks more like the low intensity, mission-shy wars in the Eastern theaters than either of them look like Sun Tzu's campaigns....

One of the things that has been pretty much standard in infosec is that the risks earnt (costs incurred!) from owning a Mac have been dramatically lower. I do it, and save, and so do a lot of my peers & friends. I don't collect stats, but here's a comment from Dan Geer from 2005: Amongst the cognoscenti, you can see this: at security conferences of all sorts you’ll find perhaps 30% of the assembled laptops are Mac OS X, and of the remaining Intel boxes, perhaps 50% (or 35% overall) are Linux variants. In other words, while security conferences are bad places to use a password in the clear monoculture on the back of the envelope over a wireless channel, there is approximately zero chance of cascade failure amongst the participants. I recommend it on the blog front page as the number 1 security tip of all: #1 buy a mac. Why this is the case is of course a really interesting question. Is it because Macs are inherently more secure, in themselves? The answer seems to be No, not in themselves. We've seen enough evidence to suggest, at an anecdotal level, that when put into a fair fight, the Macs don't do any better than the competition. (Sometimes they do worse, and the competition ensures those results are broadcast widely :) However it is still the case that the while the security in the Macs aren't great, the result for the user is better -- the costs resulting from breaches, installs, virus slow-downs, etc, remain lower [1]. Which would imply the threats are lower, recalling the old mantra of: Business model ⇒ threat model ⇒ security model Now, why is the threat (model) lower? It isn't because the attackers are fans. They generally want money, and money is neutral. One theory that might explain it is the notion of monoculture. This idea was captured a while back by Dan Geer and friends in a paper that claimed that the notion of Microsoft's dominance threated the national security of the USA. It certainly threatened someone, as Dan lost his job the day the paper was released [2]. In brief, monoculture argues that when one platform gains an ascendency to dominate the market, then we enter a situation of particular vulnerability to that platform. It becomes efficient for all economically-motivated attackers to concentrate their efforts on that one dominant platform and ignore the rest. In a sense, this is an application of the Religion v. Darwin argument to computer security. Darwin argued that diversity was good for the species as a whole, because singular threats would wipe out singular species. The monoculture critique can also be seen as analogous to Capitalism v. Communism, where the former advances through creative destruction, and the latter stagnates through despotic ignorance. A lot of us (including me) looked at the monoculture argument and thought it ... simplistic and hopeful. Yet, the idea hangs on ... so the question shifts for us slower skeptics to how to prove it [3]? Apple is quietly wrestling with a security conundrum. How the company handles it could dictate the pace at which cybercriminals accelerate attacks on iPhones and iPads. Apple is hustling to issue a patch for a milestone security flaw that makes it possible to remotely hack - or jailbreak - iOS, the operating system for iPhones, iPads and iPod Touch. Apple's new problem is perhaps early signs of good evidence that the theory is good. Here we have Apple struggling with hacks on its mobile platform (iPads, iPods, iPhones) and facing a threat which it seemingly hasn't faced on the Macs [4]. The differentiating factor -- other than the tech stuff -- is that Apple is leading in the mobile market. IPhones, in particular, have become a pop culture icon in the U.S., and now the iPad has grabbed the spotlight. "The more popular these devices become, the more likely they are to get the attention of attackers," says Joshua Talbot, intelligence manager at Symantec Security Response. Not dominating like Microsoft used to enjoy, but presenting enough of a nose above the pulpit to get a shot taken. Meanwhile, Macs remain stubbornly stuck at a reported 5% of market share in the computer field, regardless of the security advice [5]. And nothing much happens to them. If market leadership continues to accrue to Apple in the iP* mobile sector, as the market expect it does, and if security woes continue as well, I'd count that as good evidence [6]....

Here is an interesting question: why is it in IT we allow our managers to let their specialist technology skills lapse?
That doesn't happen in other disciplines as much. In marketing, you can still talk marketing even if you're running a whole division. Otherwise, you can't run marketing.
If you're an economist, even if you are the Chief Economist in a bank, you're still an economist. Otherwise, you don't know enough to approve the forecasts on which the whole business is based.
And if you're a medical doctor, you keep up to date with the latest advances, particularly if you have to teach. Otherwise you lose your right to practice altogether.
Not so in IT, where we do something quite different.
You learn your skills, probably getting more and more technical as your skill set specialises. To get ahead, you have to be the best person in some particular discipline. World best technologists are treated almost as if they're rock stars, commanding big audiences whenever they can be convinced to appear in public. Getting ahead in IT is a race to specialism, as it is in any other industry.
But then we get to that inflection point where we ask people in IT to become managers. That's when things change. What happens then is you have a race to be as generalised as possible. The more generalised you get, and the larger the number of non-technical functions you get hold of, the more successful you are. Scope of control is the measure of success for an aspiring IT Manager.
Suddenly, its OK to lose your knowledge of the current state of the art. It's OK to have to rely on less experienced people to make critical decisions because you're no longer current enough to make them yourself. It is almost a badge of honour, in fact: managers who are too technical aren't seen to be effective, because they haven't risen above their roots.
Can you imagine all that being OK if you were a senior medico?
So here's the question I'm posing today: should we allow managers to lack currency in a discipline that touches almost all others in some way?
I know the standard argument: the pace of change is such that its impossible to keep up to date in various technologies and still do the day job. 
There's another standard argument as well: you don't need technical knowledge to effectively manage IT staff.
But I'd like to make an observation: many of the critical decisions which relate to major IT estates in large organisations both private and public are made behind closed doors by managers, who probably don't have access to their staff at the precise moment they are called on to decide something. Nothing unusual about that: quite often critical decisions can't be shared widely for lots of sensible reasons.
But this means managers either have enough residual knowledge to guess at the correct answer, or they guess at the answer regardless of correctness.
So, is it OK for this to happen? I'd be interested in your thoughts.

36 posts left, and counting…

If I had more time on my hands this would have been a fun one to play with. Although OWASP has dropped information leakage from their list of top 10, it’s still a fun puzzle to put together if you can gather tidbits of info. Johnny Long specializes in piecing together small seemingly inconsequential pieces of info against a target. I wish I could find the paper on it, but many years ago there was a paper describing one technique to unblur text in an image. The basic technique, if memory serves, was that you could take each character in the font in question, blur that font and see what it ended up looking like. By comparing the blur your just created with the blur in the image you could figure out each character.

When Vista came out it shipped with a default theme called Aero, which made semi-transparent windows. The semi-transparency uses both an overlay of a dithered color scheme as well as blur. The dither may be the harder of the two to overcome because it’s dithered based on the width of the window itself and it changes depending on the focus of the window in question. The blur, however, is probably the easiest. Windows uses a default font for most applications. Therefore it should be fairly easy to de-obfuscate text that is behind screen-shots of the Aero theme.

There are obviously problems with this - the first one being that it’s not the whole window that’s transparent, only a slice on the top, but I’ve found some vaguely interesting things that were definitely not meant to be in scope of the screenshot through the Aero transparency. The second problem is that this only really helps if the thing behind the screenshot is actually of interest. But, let’s assume that those issues are met. The nice thing is the kind of people who tend to post screenshots are experts in their field. They’re often public speakers, analysts, or people who are giving instructions on how to use something. So there could be quite a bit of sensitive information in those screenshots. I only spent an hour or so trolling screenshots one day and found a few vaguely interesting peices of info.

I have sat on this concept for a few years, hoping someone would come out with it first, but I haven’t seen anything written on it, so here it is. Either way, it’s probably a minor in reality, but I recommend turning off Aero and all transparency when possible - especially if you’re like me and have to give a lot of presentations that include screen-shots of desktop applications (E.g. browsers).

Luther Martin asks this open question: Ian, I have a quick question for you based on some recent discussions. Heres the background. The first was with a former co-worker who works for the VC division of a large commercial bank. He tells me that his bank really isnt interested in investing in security companies. Why? Apparently foreach $100 of credit card transactions theres about $4 of loss due to bad debt and about only $0.10 of loss due to fraud. So if youre making investments, its clear where you should put your money. Next, I was talking with a guy who runs a large credit card processing business. He was complaining about having to spend an extra $6 million on fraud reduction while his annual losses due to fraud are only about $250K. Finally, I was also talking to some people from a government agency who were proud of the fact that they had reduced losses due to security incidents in their division by $2 million last year. The only problem is that they actually spent $10 million to do this. So the question is this: are we not spending enough on security or are we spending too much, but on the wrong things? Luther...

That which I described a month back relates to an application called payments, and a variation designed to make it better. One aspect that probably rankles is that a lot of people in the so-called Architecture role do something else, and that's not it This is what is killing Enterprise Architecture… every computer programmer, systems designer, software architect, solutions architect, technology architect, computer operator, PC owner, data architect, database architect, network architect, business analyst, systems analyst, enterprise architect, service architect, object architect, project manager and CIO calls whatever they want to or maybe, whatever they are doing, “Architecture.” It is chaos. No wonder we don’t have Enterprises that are coherent, integrated, flexible, dynamic, interoperable, reusable, aligned, lean and mean and working. So sayeth John Zachman, who is credited with having invented a term or two in the space. Here's one variation in the workspace of Architecture, which some call programming in the large. Consider the app from the last post, payments. It's cohesive, tight, and operates to a set of rules. It has strong boundaries. We can analogise this process to be like a building; hence it is probably fair to claim someone who designs and builds a payment system can call themselves an architect. If not fair, uncontroversial. There are also many others applications, and each of them can be analogised to a building. They are each cohesive units, strict rules within and without, and they are generally focussed on particular purposes. For each building, we have different Architects, and for each style of building, we have different styles of Architecture. Then, there are places where there are many applications. Larger companies, government departments, banks, etc, have dozens or hundreds of these applications. And, what's more, these applications are often connected in long, difficult transactions. A particular client's request might go wandering through from app to app, department to department, database to database until it finally pops out the other end. This is a very different building process, it's a macroworld compared to the individual building's microworld. In order for the whole organisation to deliver on its goals, all of the apps and people must somehow play towards the same goal; which means we have to bring all these together somehow. Architects have to talk to Architects, apps to apps, people to people, and many variations. It is tempting then to extend the application scenario and simply view an organisation as a very large application. But this runs into trouble very quickly. Firstly, all the individual apps run to their own timeline. Secondly, departments, and people, are jealous of their independence. Thirdly, the complexity is such that without very good oversight, very good understanding, and quite deft tuning and aligning, an Architect of an entire organisation will likely fail to make a mark. In order to make all this work, and improve, we need to set some guidelines. Firstly, once delivered, applications do not change much, if at all. Just like we don't go moving buildings around just because they are now inconveniently placed. Secondly, the interconnections between the apps are capable of changing , and being re-used for new and diverse purposes. This is the streets and walkways between the buildings, which typically become public ownership; they always seem to be being dug up and moved around for one reason or another. Hence we start to look at how the applications can look to each other, and we also start to standardise this as a first step. From this view comes the march of webservices, XML, WSDL, and friends: if all apps deliver their output in standardised forms, then it becomes a matter of cheap scripting for other apps to tap that output. Once that is done, we can start to re-connect, inter-connect and so forth. Hypothetically... Which leads to the next issue. Although we've tackled ways to reconfigure the I/O of the business units, just like we used to reconnect computer peripherals with cat(1), and we've created a fast & flexible form of BPR, we still haven't reduced the complexity. For that, a wave of tools and methodologies has rushed in like a tsunami to try and map out the complexity in some fashion to allow our supreme leader to be the true master of all she surveys: service discovery, service cataloguing, service levels, dependency mapping, defect discovery, transaction troubleshooting, model-driven reconfiguration, use-case mapping for large transactions, etc etc. With the flood of tools comes the flotsam of buzzwords, jetsam of key phrases, and sales calls for yet more tools. Anyone in the business will tell you this is a very costly area, as every new tool promises far more than any other tool has ever delivered, and you only find out after paying the price that there is a new must-have tool just around the corner. All of which goes to suggest that this is a very different game to Architecture. This is really City Planning, and although it is a sub-branch of what the Architecture Professionals like to consider their domain, it is a very separate field. An application Architect is very focussed on the tech, and needs to tear himself away from it to understand enough of the business in order to build something that is wanted. But in the wider organisation domain, the reverse is more true: this person is very focussed on the business, and she needs to tear herself away from the business just enough to understand what the tech can do for her, in the way of interfaces, data formats, etc. Just like the Architect meets the City Planner at the boundary line, driveway and other pipes, the Application Architect meets the "Company Planner" at the external I/O interfaces of the App. The desire for every building to have the same boring driveway is seen in webservices, which can be considered to be a lowest common denominator of application driveway. What then to call this person? Because the domain Architects grew out and upwards from this field, on the supremacy of their applications, they are sometimes called Enterprise Architects. But this is a parochial, bottom-up view by technologists, who press the case for more technological tools. We can also look at the question top-down, business oriented, and there, we find a familiar thread: we are talking about Business Process Re-engineering up in the early 1990s, and the rampant charge of the MBAs at that time, and then a stampede of competing methodologies from consultancy companies with different names, variations but one common theme: interconnecting the units of business in better and more efficient ways. In the last decade, we saw the Enterprise Architecture approach possibly succeeding and outlasting, where others have not. However, it is not easy to attribute the success to its rightness; more likely it is attributable to the rise of the computer and information within modern service business. Enterprise Architecture rose upwards on the back of tech companies' assault on the business of business, and less so on its own merits. All of these have something of a fad in them, but something of the truth. That old dirty word BPR was essentially what we wanted, but we want it to be done every week, not every decade. Every other buzz/fad/gee-whiz word like TQM, JIT, 6 Sigma, Lean, Business Transformation etc etc that followed (or led) tried to repair some of the gaps in the previous (or following) fad, but they all suffered their blind spots and their seduction to increasing complexity. Any recipe teachable to ordinary people in ordinary business fails to understand the whole complexity of business, it seems. Leaving plenty of room for the next fad... Meanwhile, the MBAs had the ability to talk to all the departments in their language, understand the papers and draw the lines they wanted, dominate and improve on all the various methodologies ... but they didn't have the technical credibility to make it happen in a computer-driven world. (They would have loved Agile.) The IT-focussed Architects have the latter, but not the former; they know how to program in the small with data and functions and objects. But when it comes to programming in the large, with people and customers and processes and refunds and laws and giveaways and expediting and sickleave and and and, not only is their experience simply lacking, but the rules of programming are completely different. Which all leads to what, exactly? Although I think some very good stuff is happening in the Enterprise Architecture world, I also sense the mismatch in viewpoints. To me, I get the feeling that this evolutionary game isn't over, there's a few more cycles before we figure out who is the real master of the high-density information city. It is like we are back in the 1970s, admiring the traffic jams and the smog in Los Angeles, thinking that all this activity means we're on the right track. We know that Cities have City Planners, and it is a distinct discipline. We just haven't found, named and understood the City Planner for information-driven business as yet. Right now, I feel we're back in last century, 50 years ago, Los Angeles: admiring the traffic jams and pile-ups, selling traffic lights, thinking the info-smog tells us we're on the right track, and complaining that City Hall is digging up the streets. Again :-( (Hattip to Martin Bramwell who provided much of the helicopter view for this essay!)...

Large organisations are great at creating metrics for things. They always have to have dashboards and scorecards and other little devices that let them monitor how they're doing on so many different fronts.
That's especially true for IT organisations, at least, any that are big enough that you can't just ask everyone involved how things are going.
Governance people, especially, love metrics and scorecards. 
The problem with metrics is they aggregate information to such a degree that you often know there is a problem, but not what it is. You'll see, for example, some scorecard with a red traffic light against a project, so you know something is going wrong, but you have no idea at all how to fix it.
Fixing it requires deep diving into human conversations with the people involved. Metrics are pale reflections of the people-reasons things are breaking. And, of course, it is always people reasons why things go wrong, when you boil everything down.
My problem with this whole process is that the aggregate data you get on scorecards always lags reality by a significant degree because the metrics collection process is incredibly flawed.
Metrics collection is based on the premise that people with the most to lose when something goes wrong will admit they are in trouble soon enough for management to help them. By the time the scorecard reflects reality, it is invariably because the people involved can no longer hide what's broken - they may, for example, have missed a delivery date or had to request more money.
This, actually, is a problem with all systems where the reporting process is based on top down self-reporting.
I think it is time for a new approach to this. Why can't we have reporting systems that go directly to the human front line and aggregate up? Why can't everyone in a project team be polled on what they think the status is and use that as the reporting metric? At least it would be more honest and be much closer to the human conversations which provide the solution.
Certainly, I've never worked in an organisation that manages its scorecards in this way. Has anyone got examples they'd care to share where this kind of thing has worked?

Things I've seen that are encouraging. Bruce Schneier in Q&A: Q: We've also seen Secure Sockets Layer (SSL) come under attack, and some experts are saying it is useless. Do you agree? A: I'm not convinced that SSL has a problem. After all, you don't have to use it. If I log-on to Amazon without SSL the company will still take my money. The problem SSL solves is the man-in-the-middle attack with someone eavesdropping on the line. But I'm not convinced that's the most serious problem. If someone wants your financial data they'll hack the server holding it, rather than deal with SSL. Right. The essence is that SSL solves the "easy" part of the problem, and leaves open the biggest part. Before the proponents of SSL say, "not our problem," remember that AADS did solve it, as did SOX and a whole bunch of other things. It's called end-to-end, and is well known as being the only worthwhile security. Indeed, I'd say it was simply responsible engineering, except for the fact that it isn't widely practiced. OK, so this is old news, from around March, but it is worth declaring sanity: Q: But doesn't SSL give consumers confidence to shop online, and thus spur e-commerce? A: Well up to a point, but if you wanted to give consumers confidence you could just put a big red button on the site saying 'You're safe'. SSL doesn't matter. It's all in the database. We've got the threat the wrong way round. It's not someone eavesdropping on Eve that's the problem, it's someone hacking Eve's endpoint. Which is to say, if you are going to do anything to fix the problem, you have to look at the end-points. The only time you should look at the protocol, and the certificates, is how well they are protecting the end-points. Meanwhile, the SSL field continues to be one for security researchers to make headlines over. It's BlackHat time again: "The point is that SSL just doesn't do what people think it does," says Hansen, an security researcher with SecTheory who often goes by the name RSnake. Hansen split his dumptruck of Web-browsing bugs into three categories of severity: About half are low-level threats, 10 or so are medium, and two are critical. One example... Many observers in the security world have known this for a while, and everyone else has felt increasingly frustrated and despondent about the promise: There has been speculation that an organization with sufficient power would be able to get a valid certificate from one of the 170+ certificate authorities (CAs) that are installed by default in the typical browser and could then avoid this alert .... But how many CAs does the average Internet user actually need? Fourteen! Let me explain. For the past two weeks I have been using Firefox on Windows with a reduced set of CAs. I disabled ALL of them in the browser and re-enabled them one by one as necessary during my normal usage.... On the one hand, SSL is the brand of security. On the other hand, it isn't the delivery of security; it simply isn't deployed in secure browsing to provide the user security that was advertised: you are on the site you think you are on. Only as we moved from a benign world to a fraud world, around 2003-2005, this has this been shown to matter. Bruce goes on: Q: So is encryption the wrong approach to take? A: This kind of issue isn't an authentication problem, it's a data problem. People are recognising this now, and seeing that encryption may not be the answer. We took a World War II mindset to the internet and it doesn't work that well. We thought encryption would be the answer, but it wasn't. It doesn't solve the problem of someone looking over your shoulder to steal your data. Indeed. Note that comment about the World War II mindset. It is the case that the entire 1990s generation of security engineers were taught from the military text book. The military assumes its nodes -- its soldiers, its computers -- are safe. And, it so happens, that when armies fight armies, they do real-life active MITMs against each other to gain local advantage. There are cases of this happening, and oddly enough, they'll even do it to civilians if they think they can (ask Greenpeace). And the economics is sane, sensible stuff, if we bothered to think about it: in war, the wire is the threat, the nodes are safe. However, adopting "the wire" as the weakness and Mallory as the Man-In-The-Middle, and Eve as the Eavesdropper as "the threat" in the Internet was a mistake. Even in the early 1990s, we knew that the node was the problem. Firstly, ever since the PC, nodes in commercial computing are controlled by (dumb) users not professional (soldiers). Who download shit from the net, not operate trusted military assets. Secondly, observation of known threats told us where the problems lay: floppy viruses were very popular, and phone-line attacks were about spoofing and gaining entry to an end-point. Nobody was bothering with "the wire," nobody was talking about snooping and spying and listening [*]. The military model was the precise reverse of the Internet's reality. To conclude. There is no doubt about this in security circles: the SSL threat model was all wrong, and consequently the product was deployed badly. Where the doubt lies is how long it will take the software providers to realise that their world is upside down? It can probably only happen when everyone with credibility stands up and says it is so. For this, the posts shown here are very welcome. Let's hear more!...

Seen on the net, by Dan Geer: The design goal for any security system is that the number of failures is small but non-zero, i.e., N0. If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Calibration requires differing outcomes. Ive been trying for years to figure out a nice way to describe the difference between 0 failures, and some small number N0 like 1 or 2 or 10 in a population of a million. Dan might have said it above: If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Has he nailed it? Its certainly a lot tighter than my long efforts ... Once we get that key piece of information down, we can move on. As he does: Regulatory compliance, on the other hand, stipulates N==0 failures and is thus neither calibratable nor cost effective. Whether the cure is worse than the disease is an exercise for the reader. An insight! For regulatory compliance, Id substitute public compliance, which includes all the media attention and reputation attacks....

Over at Management Matters, guest blogger Steve Burrows writes of high profile systems failures at Tesco and Barclays in the UK:These instances, two major private sector failures of customer-facing IT in a week, show us not only that the private sector is not immune to IT failure, but that our biggest corporates with effectively unlimited IT resource working to their own objectives and timescales still don't get IT governance. In both cases one has to ask what went wrong? Where was the testing? Who oversaw it? Who authorised the go live decisions? It seems the private sector still has some lessons to learn about delivering major IT projects successfully, hopefully it will do so more quickly and with less pain than the public sector. Steve, I don't know about you, but I am yet to work in any large organisation where the problem was a lack of governance. Systems failures don't happen because of governance, or the lack of it.  They happen because large systems which connect to other large systems are simply too complex for anyone to be sure of what's going to happen when you turn them on.
Yes, I know that the answer to this is testing. But the real problem is this: getting certainty that things will work out the way they are supposed to requires that you duplicate your production environment down to the very last server, the very last item of data, and find a way to realistically replicate actual user behaviour at the scale the system is supposed to handle. To get 100% certainty, the test environment has to duplicate real life in every detail, and that costs. I don't know any large processing operation that can afford to do this, actually. Most can barely afford to keep their production systems going.
Since you can't be certain whats going to happen when you turn on a new system, management is expected to make a decision on go-live given the incomplete  information they have to hand. Sometimes they know enough that there is a pretty low level of risk of something going wrong. Other times they don't but because of internal pressures, they take the chance anyway. Great IT management isn't scared to take a risk when they assess all the benefits versus all the potential things that can go wrong.
Great IT managers also make mistakes in their risk assessment from time to time too. 
The role of governance is to provide the information that managers need in order to make their risk decision about a system. Like all information collection activities, it is subject to declining marginal returns. The more you have, the more it costs for incrementally less surety. There is a point at which the additional risk you eliminate by adding a new process or a new reporting regime is more expensive than the downside it is supposed to mitigate. 
But there is another dimension to the go-live decision, and that is the non-IT pressure that managers are subjected to. Sometimes, the business downside of failing to go-live at a particular time is so significant that it justifies the risk of things going wrong, even if you don't have surety of the system. Neither Steve nor I know what really went wrong at Tesco and Barclays, but it is reasonable to guess this: those IT managers would have been under substantial pressure to get those systems out the door, and they took a calculated risk.
Steve goes on to imply that this kind of risk taking is management incompetence:The reputations of all IT workers are demeaned by such failures, the governance and management failings that allowed these errors to occur bring us all into disrepute by association. The harm suffered due to IT failings in large corporates not only affects them and their customers, it taints all of us in the IT profession, fairly or otherwise.I don't for a moment suggest that it is acceptable that major systems fail. Nor do I think taking stupid risks is sensible management. But since every change to a major IT system is an exercise is risk assessment, things are going to go wrong from time to time. It is simple to blame management when things go wrong, but not so simple to come up with a solution that reduces the chance of failure to zero in a way that's affordable.
Actually, if such a solution existed, I think we'd all have deployed it by now. Steve, if you know something that the rest of us don't, now is the time to share.
In the meantime, the answer is not to have more  governance, it is to have proportional governance, and invest in long term complexity reduction.  Complexity reduction not a complete solution, of course, but what it does is reduce - over time - the amount of information you have to get before you can safely take a decision to go live.

As an innovation person, I'm always startled when I see a product or service which turns into a huge, overnight hit. Especially one which comes from nowhere.
The reason I'm startled is that innovation academics have long used a thing called diffusion theory to explain how new ideas get adopted by populations. The long and short of it is, you find a small group of people who aren't risk averse and who are willing to try a new thing, and they tell their experiences to like-minded people who are more risk averse. The positive feedback from the first adopter influences the next to adopt, and so on. This process builds up until you get to the tipping point, where everyone adopts the new thing en-masse. Wikipedia explains this in more detail.
My surprise comes from the fact that this whole process takes time. Sometimes, lots of time. So, when it happens overnight, something else must be going on. Hit products - which I'll define here today as ones where you get mass adoption without the slow build up from diffusion - shouldn't happen.
Of course, hit products do happen. And I have the germ of a theory as to the reason.
My key observation is this: breakthrough, radical innovations are never hits. Hits happen when a previous breakthrough is incrementally improved over time, and then shifted sideways into an aligned problem space where they cause a revolution. In all the cases I've been able to find so far, this seems to be true.
Let me give you a historical example: the steam engine.
The steam engine was initially not very much use. It was invented in Greece in the first century AD - a boiler with two spouts on an axel. When the steam came out of the spouts it made the whole thing turn. Not very efficient. The breakthrough: the first time ever a motive force was created that wasn't human or animal.
Some 1500 years later, a steam engine that could pump out shallow mines was invented. It was also not very efficient - the cost of fuel was greater than paying people to bail out the holes.
40 years later, a more efficient engine came along that could do deep mines. It was till expensive, but cheaper than using humans or animals. Steam pumps started to spread.
A few years after that a highly efficient engine was designed, one light enough to move around. Stephenson, the father of the railway, put an engine on rails and used it to tow loads. Then he opened a commerical railway between two cities in England.
Almost overnight, the world changed as railways exploded across the world. 
The diffusion process occurred ordinarily for steam - it just happened in the space of pumping water. When Stephenson moved the pump into an aligned problems space - mechanical motive force for transport - there was no need for diffusion processes because they'd already happened somewhere else. 
There are so many examples of this. Vacuum tubes, invented by Edison, hardly used until they found a home in commercial radio. Polaroid film, an optical oddity until it was used in sunglasses and instant photography. 
What about the hits of today?  
iPad: an incremental improvement of iPhone (the bigger screen) moved into the aligned space of media consumption even though previously tablet adoption was low. Avatar, the movie: just another sci-fi until James Cameron incrementally improved 3D (full depth perception, not just objects flying at you) and moved in into mainstream cinema. Previously, 3D was a gimmick. Google: an incremental improvement on search (better results) moved into the aligned space of contextually relevant online advertising. Before that, ads were about replicating paper.
Now, if this is true, what is the lesson for innovators?
Don't invest in radical innovation - look, instead, for incremental improvements that can be moved sideways and turned into revolutions. Wait for someone else to do the breakthroughs, then build a business by leveraging the diffusion process they've paid for in an aligned space.
Perhaps that's controversial, but I've not found an example yet that refutes this line of thinking. I'd be grateful if anyone can give me some examples that does.

37 posts remaining…

With all the talk about cloud computing I thought it would be interesting to post this article. It turns out you can create a single chassis that contains around 67 terabytes in it for $7,867. That’s pretty incredible, and most interestingly, if you follow the link, you’ll see the cost breakdown compared with other alternatives which it pretty much blows away. It almost doesn’t make any cost sense to outsource your storage to the cloud with those cost savings. It really can be cheaper to bring it in house.

Now there are some down-sides, and they primarily have to do with high availability. There’s a good article explaining some of the potential downsides although id told me, “port multiplier doesn’t matter there, even 2-1 oversubscribed they are fine for doing what they are meant to” so take the criticism with a grain of salt and do your own fact checking. Either way, the cost savings are so dramatic, this could be an evolutionary step and I bet things will get a lot more solid down the road to elevate the issues of availability. So it might be premature to jump into this kind of storage for those massive databases you’re supporting, but given a little time and increased density I bet this technology makes a huge difference in cost down the road.

As a side note, for you people who were around for a while, I did some quick math - it would take just north of 46.5 billion floppies to equal that one 4U box. Also, as a fun fact most smart-cell phones these days are faster than the machine that we started ha.ckers.org on. Amazing how times have changed!

38 more posts left…

I first started thinking about this when I talked to a friend from Vietnam a year or so ago regarding his CISSP. Once upon a time it was nearly impossible to find someone in Vietnam with a CISSP. At first I thought he was making some sort of joke about the usefulness of the certificate, but for some things in Vietnam it’s really a hot commodity. It turns out that the cost of living there makes a CISSP almost totally not worth it. Even though it’s expensive in the United States (where I live) respective to the wages in Vietnam it’s weeks or even a month worth of work. Therefore the rate at which a certificate would be awarded is less, not because of skill, know-how or anything else. It’s purely economics. Slowly that has changed and more people now have it than before in Vietnam, but it’s still not equal as a percentage compared to the USA, for instance, from what I was told.

That got me thinking about other issues that are relatively the same. For instance SSL/TLS certificates. Buying a certificate to allow for transport security is a good idea if you’re worried about man in the middle attacks. Yes, that’s true even despite what I’m going to tell you in my Blackhat presentation where Josh Sokol and I will be discussing 24 different issues of varying severity with plugins and browsers in general. But when you’re in another country where the cost of running your website is a significant investment compared to the United States, suddenly the fees associated with the risks are totally lopsided. So this may be why you might see a lower adoption rate of certificates in certain regions. More importantly there really is no long term reason the security industry can’t create a free certificate authority (over DNSSEC for instance) that provides all the same security or more even without the costs - therefor making it a more equal playing field.

Lastly I started thinking about bug bounties and how they work almost opposite. Unlike security, where the cost is high for playing, hacking can be much more lucrative based on your geo-economic situation. For instance, a $3000 bug bounty for something that takes two weeks to work on equates to a $78k a year job if you can be consistent. In the United States for a skilled researcher that’s barely worth the time. But in a country where the average income is closer to $10k a year, something like this might highly incentivize researchers to focus on attack verses defense, which few can afford. Anyway, I thought it was an interesting concept that may play out entirely different in reality, but it was a fun thought exercise.

The following is another excerpt from my work on how the vendor relationship looks from the buy-side.

Because direct approaches often fail to get a first meeting, some enterprising firms have spotted an opportunity. They establish themselves as “horizon scanners” or “futurists” and offer to give you free advice about the shape of the things to come. Their value proposition, they say, is to bring the latest and greatest organisations in front of you, providing a curation service that means you don’t have to invest much time in such things yourself. This is inherently attractive, of course, because on the buy side you are always wondering whether there is a a killer tool or service available that competitors have that you don’t.

The problem is that such firms are really fronts for getting the first meeting. Their business model is not to horizon scan for the buy-side, but to sell access to the first meeting to the sell-side.

Now, customers aren’t dumb. After the first session or two, they recognise what they’re getting is a set of meetings with vendors who have paid for the introductions. It is incredibly false, and incredibly time wasting. Almost immediately, the introducer firms get blacklisted.

But here’s the problem with such firms. The product they sell is first meetings, and their currency in any buy-side situation is incredibly tenuous, because customers always see through them very quickly.

Their response is they network throughout an organisation, usually getting a single meeting, but very few more. You often hear people complaining in serial fashion about how much time they waste, and how they are never left alone after agreeing to that first, deadly meetup.

When you sell meetings for a living, of course, you are highly motivated to get as many as possible to sell. Consequently, they take being a serial pest to a whole new level.

Advice to vendors trying to get in the door via an introducer: we will likely be so annoyed by the introducer and their octopus-like procession around our organisations that anything you have will seem insignificant by comparison. Undoing the damage they cause (and which you are associated with) will take ages, and likely render a major sale impossible in whatever timeframe you have available before you get fired.

39 more posts left…

Just a quick post as I head into the ramp up to Blackhat where I won’t be writing posts. Jeremiah and I spent a lot of time trying to break the Flash settings manager a few years back but one thing that I never mentioned was the way in which Flash’s settings are very often scoped to the domain rather than the app. Although currently allowing Flash access to camera and microphone isn’t all that common, if it ever did become common using XSS would be a pretty interesting tactic. Once access is allowed and remembered, an XSS included object could theoretically end up with the same privileges.

Clearly XSS is bad in of itself, but once settings are permanently remembered, even on a site that has no other sensitive information on it (a free video-game site for instance) something like this could allow an attacker to do some nasty spying. In general applications should never allow access to camera and microphone permanently by default. Thankfully, I don’t think there are a lot of apps out there that request mic and/or camera access so the attack surface may be small. But if that were to change I’m sure if an attacker were creative they could combine CSS history hacking + hidden iframe + XSS + camera and microphone app to spy on quite a number of people who had selected the “Remember” option.

The nice thing about this attack is if it fails it doesn’t create a modal dialog alerting the user to the fact that they were under attack (one of the many perils of not using modal dialogs). So the moral of the story is even if your app contains no sensitive data, you need to be extremely careful of XSS. Oh, yeah and Flash may want to allow the web sites in question to remove the “Remember” function from their apps in future versions.

And, only because I wrote it in the same thread as Zookos post, here is a retrospective on how the 1990s payments startup guys saw life, as compared to the 2000s p2p generation. On 18/06/10 12:27 PM, Serguei Osokine wrote: In fact, I thought that this was exactly the hint that Zooko was dropping with his question about MN history. Was kind of surprised to read all the serious history descriptions that followed - though enjoyed them anyway... :) :) Maybe to add to your surprise, there was a serious history! Perhaps a little more background will help. In the late 1980s, a guy called David Chaum invented a cryptographic form of cash which he called digital cash. His invention was a variation of the RSA formula that allowed a transfer of something from one person to another, that a third party could prove as valid, but not track the transfer. This allowed the third party to be an issuer of value, and users to transfer coins without being traced....

Editors note: Zooko writes in p2p-hackers forum, and editor gladly copies: That there is also a new generation of interesting payment systems including The Love Machine and Flattr. I think Flattr is very interesting. Founded by founders of The Pirate Bay, they do several things that are very promising: 1. The marginal cost to you of clicking on someones flattr me button is zero. This is due to the scheme of subscribing to Flattr.com with a monthly fee and then at the end of the month your money gets split among everyone whom your clicked on. This is the most promising solution to the problem of mental transaction costs. 2. The pitch is that this is a way to express love to people. #9829; $ 3. Look: content! It is very easy to find things to love on the flattr.com web site. This has a lot in common with the tipping feature that we advertised as a future feature of Mojo Nation (e.g. it features prominently in the write-up of Mojo Nation in The Economist). (Inside Evil Geniuses For A Better Tomorrow we called that feature the Pay Lars button, in honor of a certain musician who had publicly criticized Napster for depriving him of well-earned income.) From a historical perspective Flattr is a fascinating example of the evolution of ideas. The founders of The Pirate Bay are probably intimately familiar with BitTorrent, but as far as I know, they are unfamiliar with anonymous Chaumian digital cash. I wouldnt be surprised if they got the idea for Flattr from their experience with BitTorrent and basically observing that there was a hole in BitTorrent where micropayments could go. :-) Does anyone know the inside story on how they got the idea for Flattr? Regards, Zooko...

In almost all organisations there is an authority asymmetry. The number of people who are empower to say "no" is usually much greater than those who are empowered to say "yes". This is because organisations are much more comfortable with staying the same than agreeing to changes. Empowering people to say "no" is a safe option.
It is also true to say that more often than not the  number of people you might have to influence to get something done is significantly greater than the amount of time available to do the influencing. This is why innovators often fail to get much done.
Consequently, its necessary to optimise the return on influence.
For an innovator, there is almost no upside available influencing those with the power to say "no", because the best possible outcome is ambivalence, which is not especially helpful. On the other hand, there is every chance they actually will say "no". Optimising return on influence means the best strategy is keeping your innovation under-the-radar from the nay-sayers as long as possible.
On the other hand, influencing someone with the authority to say "yes" might still get you a negative response, but at least you'll have the chance to move forward. It is a much better value proposition.
How do you tell the difference?
Here's a litmus check which almost always works. The person who controls the money is able to say "yes". Everyone else can only say "no".