Sunday, May 12, 2013

Security Checklists  

   I am a US government civilian IT Specialist.  Part of my job is to run security checks on the equipment my shop maintains.  Our guidance for running these checks is a series of Security Technical Implementation Guides (STIGs) published by the Defense Information Systems Agency (DISA).  We commonly refer to these checklists as DISA STIGs.  For what it's worth, I use the DISA DNS STIG almost daily in my work.

   These checklists are provided for almost every IT application and system you could imagine.  Here is a link to the "master list" of the checklists:

http://iase.disa.mil/stigs/a-z.html 

   These checklists are not simply run down the list and check a box for each item.  They are arranged as specific checks with something to check, an explanation as to why the item is of concern, information about applicability (version info, etc.) and a severity level for the finding if it is not compliant. Normally, there is also a recommended fix action for each item. The finding categories are ranked as follows and described using the DISA explanations for the severity levels:

CAT I (highest severity)  - "Any vulnerability, the exploitation of which will, directly and immediately result in loss of Confidentiality, Availability, or Integrity. An ATO will not be granted while CAT I weaknesses are present."  (DISA, 2012)

Cat II (medium severity) - "Any vulnerability, the exploitation of which has a potential to result in loss of Confidentiality, Availability, or Integrity. CAT II findings that have been satisfactorily
mitigated will not prevent an ATO from being granted.
" (DISA, 2012)

CAT III (lowest severity) - "Any vulnerability, the existence of which degrades measures to protect against loss of Confidentiality, Availability, or Integrity. Assigned findings that may impact IA
posture but are not required to be mitigated or corrected in order for an ATO to be granted.
" (DISA, 2012)

   I should further explain that ATO stands for Authorization to Operate, i.e. allowing the system/application to be placed into production.  So, as it says above, CAT I and CAT II findings must be mitigated in order for a system to be granted an ATO.

   Here is an example to CAT I findings in the DISA Network Policy Security Technical 
Implementation Guide, Version: 8 Rrelease 14:

ISP connections exist without approval.
No deep packet inspection- must use firewall/proxy device with deep packet inspection enabled.
Deny by default policy not implemented - for a firewall and/or perimeter router.
Unencrypted passwords stored offline.

  These are just a few of the CAT I items.  

   So, clearly these checklists were developed by the military, but they are unclassified and readily available for anyone to download and use. I contend they would be a fantastic reference for any organization to use. 



Sources:

DISA. Defense Information Systems Agency, (2012). Network infrastructure technology overview
             version 8, release 5

DISA. Defense Information Systems Agency, (2013). Network policy security technical implementation guide version: 8 release 14

No comments:

Post a Comment