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)

Scan, Baby, Scan!

I recently experienced death by scanning (maybe death is too strong, extreme pain). The system I am supporting is eventually used by the government which means FISMA and by extension certification agents. I still do some certification agent work and I will say that it is still a foggy area. Some will take it to the Nth degree and dig in to every facet and crevice to get the best assurance possible. Others will do a superficial scan and call it a day.

My current annoyance in the ability to ascertain the security posture is this; the management of the little system wants as few vulnerabilities as possible, obviously. So naturally, their scanning policy is tailored to the system and to the excepted risks. The certification agent has their own process for assessment, good for them. However, their process does not include updating their process for the environment.

The two processes are at odds with one another, so we are constantly chasing vulnerabilities. Different tool sets, different time lines, different policy baselines, plugin updates, the list goes on. When I try to convince that less scanning needs to happen, we in fact get more.

Most people I talk to would agree, it would be good to run as many tools as possible at your environment. I am currently frustrated by it.

There really wasn't any point to this story except that scanning with 19,000 tools is helpful as long as everyone is on the same page and can adequately communicate that page. So far, I have apparently been an ineffective communicator or my communication has been accepted and then moved aside in an effort to portray a rosier picture.

A new plan will have to take shape now. Details to follow.

Just buy this and you're Compliant!

Does this really work on anyone?

http://www.wwpi.com/index.php?option=com_content&task=view&id=4839&Itemid=128

To a lesser extent this one:http://www.businesswire.com/portal/site/google/?ndmViewId=news_view&newsId=20080730005428&newsLang=en

Now, I know they aren't coming right out and saying it but it is implied at the very least. The reality is compliance and risk management are hard. Its not what you want to hear. But we will take me as an example: I have an Ubuntu laptop, Windows XP in VMWare), my wife has a MacBook Pro, we have a Windows 2003
server, a Fedora Asterisk PBX/MythTV box and a wireless network.

I spent the last two days attempting to practice what I preach. I have found that even with this small setup it is challenging. Granted, I am running 5 different operating systems. But even if you take away the Mac (which I did, because she wouldn't let me touch it) I still spent a couple hours analyzing myself. The Windows server and virtual machine were quite a distance away from FDCC / SCAP Beta compliance. The SQL server instance on the server and MySQL on the PBX were laughable at best. All in all, without spending too much effort, I would give myself over 100 findings and about 15 - 20 highs, best case (and being creative with combining vulnerabilities).

Here it comes ... my main problem is the operations and management of these systems. No CM, no security analysis before changing things, constantly chasing my tail trying to remember what I did. Poorly documented accounts, inconsistent security policy, no backups, little regard for how equipment is acquired, no regularly scheduled vulnerability assessments or pen tests, the list goes on.

So, what do the "products" suggest I do? Fix ten of my technical problems that I found with a simple VBScript and MBSA. And now I'm compliant. I think not.

Compliance is not easy, it comes from detailed policy and procedures, creating and executing a plan, assessing the residual risks and managing those risks. No product is going to give you that. Can they help you, sure. But they aren't the silver bullet to compliance.

800-39, 800-60 and VBScripts that may help you.

I am slowly making my way through the 800-39. I like it so far. I worry that because it hasn't specified a deliverable yet that it will get no notice or play. I hope that it does soon. I also await the arrival of the updated 800-30 since there are clear overlaps. What would probably be helpful for anyone reading is posting my comments and markups. I am not sure how NIST will respond to it.

I also saw a that there is a new 800-60. I can't even begin to contemplate when I will get to it. The last one was weak and I don't think anyone I knew even read it. I know this because when I asked them what information type their system was processing, I instantly received a blank stare. When I was engineering Federal systems, they didn't have an 800-60 or FIPS 199. So, we merrily wrote our SSP, conducted Risk Assessment and ran the ST&E's. I get the feeling here that because they bothered to update the documents, that they will probably get a little more play.

It is my opinion, that if more system owners sat down and determined their information types, then boundary identification would be easier. I won't go into it, but please stay tuned for a post on system boundaries.

Lastly, I wrote a couple VBScripts that help me with my Nessus scanning. Since Nessus is still free (7 day lag on plugins) and generally useful I provide my little scripts for you to review and abuse. The script will run against one or multiple result XMLs, and provide output in the form of MS-Excel. They are located at http://www.redeyetek.com/Tools/. One for the results from a Linux scanner and one for Windows client.

Things to look forward to: Another VBScript that make XMLs from the DISA SRRs into MS-Excel. And a post on System Boundaries.