For those of you who didn’t know the real purpose of DojoCon, it was to raise money and awareness for Hackers for Charity. If you like anything that is in this post, go to HFC and make a donation of time, equipment, tech support, and maybe money. If you’ve never heard of HFC because you’re not one of the “InfoSec Cool Kids”, now is your chance–go read about them.

The video of my dojocon presentation. The microphone was off for the first couple of minutes but I look pretty animated.

And then the compliance panel that I tried not to dominate:

And finally, my slides are up on slideshare:

• Massively Scaled Security Solutions for Massively Scaled IT
• Building A Modern Security Policy For Social Media and Government
• Barcode Hacking
• Metricon 5 Wrapup
• DojoCon DDoS Video

My presentation slides from Sector 2009.  This was a really fun conference, the Ontario people are really, really nice.

Presentation Abstract:

The US Federal Government is the world’s largest consumer of IT products and, by extension, one of the largest consumers of IT security products and services. This talk covers some of the problems with security on such a massive scale; how and why some technical, operational, and managerial solutions are working or not working; and how these lessons can be applied to smaller-scale security environments.

• A Layered Model for Massively-Scaled Security Management
• Metricon 5 Wrapup
• DojoCon 2009 Presentation
• Where is Rybolov?
• Building A Modern Security Policy For Social Media and Government

I sat down with Jim Manico a month or so ago when he was in DC and recorded a podcast for the OWASP Podcast.  It’s now live, check it out.

• Your Friendly Neighborhood C&A Podcast Panel
• Guerilla CISO “Staff” Hit the Campaign Trail
• OWASP AppSec Conference 09
• Caught on Tape!
• Old Saint NIST: Ho Ho Hold on, what’s this?

OK, I know you’re shocked…I’m saying something controversial.  But hear me out on this one, I’ll explain.

Now this is my major beef with the way we write SSPs today:  this is all information that is contained in other artifacts that I have to pay people to do cut-and-paste to get it into a SSP template.  As practiced, we seriously have a problem with polyinstantiation of data in various lifecycle artifacts that is cut-and-pasted into an SSP.  Every time you change the upstream document, you create a difference between that document and the SSP.

This is a practice I would like to change, but I can’t do it all by myself.

This is the skeleton outline of an SSP from Special Publication 800-18, the guide to writing an SSP:

1. Information System Name/Title–On the investment/FISMA inventory, the Exhibit 300/53, etc
2. Information System Categorization–usually on a FIPS-199 memorandum
3. Information System Owner–In an assignment memo
4. Authorizing Official–In an assignment memo
5. Other Designated Contacts–In an assignment memo
6. Assignment of Security Responsibility–In assignment memos
7. Information System Operational Status–On the investment/FISMA inventory, the Exhibit 300/53, etc
8. Information System Type–On the investment/FISMA inventory, the Exhibit 300/53, etc
9. General System Description/Purpose–In the design document, Exhibit 300/53
10. System Environment–Common controls not inside the scope of our system
11. System Interconnections/Information Sharing–from Interconnection Security Agreements
12. Related Laws/Regulations/Policies–Should be part of the system categorization but hardly ever is on templates
13. Minimum Security Controls–800-53 controls descriptions which can easily be done in a Requirements Traceability Matrix
14. Information System Security Plan Completion Date–specific to each document
15. Information System Security Plan Approval Date–specific to each document

Now some of this has changed in practice a little bit–# 10 can functionally be replaced with a designation of common controls and hybrid controls.

So my line of thinking is that if we provide a 2-6-page system description with the names of the “guilty parties” and some inventory information, controls-specific Requirements Traceability Matrix, and a System Design Document, then we have the functional equivalent of an SSP.

Why have I declared an InfoSec fatwah against SSPs as currently practiced?

Well, my philosophy for operation is based on some concepts I’ve picked up through the years:

• Why run when you can walk, why walk when you can sit, why sit when you can lay down.  There is a time to spend effort on determining what the security controls are for a project.  You need to have them documented but it’s not cost-effective to be worried about format, which we do probably too much of today.
• Make it easy to do the right thing.  If we polyinstantiate security information, we have made something harder to maintain.  Easier to maintain means that it will get maintained instead of being shelfware.  I would rather have updated and accurate security information than overly verbose and well-polished documents that are inaccurate.
• Security is not a “security guy thing”–most problems are actually a management and project team problem.  My idea uses their SDLC artifacts instead of security-specific versions of artifacts.  My idea puts the project problems back in the project space where it belongs.
• If I have a security engineer who has a finite amount of hours in a day, I have to choose what they spend their time on.  If it’s a matter of vulnerability mitigation, patching, etc, or correcting SSP grammar, I know what I want him to do.  Then again, I’m still an infantryman deep down inside and I realize I have biases against flowery writing.

Criticisms to not writing a dedicated SSP document:

“My auditors are used to seeing the information in the same format at someplace they worked previously”. Believe it or not, I hear this quite a bit.  My response is along the lines of the fact that if you make your standard be what I’m suggesting for a security plan, then you’ve met all of the FISMA and 800-53 requirements and my personal requirement to “don’t do stupid stuff if you can help it”.

“My auditors will grill me to death if they have to page back and forth between several documents”.  This one also I’ve heard.  There are a couple of ways to deal with this.  One way to deal with this is that in your 800-53 Requirements Traceability Matrix you reference the source document.  Most auditors at this point bring up that you need to reference the official name, date of publication, and specific page/section of the reference and I think they need to get a life because they’ve taken us back to the maintainability problem.

“This is all too new-school and I can’t get over it”. Then you are a dinosaur and your kind deserves extinction.  =)

.

This blog post is for grecs at novainfosecportal.com who perked up instantly when I mentioned the concept months ago.  Finally got around to putting the text somewhere.

How to Plan the Perfect Dinner Party photo by kevindooley.

• Old Saint NIST: Ho Ho Hold on, what’s this?
• How to Not Let FISMA Become a Paperwork Exercise
• Ooh, “The Word” is out on S 3474
• When the Feds Come Calling
• OMB Wants a Direct Report

My friends at Potomac Forum are having a workshop on SP 800-53 R3 on the 15th of September.  This is an update to the Government’s catalog of controls.

The workshop will also be about standards convergence: how ODNI, DoD, and NIST are moving towards one standard and what this means for the intelligence community and military.

Ron Ross from NIST will talk about how the NIST Risk Management Framework is changing from a static, controls-based approach to a more dynamic “real-time continuous monitoring”.

• Observations on SP 800-37R1
• Certification and Accreditation Seminar, March 30th and 31st
• NIST Framework for FISMA Dates Announced
• An Open Letter to NIST About SP 800-30
• Opportunity Costs and the 20 Critical Security Controls

The big news in OMB’s M-09-29 FY 2009 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management is that instead of fiddling with document files reporting will now be done directly through an online tool. This has been covered elsewhere and it is the one big change since last year.  However having less paper in the paperwork is not the only change.

Piles of Paper photo by °Florian.

So what will this tool be like? It is hard to tell at this point. Some information will be entered directly but the system appears designed to accept uploads of some documents, such as those supporting M-07-16. Similar to the spreadsheets used for FY 2008 there will be separate questions for the Chief Information Officer, Inspector General and Senior Agency Official for Privacy. Microagencies will still have abbreviated questions to fill out. Additional information on the automated tool, including full instructions and a beta version will be available in August, 2009.

Given the required information has changed very little the automated system is unlikely to significantly ease the reporting burden. This system appears primarily designed to ease the data processing requirements for OMB. With Excel spreadsheets no longer holding data many concerns relating to file versions, data aggregation and analysis are greatly eased.

It is worth noting that a common outcome of systems re-engineered to become more efficient is that managers look to find ways to utilize the new efficiency. What does this mean? Now that OMB has the ability to easily analyze data which took a great amount of effort to process before they may want to improve what is reported. A great deal has been said over the years about the inefficiencies in the current reporting regime. This may be OMB’s opportunity to start collecting an increased amount of information that may better reflect agencies actual security posture. This is pure speculation and other factors may moderate OMB’s next steps, such as the reporting burden on agencies, but it is worth consideration.

One pleasant outcome to the implementation of this new automated tool is the reporting deadline has been pushed back to November 18, 2009.

Agencies are still responsible for submitting document files to satisfy M-07-16. The automated tool does not appear to allow direct input of this information. However the document requirements are slightly different. Breach notification policy document need only be submitted if it has changed. It is no longer sufficient to simply report progress on eliminating SSNs and reducing PII, an implementation plan and a progress update must be submitted. The requirement for a policy document covering rules of behavior and consequences has been removed.

In addition to the automated tool there are other, more subtle changes to OMB’s FY 2009 reporting. Let’s step through them, point by point:

10. It is reiterated that NIST guidance is required. This point has been expanded to state that legacy systems, agencies have one year to come into compliance with NIST documents new material. For new systems agencies are expected to be in compliance upon system deployment.

13 & 15. Wording indicating that disagreements on reports should be resolved prior to submission and that the agency head’s view will be authoritative have been removed. This may have been done to reduce redundancy as M-09-29’s preface indicates agency reports must reflect the agency head’s view.

52. The requirement for an central web page with working links to agency PIAs and Federal Register published SORNs has been removed.

A complete side-by-side comparison of changes between the two documents is available at FISMApedia.org.

All in all the changes to OMB’s guidance this year will not change agencies reporting burden significantly. And that may not be a bad thing.

• GAO’s 5 Steps to “Fix” FISMA
• How to Not Let FISMA Become a Paperwork Exercise
• Federated Vulnerability Management
• The Guerilla CISO Rants: Don’t Write a System Security Plan
• New SP 800-60 is Out, Categorize Yerselves Mo Better