C&A Seminar, October 15th and 16th

Posted September 22nd, 2008 by

The Potomac Forum crew is back at it again with a C&A seminar on the 15th and 16th.  While 2 days isn’t long enough to earn your black belt at C&A-Foo, it is enough so that if you’re a solid program manager or technical lead, you’ll walk out being at least able to understand the core of the process.

As usual, some of the instructors should be familiar to my blog readers.  =)

Similar Posts:

Posted in FISMA, Speaking | No Comments »

Next Up in Security Legislation: S3474

Posted September 15th, 2008 by

And here we have it, a bill introduced by Senators Carper and Lieberman to increase security in the Government, known as FISMA 2008. I’m still waiting on the text to appear on the Thomas entry, but I’ll go through the major provisions from the congressional record.

Article from NextGov

Thomas Reference

Congressional Record of the Bill’s Introduction and text (Starts on CR 8388 and goes through CR 8391)

Major provisions:

  • Changes some definitions of “assessment”, “audit” and “evaluation”. OK, I had to do some research on this one.  Thankfully, this is all online.  Sidenote: it’s not Section 3545 as per the bill, it’s Section 3535.  Basically this is just rewording and rescoping of annual audits to be written the way it should have been in the first place.
  • Creates a CISO position at each agency. Hey, I thought this was already created by FISMA.  What we need is not CISOs that work for the CIO, what we need are agency CSOs (I’ll even take an agency Chief Risk Officer) that have authority over all of security, not just IT geek concerns.
  • Creates a CISO Council. Fantastic idea, how come I didn’t think of it?
  • Qualifications for CISOs. Not a bad idea, but the bill doesn’t elaborate too much.
  • Responsibilities for CISOs. This is an interesting section.  Much of this is in guidance from NIST/DISA/CNSS already.  I like most of these measures, but I’m not sure that they need to be codified into law except for the pieces that reside outside of the agencies, like the coordination with US-CERT.  Putting the CISO’s responsibilities into law does give the CISO more teeth if they need it, but you have to wield the law carefully.

The Law

The Law photo by F.S.M.

From the NextGov article and the congressional record:

“Our bill empowers chief information security officers to deny access to the agency network if proper security policies are not being followed. If we are going to hold these hardworking individuals accountable in Congress for information security, then we should give them the authority to do so,” said Carper.

Um, yeah, we’ve given them the authority in this bill, but my problem is that it completely removes the DAA/AO/mission owners from the picture–the CISO is now responsible for the secure operations of IT systems and has disconnect authority.

I think that philosophically this bill is a step backwards.  The more progressive thought is that security is the responsibility of the agency head and the mission owners and that the CISO just provides support as a subject matter expert.  Under this bill, we’re back to a world where the CISO is the sole decision-maker when it comes to security.  Wow, that’s so… 1990’s-ish.

However, we all know that the CISOs are the people getting the security job done from day to day, and this bill makes sense if you assume that the agency heads and DAAs/AOs have 0 interest or skills to assist in the security of their data.  That might or might not be true, I’ll leave it up to you to decide.

Questions for today are these (and yes, I want to hear what you think):

  • Are we willing to scrap the “business/system owner” concepts that our security management processes are modeled around?
  • Are we willing to admit that the DAA/AO concept is a failure because of lack of understanding and capabilities on their part?
  • Are the mission owners willing to take an outage on their supporting IT infrastructure because the CISO took the system offline because they didn’t secure the system properly in the first place?
  • Can we rely on a management technique where the stakeholders are removed from the decisionmaking of a trained expert?

Similar Posts:

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

Imagine that, System Integrators Doing Security Jointly with DoD

Posted September 11th, 2008 by

First, some links:

Synopsis: DoD wants to know how its system integrators protect the “Controlled Unclassified Information” that they give them.  Hmm, sounds like the fun posts I’ve done about NISPOM, SBU and my data types as a managed service provider.

This RFI is interesting to me because basically what the Government is doing is collecting “best practices” on how contractors are protecting non-classified data and then they’ll see what is reasonable.

Faustian Contract

Faustian Contract photo by skinny bunny.

However, looking at the problem, I don’t see this as much of a safeguards issue as I do a contracts issue.  Contractors want to do the right thing, it’s just that they can’t decide if security is which of these things:

  • A service that they should include as part of the work breakdown structure in proposals.  This is good, but can be a problem if you want to keep the solution cheap and drop the security services from the project because the RFP/SOW doesn’t specify what exactly the Government wants by way of security.
  • A cost of doing business that they should reduce as much as possible.  For system integrators, this is key:  perform scope management to keep the Government from bleeding you dry with stupid security managers who don’t understand compensating controls.  Problem with this approach is that the Government won’t get all of what they need because the paranoia level is set by the contractor who wants to save money.

Well, the answer is that security is a little bit of both, but most of all it’s a customer care issue.  The Government wants security, and you want to give it to them in the flavor that they want, but you’re still not a dotorg–you want to get compensated for what you do provide and still make a profit of some sort.

Guess what?  It takes cooperation between the Government and its contractors.  This “Contractor must be compliant with FISMA and NIST Guidelines” paragraph just doesn’t cut it anymore, and what DoD is doing is to research how its contractors are doing their security piece.  Pretty good idea once you think about it.

Now I’m not the sharpest bear in the forest, but it would occur to me that we need this to happen in the civilian agencies, too.  Odds are they’ll just straphang on the DoD efforts. =)

Similar Posts:

Posted in Outsourcing, Risk Management | No Comments »

Cloud Computing and the Government

Posted August 19th, 2008 by

Post summary: We’re not ready yet culturally.

What spurred this blog post into being is this announcement from ServerVault and Apptis about a Federal Computing Cloud.  I think it’s a pretty ballsy move, and I’ll be watching to see if it works out.

Disclaimer being that at one time I managed security for something similar in a managed services world, only it was built by account with everything being a one-off.  And yeah, we didn’t start our organization the right way, so we had a ton of legacy concepts that we could never shake off, more than anything else about our commercial background and ways of doing things.

Current Theory on Cloud Computing

Current Theory on Cloud Computing photo by cote.

The way you make money in the managed services world is on standardization and economy-of-scale.  To us mere mortals, it means the following:

  • Standardized OS builds
  • Shared services where it makes sense
  • Shared services as the option of choice
  • Split your people’s time between clients
  • Up-charge for non-standard configurations
  • Refuse one-off configurations on a case-by-case basis

The last 2 were our downfall.  Always eager to please our clients, our senior leadership would agree to whatever one-offs that they felt were necessary for client relationship purposes but without regard to the increased costs and inefficiency when it came time to implement.

Now for those of you out in the non-Government world, let me bring you to the conundrum of the managed services world:  shared services only works in limited amounts.  Yes, you can manage your infrastructure better than the Government does, but they’ll still not like most of it because culturally, they expect a custom-built solution that they own.  Yes, it’s as simple as managing the client’s expectations of ownership v/s their cost savings, and I don’t think we’re over that hurdle yet.

And this is the reason: when it comes to security and cloud computing, the problem is that you’re only as technically literate as your auditors are.  If they don’t understand what the solution is and what the controls are around it, you do not have a viable solution for the public sector.

A “long time ago” (9000 years at least), I created the 2 golden rules for shared infrastructure:

  • One customer cannot see another customer.
  • One customer cannot affect another customer’s level of service.

And the side-rules for shared infrastructure in the public sector:

  • We have a huge set of common controls that you get the documentation to.  It will have my name on it, but you don’t have to spend the money to get it done.
  • It’s to my benefit to provide you with transparency in how my cloud operates because otherwise, my solution is invalidated by the auditors.
  • Come to us to design a solution, it’s cheaper for you that way.  I know how to do it effectively and more cheaply because it’s my business to know the economics of my cloud.
  • You have to give up control in some ways in order to get cost savings.
  • There is a line beyond which you cannot change or view because of the 2 golden rules.  The only exception is that I tell you how it’s made, but you can’t see any of the data that goes into my infrastructure.
  • If I let you audit my infrastructure, you’ll want to make changes, which can’t happen because of the 2 golden rules.
  • I’ll be very careful where I put your data because if your mission data spills into my infrastructure, I put myself at extreme risk.

So, are ServerVault and Apptis able to win in their cloud computing venture?  Honestly, I don’t know.  I do think that when somebody finally figures out how to do cloud computing with the Federal Government, it will pay off nicely.

I think Apptis might be spreading themselves fairly thin at this point, rumor has it they were having some problems last year.  I think ServerVault is in their comfort space and didn’t have to do too much for this service offering.

I can’t help but think that there’s something missing in all of this, and that something is a partnering with the a sponsoring agency on a Line of Business.  FEA comes to mind.

Similar Posts:

Posted in What Doesn't Work, What Works | 1 Comment »

New SP 800-60 is Out, Categorize Yerselves Mo Better

Posted August 18th, 2008 by

While I was slaving away last week, our friends over at NIST published a new version of SP 800-60.  Go check it out at the NIST Pubs Page.

Now for those of you who don’t know what 800-60 is, go check out my 3-part special on the Business Reference Model (BRM), a primer on how SP 800-60 aligning FIPS-199 with the BRM, and a post on putting it all together with a catalog of controls.

And oh yeah, the obligatory press reference: Government Computer News.

Data Release Show

Data Release Show photo by Discos Konfort.

So deep down inside, you have to be asking one question by now:  “Why do we need SP 800-60?”  Well, 800-60 does the following:

  • Level-sets data criticality across the Government:  Provides a frame of reference for determining criticality–ie, if my data is more important than this but less than this, then it’s a moderate for criticality.
  • Counters the tendency to rate system criticality higher than it should be:  Everybody wants to rate their system as high criticality because it’s the safe choice for their career.
  • Protection prioritization:  Helps us point out at a national level the systems that need more protection.
  • Is regulations-based:  The criticality ratings reflect laws and standards.  For example, Privacy Act Data is rated higher for confidentiality.

All things considered, it’s a pretty decent systemfor Government use.

Now this is where I have a bit of heartburn with GRC tools and data classification in general in the private sector–they classify the wrong things.  How the vendors (not all of them, there is a ton of variation in implementation) want you to categorize your data:

  • HIPAA-regulated
  • PCI-DSS-regulated
  • SOX-regulated
  • All other data types

How your CISO needs to categorize data to keep the business afloat:

  • Data that gets you paid:  If you’re a business, your #1 priority is getting money.  This is your billing/AR/POS data that needs to keep going.
  • Data that keeps you with a product to sale over the next week:  usually ERP data, stuff that slows down the production line.
  • Data that people want to rip off your customers:  hey, almost all the regulated data (PCI-DSS, HIPAA, etc) fits in here.
  • Data where people will rip you off:  ie, your internal financial systems.  Typically this is SOX country.

I guess really it comes down to the differences between compliance and risk, but in this case, one version will keep you from getting fined, the other will keep your business running.

Similar Posts:

Posted in FISMA, NIST | No Comments »

Next Entries »

Visitor Geolocationing Widget: