By now, I’m infamous for my antiquated keyboards. At the office I use a Unisys knockoff of an IBM model M called a PCK-101-KBD. It has most of the cool features:

• Stainless steel plate
• Weighs 2 pounds
• Curly-Q cable
• PS-2 connector
• Shelf at the top for holding
• No buckling spring keys (has inferior springs, boo)
• No key caps
• No removable/replaceable cable
• Complete with strange stains and funkyness
• Came with the office (bonus!)

About once a month I get somebody who comes in and offers to replace it with a new one. We have about a bazillion keyboards sitting around and they can swap mine out for one of them when they pry my non-bendable relic out of my cold, dead fingers.

Anyway, last week I bought a “new” IBM Model M from Unicomp for home use. It came last night. I love it already, having klickety-clacked my way into the night. The bonus is that it comes with a built-in theft-prevention feature: you can beat a thief over the head with it.

But above all, I can’t help but feel that I’m slowly becoming one of the “crusty old kooks” that you meet every once in awhile. =)

• Build a Hack Bag
• Some thoughts on QA
• More Vendor Spam
• It’s Not Just for the Feds Anymore
• Keys to the Outsourcing Kingdom

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!

• Apache Killer Effects on Target
• Stress-Test Apache with Intent to Tune: BSOFH Tip for the Software Masochist
• Your Security “Requirements” are Teh Suxxorz
• 20 Critical Security Controls: Control-by-Control
• The Rise of the Slow Denial of Service

During Christmas I took 2 weeks of vacation with a blogging break at both the beginning and the end.   I’m now ready to write some more.

Ah yes, the joy of doing nothing.  I’m back to work and ready for more stories of life in the information security trenches.

So what do I do when I’m not at work harassing the engineers? This is how a Guerilla CISO spends his 2 weeks of “relative bliss”:

• Played a ton of Guild Wars (cedega on Debian)
• Hooked up my wife with a dual-core Ubuntu workstation
• Moved my wife’s mac to be a slave for fileserving and vnc sessions
• Fixed up an older laptop with Ubuntu to make it useful again
• General tech refreshes for some things: 2GB RAM upgrade, 2 new Nvidia cards
• Started a friend’s 10-year-old down the pygame road

• Stress-Test Apache with Intent to Tune: BSOFH Tip for the Software Masochist
• The Guerilla CISO
• Personnel Turnover
• Omigod, I’m Part of a Botnet?!?!?!
• It’s a Blogiversary

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.

• What the Government Looks for in a Product
• How to Not Let FISMA Become a Paperwork Exercise
• Categories of Security Controls in Outsourcing
• Cloud Computing and the Government
• Observations on SP 800-37R1

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

• FIPS and the Linux Kernel
• Et Tu, TIC?
• It’s a Blogiversary
• Hardware Woes
• Stress-Test Apache with Intent to Tune: BSOFH Tip for the Software Masochist

I recently ended up in the assessee’s chair. I’m fairly familiar with it by this time, since every project that I host or support has to be tested every year or so. Let’s just say I host auditors at least every couple of months. Only this time it’s different, let me explain.

Back in the halcyon days of 2003, I was on a Security Test and Evaluation Team traveling to a wide variety of contractor sites. We would go assess their security posture and make recommendations to the government. After that I would usually get out of the way as the two battled over the costs associated with fixes.

Now the fun thing was that my company offers some of the same services as the people that we were assessing. At some points, we had to subcontract the work to a different company where we were in direct competition for a contract. At some times we would end up having these surreal discussions where we would play “200 questions” where the answer was almost always “stuff” or something equally non-helpful.

So now for the situation I’m in: that of the business partner and competitor. For the past three weeks I’ve had people running all over my operations group learning how we do things so that they could partner with us for a big contract. And yet you wonder, deep down inside, how much are you training the people who will come “eat your lunch” later? It’s not my favorite place to be in.

Anyway, associated lessons learned from doing ST&E work:

• Nobody is completely objective.
• Conflict of interest exists, you just have to identify it and react to it.
• Paper versions of documents are OK. Electronic versions are too easy to copy verbatim.
• An assessor can say the exact things to your boss’s boss’s boss that you’ve been saying to them for years, but it suddenly carries more weight.

• Everybody Else Is Doing It So Why Can’t We?
• My Lunchtime Hobby: Collecting Badges
• How I Became the Owner of Two Rogue WiFi APs
• Blog Statistics and Search Strings
• How I Do the “FISMA Thang”