25

I'm researching OS hardening and it seems there are a variety of recommended configuration guides. I realize the different configuration providers supply different offerings per Operating System, but let's assume (for convenience) we're talking about Linux. Consider the following :

  1. CIS Benchmarks
  2. NSA Security Configuration Guides
  3. DISA STIGs

Is there any obvious differences between these that might compel someone to choose one over the others?

Update: 2014-11-19
Some additional context, per answer submissions that asked for additional detail:

  • I don't have a requirement to harden against a given benchmark or guideline, I'm simply trying to understand the current best practices used in industry & government. However, I do plan to turn my findings into a research paper for class.
  • I will not be audited, except by those that read my paper.
  • My professor and a couple of students may be familiar with the auditing process, but I hope to make my paper approachable for everyone. I'd like to write about how to use a tool to automatically scan a system per some guidelines or vulnerability database. I'm fairly new to this area, but I'm researching OpenSCAP and OpenVAS. OpenSCAP seems more approachable than OpenVAS, and appears to be written to test against NIST standards. I'm not sure which NIST are tested by OpenSCAP, but I'll add NIST the NIST guidelines to my list of guides to consider.
  • Tate Hansen suggested using Nessus for scanning, however I'd like to stick strictly to Open Source applications to suite my needs for this research.
  • A sub-question, it looks like the NIST standards guide for hardening is SP 800-123 and SCAP is simply a format (XML?) for tools to perform and communicate analysis of a system. Is that correct?
blong
  • 359
  • 1
  • 3
  • 9
  • 1
    I am a security practitioner and would love a copy of your paper. We are currently implementing a hardening process and trying to decide between these standards. Al almon at outlook dot com –  Apr 14 '15 at 13:23
  • I like your answer security guy. Security is objective but subjective to a point. Experience trumps all. To the newly initiated not working with an experienced professional the road will be tough but passable. There are basic principles at work, many security guy outlined. Knowing the OS/App/System you're securing is the real differentiation. The better you know it the better you can determine what it will take to secure it and achieve your security objective. –  Nov 17 '15 at 12:25
  • You said that you will be writing a paper about the differences. Is this done and where can we read it? I'm also looking to cover one of the standards in order to – dobber Nov 11 '16 at 08:45

4 Answers4

8

In general, DISA STIGs are more stringent than CIS Benchmarks. Keep in mind that with STIGs, what exact configurations are required depends on the classification of the system based on Mission Assurance Category (I-III) and Confidentiality Level (Public-Classified), giving you nine different possible combinations of configuration requirements. CIS usually have a level one and two categories.

OpenVAS will probably suit your needs for baseline/benchmark assessment. Nessus will also work and is free for non-commercial use up to sixteen IP addresses. For commercial use, it's still quite affordable.

I have yet to find a comprehensive cross-walk for these different standards. The best attempt I have seen thus far is here (a Web Archive copy): http://www.dir.texas.gov/sitecollectiondocuments/security/texas%20cybersecurity%20framework/dir_control_crosswalk.xls. This spreadsheet, however, is a controls comparison, not baseline/benchmarks that I think you are really interested in.

Regarding NIST requirements, yes 800-123 is the baseline document that requires systems to implement the controls found in 800-53A. These requirements differ from benchmarks in that NIST requirements tell you a control that must be implemented, but not exactly how it must be implemented. The Benchmarks are usually very specific in that you must set setting X to value Y.

Hope this helps.

oxr463
  • 290
  • 2
  • 11
user61143
  • 81
  • 1
  • I really like your answer, although the file you're linking to is gone :-/ Has your experience in this area changed in the last few months? Any new thoughts on the topic? – blong Apr 16 '15 at 01:38
  • interesting answer; but the link is broken if you may fix it –  Sep 09 '15 at 20:01
3

One difference is the ease to find a reliable and automated tool to check for compliance. I believe Nessus has templates available for most of the ones you have listed, but some are dated. In any case, I'd choose one that makes it as easy as possible for you to check and stay in compliance.

Tate Hansen
  • 13,714
  • 3
  • 40
  • 83
3

Here are some important considerations:

  • What is the reason that you're hardening against a given benchmark or guideline?
  • Are you going to be audited?
    • Is there a preferred route or route the your auditors are more familiar with?
  • What tools will you use for self auditing?
    • Do those tools have polices or plugins to audit your system against a given benchmark?

If you're just harding your OS because someone told you to be 'secure' you will have less constraints and can reach through each guide and pick your preference. All of the mentioned hardening models will produce a more secure system.

KDEx
  • 4,981
  • 2
  • 20
  • 34
1

Before answering your question, I would like to define a word you used (hardening). According to the all-knowing wiki, I will define it as "the process of securing a system by reducing its surface of vulnerability." To know which approach is right for you, you have to know what you hope to achieve.

Some in the DoD (and other industries) may only apply STIGs while other apply more than just STIGs. This is what use security engineers like to differentiate as the difference between compliance and security. Compliance is checking a box saying that you did... Security is checking that box and looking to see if there is anything else you can further do to mitigate weaknesses.

Additionally, if you look at the Application Security and Development STIG it actually states "The IAO shall ensure if a DoD STIG or NSA guide is not available, a third-party product will be configured by the following in descending order as available: 1) commercially accepted practices, (2) independent testing results, or (3) vendor literature."

One thing you have to understand about DoD policy, is that the policy at the top is not always the end-all/be-all. Frequently there are layers of policy that are required to be followed. The lower level policies can only be stricter, not less strict. So in essence some programs may be required to apply all of the recommendations. However, what you will typically find is that there is often a substantial amount of overlap.

When there is conflicting guidance, the higher precedence policy trumps the lower. For someone trying to "harden" a system, I say err on the side of security. Also understand that any guidance is written by people who can make mistakes. This is why there have been multiple revisions due to type-Os and misunderstandings of a technology.

What happens when guidance breaks something, this is where someone will have to decide if the risk of X is greater than the risk of not being able to use Y.