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!

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.

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.

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.

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…

I’m a glutton for information, so I about made a mess in my pants when I stumbled upon a pentesting bookmarks compilation put on in part by the folks of SecurityAegis. Everything from cheat sheets to tools to reference links to ongoing information in blogs and forums. Definitely gives me new blood for my rss reader and tons of things to check out in less busy moments.

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.

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.

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.

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.

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.

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.

I really don’t know how attackers broke into Director’s Desk which is the core issue around the recent NASDAQ attack. I wish I had more details like how the attackers broke into something and what that means…so otherwise But I do know three things.

First, Director’s Desk is a web-based service. In modern parlance that’s, “cloud,” for people who don’t get cloud. In my parlance, it’s called a “Web Site.”

Second, yes, real-time forensics, aka network traffic inspection (or monitoring or whatever you want to call it) would certainly help. This isn’t new, it’s been around quite some time as NSM or even IDS/IPS technology.

Third, real-time monitoring isn’t quite as easy as a 4-paragraph article would lead laymen, managers, or even IT staff to believe. You need your network built in a way to make it convenient to capture and act on network traffic. Throughput to keep up. Software that knows how to inspect traffic and pick out the bad things and alert/act. Storage enough to review findings. And staff to blue all of that together, keep it operating smoothly, and work on the inevitable gaps and weaknesses that any such tool will offer.

I hate being a wet blanket on security where someone says XYZ will solve that problem, but leaves with the undertone that XYZ is easy to do and/or costs nothing to a company other than a license. It’s the same expectation when someone bandies about “open source” software and how it is free and saves the company money…with no regard to how much internal support and homegrown glue will cost in the long run. That’s great that it’s free in your home network of just you, but what about across 1,000 persons?

I agree with intiatives like NSM and “real-time forensics.” But I just dislike propping them up to fail by virtue of unrealistic expectations.