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...

DNSSEC - Part 1

So, this week we'll dive head first into DNSSEC.  I'll address some basic background information about what it is, what it does and what it does not do.  It seems to be pretty well misunderstood by many people. 

DNSSEC stands for the DNS Security Extensions which the IETF created to help "secure" the DNS query-response process (resolution).  In a nutshell, when querying from a DNSSEC-capable resolver, DNSSEC ensures you are getting the correct record from the correct server, or a record of non-existence when the record you are looking for does not exist.

Here are some specifics on what DNSEC can and can not do: 

DNSSEC provides:
Data origin authentication
Data integrity verification
Authenticated denial of existence
Cache poisoning protection
DNS hijacking protection

DNSSEC does not:
Provide confidentiality
Prevent Dedicated Denial of Service (DDoS) Protection
Stop IP spoofing

One of the main issues for initiating DNSSEC was to stop DNS cache poisoning where false records are inserted into a DNS server database to divert traffic away from the true intended destination.

Here is a link to a very informative Wikipedia page on DNSSEC:
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

And again, the NIST Secure Domain Name System Deployment Guide is an invaluable resource that includes a very in-depth section on DNSSEC:
http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf

 So, that covers some basic DNSSEC background information.  Next week, we'll open the hood and start examining how DNSSEC does what it does.  Cheers!

Securing a DNS Server, Part 3.

This week, we’ll conclude securing an authoritative BIND server through configuration.

1.  It is a definite best practice to keep master and slave servers isolated from each other.  This means both physically and logically (network-wise).  They should be in completely different areas of a building, or better yet one should be off-site.  This so that obviously a disaster will not wipe out all of your servers.  They should be separated logically by placing them on separate network segments so a failure of a network segment will not take out both servers.

2.  The servers should run some sort of file integrity checking tool also.  Tripwire is a good example of this.  This software can notify you that files on the server have changed.

3.  Protect your server by a firewall, don't just leave it outside to fend for itself.  Put it in a DMZ with some firewall protection.  It can also benefit from ACLs in place on the border routers of your organization.

4. Protect slave servers from false update notifications by using the allow update section in named.conf.  Put the master server IP in this section.

That wraps up this week--next week we'll start looking into DNSSEC.

Securing a DNS Server, Part2.

This week we'll look into the configuration of a DNS server and some things that can be done to make the server more secure.  Again, we are looking at an authoritative BIND server.

1.  Hide the version of BIND you are running.  The bind version can be found using either dig or nslookup.  Bad guys can target their attacks based on the version of BIND you are running. Hiding the version is easily accomplished by editing the configuration file (named.conf).  In the options section, there is a version line.  Simply edit the text in the quotes to something along the lines of "Not disclosed." or whatever you want.

2.  Disable recursion on an authoritative DNS server.  This is a best practice and also a good security measure.  Authoritative servers answer queries, not perform lookups.  With recursion disabled, the server will not build up a cache, thereby preventing a threat for cache poisoning.

3.  Limit zone transfers (and associated notifies) to only between primary and secondary servers.

4.  Secure zone transfers using shared TSIG (transaction signature) keys.  These keys should be changed at least annually.

5.  Disable dynamic updates.  This will prevent unauthorized adding, changing or deleting of zone data.

For more details on these and more actions, please refer to the NIST Secure DNS Deployment Guide in the 2nd week (3 September) post.

That wraps it up for this week.  Next week I plan to finish off securing the server through configuration before we boldly dive into DNSSEC!