DAM Solutions, Will They Let Me Pick Up Chicks?

April 17th, 2008 by rybolov

If you're new here and would like to see more of what I'm saying, you may want to subscribe to my RSS feed or have a look at my papers and presentations page for downloads of stuff that you can share or "borrow heavily from". You also might find my guidelines for posting comments interesting, especially if you're a government employee. Thanks for visiting and happy hacking!

Sadly, kids, the answer is no.

In fact, it’s worse than that. I think that the DAM integrators the world over will be dateless for decades because the product class is the meta-definition of geekiness.

Let’s look at the skills you need to be the DAM God:

  • You have to know security better than the security people.
  • You have to know databases as well as the SOX auditors. (feel free to chortle here, mkay?)
  • You have to know networks as well as the NIDS guys.
  • You have to know servers and OSs as well as the HIDS people.

Talk about a complex system and a fringe sport filled with fur-toothed geeks such as myself….

Anyway, I’ve been in training all week and I keep thinking “How do I staff a DAM integration project with some of the junior staff?”  Answer is, you don’t–you need some fairly senior people with a wide variety of experience to make DAM products work.

Posted in Technical, What Doesn't Work | No Comments »

Selling Water to People in the Desert

April 15th, 2008 by rybolov

Some things should absolutely sell themselves. In the Mojave desert, the guy to be is the one driving the ice cream truck because everybody is happy to see you.

When it comes to the Government there is one thing that is their lifeblood: they make and trade secrets. And since 2001, every building in DC has become its own semi-autonomous nation-state with X-ray machines and armed guards.

So why is it so hard to sell Data Leakage Prevention (DLP) and Database Activity Monitoring (DAM) solutions to them? I’ve talked to vendors in both solution spaces, and they’ve found that it’s a hard sell to get product in the door.

If anybody needs DAM and DLP, it’s the Gub’mint. I try not to play this game, but if you look at the PII incidents that meet the Washington Post front page threshold, you’ll see that all of them are preventable with either DAM or DLP or both.

DAM and Leackage Prevention

Photo by Dru

My thoughts on what’s up:

  • Government purchasing lags behind the private sector. Government CPIC works on a 2-year cycle. Keeping in mind that the average life expectancy for a CISO is 2 years, this doesn’t bode well. This is also why it’s so hard to get strategic projects (*cough* redundant data center *cough*) completed.
  • If it’s not in the control catalog, it’s hard to justify buying it. It’s the double-edged sword of compliance. Unless I have all the controls in the catalog implemented, I can’t really justify anything not in the catalog, and once I have all of the catalog done, they yank my budget for somebody who doesn’t have the catalog implemented.
  • It takes approximately 2 years to get a particular technology into the catalog of controls. If the catalog (SP 800-53) is revised every year, then if NIST thinks that my technology/concept is a good idea, then I still have to wait for the next revision.
  • So if you introduce a new technology today, the earliest I could expect to have it implemented is in 4 years, 3 if you’re lucky.
  • Selling to the government is long and slow (can we say “heavy on bizdev investment”) but has a big payoff: remember that the Overall IT budget is just shy of $80Bazillionz.

The winning strategies:

  1. Partnering up with the larger integrators who can bundle your product with an existing outsourcing contract.
  2. Matching up your product description with the catalog of controls. Make it easy for the Government to select your product.
  3. Let NIST and Mitre evaluate your product. Seriously. If you’ve got game, flaunt it.
  4. Invest in BizDev expecting 4 years before you get a return.

Posted in FISMA, Technical, What Doesn't Work, What Works | No Comments »

Government-Wide Monitoring? ‘Bout Time.

April 8th, 2008 by rybolov

Good, I’m glad we’re finally doing this.

For those of you watching the other initiatives, this does have something to do with the Trusted Internet Connections initiative–if you can choke traffic down into 50 “sets of tubes” to watch, then it’s easier to watch them.

Expect to see more over the next year, the pieces are starting to fall into place.

Posted in Technical, What Works | 1 Comment »

FDCC Auditing with Nessus

February 29th, 2008 by rybolov

Great article from the Tenable blog about how to use Nessus to do FDCC auditing.  As you’ve all heard me say repeatedly, the only way to make FDCC work is to have an automated tool to check large amounts of workstations concurrently.

Nummie goodness.  Expect to see similar things from a vendor near you. =)

Posted in Technical, What Works | 1 Comment »

Government Can’t Turn on a Dime, News at 11

February 27th, 2008 by rybolov

Are we done with the Federal Desktop Core Configuration yet? Are we compliant with OMB Memo 07-11?? Have we staved off dozens of script-kiddies armed with nmap and some ’sploits they downloaded from teh Intarweb, all through hardening our desktops to the one true standard?

No? I didn’t think we would. Of course, neither did the CISOs and other security managers out there in the agencies. It’s too much too fast, and the government is too large to turn on a time. Or even a quarter, for that matter. =)

Now get ready for a blamestorm at the end of the month. By that time, all the agencies are supposed to report on their status to OMB. It’s not going to be pretty, but it’s hardly unexpected.

So why haven’t we finished this yet? Inquiring minds want to know.

Well, it all goes back to the big question of “how many directions can today’s government CISO be pulled in?” Think about it: You’ve got IPV6, HSPD-12, all the PII guidance (Memo 06-16 et al), reducing Internet connections down to 50, aligning your IT systems with the Federal Enterprise Architecture, getting your Internet connections monitored by Einstein, and the usual administrative overhead. that’s too many major initiatives all at the same time, and it’s a good way to be torn in too many directions at the same time. In government-speak, these are all what we call “unfunded mandates”, and one is bad enough to cripple your budget, much less a handful of them.

Where we’re at right now with FDCC is that the implementers are finding out what applications are broken, and we’re starting to impact operations–not being able to get the job done. Yes, this is the desired effect, it puts the pressure on the OS vendors and the application vendors, and it’s a good thing, IMO–we won’t buy your software if it doesn’t support our security model, and we’ll take our $75B IT budget with us. Suddenly, it’s the gorilla of market pressure throwing its weight around, and the BSOFH inside me likes this.

Now don’t get me wrong, I’m a big believer in FDCC (for both the Government and with a payoff for the civilian world), and I think it’s security-sound once it’s implemented, but in order for it to work, the following “infrastructure” needs to be in place:

  • An official image shared between agencies
  • Ability to buy a hardened FDCC OS as part of purchasing the hardware
  • Microsoft rolling FDCC into its standard COTS build that it offers to the rest of the world
  • Applications that are certified to run on the “one standard to rule them all” and on a list so I can pick one and know that it works
  • Security people who understand GPOs and that even though it’s a desktop configuration standard, it affects servers, too
  • An automated tool to validate technical policy compliance (there, I said it, and in this space it actually makes sense for a change)

Until you have these things, what OMB is asking for the agencies to get squeezed between a vendor who can’t ship a default-hardened OS, lazy applications vendors who won’t/can’t fix their software, and the 5+ levels of oversight that are watching over the shoulder of the average ISSO at the implementation level. In short, we’re throwing the implementers under the bus and making them do our dirty work because at the national level we have failed to build the right kind of influence over the vendors.

Gosh, it sounds like this would go so much better if we phased in FDCC along with the next tech refresh of our desktops, doesn’t it? That’s how the “sane world” would tackle something like this. Not a sermon, just a thought. =)

Posted in DISA, FISMA, NIST, Rants, Technical, What Doesn't Work, What Works | 1 Comment »

Turning Routers into Firewalls

January 15th, 2008 by rybolov

Not that anyone would find themselves in a situation like this: you have a firewall that’s actually a router and you want to fix it. Maybe it’s that you’re replacing a router with a firewall, maybe it’s that you had some doofuses who set up the firewall as a “Default Allow” in the first place.

Hey, we’re not being judgemental here at the Guerilla CISO, we’re all about fixing things. =)
So here is the process to follow:

  1. Get a logging server. Even better if you point it at something that lets you sort through the data better (Chuvakin, you can chime in with a subtle bit of log evangelizing here =) ). But hey, grep still works, the key here is that we’re logging and we can store a month’s worth of data.
  2. That “Default Allow” rule at the end of the chain? Set it to log everything that hits it. Keep it as “Allow” for the time being.
  3. Build and implement a ruleset for your core services that should be “Global” or “Enterprise-Wide”:
    • DNS
    • Active Directory
    • NTP
    • SNMP/NMS
    • Patching
    • Vulnerability Scanners
    • Identification and Authentication (TACACS, Radius, etc)
    • File Servers
    • Any Application-Specific Traffic
    • Remote Management/RDP/SSH/$foo
  4. Wait it out. A month is probably a good sample of network traffic that will show you where the obvious trends are.
  5. Review the data flows that were logged passing through the last rule. You might have to do some correlation with scan results, server inventory, or network drawrings.
  6. Add rules for the data flows that you want to keep. There might be some things here that are obviously misconfigured and you need to push them to the server and network guys to fix.
  7. Do another sample period or if you’re feeling confident/BSOFH-ish, skip it. I can hear a voice in the back of my head saying “It’s an iterative process after all…” but I’ll ignore it for the time being.
  8. Flip the last rule in the chain to “Deny”.
  9. ????
  10. Profit!

Posted in Technical, The Guerilla CISO, What Works | 4 Comments »

Server Upgrades

December 11th, 2007 by rybolov

“Paranoia” is the name of the server this blog is hosted on.  It’s a very “modest” box, probably a dinosaur at this point.   Some quick specs:

  • VA Linux (remember them?) 2240
  • 2 x PIII-650 processors
  • 1GB RAM
  • 3 x 18GB drives in a RAID-5

And yet, it does everything I want it to:  mail and web for a handful of domains.  =)

A couple of  months ago, paranoia hung on me.  A quick hardware reboot and it came back up, but I was short a processor.

So last night I swapped out processors, added a new UPS and apcupsd, and while I was physically in the same room, upgraded the kernel.

One last word of advice for older hardware and upgrades:  Check out stress, which is a program to put a load on your machine so you can test the processors, RAM, etc.

Posted in Technical, The Guerilla CISO | 2 Comments »

« Previous Entries


Visitor Geolocationing Widget: