Assuming the breach

Where the security rubber hits the operational road

2011-12-12T08:17:00.000-08:00

Where have I been? Absent from this blog, that's for sure. Mostly silent on Twitter as well. What up with that? As you mighta expected, life's been busy around here. But I thought I'd give a little more detail on what that meant.

Let's start with some of the problems that had come to a head this summer.

Gunnar had a great point when he spoke of the Top 5 security influencers. For past year or so, I'd already been working extensively with the Dev and QA team - now to the point where QA is taking bug directly from vulnerability reports from WhiteHatSec and
IOActive and developing QA testing procedures from them which is now spotting more holes, faster, and resolving them more deeply.

I already work alongside the DBAs and the Ops team, but I was really running up against a wall regarding just how much I could get done. Basically, a lot of security projects were getting sidelined in favor of large infrastructure projects and I was starting to lose visibility into the whole process. Worst, overlapping concerns between ops and infosec, like uptime and integrity, were losing ground to not well-planned horizontal expansion and vertical infrastructure structure issues.

The other big bugga-boo in my life was audit. Enough that I'd ranted a bunch about it at Source Seattle.

Well, I knew in the coming year that we'd be shifting some of our operational and access control models to a more expansive system to accommodate some new business directives. This was going to a problem as our existing set of control objectives needed to be redone from the ground up. And this change needed to come both from infosec as well as the operations team, but so far, they had not come to the table with any big ideas. As mentioned before, they were too swamped fighting fires and keeping the lights on. This is an even bigger problem as auditing impacts operations as much as security, especially when you're doing SSAE-16 Type 2. Without needed changes and strong leadership, Ops and Infosec were going to sink together come the auditors next year.

Note on SSAE-16/SAS-70: They're not all worthless. It's naive to assume they're a perfect measure of security and operational efficiency. But's also naive to assume they're worthless. As with anything, you need to do the work and actually read the report - does the scope match what you need to test? Was the audit conducted by observation and testing? Or just documentation review and attestation? A telling factor is how many individual control failures are noted. If the number is zero, then likely the report is scoped too tight to be useful or the auditors didn't do anything beyond interview people and leave.

Lastly, my Corporate Masters, were having problems getting a handle on operational projects. As I mentioned in the lead, important work was being left on the table, while other lesser, more tactical projects were getting funded. Operations needed help articulating and justifying critical infrastructure upgrades and aligning them to key business processes. From my infosec seat, the solution was clear - risk to business objectives was not being defined with respect to operational problems. Simplified example, conversations like "We need a better storage system because until we do, we can't take on any new customers" were not happening in the right places. Again, the team was too busy treading water to document, assess, analyze, strategize, and communicate.

Enter me.

Our Chief of Operations wanted to inject a big does of risk management and clear process into the technical group. Since infosec had been already been doing that in spades for the past four years, he asked me to step in and manage a chunk of the operations team. So about four months ago, I got promoted. In addition to security, I am now in charge of the Infrastructure team.

Believe it or not, I passed on some more lucrative opportunities to take on essentially a doubling of my workload. I'm silly that way.

Actually, it's more than doubled since it's been over a decade since I've done anything deep with infrastructure. For past few months, I've been playing catch up learning about large scale virtualization systems, storage area networks, operational resiliency and IT automation.

It's also more of a chance for me to bake security directly into the existing operational processes. Get my hands dirty and see what is going wrong. For example, instead of auditing and dictating firewall policy, the team that directly manages network security reports to me. I can directly see the effects of new security processes and technologies, both good and ill. I'm on the front lines not just for security incidents (which also land in ops before they are identified and escalated to security anyway) but any other interruption events (which helps me design towards better integrity and availability). So yes, it's good.

But not all good. Because, as I stated in the beginning, I've been treading water myself. In addition to getting to know the team and the technologies, I've also had to immerse myself in learning a bunch of new things. Specifically:

I'm getting to be a big fan of Limoncelli
Been digging deep on project management
Reading up on complexity and systems theory
And good ole, Jerry Weinberg, who I keep coming back to for better understanding and wisdom.

I'll blog more in the future as learn interesting new things.

So, where have I been? A: Where the security rubber hits the operational road.

Guest post - don't be a dumbass cheater

2011-10-26T10:52:00.000-07:00

Hey there, I'm FCB and guest posting today. It's my b-day so Ray thought he'd throw me a bone and let me do a post on his blog of whatever I want. And boy do I have a rant.

Oh, just so's you know me, I'm a hacker for hire - Gray hat not gray beard - lol. I do all kinds of interesting security work and when I have time, I help out my friends.

So speaking of helping my friends. Some my friends are real idiots. And some of my clients are even dumber. On thing that I've heard way too much in the past few years is "boo hoo hoo, I was getting little action on the side and then my wife caught me." My first reaction is - ha ha, sucka. You managed to get yourself a steady sweetness and you fuk it all up. I mean, come on. I've just not had the same kinda luck with the ladies, but hey, your fubars means a wider pool for me.

Anywho, what really smokes me off is how dee you em bee these guys are about their cheatin. Don't they know the simplest things about operational security? Sheesh. Alright, i guess it's left to me to ejumacate 'em.

Lesson one: Keep your cell phone safe

First and foremorst, I hear the dumb guys getting caught cuz they've got incriminating text messages or logs on the cell phone. Hello? Anyone home, MacFly? If you ain't gonna password protect your phone or keep track of it - and honest, for some people, this is really hard. Duh... then ya know what you need to do? Get a second phone just for your "covert operations". In the hacker world, we call this air-gapping. Use a prepaid disposable second phone for all your communications with "under cover contact". If the phone becomes compromised, just deny it's yours. Hey, you found it the other day and forgot you were carrying it around. It's your friends phone. It's whatever, it's just not your phone and therefore any evidences pieces left on it aren't tied back to you. Look, for under twenty bucks and you can buy complete separation from your real life, keeping your secrets safe.

Lesson Two: Keep your email safe

This one's a knee-slapper. I've heard many variants of how a dumb cheater got caught with his proverbial pants down because his wife was reading his email. Two words - dumb ass. One guy commented to me "Oh, my wife never looks at my email." Guess what happened to him less than a week later. Another client once came whining to me that his wife hax0red his email account and gave the contents to a lawyer. Musta chose a stupid password, sucker. I've even heard of suspicious wifes hiring hackers to break in their hubby's emails to snoop around. Me, I've not gotten any of those kinds of gigs - but you bet your sweet patootie I'd take the job (if the price was right). The best (or worst) case I'd heard was this FOAF who actually told his wife his password and dared her to check his email. Well, she accepted his apparent honesty and didn't do it.. for a few months. Then finally when he spent too many long nights at the office, she delved deep and hard into his mail logs and guess what? Pay dirt. So the lesson is obvious, if you can't pick a good password and keep your email logged out when you're not home (you didn't "save" the password, did you?) then do like the phone and get a second email account. Keep it totally clean of anything tied to your real life and make it disposable and deniable if it gets compromised. Leave no traces, soldier.

Lesson three: Protect your ass-ets

A good buddy, who's way smarter than me in the ways of wimmen folk once told me the three key words to a successful relationship - "secret bank account" It's the same deal as above, if you can't protect your eggs then don't put them all in the same basket. No money trail for her to pick up on. And having a stash in a home-away-from-home is handy in case your little chickie decides to lay some large demands on you. You know, the old blackmail... well, then you're all set to go if you need it. And if the whole thing ever goes pear-shaped, you've got get away cash when the lawyers (or media, if you're a politico) descend upon you.

Okay, that's all my cheap advice. If you're gonna have flexible morals (like me, ha ha) and "expand your horizons", then you need to keep your secrets safe. Take it from a hacker and practice good operational security.

Fruit Cup Boy

Compliance vs Security

2011-10-20T14:02:00.000-07:00

Almost as exciting as a few other epic throwdowns, I am lecturing tonight for the University of Washington's infosec certificate program. A few quick highlights from my lecture notes, which is based on the Source talk I gave this summer.

Compliance-driven security forces you to make certain bets on the big enterprise roulette table - but I only have so many chips to play, so I prefer not to be constrained in my choices.

As a consultant I saw primarily two kinds of organizations: Those practicing good risk management who wanted to get better and Those forced to be more secure because of compliance or a breach.

Why is there such restrictive compliance regimens? Without repeatable, evidence-based, agreed-upon risk methodologies, you cannot rely on third-parties to make security decisions with your data that are aligned with your interests, instead of theirs.

Compliance is a multi-dimensional object... and lot more than three. You've got width - the general rules f the standard plus a few specific new ones based on how the organization interprets it. This is the easiest dimension. Depth: As most compliance acceptance is based on auditor opinion, which is driven by the individuals experience. Plus, if the standard is somewhat worthwhile, it includes the appropriateness of risk model (relevance) to your problem. Then there's several dimensions of scope: Time (past events, present controls, future possible events) and then the general usual dimension of Physical, virtual, sofware, network... what’s constitutes a a barrier in those domains. And of course, all of this is moving.

Security is also multi-dimensional but it has slightly different dimensions and moves differently than compliance.

Best practices? In other words, “This worked in our organization once upon a time, So it should work for you too.”

Where I live is the intersection of:

1. What the auditors demand we do,

2. What we need to do to keep from getting breached, and

3. What we can afford to do.

And I'm mot going to get all of all three.

Stupid compliance failures:

- Why is the absence of a particular control is a risk? A high risk?

- How can I be 100% compliant with an open standard? With a product lifecycle of 12-18 months?

- Hey, that's a feature not a high-risk vulnerability - it all depends on your context

- Impact does not equal risk. You forgot probability. Dumbass.

I do it for the Lulz

2011-06-28T18:15:00.000-07:00

I've always done for the lulz.   Security that is. When I lecture to students up at UW, I try to warn them that don't do this job for money.

Anyone going into infosec for the money, the prestige, or for the job security is seriously misguided.   I tell them the only reason I do it is for the lulz. I warn them to prepare to face the humiliation of having a server hacked, the terror of knowing the bad guys will outspend and outlast you, the tedium of when nothing happens and the crunch when you need to justify every thing you've done to an auditor and the budget axe. It's tough, it sucks, it's relentless, and I still love it.

What are my lulz? The thrill of the chase. Heck, forget the chase, how about actually taking down some bad guys?

Besides the sexy stuff, I also get lulz making an organization safer… or even if it's just a friend of the family that needs some malware scraped off their machine. Sure, it's tough work but it feels good to make the world a little safer, a little saner when you're done. And knowing that you've deprived some creep one less victim.   Lulz.

I get my lulz designing new systems, making the strong, making them resilient, making them better than they were before. And digging deep and figuring out where the holes are, where's the best place to fix things, and then working on presenting that to the people that care. Even more fun than all the puzzles and video games in the world.

Technology, and especially information security has always been more than a job to me. More than even a career. It's a calling. Don't tell my boss, but I'd do this even if they didn't pay me. It's what I do. I can't help it.

And to those who say we're losing the war. Whatever. I've been hearing that for years. The world hasn't ended.   I know that more systems than ever are online now and somehow we failures are still protecting a majority of them.   I know we'll be always outnumbered always outgunned.

That's what makes it a challenge.

Decompiling the week.

2011-06-17T17:34:00.000-07:00

What an amazing week...

Fantastic time at Source Seattle. If you didn't make it, you should really check out what you missed.

Great keynotes by Kris Herrin and Eric Cowperthwaite. Nice getting the executive "big picture" on breaches and managing security.

Thoroughly enjoyed giving my talk and a lively audience as well.

Fascinating lunchtime discussion with Marcia Hofmann about privacy and the nature of social media. Enough to make me re-up my membership in the EFF. You should consider it too.

Not only a great demo by Ron Gula, but he spent time after the session doing a one-on-one with me giving an insider's tour of their software. It was great to see a master at work. How often do you get that kind of access to that caliber of talent?

If Source wasn't enough, I had to get me some Agora where Kirk B. pointed me at this fascinating paper on assuming a state of compromise. Since that's what this blog is all about, you should check it out.

Now I need to sleep...

6 reasons why InfoSec should not report to IT

2011-05-12T11:44:00.000-07:00

It’s not a strict compliance requirement (tho it sneaks into Separation of Duty under SOX) but generally it’s a bad idea for the Information Security Functions to report to any of the IT management divisions. At best, maybe the head ISO can report to the CTO but anything lower down the line is a bad idea. Why? Well, Here are 6 reasons, many of which are variations on that separation of duty theme.

1) IT’s primary mission is to keep things running get things done.
InfoSec’s primary mission is to keep risk to a manageable level. These are almost most the same but not quite. Unfortunately, the infosec are the people who occasionally need to say no… or at least “slow down.” But when push comes to shove, the IT folks will say “damn the torpedoes, full speed ahead.” Not always a good idea for security.

Sometimes instead of pushing ahead, IT chooses not to do something in order to fulfill a greater business mission. This thing could be upgrading firewalls, patching vulnerable services or fixing broken anti-virus.

2) IT is about sharing information, not restricting access.

For IT, the priority is generally Availability > Integrity > Confidentiality. For Infosec, it’s generally Confidentiality > Integrity > Availability. It'd be nice if both could agree on Integrity and maybe in some organizations these priorities align. But usually if data gets breached, infosec takes the first hit not IT.

3) Part of InfoSec’s job is to keep an eye out for insiders.

And the most dangerous insiders are within the IT group. Sometimes they’re leading the IT group.

One could add that the IT staff generally develops a sense of entitlement around technology they manage. Understandable since they are, by definition, the most knowledgeable and skilled IT workers. Unfortunately, this can lead to staff feeling the rules don’t apply to them and either be accident or design, security problems can develop.

Note that security people can go bad too. That’s why it’s good to separate them from IT and take away their admin privileges.

4) Enterprise risk decisions aren’t usually owned solely by the IT department.

Risk decisions should be made at the executive level. Good infosec professionals are skilled at facilitating the necessary conversations to make sure risks are properly addressed.

Not that IT can’t talk to the executives, but often when they do, they have different priorities in mind… see #1. Delivering up a risk message about a business objective and at the same time, discussing alignment of IT to business objectives can often muddle the message and the decision. A Socratic method with two different viewpoints – IT and infosec, is more conducive to making a better decision.

5) To be effective, Infosec needs to branch out of technology.

Infosec works with many different departments at an operational level while IT works primarily outside of its group in a supportive role. Consider how much infosec has to work with Human Resources, Physical security, Accounting, Legal, Business Development, Software development, and Sales. These are specialized organizational skills that aren’t common in IT.

6) It’s easy for IT folks to think they’ve “solved security” when in fact, they’ve just implemented a control.

IT is used to solving problems so give them a security problem and they’ll quickly engineer a solution. However, security is a lot harder than that. Worse still, many IT folks don’t realize how little they understand how security works.

The Kobayashi Maru

2011-04-11T13:50:00.000-07:00

Trek nerds will remember the Kobayashi Maru as a requisite test for command. It was a simulation of a no win scenario that taught a candidate would deal with utter failure. As Spock said, "The purpose is to experience fear, fear in the face of certain death, to accept that fear, and maintain control of oneself and one's crew. This is the quality expected in every Starfleet captain."

I'll also say that this is a quality I expect in every security leader. Except our fear isn't death, but of breach.   Like the title of this blog, I think it's a useful exercise to assume you've been breached and plan accordingly.   For some, this is as radical idea of contemplating one's own mortality. Specifically, I've encountered more than a few executives and tech leads who are fully willing to go their entire career expecting that they will never experience a data breach. For me I saw as an educational opportunity to teach.   Teach them that organizations can survive a breach; it's a matter of doing the best job you can and being able to prove it. It's also a matter of knowing where your weak spots are and what can happen. And it's a matter of preparing for response.

If you take nothing else out of this post, take this: perform a Kobayashi Maru test on yourself. Test your incident response plan.   There are some great guides out there. Write a plan and test it. Figure out some likely scenarios and run the steps and see how you do. For scenrios, you could even replay the last few major breaches and think about how you'd do if it happened in your org. Not how you'd defend against it (cuz I assume y'all thought of that the second you read about it) but imagine it already happened. Now think about how far it's spread internally, what data would be leaked out, what services would be offline, what forensic data would you have? This will likely cause you rethink some controls - are you logging enough? Do you really have defense-in-depth? Do you have an accurate data inventory? Do you have all the critical personnel on speed-dial? Do you have an organized method of contacting customers? Figure this all out and share the data with your boss. Tell her it's a good idea to plan for a disaster so it doesn't destroy the company. How an organization responds to a breach is crucial factor in a security program.

And when you want to point at other major breaches and chuckle with schadenfreude, you should think one thing - that could have been you.   You think you've got all your bases covered, you're locked down and unbreakable? Think again.   And you know what, check again on those companies in 12 months and see how they're doing. Some are done and gone. Others have survived, maybe even stronger.   And to those security folks there, I think they might have done a good job preparing for failure.   And I take that as a challenge. Again, Trek said it better than me. This time it was Captain Pike, talking about the destruction of the USS Kelvin. "Your father was Captain of a Starship for 12 minutes. He saved 800 lives. Including your mother's and yours. I dare you to do better. "

What I've learned about Rugged in the past 24 hours

2011-03-30T08:16:00.000-07:00

Well, I learned yesterday's post touched something in some people. Based on the comments I got, both online and offline, I can guess a few of us are confused about what Rugged is about. Especially those of us who've only read about it, instead of having it explained to us. And sadly, some of us "saw it and dismissed it" as another security fad. Maybe this post can help fix that.

A lot of folks, including @joshcorman himself, stepped up to help me understand Rugged. Very nice, Lazyweb!

First, let's start with the problem (as I see it)

Software security programs have a poor Raison d'être. This is likely because it's hard to define what "secure software" is. (heck, define "secure") Is secure software?

Resistant to cross-scripting and SQL injection attack (insert attack du jour)
Bug-free?
100% OWASP complaint (yes, I have been asked this)
Have no high vulnerabilities?
Made with high quality?

Waste of time, right? We all know secure is a sliding scale based on value and risk. You can't arbitrarily define security, which makes it less than useful for talking to executives and business program managers. So how do we frame the conversation in a useful manner? Enter Rugged.

Rugged leap-frogs over all these definitions and points to the qualia we security grognards are jumping up and down about. It brings it down to earth with a clear and sharp image that conveys the essential intrinsic properties of "secure software"

To answer my own questions:

1) How is Rugged different than any other Best Practices?
Well, it's NOT really a best practice… more of a framing technique… or (ulp) a paradigm. I was expecting too much of Rugged to even put it in this category, it's just not that kinda thing. It's just a way to simplify the dynamic and intangible. Of course, we could apply some evidence-based analysis over time to see how effective it is in helping the non-security folks understand us.

2) Convincing the developers to write more secure/stable software isn't my problem. My problem is convincing customers and managers so that they'll let/encourage the programmers to to write more secure code.
Ah, this would be Rugged's sweet spot. Here is a meeting ground for the security team, developers and money spenders to agree on something that is useful and clear. A way to communicate what needs to be asked for, what needs to be done and what the final product looks like.

3) Software security problems are deep and complex.
Actually, digging deep enough into Rugged, this issue is acknowledged. And Rugged doesn't aim to solve these problems directly, but again, it gives us all something we can put hands around when wrestling with them.

4) Rugged appears mysterious and embryonic.
Hopefully we can change that. The more we spread the word (and ask questions), the less confusion we'll see. So I'll light a candle now:

Here's how I would summarize it as guidance from management to the developers.

"If our software is Rugged, it is built to withstand adversity, tolerate anomalies, and always do what we intend it to do. Our customers depend upon this level of unyielding reliability; in fact, they expect nothing less. It is our responsibility to meet these expectations."

How's that sound?

Would someone please explain this Rugged thing to me?

2011-03-29T10:30:00.000-07:00

I'm steeped in a huge SSDL project here at work - looking to move security in our development processes to the next level. Lots of heavy lifting doing evaluation, analysis and reorganizing. I'll throw in a shameless plug for WhiteHat Security who's helping us a ton.

Now, one of the things that came up in my search to see how to improve things was the Rugged Software movement.   Early on in the process, I foolishly mentioned it to our CTO as something to look at.   Why did I saw this was this foolish? Well, because at the time, I had only a cursory understanding of Rugged.   He went off and dutifully checked into Rugged only to find the bare documents on the website. Indeed, it was a movement, but apparently not much else.. at least at that stage of the game. He came back to me confused and wondering why I had brought it up to him. What was he supposed to do with this Rugged thing? Oops, I had just wasted some credibility and an important ally's time.   A mistake I wasn't going to repeat.

Well, here we are months later, and I'm afraid I still have only a cursory understand of Rugged. Apologies to Josh and the other creators of Rugged, but I just don't see anything there worth passing on yet. Maybe it isn't aimed at our developers? I don't know. It wasn't clear. I'll be the first to admit I've not attended any conference talks on Rugged (I admit here, I don't make to many conferences) and I don't attend many webinars or online thingies (they're often hard to follow). I have googliated a bit and haven't found much beyond a few news articles. On the other hand, I have found tons of advice and guidance on practical secure development frameworks like BSIMM.

Overall, my big questions / confusions are:

1) How is Rugged different than any other "Best Practice"?
Is there any evidence yet to show that it improves security? Can I see it?   Can I share it with management?

2) Convincing the Developers to write more secure/stable software isn't my problem.
Talk to them, as I have, and most of them wouldn't mind writing more secure code. Some of them even want to write more secure code. And a certain chunk of them don't know how to write secure code. I don't see how Rugged solves any of these problems very well.    The root of the problem comes from the fact that secure code still isn't spelled out in the requirements. Developers can only do what the project manager demands, which is based on what the customer demands.   So if Rugged is aimed at convincing customers to ask for more rugged software, specifically and pointedly asking, then I'll admit it should be preached (but not to me, to my customers).

3) Software security problems are deep and complex.
A lot of security bugs are buried deep in old crufty code or libraries. Even when all our developers are cracking on all cylinders of secure code dev, we're still excavating for fundamental faults and design flaws. And when you land in those pits, you're dealing with Expensive Questions - redesign ($$$) or patch-and-move-on.   I need a movement that helps me make those decisions.

4) Rugged appears mysterious and embrionic.
I'm sure it will grow up to be influential and useful, but to be practical to me right now, I need something that's actionable that I can use with my Development team and management.    The story I mentioned in the opening about confusing my CTO cannot be repeated.   And beyond that, my executive team will ask for proof and metrics for any new development movements I propose.   I don't blame them.

So please, help me out here. I am confused, what am I missing or misunderstanding?

UPDATE - People have stepped up to 'splain it to me (ha, my evil plan worked). Read what I've learned here.

Good pen test reporting resource

2011-03-01T09:57:00.001-08:00

I knew there were folks out there who could do a good job at this. Instead of writing sloppy security reports, here's a positive example of how to do a better job at it by Steve Shead. He's a security guy and a graphic designer, so no wonder I like his layout for pen test reporting.

Source Seattle

2011-02-23T15:19:00.001-08:00

I will be speaking at Source Seattle

Here's the lineup

How much should you do to prevent malicious sys-admins?

2011-01-28T10:57:00.000-08:00

In the age of Wikileaks, obviously trusted insider access must be controlled.   However, how much is enough? Consider the following typical conversation between auditor and subject:

Auditor: What controls are in place to prevent employees from emailing confidential data?

IT Manager: All confidential data is secured in a separate environment where access is limited only to a dozen administrators… all thoroughly background checked. Access to the environment requires strong authentication and access is logged in a tamper-proof data vault, so we know who did what. Also, the rest of the environment is swept periodically with a DLP to ensure that no confidential data resides outside that controlled environment.

Auditor: But what prevents an admin from emailing confidential data out of that secure environment?

IT: An admin would have to use his crypto key to open up a protected store in the separate environment and copy the data out to the main environment to use email.

Auditor: So there are no email filters in place? Alright, that's a finding.

IT: Wait? What are you saying? Do you want us to protect against accidental exposure or do you want to us to protect against a determined privileged insider? If the case is the latter, who do I prevent admins from viewing confidential data and copying it down on paper? I mean we log all access but at some point, admins will need access to the root kernel.

Auditor: Uh huh. I think I see another finding here.

As the Verizon Data Breach Report report shows, insider misuse accounts for nearly half of the breaches. Note that this particular report has US Secret Service data in it is as well, so there is some good stuff on insiders. So, on page 18, we see that 90% of internal agents attributable to breach are deliberating circumventing controls for malicious reasons. On page 34 we see 48% of breaches and 3% of records because of "Misuse". Of these, 49% were of the type "Embezzlement", so trusted insider determinedly circumventing the controls for malicious purposes.   So yes, there are data to back up the need for controls on insiders.

Fortunately, there are many of strong and somewhat easy (but not often politically easy) methods to lowering this threat. First off, reducing the number of people who have access to the data, as the IT manager described above. Second is to add strong accountability and monitoring, which she also does. And of course, background checks are pretty easy and common as well.

But it seems that is not enough for the auditor. Fair enough, in some environments, maybe even stronger controls can be applied. You would expect this to be the case in military and governmental intelligence systems, which is why the Private Manning case is so disheartening.

However, it is not surprising. Technical controls for privileged usage can run rather high. Last I tried to implement them, I was looking at least $3,000 per admin ($5k when I factored soft costs) for a system that would actually mediate (read: prevent not just detect) privileged access. And then the admins screamed about availability and manageability.   In short, it just wasn't feasible. It didn't help that the systems that you most want to protect (the ones holding the credit cards) are also the mission-critical money-making applications that are heavily SLAed.   So usually we stop with separation of duties, least privilege, non-repudiated access, audit trails, background screening.

So far, I don't think I've said anything new that most security folks don't encounter every day. But what I also hear all the time is the push for even more controls on insiders. So where do we go from here? How much is enough? Because to me, there is a clear point of diminishing return on insider controls and we're pretty much there.

Peter Sandman and risk communication

2011-01-23T22:05:00.000-08:00

Many of us in the infosec profession struggle with communicating risk. Not only do we need to communicate it upstream to the decision makers, but we also must spread it wide and downstream to the every day folks so they can do their jobs.

In my work in disaster preparedness, I stumbled across the work of Peter Sandman. I've read most of his articles on risk communication. I really found a lot of useful wisdom in his advice on how talk about scary potential future events. Although his specialty is disasters such as pandemics and major industrial accidents, his breakdowns of the psychology behind risk communication is sound. And in many cases, an infosec practitioner must also deal with business continuity, so it can be directly useful.

One component of his advice I find most interesting is his breakdown of Risk = Hazard + Outrage.   He says,

In the mid-1980s I coined the formula “Risk = Hazard + Outrage” to reflect a growing body of research indicating that people assess risks according to metrics other than their technical seriousness: that factors such as trust, control, voluntariness, dread, and familiarity (now widely called “the outrage factors”) are as important as mortality or morbidity in what we mean by risk.

With this, he describes outrage management, which for us, is about how we handle incidents. Not the technical pieces of incident response, but how we communicate the incident to all the stakeholders (executives, customers, auditors), with the ultimate goal of minimizing the reputation damage.   I see similar factors at play in communicating a massive oil spill and handling a public disclosure of a severe vulnerability in your product.

Many interesting lessons on his site and worth spending some time seeing what might prove useful for you.

PDCA for IT InfoSec, much assembly required

2011-01-02T12:42:00.000-08:00

"But ignorance, while it checks the enthusiasm of the sensible, in no way restrains the fools." -Stanislaw Lem, His Master's Voice

A lot of the tech industry worldwide have turned to the ISO 27k standard as guide for getting their hands around IT security. I say "getting their hands around" because I don't think as a whole, we're up to the challenge of actually measuring and managing IT risk (but that's a post for another day).

The heart of ISO 27K is the Plan-Do-Check-Act (PDCA), or the famous Deming Wheel Some even call it the Hamster Wheel of Pain because the process can be endless and ineffective if implemented sloppily. Alex Hutton has recently pointed out that the ISO 27k standard doesn't say very much about whether your processes improve your security or not. I'm inclined to agree, as the standard is primarily about the bureaucratic process of managing risk as opposed to defining the "real" work that needs to be done.   It can be wielded as bluntly and ineffectively as a SAS-70. (hint: like a SAS-70, you actually need to read an ISO 27K certification report and keep a close eye on the scope and how decisions were made).

As a former IRCA Certified Lead Auditor for ISO27k (my cert expired this past November), I was fortunate enough to get both deep and wide training in the standard from some very experienced and gifted practioners. It led me to a deeper understanding of the standard, far beyond the page, and what it was trying to accomplish.

It also revealed to me how right Alex is in saying the standard is too rough to be applied with significant training and additional material.
In fact, many apply the standard as the same old laundry list of "shoulds" and "musts" of controls (aka the 27002 list). In fact, the toughest but most important piece of the standard is based on Deming's base concept. Again, PDCA.   I have seen many skim organizations skim through Plan and race right to "Do". Without a strong and detailed Plan, every other step is futile.

Do what? Why? And how much? Check against what? Act to correct back to what plan? The essence of planning as I see it is something that is hard to define as a hard-coded procedure, which is perhaps why it is so watered-down in the standard.

A fallacy in management is that what works for some organizations may not work for others.   Cargo-cult mimicking of management processes is not only ineffective but dangerously misleading when certifications start getting thrown around.

Planning involves coordinating with the business of the organization to discover the information flows, data repositories, business rules and critical objectives. Then working with upper-management to define priorities and trade-offs.   After that is done, a thorough risk analysis of the dangers to those objectives has to be done. The standard does offer a risk analysis method, but it simplistic and shallow compared to more in-depth methods like FAIR or FMEA.

The final piece of planning is to decide how to treat those risks.   In the standard, this is documented in the Statement of Applicability or SOA.   The SOA is a mapping of objectives to risks with the selection of a treatment method. The list of controls in 27002 is suggested but not mandatory. You can drop controls to your list, if your analysis supports it. The standard actually says "Note: Annex A contains a comprehensive list of control objectives and controls that have been found to be commonly relevant in organizations. Users of this International Standard are directed to Annex A (ISO 27002) as a starting point for control selection to ensure that no important controls are overlooked." Let me repeat that, you do not and probably should not take the list of 133 controls in 27002 at face value, implement them all and think you're done.   Here you have the flexibility to choose what works to deal with the risk to your organization's objectives. That's "applicability" part of the standard.

I am really excited that Verizon is now giving us a more accurate picture of risk and controls in the real world. I, for one, welcome our new Evidence-based Overlords. Especially as an more in-depth list of control deployment tactics instead of ISO 27002.   As said in medicine, half of what we know is wrong, but we don't know what half. This is a step in moving towards knowing and the key is learning from other's mistakes.

You can see that a solid foundation is how the PDCA begins.   And as you move through the Deming Wheel, you "Do" and "Check" to see how well your controls are doing.   Not only are they being implemented correctly (which is where most people and auditors stop checking) but how appropriate and useful are they to the risks to the objectives. You also should be "Checking" how accurate your original analyses of the business and risks are. Then you "Act" to revise them appropriately.

But almost none of this is very explicit in the standard. Especially to those who used to the world of checklists and to-dos, and have a tough time with deep business analysis and strategic planning. But that is where the real value lies. My problem is that if you know how to plan your infosec well, what do you need the standard for? The ISO implementation guides do help a little (at an extra cost), but the hard stuff is to be found elsewhere.The rest of ISO 27k just defines the paperwork format that is certifiable to the standard.

TLDR; If you understand IT strategy and analysis, you probably don't need the standard except for certification. If you don't, the standard isn't enough to help you.

Security Douchanomics

2010-12-27T14:18:00.000-08:00

Hopefully this decade will be the last of prevalent Security Douchanomics. What do mean by Security Douchanomics? It is the shortcutting of the hard work of security economics (analysis of data, discussion, trade-offs) and instead using the infosec bully pulpit to cram a simplistic reason down everyone's throat to ensure compliance. While this strategy can work in the short-term, it is we in the infosec industry who must suffer the long-term degradation of authority and respect because this doucherie. Worse, Security Douchanomics can foster adversarial relationships between security teams and the rest of the business. The pronouncements seem inflated or unrealistic, the business pushes back, and everybody loses.

Some, like hyper-FUDding to sell security (koff, koff, APT) is one glaring example of Security Douchanomics. But there are more subtle, more institutionalized, more palatable douchtastic examples out there.

Specific examples:

   1. Flatly denying that some new technology as insecure without discussing nuances, trade-offs, or specific risks. (Cloud has been popular for this)

   2. Flatly declaring a technology as obsolete and insecure because it is old without discussing nuances trade-offs, or specific risks. (Windows XP has been popular for this)

   3. Flatly declaring ANY technology as "secure" or" insecure" without discussing nuances, trade-offs, or specific risks (or what "secure" means in the particular context)

   4. Arbitrarily high-risk ratings for nearly any vulnerability or audit exception found. Sometimes I think this done to make the assessors look good (see how badass I am that I found this super-s3kr1t 0-day hole that can pwnzr you?)   Of course, this makes the defenders look bad and then they usually push back leading to adversarial cycle of pain that is common to Security Douchanomics.

   5. Blindly enforcing best practices as if these one-size fits-all (and in many instances, cargo cult processes) are the answer to the entire world's security ills, regardless of cost or prove effectiveness,

   6. Using misleading/confusing graphics or statistics to convey risk metrics to a non-technical audience. My favorite is the vulnerability scan that shows huge bar graphs with counts of "low" vulnerabilities, which usually are things like "server is listening on port 80" and "Scanner has identified site running Apache." But bigger is worser, right? (see #4)

   7. Specious security reasoning. My favorite: "If a person has financial problems, they would be very motivated to steal from the company, so we can't hire anyone with bad credit checks." Uh huh, so can we please talk about implementing least privilege then?

I'm sure there are plenty I'm missing. These are just what came to my mind this morning. Feel free to add your own or comment on mine.

I'd like to think that most of the time that Security Douchanomics comes from ignorance or laziness rather than intentional misdirection. And for most of this decade, Security Douchanomics have been as effective as anything else (that is to say, pretty ineffective but it was the only tool many people had). But for whatever the causes, the end result is the same. And to those security practitioners who fall victim to Security Douchanomics instead of doing your homework: you need to set up your game and do better. We as an industry deserve better.

VB2010

2010-10-01T15:31:00.000-07:00

I just attended my first Virus Bulletin Conference. Luckily it was in Vancouver, just a few hours north of Seattle, so it was an easy drive.   This was also my first time in Vancouver (more than a few hours) and I can say that this is a very beautiful, friendly and modern city with some fantastic food. We also had a nice room with a fantastic view.

So the conference.

The keynote was by Nick Bilogorskiy of Facebook. He got into all the evil ways your FB account can be jacked and what the crooks would do with it. He got into Koobface a bit with hints that those responsible are in the cross-hairs. Graham Cluely blogged a nice summary here. Take-away: If you must use FB, make sure you use the built-in tools to warn you if your account profile is altered.

First up after the keynote in the Corporate track was Ray Pompon, who is quite the handsome and intelligent fellow. He did a fantastic job of breaking down how the FBI takes down a malware author.    He had to start late because of the keynote but he made his points well during both the talk and the Q&A.   (disclosure - I am Ray Pompon and this review might be a little biased)

Paul Boccas of Sophos got in some good PDF malware analysis and provided the perfect set up for an Adobe joke when he asked "Is there anyone from Adobe here?" with the response from the crowd "It's a security conference!"   Adobe is indeed the new "Microsoft" when it comes to being a security whipping boy. The more things change, the more they stay the same.

Websense's Don Hubbard did a fantastic job of scaring the crap out of me with his breakdown of how easily it is to juice search engine results and plant fake news with links to malicious sites.    Highly recommend reading his slides if/when they are available.

I stayed late and caught a great vendor presentation from ESET on under-reporting in the financial sector. The big problem is that banks tend to record customer stolen account fraud as "other" on the SARs. Of course banks are incentivized to point the blame finger outside their institution (and in this case, it's partially justified) but in the end, everyone loses.   For more on bank shenanigans regarding misrepresenting risk please see The Headlines for the Past Two Years.

Gunter Ollmann's talk on measuring bot-net numbers was great. TLDNR - bot-net numbers are misrepresented. Why? First, the bot-net operators themselves lie for obvious monetary reasons. Second, what is considered a bot? There are lots of categories that are not created equal. 1) Infected victims (the usual number reported) but may not have working rootlets. 2) Members - infected and root kitted but not under C&C. 3) Taskable - the subset of members under C&C but control is time or function limited. and finally 4) Fully controlled zombies.   Each category is often an order of magnitude smaller than the previous category.   There's a meta-lesson there too - never take simple numbers at face value. You need to dig deeper and understand what is being measured and how.

This led me to conclude just how generally misrepresented and misunderstood our numbers are in InfoSec.   Botnet numbers are inflated. Bank customer fraud is under-reported. Malware victims are under-reported (my talk). We security folk have a serious problem here. Not just a lack of actionable intelligence but these bad numbers just undermine our already shaky credibility with the business types. Take heart, there are solutions out there. Alex, I'm looking at you and your VERIS.

Speaking of misunderstood, there was the Symantec Stuxnet talk.   Granted, these guys did a great job of forensics reverse engineering the SCADA payload embedded in the rootkit. You've probably seen all the tweets, posts, and video from the presentation so I won't add much more. Suffice to say that it was all very exciting to have news cameras rolling and an excited crowd… only to be confused and deflated (ha) by "theoretical" demo of an attack with some bizarre speculation thrown into the mix. I wish more infosec folks would study basic intelligence analysis techniques before they attempt to speak in public about such matters.

It also gave me pause to think about Stuxnet and what it means. It is indeed a very sophisticated piece of weaponized software. This was no mere criminal malware and almost certainly the work of a (cough, cough) APT. Heck, even the United States could be the APT in this case. But what does this say about the future of malware?   Will we security folks be ducking and cleaning the blowback and friendly fire of APT's shooting high-powered malware at each other. Hey, we're all on the same Internet and it's all inter-connected. Can we at least agree to play nice at a governmental level?   KTHX

Buried in all this, there was a diamond in the rough of a talk by Safensoft on ATM malware defenses. The talk was the defensive response to the Barnaby Jack talk on Jackpotting an ATM. Turns out that ATMs are heavily used in Russian for many things, including bill payment for consumers. In Russia, ATM takes your money. This makes them more heavily used and relied upon. And of course, a lot of the ATMs are just Windows XP SP2 boxen with some ATM code running on it… and many on a network.   Based on this, it was no surprise to find that lots of Russian ATMs were "jackpotted" in 2009. So Barnaby Jack wasn't just doing bleeding-edge proof-of-concept, he was reporting "old news".    Safensoft, a traditional anti-piracy company, was forced to use a different malware defense approach because ATM hardware was too slow for the usual AV big-blacklist-of-doom approach. Instead, they went with a white-list focus with heavy integrity checking around program flow. Sounds like a road map for the future of general AV to me.

General chatting at vendor booths and with other delegates revealed an interesting new fact to me. As I'm not a deep malware guy, I did not realize just how few anti-X engines are out there. There are the big guys like Symantec, McAfee, etc and then a lot of OEM and engine-licensing going on with other companies on top of that. It does make me fear a little bit of a monoculture vulnerability but on the other hand, blacklist collection is tough, tough work.

Other conferences bonuses:
- Gratuitous use of 80's music on Hotel speakers between talks

- Lots of cool accents - Russian, Cockney, Hindi, Irish, Chinese.

- Lots of cool people attached to those accents. It was a pleasure to meet so many smart and funny geeks in the malware field from all over the world.

- Hordes of Microsofties attending - their first full year with a real AV product. Yet overall, their talks were pretty tame. One of the presenters actually did a magic trick during his talk. But it was still a psych-101 talk aimed at novice infosecers.

- The Stuxnet balloon pop / May-9-1979 press by Symantec provided rich fodder for jokes… which the Symantec folks laughed along with like good sports.

- A cool presenter gift from the VB folks

Things I hate about security reports, a rant

2010-09-21T13:27:00.000-07:00

This post is by request from @shrdlu and how I can say to no to that?

I am frequently dismayed the quality (or lack there of) in what we security professionals choose to present outside our little geeky enclave. I’ve covered some of this before when talking about pen-testing / vuln assessment.

Sadly, it hasn’t improved much. I am frequently put in the position of having to apologize for our profession’s inability to craft a document that anyone else but a security professional would consider a “business document”*. This doesn’t even cover the persuasiveness (or lack of) in most “Security recommendations”. The icing on the cake is that these documents are often the work product of consulting engagements costing tens of thousands of dollars. When someone spends thirty grand for a pen-test or a firewall recommendation, the value of the work done needs to show in the document. And I’m not talking about color glossy graphics. I’m talking about clarity, relevance and clear reasoning.

You wonder why the executives ignore us, this is one big reason.

Now, I’ll just grab a random VENDOR$ report off my desk here and get into some specifics.

Your template makes you look lazy. And the fact that you used improperly makes you look sloppy.

It’s got hooks for things that I didn’t buy yet there are orphaned headers and text in there from them. It’s an awkward one-sized-fits-all affair. Does the advice you dispense also fall into that category? I’m tempted to believe that.

Executive summaries that aren’t summaries and aren’t written for executives

Here’s how the current exec summary reads:

1.       Client hired Consultant to do job XYZ
2.       Consultant did job XYZ using generic technical process blahblahblah
3.       More detail on generic technical process blahblahblah
4.       Job XYZ was done on date ABC, the end.

Huh? What is this a summary of? The proposal? Here’s how I would expect it to read:

1.       Client hired Consultant to do job XYZ and job was performed on date ABC
2.       Consultant found MOST-HEINOUS-FINDING1 explained in 1-sentence non-technical language covering likelihood and impact (repeat as necessary) or Consultant found no significant vulnerabilities and security of Client appears to be sufficient in comparison to comparable organizations
3.       Consultant also found OTHER-FINDINGS but they aren’t that important because of low likelihood or low impact
4.       We’re not perfect and were given constraints in our testing, other vulns could be there, please plan accordingly

Chart junk

Graphics, diagrams and charts that convey almost no useful information or are so confusing that they actually detract from the report.   More common than not in technical reports. Sadly. Do yourself a favor and read some Tufte.

Technical Tables of Torpor

Trying read through most tables in reports usually causes, blurry vision, dizziness, and finally sleep. Sweet, sweet sleep. The purpose of a table in report (especially if non-techies are going to see it) is to make your reasoning clear, to invite easy comparisons or to clarify a difficult concept.   Think about what you want to convey with a table before you start slapping text and numbers into boxes.   What decisions do want the reader to make using the table? (besides being impressed with your ability to cite lots of data) Then eliminate everything else that doesn’t need to be there.

Apparently Arbitrary ratings

There are long strings of “high” attached to things like “Total risk” or “Cost to mitigate”. Executives wonder if this is canned bs (yes, it is) or was this calculated relevant to their organization in a meaningful way (likely not). This just makes us want to see how you came up with the choices. And often those details aren’t there. How did you decide that this is a “Magenta priority” and the probability is “Unlikely”. What does that mean anyway? Where are you getting your data? (out of your posterior cavity, I bet)

Frontloading reams of technical detail

Technical detail needs to be there. It falls under category of showing your work and how you came to some conclusions. But put this stuff in the back. No one wants to wade through it in the first reading of the report.   It gives me the nagging suspicion that you’re trying to impress me with your technical prowess.   Hint: Good work should not need to call attention to itself. When it tries to, I suspect it’s the opposite of good work.

Qualitative Quantitative

The security person’s trap – mixing and matching Qualitative (real numbers) and Quantitative (subjective wild guesses) . Both have their place (as long as their explained) but when their mixed together, or worse multiplied together, it just sets my teeth on edge. And it confuses anyone who looks closely at whatever is being measured is going to ask “What exactly is being measured here?” Cut it out.

Lack of examples

Whatever your doing, the more real world examples, you cite, the more credibility you gain. Screen shots, legal citations, news clippings, hacker emails, quote, whatever. Put them in the report. Cherry pick a few and put the rest in the back (again, don’t frontload).

* Before you say it, let me add that if an organization spends a bunch of money on a security report, you can bet your sweet weasel that someone in a suit and tie is going to at least look it over. So don’t go playing the “these reports aren’t meant for non-techies” card on me. In any case, I’m a techie and think these reports are terribly written. So there.

Why do I do this?

2010-05-12T15:43:00.000-07:00

I've watches this Simon Senek TED talk three times in as many days and it's given me a lot of food for thought.

He talks about the power of why, as in why do you do something. I'm not one for new agey happy talk and platitude pushing. Some of these kinds of speakers remind me of the Sphinx in Mystery Men. But this talk really got to me. It made me think about why I do what I do. Why am I in infosec? There are most days when it's a humiliating painful grind.

So far, I've come up with: I believe that most cyber-crime can be avoided.

Everything I've done in the past ten years stacks up behind this belief. I've consulted on security. I've sold security. I've lectured to infosec students and laymen alike. I've engineered . I've mentored. I even write a web comic about security.

I know there are some people in infosec because of the money, or the challenge, or even the (false sense of) power. Maybe I feel a little bit of all those things, but mostly I think that this hacking crap is far worse than it should be. And I want to do something about that.

VB 2010

2010-03-26T09:41:00.000-07:00

Presenting at VB 2010 in Vancouver. Here's the program. My talk will be on "Case study - successes and failures apprehending malware authors"

Does past behavior predict future behavior for finding vulnerabilities?

2010-02-23T10:59:00.000-08:00

I'm looking at my risk model for an application and faced with a question about whether past vulnerabilities is a relevant statistic to examine or not.

For example, say I'd found three buffer overflow weaknesses in Application X in past and had them fixed. Is the likelihood of more buffer overflow weaknesses higher, lower, or the same?

Off the top my head, the arguments are:

"Yes, more likely" - the programmers made this mistake several times already, they'll make more. This is the argument the auditors will probably make.

"No, less likely" - the programmers realized the error of their ways and removed all or most of the buffer overflow weaknesses in the entire application. This is the argument the development team will probably make.

"It depends" - Vulnerabilities are a series of independent events or this variable by itself is insufficient to determine predictability.

I'm sure someone's done some analysis in this area, probably with software bugs. Probably involve Markov chains and a lot of math.

Intuitively, I'm inclined to go with the "it depends" answer and throw this measure of my risk model, unless someone says otherwise.

Everyone else is doing a predictions blog post…

2009-12-29T14:38:00.000-08:00

I’m going to focus on the growth of semi-automated social engineering. Why? Well, first because we humans need to communicate and technology has recently exploded to facilitate this. Second, the important thing to focus in security is how things fail. Right now, things are failing (as usual) with the user. We can’t expect the user to be rational and security-minded, that’s what our job. So they are the weakest link and will continue to be exploited. Third, I approach infosec with a warfare mindset, not an engineering one. And defense engineering always follows advances in warfare. We will always be playing catch up.

Prediction One - Technology-mediated scamming of users soars past our capability to deal with it
By this I mean, I mean phishing, spearing, fake security alerts, social engineering malware. It will quickly reach the point where it will overwhelm not only our defenses but the even the context we use to describe it. There are so many attack surfaces and so little useful defenses in the hands of the average user, we’re in for a rough ride. Why will this get more prevalent? Well, because of...

Prediction Two - Better use of unclassified and "harmless" data to leverage higher access
Military wonks have been warning us about this for decades. Now we're going to see it go farther into the mainstream, especially with all the info stored in Facebook, LinkedIn, Flickr, blogs, and Twitter streams. Some of the worst stuff is being generated by our friends and family without our consent. Just ask Sir John Sawers. This will lead to...

Prediction Three - Attackers will becoming adept at exploiting unknown critical dependencies
There's dozens of these kinds of undocumented and unexpected linkages between our organizational security systems and the consumer-grade applications we all swim on a daily basis. Password resets that bounce out via email to our iPhone or Gmail accounts. Twitter links with embedded passwords that happen to match our main password. Web mail sites can be used to spread custom malware internally. They're considered low value and therefore have weak security accordingly. And what about those consumer grade systems? Well, expect...

Prediction Four - Larger attacks against "soft" targets because of items 1,2,3
Why hack Twitter, Facebook, Gmail, etc? Because that's where the money is, duh. Most of these services were designed to protect low-value assets and casual attackers. But that value is out of proportion because of the aforementioned dependencies, the value of this secondary data in escalating attacks, and the scam-value of the friend-trust relationships embedded in these systems. Which all leads to...

Prediction Five - The move of the traditional perimeter from the Untrusted Internet User to the Trusted User.
Most of the standard threat models say the normal user is somewhat trustworthy. Many say otherwise that's a bad idea. As items 1-4 become widespread, the popularly accepted models will need to evolve to simply not trusting the average user or customer in the slightest bit. For many high-risk applications, like web-banking or large e-commerce sites, we're pretty much there. Now everything will move to this level, even the common low-value / low-hanging fruit applications and services. Those of us folks who already live in that mindset, we'll be helping the rest of the world deal with the new paradigm. The standard of reasonable care will change to this new baseline and more resources will need to be expended. When will it reach that point? Probably soon. So what can we do about it?

In the near future, I see us faced with two choices: Radically alter the user experience to the point where any high-level application change (like transferring or altering valuables, changing your password or installing local software) looks like something out of a COBIT change control process (approval & authorization, separation of duties, mandatory change windows). Think "sudo" not only in our operating system, but also within our applications. We stuck a toe in the water with Vista and the users hated it. Another solution to pursue is to push more security downwards into the operational core (behavior monitoring, red flagging, white listing and application flow restrictions). Perhaps by combining these two, we can come up with something useful. I hope someone’s already working on a more intelligent warning tool that fires off meaningful alerts like “It appears that you are about to submit your credit card number to a server in Latveria whose domain was registered only two weeks ago. I think is a Phish and you should verify things before continuing.”

Those are my rough thoughts this chilly December day. I'll be thinking and working on solutions to these problems in the coming year. Let me know if you have any ideas that might help.

Ten ways to build/improve your infosec career

2009-12-22T11:24:00.000-08:00

I talk to a lot of students and folks just launching their security career. This article is for you. Veterans, feel free to chime in and tell me what I missed or did wrong. On with the list.

1. Communicate in a business positive manner.

Learn to communicate on their terms, not yours. The worst problems that occur in infosec (and in technology) are communication problems. This is because techies don't speak to their customers (the users) in the language that their customers understand. It's also important to phrase things positively and not negatively. Instead of saying - "You can't use
56 bit crypto because the traffic is sniffable and now PCI compliant" in a project meeting, say "We should use newer encryption systems as customer's will expect us to do a quality job securing their data and it will reduce our legal exposure, yet it won't cost us anything to do."

2. Discover your assets
You accomplish goals if you don't know what they are. And you can't protect your assets if you don't where or what they are. After number 1, this is the second most common mistake I see infosec people make. To get an accurate read on this, you need to the grunt work. That means scanning with tools, interviewing people, reviewing documentation and examining configurations - then cross-referencing your results.

3. Do the risk analysis
Take your asset list, map the risks to them and rate them. This is your priority list. Everything you should do should circle back to this. If you've never done a risk analysis before, there are lots of different ways to skin that cat. Here's one. Here's another. And get creative. The bad guys will get creative so remember that when you're doing your analysis.

4. Never assume
If you don't see it for yourself, you shouldn't assume it was done correctly and completely. This is what audits should be about. Assumptions have a way of coming back at you in the worst way - like the confidential data you didn't know existed that is stored on the systems you didn't know were connected to the Internet. It's safe to assume one thing - you'll never know everything.

5. Don't compromise yourself
This is more than just ethics (which is important) but also about segregation of duties and who's orders you obey. The security team should never report to the IT director. IT's mission is to use technology to fulfill the business objectives. Security's mission is to use technology to fulfill the business objectives safely. Sometimes these things overlap, sometimes not. When push comes to shove, IT will let security slide to make a deadline. There are times when security can be sublimated to the greater mission, which brings us to...

6. Remember who signs your paycheck
This is a corollary flowing from items 5 and 1. Just because the organization wants to do something risky, doesn't mean you need to be a roadblock. Your job is to provide information to the decision makers about risk. If the organization is willing to take on the risk, then your job is to make sure it can be done as safely as possible. Remember, business is about risk. And you can never be 100% secure.

7. You can outsource tactical tasks, but never your strategic thinking
I've seen a lot of organizations outsource their firewalls, their log reviews and major project implementations. Sure, if you're got a very tight set of expectations locked into the contract that you can verify on an on-going basis (see #4). I've even seen organizations hire in consultants to do things like write their entire security policy or DR plan. You can bring in consultants to help with these things, but make sure you're feeding the strategy to build upon. You need to make sure that these outsiders are creating solutions that are as flexible and intimately fitting as a pair of good jeans. I've seen organizations throw down tens of thousands of dollars for cookie cutter security documentation which might get them through an audit but doesn't provide more value than that.

8. Stock your tool chest appropriately
Hat tip to shrdlu for pointing out the Alton Brown method of choosing tools. Whenever you can, choose a multitasker over a unitasking tool. You've got a limited budget and you never know what the business guys are going to throw at you (see item 6). The best deals are for things that you can use in a variety of ways to protect yourself in lots of different ways. For me, DLP is useful as a discovery tool (see 2), an access control and even as a general awareness tool (see 3). If can't afford a dedicated virtual server sitting around waiting to guest host the latest greatest VMware security tools then at least have some burned ISOs ready to go.

9. You can break the rules when you've mastered them
Until then, implement the best practices and the PCI compliance standards. They're there for a reason. And most people are getting hacked because they're forgetting to do the simple well-known stuff. This also applies to enforcing your own rules. If you truly understand the security policy, then you'll known when you can bend it (see item 6) and when you must enforce it (item 5).

10. Network
In person, online, at conferences, locally and around the world. Meet other security people and swap war stories. You'll want the advice and you need to commiseration. I try to attend at least one national conference a year and 4 local ones. Plus my blog, the Security Twits and my Brazen Careerist network. Find a mentor and be a mentor. It's important to give and to take. Even if you don't think you have something to contribute, you do (even if it's only to share your fails). And for many of us, the problem is the opposite. Stop bragging and just shut-up-and-listen. Nobody likes a know-it-all.

Christmas Bonus Item

11. The question of specialization
If you're already not along in your career, then you will discover that the consummate security professional knows everything about security. To be worth anything, you should at least be competent with the basics like the ISC2's common body of knowledge . But at some point, you'll be tempted (either by yourself or your organization) to start specializing. If you do end up specializing, my advice is to pick a couple of specialties. Not only does it make you more layoff-proof, but it's also a lot more intellectually interesting. Some of us end up specializing in being generalists (hah), which really means we end up specializing in management because we spend more time overseeing things than actually doing things. That's fine, just get very good at all these items. Heck, if you're a Heidi fan, you'll notice that our beloved geek girl detective specializes in forensics, penetration testing (social engineering, physical security, info reconnaissance) and malware analysis.

Why do pen-tests suck?

2009-10-27T10:20:00.000-07:00

I was just listening to the Exotic Liability Podcast and once again, Chris and gang were lamenting the sorry state of pen-testing. While I've ranted before on the poor quality of the risk reporting in pen-tests, EL was lamenting the watered-down nature of most testing.

Specifically, they asked "Why are pentests so limited?" And that's true. In most external security testing (which includes both pen-testing and vulnerability scanning), there is often no intelligence gathering, no social engineeringn testing, and no physical security testing. Of course, no "cheating", like hitting DNS or business partners, either. Very often the scope of the attack is limited in both targets (only touch these assets and these IP addresses), and limited in time (you can only attack us during this timeframe and spend only 40 hours on the testing). Implied by these restrictions, include restrictions - no time for extensive manual testing, deep analysis, or reverse engineering.

A water-down test of your defenses means a myopic analysis of the strength of your perimeter. And remember, even in the best of the times, security testing only tells you two things: where some of the holes are and a measure of the skill of the attacker. Passing a security test never means you are secure. The more "real world" your testing, the closer you approach some kind of reasonable measure of useful information about possible holes. But why water them down?

Well, the obvious reason for the reason for these limitations is not wanting to spend a lot of money on consultants. Of course, I think this is a distractor. Having been a tester and now, one who hires testers, I can tell you a bigger reason is not wanting the liability. Consider, most testing that is going on right now is because of compliance. PCI requires vulnerability scanning. Most organizations acting as custodians for other organization's data are beholden to demonstrate "best practices" - and that includes pen-testing. And here's the real rub - many auditors and customers want to see the results of those security tests.

As a tester, I've also been told by very large e-tailers that they were limiting the scope of our engagement not because they knew we wouldn't find anything, but because they knew we would. They knew we would find too many security issues for them to feasibly fix without going out of business. And if they had a report of all those holes, well, now they're liable for fixing them.

So what's a poor organization to do? They need to hire someone to do security testing that has a strong reputation but at the same time, won't do too good a job. Credibility but not competence. Or barring lack of competence, someone who will sell them a testing service that is so cookie cutter that the scope will be automatically limited to the basic scan-and-patch kind of findings. Enter the big organizations, like Veri zon Cyb ertrust, I BM, Hac kerSafe, etc. Yes, there is some collusion there. But hey, it's all about staying in business and meeting unreal expectations. After all, most people don't actually want to pay to have their data protected. At least pay what it would really cost.

BTW, you can lather, rinse, repeat this post for entire financial audit industry. See Enron, WorldCom, Lehman Brothers, WaMu, etc.

The art and science of infosec

2009-10-26T14:24:00.000-07:00

"The art of war and the science of war are not coequal. The art of war is clearly the most important. It's science in support of the art. Any time that science leads in your ability to think about and make war, I believe you're headed down a dangerous path. "
Lieutenant General Paul K. Van Riper

I think it's no different in infosec, especially in the senior decision-maker roles.Sure, there are cool technology to learn, awesome risk analysis models to study, complex financial calculations to crunch, but in the end, these are but tools for the practicioner, not ends in of themselves. Just because a some report said some risk should be rated high, doesn't mean it should be taken at face value. Nor should any defense be considered adequate for any length of time.

Too many security folk, especially consultants and auditors, seem to fall into the trap of having the science drive their work more than the art. I think there is a tendency to do this since many of us infosec folks started off in engineering. And yeah, in theory, engineering should be tamed by mathematics and science. But security, especially defense, has a huge human element. And this is where the art is necessary.

Optimizing specific defenses with statistical analysis is useful, but remember that attacks evolve. By the time you perfect a defensive technique, it'll be obsolete. For an example, read up on the history of the invincible Fort Pulaski.

But, it's still better than the cargo cult science of best practices in security.

What skills are useful in the art? Obviously experience and people skills. But to be more specific... well, off the top of my head: Good threat modelling (with a healthy dose of game theory), Logistics, Behaviorial Economics, Theory of Mind, what my boss calls "BS detection", Projecting integrity (not tripping other people's BS detectors), conviction and courage.

NCA Security & Technology Conference '09

2009-09-04T14:54:00.000-07:00

I'll be enpaneling at the NCA Security & Technology Conference '09

The subject is DLP, Risk and Compliance.

Been plenty busy lately, but hopefully I'll have one or two intelligent things to say.

Toorcamp Top Ten Things

2009-07-04T21:26:00.000-07:00

I was very proud to both attend and be given the privilege of speaking at the inaugural hacker camp for the USA. I'm sure in years to come, Toorcamp will only grow bigger and bigger. I know there were a lot of logistical problems, but I think the staff battled with them brilliantly.

Here are my top ten moments, in no particular order:

The raising of the pirate mast at HBL.
Meeting lots of cool people and their cool vehicles.
Finally meeting Leigh F2F. She's even more interesting and intelligent in person. My only disappointment was her hair was a normal hue (job hunting, she said). No matter her hair, I know she'll soon land in a great job.
Touring the missile silo!
Mudsplatter's drunken talk on messing with people's heads. Worthy of the best stand up comedy, and despite my best efforts, I learned something.
Willow's ignite talk on parkour. It met my criteria of learning something unexpectedly new and interesting. I also found elements of parkour similar to what I'd learned when I studied Aikido.
Giving my talk and having it pretty well received.
Levitate.com and their silly publicity antics, including that emo concert which I'm sorry I missed (not).
The friendliness, intelligence, and creativity of all the folks who were gracious enough to share their booze and time with me.
Finally getting home and washing off all the cursed ash.

What went wrong?

2009-06-26T09:49:00.000-07:00

Another day, another breach notice in the mail. This one to my wife yesterday.

What I want to know is:

What merchant breached the data?
How many other cards were breached?
How long after the breached was this detected?
How was this detected?
How long before the lapse that allowed this breach is fixed?

What are the odds that calling the 1-800 number will give us these answers?

IT Infrastructure Threat Modeling Guide.

2009-06-16T13:35:00.000-07:00

Russ Mcree (now at Microsoft) has just released the official 1.0 version of the IT Infrastructure Threat Modeling Guide.

I contributed a teeny tiny little bit of reviewage to this when it was in beta, and I have to say, it looked real good. A nice first jab at the problem of looking at whole of your infrastructure risk-wise. At the time, I was already using a similar model at work, but I'm definitely going to be adding this model to the mix.

It's worth a read.

PS: Russ is a great guy and totally open to feedback. If you've got something intelligent and useful to say about the model, please do speak up.

Toorcamp

2009-05-28T14:22:00.000-07:00

I'll be presenting at ToorCamp this July. I've chosen to speak on something I've never publicly talked about before, tho I've been talking a lot about it behind closed doors for a while. It's not a new idea, but I think it's an idea that worth looking at. I call it "The IED defense", but it's really about using deception and counter-intel to trip up intruders.

The coolest part is I'll be speaking here:

Losing your infosec innocence

2009-05-12T11:43:00.000-07:00

A lot of people talk about how cool my job must be and really want to get into the security field. Well, not that I blame them, but there are parts of this job that are really tough. And it's usually the thorny emotional painful stuff that's the toughest.

A good part of the job is keeping secrets, because as the security officer, you're privy to a lot of behind the scenes info. Often painful info, like who's under investigation, who's about to get fired, or what huge horrible screw up is being whitewashed over. And no, we can never ever talk about that kind of thing, so it sits inside of you and stews.

Then there's the especially nasty stuff, like doing forensics and analysis on what people might have thought was private. Then you uncover a lot of icky personal private details - things you warned them not to put on corporate systems (assuming you have a solid acceptable usage policy). I'm not just talking about reading emails between husband and wife at home (cuz that's happened too), but graphic sexual messages between two co-workers having an affair. The kind of stuff that makes you feel like taking a shower afterwards. And because it's not directly part of your investigation, you may delete it and move on - hopefully pretending you never saw it to begin with. At least on two occasions in my life, I've had to do digital forensics on computers owned by recently deceased friends. A lot of this kind of baggage, I pour back into the Heidi stories.

Now, no time is worse than your first time. How did I lose my infosec innocence? Although I've been in security off and on for about 20 years, and having it directly in my job title for the past eleven, I really lost my security innocence about ten years ago. I won't got into details (because you never can), but the upshot was I developed a specialized tool (now it's a standard product) that detected installs of inappropriate software on workstations. Inappropriate doesn't mean games or pr0n, I mean hacking tools and such. My tool fingered someone a co-worker. We weren’t close friends, but someone I liked and was part of the gang who went drinking after work. It was someone who I found interesting and pleasant to work with. But also someone who really shouldn't be loading that kind of software, especially in the type of secure environment we ran.

Now, I'd been involved in firings before - hard to be in IT any length of time and not be directly in the loop as someone is marched out the door. But in this case, I had to be the policeman and the prosecutor for the case. I had to present my evidence to his boss, interview his co-workers (who I also knew) and then discuss the matter with internal audit and outside counsel. Then it was left to me to damn him and advise my superiors that he be terminated immediately. They tool it a step further and called a company meeting to discuss what had happened and why this sort of thing would not be tolerated. It was totally the correct thing to do from a security perspective and the best thing for policy and morale. But I still felt like a rat. And I still feel like a rat.

This is a hard job and a lot of what's tough about it, they don't teach you in a classroom.

Pay attention

2009-04-29T15:10:00.000-07:00

The recent Verizon Breach Report hammers home once again is that people are still not taking the basic, known steps to secure their systems.

Why?

I'm not sure what the cognitive breakdown is. Perhaps it's the human mind's tendency to be attracted to the new and different while ignoring the routine. My own experience in security work mirrors this. Whenever a new security initiative drops down from on high, for the first month or two, I see staff scurry about implementing the controls and following policy. Then after the shine wears off, an interesting phenomenon happens. It's not that they forget about security. In fact, they are still fixated on it. I hear things like "Well, we can't do Project XYZ. How would that affect our security?" "Oh, if you're going to build a new server, then we need to make sure it's in line with security plans." Being sarcastic or not, at least they're thinking about security. But I suspect it's not all sarcastic. I often see very long detailed project plans about how to secure some new esoteric service - often with meticulous lockdown steps enumerated for even the most unlikeliest of attacks.

But of course, a quick check of basic processes finds that the same people who are bringing up security for every new initiative or system change are also getting sloppy with the daily routine things they're supposed to be doing. They're making extraneous firewall changes; they're using weak passwords; they're not patching; they're turning off logging to fix something and leaving them off; Oh, and they don't notice that because they're not reviewing logs either. They're busy and they'll get to all these things when they can. And then they forget.

The solution is often to install a massive administrative and technical compliance infrastructure to double-check everything that everyone is supposed to be doing. Assume the breach, even for the internal processes. Costly in time and money, but sometimes unavoidable.

Write clear risk assessments

2009-04-02T10:20:00.000-07:00

The conclusion of our analysis shows that the data does not contain anything we can not share with this particular third-party.

?

Remember Orwell's advice about double negation

"One can cure oneself of the not un-formation by memorizing this sentence: A not unblack dog was chasing a not unsmall rabbit across a not ungreen field."

Mapping the Unknown Unknowns

2009-03-20T13:53:00.000-07:00

There comes a time in an InfoSec professional’s career when they’re forced to do a risk assessment. I know, they’re a big pain in the butt and no one ever reads them, but some people seem to think they’re kind of important¹. I say if you’re going to do it, you might as well get some use of the thing.

First of all, I’m not going to explain some formal risk assessment methodology. There are far too many out other sources out there for that. What I am going to talk about is the general stance you bring to an analysis. As the poet Rumsfeld said, how do we deal with the unknown unknowns. This is where your prejudices can color an analysis and you could miss something important. Hopefully by better defining the known unknowns, we can shrink the size of the unknown unknowns. Here’s where I start:

Who is qualified to be working on this?
1. You? Do you really understand what is going on here? Were you paying careful attention to what was presented? One way to check yourself is paraphrase things back. Seriously, I can’t tell you how many times I’ve starting solving the wrong problem simply because I misunderstood what I was being told.

2. Are the people giving you data qualified to give you what they’re giving you? Nothing seems complicated to the person who don’t know what they’re is talking about.

How are people involved?
1. Generally, the more people are involved, the greater the chance of error. And hastily implemented automation can magnify that.

2. Will people have the opportunity to take reckless actions? Recklessness boils down to knowing what a reasonable person should have done, knowing the possible outcomes but going ahead and then doing the dangerous thing anyway. I’m willing to say this is somewhat uncommon in infosec because people rarely understand what a reasonable person should be doing, or the real probability of a bad outcome.

3. Speaking of reckless, how can someone’s personal misjudgment compromise the entire operation? For example, one guy surfing porn could bring down a costly lawsuit. You need to be aware if those kinds of situations exist in whatever your examining.

4. Can you truly say you understand all of the user’s intentions, all of the time? Unless you’re Professor Charles Xavier, this is another unknown that should be considered.

How is technology involved?
1. Software will always be buggy; hardware will always eventually fail; and operational and project emergencies will always occur. What happens when it does?

2. If you’ve got a track record of the technology involved, it’s helpful to look not just at the failures but the “near misses”. How many close calls were there with that tech and what could have happened if it had gone pear-shaped? Just because it worked up to now, doesn’t mean it will keep working.

3. How polluted is the technology? Is it well-maintained and well-understood? What are the dependant linkages? How many moving parts, software or hardware? How resilient is the system to delays or failures? How many outside parties have their fingers in the system? Are you sure you’re aware of all the outside parties and linkages?

Some specific known unknowns about technology
1. The systems you don’t know about
2. The data that you didn’t know existed
3. The systems storing data that shouldn’t be on that system
4. The connections you don’t know about
5. The services on those systems that you don’t know about
6. The accounts, privileges or firewall rules that you don’t know about

Conclusions
These are all things that you will need to account for when you’re doing a risk analysis and filling out those worksheets or forms. And hopefully the solution deals with these things in one way or another – if nothing else at least accepting the risk that these things exist and crossing your fingers.

All of this stuff can take a while to keep in your head, but I’ve extracted a few insights from this process to keep me on track:

o It will not always be obvious which technologies or processes are relevant to the security of a system. Follow the money (or data, or control).

o It is difficult to maintain a secure, operational system in a changing environment. Assume things will get broken and be prepared to deal.

o Listen to complaints. Make sure there is a way for complaints to get to you, from both the people and the systems. Even if the complaints are wrong, they’re complaining for reason. Figure out the reason.

o There will always be people in positions of trust who can hurt you occasionally

o Security policies should allow for workarounds

o Workarounds will create vulnerabilities

o There will always be residual risks

o Assume everything is insecure until proved otherwise (see name of blog)

¹ Okay, I’m kidding and you know it. You can probably get through your entire career without doing risk assessments. Just keep buying firewalls and hope for the best.

Build vs Buy - the auditor's perspective

2009-03-18T14:10:00.001-07:00

Sat through a comprehensive demo of IBM's Tivoli Compliance Insight Manager. Overall, the product is another SEIM, which means it aggregates logs from a wide variety of servers and lets you write queries against data. In short, if your servers are configured to see something and log it, then you can alert and report on it. That's all well and good.

Here's my problem - My requirements include pretty tight change control oversight. I need to be able to confidently tell auditors that I am aware all of unauthorized changes to my systems. Now here's where the rubber meets the road: our team developed a customized change control monitoring system that's part log scraper, part file watcher (ala Tripwire) with some dashes of config dumping-&-diffing. It's laser-focused to our environment, our apps, and the types of work (and mistakes) our Operations team does. It produces a daily report that's mostly readable that gives me a very accurate answer to the question "what changed yesterday". Even when the system has problems, the data is still captured and flags about the errors are usually thrown.

But, and this is a big BUT -when auditors see the report and see that we developed this system in-house the suddenly become very inquisitive. "Oh, it's home-grown. Well, we need to test it." It's not trustworthy. Every piece of the system is in question. Okay, that's understandable and we do our best to deal.

However, if I were to buy this IBM system (or any professional system), would the auditors feel the same way? One would hope they would have some doubts about how the system was implemented and how accurately it monitors. So far in my overview of vendor landscape of these types of products, I've found no particular product has the monitoring coverage we need. So if I were to buy a single system (and I really could only afford a single system of this magnitude), I know for a fact that I'll be missing about 20% of the changes being made on my network.

What I wonder is this: what is the real value of one of these professional change management tools? I suspect it's the trustworthiness of the brand name. I know I've been through this argument before with open-source homemade firewalls versus professional products, but at least the products go through some kind of testing (Common criteria, ICSA, etc). Moreover, that still doesn't address the concept of "best fit.” We all know that in-house works better (but can be more costly to maintain) than COTS products.

For the matter of change control, I felt that best-fit was more important since I needed (according to the auditors) to be able to confidently assert that I was aware of all changes. If I bought something off the shelf, I wouldn't be able to assert that (they're only catching 80%). I could buy something and then implement some homegrown stuff for the remaining 20%, but frankly, the effort on our part is about the same as just writing the whole thing ourselves. Plus we have the added bonus of being to adapt to infrastructure changes better than a canned product.

I wonder how many auditors out there will see the product with it's fancy dashboards and professional reports and go check the box "monitoring - compliant" and never question how well the system fits the environment? I bet a whole lot more than those who will needle me relentlessly on the effectiveness of our internally-developed system. So the real question becomes: is the cost of a canned product worth the cost of making the dimmer auditors leave me alone?

Snappy answers to vendor bullwash.

2009-03-03T11:46:00.000-08:00

I hate dealing with slippery vendors, especially the ones will be handling our confidential data. Here's some snappy answers to their weasely questions.

Q1) "No one has ever asked these questions before."

A1) "Either you're not been as clear to me as you've been with others or no one else has been as thorough in their investigations as we are. Now can you please answer the question?"

Q2) "Look, BIG-COMPANY-NAME does business with us and they don't have any problems, so why do you?"

A2) See A1

Q3) "Why are you asking for that? Legally, we're only obligated to do half of that."

A3) "Because my requirements exceed that of the general compliance requirements and fall into tighter compliance requirements such as HIPAA, PCI, etc."

Q4) "Sure, we do that all the time. But look, we can't modify our agreements to show that. It's too much legal overhead, especially we use the same contract for everyone. But I promise, we'll actually do that."

A4) "How about we don't sign any agreement at all. But don't worry, we promise to pay you on time."

Q5) "Here is our SAS-70 management report. And we get quarterly pen-tests too. Aren't we great?"

A5) "I'm very impressed by all your certifications and audits. Can I see the actual reports instead of just the executive tear-off? Can I share the reports with my external auditors?"

Q6) "Oh, we don't have any third-party risk management practices simply because we don't use any third-parties. Why would we trust a third-party ever?"

A6) "Who cleans your offices? Do you run your own Internet and phone cables? Do you manufacture all your own software and hardware?"

Q7) "Oh that item in the agreement? That's just in there because the legal made us put it in. We've never had invoke that."

A7) "If it's not going to be invoked, then remove it. Otherwise my legal will insist that we treat that requirement as if it will be invoked. So we need to clarify what is going here a lot more."

That's all I could come up with off the top of my head. I'm sure I'm missing some classics. Feel free to leave your own snappy answers in the comments.

Give me something useful

2009-01-02T14:05:00.000-08:00

Sadly, I agree a lot with what Alex Payne blogged:

Much of the tech world is obsessed with engaging in macho pissing contests, but no part more so than computer security. In the case of yesterday’s announcement, the researchers in question were more concerned with their ability to present their findings at a popular hacker conference than with guaranteeing the safety of the Internet.

While presenting data on new threats and vulnerabilities is useful in the security world, it's just not very useful to me. For the majority of us security folks, we're heads down in our cubicles every day desperately trying to swim upstream of the the new vulnerabilities, the new projects that break the organization's security model, the treadmill of compliance obligations, and educating the unwilling or unmotivated. The last thing I need is to hear more FUD. And yes, most of these big announcements were based on things I always assumed were weak to begin with (reread the title of this blog). Yeah, I blogged about this quite a while ago, but it bears repeating.

What do I want to hear about? Well, since security != operations, we often have to come up with security band aids to slap over the operational heaps-o-junk (75% of my job is doing this), so how about some ideas for tools or techniques that fix this. Specifically:

How about a comprehensive method of determining technical vulnerabilities across all my infrastructure. And the method needs to accommodate an aging, wide-spread Katamari ball of stuff comprised of a variety of Windows (2k,2k3,Xp,Vista), Linux (RH3-5,Ubuntu,Centos), a handful of Macs, and a variety of network devices (Cisco, Netgear, F5).

And maybe patch/versioning in that fluid , heterogeneous environment.

Or, maybe a just repeatable method for detecting and tracking critical information within the Enterprise.

It'd be really cool to be able to enable users to have the data they are authorized to access on any host, any time, from anywhere.

Oh, and if you're going to sell me a tool, I'm not going to pay more than $25 per user per annum per problem solved and 1 hour of work per week per 100 users. I've had lots of solutions pitched to me that solve just one problem like change management, yet cost on the order $1k per user. Get serious. Open source tools, you can convert the money to time spent installing and customizing, cuz my time is money, ya know.

Visibility

2008-12-03T20:05:00.000-08:00

How many security people have had near total visibility into their critical regions of their networks?

For a decent-sized enterprise trying to show a profit, this is a difficult challenge.

Well, with a very large deployment of Snare agents, syslog streams off firewalls and authentication servers, some scripting magic, and a ton of backend AWK processing... I'm getting near total visibility.

And lemme tell ya... it is a frightening thing.

What is good pen-testing?

2008-11-04T13:13:00.001-08:00

Over my last couple of decades in InfoSec, I've been both a consumer and a provider of pen-tests. As a consumer, I've seen quite a few tests that I've simply thrown back in the face of the consultant requesting a do-over, mostly because the data was so inaccurate that it was unusable. I'm writing this to raise the bar on what is being offered. And rather than curse the lameness, I'm lighting a candle.

Wait, what do I mean by pen-test? Well, I'm lumping a wide spectrum into this post. So when I say pen-testing, assume I could also mean vulnerability testing/scanning, perimeter scanning, web app vulnerability analysis. For me, it all falls into the bucket of technical risk analysis. Some tests are done for certification purposes (PCI, Cybertrust), but I'm talking about actual value. And that's, providing a technical risk analysis.

Let me decompose this technical risk analysis business. A risk analysis requires several pieces, namely: 1) asset identification, 2) threat analysis, 3) vulnerability analysis, 4) impact analysis and, 5) control effectiveness analysis. Most pen-testers deliver a vulnerability analysis. Good testers do the threat analysis and ask for the asset identification before they start. The best spend a lot of time upfront to help figure out potential impacts and do a decent job on control effectiveness analysis. And yes, this means you should spend a bunch of time talking and analyzing before doing. Trust me, it pays off.

Of course, it's worthy assumption that an external pen-tester will get some of these things wrong. Either their guesses about impacts to an organization ("hey, we don't rely on that service so who cares if it's DOSed") or more likely the vulnerability assessment itself. Specifically, many pen-testers run scanning tools, jam the results into a report and call it done. Well, a lotta scanning tools do basic banner grabs on listening services and assume from there. A good pen-test report always shows its work. When I was a consultant, what I often wrote in my reports was something along the lines of "We initiated an TCP connect on port 5678 to IP address XYZ and sent along a packet stream MNOP and got back result ABC. This matches vulnerability #123. We verified by doing PQR and then reviewed JKL, which leads us to believe this is a high-risk root compromise vulnerability." And of course, by showing your work, the client can reproduce your results and test later to see if the hole is closed. Bonus points for including source code for scripts in the report to facilitate easy test duplication. If you can't be accurate, at least be transparent. And if you're extremely inaccurate, the act of writing up the assumptions should be a red flag for you.

All good pen-test reports will be shared everywhere by the client. Sometimes they will go to the client's clients and almost always they will go up the management chain. Keep this in mind when you are writing the analysis. Don't be glib, don't hide your assumptions, provide concrete proof, and don't ever assign blame. Contrary to what your Eighth Grade English teacher told you, passive voice is your friend. "This server was found to contain a database dump full of social security numbers. I have no idea how it got there and who fcked up, but this what we found on this day at this time using this tool. Oh, and here's a screenshot to prove that I'm not lying."

Also, you need to include an executive overview. Not only is this the shortest part of the report, usually 3-4 paragraphs, but it is also the hardest to write. I usually follow the BLUF method when writing these: Bottom Line Up Front. Open with a "we did a scan on this date/time against these assets. We found one serious vulnerability, which we alerted staff about during the test and it was immediately corrected." - Hint: make the client look good whenever the opportunity presents itself. These people sign your checks. Continuing - "We also found several other low risks..." Then the next paragraph summarizes those risks in as plain language as you can possibly can - be sure to speak of likelihood of exploit and potential business impacts. Executives will only read the summary, yet will be making a decision to spend money based on it (possible spending money to hire you to fix them or scan more later). Be concise and remember your audience. I usually spend 6-8 hours writing the summary, and spend the entire engagement thinking about what will go into it.

If there is a compliance requirement (and bingo, there almost always is), there should be a separate section highlighting the gaps found there as well. Usually a client considers this a high-priority (we need to pass PCI!) but I've found the compliance junk provides the least value. Heck, the reason pen-testing is in most compliance requirement lists is so that a good technical risk analysis is done regularly. But anyway, it is usually a requirement, so there you go. And if it's a key requirement, then the results here should also bubble up to the top of the executive overview - "Blomo corp. appears to be 95% compliant with RHINO rules with the exception of the weak password on the mail server."

Okay, I've ranted enough. I just wanted to pop off my experiences and wants regarding pen-testing. Who knows, maybe in a few years I'll go back into consulting and do these again. Until then, I'll just keep rewarding the competent professionals with more business and keep shunning the lamers.

Thought experiment

2008-09-10T22:29:00.000-07:00

Economists say, incentives matter.

Here's a thought experiment -

What if we did away with all the security regulations and rules. No more GLBA security rules, no more HIPAA privacy, etc. And for contracts and b2b relationships, no more SAS-70's, no more PCI, no more ISO certifications.

Just one new rule - each person who's confidential information is breached gets a cash settlement. For example, your credit card ended up with some hackers. Here's $250. And if we didn't warn you or tried to cover it and you later found about it the hard way... well, now we gotta pay you $2500.

That's it. Let each organization figure out how to secure themselves and what the trade-offs are. Next step in my hypothetical world - organizations would need to post bonds or have insurance to make sure they can pay people off when breached. And then the insurance companies will come up with criteria for good controls. And with all the payoffs, they'll be able to build actuarial tables to see what works, what doesn't.

Hmmm.

Compromised integrity

2008-08-27T12:03:00.000-07:00

Two words we often use in InfoSec... compromise and integrity. But their origins outside of technology are of interest to me today.

Specifically,

Compromise - To expose or make liable to danger, suspicion, or disrepute.

and

Integrity - Steadfast adherence to a strict moral or ethical code.

What do I mean by this? I mean asking yourself how what these things mean to you as a member of a community (substitute nation, organization, company, family).

In the tech world, when a machine gets compromised, there is often a battle between the security team and... well, everyone else. Security says, once it's compromised it can't be trusted again - reformat and rebuild from scratch. The techs often say "that'll take hours" or worse, "that'll take days" and of course, it's a critical system. Management agrees, after all, it's going to cost us money to take those services down. And no, there are no hot spares or quick reloads available. In the end, the risk is made clear and the machines are replaced.

But what happens when the human soul's integrity is compromised? Many security folks have been a part of internal investigations. Often evidence isn't entirely clear how much an insider may be compromised. Did they make a one-time mistake? Or are they actually malicious? Again, the security folks often recommend termination and replacement. Again, there is often some (but not nearly as much) push back - especially if that person is critical to the organization.

Those who read Geek Girl Detective know how devastating it can be to a company when someone in an important position becomes compromised. It could be the end of the organization itself. But again, is it better for an organization to implode, minimizing the damage of the compromise, or explode with a devastating shockwave of litigation?

I've been told recently that no person should be replaceable. Same is true when designing systems. However, in either case, is this always feasible? No. But it's on the table as something that should be thought about and planned for - People and computers.

What is the bare minimum we can do and still operate as a business?

2008-08-07T20:10:00.000-07:00

In her column, The Agency Insider, Linda McGlasson writes in a post GLBA and Security Avoidance Questions - Why Are We Not Surprised? about GLBA compliance.

Thee post is about her dismay when hearing "What is the bare minimum we can do and still operate as a business?" from many large banks. She goes as far as saying that hearing that is "the number one sign that there is something wrong with the approach many financial services companies are taking on GLBA."

Okay, granted on the surface, this statement does appear to be like sloppiness, cheapness, and/or general dereliction of duty.

But wait, let's unpack this:

Is she saying that banks should spend MORE than necessary on GLBA compliance?

Does spending more on GLBA compliance entail better security?

Audit checklists and industry regs usually do not always entail improved risk management. But hey, for argument's sake, let's just assume GLBA Compliance = adequate security.

Now, let's restate and clarify:

"What is the bare minimum amount of risk management we can do and still operate as a business?"

But what's wrong with adequate (or minimum amount). It's that tipping point where it becomes too costly to protect an asset than to lose it. That's risk management and just plain dollars and sense.

Okay, but what is that bare minimum? How do you know what that is?

Wouldn't knowing what the minimum amount of risk management needed imply a thorough examination of risk and the value of the protected services and assets?

So to truly make that statement, banks will have be doing some pretty darned good risk assessment.

And to choose the bare minimum, means they are making an informed decision about the tradeoff between business value and risk mitigation.

The only problem I see with all of this is banks should not be asking their auditors "what is the bare minimum I need to do?"

They should be asking their security people.

And they should be answering in a manner that makes sense to someone who's job it is to choose how money is spent for the overall good of the organization.

Can you buy security? How can you make things better?

2008-07-31T19:38:00.000-07:00

So I'd twittered a bit lately about the question of organizations "buying" security. What I really wanted to know was if an organization was taking unnecessary InfoSec risks ("insecure" in lay-man's parlance), then they could simply bypass the whole cultural change thing and just write big checks to get improve their risk management ("become secure").

I've been asking this question myself a lot lately. I've spent nearly a decade as a security consultant, trying to fix organizational security programs (both for profit and non-profits). I've also spent about that much time working inside companies as a either a network guy with security responsibilities or a pure-play security guy. In my current job, I am *the* security guy. The buck stops with me. Now, with that in mind:

When I was a security consultant, I noticed there were basically two types of customers:

The organizations that were already practicing pretty good risk management but wanted to improve
The organizations who were being forced to be "more secure"

Naturally, the first type of organization made the best kind of client. It was fun to come up with innovative solutions to push them from a B to an A. We just ate up those technically complex security challenges. And yes, we were very successful. Usually these were complex, highly-regulated organizations like hospitals, law-firms, banks and public utilities.

Now the second type of organization, the ones forced to be more secure. These are the folks who've failed an audit, experienced a breach, or have an important customer dissatisfied with their security. Many of these organizations produced online products or services, and they "simply didn't have time to worry about security."

Not surprisingly, these were often the least successful clients of my consulting career. Advice was ignored, reports were shelved, warnings were rationalized away, blame was shoveled about. And things rarely improved much beyond some cosmetic fixes. They wanted to "buy" a fix to their security problem. Sadly, a lot of money was often spent on either new hardware or expensive audit reports.

As Jerry Weinberg said "Things are the way they are, because they got that way." And that's very true in these organizations. Their risk management processes are seriously messed up. And hiring a bunch of consultants and buying a bunch of tools doesn't seem to make a dent in that.

Over time, I quickly sussed out some warning signs:

Not invented here syndrome. When given a suggestion for a new process or tool, you are often told "That won't work, we're special." Hint: the only things that should be unique should be your cash cows. Usually wasn't true for IT operations or infosec.

Ill-fitting and ignored policies. "The security policy says we can't do that. But we need to do that. So we just ignore the policy." And thus begins the precedent to ignore everything in the policy. Usually a soup-to-nuts rewrite of policy with copious re-education to regain the user's trust is needed here. Difficult to do, even more difficult to do as a consultant.

Lack of defined process and/or roles for critical things. These are the folks who are surviving because they have a lot smart people thinking on their feet. No time for docs, no time for process. We can figure out as it comes at us. Unless you don't know anything about security.

A culture of reactive fixes. Managing risk just becomes another reactive fix. After we're done patching that hole, we can get back to The Real Work. Right?

Of course, there's the obvious: evidence of breaches, failed audits, high turnover, etc

Compare this to the things I see in the organizations who are doing a decent job of managing risk:

Change management, especially for critical services and components (hat tip, Gene Kim)
A clear understanding of their environment, the risks present in that environment and an awareness of how well they're dealing with them.(hat tip, Alex Hutton)
Actually looking at their logs and understanding them.(hat tip, Anton Chuvakin)
Someone who's primary focus is security. And this person is internally credible and willing to learn more.
Reliable infrastructure. May not be the best, the fastest, the latest or the most flexible; but they know how it behaves and they know where everything is

Conversely, many of the aforementioned "obvious" signs can mislead here: places with strong security can experience breaches, failed audits and high-turnover.

But what about those broken organizations? Now we circle back to the original question? Can they buy thier way out of the hole? Not in my experience. External consultants fail... "Like trying to throwing sod down on cement and hoping it'll grow" as a colleague used to say. Heck, even hiring in good security folks and having them try to turn the ship is mighty tough. Of course, everyone says you gotta have management buy-in if you want to effect cultural change. And that's usually the cognitive disconnect you have in these kinds of organizations.

I could go into another long list of the types of executive paralysis that I've seen. It usually starts with "We really care about security, do what you gotta do." And it ends with endless trickle of dying projects that go nowhere.

Not to be all doom and gloom, but I've had some success starting to fix these kinds of organizations. But not from the outside - meaning the answer to my original question is "no", you can't "buy" security. But I've made change from the inside with slow and steady grinding away at the old culture. Gaining trust, garnering political will and slowly building up the layers of paint.

The two things that have been helpful in selling security culturally have been:improving system reliability and increasing organizational agility. Reliability is easy... that's the A of the CIA triad of security. The second is more interesting. At some point, security's just another characteristic of the overall health of operations. Organizations that are doing a poor job of managing risk are not very agile. They can't to market changes without increasing their risk exposure (usually exponentially). They can't scale very well and they can't hire/replace people. Look back at the warning signs and the positive attributes. A lot of them can tie directly to agility. And I find it ironic selling security as an agility improver when security is often cited as something that "slows us down". It's also ironic that the organizations that need agility the most (the software product and service producers), have it the least.

That's the end of my ramble. I'm going to think on this more. Feel free to comment.

Still alive

2008-07-09T22:14:00.000-07:00

Just been super busy with work, family, life, Heidi, etc.

I've got a whole bunch of stuff lined up to post... just gimmie some time.

Security speeches I'm working on

2008-06-19T09:48:00.000-07:00

From Cradle to Autopsy - the lifecycle of exploited data.
A collaborative speech with an FBI friend... actually fleshed out an outline for this talk. It'd be about an hour and cover pretty much everything in security, but in an interesting narrative fashion. I'm excited about this one.

Third Party Due Diligence
Sounds boring but really critical process to master here. A large number of breaches are coming from third parties. Throw all the new regulations and requirements (like the recent FDIC FIL-44-2008), this really needs to be done right. And as far as I've seen, most third-party audits aren't being done right. Hint: It's not a checklist of controls. And it's not blindly asking for a SAS-70 Type 2. I've got about an hour long speech mapped out in my head on do this, how to intepret SAS-70, CyberTrust, ISO 27001 reports... and roll your own proccess.

Recovering from a breach - what to do, what not to do
Title says it all. I think this is an over-looked topic. Cognitively, a lot of folks don't think about breach beyond writing an incident response plan. Remember the title of this blog. And how you recover from a breach can mean the world of difference to your organization. Short version - do it right and your company's market position will actually increase (I can show proof), do it wrong and you're toast. Might see if I can pawn this idea off on a mentor-buddy for him to present.

Aligning InfoSec to Business
A common topic but people are still doing it wrong. I wanna get to down to brass tacks and explain how to speak risk management in terms that the suits will understand. And note the title - you align infosec to business, not the other way around. Yet that is how most IT security people (and IT people in general) view their job - make the business adapt to the technology. Doesn't work so well, does it? We can do better.

So you've decided to use ISO 27000, now what?
ISO 27000 is not just a list of controls that you can throw onto a checklist. The heart of the ISMS is risk analysis & treatment and executive involvement in that process. Risk management is a radically different approach than the compliance work that many people are calling ISMS. Time to learn how to do it right.

Defining a process for quantitative analysis of data breach information
See previous post. Not my talk, but the fine researchers at UW. This one will happen. And soon.

Assuming the breach
What this blog is all about. Doing security in the mindset (dare I say paradigm) that the barbarians are already past the gate and in the courtyard. Tons of stuff to write up here. Still need to get to it!

The Breach Data Report

2008-06-17T11:48:00.000-07:00

Today I want to talk about the breach data report. No, not the
Verizon breach report, but the other one. The one you haven't seen yet.

Over the past semester, University of Washington researchers in the
iSchool Information Assurance program spent hundreds of hours analyzing breach data. This was a semester-long final project for a pretty senior group of graduate, under-graduate, and returning professional students.

Initially, the goal was to dig for nuggets of useful information in the breach data, much like the results of the Verizon study. However, the analysis quickly uncovered that most of the breach data out there is incomplete, inaccurate, or just plain incomprehensible.

How did Verizon get such accurate results? Well, according to them, they used data incidents they were involved in. Specifically, they say the data comes "directly from the casebooks of our Investigative Response team." So we know that this data is at least biased towards Verizon customers, which is interesting. I'll mention that I am a Verizon Business Security customer but I've never been involved in a breach investigation with their team. If I did have an incident, I don't know if they'd be the ones I'd call. The data they examined is probably complete for the cases involved. It's just that cases do not represent the entire range of possibilities.

Now our project, Defining a process for quantitative analysis of data breach information, cast a much wider net. And the results were startling. The students could only verify 30% of the reported breaches with high confidence. And many data sources had to be thrown out since they were so incomplete to be not useful.

The whole report is 56 pages long and covers processes for vetting, parsing, and querying breach information sources. The report isn't available yet, but soon will be. If you're in the Pacific Northwest, we will be having a special InfraGard meeting with the researchers to go over the results in detail.

Back from vacation and ready to rant!

2008-06-09T13:18:00.000-07:00

How many cases of breached privacy do you need?! How many people have to lose their identity to make it cost efficient for you people to do something about it? A million? A billion? Give us a number so we won't annoy you again until the amount of money you begin spending on lawsuits makes it more profitable for you to protect information than to leak it!

Channeling Alan Alda from And The Band Played On

A word about assumptions

2008-05-29T09:23:00.000-07:00

This morning I was reading a chapter in Jerry Weinberg’s
Becoming a Technical Leader. On the chapter on innovation, he poses the following puzzle:

A man hires a worker to do seven days of work on the condition
that the worker will be paid at the end of each day.  The man  has
a seven-inch bar of gold, and the worker must be paid exactly one
inch of the gold bar each day. In paying the worker, the man
makes only two straight cuts in the bar. How did he do it?

Stop reading now if you want to try to solve this.

The story goes on to explain the solution. The man cuts his gold into three pieces of the following lengths: 1 inch, 2 inches, and 4 inches. Very clever, because the idea is that the worker can now “make change” when getting paid.

I thought for a minute about how clever this was but then dug deeper. Why didn’t I get it? This whole puzzle hinges on an assumption. An assumption that we can foist off an unusual set of requirements upon the “user” (the worker). The assumption is that the worker will retain his wages every day and have them available to make change. Therefore, the burden of making the employer pay with exact change is removed. Nice.

Now I why I didn’t think of this? Because it’s counter-intuitive of me to introduce unexpected (and possibly contract-breaking) conditions into a solution. But in a wave innovation, Mr Weinberg did. But we can’t blame him. He’s a programmer and this is the kind of stunt that programmers are wont to do.

But back to assumptions. The lesson learned is: every problem drags along a set of assumptions. Sometimes the assumptions are as simple as “the default conditions” that we take for granted. And every solution also brings along a set of assumptions. It’s always a prudent idea to keep an eye on the assumptions. You never know what they’re going to tell you about the problem and the problem solver.

The problem with our defense technology Part 2, “Advanced” technical controls

2008-05-22T16:30:00.000-07:00

The next level up from basic controls, are what I’m calling the more advanced technical controls. These are the things usually used by the organizations who’d be sued if their security was breached. Again, this is the low-water mark list. And like before, most of these security controls are overrated, overly relied upon, or implemented narrowly.

Strong authentication
Strong authentication, by which we mean two-factor, by which we usually mean carrying a token thing. These are great replacement for passwords, but that’s about it. It all gets very interesting when you use a token to authenticate to a box that has significant vulnerabilities (see patch management). And for most strong authentication systems in place, I’ve found several work-arounds implemented by the system administrators just in case we get locked out. Thus begins the whack-a-mole game with the auditors and operations staff. And don’t think strong authentication will be helpful with man-in-the-middle attacks or phishes. I’m not saying throw the baby out with the bathwater, but I just remember that strong authentication is only an upgrade for a password.

Storage encryption
If your organization hasn’t encrypted all its laptops and backup tapes, someone in IT is probably is working her butt off trying to get it done. If you’re really advanced, you’re encrypting all your database servers and anything else that’s Internet reachable. Here’s a wonderful case of doing something so we don’t look stupid. Is there a problem with cold boot ram attacks against laptop encryption keys? Sure, but the law says if someone steals a laptop and it’s encrypted, I don’t have to disclose. And yes ma’am, the database is encrypted - but the password is in a script on an even more exposed web server in the DMZ. Whatever, the auditors demand the database be encrypted, so shall it be done. In any case, it’s safest to assume the breach - if an adversary has physical access, they are going to get in eventually.

Vulnerability scanners
Take patch management and now repeat with vulnerability scanning. It goes like this: scan your machines, analyze the results, find a hole (and you always will), request that IT patch the hole, request that IT patch the hole, request that IT patch the hole, insist that IT patch the hole, raise a major fuss about IT not patching the hole, IT patches the hole. And then repeat. And this doesn’t count the zillions of false positives because your vulnerability-scanning tool is banner grabbing instead of actually testing. No, vulnerability scanning isn’t worthless. Heck, anything that gives you some visibility into your enterprise is a good thing. But it will it truly give us battle hardened servers ready to take on the deadly sploits of the Intarnetz? No, not really. And depending who you ask, more trouble than it’s worth.

Logging
The vendor’s cha-ching. This is the security information management (SIM), security event management (SEM), etc. It’s the big box o’ log data. Essentially, it’s syslog on the front, database on the back, with some basic rules in-between. If you’ve paid a decent amount of money and/or time on those rules, then you’re only trying to drink from a lawn sprinkler instead of the fire hydrant. In any case, getting useful real-time information out of your logging system is a part-time job in of itself. Now there are intelligent log analyzers out there, but usually they cost around 80K a year plus benefits. Can automation? Get serious. There is simply too much data to make a decision in a timely manner. And remember, you are facing intelligent adversaries. The most useful automated intelligence you’re going to get out of logging system is a measure of the background radiation of the worms and bots. Now, again visibility is a good thing. I use my logging system for forensic detail after suspicious events. I also use it for trending and for showing management just how dirty the Internet is. But as an actual alarm system? Only if I’m lucky. And producing actionable intelligence? Not so much.

Like I was saying the other day...

2008-05-22T09:00:00.001-07:00

Tapping a trend, or now just painfully obvious that's safe enough for anybody to say?

Antivirus is 'completely wasted money': Cisco CSO

In any case, I really didn't want to turn this into a ranty blog about all the problems with infosec. Sure enough of that to go around.

I promise to wrap up this "problem with" posts and get onto the meat of how to defend ourselves.

No Sith, Sherlock

2008-05-20T10:33:00.001-07:00

U.S. corporations massively read employee e-mail:

41% of the largest companies surveyed (those with 20,000 or more employees) reported that they employ staff to read or otherwise analyze the contents of outbound e-mail.

Yeah, yeah... this has been going on for years. Heck, when I wrote Heidi Book 1, five years ago, this was old hat.

It's funny tho, people still seemed shocked by this. Not security people, of course. Usually it's the business folk and sales-critters. Y'know, the ones with the iPhones and bluetooth headsets... just basically screaming "Please snoop away!"

These are also the same people who don't care so much about protecting corporate secrets and claim not care much about their own. Of course, they would squeal a different tune if I were to do a Powerpoint preso on the personal ickiness I've seen fly across the corporate firewalls. Talk about Hawt mail.

So yeah, the trick is to show these people the link between protecting their sticky lurid personal data traces and PII. Some of the stuff I've seen is far more damaging to some people's careers than mere identity theft.

UPDATE: Great Minds Think Alike or a different spin on the same topic.

The problem with our defense technology, part 1

2008-05-13T20:11:00.000-07:00

At best, our defensive technical controls do nothing but scrape off the chunky foam of crud floating on the surface of the Internet. At worst, they represent exercises in futility we do primarily so we don’t look stupid for not doing them. Consider the tsk-tsking that goes on if an organization gets hacked and it's revealed they don't have a adequate encryption or haven't patched some workstations. That's what I mean by stupid. Of course, if anyone gets hacked, there will be tsk-tsking anyway. Anyway, what have we got?

Basic technical controls
I am going to start with basic security technology, which represents the universal, low-water mark for security controls. Basic security tools are what everyone implements to achieve “acceptable security” because that’s what Management and the auditors expect. Usually when you want a tool that isn’t on this list, you have to fight for resources because it’s an unusual control that wasn’t budgeted for or worse, doesn’t directly satisfy an audit requirement. Many of these tools have a low entry cost, but often entail a burdensome maintenance cost. In some organizations, these maintenance burdens outweigh the defensive value of the control.

Passwords
If there’s any universal, ubiquitous security control, it’s the use of passwords. In fact, passwords are decent, cheap way to provide basic access control. Manufacturers build passwords into nearly everything, so it’s safe bet you’ll have them available to protect your systems. Where passwords veer off into something stupid we have to do is in the area of frequent password changing. The reasoning for around password changes is out of date, as on old fallacy about the time to crack a password. Gene Spafford explains it better than me, "any reasonable analysis shows that a monthly password change has little or no end impact on improving security!" Passwords can give some utility in exchange for relatively little overhead, provided you aren't mired in an audit checklist organization.

Network firewalls
In the past, the interchange most commonly heard regarding security went along the lines of: "Are you secure?" "Yes, we have a firewall." "Great to hear." Luckily, we've progressed a little beyond this, but not far. Most firewalls I examined as an auditor were configured to allow all protocols outbound to all destinations. Add to that, the numerous B2B connections, VPNs and distributed applications. Then there's the gaping holes allowing unfiltered port 80 inbound to the web servers.

When I was a kid, my family lived in Western Samoa. At the time, the local water system was pretty third world. My mom would tie a handkerchief around the kitchen water spigot. Once a day or so, she'd dump out a big lump of mud and silt, and then put on a clean hanky. After being filtered, she boiled the water so it would be safe for us to drink. That handkerchief? That's how I feel about firewalls. And people rarely boil what passes through their firewalls.

So, I'll have agree with Marcus Ranum, and the folks at the Jericho forum that firewalls are commonly over-valued as defensive tools.

Blacklisting Filters
Anti-virus, intrusion prevention, anti-spyware, web content filters... I lump all of these into the category of blacklisting filters. These types of controls are useful for fighting yesterday's battle, as they're tuned to block what we already know is evil. In the end, we know it's a losing battle. In his "Six Dumbest Ideas in Computer Security", Marcus Ranum calls this "enumerating badness." Now, I think there is some utility there for blacklisting filters. But at what cost? All of these controls require constant upkeep to be useful, usually in the form of licensed subscriptions to signature lists. These subscriptions are such moneymakers, that many security vendors practically give away their hardware just so they can sell you the subscriptions. Annual fees aside, there's the additional burden of dealing with false positives and the general computing overhead these controls demand.

Hey, raise your hand if you've ever had your AV software crash a computer? Uh huh. Now keep them up if it was a server. A vital server. Yes, my hand is raised too. But of course, you wouldn't dare run any system, much less a windows system, without anti-virus. You'd just end up looking stupid, regardless of how effective it was.

Patch Management
Best Practices force most of us to pay lip service to performing patch management. Why do I say lip service? Because organizations rarely patch every box they should be patching. Mostly by patch management, we mean we're patching workstations - smaller organizations just turn on auto-update and leave it at that. But servers? Well, probably if the server is vanilla enough. But no one is patching that Win2K box that's running the accounting system. And what about those point-of-sale systems running on some unknown flavor of Linux? Heck, what if you've got kludged together apps tied together with some integration gateway software from a company that went out of business five years ago? What about all those invisible little apps that have been installed all over the enterprise by users and departments that you don’t even know about? Are they getting patched within 30 days of release of a critical vulnerability? Bet that firewall and IPS are looking real durn good right now.

My favorite part of Best Practices is to watch the patch management zealots duke it out with the change management zealots. "We need this service pack applied to all workstations by Friday!" "No, we need to wait for the change window and only after we've regression tested the patch." (To tell the truth, I'm on the change management side, but more on that later)

Transmission encryption
Everyone knows if you see the lock on a website, it must be safe. We've been drilling that into lay people's heads for years. Yes, we need to encrypt anytime we send something over the big bad Internet. But what is the threat there really? We're encrypting something in transit for a few microseconds, a very unlikely exposure since the bad guy has to be waiting somewhere on the line to sniff the packets and read our secrets. Consider how much trouble the American government has to go thru just to snoop on our email. If the bad guy isn't at the ISP (which I'm not saying is unreasonable), then it's difficult to intercept.

Now consider this bizarre situation - you put up a web site and there is a form to put in your credit card number and hit submit. Wait, there is no lock on the site, I'd be sending the card number in the open! Oh dear. No, actually, the website has put the SSL encryption on the submission button so that only the card number gets encrypted. Of course, your browser can't show you a lock for this. Now consider the opposite - an SSL website, showing the lock and everything, where the submission button activated an unencrypted HTTP post. So now you have exactly the opposite, something that looks safe that isn't. And yes, as a web app tester, I've seen this before.

My last word on transmission encryption - I'd prefer to encrypt on my own network than on the Internet. Why? Because if someone's breached me (what was the title of this blog again?), it'd be very easy for them to be in a position to sniff all my confidential traffic. Especially the big batches of it, as things move around between database servers and document shares. So yes, if I was able to ignore the fear of looking stupid, I'd encrypt locally first before dealing with Internet encryption.

Next up: The problem with our defense technology Part 2, “Advanced” technical controls

Introduction

2008-05-13T20:10:00.000-07:00

Over a long series of posts, I plan to explore thoughts around the next generation of information security. The title of the blog comes from a discussion with the many of my InfoSec mentors, who have implored security professionals to “assume the breach” when managing their enterprise security. Eventually, all defenses are breached. What do we do then?
I’m going to start with a quick overview of the problems. Nothing original here, just a breakdown of what’s going wrong. I’m usually the first one to tired of all the curmudgeon’s tossing bricks at our glass houses of best practices. My response is along the lines of “yes, I know. But tell me how to fix it?” Well, I do intend to propose some solutions.

Why I don't go to most security conferences

2008-05-07T17:00:00.000-07:00

First, let me define security conference. By this, I mean, the conference that either has a hax0ry name or is simply an acronym. Okay, I gotta pay for a ticket, expend travel resources, and then lodging. Even if I can convince my employer to pay, I still have to burn political capital and then finagle time away from the office. TANSTAFL. So, when I see that announcement for Plopc0n 5 fly across my e-mail, I do my cost-benefit analysis and usually decide to skip it.

Why? Let's set aside the vendor hype-fests. They're too easy to bash. Besides, I can get all the vendor love I want by simply answering my constantly ringing phone.

What is at a typical security conference? Well, there's usually some forensics stuff. Cool, but that's really not my bag. And honestly, most of what speakers present as "forensics" wouldn't stand up under a halfway-technical defense attorney's cross-examination. Pass.

All right, there's a mixed bag of privacy and legal talks, which are mildly interesting, but are highly dependant on the speaker. Most of the time, the speaker's book or blog gives me the same basic information.

But what else do conferences full have? It seems that a good third of the content is "Hacking XYZ" or "New way to exploit" or some attack against physical security. BFD. I already know there are holes in my network. Most of these "new" attacks are just new variants in old attacks. Attacks that you can figure out are there just from looking at the basic design. I've read enough Ross Anderson to grok the basic idea on how things can be exploited and how they should be engineered. At best, the hacks they demonstrate are proofs of concept to something I'd already assumed I had to deal with. Thanks for that, but I don't need to attend just to see a proof of concept. I'll just grab the press release, usually released within hours of the conference demo.

I guess the biggest reason why I might be inclined to go is to network. But the last few conferences I've been to, I felt I was the only "adult" in the room. Yeah, except for a few Internet blogger friends, I'm really not compelled to spend the time away from work and family. I do hit a couple of local quarterly security conferences for the networking.

What am I interested in seeing? Radically new defensive technologies, "game changing" strategies, and thoughtful analysis of cyber-criminal operations. If I'm lucky, I'll see one or two of these kinds of pearls in several days worth of chaff. Nice, but I'm staying home for now.

BTW, if you haven't read With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988, then I suggest checking it out. I bet you get a lot more out of it than the average hacking demo.

Outline of what we're going to see

2008-05-06T11:53:00.000-07:00

1 Introduction

2 The Problem with our defense technology

3 Our Katamari infrastructure

4 The attackers - Fighting Iron Age adversaries with Bronze Age weaponry

5 Other related work

6 Can we do better with what we've got? Will we?

7 Prepare for failure

8 Changing the game by striking back

9 Changing the game with dirty tricks

10 Big New Ideas that may never fly