COMMENTARY

The 3 urgent security concerns you'll have this month

Whether driven by mandates or new vulnerabilities, June brings worries that need to be addressed

Federal agencies have more than enough security issues to worry about these days. But unfortunately, they may find three new concerns this month, and they should be branded “urgent.” Some of these issues are driven by specific federal mandates; others are motivated by newly discovered flaws. Either way, they need to be addressed.

Security challenge 1: IPv6 expansion. Efforts toward government Internet Protocol version 6 (IPv6) compatibility could further complicate IT security this summer – in ways that many system administrators haven’t imagined.

Here’s the catalyst: The Federal Acquisition Regulation (FAR) will be updated as of July 1 to require all federal agencies to purchase computer hardware, and in some cases software, which has been tested and certified for IPv6 readiness. This certification is performed by a third-party lab, with coordination from the National Institute of Standards and Technology. This will effectively boost the number of IPv6 machines that reside on government networks. The newly certified hardware will join a wide range of routers and servers that already support the protocol. (Agency backbone networks were supposed to be capable of handling IPv6 packets by June 2008.)

Many machines today are capable of operating in “dual mode,” which means they can support either IPv4 or IPv6. But here’s something a bit scary: If you already have IPv6-capable machines running on your government network, you could very well have a small IPv6 network running within your facility – and you might not even know it. On dual stack machines, the IPv6 capability must be shut off unless there is a specific need for it. If it’s not, it may be capable of routing IPv6 packets when they pas through, even if you don’t monitor for that. You have to properly configure each machine to make sure IPv6 isn’t enabled. If for some reason it needs to be enabled, you must to be able to monitor this type of traffic.

Often, firewalls or intrusion detection systems are not configured to recognize IPv6 traffic. This is one of the reasons that agencies should not have inconsistent configuration rules and support for IPv6. Once the transition is made, configuration issues should be addressed across the organization.

Security challenge 2: More DNSSEC dealings. There’s a June deadline looming for the next phase of deploying Domain Name System Security Extensions. First, a quick bit of background. DNSSEC is designed to improve security within the Internet's Domain Name System. It's a set of changes designed to prevent certain type of attacks, including DNS cache poisoning, which is a situation where rogue Internet address information that did not originate from an authoritative DNS source is loaded in the caching of a name server.

The security extensions provide three things: origin authentication of DNS data, confirmation on data integrity, and authenticated denial of existence, if needed. To implement DNS, changes have to be made to DNS servers. The government operates hundreds, if not thousands, of these servers.

DNSSEC adds four new resource record types: Resource Record Signature, DNS Public Key, Delegation Signer and Next Secure.

The federal Office of Management and Budget (OMB) dictates deadlines for DNSSEC in Mandate M-08-23. Per those specifications, internal DNS must be signed by June 2010. If your agency needs details on this implementation, see NIST Special Publication 800-53, Revision 3 issued by FISMA and NIST.

Security challenge 3: Domain hijacking (accidental or otherwise). A couple of months ago, an information technology administrator somewhere in China misconfigured a setting, which in turn then exported China’s technique of blocking traffic to some domain names (essentially a man-in-the-middle style DNS spoof). In many cases, it effectively rerouted some traffic through China.

The basic problem is that when an organization has a right to update routing tables on a server, especially a root server, whatever they upload can trickle down, sometimes to multiple regional and local DNS servers, as authoritative DNS information. There are safeguards against this, but, as this incident shows, things happen.

As government agencies look toward externally hosted cloud solutions for many of their software applications, the issue of possible domain hijacking needs to be taken more seriously. Since the .gov and .mil domains are hosted and control by the federal government, they have a greater level of protection. Agencies should keep that in mind when they are setting up the addresses for their cloud solutions.

Oh, by the way: To further complicate matters, last year the Internet Corporation for Assigned Names and Numbers (ICANN) approved a plan for the support of non-Latin based alphabets within domain names. In May, three Arab nations--Egypt, Saudi Arabia and the United Arab Emirates--were the first to receive domain names written in Arabic script.

Other languages, including Chinese, Thai and Tamil, will soon follow.

Happy routing!

 

The 2014 Federal 100

Get to know the 100 women and men honored this year for going above and beyond in federal IT.

Reader comments

Thu, Jun 10, 2010 Jeffrey A. Williams Frisco Texas

I largely agree with Shawns stated concerns, especially in regards to DNSSEC. The current DNSSEC project has some additional yet to be fully recognized security holes as big as a barn door. I have in the past already articulated the problem with the method of DNSSEC implimentation that is currently being moved forward, however slowly. IPv6 itself is not a problem nor is the hardware. But without IPSEC complementing IPv6 if auto install is the desired implementation method leaves government workstations and IPv6 capable hardware for servers exposed to a number of already recognized attacks, but these can be mitigated if delt with durring implimentation. Vista is a poor default platform as it's many already found and fixed security holes give testiment too. Better would be to move to either Windows 7 or another OS platform.

Wed, Jun 9, 2010 Dave

Is this new FAR update in addition to that which went into effect last December, or is this just old news? In any case, it will NOT significantly increase the number of v6 capable machines in the Federal Government, since the Federal Desktop Core Configuration (FDCC) is already based on Microsoft Vista, which is dual-stack capable: these machines are already all over your network! If your agency doesn't already have an IPv6 office of some sort, planning for a secure and orderly transition, you're well behind! Fear-mongering about IPv6 is the LAST thing we need right now, because the standard security answer will be to shut it off completely... even as we near the date when the v4 address space will be exhausted!

Fri, Jun 4, 2010 CJ

The computers can't tell the difference between "latin" and Farsi or even Klingon - it's all binary IP addresses to them. As long as the translation tables work it really doesn't matter what language the URL's show up in in the browser.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above