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!

What you wanted for Christmas but didn’t get: The Zombie! board game, complete with rulebook and variations.

Bookmark to:

Your favorite phrase in zombie letters. Think of the Christmas present wrapping possibilities!

Bookmark to:

No big surprise, I’m a contractor who operates outsourced government IT systems. As a result, I get assessed and audited more than anybody else in the world (yes, hyperbole added). Anyway, I’m going to talk about what I give to my customers in the spirit of “object reuse”, it might come in handy for other people in the future.

I provide the following items to our account teams:

• Pre-sales: Document explaining how the operations group handles security that can be dropped into a proposal. This is freely-available because it doesn’t open up the cookie jar too much, and proposals to the government are available with the right requests. Modified version is included below.
• Pre-sales: Traceability matrix to delineate controls provided as part of service. This is released only to the capture/account team.  This is a work-in-progress because it’s a big bite to chew.
• Post-sales: Security controls document covering shared controls that can be dropped into a system security plan. You can get this in electronic form with a signed NDA.
• Post-sales: Addendum to Security Controls Document that describes the specifics on hybrid controls for your system.
• Post-sales: Auditor binder with all local policies and evidence for common controls. You can look but you can’t take it with you.

This is the text of the pre-sales security description, remember it’s written for a general-purpose audience:

Security of the Government IT systems and the data at the $FooCorp Operations Center requires cooperation between the Government and $FooCorp for program-specific and hybrid controls not provided by either the Government (security governance, Exhibit 53 filing) or the Operations Center (physical security, personnel security, media protection).

The hosting, monitoring, and management services provided by the state-of-the-art $FooCorp Operations Center are specially designed, configured and managed to meet the special IT security requirements of our Federal customers. The facility supports a FIPS-199 and FIPS-200 moderate control baseline and provides a common controls subset of SP 800-53 for all customers. The Data Center, NOC, and SOC have been audited numerous times by a wide variety of client agencies and their Inspectors General in support of Security Test and Evaluation, Certification and Accreditation, and annual FISMA audits.

Upon client request, $FooCorp can provide the Government with a Security Controls Document that describes the security controls, primarily physical security, in place at the Operations Center. The SCD is designed to be a “drop-in” augmentation for the customers’ system security plans. The Operations Center staff also maintains an audit binder that is for on-premises viewing by auditors, C&A staff, or security testers.

Now, taking a look at what I have, basically I’m saying the following points:

• Security controls are a joint responsibility between the Government and $FooCorp.
• I have common controls to save you time and money, you can get the full details after you hire us.
• I have many other customers that are satisfied with my controls.

What I have on my wish-list for the future:

• Being able to provide verification and validation of my common security controls. Yes, a SAS-70 properly scoped fits in here, but I don’t have the budget to make it happen and it will end up being a duplication of effort in most cases where the customer wants to do their own assessment.
• Being able to reuse evaluation results from one customer to to share with other customers. So far, I haven’t gotten any traction to do this because everybody wants to own their assessment results even though it’s a shared control.

Bookmark to:

Interesting concept: The Federal Vampire and Zombie Agency. Something makes me think it should be part of DHS.

But check out the following bits of information:
Myth: Zombies are immortal
Source: as with vampires, victims of zombie bites arise from comas, an event often misinterpreted as some sort of resurrection.
Fact: most zombies live less than a year.

I mean, who would have thunk it? Think of all the things you can find out about our favorite pest species.

Bookmark to:

“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.

Bookmark to:

OK, so it’s about as sensationalist as government news gets (but still way sedate when compared to Brit-nay news), but check out this article on reauthorization of FISMA.
Let’s do some numbers:

• Assuming a $64B IT budget for the federal government (budget request for FY 2007)
• Assuming $29B for 4 years (OK, so we conveniently clipped that out of the headline)
• That is $7.25B/year (29/4)
• That is 8.83% of the total IT budget. (64/7.25)

Now before everybody shows up outside the Capitol with their torches and pitchforks because we’re spending $29B on FISMA (which doesn’t work, and SANS will attest to it), let’s think about that number.

The 9% of the total IT budget is about right on track (some say less, some say more) with large companies. The problem is, the CBO reports don’t tell us what exactly is behind the numbers. IE, $29B could be any combination of the following:

• Direct FISMA costs such as quarterly reporting
• Semi-direct FISMA costs such as C&A, contingency planning, and risk assessments
• Direct security costs such as policy, procedures, firewalls and IDS
• Indirect security costs such as processes taking longer because you have the security layer of abstraction

If it only includes the first point, then I’m shocked but it figures that the study would only include the direct costs. If it includes points 1, 2, and 3, then it’s inline with what I think the budget should be. If it includes all 4 points, then I think it’s a little bit on the light side for a number.

Thing is, the contractors are looking at $29B and thinking it’s a huge market. The FISMA critics will look at FISMA and say it’s horribly expensive.

It’s all different sides of the same coin: does anybody really know what FISMA means?

Bookmark to:

Ok, we all know how to patrol in the woods looking for things to shoot. We’ve been doing that since the beginning of time, and really it’s ingrained nature for most people. Some people say that it’s why we developed bigger and better brains–so we could hunt more effectively.

Then the world changed. We went from being hunter-gatherers to living on farms to living in cities. And as you might expect, the amount of warfare conducted in cities has grown comparatively, from the Meistertrunk of Rothenburg in the middle ages to the burning of Atlanta during the Civil War to the Rattenkreig of Stalingrad to the mean streets of Baghdad. Truth of the matter is, nowadays cities are where the critical infrastructure is, and that’s where a modern army needs to learn how to combat and win against their enemies. In the US Army, we have a word for it: Military Operations on Urbanized Terrain, or MOUT (the department of modernization just told me that it’s now “OU” or “Urban Operations”).

One lesson from MOUT that there are many ways to kill people. Yes, you can shoot them (the good ol’ standby), but there are new ways: “anti-handling devices” (aka, booby traps and IEDs), channelization of traffic into better kill zones, better line-of-sight for snipers, ability to hide ambushes, short engagement ranges for anti-armor teams, etc.

In MOUT, you have to live with the fact that heavily barricading a building means it’s harder for the bad guys to get in and it’s also harder for you to get out if the building is on fire. It’s something to think about in the IT world where protecting against one type of attack means that you are susceptible to another attack: think dual-homing all your servers on a backup network to help with availability but meaning that if one server gets hacked, it’s a shorter path to the other servers.

Just like MOUT, there are many ways to “die” in the IT security world. Let’s see, this year it’s XSS, Ajax attacks, and USB drives. 5 years ago it was worms, virii and unpatched systems. Next year it will most likely be application vulnerabilities.

Now welcome risk management into that picture. Risk management means being able to triage the “bazillion ways to die” and come up with a list of the ones you need to fix now, the ones you need to fix over the next year, and the ones it doesn’t make sense to fix. In MOUT, it’s a question of “Do I spend the time putting in more wire and mines,” or “Do I need to work on blowing holes between rooms so I can move people and weapons internally?” or even “Which parts of the city do I rig with explosives and give away to the bad guys because they have no strategic value to me?”

Bookmark to: