All,

I know many of you might not have to deal with, or have ever heard of the DISA STIG's, but I wanted to reach out and see if any of you have created or thought about creating scripts/RPM's/DEB's that will automatically put the OS into the most "secure" state dictated by the STIG's. There is a commercially available too to do this however, it's not open source and I'm sure will cost as much as a small country.

I do not have a lot of experience in building RPM's or DEB's but with enough interest if anyone would like to start collaborating and possibly building something like this with me I think it could be something really good for the "community". I do have a tremendous amount of experience with the DISA Stigs/Scripts.

First of all thanks for offering and I hope something good will come out of it.

I've read some STIG shell scripts for GNU/Linux and they looked like they needed more eyeballs ;-p And I know just enough of systems hardening, RPM building and scripting to get around. But maybe you could start by clearing up some misconceptions for me. How does STIG relate to work done by say NIST? CIS? What's the current state of STIG scripts for GNU/Linux? Does it already cover RHEL-5? Ever looked at other tools like COPS, SARA, Tiger, Bastille-Linux? Who will be working on this, you or? Will all contribs be accessable w/o restrictions? What does STIG bring to the table others can benefit from?

Thanks for the post. In answer to your questions:

"How does the STIG relate to work done by NIST? CIS?"

The STIG's are what is used as a baseline security screening for DOD systems. It's what is mandatory for DOD systems to comply with. You have to comply 100 percent, or if you don't comply 100 percet you have to write a Risk Assessment and someone signs off saying that any remaining vulnerabilities that cannot be fixed are "accepted risk". NIST does a similar "baseline", only it's for everyone else. Personally I think the NIST stuff is more policy. I have actually had to ask the question to a client, "Do you have a policy written on how to write your security policy?"

That got a funny look!!

Anyone can use the DISA SRR scripts to "analyze" the security posture of any system. For commercial company's they usually don't like the DISA STIG's guidelines because they are way more strict then say NIST.

"What's the current state of the STIG scripts for GNU/Linux?"

The scripts that are used by DISA (SRR's) dont actually fix anything. They just analyze. I can post the link if you would like to run one on your system. They are pretty self explanatory.

"Does it cover RHEL-5"

Yes, it can run on multiple platforms ranging from Sun to Fedora to AIX to RHEL. But yet again, they just analyze. No automated fixing.

"Ever looked at other tools like COPS, SARA, Tiger, Bastille-Linux?"

I have used S.A.R.A., for vulnerability scanning. But not any of the other tools.

"Who will be working on this, you or? Will all contribs be accessable w/o restrictions?"

Yes, 100 percent open. I'm very new to the programming game, so it's not like I will be able to pull this together on my own. I just wanted to probe and see if anyone was even remotely interested in any of it.

"What does the STIG bring to the table others can benafit?"

The DISA STIGS/SRR's are great tools for looking at single host's security posture. Does it cover all the bases? Absolutely not! But its another good free tool to use when securing a system and if something can be created that will aid the "lockdown" process I think it would be a great time saver.

Yes, please do post the link to the most current SSR tarball.
BTW, does "new to programming" mean you can't write Bourne compatible shell scripts?

http://iase.disa.mil/stigs/SRR/index.html

The link above has all the available DISA SRR's.


lol, yes I can Shell Script.

OK, OK, just had to ask. Now I've got this UNIX_51_15January08.tar.bz2 (which was wrongly named _tar.bz2 and some files/dirs have wrong permissions and the spec mentions RHEL-3,4 but not 5). It's huge, addresses a lot of *NIX and carries around stuff like john. Where should we* start?

* We as in it's FFA I'm sure, so come on. Don't just eyeball this thread.

Yeah,

It's a beast. I think the first part will be addressing the checks that are easily fixable. The software update ones should be completely eliminated.

What do you think?

I'm cool with that. Let's just see where it ends up.

BTW: is there a simple document listing all compliance checks w/o any fluff? Like just "must have IP, must have hostname (as in FQDN)" and not anything else? Could help track things more easily. Are you aware of certain areas in which checks aren't complete or nonexistent? Are there any checks you would like to see? Or are you just aiming for this to be STIG-compatible and nothing else?

In any case I'll start by reading the Start-SRR.

I'm up for anything. After hearing about Security Blanket (Which puts a *nix box into STIG compliance) I thought there might be some intrest in having an open source counterpart. But that's just me

at USD 200 per server...

Anyway, initially it seems a bit slow until I found out he's doing a load of stuff with find scripts. Pretty nifty. After killing Linux/GEN003000 (hang) and after the Manual Review (interesting but some issues aren't GNU/Linux or could be tested for) I get the impression it's done quite the bit of checking. It's just a bit of a let down on the reporting side ;-p Definately workable. Now on to read the tests it actually performs and compare them to what the UNIX Guideline says about it and see if it could be improved.

Found this thread via Google and thought I'd pipe in. I've been battling STIGs for a few years now and have been praying someone would develop a script that would help automate the process.

I have tried out Security Blanket, and the coolest thing they have going is the ability to not only scan the system and fix insecure things, but to be able to undo those actions easily.

For me, the biggest problem with STIGs has come when you have to update/patch your system. In some areas, things are so locked down, applying patches from, say, Red Hat Network, will hose everything up severely. So, having a tool that can *undo* STIG lockdowns, let you apply patches, then *redo* the STIG lockdowns, would be awesome. Security Blanket does that, but as mentioned above, it is $200/server and then $40/year for updates.

I'm not so great at shell scripting so I'm not sure I can lend a hand there, but here's a link to the UNIX STIG documentation, which may be of help:

http://iase.disa.mil/stigs/checklist...1_20080315.zip

Hopefully you people not on a .mil domain can access that.

Good luck, and let me know if I can do anything to help!

Thanks for the post. I unfortunately haven't made an inch of progress in this "script".

I'm actually out on client side and speaking with some of the admins there are some GREAT tools that are coming down the pipe to help with disa/FIPS/NIST stuff. I dont recall the program name, (I will try and scrounge it up) but it supposedly you do something to the effect of pick
disa/nist/fips, etc and then select lock down. Bang your compliant.


I'm guessing it will break some stuff, but thats how the cookie crumbles.

Also it will do routine checks to ensure nothing has been changed on the systems.

Sounds pretty interesting.

R/

Vince

We also use security blanket and it works great. The nice thing like stated above is that fact that it is not extremely expensive and it gets updated every 3 months when a new STIG comes out.

And is on the approved software list

this is exactly what Security Blanket is.


I think the GOVT. is going to try to change the STIG at some point to just say

Is SELinux enabled and running

yes= compliant
no= non-compliant


Sad to see but thats what it looks like.

Yeah, I was tracking on security blanket. Does it do audits. So after you click the "fix me" button, can you have it go back and report percentage of compliance?

yes you can and you can also do baselining with security blanket.