800-53 Appendix J - Privacy Controls

I feel like I need to say something about the latest addition to my favorite document.

Redundant and unnecessary springs to mind. While new words may be used to talk about the same things, the bottom line is the same as it always is: limit what you collect and then protect it with in the budget constraints you have.

Below is the text of an email I have sent to a number of my customers (as they pay my opinion on such things).

Subject: NIST 800-53 Rev 4

NIST is projecting a release of an updated 800-53 in December. At this time, the only thing that is changing is the addition of Appendix J. Appendix J provide 23 new controls related privacy data protection.

After a quick review, I do not believe that we are in any danger of having to implement something new as far as technology. However, we may need to go through the exercise of updating our documentation to add these new controls (should decide to adopt them).

Attached is the draft of Appendix J for your review. Let me know if you have any questions.

-C

Of course, I attached the PDF for them - you can look at here: http://csrc.nist.gov/publications/drafts/800-53-Appdendix-J/IPDraft_800-53-privacy-appendix-J.pdf

I know that some organizations feel they need these new controls. The ones I work with are not those. If I am totally cynical about the whole thing; I think that this is a way for some people to check more boxes to say how awesome they are OR for someone to justify spending more money on technology that should already be in place.

Announcing RedSpartan

Today a private alpha of RedSpartan is being made available to compliance and security professionals for review. RedSpartan has been built from the ground up, incorporating features and workflow to benefit audit and compliance teams struggling with tasking and geographical challenges.

RedSpartan is a platform from which an organization can assess (itself or another organization) with industry standard or internal control sets. RedSpartan will maintain the customer’s control set and test procedures. This allows organizations to have standard procedures for all team members, but provides the flexibility to add custom procedures as necessary. Teams can review all procedures for a control in a single view and write a compliance statement for the control and/or findings.

In RedSpartan, findings are tied to test steps, eliminating confusion about what needs to be done in order to satisfy remediation. RedSpartan has a standard set of several reports and formats. The reporting is designed so that new and custom formats and reports can be rapidly developed and deployed, however that feature will be available in the future.

Future features planned for RedSpartan include: allowing for uploading of results from tools such as Nessus, Lynis and our own testing scripts; incorporating role-based access to the features of the system; an archive function; plus other exciting plans on our roadmap.

We welcome any and all feedback via Twitter (@RedSpartan), our web site http://www.redspartan.com or email (support -@- redeyetek dot com)

The Biggest Problem

By far, the biggest problem I run into during my time as an information security person is not: misconfigured firewalls, unencrypted USB drives or a poor risk management program. The biggest problem is communications.

I don’t know that I have the answer, but I will tell you that I get a lot of emails that I don’t care about and others that I probably do need to care about but aren’t written in a manner that is useful. I imagine that this guy has some interesting idea regarding email management. But that isn’t all.

It is all about knowing your audience. It sounds basic, I know, but don’t confuse basic with simple. Many people don’t totally understand things like FISMA, FIPS and the 800-series documents. Even those that do may interpret different ideas and concepts in a conflicting manner.

We deal in a complicated and ever-changing space, so do us all a favor and maintain a project glossary and acronym list. Use your snazzy Document/Content management systems or MediaWiki.

I also like to provide standard process documents that back up a project plan. A project plan is telling for some, but here again is an opportunity for failure. One-line entries in a spreadsheet or MS-Project are prone to misinterpretation given their short nature. My process documents are not tasks, but an explanation of activities. It is in plain speak usually one to two paragraphs that talk about what is going to happen during a phase of the project (not necessarily tied to 800-37 or SDLC frameworks). Especially when it comes to short engagements, it is difficult to spin up a lot of collateral or spend time with education.

Learn how to write. I know I’m not the best writer, but damn. Spell check is not a fix for the “they’re/their/there” issue. Some of this can solved with taking an extra two minutes to read your writing again.

Lastly (and something that I intend to try out in soon), is to spend the time to copy and paste. I am one of those people who think I impress someone with my ability to reference an appendix or section of a document. No more. I estimate that 90% of the time, the recipient(s) of my reference didn’t bother to go look at it. Therefore, they still don’t know what you’re talking about, but worse you think that they do. It also gives you an opportunity to apply to explain the relevance or your interpretation of the selection.

This is only some small hints, but sometimes the smallest gains in productivity are the best (because they are the most annoying).

Numbers and Metrics

Before I get to an analysis of FISMA reforms and their potential impacts, I wanted touch on something that has been biting my ass for a little while.

I get asked to justify my existence and what I provide as a return on investment. As part of that, I have tried to quantify the value of an information security or risk management program. If this were a normal blog, I would launch into a diatribe replete with all the necessary management buzz words, catch phrases and witty clichés. This is not a normal blog, so if that is what you are looking for then you can move on.

Much of the time information system risk management is based on existing risk assessment and monitoring frameworks, either insurance or financial or whatever. My opinion is that those don't work. Mainly, because those metrics are difficult for everyone to understand and they are basically rigged out to screw a customer. In the information systems world, the risk management framework needs to HELP a customer. I could be totally wrong though, but these frameworks are developed by corporations with a profit motive (not that there's anything wrong with that).

The other weak link in the chain (for me) is that even for quantitative frameworks, there is still room to fudge the numbers by a single person or data input. When you are assessing a mortgage for risk there is a history for a person, history for the house and the general climate of the market. All of which let us down in the recent past, due to securitization, greed and complicated schemes to make it all look good. There isn't a lot of room for that in the information security world.

I know what also isn't working - technical numbers. Number of viruses caught by AV, IDS true/false positive rates, percentage of environment patched. These don't work because MBA can see a 90% as pretty good. The problem with this is that even when you are at 100% there is still an unknown number of zero-day exploits in deployed software and there is still the element of human failures (lack of knowledge, misconfiguration and outright theft).

This wasn't supposed to sound all doom and gloom though. I am pointing out that somehow we as a community are doing something wrong. But please comment if you have had success in this arena. I have not seen it yet.

My idea:

I have been a fan of Eli Goldratt and the Theory of Constraints for about 10 years now, and I would love to figure out a way to apply ToC to information system risk management. You will notice I didn't say information security because a holistic risk management program includes operational and security risks.

For a couple of reasons: it is flexible for a dynamic environment, it depends on the improvement processes and the measurements for success are easy to understand.

Where's my white board?

Lame Post

This week's post is a pointer to my interview on the Southern Fried Security podcast.

http://www.southernfriedsecurity.com/the-episodes/episode-16---av-is-dead

Thanks for reading and listening.