innismir.net

So, a quick post about two things:

1st, I did a presentation to the Boston Chapter of the Association of Government Accountants for their monthly meeting as part of my day job. I’d like to think I did fairly well and there certainly was a fair amount of discussion afterward. In case any of them find their way here in an attempt to find my slide decks, I am happy to oblige:

• Information Security and You PPT (1.4MB)
• Information Security and You PDF (1.8MB)

2nd, I have been selected to speak at QuaghogCon in Providence, RI the weekend of April 24th and 25th. I’ll be departing from my usual “Information Security” speaking groove and instead will be evangelizing Amateur Radio. Sadly, this means I’ll be missing out on B-Sides Boston, but that’s the way the cookie crumbles. Registration is open now and I’ve heard rumors that attendance will be capped at 150, so even if you don’t want to hear me speak, buy a ticket; there are going to be some awesome presentations.

The episode of PaulDotCom I made an appearance on has been posted:

• Part 1
• Part 2

Hear me discuss cigars, G. Schneider & Sohn beer, and decoding digital signals.

I’ll be appearing tonight on PaulDotCom Security Weekly on Episode 179 tonight around 8:30PM helping Larry discuss the legal ramifications and technical aspects of decoding pager traffic and plugging amateur radio.

When the stream goes live you can check out

• PaulDotCom Live Video Stream
• PaulDotCom Live Radio Stream

If you’re interested in making fun of me while I am live on the air feel free to join the PaulDotCom IRC channel during the stream. Point your client to irc.freenode.net #pauldotcom.

Haven’t been on the train lately so this is a bit old, but Chris Gates (@carnal0wnage) and Richard Bejtlich (@TaoSecurity) started an interesting discussion in the comments section of one of Richard’s postings regarding who is to blame when a security incident occurs. Richard was talking about SHODAN, the new AI being deployed to the  TriOptimum Corporation’s new Citadel space station… er… No… Wait.. Wrong SHODAN… The spiffy little searchable database that was recently put up containing portscans and banners of various computers across the Internet. While discussing the morality of such a database, Chris made an interesting statement:

again we take the responsibility of securing devices and systems away from responsible party (the admins and owners) and blame the bad guys with the “think of the children” argument.

why dont we start blaming the jackasses for allowing theirselves to be hacked and not the bad guys who do it. can you really blame the guy that steals the “whatever” out of the unlocked car? really?

This easily carries over into the cyber war arena. lets stop pointing our fingers at the guys breaking in and instead point our fingers at the organization who allowed it to happen.

Wow. I understand where Chris is coming from. When an breach occurs, it’s often followed up by incident handlers like Chris or myself looking at the server and muttering “What in God’s name were they thinking?” As someone who, for the increasingly-rare insightful commentary, still listens to Off The Hook on my iPod every week, I hear statements similar to Chris’ a lot. Every time some company gets attacked and releases a statement “Teh H@x0rz did it!” they rail on the company and blame them for having insecure computers in the first place.

It doesn’t matter if the admin decided to toss Windows 2000 without any service packs on the Internet. Yes, he or she was stupid, probably violated about twenty different policies, and should be given fifty lashings with a wet noodle. There would not have been an issue if the silly script kiddie from Eastern Estonia didn’t compromise the box.

Another interesting thing about the “Blame the Admins!” advocates were that they seemed to be guilty of the same things that the Admins were. They were blaming someone else. Admins were blaming the attacker while the security guy blames the admin. When someone gets compromised at my job, I’ve failed as the security person. It’s partially my fault.

• Why didn’t I notice traffic going to computer?
• How did I not notice when that computer went online?
• What didn’t I do to make sure that computer wasn’t part of the patch cycle/AV/IPS/IDS etc?

We can make excuses all day, blame the admins, blame our tools, blame the lack of support from business owners, the issue is that are we men, or women, enough to say that the buck stops with us and we missed something along the way. Do we fall back into our regular routine after the crisis passes or do we try to take steps to ensure that we aren’t caught with our pants down again?

While I am not saying the admins or the maintainers of the data are completely blameless during an incident, I think Chris’s and OTH’s statements reveal a very scary shift in thinking regarding InfoSec. We are essentially saying that we’ve lost not only the battle, but the war, and we are being overrun. We’re admitting that we can no longer protect endpoints and that it’s a crap shoot if you go out onto the network. But don’t blame us if you get compromised, it’s your own damn fault.

I was very lucky this summer because the Security Office got some funding for training and footed the bill for another SANS course. I opted to go for SANS SEC504: Hacker Techniques, Exploits & Incident Handling. I did a “At Home” course this time, which met three times a week online and was taught Ed Skoudis and John Strand. While I did like the self paced learning that I had for SEC503, but it was very cool to be taught by the folks that you always heard on and about PSW. Plus, I was able to make snide remarks in the chat window.

As much as I still wonder about certifications in general, I am starting to really like SANS courses. The course wasted little time on the basics and quickly had us rolling up our sleeves mucking about in what I classify as “cool sh*t”. While I did have stretches where I was just nodding and going “yeah… yeah… know that… uh-huh…” I would occasionally see or hear something, go “Oooh!”, and make write down some notes. The course consisted of 5 books of material, ranging from incident planning and handling to how to exploit systems, and then culminated in a capture the flag contest. I am ashamed to say the CTF was designed well enough that I could barely establish a toehold on the first server, I guess my days of staying up for an entire weekend and dominating the CTF at Northeastern is far behind me.

Although the course itself wrapped up sometime in the summer, I finally took my certification test today and passed with flying colors. I am happy to report that I have even more alphabet soup after my name and I am now “Ben Jackson, GCIA, GCIH”

OK, this floated across Twitter over the weekend:

With the annual cost of ATM crime in Europe approaching half a billion Euros, ENISA, the European Network and Information Security Agency, is urging consumers to be more aware of the risks and take precautions to avoid personal loss. The rapid growth in the number of ATMs, combined with more sophisticated attacks and fraud has resulted in an alarming 149% rise in ATM attacks in 2008.

For those of you who don’t know what ENISA is, they’re kind of the EU equivalent to US CERT. While I think that the “Golden Rules” are mostly fluff, I’ve always felt that Europe is more of the FEBA of ATM based attacks. This is a good start at trying to address issues with ATMs and I applaud it. However, with more and more sophisticated attacks coming out against ATMs, is ENISA trying  formulate battle plans against horse cavalry when the bad guys are deploying armored tanks? Could the effort of creating these be better used to start pushing banks to start reevaluating ATM security? ENISA seems to be aiming for “low hanging fruit” in this case, however,  this strategy could backfire. It’s possible that they’re setting themselves up for failure if these malware based attacks start to prevalent. If people, by some strange miracle, start taking these recommendations to heart, follow them, and still get owned, ENISA is going to have a tough time explaining themselves.

There are a lot of issues with it, but I’ll be the first to say that the perfect is the enemy of the good. This is a step in the right direction. I would love to see this start being pushed in the United States. ATM skimming scams are starting to become increasingly common across various regions in the United States. Various European gangs are starting to export attacks, sending them to other countries to steal data, so this is rapidly becoming a global problem. Ideally, in the United States at least, it would be great if some of the big banks started pushing PSAs to their customers regarding skimming and shoulder surfing. This could be sticky as I think we’d see “third party” ATM vendors scream bloody murder if the big banks say “Look out for sketchy ATMs!” I also know for a fact that Bank Of America has “free standing” ATMs (like the one at the MA-24/I-495 rest stop, complete with a Cisco router visible inside the machine, *shudder*) in some spots and I doubt they would want to drive people away from them. But still, could you picture a bank embracing ATM security? I’d certainly consider moving my business to them. The more evil side of me would love to see technology advocacy groups start pushing this as well. It be interesting to start seeing stickers on ATM proclaiming them possibly unsafe to use similar to the circa-2005 “This phone is tapped” stickers that were placed on pay phones across the US. I am sure that the banking industry would be in a tizzy if these started showing up on numerous ATMs overnight.

So, this has become a bit of a rambling post with no clear point to tie it all together. So, I’ll guess I’ll just give kudos to ENISA and tell everyone to read the Golden Rules and follow them. You’ll be glad you did.

Farhad Manjoo over at Slate recently did his best Moses imitation and cried out “Let My Office PC Go!” and railed against restrictive IT policies in the Office environment. While I understand his pain, it illustrates the disconnect between users, IT, and Information Security.

You ask your IT manager to let you use something that seems pretty safe and run-of-the-mill, and you’re given an outlandish stock answer about administrative costs and unseen dangers lurking on the Web. Like TSA guards at the airport, workplace IT wardens are rarely amenable to rational argument. That’s because, in theory, their mission seems reasonable. Computers, like airplanes, can be dangerous things—they can breed viruses and other malware, they can consume enormous resources meant for other tasks, and they’re portals to great expanses of procrastination. So why not lock down workplace computers?

Here’s why: The restrictions infantilize workers—they foster resentment, reduce morale, lock people into inefficient routines, and, worst of all, they kill our incentives to work productively. In the information age, most companies’ success depends entirely on the creativity and drive of their workers. IT restrictions are corrosive to that creativity—they keep everyone under the thumb of people who have no idea which tools we need to do our jobs but who are charged with deciding anyway.

Productivity and Morale are two very important things and I understand where Farhad is coming from. I agree that draconian restrictions can kill productivity. In my career (2001-ish) upper management decided to install web monitoring software at my place of work unannounced and came down hard on people who spent “too much” time on the web (including yours truly). It didn’t matter that my work was getting done, or I got glowing reviews from the users I supported, or that I spent my time on technology sites,  I was spending “too much” time on the web. The “solution” to this was to have me sit there and stare at my e-mail folder waiting for a support ticket. Loads of fun.

While Farhad does a great job illustrating that productivity can go up when users are given more control over their desktops, he inadvertently provides and example of exactly why users shouldn’t be given free reign over their desktops:

When I worked in an office not long ago, though, a new man in IT decided that forwarding company mail to my Gmail account might violate the Sarbanes-Oxley Act. I tried to explain that was ridiculous—Sarbanes-Oxley proscribes deleting mail, which I wasn’t doing, and, anyway, the IT department had no problem forwarding mail to people’s BlackBerries and iPhones.

Uhhh… Hey what now? While the only SOX I know in detail are the red ones, this, as a “security guy” makes me cringe. SOX aside, this is very much a BadThing™, and while yes, this might make it incredibly easy to access your work e-mail from home and give you all kind of options that your work e-mail environment may not provide it’s a bad move from a security viewpoint. How is it bad? This can be illustrated by the massive Twitter document leak this past July. A combination of bad passwords and Google Apps absolutely reamed Twitter. By putting your e-mail to a non company controlled system you are bypassing any kind of security that your company provides. Internally your IT department may have firewalls, anti-virus, intrusion detection systems, strong password policies, etc. Google, Hotmail, Yahoo, etc provides none of this for your account. If your IT department is smart, they’ll notice your account being accessed by someone who shouldn’t have access to it, while if you use GMail, how do you know that your account isn’t compromised? More importantly, how can you prove it isn’t?

As a side note, Blackberrys and iPhones are their own beast within themselves. Thankfully, RIM and Apple as of the iPhone 3GS provide pretty good restrictions on enforcing secure usage. For example: we can require you to enter a complex password if you haven’t used your device for 15 minutes. This provides us with a reasonable assurance that if you leave your device in the back of a Taxi while you’re sloshed on a Friday night, it limits the exposure of the information it contains to 15 minutes. While it’s not perfect, it does give us a bit of breathing room. If you set up some kind of Rube Goldberg system where your device checks into GMail which you sync your device to, you’re torpedoing this.

Farhad compares IT workers to the TSA, and while I’m not going to suggest that all IT workers are helpful and flowery, I can make the counter point that many times a “rational argument” boils down to “I want to use this because I want to use it” rather then providing justification. More often then not when someone “wants something” for their PC, they can rarely provide reasoning equating to “Look! Shiny!” and when pressed to answer some fairly basic questions on why they need it, it suddenly becomes the IT department standing in the way of progress. That’s not to say that there are cases when users provide an actual business justification on why they need a product and said business justification has outweighed the risk, it’s just that it seems to be the exception rather then the rule.

I’m not saying that IT needs to lock down PCs into some kind of 1984-esque environment (Although, quite frankly, it would make my job a hell of a lot easier), nor am I agreeing that everything would be sunshine and puppies if we allowed users to completely control their PCs. What I’m saying is that both IT and users need to meet each other halfway on this issue; while IT needs to understand that certain products and websites can help users do their jobs better, users need to understand that certain products are not allowed for a reason.

The entire discussion really can be reduced to a single question. IT departments face this question regularly and if we follow Farhad’s advice I think it should be passed on to the user.

As a user, are you ready to accept personal responsibility if something you want affects the security of the network?

Keep that in mind the next time you want to use Facebook at work.

While going through my backlog of RSS entries that have piled up over the past week, I came across this story from Byron Achohido (via Threatpost, which I highly recommend) who talks about the moral ambiguity of the release of tools that can allow rainbow tables made for cracking the A5/1 GSM encryption cipher. First, let’s get this out of the way: Attacks like this against A5/1 have been around sine at least October 2007. The big deal with these new tools is that they provide the basis of taking the computation time down from days or hours to seconds. These tools are rainbow table generators. They do not do any kind of sniffing or cracking, just a boat load of computations.

This aside, I find the story interesting for a number of reasons: First I like how the iPhone is specifically mentioned. Byron mentions that:

Hackers could go after sensitive information exchanged while using Web apps for phone banking and stock trading; or they could eavesdrop on sensitive conversations, discussion about medical histories, for instance.

Actually, in cases where you are on a 3G network, you’re safe from this attack on the data side, as 3G networks use the A5/3 cipher. The problem is that, at least in AT&Ts case, even if you are on a 3G network, any voice calls are routed over regular GSM channels, which use the faulty A5/1 cipher. I believe T-Mobile is in the same boat. Fixing this is rather simple from a technical standpoint, just flip the voice side over to 3G as well. Of course, we know that in real life it’s almost never that simple. Both carriers’ 3G network is nowhere near the size of their GSM networks, and who knows what kind of capacity they have on the 3G side. However, the decision here is completely on the carrier: What do they value more, their customers security and privacy or their profit margin?

Plus, I think the larger question here is when did mobile phones become secure? I think any person with a background in Information Security or Radio that was around in the early 1990s either monitored cell phones or knew of someone that did. While with the introduction of digital phones the monitoring became more difficult by your simple geek, given a sizable sum of money, it is still possible. The creation of devices such as Cryptophone proves this. Even before these tools were released, there are attacks on GSM in the wild which are “active” attacks, such as spoofing cell towers and then telling the phone to go sans encryption.

Next, regarding the question of releasing these tools; Byron calls the release taking the “morally debatable high ground.” I think his logic is really flawed, and he shows why in his article:

As this timeline depicting the emergence of the Conficker worm shows, the bad guys pay big bucks to black hat researchers adept at finding vulnerabilities, which can be immediately exploited for profit — before anyone issues a patch.

And now grey hat researchers,  like Moore and Nohl,  build careers out of concocting campaigns to embarrass vendors under the banner of compelling vendors to resolve security flaws in popular products – usually highly profitable cash cows — in a timely manner.

It’s been shown that attackers pay large sums of money for attacks that aren’t patched, making a market for enterprising attackers with questionable morals to develop them. With the existence of this market, why are we assuming that the bad guys don’t have rainbow tables for A5/1 already computed and are actively recording calls from high value targets? Cons It’s silly. Releasing these tools essentially destroys the already tattered blanket of ignorance people have been wrapping themselves up in since people started shouting that A5/1 was insecure and once again shows us that mobile phones are, by their very definition, insecure devices.

This article just was posted to my Twitter stream (Hat Tip: Chris Boyd). Graham Cluely from Sophos calls for people to stop using the word “endpoint” and replace it with “computer” as it confuses users. On it’s face, it makes sense. My wife would have no idea what I was talking about if I started bandying about “endpoints” in conversation instead of “computers”. I also completely agree that the term “endpoint” is incredibly overused by marketing departments. However, if we start trying to fit our nomenclature into simpler terms rather then continue to use our existing ones, are we hurting ourselves in the long term?

Allow me to babble about my childhood. I have always had a deep love of radios. My dad would have the police scanner on almost every evening and one of the channels he had crystaled in was “North Shore CMED.” For the 99.9% of you who have no idea what CMED was, it allowed ambulances to brief hospitals about inbound patients being delivered to their ER. For those of you familar with the 1970s era TV Show Emergency, the radio traffic was similar to the calls between Squad 51 and Rampart. Now, what does this have to do with endpoints? Well, back when I first started listening, there would be patients that were involved in “car accidents”. Then, a few years later, “car accidents” started being replaced with “motor vehicle accident” or “MVA”, makes sense, right? Person could be in a truck, bus, dune buggy, etc. Now, apparently, the new term is no longer “MVA”, it is now a “MVC” or “Motor Vehicle Collision”, that makes sense too, right? Person could have decided to ram someone off the road or is suicidal. These terms do a better job of encompassing all possible scenarios, despite most people possibly not understanding the difference between a “car accident” and a “motor vehicle collision”.

This reasoning is exactly why we use the term endpoint. While the public might not understand the difference between a “computer” and an “endpoint” there are key differences between the two.  For example: I currently have five endpoints on my desk, but only two computers, the other three are an embedded device, an IP phone, and my mobile phone. While all are endpoints and you could make the case that all five are indeed “computers”, they do not fit what the general public thinks a computer is. When you’re talking about endpoint security, you need to keep in mind anything that is a destination for information is an endpoint and they all need to be protected. Yes, in 90% of the cases it is a computer, but this is rapidly changing. Language is a very powerful tool. By switching to “endpoints” instead of “computers” we as professionals are being more specific to whats affected. If we say that computers are affected by a certain issue, do we mean only computers? Or do we mean computers along with other devices? As a side benefit, it’s also the first step to start convincing people that they need to start looking at any kind of device needs to be secure.

While we’re not going to be changing any thinking overnight, nor are we going to enjoy answering the endless questions of “What’s an endpoint? Oh, you mean a computer…” its one of those painful things that we’re going to need to do. Keeping ourselves to old definitions keeps us from talking about evolving threats accurately and that’s just a bad idea.

Tuesday, work had some training for some $FAIRLY_EXPENSIVE_SECURITY_SOFTWARE. Training required us to install one of the desktop versions of their product (which was passed around on a USB stick. </facepalm>)  and required a license key. The trainer walked around to my laptop and set up a key. My paranoia is peaked when someone uses an computer with my account, so I watched him log in to the webpage with the key generator (OK, I averted my eyes when he typed his password, that’s a common courtesy), generate the key, made sure it worked, and moved on the the next laptop.

Did you notice the missing step? Allow me to show you what was still up on my screen behind the software (censored to protect the guilty):

Click for Larger

Click for Larger

License Keys anyone?

Being the upstanding citizen I am I took my screenshots and logged out. I could have, however, generated a nice stretch of license keys for the next few months for my own personal use. Considering the amount of money the software costs, these keys would would have saved me a pretty penny.

There were four mistakes here, all small, two of which could have been fixed in the design phase of the application, two of which were the trainer’s fault.

1. Trainer using a unknown laptop to log in to a secure site. Good thing I didn’t have a keylogger or something.
2. Application not having a some kind of system that would allow me to submit for my own key and have the trainer approve it.
3. Trainer not paying enough attention to log out.
4. Application not having some kind of oversight so that if I…. uhhh… I mean someone… did compromise the trainers account, I… er… he couldn’t create a bunch of keys.

I will give credit to them for some restrictions that kept this from being an epic fail:

1. 30 days was the longest period I could generate a key.
2. It would likely had my fingerprints all over it.
3. I believe the key could be revoked on their end.

That being said, it’s still an interesting example on how a series of small mistakes can cost an organization. Not that it did in this case, but how often do we hear about a bad system allowing a breach of sensitive data? A secure system requires both proper design and diligence of the users. In this case, unfortunately, they all clicked to allow the possibility of someone making off with the goods.