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. =)

• Government Can’t Turn on a Dime, News at 11
• Our “Peace Dividend”: DISA SRR Scripts
• Sir Bruce Mentions FDCC, World Goes Nuts
• SCAP for Dummies
• A Little Story About a Tool Named #RefRef

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. =)

• SCAP for Dummies
• Some Words From a FAR
• Sir Bruce Mentions FDCC, World Goes Nuts
• Et Tu, TIC?
• Reading Between the Letters G, A, and O

I’ve been thinking about SP 800-53 lately because almost all of our efforts in the information assurance world lately are revolving around a catalog of controls concept.

Advantages that you get with a catalog of controls:

• Standardization (Important when you’re dealing with auditors)
• A minimum level of due dilligence “across the board”
• Each control can have an objective/intent, implementation guidelines, and test cases to validate effectiveness
• Easy to score (my cynical readers can retort with “auditor checklist” any time now)
• Applicable to a workforce with varying degrees of training and ability (ie, you don’t all have to have PHDs in IA)

And the dark underbelly of a catalog of controls:

• People just do the bare minimum because that’s all they get credit for
• Controls still need to be tailored by highly-educated people
• Enforces a “one size fits all” mentality which doesn’t work in the real world
• Your security is not streamlined because you’re doing extra where you don’t need it and not enough where you do need it

If you had to recreate your own catalog of controls for internal and external use, how would you go about it?  Well, this is the approach that NIST used to make 800-53:

• Collect all the control requirements from the various applicable laws (FISMA, Privacy Act, etc)
• Collect all the control requirements from other applicable standards, policies, and procedures (PPD-63, OMB Memoranda)
• Collect best practices from vendors and experienced security managers
• Consider the control requirements from comparable control catalogs (27001, PCI, A-123, etc)
• Lump all the requirements together and take the high-water mark
• Add some housekeeping controls that have been implied to bridge the current-state with the desired-state (document your security controls, perform a formal risk assessment, etc)

So far, this all makes sense and is exactly how most of us would do it, right?  NIST even did us a HUGE favor and gave us a traceability matrix in the back of the book to show us where each control requirement came from.

Except for one thing:  this is a compliance-based model, and I’ve just described how to build your own compliance framework.  No, that wasn’t my intent to prove, I realized it as I recreated the process.

We live in a risk management world where what I really need to provide effective and adequate security is a control framework based on threat, risk, and countermeasure.  A catalog of controls does the first 2 for me, and what I end up with as the security practitioner downstream is just the list of countermeasures detatched from what we’re really trying to accomplish–the intent.

So there are 2 approaches that NIST took to minimize some of the negatives of the catalog of controls approach.  The first one is that they allow you to catagorize your system (FIPS-199) and pick a level of controls.  It’s not perfect by any means, but it does that first part of tailoring the controls into large, xtra-large, and jumbonormous-sized buckets so you can choose your own level of involvement.  Sadly, though, most often this process involves the managerial equivalent of throwing darts at a dartboard with H, M, and L written on it.  Yes, it’s easy, but the best thing you can do for security in the government is to pick the right size of security helping that you’re going to eat.

The second thing that NIST gives you is the ability to tailor your controls.  If you’re not doing business impact assessments for where you undershoot and overshoot the untailored 800-53 controls, you’re doing yourself a great injustice.

However, just like the compliance-driven model that it supports, a catalog of controls is only a 75% solution.  The geek in me cringes that we would be using a rock chisel for rocket surgery, but in effect that’s what we’ve done so far as an industry.  And yes, 75% is better than 0%, but it’s still 25% short of perfection.

Will our catalog of controls be around in 5 years?  I don’t know.  There might be other ways to do what we want to do, and I’m sure a couple bright and not-so-bright people would step forward with their opinions if you asked them.  I for one would like to see 2 control catalogs:  one based on the minimum level of compliance where you do not have an option to deviate (and kept very small), and a second catalog that breaks down into threat-risk-countermeasure tuples so that I can exclude controls based on the fact that the threat and subsequent risk does not exist.

After all, that’s the point of tailoring security controls:  to answer the age-old question “How much is enough?”

• Blow-By-Blow Commentary
• An Open Letter to NIST About SP 800-30
• Opportunity Costs and the 20 Critical Security Controls
• What the Government Looks for in a Product
• Special Publication 800-53 Revision 3 Workshop

OK, the title is for hyperbole purposes, but I think that the current Government security model doesn’t work with the way we do Software as a Service (SaaS) today. =)

Karen Evans has officially thrown her hat in the ring to support Software as a Service. I agree, but I think it’s also harder to accomplish than OMB might think. I’ve said this before, but information sharing, security, and SaaS doesn’t fit into The Government Way of Doing Things ™, and that needs to get fixed.

Hurdles that the government needs to overcome for SaaS (and I guess Lines of Business as a whole):

• Personnel Security: How do I know that my user population is cleared to view the information that I’m providing, and how do I ensure that I get notification when they leave? (note: HSPD-12 in theory could fix this)
• Trustworthiness of Service Provider: How do I trust a server and/or application operated by another agency?
• Interconnectivity: Can we route SaaS traffic over the Internet or do we need to interconnect our LAN/WANs to get to the resources?
• Assurance: How do I prove to a customer agency that my solution meets their security needs without running into “Not Invented Here” problems?
• Certification and Accreditation: If this is a mission-critical system for me, how do I account for the security of it when it’s a low-impact system for the service provider? What do I do if I want the service provider to increase some of the security on the system?
• Guidance: We have OMB telling us what they want to see accomplished (which is SaaS in general) but there isn’t any formal guidance on how to do this and still stay within the bounds of our security framework.

All of the current guidance for information sharing between IT systems is based on IP connectivity between 2 LAN/WANs. The process (SP 800-47 if you want to research) breaks down like this:

• Certify and Accredit the networks of both agencies.
• Do a Risk Assessment of the connection.
• Establish a Memorandum of Understanding (manager-level, we like you, you like us, these are the rules on what you can do with our data).
• Make a “firewall sandwich with circuits betwixt” with each side owning their own firewall so if they decide they don’t want to play anymore, they can unilaterally kill the connection.
• Establish an Interconnect Agreement (technical level, routing and firewall configuration, technical POCs, etc)
• Make the connection.

Nowhere in there is anything we can use for SaaS. Believe it or not, I’ve seen well-intentioned IA analysts trying to get people to sign an interconnect agreement for an RSS feed out on a website when in all actuality, the interconnect is with the Internet and it’s your responsibility as a feed customer to sanitize the input before you do anything with it.

SP 800-95 covers web services but from a Service-Oriented Architecture (SOA) angle but doesn’t talk about the interaction between the players and processes.

Hence, the Guerilla CISO’s guide to SaaS in the government:

• Determine that you want to be a vendor for SaaS. You can be G2G or C2G.
• Pick a security baseline. I usually recommend a Moderate FIPS-199 because it will apply in most contexts.
• Build your SaaS system.
• Certify and Accredit your SaaS system.
• Provide a SaaS kit to your supported agencies containing the following information:
  • Service delivery options (interconnect or via Internet)
  • API/Service Specifications
  • System Security Plan
  • Security Test and Evaluation Report
  • Sign a Memorandum of Agreement that is basically an Acceptable Use Policy at a department level.
• Perform security upgrades at a partial cost to the supported client agency.
• Periodic client agency meetings with the service provider.

• HR 5983–DHS Now Responsible for Contractor Security
• Lines of Business, Relationships, and Trustability
• Alternative Uses for System Security Plans
• Response to “What is Information Assurance – The Video”
• Compensating Controls

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