Idoneous Security

Going back to the stack.

2012-03-03T05:18:00.000-08:00

In the spirit of trying to suggest solutions, here are a couple of thoughts about what an enterprise can do first off to make security a little better.

It's bothered me that infrastructure is being administered more horizontally than vertically these days. Everyone specializes in a different layer: network, OS, utilities (such as Exchange), middleware, applications, etc. And this gets worse when you outsource one or two layers to "the cloud" (think IaaS, PaaS and SaaS), so that you have to coordinate with a third party to troubleshoot something.

Back in the Pleistocene era, system administrators knew their systems like they were their babies. They knew everything that was running on them, how they were configured, who they talked to, and they knew when something was "off." I know sysadmins that would regularly help a developer debug code, and they were often better at it than the developer, because they also understood the underlying environment better. They could troubleshoot all the way up and down the stack, and you went to one source to do it instead of having to get a conference call together with 3rd level engineers from four different companies. (Seriously, I know of a data center that had five different networks owned by five separate entities. Think you could figure out what happened to a packet? Think again.)

So one thing that enterprises can do is simply to get control of their layers as much as possible. Know what you have, know where it is, and be able to cause changes to it when you want to. That sounds so obvious as to be not worth saying, but I don't know of any admins who know more than about 500 hostnames by heart, and many times the environment is so dynamic that boxes come and go without any centralized tracking keeping up with it. (And I'm not even talking about VMs.)

If you already have parts of your infrastructure outsourced, go over your contracts and strengthen your relationships with your providers. You want them to be able to give you logs, for example, within a few minutes of the request. You also need to have the right technical level support people on call without having to fight your way through first-level script-readers.

And finally, go back to designating "stack admins," who are generalists rather than specialists in one particular technology. It should be their job to know as much as possible about any given system. You can fit this into DevOps if the developers truly know the lower layers. A stack admin is your best hope for knowing what normal operation is, and for alerting you when something doesn't smell right; they're also the best at understanding the implications of any given planned change (such as changing the ports an application uses without creating the corresponding firewall rules).

Start with knowledge, and then work your way to control. Notice we haven't really touched on security yet; that'll come later. But knowledge and control are basic building blocks of security.

In 50 gigabytes, turn left: data-driven security.

2012-02-11T09:31:00.000-08:00

I love Scott Crawford's research into data-driven security. I agree with him that IT operations and development can both benefit from the right security data -- where "right" means at the appropriate level and relevant to what they're doing. It also has to be in the right mode: an alert should be based on a conclusion drawn from the analysis of data (20 failed logins per second = someone is using automation to try to break in), based on an event or confluence of certain events. Once someone in IT needs to perform an investigation, the need changes to looking at more atomic data (exactly which logins are being targeted, whether they're active or disabled, etc.). In other words, the details need to be available on demand, but they shouldn't be shoved at the IT staff in lieu of useful alerts.

Another kind of data that is useful is situational data: how things are configured and what is happening during "normal" operation. Viewing all the responses from a database is too much to ask of a developer -- but the developer would benefit a lot by knowing that some queries are taking 25 minutes to return (do you suppose that would have some effect on application performance?). This is the sort of data that is incredibly useful, but setting up every possible abnormal situation to trigger an alert is way beyond the scope of an overworked operations team. Sometimes you just have to sit down and do some exploring every so often, to find out these sorts of operational problems. Packet captures can teach you things you can't learn any other way -- if you have the time and skills to read them.

Because detection is expensive. It requires the luxury of having staff both knowledgeable in the technology and in the context of those particular systems, and having them devote a lot of their time just to sitting and looking at things, sorting out what's normal from what's not. Those are the kind of costly eyeballs that have been transferred so frequently to managed security service providers. It's the kind of thing you pay consultants to do, because if your staff weren't completely occupied with keeping the infrastructure running, you wouldn't be allowed to keep them. Data analysis today is expensive, and it's a one-off deal unless you can find economies of scale somewhere.

Yes, automation is getting better, but it's not there yet. There are still too many alerts taking up too much time to sort through (particularly in the tuning phase). IT staff get hundreds of emails a day; they can't handle more than two or three alerts that require real investigation. (By the way, this is why operations often can't respond to something until it's down -- it's the most severe and least frequent kind of alert that they receive all day, and they don't have time to chase down anything lower-level, like a warning message that hasn't resulted in badness yet.)

If you break security events down, you're generally looking for two kinds of things: normal activities that are being done by the wrong people (as in, from a Tor exit node through your administration console), or abnormal activities that are being done by the "right" people (internal fraud, or someone has taken over an authorized account). And by "people," of course, I also mean "systems," but at first glance it's sometimes hard to tell the difference.

This determination of "wrong" and "right" is a security activity, and for the reasons I listed above, operations people may not care that much until it makes something happen that they have to fix. If someone wipes a database, they'll care a whole lot, but if there's some unusual encrypted traffic leaving the enterprise on port 80, not so much. A fully leveraged (i.e. overworked) ops team doesn't have time to analyze alerts at that level.

"Wrong" and "right" to the business is on a completely different stratum, and it's one that's hard for automation to reach today. Executives care when it gets to the level where they have to do something about it, like fire someone for looking at patient data, or talk to the press about a breach. They care when an event starts to present the risk of legal liability or increased cost. But you can't bring them alerts like that until you have digested everything at a lower level and put together enough evidence to reveal a business issue.

And finally, historical data can be extremely useful in determining what works in security and operations and what doesn't. But that kind of data has to be analyzed in a different way from real-time operational data or situational data. It requires a different model that caters to the requirements of risk analysis -- and that, too, is expensive, even assuming you know how to do it today. (Hi, Chris.)

My point here is to say that data-driven security is where we need to go, absolutely. But there is no single path to take with the data we have; there are a number of divergent paths that are all needed in the enterprise. We also need to be able to drive the data in the right delivery directions -- which means that we need a really good data navigation system.

Security: ur doin it rong.

2012-02-09T05:23:00.000-08:00

As I mentioned before, a lot of security work consists of telling people they're doing something wrong. There are all the "thou shalt nots" in security policies, there's the "scanning and scolding" of vulnerability assessment, and there's the "Ha! Got you!" inherent in penetration testing and exploit development.

In other words, it takes a lot of moxie (pun intended) to stand up to a security professional.

Rob Lewis, aka @Infosec_Tourist, made the comment yesterday:

You're right. Nobody says "we're screwed!" with as a sincere and calm demeanour as @451wendy.

Which I appreciate, but it's been bothering me lately that that's almost always how we discuss security.

In his preso at Security B-Sides London last year, David Rook (aka @securityninja) made a great point about application security: if we taught driving the same way we taught secure development, we'd make a whole big list of different ways you could crash the car, but never actually tell the student how to drive safely.

A good number of talks at security conferences focus on what we (or other people) are Doing Wrong. Very, very few are about how to do something right. Part of the reason for this, of course, is that practitioners are afraid to stand up in front of an audience and talk about how they're defending themselves, for fear that someone in the audience will take it as a challenge and de-cyber-pants them before they've even gotten to the Q&A session. (I've heard tell of presenters' laptops being hijacked in the middle of a presentation.) I know a lot of practitioners are doing very cool things that their management would never let them say publicly.

But when we focus too much on what people are doing wrong, there's a danger of our talks turning into pompous lectures. "We need to do something different from what we're doing today." Okay, but what, exactly?* This is why I admire those who are proposing alternative solutions, such as Moxie Marlinspike's Convergence. These folks might be right, or they might be wrong, but at least they're trying to make things better.

So, lest this turn too Gödel, Escher, Bach on us, I'll stop lecturing too, and talk about what I plan to do about it. I'm going to do more talks about what I think works in security. I've done a few before on topics such as how to bootstrap an infosec program, what multi-contextual identity and access management looks like, and how to dicker on the contract with third party providers. I won't aspire to #sexydefense; I'll leave that to the ones who show up all the time on the Top Ten Infosecsiest lists. But I'll encourage people to turn that frown upside down, and try not to bring up a problem without also proposing a solution.

Maybe this way, we can get invited to a few more non-security parties instead of having to throw them all ourselves.

*No, the answer is NOT "use our product." Thanks for playing, though.

Insecure at any speed.

2012-02-08T05:47:00.000-08:00

With the release of breach data reports, such as the one from Trustwave SpiderLabs that came out recently and the highly anticipated one from Verizon Business, inevitably comes a wave of data dissection and then disbelief. Security pundits moan at the statistics, such as the one this year that 78% of organizations that Trustwave investigated had no firewalls at all. The report itself takes an incredulous tone as it describes the pervasive use of unencrypted legacy protocols (one highlighted case study described a breach involving an X.25 network), insecure utilities such as telnet and rsh, and more.

Security pros who specialize in this sort of thing may be surprised at how big the problem is, particularly among smaller enterprises, but anyone who has actually tried to implement security in these organizations isn't surprised at all. You can tell by the faces in the audience when one of these talks goes on: it's the difference between "ZOMG!" and "Yup, *sigh*."

It's not that these organizations don't care about security. You'd have to know about security first in order to care about it. The next time you go to a sandwich shop or a gas station, ask the manager about the security in the POS system they're using. It should be an interesting, but very brief, exchange.

Should everyone be able to manage their own security? It's very much out of reach for those below the security poverty line; when you think about it, the level of security management needed for technology today reaches the equivalent of having to rebuild and restock grocery shelves on a weekly basis, or requiring an accountant to know construction, electricity and plumbing for the office. Just reading through the Trustwave report, and all the myriad ways that systems are breached, I can't help but imagine the look on a manager's face if I made it into a checklist and handed it out. Who outside of the clannish IT industry knows how to spell ftp, much less knows that it's insecure? Who would know the better options and be able to implement them? Who has the time to examine and reconfigure computers on a regular basis?

What this indicates to me is that our IT infrastructure -- from the networks to mobile -- is inherently, badly insecure. And we're so far down the road in its widespread implementation that it will be decades before the problem is substantially fixed, even assuming we started today with all software developers and manufacturers. Nobody is going to pay to replace what's running just fine today -- until someone loses a figurative eye.

As technology advances, organizations have to deal with an ever-widening range of technology that they have to try to get secured. Yes, there are still X.25, COBOL, VMS, DOS, NT, SunOS, Sybase, and token ring out there. At the same time, iOS and Android are coming into play, along with "the cloud" and Hadoop and NoSQL and everything else that's new. A CIO needs to know about all these; a CISO has to know how to secure them all -- especially when older systems aren't compatible with updated software. The complexity grows year by year, and the inertia of the legacy environment weighs more heavily on it.

And make no mistake: security is disruptive. It's enormously disruptive. Getting the network architected correctly, every version of software patched and every configuration right, especially after the system has been in use for a while, is as disruptive to the business as migrating to a completely new system or platform. Ask anyone who has tried to manage a security initiative in an enterprise. Even assuming the enterprise wants to do it, it's a major undertaking. All this shows how badly security is designed today; you shouldn't have to keep reconfiguring your systems on a weekly or monthly basis in-flight just to keep the security entropy at bay.

It's an intractable problem, and frankly, it's one that the enterprise shouldn't have to solve. People are trying to work with the equivalent of a pencil, and it's not their fault that their pencils are fragile, complicated, and prone to exploding at inopportune moments. They shouldn't have to know or care why the pencil isn't working; they want a new one without any delay, and without hearing long stories about how the graphite in this type of pencil isn't backwards-compatible with all the erasers in the firm.

So when we read about how bad security is getting, we shouldn't be pointing the finger at the compromised enterprises. We should be pointing it at their IT providers, who really ought to know better; but more fundamentally, we should be pointing it at ourselves. We should stop demanding that the user be responsible for security; those of us who are building this stuff to begin with should fix it ourselves, and build it in to all future technology. Today security is an afterthought, and a bad one at that. As long as it remains separate from the systems it's supposed to protect, instead of being simply an attribute, and as long as it requires users to maintain an abnormal height of awareness as they go about their daily jobs, security is going to continue to be as bad as it is today.

Analyst geometries.

2012-02-07T06:55:00.000-08:00

Quadrants and cycles and waves, oh my!

We're all familiar with the best-known graphics, in which there are #WINNING parts of the page and #LUSING parts. In fact, I like anything that lays out concepts and relationships so that I can pick them up at a glance, like this lovely "subway map" from The Real Group. I've argued that my employer needs a "magic dartboard" so that we could write reports like this:

"Vendor X is in its third year right next to the bullseye. On the other hand, Vendor Y took a wrong turn recently and is now firmly wedged in the fake wooden paneling on the wall."

I myself have presented a Punnett Square of Doom before; we have Christofer Hoff's Hamster Sine Wave of Pain; and we have the one that started it all, Andrew Jaquith's Hamster Wheel of Pain. Someone even proposed a magic quadrant for analysts, with one axis being "ego" and the other being "clue." (I'm not drawing that one up; someone else will have to do that.)

However, the issue in drawing something out, especially as a chart or graph, is that people want to see numbers (mostly so they can argue with them: "We should be at least 3.5 to the right!"). And where there are numbers, there is a danger of misleading math holding it all together: quantitative depictions of what are really qualitative properties. I don't think anyone means "20/300" when describing a company's vision.* There's also a tendency by decision-makers to turn the positioning into a binary sort of proposition: "Upper right or not? Okay, I'll sign the purchase order." I've never had a discussion in which I successfully argued for one vendor over another based on one being eighteen pixels down but twenty degrees north-northwest of the equator.

So what kinds of graphics are useful without turning the exercise into a rating system? I started a mind map of vendors in one particular sector, in which I simply tried to categorize them by offerings, show who was reselling whom, and who was partnering with whom. It turned into a confusing mass of spaghetti faster than you could say "al dente." It certainly wouldn't help anyone who was trying to evaluate products.

The problem is, sectors within security are blurring and merging, companies are building out portfolios, and everyone's adding discrete functionality from different categories. Static and dynamic security analysis, for example, aren't separate revenue streams for some vendors who do both, and it'll just get more muddled when you add "glass box" or "hybrid" testing to the mix. To make matters worse, some vendors invent a new sector for themselves: "We're not Category X! We're next-generation big data hybrid security snorkeling!" There just aren't enough drinks at RSA to make up for that kind of headache.

So any kind of graphic that I can come up with to depict market placement is going to look more like Jackson Pollock than a fixed geometry, maybe with contrails behind some of the vendors going in different directions from their current paintdrop. Especially with the startups, the best I could do would be to create a magic pinball machine. I'll mull it over some more and let you know what I come up with for the next report.

*Although it would be really fun to get into business astigmatism or technology presbyopia. Hey! Magic Spectacles!

Of Egyptian rivers &c.

2012-02-06T05:21:00.000-08:00

Just for fun, I've compiled some of the top security excuses I've heard in my career.

It's okay, it's behind the firewall.
Won't antivirus catch that?
No, we don't have confidential data on our system, just these Social Security numbers of our employees.
But nobody would do that [exploit of a vulnerability].
I can't remember all these passwords.
My application won't work with a firewall in the way.
They won't be able to see that; it's hidden.
It's safe because you have to log in first.
No, we don't have credit cards on our system, just on this one PC here.
We didn't HAVE any security issues until YOU came to work here.*

*True story.

Eating the security dog food.

2012-01-13T12:55:00.001-08:00

I kept meaning to get back to Rafal Los's post on "The God Complex" -- and answer his question.

Are you an exception to your own security policies?

To which my answer is (was): no. In fact, as a CISO I tried hard to follow every policy.

Why? Because if it was too annoying for me, if it kept me from getting something important done, then it was probably obstructing other people too, and I should change the policy.

Admin rights? There should be policies governing their access too -- arguably even more of them, because the more access you have, the higher the standard you should be held accountable to. For their own protection as well as that of the users, admins should be able to demonstrate that there are checks on their powers and activities, and that they can be open about what they're doing. It's harder to be accused of nefarious activities if you are completely above-board, show that you're willing to be subject to appropriate limits, and make a point of relinquishing any sole powers you might have. Call it CYA, call it leading by example, whatever. It's ethically important.

Not only is it the right thing to do, but it also helps in user relations. A lot of security is about telling people that they're Doing Something Wrong. And if you're going to be telling them that, then you'd better be doing things Right yourself.

Now, constructing things so that everyone has accountability checks all the way up to the top can be harder than you think. It can end up being "turtles all the way up," so to speak. In every organization there's going to be an Ultimate Decider, and the Ultimate Decider is always someone who is too busy to do that deciding. He or she will want to delegate parts of that responsibility back down the chain, leading to conflicts. For example, someone can end up being deputized to submit and approve requests rather than having those broken up into separate duties, or be empowered to monitor the activities of their own bosses. Sure, there will always be exceptions to policy, but the point is to design them so that they still have checks and balances on them -- not to ignore them and let them be gaping holes in your controls. They need to be documented five ways from Sunday, approved by as many people as you can hunt down, and changed back to normal as soon as they're no longer necessary.

I'm sure everyone agrees that those with power need to be held accountable for that power, whether it's a government executive, law enforcement officers, the military, or any other person in a leadership position. In security, you don't need to be a leader to have power, but you still need to be conscious of what you can do, how someone could abuse it, and how you can make sure you're not the one who will do the abusing. You've got to protect the enterprise from external and internal threats, but one of those threats is you. Go look in the mirror and start threat modeling.

Why we still need firewalls and AV.

2012-01-13T06:52:00.000-08:00

It's become trendy to talk about how ineffective some commoditized security products are, classic firewalls and AV being the poster children for this. One of Josh Corman's favorite points is that "we never retire any security controls." But as fond as I am of Josh, I think he's wrong in his implication that we should.

Let's take my firewall. (Please.) It's still blocking what it's supposed to block; it's just that the ports that I need to leave open (such as 80 and 443) are now carrying all the traffic as a result, and those protocols are being used to tunnel attacks these days. The firewall is doing its job; it's just that the job is no longer as sufficient as it used to be, back in the '90s.

In the same vein, we still have umbrellas, even though they're not terribly useful in a hurricane. Nobody would tell you to throw away your umbrellas because they're "ineffective" -- nobody, that is, except the maker of a Next-Generation Umbrella. (And while we're on the subject of umbrellas: I really hate it when firewalls are described as stopping "millions of attacks per day." An umbrella isn't rated by how many raindrops it blocks and how wet you didn't get every day. A probe shouldn't count as an attack; it's just a raindrop to a properly configured firewall.)

Now, it's important for a consumer to understand the limits of the umbrella and not to believe that it will stop someone from getting wet in a hurricane. It's also important for consumers to know that even if the chance of a hurricane in their area is small, there are still tornados, sideways winds and Advanced Persistent Puddles to contend with, and they should plan accordingly. They shouldn't pay a whole lot for an umbrella that is not going to protect them in all use cases. But it's still useful for what it does well.

The functions that classic firewalls perform are so commoditized that they're tucked into just about everything right now; I could wear them as earrings if I felt like it and someone made the right form factor. In the future, it should be a given, and therefore not worth marketing. But we will always need that functionality for as long as we have network traffic that doesn't automagically inspect and block itself.

Same thing goes with anti-virus. It's necessary but not sufficient, and it ought to come in every cereal box, not as a standalone product that will completely solve any given problem. Classic viruses are still out there, and they still need to be stopped, but advances in anti-malware, anti-phishing and other forms of automated defense still continue to pick up where classic AV leaves off. More sophisticated inspection and detection methods need to be developed, but that's a universal problem in security.

My belief is that users need education, not exhortation to throw out perfectly good controls that just aren't covering as much of the attack space as they used to. They need to know what each security product will and won't protect, and they need to understand this in a non-technical way, just as people have learned over time that air bags plus seat belts are better than seat belts alone, without needing to know the mechanics of how they work, and without having to do threat modeling when they buy a car.

So if you don't agree with me, and you've really stopped using these products, I'd love to hear about how you're addressing those classic threats, and what controls you replaced them with. (You don't get any points if the threats don't apply to what you're using; of course your toaster doesn't need AV. But your smart meter just might.)

Well, that was unexpected.

2012-01-06T08:06:00.000-08:00

I have to thank whichever sneaky judge it was (and I have my suspicions) who nominated this blog for a Social Security Blogger Award. Honestly, I only started the blog when I did because I figured it would be disqualified on account of my being a judge as well; obviously I didn't read the fine print.

But there are a lot of great nominees out there (I should know; I picked some), and although I won't be at RSA myself, I'll be watching the bitwaves to see who ends up buying the drinks later that night at the Irish Bank.

The Security Poverty Line, and junk food.

2011-12-23T10:04:00.000-08:00

I've given talks on this before, and published a report (available for free here), but I haven't really put everything in one place until now. I coined the term "security poverty line" to describe those organizations that, for one reason or another (usually a lack of IT funds), can't afford to reach an effective level of security, much less compliance with security regulations.

When you don't have a lot of IT money, you can't afford your own IT staff (or you go with whatever you can borrow or rent). This means you don't have in-house expertise to maintain a decent level of security controls and monitoring, even assuming you get systems and networks configured right to begin with. As we all know, security is an ongoing process, and if you have Jane the IT Girl as your sole resource, she's going to be too busy troubleshooting problems and installing new systems to be able to maintain the existing ones in a proactive fashion.

Organizations below the SPL tend to be inordinately dependent on third parties for this reason, and since they're so dependent, they have less direct control over the security of the systems they use. They also end up ceding risk decisions to third parties that they ideally should be making themselves.

And they don't have resources for luxuries, such as separate systems for different tasks, or different personnel to achieve segregation of duties. They'll tend to throw everything on the existing old hardware until it breaks, or until the performance is so unacceptable that they're forced into paying for more. (This is why nobody should be surprised that the public sector has to struggle with crowded, antiquated systems. How many taxpayers are going to pay for upgrades just to keep everything new and shiny, when the old systems were working just fine?) They'll share data and networks with partners. They'll use the cheapest software they can find regardless of its quality or security. And they'll have all sorts of kludges and back doors to make administration easier for whoever they can convince to do it.

So although some people see the failure to achieve compliance or effective security as simply a matter of attitude ("if you really cared about auto safety, you'd buy a Mercedes!"), it's not that simple. Even upgrading and untangling a set of legacy systems can double the cost of migration to a new platform, due to system inertia and missing institutional knowledge. Any consultant who has had to step in to one of these environments to fix something knows what it's like to pull on one thread that appears to have an obvious solution, and discover that it's attached to too many other things that can't be easily changed.

Not only that, but certain types of security technology are more expensive than others. In a talk I gave at the UNITED Security Summit this year, I showed some figures from some back-of-the-envelope surveying I did on what $2,000 can buy you; slides are available here. (Even $2k is a lot of money to justify spending on security for a lot of these organizations.) As it turns out, most of the affordable security technology is the oldest kind, the least effective, and mostly preventive in nature -- firewalls, antivirus, and a scanner that will tell you what's wrong with your systems that you can't afford to fix. The newer stuff, especially anything that involves proactive work and monitoring, is out of reach. Enterprises below the SPL are not only stuck with the equivalent of burgers and fries, they can't afford any vegetables (thanks to Alan Shimel for making this more explicit).

Open source, you say? Tell me if your dentist's office uses open source software, and who there knows how to install and maintain it. Open source software is expensive when you include the expertise needed for support. (I chatted with Alan about this one time when a recording was running.)

What this means is that many organizations that slip into security poverty tend to get trapped there. Unless they can afford to do a greenfield transfer to a provider with a squeaky-clean new network and managed security services, they will just keep patching what they have, and only do the minimum that is going to fend off their biggest, most visible risk: the auditor. Rather than continuing to beat them with the compliance stick until morale improves, we need to make security services more affordable (and there are some providers who are working on just that). We need to build security into products and deliver them already secured, so that security isn't an add-on luxury. We also need to create more hands-on resources -- perhaps as a community service -- that poorer organizations can draw on, not just to give them guidelines, but to adapt them to what they can afford to do.

And finally, we need to be able to state clearly what effective security looks like. The great thing about compliance (yes, I really did just write that) is that you know when you're done. When the last box has been checked, you have that sense of accomplishment, and it's straightforward to know whether you pass or not. I challenge anyone in the security community to tell me what, say, a 50-person company needs to buy -- even assuming they have a blank check -- to make sure they are doing everything necessary to manage their risk. (Hell, I challenge anyone to tell me what their risk is without using colors.)

At least there's a food pyramid (or plate, or whatever -- they keep changing it) to describe the minimum daily requirements for nutrition. What should be on the security plate for a healthy organization?

Update: I talked with Tracy Kitten at BankInfoSecurity.com about the topic here.

Guest Post: The Angry Angry CISO.

2011-12-23T07:34:00.000-08:00

I'm happy to publish a guest post from someone I'll call the Angry Angry CISO. Obviously they speak only for themselves, but boy howdy, do they go well with popcorn. Enjoy.

_____________________________________

It’s a tough time to be a CISO in an enterprise of any size these days. I don’t want to be a whiner, but when you look at the challenges being faced by the folks who play permanent defense, things are looking pretty bleak. APTs to the right of us, auditors to the left of us, onward – onward – into the Valley of Compliance…

But that’s not what I’m here to talk to you about today.

I’m here because so many in the “security researcher” community have become -- well, hypocrites.

WHAT?

Lemme s’plain. No, it’s too much – I sum up.

When the CarrierIQ story broke, what happened in our community? People went berserk. “How could they do this?” “It’s EEEEEEVVVVIIILLLLL!!!” “They should be prosecuted to the fullest extent of the law!” and on and on and on.

And for what?

For something that the vast majority of them would have been cackling in glee about had someone in a black t-shirt and questionable personal hygiene been presenting it in a meeting room of a hotel in Vegas. Had the CarrierIQ tech been revealed by a “researcher” it would have been seen as further evidence of the total incompetence of the carriers, phone manufacturers, and phone OS providers. Had a “researcher” presented CarrierIQ, anyone who said, “Gee, this tool could be used for underhanded and devious things” would have been scolded into submission on the Twitterz because, after all, The Community Needs These Things.

Yeah, right.

What gets this CISO angry (amongst diverse other things) with the community is that we have developed a serious case of situational ethics. We readily explain away the things we do that could negatively impact the security and privacy of millions of people as “projects”, “proofs of concept”, and “just plain old hacking”, but throw a complete conniption fit when a corporation does the same. Are we that special? Or does being a hacker make one impervious to irony?

Look – I expect hackers to be hackers. I know that any piece of technology I own or gets deployed in the factory is going to get hacked at some point. I accept that. I also expect companies to be companies. I know that anything I buy for myself or the factory probably is gathering information for the vendor to use in marketing, etc. I accept that.

So should you.

__________________________

The Angry Angry CISO, when not writing as part of anger management treatment, is the head of information security for a medium-sized enterprise somewhere in North America. The Angry Angry CISO speaks only for the Angry Angry CISO.

Remember, predictions make a ...

2011-12-20T07:31:00.000-08:00

Oh, no, I almost went there. Pull up! PULL UP!

'Tis the season for half of the security world to make predictions, and the other half to make fun of them. Why do we even bother to make predictions, anyway? In the analyst world, it's another chance not only to show you've been thinking hard about these topics, but also to talk about what you'd like to see happen. Predictions can be a great way of starting conversations, if you look at them the right way. (If you look at them the wrong way, they're great for raising a huge chorus of "Nuh-UH!" or even "You're kidding, right? Call the coroner?")

But let's have some fun with unofficial "predictions" that are intended, as the horoscopes say, for entertainment purposes only:

Big Data, having shed its sizeist origins and become Total Data, will go on to become Totally Leaked Data.
Security teams will finally get invited to the table -- that is, the table at the pub where they can drink and commiserate with the legal, HR and audit departments.
PCI will become the most widely used de facto security standard for cloud services.*
Personal feuds will break out among security researchers and they'll start hax0ring each other, leaving the rest of us to breathe a little easier as we polish our Generation Z Firewalls.
Patent wars will escalate among security vendors, causing a new crop of IT lawyers to go shopping for Maseratis and stimulate the economy.**
Some enterprise somewhere will try to ban all email attachments in an effort to stop phishing, and text-only messaging on retro CRTs will become hipsta.
Someone will try, and fail, to rename The Cloud into something more ambiguous.
Security conferences will become Big Business, and some people will leave their hands-on security jobs to run them full-time.
An analyst will issue a prediction with an actual number in it. However, this number will be an attempt to quantify a qualitative metric, so it will be useless. "GRC dashboards will be 15% greener!"
Nobody will make risk management any more understandable than it is today.

*Okay, I slipped in something a little too close to the truth.
**You're probably wondering how I came up with such a far-fetched idea.

Now that I've gotten these published, feel free to refer back to them at this same time next year, and if any of them are proven wrong, you'll get your money back. Guaranteed.

That's not a bug, it's a creature.

2011-12-13T06:47:00.000-08:00

Adam Shostack posted a great expansion on the very short Twitter conversation we had regarding threat modeling. I think we agree on most things, but I sense a little semantic disconnect in some things that he says:

The only two real outputs I’ve ever seen from threat modeling are bugs and threat model documents. I’ve seen bugs work far better than documents in almost every case.

I consider the word "bug" to refer to an error or unintended functionality in the existing code, not a potential vulnerability in what is (hopefully) still a theoretical design. So if you're doing whiteboard threat modeling, the output should be "things not to do going forward."

Or not. You see, there are two reasons why I think estimating probability is crucial to threat modeling. One is simply that motivation is the difference between targeted and opportunistic attacks. And there's a lot of difference between managing an opportunistic risk (make sure your virtual pants aren't down) and a targeted one (call in the brute squad and batten down the hatches).

But the other reason for considering probability in threat modeling, even in the design phase, is that you may already have constraints that you need to work within, and those constraints may carry their own risk. For example, a mandated connection to a third party: "We could be vulnerable to anyone who breaks into their network." The business will say "Too bad, do it anyway." As a result, you're stuck with something to mitigate, probably by putting in extra security controls that you otherwise wouldn't have needed. I consider this a to-do list, not a bug list.

Now, if you're working with an existing application when you do threat modeling -- and I've used Adam's most excellent Elevation of Privilege card game to do this -- then yes, the vulnerabilities you're identifying are most likely bugs, and they need to be triaged using probability as one input. (And the sad part is that the "winner" of an EoP card game is also the loser, with the largest number of bugs to go fix.)

Either way, though, the conversation with the project manager, business executives, and developers is always, always going to be about probability, even as a subtext. Even if they don't come out and say, "But who would want to do that?" or "Come on, we're not a bank or anything," they'll be thinking it when they estimate the cost of fixing the bug or putting in the mitigations. It's a lot better to get the probability assumptions out in the open, find out what they're based on, and have an honest conversation about them. (My favorite tool for doing that is a very simple, high-level diagram from FAIR.)

More than that, though, I always enjoy a conversation with Adam, whether it's over tapas or over the Intertubes. Same goes for Alan Shimel, who just added his two cents* about how blogging should be a conversation. It's a shame we can't always do it on Twitter, but that's a good place to start the fire.

* Adjusted for inflation and intrinsic value, that's now about $83,000.

=======
UPDATE: Adam came right back with another volley here. I'm too tired to think of another clever blog post title, so I'll just add it at this juncture ...

I simply think the more you focus threat modeling on the “what will go wrong” question, the better. Of course, there’s an element of balance: you don’t usually want to be movie plotting or worrying about Chinese spies replacing the hard drive before you worry about the lack of authentication in your network connections.

Absolutely. And you'll have to keep track of all the things that could go wrong (with varying levels of probability and mitigation), including the ones that you just can't fully address for one reason or another, like the aforementioned third party connectivity. Or, to take Adam's example, the lack of authentication in your network connections may be a known problem that is going to be fixed Real Soon Now (unless the budget goes away), or can't be fixed (you don't run the infrastructure and have to convince someone else to fix it -- hello, cloud!). Known exceptions, mitigations, and problems that need to be solved at layer 8 and above all go into the list, especially for when the auditor comes around, or even the next pentester.

I also find that the design phase is a really good time to talk about ensuring availability and performance -- in short, making the application Rugged. (Yeah, I'm not a manifesto type myself, but the principles are still worth incorporating.) Helping the developers solve for those kinds of issues -- ones that probably stay longer on their radar -- also helps them be more open to the security vulnerabilities you're looking for.

(I'll write more on Rugged Software in another post.)

Thanks, Adam -- I'm getting hungry now for almond-stuffed, bacon-wrapped dates with goat cheese crumbles and a red wine reduction ...

What your analyst wishes you knew.

2011-12-07T11:49:00.000-08:00

Not naming names here, but these are a few things that some industry analysts would like you to know:

If you claim that your product is the "world's only" or the "first," I will be tempted to prove you wrong, and nine times out of ten, I can.
Please don't assume that I'm not technical. Make your presentation detailed, and I will ask you if there's something I don't understand, but starting out by explaining what a firewall is does not win any points.
You know how some vendors send out a marketing email using the latest headlines as soon as they come out? That's ambulance chasing. Don't be that guy.
One-way webinar-style briefings are a waste of your time and mine. We have a chance for a good, personal dialogue; don't throw it away on a cattle call.
I'm happy to hear about any factual errors I've made in a report about you, but if you object to an adjective I used ... sorry. Not changing it to fit your marketing better.
Yes, I talk to your competition. Don't worry, I love you all equally.
I try hard to find something positive to say in all my reports. If I can't, then I don't write one. If I haven't written about your latest ... you might try asking me why before complaining.
Yes, it's very nice that you're in the Magic Quadrant. It doesn't have anything to do with my analysis, though.
If you want to meet up at a conference, that's great, but please book EARLY. Especially for RSA.
At the end of the day, this is only my opinion. As an analyst, I reserve the right to be wrong.

Baby, it's Veracode outside ...

2011-12-07T09:02:00.000-08:00

Just read Veracode's chilling new State of Software Security Report, Volume 4 (I'm just waiting for the Greatest Hits to come out), and it's pretty depressing. Among those organizations that use Veracode in any capacity -- testing their own applications or someone else's -- things haven't gotten all that much better.

As I've said once or twice in my talks, I like to learn about how security goes wrong; how the best-laid plans of CISOs gang aft agley. One of my favorite German words is Sollbruchstelle: the place where something is supposed to break or tear, such as a perforation. And as my lovely and talented spouse points out, "Sollbruchstelle heißt nicht unbedingt Wollbruchstelle" -- just because something is supposed to break at a particular place doesn't mean it will. For this reason, I'm interested in other data from reports like Veracode's and those of other vendors. Why are we not seeing more progress in securing software? Is it really just a matter of awareness and education, or is it something more?

Reading between the lines of the Veracode report, we see the statistics on the number of applications that never get resubmitted for testing, but not much explanation as to why they didn't. The authors seem a little puzzled by this, but it makes a lot of sense to me: the applications probably never got resubmitted because they haven't been fixed yet. I'd love to see data over a longer period of time for those enterprises to see which fixes got made quickly, which ones took longer, and which ones were pretty much abandoned.

I tried doing a meta-analysis at one point among the various "state of the state" reports for application security to see whether there was a large difference in findings between dynamic and static testing. The effort sort of fell apart for a number of reasons: one, because not all reports described the data in the same way, and two, because vendors are increasingly melding static with dynamic both in their tools and in their revenue streams. In the few places where I was able to do a one-to-one comparison (as best as I understood the language in the report), the statistics from static analysis tools were all very similar to one another, and the dynamic ones were also very similar for a common set of vulnerabilities; there were marked gaps between the two types of testing results.

Of course we know that static analysis and dynamic testing are two different beasts; that's no surprise. But I'll be very interested in seeing how the two are bridged going forward. I think there needs to be some sort of translation between the two before a significant amount of correlation can be done; and Dinis Cruz thinks it ought to be an abstraction layer. This is a good idea, but before it can be abstracted it needs to be normalized, and we can have a lot of visibility into how the application is functioning in real time, but unless we can describe all the testing with the same words, I don't think we're going to achieve enough understanding of the problem space. (Yeah, I'm getting my Wittgenstein on.)

So kudos to Veracode for adding some more to the shared knowledge out there. It's clear that we have more work to do, and only outcome data will really point us in the right direction. We need to understand why and where things break before we can make sustainable progress.

My opinions, let me show you them.

2011-12-07T07:10:00.000-08:00

Well, this is really Tripwire's fault. I realized that not only am I the only ch1XX0r on the list along with the incredibly smart Allison Miller, but that we two were the only ones without a blog.

So, um, hi. It should go without saying (so I'll say it here anyway) that anything I write here isn't on behalf of my daytime employer. I may link to reports I've written, and they're behind a paywall -- sorry about that. This blog will contain the thoughts and opinions I don't get paid for, which means they're probably worth what you're paying for them.

Please keep your arms and legs inside the drama at all times, and enjoy your flight.