Monthly Archives: March 2012

RSA 2012 Day 4: IPv6 Vulnerability Management and BYOD

Two good sessions today, one on the state of vulnerability management in IPv6 and the second on the security issues with BYOD.

The vulnerability management session was interesting in that while Microsoft, all Linux variants, Cisco, HP, Juniper, Check Point and other OS and network device vendors have been implementing IPv6 capabilities into their products, the vulnerability management vendors have been sleeping.  They are just coming to the realization that customers would like to be able to perform vulnerability tests for IPv6 enabled hosts on their networks.  I mentioned in my post yesterday that the primary issue with performing vulnerability scans on IPv6 is the scarcity of the addresses in an IPv6 address space.  It is simply not possible to scan all of the addresses in a single IPv6 subnet to find hosts and to then probe for vulnerabilities in a reasonable amount of time.  The vendors are working on models to do this; however, no final “best practice” solution is available yet.  Some suggestions which were presented are to scan active IPv4 addresses to find the hosts and then check if they are running IPv6, to perform SNMP walks on the routers or switches to determine which hosts are running IPv6, review the CMDB for known hosts or review log files on network and other devices.

In the BYOD session, the primary discussion revolved around identifying the threats to mobile devices in general, but only two possible models for supporting BYOD emerged.   The primary threats to mobile devices as seen by the panel are:

  • Bridging from a mobile device into the enterprise network
  • ActiveSync vulnerabilities
  • Rouge base stations which can eavesdrop on calls
  • Lack of granular controls for many of the mobile OS’
  • Poor password usage since users find it difficult to type in complex strong password

The two models which were discussed for supporting a BYOD model are to either require the user to accept corporate policy controls (e.g. encryption, virus scanner, etc.) on their personal device by installing an enterprise MDM solution or to implement local virtual containers on the devices.  The container solution would solve the problem that if a user leaves the company, only the corporate container can be wiped and the personal container can remain in place.

In both situations, a security policy should define what applications will be made available to users who bring their own devices. This policy should be based on the criticality and security requirements of the applications as well as the usability of the applications.  For example, does it make sense to allow access to spreadsheets from iPhones when they really cannot read or manipulate them in any practical manner?

RSA 2012 Day 3: Securing IPv6 and Moving to the Cloud

The first session today covered the basics of security in IPv6.  IPv6 contains some features which provide it with some additional security.  Some are not actually features designed into the protocol but just exist because of the nature of the IPv6 address space, for example brute force scanning of IP addresses will no longer be possible with IPv6 just because of the sheer size of the address space you will need to scan.  Of course on the down side, this feature makes vulnerability scanning also impossible if it is based on scanning IP addresses. The same is true when using ULA addresses for internal private addressing (like the 10.0.0.0 in IPv4).  Since the number of ULA networks is so great, each company can pick their own and there will be virtually no chance that there will be an overlap with other companies. Worms will no longer be able to spread just by counting up IP 10.0.0.0 addresses and infecting the next active device.  Finally designed in features, such as IPSec or secure neighbor discovery do secure the protocol, howver, since IPSec is no easier to manage in IPv6 than it is in IPv4, it does not provide any additional security over using IPSec in IPv4.

Administrators should also actively implement certain controls to secure IPv6.  Controlling the boundaries of where headers can be distributed, controlling rogue router advertisements through using IPS and filtering at the layer 2 switches, and blocking tunnels (6to4, 4to6, etc.) from any but approved tunnel endpoints will help to secure an IPv6 based network.

The final recommendation is to develop an IPv6 security policy which parallels an IPv4 policy.  Everyplace where you have a policy which references IPv4 should also have a statement about IPv6 plus there should be some IPv6 specific statements to cover the IPv6 specific features.

In the Cloud session, the CTO from NASA’s Jet Propulsion Labs discussed how they use public and private clouds within their organization.  They have developed a very interesting model of using both public and private clouds depending on what the use case is for the data and applications being implemented.  The model allows the users to define their requirements for their application in an on-line tool and they will be given options showing which cloud based services are allowed to be used based on security level, performance, availability, cost and other factors.