I’m always keen for a good Onion article, this one is no different.

“For too long, hands-on, maverick CEOs have devoted their valuable time to strutting around on stage and breathlessly describing the features of their new products, in the process encouraging cults of personality that could have a detrimental long-term effect on their companies…”

• Government Pre-Election Slowdown has Started
• My 2 Obsessions this Week
• More Tollroad Follies
• Conflict
• Standard Maturity

OK, this is probably one the unknown gems that are out there in the infosec world: CSO: The Resource for Security Exectives.  If you’re a mid-career guy and looking to move up, a senior manager looking for external input, or a junior person looking for some kind of insight, this is the site to look at.
No, this wasn’t paid for.  I love these guys and I think more people need to read what they have to say… their editorial review board “gets it” or is smart enough to hire writers who do.

• An Informal Study on the Literacy Level of Security Blogs–We All Get Pwned by Amrit
• A Little Advice From Mike and Lee
• Milestones
• Cult Crossovers Into Information Security
• Got Training?

OK, this is cute.  Demotivator poster on the Aqua Teen Hunger Force Bomb Scare.  “If it’s not an American flag, it’s probably a bomb”.

• Julie Amero Backlash Reaches Mass Media
• My Stalking Spammers
• Enterprise !== Managed Service Provider
• More Vendor Craziness
• My Favorite Conspiracy Theory

Do I really need to say this?  As a government agency outsourcing some of its IT functionality, you did not outsource your responsibilities to provide adequate security to the outsourced systems.  OMB, the GAO, and your IG don’t care if you outsourced the system or not–they expect a certain level of security performance.

What you did do when you made a decision to outsource, however, was enter into a partnership with a vendor.  Yes, sometimes it feels like an abusive relationship. =)  But the key here is that it is a partnership.

The key to this partnership is open communication and understanding of the nature of this relationship.  The crux of the problem with outsourcing in the government is that it amplifies the operations-cost-paranoia triangle that you manage on a daily basis.  Where you used to be able to handle security problems internally, now you have several layers of abstraction (contracting officers, funding, 2 political structures) to work through.

So, for example, the life-cycle of a vulnerability looks something like this (everybody does it differently, so don’t cut-n-paste this into a process document unless you’re happy with it):

• Vulnerability discovered by vendor’s security team during monthly scanning
• Vulnerability reported to government ISSO and System Owner
• ISSO requests vendor to provide a rough order of magnitude (ROM) as a cost estimate
• Vendor provides ROM to ISSO through contracting
• System Owner and ISSO make a risk-based decision to mitigate and approve a budget for mitigation
• Mitigation plan transfered through contracts officer to require the vendor to mitigate
• Vendor mitigates the vulnerability and reports completion through contracts officer
• ISSO contacts vendor security team to validate mitigation through a “regression scan”

That’s pretty complex if you think about it, and there are numerous handoffs that could be missed if we don’t have a healthy, communicating relationship.

The conclusion you should have come to by now is that in order to succeed in outsourcing engagements, both sides of the contracting “fence” need to figure out tactics, techniques, and procedures to effectively manage this new layer of complications.

One thing that you’ll notice with outsourcing is that you have to have at least one knowledgeable security person on both sides.

One thing that works is to add a contract clause that lets the contractor’s security people talk to your security people.  The first ground rule is that you decide on what is the security-correct thing to do first, then figure out how to manage the business and contract end of things.

Another thing that works is to decide on a firm delineation of responsibilities before you put the RFP out on the street.  Look at your strengths and weaknesses as an agency.  It could be that you need a full turnkey solution from the vendor along with a large security team to support it because you only have one security practitioner on your project staff (for example, a large LAN/WAN rollout) or you just need a small team from the vendor to dovetail into your already-existing staff.  More on division of labor later this week….

You might want to consider a second, smaller, contract, for security support if you have a small staff on both sides of the contracting relationship.  This adds complexity to our relationship, but it also fixes some conflict-of-interest issues.  An even better way to use a second contractor is for a short engagement to perform a “gap analysis” to tell you what support you need the outsourcing vendor to provide.

Ultimately, though, the thing to remember is that as the government, it is your system, and you have a responsibility to provide adequate security .  Outsourcing just changes the nature of the business, not the endstate.

• How Much Security Should the Outsourcer Do?
• Keys to the Outsourcing Kingdom
• What the Government Looks for in a Product
• Compensating Controls
• Always Behind

Over the next week, I will be doing a blog theme on outsourcing in the US Government and my thoughts on how to effectively manage the security concerns associated with it.  This, of course, dashed with the usual dry wit that people have come to appreciate, or not, as the case may be. =)

For non-government outsourcing, I recommend keeping an eye on the ISM-Community outsourcing forum.  You can even read about myself and kimonos there.

• You Didn’t Outsource Your Responsibilities
• Keys to the Outsourcing Kingdom
• How Much Security Should the Outsourcer Do?
• Compensating Controls
• C&A Seminar, October 15th and 16th

I have a unique vantage point on how security, outsourcing, consulting, and the public sector work.  While I am a contractor who works for a company that provides outsourcing services, most of the time I end up arguing the government’s standpoint to my company, and I end up arguing my company’s standpoint to the government.

In short, I argue a lot.  =)  So much, in fact, that most of the time people have to ask who I work for and they’re shocked to find out the truth.

One issue that I hold close to my heart is how to manage security in outsourcing.  I’ve seen what works, and I’ve seen what doesn’t work, but usually more of the latter.

The truth is that while the government is getting smarter about outsourcing, we still have miles to go.  For example, more often than not a government contract nowadays contains a clause that “the contractor must be compliant with FISMA and NIST standards and guidelines”.  On one hand, I like this, it shows that “The Word” (TM–thanks, Joe) is slowly sinking in.  However, it’s not enough, and I’ll explain why.

The problem is that if you are wearing a contractor hat, what you are looking at is a simple problem: “How do I estimate the cost to me for providing security support to the government as part of this contract?”  This is a problem because “compliant with FISMA and NIST standards and guidelines” runs an entire range of situations from horrible Bataan-death-march malicious compliance contracts to well-managed common controls shops, and unless I have prior experience with this particular agency, I don’t know which side of the spectrum they are on.

As a contractor, when it comes to security, we are almost always responding reactively to security requirements.  This might mean that we have to significantly change the solution mid-stream in order to satisfy what the government wants.  Contractors don’t like this because it means we have to fight with the government over costs, which is just no fun for either of us.  On the government side, we’re wondering why the contractors don’t just Do What I Mean, since I obviously said “be compliant or else”.

Just thinking back, I know what to expect from a handful of agencies, but if they’ve experienced key personnel changes or were suddenly born-again security-wise because of a bad report card, then suddenly my crystal ball has gone black.  Wouldn’t it be nice if we could ask them in advance on which side of the teeter-totter they are sitting on?

Well, I have a partial answer.  You cynics were waiting for this, weren’t you?

How about the government starts their System Security Engineering process and their Certification and Accreditation before they send out the Request for Proposal or Request for Information?  That way, when we send out something for the industry to respond to, they have something to base their security estimates on.  According to the fancy manuals, this is how we should be running the Capital Planning and Investment Control Process all along.  You’re not that mature as an agency?  Don’t worry, you’re not alone.
We have the tools already built to do this.

We have FIPS-199 (ratings for Confidentiality, Integrity, and Availability) which can provide a contractor with a very rough order of magnitude on how much security to build into their response.  As soon as we know what we want to use the system for, we can determine data types and, by extension, criticality.

And we have FIPS-200/SP 800-53 which, although we don’t want to build the entire set of controls, we can select controls out of the catalog which absolutely need to be implemented.  We base this on, take a seat for this one… risk assessment.  We can then put these controls (a dozen or so of the high-priority controls at the most, otherwise you’re defining the solution space and limiting the flexibility of the vendor to be cost-effective) as security requirements or even functional requirements.

Now isn’t that better than a blanket FISMA/NIST clause?

• Keys to the Outsourcing Kingdom
• Imagine that, System Integrators Doing Security Jointly with DoD
• Your Security “Requirements” are Teh Suxxorz
• How Much Security Should the Outsourcer Do?
• Compensating Controls