Since 9/11, more than three dozen federal air marshals have been charged with crimes, and hundreds more have been accused of misconduct, an investigation by ProPublica, a non-profit journalism organization, has found. Cases range from drunken driving and domestic violence to aiding a human-trafficking ring and trying to smuggle explosives from Afghanistan.

The meta-problem is that the kind of person who wants to be federal air marshal is the exact kind of person we don't want for the job.

Before 9/11, the Air Marshal Service was a nearly forgotten force of 33 agents with a $4.4 million annual budget. Now housed in the Transportation Security Administration, the agency has a $786 million budget and an estimated 3,000 to 4,000 air marshals, although the official number is classified.

And 3,000 to 4,000 is a lot of people to hire quickly; it's hard to weed out the bad eggs.

He makes the argument that the Digital Theft Deterrence and Copyright Damages Improvement Act of 1999 is very much unconstitutional, in that its hefty fines for copyright infringement (misleadingly called "theft" in the title of the bill) show that the bill is effectively a criminal statute, yet for a civil crime. That's because it really focuses on punitive damages, rather than making private parties whole again. Even worse, it puts the act of enforcing the criminal statute in the hands of a private body (the RIAA) who uses it for profit motive in being able to get hefty fines.

Imagine a statute which, in the name of deterrence, provides for a $750 fine for each mile-per-hour that a driver exceeds the speed limit, with the fine escalating to $150,000 per mile over the limit if the driver knew he or she was speeding. Imagine that the fines are not publicized, and most drivers do not know they exist. Imagine that enforcement of the fines is put in the hands of a private, self-interested police force, that has no political accountability, that can pursue any defendant it chooses at its own whim, that can accept or reject payoffs in exchange for not prosecuting the tickets, and that pockets for itself all payoffs and fines. Imagine that a significant percentage of these fines were never contested, regardless of whether they had merit, because the individuals being fined have limited financial resources and little idea of whether they can prevail in front of an objective judicial body.

Another news story.

The problem is that (Chris’ analysis is) completely impractical. I’ll take a recent, and fairly typical situation as an example. I was taking issue with the manner in which remote access was being provisioned for a third party vendor to connect to a system hosted by one of our European business units. To cut a long story short, it was not only a breach of policy but highly insecure. I wanted the access to be disconnected, the business unit director wanted my risk assessment. And he didn’t want to wait for it.

To quote Chris Hayes, spending time on working out the expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force was not going to pacify an angry Italian fearful that my decision was going to cost him money. He wanted my explanation of the risk and more importantly, what I was going to offer as a solution to keep his business functioning

As Chris is someone who actually does this for a living in a large company, and this is typical of his actual day job, I really find Stuart’s “impractical” comment to be, um, misinformed.

Also, I think Stuart mistakes the purpose of a risk analysis.  The purpose of the risk analysis is not to force someone to be “secure”, but to provide knowledge for decision making.  Using it as a “hammer” to knock in the nail of your personal risk tolerance impairs efficiency and in the long run retards “security” as it creates political resentment.  Seriously, who cares if something might violate policy or not in a pre-implementation discussion?  Policies are not stone tablets handed down from on high, they are state-in-time codification of the data owners risk tolerance.  This risk tolerance changes sometimes, and that’s OK.

To that extent, I appreciate (and I’m sure Chris does, as well) that risk analysis does not create rationality in the data owner.  Someone who sees you as a speedbump on the route to progress they may not be ready to appreciate your point of view even if it is stated in the most rational manner possible.   But it’s worth noting (and Stuart’s example is indicative of this point) that risk analysis does not create rationality in the analyst, either.  If one is being so “security minded” as to ignore the risk tolerance of the business owner - we’re bound to get a reaction similar to that Stuart encountered.  In fact, a practical risk analysis like Chris performed on his blog, done in 30 minutes, should identify the critical point of disagreement between Stuart and the data owner (again, Stuart doesn’t own the data, the agitated Italian does).

But let’s stay rational and open to alternatives to what Chris offers.  Stuart states his approach to risk analysis as:

When I need to document a risk assessment I use a very simple form: list the threats, state the level of vulnerability, list the associated operational costs and potential revenue hits. High, medium, or low risk? Describe the controls and options. Write up who needs to do what, and how much of their time it’s going to take. Job done.

At first glance, I don’t think what Chris has done is any less efficient, and it provides greater insight (using Frequency and Capability instead of just ‘listing the threats’).  But what is key here is that Chris’ approach is consistent and defensible.  Less generous risk geeks and CSO’s I know would have no little difficulty with Stuart’s approach.  But to particularly answer Stuart’s main objection (impracticality) I would offer that with practice, Chris’ work is probably quicker and easier than Stuart’s described process as it eliminates much of the ambiguity an immature risk analysis creates - reducing the need for further discussion and arguments with data owners (regardless of disposition or nationality).

Finally the irony of Stuart’s post is that the reason he had this confrontation may in fact be because he was incapable of bringing a salient model for risk to the table, one that identified the factors that create risk and developed a defensible belief statement concerning risk.   We’ll never know if one would have helped him in this isolated instance, but I can tell you that in organizations like Chris’, good risk models and strong risk anlayses create operational efficiencies, reduce costs, and streamlines intra-departmental communications.

The latest Microsoft patch MS08-68 is a great example. It is a problem with NTLM authentication where the attacker can force a client to authenticate to him and the credentials, while not exposed in cleartext, can be relayed to another server or brute forced to obtain the cleartext. This is a very classic crypto protocol vulnerability. It’s not the crypto algorithms that are the problem, but the protocol implementation.

Microsoft recently fixed the problem, perhaps due to the availability of exploit code, the availability of an easy to use Metasploit implementation, or perhaps Microsoft’s changed tolerance for vulnerabilities. We can sum it up as a change in the threat space that made it worth fixing. But make no mistake, this is a very old problem.

News reports have been citing Sir Dystic’s SMBrelay tool, which was published in March, 2001, as the first knowledge of this vulnerability. Eric Shultze who worked at MSRC in 2001 just yesterday is quoted as saying, “I have been holding my breath since 2001 for this patch.” Obviously it is a long time coming. But this wasn’t the first publication of the problem. In 2000, one of my collegues on the research team at @stake, Christian Rioux (aka Dildog) published the telnet NTLM authentication vulnerability.

Rioux’s advisory has a great description of the credential relay and cracking weaknesses. I have talked to him and he says he discovered these problems independently, but he didn’t find them first. Dominique Brezinski published exactly these NTLM vulnerabilities in the SMB protocol in 1996 in a paper titled, “A Weakness in CIFS Authentication”. The earliest reference I can find on the paper on the net is here where it is included in another paper published in 1997. Such is the ad-hoc world of independent security research of 12 years ago which still continues today.

It seems ridiculous that a field like security research, which is so important to the running of modern society is so ad-hoc. Shouldn’t we know who discovered a vulnerability? Shouldn’t all researchers and engineers know about it? More importantly if someone implements a tool that takes advantage of a vulnerability shouldn’t they credit the discoverer? Don’t get me wrong. Implementation takes a lot of work and sometimes makes all the difference in makeing people aware of a security problem. After all when I was at the L0pht our slogan was, “Making the theoretical, practical”. I still think researchers should get credit when credit is due.

The security community has gotten better at documentating our research but I still see instances of independent discovery, misplaced credit, and tools giving no credit to researchers. I hate to say it but getting a bit more academic is in order. Credit is the currency of a researcher and placing it well will reward the right people and we will all benefit.

I’ve often read people who say that we (security, risk management) need to “think like the attacker”.  And when you read this sort of article, that usually alludes to trying to anticipate the tactics an attacker might use to mess with your C, I, or A.  Smart stuff, that, and very useful when architecting security solutions.  But as I was training some folks Monday, I was thinking in the back of my head about Threat Capability (TCap) in FAIR.  As you might know, we like to estimate the capability of a threat to apply some level of “force” against our assets.  This ability to apply force is a byproduct of the attacker’s skills and resources.  And thinking of how an attacker applies skills and resources, I came across another way we might “think” like an attacker.

Traditionally, I’ve thought of “skills” as being a byproduct of the toolset an attacker has.  This mindset probably stems from my time with Penetration Testing teams, where in the process of scoping the  PenTest I would ask our clients to select the level of effort that they wanted us to throw at them.  If a client chose “high” we’d throw every ‘spoit we had at them.  If they chose “low” we’d limit ourselves to a more commonly available toolset.

But while the resources part of TCap is time & materials (money) - the skills are really more than just the toolset.  Skills would include the ability of the attacker to be creative and innovative.    As an example of that innovation from those PenTesting days - when we got a “high” effort request, we would always try to couple that with some “social engineering”-type of attack, or some unique means of delivering an existing exploit.  Our creativity was not necessarily a byproduct of a unique exploit or tool we had, but the process by which we might deliver pre-existing or commonly available exploits.  I remember when we first got ahold of a handful of 32mb thumb drives (hey, 32mb was huge back then) and “dropped” a few in the lobby of a client’s retail space.  The keystroke loggers and phone-home script weren’t new, but using the thumb drive as delivery vehicle certainly was.

So I’ve started to really think about this concept of innovation, and how if “thinking like an attacker” means to be innovative, we ought to do the same.  I’ve been thinking of two main categories of innovation this morning.

INNOVATION

The first I’ll call Technology Innovation.  And by Technology Innovation, I mean some new, unique, “ahead of the curve” technology that an attacker can use against us.  The obvious example of which is a zero-day.  It’s that “high” tool set our PenTesters would use against the clients.  For security departments, this might be the latest security product designed to enhance our ability to P, D, and/or R.

Alternately, we can be creative in the way we deliver (manage) existing technology.  I think of this as Process Innovation.  It’s doing more with what we already have, just like the PenTest team would be creative in the delivery of an existing exploit.

Unfortunately for us - attackers have traditionally had quite a leg up on us in terms of Process Innovation.  It is much easier fro them to be creative, as they are free of political constraints and bureaucracy.  In contrast, when the security industry tries Process Innovation, the results are checklists and “standards”.  It’s committees and consensus.  An extreme example of which might be something like SABSA - a great work if you want to understand some very smart people’s comprehensive understanding of organizational security  - but the “adoption”of which will do very little to help you be innovative in P/D/R.

It’s worth noting that ultimately, this is one reason I don’t like regulatory compliance efforts - they simply serve to prove how mundane your security department is,  wasting valuable resources that could be spent on creating ways to be more effective.

PROCESS INNOVATION AS A SUBSTITUTE FOR TECHNOLOGY INNOVATION

As we come to the close of 2009, some surveys suggest that security spending isn’t horribly impacted yet by the economy (the latest from E&Y points to only 5% of their respondents getting budget cuts).  But if this is a protracted downturn, and because InfoSec is an operational expense, I would expect cash to become more and more difficult to keep.  And regardless if technology spends do slow, I believe it makes sense to think about Process Innovation because I see Process Innovation as a means to increase effectiveness without significant capital expenditures (effectiveness increases because our ability to manage risk has a direct correlation to the amount of risk we have).

The bad news is, of course, that great innovation is hard.  It is R & D.  Failure is usually a pre-requisite to success.

The good news is, our current state is so bad that many of us don’t need to come up with a whizbang new way of reducing software defects in the SDLC as innovation.  Simply inserting a risk analyst into the PMO’s processes might count as a big enough victory. Be cautioned, though,  that if we’re substituting the risk reductions provided by technology acquisition - Process Innovation might actually be even more “expensive” as it requires us to expend political capital.   But there are (forgive the term) innovative ways to spend this political capital.

For example, by taking a second now and figuring out the 3 things that the rest of the organization can do to make your life easier, when that “I need to reduce your budget” talk comes, you can be prepared to negotiate.  Get a political capital “loan” or “investment” from the C-Suite reducing your budget.  Something to the effect of: “I expected this, and am happy to give up my budget.  But if our tolerance for risk hasn’t changed, what I’d like to do is get you to personally back my office on three projects I’ve identified that can reduce our risk without requiring significant capital expenditure.”

Salesforce.com’s Dreamforce conference takes place this week in SF. Billed as “The Cloud Computing Event of the Year”, the conference kicked off with a keynote by Benioff while people wearing puffy-white jackets and holding giant helium-filled cloud balloons stood outside.

Benioff announced partnerships with Facebook and Amazon.

Part 1: Force.com apps will be able to run on Facebook and leverage the Facebook users’ social network. An example shown was integrating “My Starbucks Idea” into Facebook. If a user submits an idea through Facebook, their friends can see it, comment or be prompted to submit their own.

Part 2: Force.com applications can now use Amazon’s cloud hosting services in addition to the public Force.com sites.

This is smart and a surprisingly non-megalomaniac way of doing things. Instead of trying to own the entire cloud stack (hmmm – someone just made a very different announcement), Salesforce looks like it’s focusing on what it does best – enabling application development in a hosted model. And letting Amazon take at least some of the future blame for any outages/interruptions in service (anyone who has Salesforce can say amen to that). That is smart.

The best security program is at the business with the happiest customers.

There's a fine line between happy customers and playing piano in a bordello.

Sees a lot
Can tell the king he has no clothes
Can tell the king he really is ugly
Does not get killed by the king
Nice to have around but…how much security improvement comes from this ?

Changes happened faster that he was able to move
Did not read the signs
Good intentions went unfulfilled
A brutal way to ending a promising career
Sad to have around but…how much security improvement comes from this ?

Obviously these models of CISOs are not solving our information security problems. Instead Dr. Garigue points us to Charlemagne as a better model

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

This is the way forward! Find software security champions in the architecture and development groups,help them understand the real security issues. They will find solutions you have not thought of. Same for DBAs, same for business analysts even. Its all about beating the bushes, education, and decentralizing security services. Specifically, he points out this important mandate for IT security

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?
How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

To me this is our mandate and measure of effectiveness. Empower our customers, educate, and create business value. If I am a CISO  I don't want 20 people reporting to me who do firewall ruleset changes. I want one champion in 20 different groups - development teams, architects, DBAs, business analysts.

A concrete example, infosec can continue to go along with the herd and follow the "what everyone else is doing architecture" meanwhile developers are connecting every single thing in your business to the Web. I have been doing integration and new technology projects for a long time, and let me tell you - Change does not always create happy customers in the short run. But the chart below shows that information security is maybe more concerned with not causing waves rather than adapting.

The best security program is at the business with sustainable competitive advantage.