Yesterday I got a hasty call from Jon D about my server. He had checked out my blog from work and within an hour got a call from a Symantec SOC that he was looking at a web page that was part of a botnet.

So he called me.

Back 4 years ago I had set up an IRC network for a friend, including my server as one of the nodes. Over time the network died, as they do, and when I moved the server a couple of times over the course of several years, the ircd didn’t come back up.  The ircd.conf didn’t match up with the network interfaces on the box, so ircd would croak every time it tried to start up.

Well, I guess the last server move did something that the ircd did like because it came back up and stayed up.  Bah, that’s resiliency in action for you, kids.

When I got the call from Jon I knew exactly what it was.  It took about 2 minutes to ssh in,verify that there were 8 dirtballs squatting on my server, kill the ircd, and kill the line in crontab that restarts the server if/when it dies.  Problem solved, now back to playing zombie hack-n-slash games.

In an OS sense, there wasn’t a compromise or anything, just the greasies using the application like it was intended to be used, only with a different intent.

• Life Behind “The Great Big NAT in the Sky”
• Rybolov is Dead, Long Live Rybolov
• Downtime
• Turning Routers into Firewalls
• Stress-Test Apache with Intent to Tune: BSOFH Tip for the Software Masochist

I’m not Lord Nikon, but I play him at lunchtime. A guy can always pretend, can’t he?

You see, here in “occupied” Northern Virginia, we all work for either the Government, contractors, IT companies, or any combination thereof. Everywhere you go, you have a badge. Most badges have at least two things: the company name and the employee’s name. Looking at my “25 pieces of flair”, I see that you can even get my middle initial and where I work.

If all this sounds exactly like seed material for your password seed files, well then it just might be. Not really what I would call earth-shattering ‘leet skillz, but it might be enough to get a foothold if you’re targeting one company in particular–find the nearest lunch spot and look for the right logo, check the web for @targetcompany.com email addresses, note the smtp headers to see what kind of a user naming convention they use, and mung your collected names list into the right format.

Then get hacking! That’s an exercise left to the reader, just follow the golden rule and “never hack from home.”

Anyway, my little lunchtime distraction is to notice how many organizations I can see standing in line, talking on the phone, or enjoying their lowfat Atkins-friendly salad. I guess you could say it’s the CISO’s version of buzzword bingo.

But then again, I’ve always been a little bit touched, so this shouldn’t be a big surprise. =)

• Some Thoughts on Comments to My Blog…
• My Stalking Spammers
• Internet in the Remote Desert
• And in This Corner, Special Publication 800-60
• Is Myspace Satan?

No, I’m not talking about the guy at your local automotive garage co-op that signs out wrenches. What I mean is something similar to what a project manager would recognize as scope creep.

Imagine the scenario: You’re a managed service provider and have a variety of tools to do the following things:

• Monitor servers
• Monitor network devices
• Archive/review logs
• Automatically generate trouble tickets
• Manage NIDS
• Manage HIDS

And then along comes a client request out of the blue that surprises you. Say, for instance, they want to generate an automatic feed for an asset management system. It’s a great idea, but you don’t have a tool that can do it, then you end up buying something new.

Normally this is a problem for the typical IT shop. For a Managed Service Provider, it’s what will kill you.  Either you support a tool for all clients, or it becomes a one-off for that particular client, and that’s bad because then you end up with every client having their own peculiarities.

So the big question is, how do you handle tool creep?  Well, about the same way you handle engineers messing around with :

• Train your people on what you have build already and manage attrition.
• The Technical Review Board if you have one can/should do tool evaluations and selections.
• Look at plugins for the existing toolset that you have–can you get the same effect with an additional license/module or teaching a new group of people how to  use what you already have?
• Make the new tool ODC–Other Direct Charge.  IE, carry through the cost to the customer, including design and implementation.

• Being the Resident Curmudgeon
• More Vendor Spam
• Federated Vulnerability Management
• Enterprise !== Managed Service Provider
• 20 Critical Security Controls: Control-by-Control

I promised myself I would stop with the vendor bashing at least long enough to catch my breath. Well, sometimes in your life something comes along that you just can’t help but comment on.

Press release on how a network emulator can help with FISMA reporting.

This class of products is great–simulated network lag so you can test your network devices, software, etc. Every lab should have this stuff.  I’m pretty sure that some of it is inside my building in the various replicas of customer networks that the engineers use.

But what does this have to do with information security management? Once again, it’s sprinkling the magic FISMA fairy dust and wishing that it makes your product a security device.  Makes me had the”make it secure” wand (complete with star on end and ribbons) that one CISO I know of carries about just for the purpose of being able to wave it around and say “*Poof* It’s secure now.”  I figure happy thoughts are in there somewhere, but I’m just not seeing the exact mechanism.

My friends have a theory that I should start selling SOX socks and FISMA underwear. I’m not so sure about that, but I figure if it works for all these other products, it might be a massive moneymaker for me.  =)

• Do You Know What FISMA Is?
• Blog Statistics and Search Strings
• Selling Water to People in the Desert
• On Why I Blog… FUD is the Reason for the Writin’
• Digital Forensics: Who should make the keys?

Interesting news article about some of Boeing’s problems.

This is an industry problem, one that we don’t talk about too much, and the heart of it is that it’s hard to manage security in huge organizations. Sure, there is the infosec frameworks like 7799/27001, FISMA, etc. If you look at the fairly undeveloped pieces of security, you’ll notice some trends:

• At the tactical level, we know vulnerability scanning, exploit writing, and hardening standards.
• At the operational level (Army sense of operational–we’re talking brigades and divisions here), we have risk management, certification, and my favorite whipping-boy, compliance.
• At the strategic level, we have enterprise architecture, inventory management, and capital planning.

My opinion, and it’s purely opinion, is that as you progress up the ladder to strategy, there is less and less of a knowledge base and a higher rate of opportunity for charlatans. But then again, it echoes IT management in general–everybody knows how to build a fairly secure server, not a whole lot of people know how to manage IT infrastructure for 75K users.

Purely as a sidenote, ISM-Community is working to be a player in the operational and strategic area of security, I’m just trying to figure out how to get more people involved.

• Core Belief #4 — Compliance is a Dead-End
• Lousy Security Advice
• In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• Build a Security Program

I’ve been courting with VLANs again this week.

For those of you who don’t habla routing and switching, VLANs are a way to carve out a virtual switch. You can share the VLANs over different physical switches using a technique called trunking, which comes in way handy.

Technically, it makes sense to take most (all?) of your switches and trunk them into one huge-gantic, gi-normous switch then do all the work withVLANs.  This is the “cram everything (router, firewall, and port modules) into one Catalyst 6500 chassis and have a nice day” approach which Cisco will gladly sell you.

Until you start looking at the typical setup. For DMZ servers (just about everything I deal with is in a DMZ of some sort), it’s fairly standard to have a switch (or any number thereof) sliced up by VLANs for different functions and then each VLAN segregated by a firewall.

The problem with this is when you put untrusted/external and  trusted/internal network segments on the same switch and use VLANs to separate them.  Basically what you’ve done is taken a “moderately robust security architecture” and configured it so that the switch is a single point of security failure.  That is, if you misconfigure or compromise the switch, you can bypass the firewalls.

In either case, being able to conduct a successful attack depends on misconfigurations which can happen anyway with firewalls, servers, and any other equipment that you own.  The real problem is that single-point-of-failure that the switch becomes.

My personal rules for using VLANs:

• Don’t put untrusted/external and trusted/internal VLANs on the same switch.
• Putting untrusted/external and semi-trusted/DMZ VLANs on the same switch is on a case-by-case basis.
• Putting trusted/internal and semi-trusted/DMZ VLANs on the same switch is on a case-by-case basis.
• Don’t trunk VLANs across trust boundaries.  IE, don’t mix up customer switches with our own switches.

I think the key for today’s CISO is that when people bring you drawrings of what the network looks like, you should get both a logical network drawring and a physical network drawing.  The differences between the 2 might shock you.  Usually when you’re asked to approve a design, you get the former and not the latter, so the usual caveats apply.

Further reading:

• Cisco guide to VLAN Security
• Steve Rouiller’s paper on VLAN attacks

• In Response to “Cyber Security Coming to a Boil” Comments….
• My System Environment
• CISO Trick: Know the Hiding Places
• Et Tu, TIC?
• Internet in the Remote Desert