biggest lesson from rsa: security really is hard

Posted on by michael

The RSA breach details will spark discussion and armchair quarterbacking for years, that’s a given. But I can at least pile on a little bit more here and there, yeah? The SANS ISC weighed in on some of the RSA details, and I wanted to pull out small bits to tackle briefly. Here’s what I consider the prefacing assertion:

There are just too many ways to circumvent the perimeter, spear phishing being just one.

1. “The thing is I don’t think this new paradigm is so new. Many have been advocating for years moving the prevention and detection closer to the data.” – We wouldn’t be *quite* (important word!) as concerned about the circumvention of the perimeter if we didn’t have such awfully porous technologies sitting on the desktops. Yes, you, web browsers and attending tech (Flash), Adobe, and Office. You’ve all become too bloated to be secured anymore, and it’s your own damn fault. Just think if these were much better secured by default. We’d have less updates which should mean better ways to keep them updated on desktops, etc. (Some may argue that others will just take over the role, and perhaps that is the inevitable result…but you can’t ignore that these porous softwares are making things worse. The insecurity of the interior is making the security of the perimeter worse. If you improve the middle, the perimeter is better valued…from a certain perspective.)

2.”There are a lot of approaches that can be used here, but in my mind it begins with segregating servers from the desktop LAN and controlling access to these protected enclaves as thoroughly or better as we do our perimeters today.” – This is one area where the “cloud” is actually useful; it moves data away from these workstations…sort of. One could still argue that access is access, whether you have 3 firewalls or 0 between them. But any push to get users better segregated from servers when so many are in a shared network by default, is a good thing. If nothign else, this can push better documentation on data flow needs. This should also include better egress controls…yeah, I’m looking at you FTP-exflitration. (Of course, lock that down, and even more people/devs will just use 80/443 more…)

3. “It means classifying your data and installing protection and detection technologies appropriate to the sensitivity of the data.” – I imagine the most common way of classifying data in an SMB is saying it’s all secret. Classifying data is great and makes a lot of sense, until you get into the reality of *gasp* actually doing it. This is where the CISSP hits the road and suffers the knee and elbow scrapes.

4. “It means installing and tuning Data Loss Prevention (DLP) technologies to detect when your sensitive data is leaving your company.” – Just don’t fall into these three traps with DLP: First, don’t expect to plug it in, do a few hours of tuning, and then forget about it. It’ll need ongoing love. You will have false positives and small incidents constantly, or it’s not tight enough. Second, don’t think you can tackle DLP without first coming to terms with data calssification, or at least doing *something* to identify your data and flows. Third, don’t think that DLP will block/detect everything. Does it interrogate 443? Should it? And so on…

5. “It means instrumenting company LANs and WANs so a network baseline can be determined and deviations from this baseline be detected and investigated” – This is another idea I find compelling, but the cloud isn’t helping, nor are consumerland technologies that just spray garbage into your baselines and everyday traffic patterns. Still, if someone FTPs a large amount of data to an external source you’ve not seen before, you really want to know that happened. But again, this is just a part of a blended network security posture and not something to even do until you’ve a maturing security team/process.

The end result of all of this is: SECURITY IS HARD. And it’s only getting harder.

rsa comes out with more incident information, yay

Posted on by michael

Since I started the ball rolling, I guess I’ll continue logging references to the recent RSA hack. Finally, RSA has started talking about the actual incident progression itself in a blog post. This is a great thing! I tweeted my thoughts, but I’ll repost here for posterity.

1. Kudos for posting more information, and being detailed about it! I was a bit surprised, but I appreciate it.

2. Sadly, the blog post rambles. Remove the historical/contextual crap about APT. Remove the historical examples. Describe APT in another blog post, or in a separate section of the blog post. That way I can skip that useless crap and not feel like I need to skim it because what I want to read is interwoven with it.

3. There’s no reason, so far, to even include the term “APT” into this post. APT is a reference to the ATTACKER. If you’ve not identified the attacker, you can’t name them an APT. This would have simplified the entire blog post and focused it very nicely if no mention of APT had been made. There is plenty of time to do so if you need to, but later. Use attacker(s), hacker(s), cracker(s), whatever. It was just not useful to use APT right now, except to try and deflect any blame by tying it to some genius attacker(s) whom Google didn’t even stop, blah blah blah. Let the mass media do that, not you.

4. I loved the start with mentioning your own internal CIRT and detection. I know it’s a dig and sort of jerking yourself off to talk about your own products and response time when so many others don’t detect this shit at all, but IT’S FUCKING TRUE! So, props for starting the conversation moving forward, though I’d still love to hear more details on the detection. So far, for all we know, this runs into the category of, “user reported ‘weird’ system issues, desktop support checked on it and thought things looked weird, found Poison Ivy, queue CIRT.” That’s not the same as, CIRT notices FTP data egress, opens incident. One shows luck, the other security maturity. Still, great, great start to that discussion, and I hope to see more!

5. APT is not new. I really bristled in the few moments in the blog post where it was implied or outright stated that “APT” is new. APT is not new, in practice. Again, drop the APT crap for now. These attacks are not new. The existence of 0day is not new. SE is not new. Yes, they may be on the rise and increasing in use and exposure, but that’s not new. If you’re in security, you hate those moments in blog posts like this. It’s awkward, it makes you feel like the author is a newbie (or so far removed that this stuff *is* new to him), and it detracts from the usefulness. You’re not a special snowflake, but no one is saying your baby is ugly. Stop being defensive up front. That’s for PR drones and legal vultures.

Lots of people are whining and complaining and throwing stones at RSA, and I think justifiably so, but only on the basis that they’ve been unforthcoming with answering my basic two questions:

1. As a customer, tell me enough about how this impacts me so that I can manage my risk and talk intelligently to my boss. RSA is still failing at this, even in a twofold manner. By not telling me anything useful, they’re allowing rumors to run rampant, which are damaging to them and me.

2. As a security geek, tell me enough to understand the progression of the attack, how the attackers worked, moved around, eggressed data, and how they were found, handled, investigated. Both the good and the bad. Lessons, people!

For lots of other people who complain, I wonder if they’re just doing so to complain. Are there any conditions that would appease your complaints that RSA can meet? If not, then shut up and stop wasting your time and energy.

mobile device encryption article response

Posted on by michael

Today’s article rant comes from ComputerWorld’s article titled, “Failure to encrypt portable devices inexcusable, say analysts.” The quote from the article is actually, “‘”There really is no excuse for not encrypting laptops …'” In this world of smartphones and mobile devices, that’s a *huge* distinction, especially since you’re still being told, “good luck,” when it comes to smartphone encryption (Droid Pro being an exception).

Also, it’s annoying to make such blanket statements about inexcusable security measures. It’s inexcusable that orgs not do a risk analysis of their mobile devices and determine whether device encryption is going to be worth their time and money. It may not be.

But I do wonder if executives and managers are vastly naive about the sorts of data their employees are storing on laptops. Many such leaders have verbal expectations that sensitive data is protected and not placed on laptops and how their employees are smarter than that, and so on, but that’s getting back to management by belief, which is a gamble you will eventually lose.

Sometimes it makes me wonder. We trust employees to make proper choices, but then we want employees to be innovative and get their tasks done and be creative. Those values can be just as at odds with each other as security and usability.

didn’t perimeterless assume more secure endpoints?

Posted on by michael

I was reading a post from Dan Morrill about mobile security, and it got me thinking. The advancing of consumerland mobile devices putting pressure on corporate networks, most specifically the network perimeter and data diffusion…leads people to start calling for harder endpoints that are resistent to attack. This is long part of the ‘perimeter-less’ viewpoint. One might say to such groups, “Here we are, on the advent of your predictions. So have you solved this?”

But look at our mobile devices. They’re rooted. They’re gaining malware. They’re less known and less supportable by your techs. They’re not centrally managable, and they’re not secured physically. They store passwords, have incomplete security, are rushed to market, and have barely passable in-transit protections.*

In short, they just might be WORSE! Awesome. 🙂

Did you notice that two recent high-profile hacks have dealt with trusting in-transit encryption (Comodo) and [2-factor] auth often used for mobile access (RSA)? Both of these have implications for the current trending towards less perimeters and more mobility (and, grudgingly, “cloud”).

* The difference between a blog like mine and being a journalist is I can get away with making claims without days of research and backing citations. So, nyah!

comodo hacker info at erratasec

Posted on by michael

Robert Graham has a great series of posts concerning the recent Comodo SSL hack. Start with an intro to web certs, then “Comodo hacker” information, some interview pieces, and finally verifying his own private key. The hack itself illustrates the web of trust the Internet has placed us into (pun intended if you link that to SQLi attacks), specifically that someone else didn’t protect their trusted credentials very well which lead to trusted access into Comodo where other weaknesses were leveraged.

Try to not get too involved in the comments; there’s a wave of politicking in there…

Incidentally, he also has a fun terminology post about “cybersecurity” and “hackers.” I think I agree with his sentiments; I know and prefer to use the terms appropriately, but I also know how they are *really* used day-to-day outside our circles, and accept that.

apt: advanced persistent term

Posted on by michael

It’s been relatively easy to not get sick of the term APT since we have “cloud” being far more used, abused, and easy to hate. But I’m with Michael Starks over at Immutable Security, in being a little annoyed at the continued blaming of “APT” for any security issue. Saying something was caused or leveraged by APT isn’t actionable unless you define the actor(s) you’re using APT to refer to. Otherwise, this is dumb and has gotten out of control.

It’s true that almost everyone who makes a mistake blames something or someone else. That includes security incidents. “Well, gosh, that attacker was so sophisticated no one ever would have caught that!” is the undertone of almost every breach notice that tries to mention APT. Let alone any time an attack could possibly have been traced to some IP address in Asia or Eastern Europe. Hogwash.

Whenever I hear APT, I internally translate that to corporate and/or state espionage. To me, the “persistent” part of the term indentifies the threat as having a specific reason to continuously attack you, or at least a goal that until met will result in continuous attack. That’s a far cry from accidental breaches or crimes of opportunity because someone is dumb or naive. (Though I will grant that APT actors can utilize those holes as well.) This is also why I don’t consider APT new at all; we’ve had corporate/state espionage for ages. (Yes, *ages!*)

I’ve been silently predicting for many years the continued increase in corporate espionage diving further into the cyber world. We’re still only at the cusp, if you ask me. We’re talking tracking location of executives, cloning their devices from hotel rooms, befriending people in social networks in positions of influence (assets), outright stealing data from poorly guarded systems, and so on. Information is power, and the more you can get and then use it…even that naughty text pic from that executive’s phone to an “assistant” is useful.

Nonetheless, I’m likewise sick of the term APT.

hbgary lessons from a hack

Posted on by michael

Lessons learned are always good to pass on, whether by gleaning mistakes others make from disclosure details, or their own words after the fact. Greg Hoglund offered some in the shadow of the recent HBGary Federal incident.

I wouldn’t be entirely surprised if the entire hack really was simply a gleaned password that then lead to other accounts, either by account/passwd reuse or because an email account is the contact target for passwd resets or something. (Side note: downloading a firm’s entire email spool…yes, it’s *that* big of a deal to keep protected. Don’t forget about it in the chatter of CC, SSN, PII, Corp Secrets, bank accounts, corp secrets…)

But in world where everything is connected, everything is on the Internet all the time, and we demand mobile “stuff,” a stolen credential is the new hack, really. Ten years ago that might get you into a corporate web mail account or VPN connection if you were lucky, but otherwise you still needed to get past the corporate virtual walls. Today, no so much. These credentials are also increasingly easy to snarf, sniff, sidejack, and replay…

picked up from the infosecnews mailing list.

rsa breach disclosure illustrates need for more information

Posted on by michael

So far, word about the recent RSA hack illustrates just one really important problem with the current “disclosure” system: We (customers or experts or stakeholders) rarely get enough information to properly decide what happened, what the risk is, or how to really value the news. I don’t always necessarily need to know how an attack happened or what *all* was accessed, but I’d like to at least be able to do more than just wonder about the impact. Maybe it’s too soon, but anyone who knows anything about the news knows that the longer this goes on, the less it will ever get widely covered/disclosed as firms wait for the interest to die out…

diet pills, silver bullets, and the truth of hard work

Posted on by michael

I just wanted to repost a snippet from a recent post by John and Larry over at pauldotcom, “…Security is Hard,” (emphasis is mine):

“Moving forward we need to start looking at how we can baseline our networks, systems, and applications. Then we need to start watching for deviations from the norm. There is no shiny box or product that is going to “beat down” all malware and attacks for you. It is just like health. We all know what it takes to be healthy. It requires a good diet and exercise. But that is hard. We would much rather buy a pill, which never has worked. But, it looks easy, so we give it a try anyway. Maybe, just maybe this time it will work. It is the same with security. We know what we have to do: know your network, your systems, your applications, test, test and retest. Then, when you are done testing, do it some more then hire an organization to do a pentest for you that actually knows what they are doing. Then, start over again. “

The diet pill analogy is always an excellent one that I too often forget. We so often want the easy road in so many things, but sometimes you just have to plain put some effort into it. This is a great companion analogy to home security. Is there any one thing you can do that will solve home security? Nope. Ask anyone who has a nifty security system and still had an incident…

Someday I should make a page that goes over some useful infosec analogies…

risks with car drivers
diet pills
home security
healthy living/immune systems
insurance

I’m sure there’s also some useful ideas in sales/marketing for when an organization simply doesn’t want to face the music when it comes to security and security spend. How do you get someone to buy something you feel they need but they don’t feel they need, or feel like they need to put any time into? For most (including me) you’re really just left with FUD or an actual smell-the-coffee incident.

playing the game many moves ahead

Posted on by michael

Adrian Lane posted what is so far the best blog post of 2011 with, “The CIO Role and Security”. If you read the first 5 paragraphs and can’t find any way one of those situations applies to you, then I dare say you’re not working in security (and I might argue you’re not even working in IT!). I love the point that either you’re Getting Things Done for the company, or you’re going to be shown the door, security-be-damned.

I have “just” 4 thoughts to discuss/add.

First, if I were to formulate any one argument “against” this posture, sometimes those groups throwing out ideas/projects really don’t know security and they just don’t have the knowledge to put it in, and therefore they look to the security geek or CIO/CSO to inject their expert opinion. Of course, this is often done in a non-direct, smarmy-feeling way by looking like a deer-in-the-headlights when asked about security. It would be better to just flat out grow some balls and ask directly for help/guidance. Moving a step further, I’d then say Adrian addresses this in his 2nd bullet, but also the people brainstorming these ideas need to take the blinders off and think a little bit about the whole picture, or at least accept it when someone else does their thinking for them.

Second, Adrian’s post applies not just to the C-level role, but also mid-managers and even the techs in the trenches. *Especially* in the SMB world where quite often, it is low-level tech to low-level tech where projects get communicated. Where any sort of getting in the way of projects is a surefire way to start eliminating potential allies for your long-term advancement in that company. Adrian’s point about security adding complexity will always make me wince when I read it, like some mysterious childhood-borne tic/fear. My addition of complexity just might be compensation for your lack of foresight and critical thinking, eh? (Not an uncommon issue, as I will always draw the analogy of risk-based decisions by typical daily drivers on the road. The ability to think beyond 1 move or 5 seconds is rare…really, you nearly cut me off and bottom-out your front bumper to pull into that turn-off…when there is no one behind me and waiting 5 seconds would have been a tense-free situation? Fuck you.)

Third, this is one of the biggest things I like about compliance regulations like PCI. It gives otherwise powerless/underappreciated security advocates a rather firm way of saying, “No,” by having something else say no. I’ve long called this “security by bowling bumpers,” i.e. fine, we’ll let you wildly toss the bowling ball down the lane, but these bumpers are going to give you finite boundaries on where the ball can go.

Fourth, pick your fights. Some projects can probably be seen right away as never going to fly, maybe because of some other reason. Others may be visible and obvious enough that you either need to start getting on board and live with it, or start moving on. There are always initiatives that are bad risk-based decisions, overall, but sometimes you just gotta let it go.

As a parting thought, I think low-level techs and mid-managers make far more risk-based decisions that anyone likes to admit, because they automatically do the cost, risk, ROI dance pretty quickly in their heads up front; maybe not in a way that can satisfy accounting/CFO, but in a way that is pretty accurate if heavily scrutinized; and few get any recognition for it. If you’re a manager and you have an employee who exhibits this skill, please nurture them and keep them close.

oberheide details xss flaw in android web market

Posted on by michael

Check out Jon Oberheide’s highly detailed report on an Android web market XSS that could have pwned mobile devices. These 2 quick lines illustrate the uphill battle security will always have:

The actual vulnerability was an incredibly low-hanging naive persistent XSS in the Android web market….While being able to browse the Android market via your browser on your desktop and push apps to your device is a great win for user experience, it opens up a dangerous attack vector.

a few points on pauldotcom’s 7 ways to not get hacked…

Posted on by michael

The folks at Pauldotcom recently posted 7 ways to not get hacked by Anonymous. The steps are good, but wanted to add something to it.

Yes, the first item should be, “Don’t be douchebags.” And further, don’t be an idiot. How many people go around punching hornet nests? If you do, it’s because that’s your job and you take precautions!

2. Tried and true CMS. I’d add that yes, you should maintain a tried-and-true CMS, but also make sure your web developers exercise restraint in the plugins/addons they include into the CMS, keep an inventory of which ones are included, keep up with new releases, and install new releases of those addins. There are many issues with poorly-made addons to these apps…

There are tons of other points and tips to make…but I’ll just stop there! This should further illustrate the difficulty in keeping up with IT/security these days, even in a “smaller” shop like HBGary Federal.

shrdlu channeling joel scambray

Posted on by michael

To offset some recent ranting posts, I wanted to point over to the most recent and absolutely awesome post from shrdlu, How secure does that make you feel? The two points I’d like to underline from this:

First, as a people, we have our flaws, and yet the world is doing ok. Remember that. Not only in terms of business and security, but also our short lives and happiness.

Second, investment advisor and the security poverty level (and the money vs risk tolerance spike!). I think this is an awesome way to put it, and it lines up with my ache whenever I hear someone thinking a solution to security is turnkey or no cost or just a one-and-done project rather than an ongoing task.

In fact, the more I think about it, the more I like the financial/investment advisor analogy. He’s not there to follow a script, but rather give his expert opinions based on your situation. Everyone should have a security advisor, even if it is just to tell you you’re not ready for the bill from one. And truly, a security advisor should have that presence to do exactly that; tell someone they’re not ready, give some entry-level advice, and waive the bill. One could almost see this also like a very customized insurance agent, as well.

is it ever less costly to do something more secure?

Posted on by michael

If there’s a theme in my recent postings, it’s that I’m turning into a curmudgeon; complaining and ranting and shaking my head. I’ll get over it, I’m sure! Just…not yet!

There are so many levels to security, it’s sick. You can talk about microscopic security (in an SMB) or macroscopic (global/universal). Web App or Network or OS. Data or device. High risk/value, low risk/value. Skiddies, APT. General users or highly technical admins. Your customers or your company’s customers. And on and on and on…. It’s crazy. It’s liable to always be the monkey[wrench] chuckling from around a blind corner that keeps poking holes in any sort of best practices or standards or commonality amongst any of them. At some point, you have to get back to the basics and starts making your Laws. You will be breached. No single answer is The Answer. Staff is key. Users are a big weakness. Security vs convenience. The point of business is not digital security. Secure Enough. And so on…

And sadly, for almost every Law, we can come up with, “Yeah buts.” Maybe the Best Practice is that there is no universal Best Practice? Yeah, that will make every executive roll their eyes and find a new consultant/partner/manager/tech. I still have this nagging feeling that our problem is one that is not just at odds with users and convenience, but fundamentally at odds with business and management; that the last 50 years of digital technological development is still dashing a century of business acumen in the face; that they’re just not all that compatible without painful change, much akin to the RIAA/MPAA/newspapers and their painfully changing businesses. Or maybe not. Maybe we’re (IT that is) just an underswell right now, that we’re just heaving up against the older guard of business…like a rolling wave (a slooow one)…that will recede back down in the future? Possible…though it doesn’t help that business keeps dragging IT (and thus security) back into the core business in ways that aren’t very smart or far-seeing. It’s like a heaving wave pushing up against your inflatable raft, while also turning up the wave pool dial and splashing your own face with more water, both sick of it and yet insatiably wanting more. Like McDonald’s fries.

Rafal Los published a post the other day that sparked some of these thoughts of mine, not directly, but just through his tone, really. His post titled, The Path of Least Resistance, went into some not-new, but good thoughts:

…It’s not a stretch to consider that when confronted with a complex, convoluted, and difficult set of security processes and controls users often find ways around them without too much fanfare.

It’s important to remember this applies not only to “users” but also to technical persons, even in fact the administrators creating these policies/processes! We routinely know security processes and routinely ignore them in order to get the *real* immediate issues taken care of. A user needs to reset their password. You know the user, so do you take the time to go through proper procedure or do you pursue the positive feedback that comes from quickly helping the user get on with their life/job? If your boss finds out about either case, which one will get *him* in trouble quicker, and thus which one will get reflected in *your* next professional appraisal? I’d suggest we almost always reward Getting Things Done rather than inconveniencing anyone with process. Even the best customer service stories taught in generic management classes espouse breaking rules to solve problems and send customers away happy.

You can’t do that in security unless you are an expert and can make risk decisions quickly and accurately. Otherwise you should follow process; it’s there to help security in situations where the involved actors aren’t sure what is risky or not. And, by that very nature, will always add inconvenience (or other resources).

Even the most simple concepts of “risky” behavior vs “non-risky” behavior involves negative cost, whether we’re talking security or even safety. I really wonder if there are very many examples where doing something securely is easier (less costly) than doing it insecurely, when simply in the moment and ignoring resulting costs/benefits.

Rafal Los goes on to talk about creating software more securely:

I know this isn’t something novel to read on this blog, or coming from me -but Software Security Assurance efforts have to make producing and releasing more secure software more simple than releasing less secure software.

Now, one can look at this and mistakenly say, “Well, let’s just make it really hard to make insecure software. You have to jump through hoops, sign documents, put your pay on the line, and so on if you want to do something that is less secure (assuming you even know what secure means, which you likely don’t if you even have this problem). That way making it less secure is harder!

I doubt that’s what Rafal was going at, but I’m not sure you can simplify making things more secure from the start. I mean, it’s always going to be *easier* to write simpler, less secure code, right? Accepting raw user input will always be easier than accepting user input after a scrubbing routine. Even the pseudo-code for that illustrates the extra steps, yeah?

Maybe I’m still thinking inside the box. 🙂 If I think of any situations where it is less costly to do some more secure, I’ll post a follow-up.