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.

Robert Graham has 2 excellent posts going up. First, be aware of the ports on your laptops/devices, specifically the new Thunderbolt technology from Apple/Intel. Yup, this brings back memories of Firewire issues! Second, be aware of SSD disk drives and how you might not be properly wiping such flash memory unless you’re careful.

Essentially, take care of your device ports and shore up your SSD drive destruction policies and practices.

I’m still ornery today. I’m not sure what it is; I think it’s just this lingering tail end of a cold I’ve been stuck with for the last 2-3 weeks…
I’ve been sitting on this post from Dave Shackleford for a few days, letting it digest and ferment…errr I mean sink in and blossom. Dave talks about a few topics and I wanted to pull it apart like unwinding some Twizzlers. He talks about post-RSA thoughts, business alignment, change, worshipping exploit-finders, and the echo chamber.

As with the post I discussed yesterday, I just want to preface that I agree with Dave. This isn’t meant to be argumentative or critical; rather building and fleshing…

Post-RSA thoughts? I think it is fine to desire security companies who do have passion for their job, but yes, point taken that there are still plenty of companies who are only chasing profits. (As a corollary, how many security nuts want to go into sales? And thus, how many sales and marketing people are security nuts? Yeah, that’s the gap. It won’t change.)

Aligning with business. I don’t think when someone says that security needs to integrate with business that they’re meaning you need to figure out how *other* businesses work and accept that they’re in it to make money. Maybe that’s a given to me? Who knows, maybe there are still people who come into security all idealistic and think every vendor is out there to help them with their security and offer only solid, value-driven solutions. Well…it will only take them about a year to realize they’ve sometimes been sold lemons and sometimes they’ve been sold tools that can’t manage with their budgets.

Change. I agree. “Change what?” I’ll say that sometimes this is the right approach. If I’m not happy, the solution is two-pronged: change and to figure out what to change to make me happy. In the case for security, I don’t think we know the answer to either prong of that solution. We don’t know what to change and we don’t know what changes will improve anything. So why do we say change? Because we’re not perfect? Because we’re still behind the curve of security? I’d argue that’s exactly where we will always be by nature of the beast! Sometimes you’ll be unhappy if you’ve set unrealistic, maybe even impossible goals for yourself. In that case, you need to redefined your happy state. Or redefined what “security” means to you.

Worshipping exploit finders (aka the adversary motivation). This is complicated, and I both agree with Dave and think there is simply more to it. First, I think our focus on exploit-writers and breaking into things is deep-rooted, probably something to do with competition. This may be a people thing or even a national/socio-economic thing (capitalism==competition). Second, we’ll all become better defenders if we had more skill/knowledge as/of attackers. How best would person a secure their OS/apps? If they knew how to break them. Maybe not in a way you can do it while sitting in a club getting a blow, but at least know that it’s possible.

In the end, I do agree, however. For as much fun as it is to break things, we continue to need to focus on the fun of securing things and thwarting attackers. We need rockstar defenders as well as attackers. (At least there are many attackers breaking things for the greater good as white hats; we do still need that segment.)

Echo chamber (aka evangelize). This is a tough call. I agree we need to get out of our comfort level, but this is a bigger bill than one would expect. On one hand you can talk to technical people, but if you’re going to talk to them about security, you need to talk on their level and give them actionable information. Not just point at OWASP top 10 and hit the bullet points, but give examples of insecure coding and ways to actually do it. Otherwise you’re just a burden; another requirement-giver causing them more work and telling them their babies are ugly. You have to actually teach, which is still hard for many security persons to adequately do. On the other hand, you have a crowd of non-technical people who need to know why they should even bother; and they often need a heavy dose of FUD to get the point. But even here, expectations need to be tempered or we’ll always be an unfulfilled bunch. My age-old example of home security hits home here (huk huk!): it’s easy to scare people, people know they need to do it, yet so many homes are just waiting for theft/invasion. You’ll also need to be able to deftly, and understandably field dumb questions and deflect misguided assumptions while keeping mind that not everyone is as paranoid as a security geek and not everyone puts the same value on their personal information as a security geek does.

Biggest point: We security geeks rant and rave and we *need* to. We *need* to talk to each other to share ideas, but we also need to share our pains and stresses and cathartically release them together. And we *need* to keep talking to others outside those groups. This is where consultants really, really need to bring their game. Charlatans in it for the paycheck need not apply.

Last point: We’re often at the end of the stick, just like IT operations. We’re at the mercy of attackers, users, software, business, and vendors giving us crappy security products filled with half-false promises. Getting to the forefront of this probably means embracing risky, edgy concepts like “there is no perimeter” and doing things so dramatically different… Maybe. That’s just me high on tea this morning…

Go read this post from John Strand over at pauldotcom talking about the latest Microsoft 0day:

You have to ask yourself, if someone wanted to target you, how successful could they be? What’s stopping them from getting your users to click on a link or open an attachment? What stops your users from accessing SMB on your servers? How do your servers defend against a 0day attack?

I have several issues with the particular post, but maybe I’m just killing time at the end of the day being ornery…warning: this is a bit ranty/rambling/disorganized, even for my tastes.

1. Just to start, I agree with the post and position in general. There’s really nothing new or wrong here. It’s a great starting point to a discussion/thought-exercise on security paradigms/posture. Security geeks should *always* think this way.

2. It’s just that: a starting point. I liked this post at first hoping it would go into some ideas about this issue. But there’s really nothing other than the point that prevention eventually fails, therefore detection/response are important. (I’ll get back to this in a few points…) Well, if IDS is evaded, what other detections are we talking about?

3. Also, I take issue with the possible tone of the last line: “No friends, it has nothing to do with prevention anymore. It is now a questions of containment and detection.” Is that in the context of the hypothetical? I hope so, because this month’s 0day shouldn’t be the catalyst for such a position (1996’s 0day should have been) nor should we just throw our hands up about prevention just because 0days exist.

4. The problem, in business anyway, with the “prevention eventually fails so get with the detection and containment” idea is it’s only a vague concept. It sucks to get budget dollars on something that doesn’t actually empirically exist. But, I’ll defer to all risk experts out there who do just that… Yes, it’s important, it’s just more difficult to explain that to a layperson; it’s difficult for them to grasp the concept that an attack *will* be successful at some point. Even in security ranks this is spoken but not always truly followed upon.

5. Every time a new 0day comes out, there are sets of people who start wailing about how you can’t protect against unknown attacks leveraging existing holes in software. Well…that’s not a new proposition and has always and should always have been part of a security mindset. Every single piece of software, hardware, and protocol we run right now probably has a weakness we don’t know about. Hell, we should *assume* as such…at least as much as we can do anything about.

6. Before anyone gets too uptight about a currently known 0day issue, we really have to dive into the issue and what is really at risk. In this case, yes, someone can *possibly* run remote code on a domain controller. How do you do that? Fine, you can trick a user to hit a website and get their machine owned via some other exploit, which may then act as either a call-back zombie or just itself launch this new 0day attack against whatever domain it belongs to. Let’s assume said attack can run remote code and then own the domain controller. (Wormable? Only on a small scale, i.e. within trusted domains. Unless this can reliably attack the services on regular Windows machines or blend attacks [ala stuxnet]…then we’ll have to scrub all of this!)

7. Well, what next? Someone might talk about VLANs and firewalls and segmentation, but those are largely out the window when you talk about owning a box that, in a Windows environment, needs access everywhere. You can make sure your domain controllers can’t talk to any untrusted networks at all, for starters. Why let a DC call home to an attacker? I would hope proper log management and file integrity monitoring would help (for those few that actually do that passably well!) raise the alarm quickly.

8. Once an issue is known, we do start seeing signature definitions get pushed out by various AV/AM/IDS/IPS vendors. This is a start, though I’ll admit some would be stymied by even small changes in the payloads, especially for POC exploits. Yes, you can evade defenses, but how often are they *really* done in a way that isn’t a gimme. (A “gimme” is using SSL/TLS over 443 to deliver it…I mean, come on, I don’t consider that to be an *interesting* evasion of IDS. To me, evasion is walking past the security guard while he’s looking right at you, not walking in a side door he can’t even see.)

9. To build on the previous point, it is useful as a thought exercise to think about life without AV and IDS and patches and then to justify that by saying AV is weak, IDS is evadable, and patches are often not done. But that shouldn’t mean to anyone that there is no value in any of the above 3, or no need to pursue them. We need to make sure laypeople know that us security geeks are realistic, but paranoid. Trust, but verify.

10. So now we’re back to endpoint security and various ways to protect the endpoint including reduced rights, web proxies/filters, egress monitoring, education, etc. Or maybe even just data-centric security (which cloud and virtualization/consumerization of enterprise IT will tell you is now nigh impossible). In chess, how do you protect your king? You protect him with pawns, and you protect those pawns with other pieces. Now we’re starting to think in layers…

11. In the end, while I do have some small issues with the post (would have liked twice the post with some follow-up answers/solutions/theories), I do absolutely agree with the spirit of it!

Whoa, is there a devil’s advocate flying around here today?

Is it easier to accept user input and then consume it (either plug it into a SQL query or echo back to screen somehow…), or to accept user input, validate it securely, and then consume it? The difference in effort/time/knowledge is a reason why we’re still seeing massively insecure systems.

That effort/time/knowledge cost is something far too many businesses don’t really value. It increases budgets and pushes deadlines. Why spend extra resources and then get your product out…versus just getting your product out? You’re going to have egg on your face if you have a security breach, but you’re going to have egg on your face if you spent cost*2 for something that ended up not working out (as a product, process, etc).

This is the conundrum… And you can see it any time a technical person is appraised based not on the quality of their work, but on their delivery times and customer satisfaction. Both of which are helped by cutting corners, bending rules, or taking shortcuts.

This is why all of this is a balancing act. We just need to keep adding security where we can, adding input when asked, and pooping out as much quality (real value) as we can without sacrificing ourselves on the business profit altars.

I don’t make much secret about being from Iowa, and I wanted to note a post over at Infosec Events which recently highlighted the community in Des Moines, Iowa.

At some point, I need to show up at ISSA, considering I work within walking distance…

More news, this time from Forbes, on the storm roiling around HBGary Federal.

I don’t outright condone hacking incidents like this, but as has been said elsewhere, it is hard to feel sorry for someone who has had their closets turned inside out for skeletons…and indeed many (fresh) skeletons are found. It is also hard to exonerate the attackers because any target they attack likely has similar skeletons…or if they don’t, then the damage done in finding that out does everyone a disservice.

In our world today, the “hacker ethic” that information (and secrets) tend towards being public needs to be remembered by business leaders. Yes, there are secrets to be kept (an arguable point I won’t argue), but keep in mind that you really, really, really have to be conscious of keeping those secrets secret in today’s world. (This can dive into why pen testing isn’t and won’t be “dying” any time soon…)

No, I’m not ignorant enough to think that these sorts of business dealings, coercion, and borderline shady approaches don’t happen on a regular basis with most individuals and corporations. But as much as possible I believe people should act with some degree of integrity and respect, including corporations.

I have this weird internal compass that has sympathy towards things like the “hacker ethic” as well as aspects of Randian objectivism… It all makes sense in *my* head anyway!

Researchers have figured out a way to recover some passwords from iPhone/iPad devices in 6 minutes (video and pdf links are in the article). Obviously this is yet another excuse to preach about not losing your devices and reporting lost devices so accounts can be disabled and/or passwords changed.

But there’s more…think about this. Your VP of Whatever is on a business trip to China. He unplugs for a bit and heads to the exercise room of the hotel, leaving his iPhone in his room. Someone enters his room and will have unfettered physical access to his device for x minutes. And you won’t even know it. And don’t for a minute think this doesn’t happen. Maybe the VP will just think his iPhone is broken and exchange it…

In other words, always know where your devices are, even when they are switched off or locked. This should be obvious, but I don’t think non-paranoid people have been often told this.

The Register posted a story comparing passwords disclosed from rootkit.com and Gawker, which suggests a problem with password reuse.

This is a classic journo case of an editor-sensationalized title for an article that doesn’t really get reasonable until the last two paragraphs where it kinda puts the brakes on calling password reuse “endemic.”

Gawker is a celebrity gossip site. Rootkit.com had a forum. As a security conscious person, would even *I* use the same password for both sites? Actually, I likely would. Gawker would be exceedingly low value to me, if I had an account there, and a php-based forum would be exceedingly risky to me. I *might* actually use a crap password for a forum like that, but I’d call that a flip of the coin depending on my mood the day I make those accounts.

Does this mean we should start running around screaming about endemic reuse of passwords? No, though we should encourage people to not reuse them anyway, but this research really doesn’t say all that much.