Application "hardening" procedures

227 views
Skip to first unread message

Steven Siebert

unread,
Jun 17, 2013, 10:55:51 AM6/17/13
to mil...@googlegroups.com
I was wondering if anybody maintains checklists/instructions for application-level hardening.  We're creating a good deal of documentation for applications we use (activemq, glassfish, postgres, etc), in preparation to (finally) handing off the requirements of managing these from the programmers to the administrators, and in the process I've noticed a void between STIGS and actual implementation of application hardening - not unlike at the OS level as well, though individual vendors like RH has done a pretty good job.  If anyone has anything to share (publically), please let me know, and when we finish compiling we'll either include it, or link to it (if it's hosted).  Of course, any "fully baked" solutions such as puppet scripts or chef recipes would be awesome as well -- but it would be important to document what exactly is being done as well.

Anything from containers/application servers to specific applications would be of interest.

Thanks,

Steve

Shawn Wells

unread,
Jun 17, 2013, 11:44:01 PM6/17/13
to mil...@googlegroups.com
DISA publishes requirements for both applications and application
servers. Technically ISSM/ISSEs within DoD should be evaluating both and
apps and their underlying platforms against these standards before
granting ATO's.... but admittedly many just run SECSCAN (which only
checks the OS) and ignore locking down the app itself. It's *fantastic*
you're asking these questions!

The DoD requirements for application servers can be found here:
http://iase.disa.mil/srgs/u_application_server_v1r1_srg.zip

And for apps themselves:
http://iase.disa.mil/stigs/app_security/app_sec/u_application_security_dev_stig_v3r4_20111028.zip

And if you're interested, here's a list of *all* STIGs:
http://iase.disa.mil/stigs/a-z.html

The STIGs are created by DISA for the U.S. DoD, and is a very good
program. NIST has something similar called the National Checklist
Program, which is a centralized government repository of publicly
available checklists. Their URL:
http://web.nvd.nist.gov/view/ncp/repository

We (Red Hat) have published a checklist for JBoss EAP5, and so far DoD
elements have used this in place of a STIG:
http://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=430

I don't particularly understand the politics between DISA FSO and NIST's
National Checklist Program, but it could be a good source for finding
some extra guidance. Perhaps someone has deeper insight into the STIG vs
Checklist program?

Shawn Wells

unread,
Jun 17, 2013, 11:58:53 PM6/17/13
to mil...@googlegroups.com
Also, for those who are working with Red Hat technology, we've been
using the SCAP Security Guide project as the upstream development repo
for our STIGs and security guidance. To date the project has been used
as the upstream source of the JBoss EAP5 NIST guidance, the RHEL6 STIG,
and working on the NSA RHEL6 SNAC Guide. On deck is the first OpenStack
STIG (work begins on that next week, actually!).

1,988 days passed between RHEL5 GA and the RHEL5 STIG, with RHEL6 we cut
this down to 932 through utilizing open source development methods. For
RHEL7 we might actually have a STIG before or *very* slightly delayed
from the general announcement of RHEL 7.0. You mentioned ActiveMQ in
your technologies list, which is part of the Red Hat family. If there is
interest in working together to form an ActiveMQ STIG or NIST Checklist
let me know! It'd be great to identify shared problem spaces within the
Mil-OSS community and begin working on STIGs together.

I'm personally interested in collaborating around Red Hat technologies,
however we're not alone in the 'open sourcing the STIG' mentality. Apple
is performing this work via their SCAP on Apple project:
http://scap-on-apple.macosforge.org/

Within the SCAP Security Guide community we've created a common build
process that can be applied towards other technologies, either within
the SCAP Security Guide umbrella or forked into their own communities.
The SSG has strong RH involvement, but isn't mean to be only for Red Hat
tech!

Reply all
Reply to author
Forward
0 new messages