Friday, March 30, 2012

Segfaults

Network segmentation faults, that is- not those pesky software problems.  Penetration testers and others often say network segmentation doesn’t stop attackers, and that at best segmentation only slows them slightly. Systems and network admins often complain of needlessly complicated routing and access rules, latency, and other problems. 

What these people say is largely true and also largely wrong.  Because they are doing it wrong, and for the wrong reasons.

Network segmentation does not mean simply adding a hop between network segments to confuse and exhaust the poor little packets, and it is not just a tool for restricting traffic for controlling access.

Obviously restricting traffic and isolating access in logical network divisions by function, type, criticality, sensitivity or other reasons relevant to your environment is a logical reason to think about segmentation, but that is only the beginning.

VLAN if you must, but I like physical segregation where possible.  Especially for the most high-traffic and most sensitive segments.  I prefer to use a firewall with a lot of real ports, not one of those crappy things where most of the ports are just switch ports for the LAN.  Just make sure whatever gear you use can fling packets without adding noticeable latency.

Thankfully, broadcast storms are largely a thing of the past, but isolation can still help in diagnosing network oddities.  Not pretty or sophisticated- but sometimes disconnecting segments is the fastest way to find problems.  I can unplug a lot of patch cables (or power cords) in the time it takes to log in and poke around in most network gear (where’s the damned CAM table shown in this version of $EXPLETIVE).  Also, the switch/router/firewall interfaces are great places for packet captures when you are having one of those “the packets hate me” days.  You know, the ones where you go digging for the old taps and suck traffic right off the wire (or fiber).

Why else should you segment?  Network and systems management can be enhanced by segmentation and isolation, as can performance- patch and systems management servers, departmental servers, printers and more can be placed in the most advantageous segment of the network.  For systems which can’t be in the target segment, traffic can be restricted and directed to limit noise on the wire (or fiber, or ether, whatever).

And finally, near and dear to me lately, we have scanning and monitoring.  All your Apache servers in one segment?  Great, patch or vulnerability scans can regularly scan that segment with minimal stray results if the scans have the relevant tuning.  The great unwashed of Windows workstations?  Hammer those with scans looking for unpatched RDP or whatever the Next Big Bug is- without annoying the PostgreSQL servers over there in the DB segment.  It goes without saying that you put scanners in each segment to minimize network noise.  And not just active scanners: passive scanners, network analyzers, netflow sensors, IDS sensors, full packet capture systems, and more can benefit from segmentation and isolation of traffic.

This even applies to virtual segmentation.  Well, some of it does, and there are some virtual equivalents for some things.

 

Jack

Monday, March 12, 2012

Let’s look these gift horses in the mouth

I have a habit of tearing up the various reports and surveys that wander past my view in the world of information security.  This is often really unkind of me, because we need to share more information on what works and what doesn’t if we are going to move forward in this struggle to protect whatever it is we’re trying to protect.  Companies like Veracode, Verizon, Mandiant, Trustwave, and others put a lot of effort into sanitizing, organizing, and distributing the information they gather in their various endeavors, and they share it for free (or at least just an email address).  In a desert largely devoid of data, these reports are oases of information.

Umm al-Ma Lake - Desert Oasis, Sahara, Libya

And here I am being an ungrateful bastard, trying to x-ray the teeth of these gift horses, then complaining loudly about gingivitis, impacted molars, selection bias, confirmation bias, corporate agendas, and other things Crest™ and a good flossing will never fix.

Fotolia_1358404_XS

The problem is that a lot of the data leaves me wanting more.  More details on the data we get, just plain “more data”, and more context.  I also want more honesty about the shortcomings of the reports and data.  Let’s not even talk about some of the bizarre conclusions.  And it makes me crazy (crazier) when I see contradictions in a single report, then one report contradicts another company’s report, then year over year reports appear random rather than additive or complementary.

When you read this year’s Report X from Company Y, ask yourself how the information presented made it into that dataset.  In the case of the breach reports remember that they are about failures- organizations which were:

  1. Compromised
  2. Discovered it (probably not themselves)
  3. Called Company Y to help them solve it
  4. And could afford Company Y’s rates, and paid them

Suppose that skews things?  Yeah, me too.  Where are the success stories?

If you see me talk about any of the career studies I’m involved in you will generally hear me start talking about known flaws in the data, after the disclaimers and caveats we move into what we feel comfortable saying about what we have collected.  Of course, I’m not trying to facilitate a transfer of funds from your organization to mine, so maybe its unfair of me to expect the same from those with a financial motive.

And for closing complaints: stop with the moronic USA Today-style “infographics” which tell me less than text would.  Combine the graphics with mixed dark on light and light on dark type/background, add PDF format- and we can’t read them on anything but a large monitor (or in dead-tree mode).  Just make the reports available in epub/mobi so I can read them on my terms and not be forced to read them in the deity-forsaken PDF format these always come in.

And, thanks for doing all that work.  Just stop making me hate you for it.

 

Jack

Friday, March 9, 2012

Post BSidesSF and RSA Post

It was a great week for Security BSides.  I post semi-regular updates to the BSides Google group if you want the ongoing story, but a couple of high points:

I met with Mike Dahn and Gene Kim for a few Board meetings, we reviewed accounting, roles, 501(c)(3) filing status (which is ‘waiting for CPA to complete the audits”), how best to support BSides event organizers, and more.

We had a great conversation with folks from RSA and the RSA Conference.  We all want to minimize needless tension, and RSA was gracious.  The event organizers for BSides San Francisco will continue the conversation with RSA in the coming months.

I had some good conversations with folks from Black Hat.  This will be tricky, we have a direct overlap on dates, and a greater overlap on speakers, sponsors, and attendees than we do with RSA.  But, we’ve started talking.

And finally, planning for BSides Las Vegas 2012 moved forward through several good conversations during the week.

The RSA Conference was the RSA Conference.  It is where a lot of business of InfoSec gets done.  I thought it was better than the past few years as far as talk content.  As has been observed by many, it is not generally the place for cutting edge research, and the expo is all about selling security products.  It can be disillusioning to see the crass commercial side of our business.  The split between those who say RSA is great, and those who leave scarred and scared seems to be whether you have productive meetings during the week (and I had a lot of those this year).

Our Burnout panel went well, we filled the room on Monday afternoon.  Members of the team will be presenting at other venues including AIDE and possibly Infosec UK.  I’ll post more about the career research, as well as the burnout project, as those efforts evolve.

Amazingly my P2P session on “What Works in Log Analysis” was packed, too.  Of course, we had more questions than answers, but people have realized how much data we are missing in our own logs, and want to ease the pain of finding the goods.

All the usual vendor hype and FUD was out in full force on the Expo floor and beyond.  “Big Data” was the buzz phrase of the year, and it seemed at least as poorly defined as APT, Cyber, Cloud, and other past buzzes (even though most have real definitions to those who actually know what they are talking about).  Some glaring examples:

Ferraris and firewalls? I get the speed reference, but really…

Special dishonorable mention goes to Bit9 with the little girl in their poster- ugly scare tactics are ugly.

Good vendors blighting themselves is a recurring theme, whether it is execs telling untruths and trashing the competition, or folks showing ignorance in talks, or just general boorish behavior- there was plenty to see.  Let’s not even discuss what the bad vendors do.

Special dishonorable mention in this category goes to NetOptics, a good company with great products. I have nothing against fast cars, attractive women, or network tools- in the proper context. All three in one obnoxiously loud booth is not the proper context for any of them, especially when I just want to see the latest in traffic capture tools.  Sadly, NetOptics seems to think this is the way to present themselves at RSA, they were a bit obnoxious last year too.  There were certainly worse vendors there, but it really annoys me when good companies do bad things.  The usual fear and hype mongers are somehow easier to ignore than people tarnishing their own otherwise good image.

And yes, we are still dealing with the “booth babe” phenomenon, and NetOptics was far from the only vendor guilty of this.  I have an answer to this, but it will have to wait for Las Vegas.  It involves fishnets, short shorts, and probably eye bleach.  You’ve been warned.

Finally, thank you very much to my fellow members of the Security Bloggers Network for voting this the most entertaining security blog of the year.  It may just guilt me into writing more.  But don’t hold your breath.  (I do have a backlog of posts to write for my drunken con, er, travel blog).

Jack