IT Risk Assessment in the Military

I am a civilian employee working for the Air Force.  Part of my job is to perform recurring assessments on the systems I maintain and report the status to our IT Security Office who decides what, if any action to take on findings.  The CISO will then either decide to accept some risks or approve what is done to mitigate them.

As I mentioned in my first post we use Security Technical Implementation Guides (STIGs) provided by the Defense Information Systems Agency (DISA) to perform these evaluations.  Some of the STIGs are automated and others are simply checklists used to check a system for compliance with the STIG guidelines.

These checks are performed before a new system is brought online and recur periodically throughout the life-cycle of the system.  When we complete a review, an IT inspector goes through the checklist and verifies the findings and then a plan is made to mitigate or accept the risks.

As another layer of verification, organizations are inspected by an outside agency that also runs the the STIGs on systems. 

This multi-layer risk management system has proven very effective.

Here is the link to the DISA STIGs that are available to the public:

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

DNSSEC - Part 4

This week, we'll look at some of the maintenance tasks involved when running DNSSEC.

1.  Periodic zone re-signing-this will most likely be dictated by a parent zone or organization.  The reason for re-signing is that the longer signed records are available to the public, the greater the chance that your private key components could be cracked.

2.  Key rollover-both the KSK and ZSK should be rolled over to new keys periodically.  This is again due to records being available that may lead to the private keys being cracked.  NIST recommends a 60 day (or so) rollover period for the ZSK and yearly for the KSK.  The ZSK is more exposed to the public, hence the shorter rollover period.

There are two methods for key rollover; double-signing and pre-publish.  Double-signing involves creating a new KSK, ZSK or both and signing with both the old and new keys.  Then after waiting at least a full TTL, re-sign the zone using the new key(s).

Pre-publishing is sending the new public key (s) to your parent and signing with the new key(s) after ensuring the parent has your public keys.

3.  Key management-again, the private keys should be kept secure and offline if possible.

4.  Firewall requirements-DNSSEC greatly increases the size of packets that come back in a query response.  See below:

A normal (non-DNSSEC) dig query for www.fbi.gov.  Note the size of the CNAME line.

;; QUESTION SECTION:
 ;www.fbi.gov.   IN A
 
 ;; ANSWER SECTION:
 www.fbi.gov.  300 IN CNAME www.fbi.gov.c.footprint6.net.
 www.fbi.gov.c.footprint6.net. 230 IN A 198.78.202.118

Now, a DNSSEC-enabled gig for the same record.  Again, pay attention to the
CNAME line.

;; QUESTION SECTION:
 ;www.fbi.gov.  IN A
 
 ;; ANSWER SECTION:
 www.fbi.gov.  259 IN CNAME www.fbi.gov.c.footprint6.net.
 www.fbi.gov.  259 IN RRSIG CNAME 7 3 300 20121211184410 (
     20120912184410 58969 fbi.gov.
     wdRHrnOp53u8b4fs1vhV5YdAChNO/dsFQ3dxgyYoWKox
     nbA8Mez4q7hE0lWTM7JFqNBjF+7U2YKYPkPbMZHa1U0I
     2tbU690IYs3HVxONoiq61jPMz9Ox2693ZFNCl3xtuBCG
     +UWzXpwXFUcgTWz9qefx2kA/7CDZnMqnTq/nKSQ= )
 www.fbi.gov.c.footprint6.net. 189 IN A 198.78.202.118

As you can see, the CNAME that came back from the DNSSEC-enabled query was much larger than the non-DNSSEC-enabled answer.  This can be an issue with firewalls that are not configured to allow packets larger than 512 bytes to pass through.

Another potential firewall issue is that DNSSEC requires both UDP and TCP ports 53 to be opened.

That about covers maintenence.  Next week will be a surprise for us both, since I am about done with DNSSEC...

DNSSEC - Part 3

So, now we'll look at how to enable DNSSEC on a BIND authoritative DNS server and specifics on the KSK and ZSK this week.

Here are some steps required to get DNSSEC up and running:

1.  Enable DNSSEC -this requires a simple line dnssec-enable yes; be added into the named.conf file.

2.  Generate the KSK and ZSK public/private keypairs - this requires pre-planning as to what algorithm to use, what the key size will be and the names of the generated keys.  NIST recommends the KSK be 2048-bit and the ZSK be 1024-bit. RSASHA1NSEC3 is a very commonly used algorithm along with the NIST recommended key sizes.  The UNIX command for generating keys is dnssec-keygen.  Details on this command can be found in the NIST Secure DNS Deployment guide or a look at the dnssec-keygen man page.

3.  Plan for and Implement Secure Storage for the Private Keys - dnssec-keygen will create both the public and private keys.  Their names will be K"keyname".+xxx+yyyyy where xxx is a number representing the algorithm and yyyyy is a system generated number for the key.  Additionally, the two generated keys end in .key for the public key and .private for the private key.  So if we create a key, bubba using RSASHA1NSEC3, the two keys will be:

Kbubba.+007+12345.key

Kbubba.+007+12345.private

Remember the 12345 will be a system generated number, but the public and private keys will match.

It is a definite best  practice (and good idea) to keep the private keys stored off line.  Be it removable media of some sort, or a secure storage device they should be protected.

4.  Send KSK Public Key to Parent - this will establish the chain-of trust we discussed last week.

5.  Sign the Zones - this is done using the command dnssec-signzone.  In order to do so, your private keys must be pulled out of storage and put on the system since both the public and private keys are required to sign the zones.  Here also, for more details on the dnssec-signzone command, consult the NIST guide or man pages.

So, that will do it for this week.  Next week, we'll look recurring DNSSEC maintenance tasks required once you are up and running, cheers!   

DNSSEC – Part 2

Last week we took a quick overview of what DNSSEC is and what it does and does not do. As promised, this week we'll take a quick look at how DNSSEC works.

As I stated last week, DNSSEC is intended to secure the DNS query-response process. It ensures you are getting the correct answer (or verified non-existence) from the authenticated DNS server that is truly authoritative for the record requested. There is a caveat here, the querying server must be DNSSEC-enabled in addition to the answering server in order for this process to work properly. The DNSSEC authenticated reply from an authoritative server is known as a signed response.

DNSSEC is able to do so by establishing a chain-of-trust between a DNS server and it's parent servers. For example if the .gov servers hold DNSSEC records for fbi.gov, then there is a chain-of-trust established between the .gov and fbi.gov authoritative DNS servers.  When a zone is DNSSEC signed without a chain of trust, that zone is known as an island of trust since it is operating on its own as far as DNSSEC goes.

DNSSEC performs these authentication and chain-of trust actions by using two different types of asymmetric keys (asymmetric keys are those having two components; a public key and a private key) a Zone Signing Key (ZSK) and a Key Signing Key (KSK).  The ZSK is what is used to sign a zone--specifically the private component of the ZSK.  The KSK performs two functions:  the public key is sent to the parent zone DNS server to establish the chain-of-trust, the private key is used to sign DNSKEY key sets that DNSSEC generates when signing zones.

If you'd like a deeper look just google "DNSSEC", or as always check out the NIST Secure DNS Deployment Guide I have referenced in past posts.

Well, that is probably enough to keep your head spinning until next week when we'll go still deeper into the ZSK, KSK and other DNSSEC operations...