SecurityCurve Weblog

Security, Economy, and Les Mis

So interestingly, we've been reading some articles over the past few days that are speculating heavily about what the current economic meltdown will mean to us guys over here in IT security and risk. The net consensus appears to be - with budgets shrinking and credit freezing up, spending on IT risk is going to be hard hit.

Really? We're not so sure about that. Historically, security spending goes up when perceived risk goes up. Look at DHS in the post 9/11 era. Or your own house after a break-in. Or your company's spending after a worm took down the mail server.

Also - what about the way spending soared after key regulations and bills were passed? While it might have been hard to sell the CEO on file/disk encryption before SB1386, et al came into effect, it became a "get it done" spend for many afterward. Couldn't get the budget for wireless intrusion detection or application scanning before PCI? After high-profile breaches like TJX, Forever21, and Hannaford, executives freed funds and started demanding why purchases weren't being completed and implemented fast enough. And the big Daddy of 'em all - SOX. Implemented to, ostensibly, prevent another Enron, but in reality a huge spend in IT governance, risk, and audit.

So, sure, we agree that budgets are going to shrink overall. And that many companies will not withstand the credit freeze and financial turmoil. But for those who do - we suspect there's going to be increased oversight (The Financial Stability Oversight Board and congressional oversight panel in the current "bailout" for example) and that's going to translate into IT security and risk spending. Not because it's right necessarily, but because it's going to be mandated by overseers, auditors, and examiners. We're in for a bumpy night.

Now this is a bit more speculative, but we could even see a direct increase in overall electronic fraud and crime given the new economic outlook. Studies show that straggling economic conditions tie directly to increased crime rates - lower wages, worse economy, more crime. So, even assuming those folks who foresee less spending are right, it could lead to higher spending once the initial hit is over. It's like the dude from Les Mis - he was a decent guy, but needed to steal bread to feed his family. And some percentage of that crime will be electronic crime - meaning more need for risk, risk managers, and infosec.

Audit's going up, perceived need will go up, and fraud is likely to go up. Sounds to us like business could actually boom in these conditions.

Blame the Victim? Blame Human Nature...

Emergent Chaos, because they're awesome, posted this discussion the other day responding to Ars Technica calling most users idiots. In case you don't feel like reading the background material on this, a bunch of scientists over at the Psychology department of North Carolina State tested the response behavior of a number of subjects when presented with "fake" dialog boxes such as might be presented by malware, trojans, or other unwanted software.

What they found was that users click on fake dialog boxes - no matter how outlandish they look or what warning signs that they include that the dialog box is dangerous (or suspicious). Now, from this evidence, Ars Technica concludes that the users in question are (in their words) "idiots". Sigh. Emergent Chaos claims that it's the developers who pop up useless dialogs that are the idiots. Hmmm... Closer to the truth maybe, but I think there's a much different process going on here.

First of all, you can't blame the users. You absolutely cannot. Not just because that would be "blaming the victim" (which is admittedly uncool), but also because they'd be hard-pressed to behave any other way than how the NC State folks found them to behave - in other words, they are just responding in a way that is consistent with human nature. It's called "habituation" - in other words, the more dialog boxes that you show somebody, the more people just respond without analysis.

Which moves us to the developers. Do you blame developers for putting up dialog boxes? Well, I'm not sure about this one either. Developers usually learn pretty early on the principal of "when in doubt, ask the user." All kinds of crazy shiz could happen in any snippet of code - how do we know what to do or how to try to recover? Throw up a dialog. So that's already ingrained. But even if developers could write an app that didn't put up any dialog boxes at all, don't forget that Windows would still pop them up anyway without our knowledge or consent. In fact, that error box that the NC State guys used? NOT a developer-initiated dialog box - Windows puts it up "automagically" given a certain set of parameters. it's the default behavior for a corrupted pointer: no intervention necessary on the part of the developer to make it happen. Somebody just trashed a pointer a mite early - it happens *all the time*, and it's *crazy hard* to fix. Now, I'm not saying that developers don't come up with all sorts of unnecessary dialog boxes (I see thousands of them every day), but I'd say a good 50 percent of error boxes are just windows being windows (or macs being macs, or linux being linux).

So, who's fault is it? Well... I'm not sure I know, but I'm not going to be first in line to point fingers... Maybe we can just agree that it's a confluence of events and work on fixing the problem rather than assigning blame.

Risk Managment: It's Pretty Meta

Ed just posted on a blogversation regarding what's wrong with risk management. The net of the discussion came out to treating the sickness not the symptoms when dealing with risk. Ed added the concept of proportional levels of risk in context.

I wholeheartedly agree - but there's an additional point about context that I thought might be useful for us to consider. We don't know the whole system, so treating it systemically is even trickier than treating only symptoms.

What do I mean? Well, for anyone that remembers the faux Mac Ads that VH1's "Best Week Ever" did a few years ago, I mean what happens when we create a mash-up of Gnarls Barkley tunes and Hitchcock's Psycho? Not doing that in your enterprise? Okey, what about what happens when my Enterprise or Intranet Portal application relies on consuming services, widgets, or some other piece of code that was created by some entity outside of the system? What if our internal resources are updated and fed with information from someone outside? How does the interaction impact my organization's systemic risk? How is the system impacted by events that occur outside of the system as a whole?

Parsing it out - consider a UL (Underwriters Laboratories, Inc.) approved piece of electronic equipment, like, say, a toaster. The toaster has been vetted and tested and works perfectly in the correct context: plugged into a properly grounded wall socket, no knives being inserted to fish out errant toast pieces, etc.

Now consider a nice bath. The water heater in the house is configured to prevent scalding water coming out of the tap. The tub itself is properly caulked. And the aroma-therapy bubble bath in the water is paraben-free.

Right. Nicely risk managed piece of toast waiting for us after the nicely risk-managed bath. But in a “mash-up” (and read in SOA or Web 2.0 here, they both fit) environment, maybe I want that toast while I'm having the bath. Heck, it's a partial continuous attention world, why not?

Of course, we know why not. Even though I’m using the toaster properly, and I'm using the tub properly, the consequences of bringing the two components together is catastrophic for the system as a whole. Like your enterprise, there are a number of contextually complicating layers beyond the single system that we have to figure out before we can get risk management "right."

Agreed, it's about sickness - but what about inherited sickness in an ever consuming, evolving space?

Risk Management: You're Killing Me

So, I hadn't cracked open Google Reader in a while, and I found out that there's been some very large talk behind my sleeping back. For one, I had missed a conversation between Alex over at RiskAnalysis.is and Chris over at How is that Assurance Evidence?. All in all, a really good discussion.

Now, I won't get into the specific points of this discussion, other than to encourage folks to read the original discussion (Chris) and then to read Alex's replies. However, Chris hits on a really good point that really got me thinking, and I do think points to a flaw in the way that a lot of us are doing risk management. Namely, when we break a system down into it's various components, we often don't take into account the impact that a given component has on the overall system.

It's easiest to illustrate this by example. Take a car - if I'm analyzing the risks associated with the headlights, I might have a bunch of assumptions about them. I might have certain assumptions about the impact of a failure in that system - I might say, "well, they're not required to make the car move, they're only needed for night driving, etc." But if they fail, and it's night, the whole system (the car) is non-functional. In short, the whole system is impacted because of a failure of a given part. Now, you might say, "but our risk models are supposed to account for that." But the truth is that in practice they don't. Most of the time, the folks who are creating the models don't have all the data about what the system is used for. They might conclude that because the car won't stop, that the risk level of the headlights is small. They might not know anything about night driving vs. day driving and that you won't be able to drive at night without the lights.

Anyway, I'm going to need to mull this over a bit more, but thanks to Alex and Chris for a very interesting discussion.

Pure, unadulterated, hilarity

Today, Diana came across this on the wild, wild, world of web. I won't spoil the fun by giving away too much of it here - suffice it to say that it is hilarious. Unadulterated hilarity.

I suppose it's funniest because of the grain of truth nestled inside their sarcastic message. Now, we over here would never say that the whole PCI certification process is a joke (please don't interpret what we're saying as anything close to that), but suffice it to say that the fact that we're totally on board with poking fun at those unscrupulous vendors who would attempt to leverage PCI to make a quick buck... as Mastercard would say, "priceless."

IRS security sucks on ice. Why are people surprised by this?

So, the IRS got audited and it turns out that their security sucks. I mean, it really sucks. The part about them having 2000 or so servers with security weaknesses is pretty much par for the course, but what really freaks me out are the additional 2000 or so (alright, 1811 - but close enough) unapproved internal web servers.

Wait. Unapproved? You mean like somebody just came in and dropped some arbitrary web server into the IRS infrastructure? Yep. Now, as you probably know, this happens in every organization. People set up software without permission, deploy apps under the radar, etc. They do all kinds of crazy shiz. But 1811 times? That's more than I've ever seen - even at organizations that dwarf the IRS in size and that are run more or less like the wild west.

Now, this concerns me, don't get me wrong. But are you really all that surprised?

Coffee. Strong. Hold the liquid

So, I was reading today about the Hong Kong police using the Microsoft Cofee toolkit. Interesting stuff. Of course, there hasn't been much data made available to the general public about Cofee (the "Computer Online Forensic Evidence Extractor" for sticklers) ,so I'm eagerly awaiting to see what it looks like.

What I find particularly interesting is whether Microsoft will specifically introduce new features to aid law enforcement in terms of access enablement. The temptation here would be to give the fuzz some type of "get around your security free" card (like people have been worried about), but I really don't think they're stupid enough to go there. Of course, if they're going to rely on autoplay, then I don't see how the toolkit is more helpful than, say, a bootable CD.

Like I say, there's an interesting balance here, and I'm wondering which side they'll wind up on.

Giant Feral Babies Attack Manhattan!!!

So, it's the day after Labor Day (ever wonder why they call it Labor Day when nobody's laboring? Ironic, no?) Anyway, I was getting back into the swing of work this morning and reading through the security news, blogs, mailing lists, emails, etc. and started collecting my thoughts about what to discuss today. Now, I had originally planned on discussing and entry in Donald's new blog, but then I saw the McAfee whitepaper about malware in online gaming via Security News Portal and I figured I can't let them "go there" without opining at least a little bit on it.

Anyway, let me preface what I'm about to say by stating first that I think that the fact that McAfee is concerned about the virtual world idea deserves a kudos. I've pointed out a number of times that these online games are "ripe pickins" for the astute criminal. And they are now - and will continue to be in the future - a place where malware authors (and other shady characters) are likely to concentrate efforts. So, "go go McAfee" for looking under this particular rock to see what you can find.

The one cautionary thing that I'd say about this topic though, is to not get caught in the trap of "giant baby" reasoning. Here's what I mean by that. Say you're an alien biologist in the far future and you arrive on planet earth far after the human race is extinct. You find some human DNA and decide you're going to clone up a few newborns to examine what human life was like. You pop a few newborns out of your "Clonimagic 2000" and you wait to see how the infant develops.

You watch over the first 3 months and see the infant increase in weight by 50%. You watch the next three months and see it increase again by 50%. You try this with a whole batch of infants and they all do the same thing. Since the average newborn doubles in weight during the first six months after birth, if you look at a million babies you'll always see the same thing: rapid, uncontrollable expansion in size. Now, knowing nothing about babies, would it not be reasonable to extrapolate based on the data that the newborn would reach a size just over a ton before they turn four? Absolutely not...

But we know something empirically that our alien biologist does not. Which is that the growth curve for a newborn is sharpest right after birth. So, while a newborn might double in size the first six months, it doesn't do so forever. The same thing is true for example of malware (and other security issues) in virtual communities - there might be a sharp uptick in malware and security incidents targeting these communities during the infancy of these phenomena, but - over time - the growth curve will steady out. Meaning that it's right to look to these communities as a potential source of issues, but don't assume that what we see today will continue indefinitely. We're going to have to wait and see how things pan out over the long term.