Common security analogy: “When you’re chased by a bear, you just have to run faster than the guy next to you!”

I continue to hear this analogy, and like pretty much any analogy it has holes if you look too closely. So the contrarian in me gets restless when I hear it (or insinuations of it) a few too many times. Lord knows I’m sympathetic to analogies and try not to get too far beyond the spirit of their point, but the over-used ones lose that privilege eventually!

1. Assumption: the bear is rational. I’ll run (pun unintended) with this further…

2. Assumption: the bear will survey all of his possible targets and choose the one most accessible. The bear may not know all of the possible targets, or not even bother trying to make himself aware of all the possible targets.

3. The bear may not properly evaluate the targets he does see.

4. Again defying rationality, the bear may just go after whomever for strange reasons. Maybe the last target he ate that was wearing a blue vest tasted good.

5. Assumption: the bear will stop after he takes yoru buddy down. If a blanket, automated malware campaign is released, it will probably not stop at one success, but rather keep going to get as many as possible.

6. Assumption: there is only one bear. I’m pretty sure there are more attackers than just one mean ol’ bear.

7. Assumption: that you even realize there is a bear about. Let alone where he’s coming from, how fast to run, how the bear will respond, or whether the bear learned how to shoot a crossbow. (Yes, a crossbow.) The game may not be about outrunning the threat.

8. What about the bears of opportunity? Not every bear is a threat, but if you get complacent because the last 10 bears just ambled on by with barely a sniff, doesn’t mean the next one won’t take a swipe as he lumbers near. Can you tell a bear from a boar in the dark as it shuffles around? Or do you just run from everything that may be a threat…including your customers?

Blah, blah, blah. I had to get that off my chest a bit. Maybe this is a better picture. You’re in the woods. You and some buddies and about 500 other people. There are lots of animals and it is dark, the foliage is thick, noise is everywhere. There are also 100 bears. Some of these bears are large and obvious, but others kinda look a lot like your buddies or other people. Strange, I know! But the point is really that you can’t plan your security around simply being better than the others in your industry. In fact, others in your industry, strictly speaking, shouldn’t even be an influence (in reality, they are, but that is just good strategic management-thought).

A few thoughts on a movie I watched this weekend that I’d never heard of before: Foolproof. Kudos to either the technical advisor or writer/director of this film for their research.*

1. Good lord, lockpicking done right?! Multiple times?! Indeed, not only do we see one of the protagonists pick several locks using *gasp* both a tension wrench and pick, but in at least one of those attempts it isn’t *double gasp* immediate! They even mention how it is taking him over 4 minutes to pick. I about fell over during that scene.

2. The protagonists are essentially doing red team activities, with an emphasis on physical attacks. To me, this sounds like a very healthy endeavor, even though they’re targeting companies they’re not affiliated with. One thing I liked, especially in their plans, is the lack of hollywood dramatic license. Or rather, diminished use of it. I appreciate that…unlike the nonsense dialogue of Swordfish or stylized file browsing of Hackers. This is more like Sneakers only without the sci-fi-esque prize (encryption decoder box).

I had more things to say last night, but I’m in a hurry this morning, so suffice to say I enjoyed the movie quite a bit, even though I see it was a terrible financial failure back in 2003. Give it a try!

* Minus one scene with the ever-present sharpening of a grainy image to read text on it. They came ever so close to pulling this off appropriately! They even had the dialogue correct and even sort of cut away from the usual telltale problem most films fall into, but you can still tell the print-out of the image is far clearer than it should be from a grainy security camera, even with some diddling to tease out some contrast to read text.

NetworldWorld has a fun article up about sysadmins and the Insider Threat! (Here if print link doesn’t work to save you 4 page-clicks.) This is a decent article if you give it a chance through 4 pages, and overlook the fact that it hyper-skims over enough topics to fill a book.

“It doesn’t mean they’re guilty of anything,” Theis adds. “Sometimes they’re just trying to get the job done, but they’re outside the bounds of the organizational policy.”

Sometimes IT workers are pushed by demanding users, such as business and sales managers, to perform tasks in a hurry or to violate official IT policy by, for instance, adding printers on network segments where that’s not allowed.

Many suggestions in the article are correct suggestions, but are appropriate really for larger enterprises, and completely ignore the SMB. To its credit, the article does briefly cover some of what I consider the bedrock approaches to the topic of privileged IT insider threats.

1. Hiring practices. You’re hiring someone who may have access to your entire asset line and data. You better have decent hiring practices in place for background checks, credit checks, proper valuation, and so on. In the SMB, your admins are pretty much gods, even if you don’t want them to be.

2. Management directly. No amount of automation will remove the need for proper, close management of privileged users to determine if they are disgruntled, have pressures going on in their lives, and so on. The warning signs are almost always there.

3. Management protection. Many (all?) times IT staff are just trying to solve a problem. The management needs to be outwordly present to protect their staff from bending to those pressures. Don’t leave your employees to handle the brunt of pissed users who then return back poor customer service reports which influences staff to be more lenient to get better reviews. That’s a downward spiral that will erode security.

4. High-Level policy. There must be policies in place on what the company and management expects for architecture, security stance, behavior, and so on.

5. Standards/procedures. This is a tough one, but there should always be procedures for admins to follow to accomplish common tasks, and guidelines (along with aforementioned policies) when solving new problems. One person should not solve a recurring task in their own way which may erode security. This happens way too often. Collaboration amongst peers helps as well. In the SMB, don’t undervalue consistent verbal standards/policies. (I know, some people will argue and say policies need to be written [*slammed fist*], but I believe the verbal side has realistic weight.)

6. Peer management. No one likes a snitch, but employees are very good at sensing changes and ethics in their peers. If someone is going through a hard time, or suddenly is acting suspicious, or you get an untrustworthy vibe, handling these sorts of things should be encouraged, either through a manager or through interaction. I wonder how many “disgruntled” employees could have been helped through better relationships in the workplace.

7. Awareness of options. This article presents a nice array of options on this topic, but most of them really require additional staff and tools to accomplish, beyond the reach of many SMBs. But it is still nice to know what options are out there and evaluate if something may be appropriate.

8. Audit access. This can either be simple or enterprise-worthy, so I won’t go deep into it. But have some approach for auditing access and who has the ability to use shared accounts, and so on. This can be some quarterly manual review, a brainstorming verbal session, or something vastly larger. The point is not to be surprised by who has access to what.

Got linked to this via the Infosecnews mailing list.

I just today mentioned an article between Ranum and Schneier titled, “Should enterprises give in to consumerization at the expense of security?” I imagine most security folks can feel this question every week, if not more so. I had a taste already on a Monday.

Clickability is a service that allows you to email links to people. Some sites such as The Wall Street Journal legitimately partner with Clickability to provide the limited ability to share articles with people who aren’t normally allowed beyond their pay-wall. Nothing too bad, yeah? But if you go to the links that Clickability advertises about itself, you find that anyone can add a javascript bookmark and email, essentially, anything they want to anyone they want…and pose as anyone they want. Rut roh… In my organization, we use IronPort web filters, and IronPort blocks Clickability features due to their categorization as “Web-based Email.”

This is one of those grey area cases. What advice do you give?

On one hand, I can basically email anyone anything and pose as anyone. This may mean the ability to exfiltrate information via port 80 (without normal logging like outbound smtp). It might mean being able to harass an ex anonymously. Or harass someone at work! And while some may argue you need to dig a little to utilize such functionality, I would say not really. The links in Clickability advertise the ease of use, and even the barest minimum use-case demonstrates the spoofability. And while most people won’t be going out of their way in their daily lives to figure out how to spoof emails, if you put it in front of their noses, they’ll turn into criminals-of-opportunity; even if it just starts out as a practical joke to your cubemate.

In addition, an expert appliance, the IronPort web filter, is saying this site breaks policy. Should an SMB take it upon itself to make exceptions and start down that slippery road? One could argue that a major portion of the value in appliance-based web filters is not having to sift through and block sites on your own, but rather inherit what the experts say.

On the other hand, this is a borderline case for “Web-based email” in that it does not allow two-way communication. You can fire off emails, but you can’t get any in return. Likewise, you can’t send attachments.

In addition, the person making this request is a salesperson. With a laptop. And readily available access to networks not subjected to our web filtered VPN connection. So why even bother to control this? Similarly, we’re looking at expanding our mobile presence, which will further the inability to truly keep our arms around the data (assuming we’re still legitimately *in* that battle yet!).

These are big questions, and completely depends on corporate culture. Unfortunately, those with open cultures will always slowly pressure and erode those with tighter cultures. The whole “grass is greener” or “But Bob at the Club told me they decided to allow it, so we can, too!” mentality.

Often the best we (SMBs) can do is educate management as much as possible, but then roll with whatever decision is made. In the absence of regulation, I’m pretty sure there is no right or wrong answer. We could clamp down and say no, or we could stay aligned with consumerland technology.

(My advice is pretty much the above; but I would lean just slightly on the side of trusting the appliance categorizations, and as such keep the site banned. But if someone else overrules me, I won’t be kept up late at night. There are good reasons to roll with the winds of technology, many of which go beyond security.)

Post and code up on Attack Vector: Geolocation Using BSSID. Matt finally brings this home at the end with the key question: How do you get someone’s BSSID? And that’s really the key, right? Well, if Javascript can leak that information over the Internet, you have an interesting way to track people down.

I hate how movies geolocate someone using their IP address (if we’re lucky, they even get *that* technical) within seconds. Now this might be a bit more realistic (with some room for error due to proximity or overlapping BSSID names) for people on wireless and leaky equipment. Very interesting!

I guess I told my team about this, but neglected to put anything here! A few days ago Microsoft issued an advisory about a “Vulnerability in ASP.NET Could Allow Information Disclosure”. There are really two aspects of this vuln that require attention: being able to read viewstate data and being able to pull files/info out of the server, such as the web.config contents.

A video of POET (Padding Oracle Exploit Tool) demonstrating the attack is available, along with more info at Netifera. If you’re looking for even more detailed analysis on the crypto attack, check out Gotham’s excellent blog post along with their own tool, PadBuster.

ScottGu has a great blog post with more details and workarounds, along with an FAQ post, and there is a special forum carved out for discussion on this issue.

Is this a Big Deal? Reasonably so, I think it is, especially as a gateway into further application attacks that lead into system access, as the earlier video demonstrates. An attacker could sniff client traffic, grab viewstate, and attack it to possibly retrieve that client information. But why bother with that? The important part is an attacker can generate his own viewstate and directly attack the application and even the server on his own.

The attack is noisy. The attacker will generate a large number of exceptions in the logs, but unless there are specific alerts for such jumps in numbers or an analyst is watching logs in realtime (yeah, right), the attack can be quick enough that detection won’t catch it before damage is done.

A couple Friday quick-rants. These didn’t happen today, just in general!

Please don’t wait until 4:30pm on a Friday to make a non-trivial need-it-now request for something you’ve known about for more than a day. Don’t make me go crazy for your lack of planning.

And if that request is something that regularly happens and usually doesn’t involve me, please don’t tell me you don’t know any details. If it is that important to you and happens regularly, please educate yourself on the things that your job’s success depends upon. (Or, from my role, don’t hoard the details; freely share them. Even if they don’t make sense, they may help a future request succeed.)

Insecure Magazine issue 27 is available [pdf].

This is a shorter issue, and I honestly didn’t really take much away from it, but I did enjoy the article Payment Card Security: Risk and Control Assessments (pg 44). Specifically, I liked reading about FMEA (Failure Mode and Effects Analysis) and basically the rest of the article after that.

FMEA isn’t necessarily groundbreaking (you’re still pulling numbers out of the air), but I’d never heard of it before and I liked seeing a quick summary of bullet items to fill in for it.

The Preventative/Detective controls and Guidelines for Risk Mitigation mentioned later are collectively just a way to summarize PCI DSS requirements, but is worded much better.