Pet peeve of just about every CISO in existance:  the so-called “audit requirements”.  What they really mean to say is “It’s on the checklist, so it has to be true, just do what I say”.

Without traceability to the actual requirement, items on a checklist are just that: items on a checklist.

Anyway, on to the lulz:

• Auditors and LULZ
• IKANHAZFIZMA Tackles the Consensus Audit Guidelines
• LOLCATS Take on MS08-67
• Continuous Monitoring with LOLCATS
• The Authorizing Official and the Lolcat

OMB sneaked this one in on me:  OMB Memo 08-23 requires secure DNS (standard .pdf caveat).  Agencies need to submit a plan by September 5th on how they should accomplish this.  The whole switchover should occur by December 2009.

The interesting thing to me is that OMB is getting bolder in specifying technical solutions.  Part of me wants to scream because public policy people have no business dictating technical solutions–that’s what we have standards boards and RFCs for.

From what I hear, some of this is because OMB is starting to be a really bad lame duck.  Think about it, what are the odds that anybody at OMB is going to be around in December 2009?  Completely unofficial word on the street is that OMB is pushing last-minute initiatives because of politicals–trying to accomplish things in time for the elections.

Also, I think that OMB is getting tired of NIST’s nonpspecificity in their guidance.  NIST’s approach to being generic in nature is necessary because of their role as a research organization and the producers of methodologies.

The solution to all this?  Well, the way it happens in the rational world is organic standards boards.  Yes, they have their problems (*cough* WAFs anyone? *cough*) but overall, they fill a place.  Inside Government, we don’t have much of that happening–we have the CIO council and the Enterprise Architecture folks, but nothing security-specific.

Lock Up Your Data photo by psd.

Description of the picture, it’s great and needs to be repeated:

The road passes the temptations of Flash and AIR. Those who succumb or who are unfortunate enough to be lured by Silverlight’s Siren find themselves sold down the river of Rich User Experiences and hurled towards lock-in weir. The TiddlyWiki steps may rescue some, who can then join those who stuck to the main path of Javascript and AJAX for their interactions.

The URI scheme is based on DNS, a registry which has weaknesses, meanwhile the ICANN Fracture results from their greedily adding spurious new Top Level Domains such as .mobi, .jobs, .xxx and even .tel, which whilst generating more revenue (for them) causes mass confusion and threatens to break the opacity of URIs.

• The 10 CAG-egorically Wrong Ways to Introduce Standards
• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• Realistic NSTIC
• Federated Vulnerability Management
• Comments on SCAP 2008

PE-52 Self-Destructing RFID Implants
Control:
The organization equips all employees with integrated storage media with self-igniting RFID devices so that they can be tracked throughout any government facility and destroyed upon command.

Supplemental Guidance:
All CISOs know that the information inside their employees’ heads is the real culprit.  When they get a new job, they take that information–all learned on the taxpayers’ dime–with them.  This is a much bigger security risk than the data on a USB drive could ever be.  Instead of denying the obvious truth, why don’t we implement security controls to minimize the impact of out-of-control employees?  This control is brought to you by L Bob Rife.

Control Enhancements:
(1) The organization destroys the information inside an employee’s head when the employee leaves the organization, much like hard drives need to be degaussed before they are sent for maintenance.
Low: MP-52 Moderate: MP-52(1) High: MP-52(1)

• Continuous Monitoring with LOLCATS
• LOLCATS Take on POA&Ms
• Oh to be a Program Manager
• Super Secret Security Control You Were Never Meant To See
• More Security Controls You Won’t See in 800-53: Now in LOLCAT Form!

Ever feel lost and lonely when staring at the business end of an ST&E?  Confounded and confused considering Configuration controls?  Perplexed and Puzzled at Planning procedures?  Anxious or amazed at Audit and Accountability assessments?  Annoyed at aimless alliteration?

NIST has heard your muttered curses and answered them!  (Except the annoying alliteration, which is my fault.)

Now available are the Assessment Cases for Special Publication 800-53A.  The Assessment Cases offer supplemental guidance on assessing security controls found in the recently released SP 800-53A Guide for Assessing the Security Controls in Federal Information Systems (PDF Warning).  These documents are in their Initial Public Draft so be sure to give them a look and provide some feedback.

The Assessment Cases contain consensus recommendations from the Assessment Cases Project on specific actions to perform when assessing security controls.  These specific actions are intended to complement the assessment procedures documented in NIST SP 800-53A.   Yes, you heard that right, Specific Actions.  Less time spent pondering how to “Examine: … other relevant documents or records”.

The Assessment Cases Project is an inter-agency workgroup headed by DoJ with members including NIST, DoE, DoT and ODNI-CIO.  Many thanks for the hard work of this workgroup’s membership.  You may not be able to hear it but I am applauding on this side of the keyboard.  And a big thanks to Patrick O’Reilly for pointing me to this wonderful resource.

• How to Not Let FISMA Become a Paperwork Exercise
• SP 800-53A Now Finally Final
• An Open Letter to NIST About SP 800-30
• Special Publication 800-53 Revision 3 Workshop
• The Guerilla CISO Rants: Don’t Write a System Security Plan

Any comment or graffiti you want to put up in the comments, go ahead.  Only stipulation is that it’s profanity-free (ack, this coming from me?) and relevant to security in the Federal Government.

Why do this?  Well, to give a voice to those who don’t say anything about what’s going on.  We need to hear more from the “silent infosec majority” who just do their jobs every day.

• Some Thoughts on Comments to My Blog…
• On Government Employees, Culture, and Survivability
• The Press has Me all Confused
• The World Asks: is S.773 Censorship?
• Entrepreneurship and Government 2.0

So what exactly is a “system”?  After all this time, it’s still probably one of the most misunderstood ways that we manage security in the Government.

The short answer is this:  a system is what you say it is.  Long answer is it depends on the following factors:

• Maturity of your agency
• Budget processes and Exhibit 300s
• The extent of your common controls
• Political boundaries between inter-agency organizations
• Agency missions
• Amount of highly-regulated data such as PII or financial

Yes, this all gets complicated.  But really, whatever you say is a system is a system, the designation is just for you so you can manage the enterprise in pieces.  There are 3 main techniques that I use to determine what is a system:

• As a budget line-item: If it has an Exhibit 300, then it’s a system.  This works better for Plan of Actions and Milestones (POA&Ms) but in reality there might not be a 1:1 correllation between systems and Exhibit 300s.
• As a data type: If it has a particular type of data, then it’s a system.  This works well for special-purpose systems or where a type of data is regulated, such as PII or financial data.
• As a project or program: if it’s the same people that built it and maintain it, then it’s a system.  This dovetails in nicely with any kind of SDLC or with any kind of outsourcing.

Inventory photo by nutmeg.

Inventory management techniques that work:

• Less systems are better.  Each system incurs overhead in effort and cost.
• More systems works when you have no idea what is out there, but will cripple you in the long term because of the overhead.
• Start with many systems, assess each as its own piece, then consolidate them into a general support system or common controls package.
• Set a threshold for project size in either pieces of hardware or dollar value.  If the project exceeds that threshold, then it’s a system.
• Determine if something will be a system when the budget request is made.  Good CISOs realize this and have a place on the investment control board or capital planning investment board.

Guerilla CISO war story time:

Way back when all this was new, one of the agency CISOs would have a roundtable every quarter or so.  Won’t name who, but some of my blog readers do.  Almost every meeting devolved at some point into the time-honored sticking point of “what is a system?”  Everybody wanted to know if they had “2 servers, 3 PCs, a database, a dog, and a dickfore”, was that a system.  After one too many iterations, the gray-hair in the group would put up “Exhibit 300=System” on the whiteboard before every meeting.  Then when the inevitable conversation of “what is a system?” would come up, he would just point to the board.

And another story:

Several years ago I was working an IT outsourcing contract with an inventory that was determined using the budget line-item technique.  Turned out we had all sorts of systems, some of which didn’t make sense, like the desktop client to manage the local admin account.  One of my first priorities was to consolidate as many systems as I could.  Not that I was altruistic about saving money or anything, it was that the less systems I had, the less paperwork needed to be generated. =)   Most of the systems I rolled up into a general support system aimed at basic user connectivity.

• When the Feds Come Calling
• The Guerilla CISO Rants: Don’t Write a System Security Plan
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• How Much Security Should the Outsourcer Do?
• Needed: Agency CSOs