Chief Monkey has linked to an excellent case study in corporate banking fraud. The story takes a few pages to work into the juicier details, but it is worth the burn to get through it.

The network still has a perimeter, but the business and its users have less of a perimeter. If you can check email from any system, than your email password can be snarfed by any of those systems if they’ve been victimized by a drive-by trojan. This can often lead to further attacks, even up to logging into a VPN session from a remote location! People like to think of one-time attacks and siphoning of valuable data, but few think about an attacker looking over your shoulder and reading your emails and data continually.

I wonder if the VP in the story had any personal fraud attacks against her as well, or if the company account was the juicier target. In the end, yes, home users (and their systems and networks) elevate my nervousness considerably.

My only bit of caution would be to anyone who starts crucifying banks too much about their security. There is no measure that will magically protect against fraud. It is entirely a scale between security and usability. Some banks fall low on that scale and get burned (hopefully!) for it. Other banks may slide up the scale too far only to get burned because they’re slowing down, flagging, or outright blocking abnormal but legitimate transactions for important customers. What do you do in those cases? Given different perspectives, I think most people would opt for the least economically costly options from their respective perspectives. Just think about that for a while… People complain about bank security, only up to a point where it inconveniences them too much, then complain more when it still fails, and so on. That’s not a rhetorical game I like to play…(maybe I just like to play a few more moves ahead, I dunno…)

I’m not trying to defend lax, or even negligent, bank security so much as I want to attack overzealous sunday morning security quarterbacking that just perpetuates the problem of a wildly swinging security pendulum that can’t find any peaceful middle ground.

(Don’t get too upset if you don’t agree with something I say here; I likely won’t get too deeply into the discussion. There is far too high a chance that most discussions consist only of straw man arguments, or even trying to be too general without admitting to exceptions…read the many comments about this case and you’ll see them rife with logical fallacies. Wait, are mainsteam comments anything but? heh!)

The case against Terry Childs has come to an initial close as he has, predictably, been found guilty. I expect that, while guilty, there is still the chance of other grievances that Childs can raise against the city of San Francisco and his superiors and how all of this was handled. At least, I kinda hope so because my continued impression is that Childs is as much a victim as he was the problem, i.e. the victim of absolutely horrible management, both from a technical and a non-technical aspect.

Chief Security Monkey has a nice article with some comments reposted on his blog, which I suggest reading through. Update: This is a great ComputerWorld interview with one of the jurors.

I have a pending comment on that site, but wanted to just record some of my own thoughts here.

Management is fully to blame for this situation, both for horrible policies and for probably conditioning Childs in a way that made this escalation inevitable. These are people who should be banned from ever managing other people ever again. Or even manage anything technical. They obviously don’t get it. It saddens me that while Childs broke the law, these managers won’t get similarly tried and branded.

Childs is, of course, also to blame. He should have just walked away. Or he should have given up the access and taken the blow from management (which likely would have resulted in firing). But I can’t necessarily blame him for leaning into the wind stubbornly. That’s just how some people are. But yes, strictly speaking, he broke a section of penal code, hence I’m not surprised nor much saddened that he was found guilty of that part.

I expect Childs and this whole situation was the product of a very stubborn-to-a-fault (righteous?) admin, failure management, and psychological conditioning.

Yes, that conditioning part is the one where I take a leap of faith, but I expect my leap is not all that large. If, in the past, Childs was either harmed or even blamed for lapses in his network due to someone else’s changes, then I am not at all surprised that this escalated into him refusing to let anyone else into the network. Did he have anything to hide? Doesn’t look like it. Was he trying to hold the city hostage? I didn’t get that impression. Was he trying to make sure it kept running so he wouldn’t get in trouble when some moron took it down and blamed him? Probably. If I held you ultimately responsible that my coffee cup is not spilled over, you’ll probably try to keep everyone away from it to prevent the spilling, especially so if someone spilled it a few days ago when you weren’t looking and I blamed you for it.

But, in the end, while I see lots of idealistic responses and comments about this situation, I think it is far, far, far easier to talk about excrow and continuity than it is to actually walk that walk, both from an administrative but also a managerial perspective. It takes work, knowledge, politicking, and proper people management to even begin to start. And I think far too many people who make comments to that nature, don’t follow their own ideas in practice, both from a godlike administrative access but also for smaller things like inconsequential accounts, processes, systems, programs, scripts, and so on. It is the nature of things that when someone leaves, there is a gap and loss of some information…no amount of planning will truly overcome that with regards to highly skilled or specialized job roles.

But that’s me, and I’m a cynic. 🙂

Episode 10 of the Southern Fried Security podcast is available and it includes a great discussion with DarkOperator about getting started and getting involved in security. Skip ahead to 13:30 for the start of that discussion. In short, get involved in a positive manner, and if you’re already in security or have some knowledge, contribute and pass it on! Check the podcast out for all the discussion points.

The case against Terry Childs, former San Francisco network admin, is hopefully coming to a close soon, and I’m anxious to hear what the jury decides.

I fall on the side of those people who don’t dismiss this case with a hand wave; I think it makes an important statement about management, policies, security, and IT operations.

I’ve been in similar, but far, far smaller, situations where I had to expand access or duties beyond myself to other people. And there are very real times where doing that leads to a degredation in the quality of the work, even up to someone being dumb and bringing down a network or device! I understand his position, even if I wouldn’t have defended it to quite such a degree!

I’ve also seen extremely protective admins whose strangle-hold on their operations starts introducing new avenues of risk, especially in terms of business continuity.

Of course, going too far in the other direction where things are spread out amongst so many other people adds in yet different risks in, well, too many people with God knowledge… Work long enough in IT, and everyone at some point experiences that non-technical manager doing idiotic things just because he has the access…which only conditions the behavior Childs exhibited!

Ugh. You know, sometimes in security there are heavy issues you just don’t want to have in front of your face, but then you walk away and come back and see them again, and it instantly brings the pot back to a boil (not an angry boil, just a boil).

That is how I feel when I write and erase and rewrite about articles about Cormac Herley’s [pdf] paper last year. I walked away to lunch, decided not to post, and started closing my windows until I got back to the originator for today: the Boston Globe with this tagline: “You were right: It’s a waste of your time. A study says much computer security advice is not worth following.”. (via Liquidmatrix) Yeah, I knew the moment I saw this paper, that it would make misguided headlines just like this (to its credit, the headline is the worst part, and likely not even written by the author but rather an editor).

It is not so much the article as it is the 120+ comments atttached to it, which lend importance to the topic…most of whom have no idea about the costs involved in building an infrastructure correct the first time versus how pretty much all of them are built today: grown. Over time. Over years. A one-off app written 4 years ago suddenly gets a few late features added which makes it mission critical for 75% of your staff…and so on.

I agree with what Chandler Howell (NewSchoolSecurity) said; actually two things he said. First, the paper seems incomplete, or at least basically tries to monetize the bitching of users, but doesn’t seem to have any idea what to do about it (like so, so, so many other rantsattempts…we get the fact that security has an inverse relationship to convenience…duh!). Second, at the end he mentions making security as transparent to the user as possible. Yes.

Of course, that means tipping the scale between user education vs technological (in this case, what I read as transparent) controls closer to the technological controls side. Larry Pesce also opined (Fudsec) about this in regards to the futility of user education. Perhaps user education does still have a point. The paper makes an attempt to demonstrate that user “stupidity” is a rational behavior. But would user education actually demonstrate why that rational behavior is in fact wrong? (“Rational” is being used in the “justified” sense.) Is it rational for users to open email messages, or should that actually *not* be the rational action when the user knows and accepts that someone from Nigeria probably wouldn’t be emailing them?

Nonetheless, read the comments on the Boston Globe article for the “user” viewpoint. Read the comments on the other articles I posted for security professional opinions. Yes, something is wrong, but I think much of it still has to do with: people making mistakes; economics (which has various influences here!); cost (again, various angles); and how IT does business fundamentally. (Mycurial had a great comment on the Fudsec article) Really, unless security has true demonstratable value to your organization, it *has* to be lagging behind attackers, technology, implementations, and IT in general. (I know, that’s an arguable point!)

Anyway, this is me sharing my growling. 🙂 …and adding another rant! I can rant about people ranting who don’t have any solutions, but I’m answering back with more ranting with no solutions as well. I guess the most I can hope for is some cathartic release!

DarkReading throws out, Organizations Rarely Report Breaches to Law Enforcement. This is a, “Duh,” moment, but I do like reading the reasons given in the article.

Taking this further, I think data breach disclosure is still a lot like the age-old iceberg analogy. Even despite actual laws requiring it, I would bet all the data breaches we hear about are just the visible top of the iceberg. And there are a whole host of other breaches (both known as well as undiscovered ones) that lurk in a huge steaming pile under our field of view.

I firmly believe that many businesses (if not all of them!) have a first reaction to ask, “Is this public yet? How likely is this to be public?” And then to kneejerk on the side of saying nothing and keeping things hush-hush. Of course, until someone finds out, most likely through third-party fraud detection analysis or the finding of files obviously stolen from that organization. I would actually expect (whether I like it or not) that all companies will stay mum when not given extremely huge incentives to disclose (jail time, extreme fines, jeopardizing of business).

Hell, I would even expect this occurs not just in disclosure to the public or to law enforcement, but internal disclosure as well! Tech finds evidence of attackers, tells manager. And somewhere along the chain up, the message gets quelched for fear of one’s job or a naive misunderstanding of the importance of some incidents.

I wonder how many cases Verizon worked on in their DBIR that should be disclosed, but the host company has opted to stay quiet on….or other security firms. Again, I’d bet it’s a decent number. (Note that I’m not trying to criticize Verizon or security firms who are likely under NDA and certainly have given their strong advice, but rather on organizations making the ultimate decisions about security and disclosure. Props to any sec firm that still makes an effort to distribute as much info as they can [formal or informal] to help the rest of us!)

Just a few days ago I read about and mentioned a recent New Jersey ruling about client-attorney communications and storage in temporary files on a computer.

I failed to delve into the idea that possibly, quite possibly, other controls in an organization may be affected, namely traffic captures and web filtering tools, especially if SSL termination is provided with the latter.