Posts RSS
Subscribe via Email
The Guerilla CISO Rants: Don’t Write a System Security Plan
Posted October 1st, 2009 by rybolov
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:
- Information System Name/Title–On the investment/FISMA inventory, the Exhibit 300/53, etc
- Information System Categorization–usually on a FIPS-199 memorandum
- Information System Owner–In an assignment memo
- Authorizing Official–In an assignment memo
- Other Designated Contacts–In an assignment memo
- Assignment of Security Responsibility–In assignment memos
- Information System Operational Status–On the investment/FISMA inventory, the Exhibit 300/53, etc
- Information System Type–On the investment/FISMA inventory, the Exhibit 300/53, etc
- General System Description/Purpose–In the design document, Exhibit 300/53
- System Environment–Common controls not inside the scope of our system
- System Interconnections/Information Sharing–from Interconnection Security Agreements
- Related Laws/Regulations/Policies–Should be part of the system categorization but hardly ever is on templates
- Minimum Security Controls–800-53 controls descriptions which can easily be done in a Requirements Traceability Matrix
- Information System Security Plan Completion Date–specific to each document
- 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.
Similar Posts:
Posted in FISMA, NIST | 
11 Comments »
Tags: 800-53 • 800-53A • accreditation • auditor • C&A • catalogofcontrols • categorization • certification • compliance • government • infosec • infosharing • management • NIST • scalability • security
October 1st, 2009 at 10:37 pm
Yeah, this type of thing is a huge pain. Maybe SSP-type info should be stored in a database or something. Maybe everything should be stored in a database (even all the docs we create). That way there is only one source and things can just point to each other. If someone wants an SSP, then you’d just need to write a SQL query to pull out the particular data you need. I heard there are COTS that do this but they cost 1 biiillllliiiooon dollars. 🙂 And it ends up being more cost effective to pay us to do it manually. On the other hand, maybe I shouldn’t be pushing this … you know … job security and all. 🙂
October 1st, 2009 at 10:43 pm
If you have it stuck in a tool, you lose flexibility and portability. I’ve seen it happen a bazillion times.
October 2nd, 2009 at 12:33 am
Agreed, there are pros & cons to every solution. Maybe wikis then. 🙂
October 2nd, 2009 at 7:20 am
This is the opening salvo in a dialogue. Excellent points. I disagree with many of them, but I vehemently endorse the suggestion and the observations which cause you to issue the fatwah.
Polyinstantiation is a sin.
But an equally horrid behavior is bad foreign key reference. What you’re suggesting is that the ISSP become an index table to other documents where the information is stored. If the link is broken (because someone revises the underlying information but doesn’t tell security “Why should I tell security? I’m not an attacker!”, then the ISSP loses utility.
I’d very much like to see people do some research into notions like wiki’s (I know one site where the ISSP is a sharepoint portal).
Excellent suggestion – but let’s make it better.
October 2nd, 2009 at 2:33 pm
I dunno- I’ve read some rather flowery 5 “paragraph” OPORDS in my time… 🙂
October 5th, 2009 at 2:36 pm
I tend to agree with Grecs. The document we call an SSP? It’s a report. ditto the POA&Ms.
But what I’ve been wondering for a while now is… I tend to think of plans in terms of plans are something you intend to do, a course of action, maybe a set of protocols (like a comms plan)
if the ssp is a “plan” why aren’t we executing it? Don’t we execute plans? If all your controls are in place what is plan like about the SSP?
October 6th, 2009 at 3:25 pm
Badly specified tools compromise flexibility and portability. But that’s the fault of the software requirements spec, not the tool.
Portability – particularly portability of data – should show in every spec.
October 7th, 2009 at 7:34 am
Yes portability should be part of the spec. But there is some incompatability between tools.
If I chose CSam for my element but the department later chooses and mandates oh, say TAF. (and then OMB decides on something else – finally) Then even though my tool supports portability their’s don’t. But I’m still hogtied into data conversions by these higher level mandates.
Enterprise wide (at the fed level) clearly defined data elements need to be described. I’ve seen organizations less than 500 peeps unable to agree on a data dictionary. I wouldn’t want to lead, be a part of or follow an effort to establish one for federal space.
October 8th, 2009 at 7:15 am
Fin – When I asked that question, the pitchforks & torches came out. Who would have imagined that people would get so defensive over shelfware.
The SSP should be a maintenance plan for the countermeasures. It should specify the period of monitoring, the tests that are done, and how. Every day/week/month, the System Security Officer should check the plan to see what maintenance (oh – sorry we call it continuous monitoring) needs to be done.
But first I have to put some heavy furniture in front of the door to block all those SSP writers with pitchforks.
RE: portability. Yep, another fight that I’ve failed to have an impact on. Matter of fact our software spec specifically forbids interoperability, data standards, or portability. (Yes, this makes my head hurt).
I will however ponder the cynicism in your third paragraph.
October 8th, 2009 at 9:45 am
Hey folks, I’m in Toronto this week for SecTor so I haven’t been able to play in this discussion much. Watching from the sidelines is pretty interesting.
This debate needs continue because I think the current state of what we’re doing is unmaintainable.
November 5th, 2009 at 10:26 am
GAO says our FISMA paper is costing about 1400/$ a page. Righteous bucks. What’s unsustainable ’bout that?