Network World today published an article by Bruce Sinclair on IPv6 security risks (https://www.networkworld.com/news/tech/2013/110413-ipv6-security-275583.html?hpg1=bn), based on a survey of the 95,000 community members at the gogo6 discussion forum (http://www.gogo6.com/forum).
So what are the Top 6 IPv6 Security Risks you ask?
1. Lack of Training/Education – Based on the DHS Framework Categories (http://csrc.nist.gov/nice/Sept2011-workshop/presentations/Tuesday/Tues_Framework_Maxson_and_Homeyer.pdf) was created based on the category type and user type to help provide a career path for professionals and provide a framework for hiring. IPv6 needs seven unique flavors of IPv6 training to address the requirements of: Securely Provision; Analyze; Operate and Maintain; Support; Operate and Collect; Protect and Defend; and Investigate. Currently all training I have reviewed is focused on partially educating the “Protect and Defend” and “Operate and Maintain” communities, and not fully focused towards addressing the unique concerns and needs.
2. Security device bypass and unfiltered IPv6 and tunneled traffic – This is a hard one, as we have so many tunnels, and by default tunnels are never officially provisioned and approved, but more likely setup to fix a point problem. In support of the transition of users from native IPv4 network, through dual stack and finally to the native IPv6 networks, we now have over 24 methods applied, some for a reason and other accidently. Sadly the vast majority of Intrusion Detection Systems (IDS), Intrusion Prevention System (IPS), Deep Packet Inspect (DPI) and Next Generation Firewalls (NGF) have little if any ability to detect or stop these tunnels.
Stay tuned to this blog, future book and classes for more details on how to detect and bypass existing security controls using IPv6.
3. Lack of IPv6 support at ISPs and Vendors – for over 12 years I have been banging the drum to security vendors and ISPs about support of IPv6. Just within the last two years we have seen support from both, but not at the level which will mitigate the security risk. Based on the capital expense (CAPX) of changing our current technology and the lack of procurement policies requiring all new product insertions over the last few years to support IPv6, they are budgeting to integrate systems into the environment which in many cases leads to security and connection problems for their customers. Both the ISP’s and Vendors have been claiming for years that customers are not asking for it, but in many cases no systems exist to document these requests.
4. Congruence of security policies in v4 & v6 – Each time I talk to a customer, speak at a conference or teach a class, I am surprised at the number of people that apply their knowledge of IPv4, and very limited knowledge of IPv6 as justification for not making policy changes. In support of the assessment, auditors and security management, I have begun collecting changes in policies required to support IPv6 and eventually change the policies when IPv4 is no longer used. Some changes are simple, but others require a re-think of the architecture and processes.
As a reference we will use the National Institute of Standards and Technology (NIST) Special Publication 800-54 revision 4 (csrc.nist.gov/publications/drafts/800-53–rev4/sp800-53–rev4-ipd.pdf), to provide some of the details needed for security IPv6 networks to be integrated into the people, processes and technology across the lifecycle of all systems.
Example 1: “AT-3 ROLE-BASED SECURITY TRAINING”, requires among other things, the procurement manager to take security training, and in this context training on procurement of IPv6 devices, and some sample language to use. In addition,
Example 2: “PL-7 SECURITY CONCEPT OF OPERATIONS”, requires the people developing the security CONOPS for information systems to update the existing document, and create an all new document with the knowledge of IPv6 being the network layer of these systems.
Example 3: “IR-5 INCIDENT MONITORING”, requires that organizations track and document information system security incidents. Is the field that contains the IP address fixed? Does it support IPv6 sized addresses?
In short, IPv6 requires many large and small changes to integrate this new network protocol into the security of an organization.
5. Bugs in new code – Bugs can enter code by way of the protocol specification, business decisions on what should be included, programming libraries, Integrated Development Environment (IDE), meshing old code with new code, direct coding mistakes, or interface oversights. With IPv4, it has been over 43 years and we are still finding problems. Last year, I wrote a one-day class on common coding bugs and processes of migrating to IPv6 network securely. With only limited interest, I had one group engage me on the training, and as a result discovered a code bug when using a dual stack proxy in front of an IPv4 only Windows 2003 server with IIS.
6. Absence of NAT – This protocol is not a security feature; if it were then why did IETF create multiple specifications on how to bypass this feature? Understanding how to securely architect an IPv6 network is different than architecting an IPv4 network. Yes, many vendors want to tell you they are the same, because they are generally unaware of the agile security methods and do not have products in that space. I spoke about this at Internet Security Days 2013, only a month ago about the changes required and the benefits of easier management and far more immunity to attack. You can find the slides at this link: https://scientifichooligan.files.wordpress.com/2012/02/isd2013-shifting-security-paradigm-joe-klein-v4.pdf