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!