<?xml version="1.0" encoding="utf-8"?>

<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <title>Shaul Efraim</title>
  <link href="http://huffingtonpost.co.uk/author/index.php?author=shaul-efraim"/>
  <updated>2013-05-24T16:52:13-04:00</updated>
  <author>
    <name>Shaul Efraim</name>
  </author>
  <id xmlns="http://www.w3.org/2005/Atom">http://www.huffingtonpost.co.uk/author/index.php?author=shaul-efraim</id>
  <rights>Copyright 2008, HuffingtonPost.com, Inc.</rights>
  <subtitle>HuffingtonPost Blogger Feed for Shaul Efraim</subtitle>
  <generator>Good old fashioned elbow grease.</generator>

<entry>
    <title>Firewall Management, IPv6 and You</title>
    <link rel="alternate" type="text/html" href="http://www.huffingtonpost.co.uk/shaul-efraim/firewall-management-ipv6-_b_1650671.html"/>
    <id>tag:www.huffingtonpost.com,2012:/theblog//3.1650671</id>
    <published>2012-07-05T08:06:37-04:00</published>
    <updated>2012-09-04T05:12:15-04:00</updated>
    <summary><![CDATA[Created 30 years ago, IPv4 has a 32-bit addressing scheme and can support approximately 4.3 billion devices connected directly to the Internet.  Well aware that IPv4 addresses would eventually run out, the IETF created IPv6 as an upgrade to IPv4]]></summary>
    <author>
        <name>Shaul Efraim</name>
        <uri>http://www.huffingtonpost.com/shaul-efraim/</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://www.huffingtonpost.com/shaul-efraim/"><![CDATA[Created 30 years ago, IPv4 has a 32-bit addressing scheme and can support approximately 4.3 billion devices connected directly to the Internet.  Well aware that IPv4 addresses would eventually run out, the IETF created IPv6 as an upgrade to IPv4.    IPv6 features a 128-bit addressing scheme, supports a mind-numbing amount of devices and delivers much needed security and performance improvements.<br />
<br />
It is well known that most security incidents are caused by human error. The lack of experience and training for those IT professionals dealing with IPv6, will only make mistakes more likely. Knowing that IPv6 migration will be a fact of life, here are some measures you can take to ensure migration efforts will not impede firewall management:<br />
<br />
1)	Understand what IPv6 means to your network, people, and vendor partners: Although many potential issues can be avoided by testing IPv6 conditions in a lab or by running pilots, as with any IT deployment, there are some scenarios that even the most savvy IT people would not have known to anticipate.  the only way your team will learn what the issues are, is by experience. For example, network devices or firewalls could become overwhelmed and fail when used in an IPv6 environment, allowing data traffic to pass without full inspection or resulting in an outage, or not.  Talk to your firewall and network infrastructure vendors to see where they are at with IPv6 and what sort of resources they can provide to aid with migration.  If you outsource firewall management, get educated on what your MSSP or service provider is doing for IPv6.<br />
<br />
2)	Avoid having to manually type IPv6 addresses: Because writing IP addresses manually is a highly error-prone, endeavor, you should minimize this.  If you have to write an address, do it once and whenever possible, assign a human readable name to it and use the name in all places (firewall rules, policies, ACLs etc.).In order to minimize the duplication of address definitions, you need consolidated management systems so that IPv6 addresses are stored on a central repository and can be sourced as needed - for example, host naming should be consolidated across firewalls and routers, even from different vendors.  For those organizations running Next-Generation firewalls, incorporate your firewalls with Active Directory to avoid having to manually enter user addresses.<br />
<br />
3)	Things will go wrong. Be prepared:  IPv6 increases complexity, which is already beyond manual control on most enterprise firewall policies.  But if you plan ahead, when something does happen, you will be in a good position to troubleshoot. From a process and operations perspective, the simpler the better. Make sure changes are properly and clearly documented so that anyone can understand what the actual change was, why it was made, who made it and when. <br />
<br />
4)	Deploy network management tools that understand IPv6: Look for tools that will help analyze IPv6 addresses, objects, rules and ACLs across networks and security devices.  Additionally, look for network management tools that can provide reverse lookup for any IPv6 address to its human readable names.  Do not be the person that gets stuck having to manually troubleshoot mistyped IPv6 addresses across multiple firewalls.<br />
<br />
5)	Upgrading and automating: Chances are external people you are working with on your IPv6 migration efforts are working with others as well.  Any tips or best practices specific to IPv6 migration or in general withthe systems or products they work with should be welcomed to ensure that systems are optimized for future needs.   The processes you automate are likely to stick for quite some time  - take the time to set things up in a way that is just aligned with the strengths of the product(s) your deploying, standard operating procedures and the culture of your company and team.<br />
<br />
While it may not be of consequence to end users, IPv6 migration will be a big deal to enterprise IT and particularly network and network security managers. IPv6 has been in use for many years, it has been deployed on relatively few networks.   Because people are less familiar with it, they are less likely to spot mistakes. With IPv6, security practitioners have a chance to get ahead of the game and bake best practices into IPv6 processes and operations instead of bolting them on after the fact.  Lessons learned and best practices will come from trial and error, information sharing, and by supporting industry initiatives such as IPv6ActNow.com and World IPv6 Day.  Let's not waste the opportunity to do things right.]]></content>
</entry>

<entry>
    <title>The EU Data Breach Directive Reminds Us That It's About Respecting Customers Not Just Ticking Boxes</title>
    <link rel="alternate" type="text/html" href="http://www.huffingtonpost.co.uk/shaul-efraim/the-eu-data-breach-direct_b_1509735.html"/>
    <id>tag:www.huffingtonpost.com,2012:/theblog//3.1509735</id>
    <published>2012-05-11T12:28:02-04:00</published>
    <updated>2012-07-11T05:12:13-04:00</updated>
    <summary><![CDATA[New 24-hour data breach disclosure rules are a golden opportunity for organisations willing to embrace automation.]]></summary>
    <author>
        <name>Shaul Efraim</name>
        <uri>http://www.huffingtonpost.com/shaul-efraim/</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://www.huffingtonpost.com/shaul-efraim/"><![CDATA[New 24-hour data breach disclosure rules are a golden opportunity for organisations willing to embrace automation. <br />
<br />
It's not often that a single speech has the power to reshape the computing industry, but EU Justice Commissioner Viviane Reding's confirmation in a January 2012 address that the European Commission is planning a raft of new directives on data security will come to be seen as an important turning point.<br />
<br />
The Directive includes a number of tough new provisions on data handling, but the element that will give security professionals the most immediate anxiety is the insistence that organizations doing business in the 27-nation EU zone inform national information commissioners of data breaches affecting consumers or citizens within 24 hours, or risk heavy fines for not doing so.<br />
<br />
This is a radical jump. Having been under little or no obligation to formally disclose a data breach in most EU countries, companies will suddenly be required not only to inform the authorities but do so in some detail on an accelerated timescale.  Moreover, the change will affect not only companies in the EU but those doing business in it, making the Directive the first de facto global data breach law.<br />
<br />
Informing the authorities that a breach has been discovered sounds straightforward but is anything but.  Assuming administrators have evidence that something has gone awry do they have the tools to say precisely what without delay?  What sort of reporting systems do they have to explain the extent of a breach?  Do possible security failures have any regulatory and legal consequences and if so, what? <br />
<br />
A major consequence of this development is that old-fashioned periodic, manual security audits and the manual configuration processes that underlie them should be viewed heading for obsolescence. <br />
<br />
Currently, security is often measured for regulatory and compliance purposes through an external audit that takes place quarterly or annually, depending on the business sector. Some organizations also perform more regular internal checks, but the design of these is open to interpretation and their frequency varies from organization to organization.<br />
<br />
The reality of the data breach Directive is that administrators could be asked to audit their security stance at any moment in time as a breach is uncovered, with only a few hours notice. Referring back to an audit possibly months or weeks in the past will be useless; CISOs will require an overview of security policies, compliance and data protection that reflects what is happening at the moment the request is made. <br />
<br />
This makes complete sense - can any company possibility understand its security state using an audit that is possibly months out of date? Here the Directive imposes an important level of discipline organizations should welcome. <br />
<br />
What such continuous auditing does do is render manual assessment impractical. The solution - automated auditing in real time - goes from being a useful convenience to an essential component of any security infrastructure.<br />
<br />
Today, realtime security and auditing requires that organizations integrate information from multiple types of hardware system, and across a range of vendors that generate reports through proprietary management consoles. On top of this any reporting infrastructure must also make sense of the flow of security data from different elements of the system, comparing this to a set of security policies. At any moment, security managers must be able to react quickly when a particular setting infringes the policy and have the means to describe what action was taken and why.<br />
<br />
Although new reporting systems will be needed to build such an infrastructure, a key issue is whether this change from causal to mandatory and continuous auditing will be viewed positively by the people tasked with putting it into practice, the security professionals themselves. This is the biggest unknown of the data breach Directive - how will professionals interpret and react to it?<br />
<br />
A recent survey of 100 network managers by Tufin Technologies sheds some light, finding 42 percent believing that the Data Breach Directive would lead to an increased risk-awareness within their organization. A third believed that their attitude towards continuous compliance had changed as a result of the new regime, with just over half convinced that automated audits would make it easier to comply with the Directive.<br />
<br />
Close up, attitudes probably vary from individual to individual, organization to organization, some seeing the Directive as more of an aspiration, others as the medicine needed by an industry that even after a swathe of data breaches remains complacent.  <br />
According Jericho Forum board member, Andrew Yeomans, the Directive serves to focus security professionals on data security over systems.<br />
<br />
"From a Jericho Forum viewpoint, any strengthening of regulations is an incentive to implement pervasive data-centric security, so the data is protected wherever it is," says Yeomans.<br />
"The Jericho Forum has highlighted that the 'perimeterized' [that is, traditional] model misses many possible breaches, especially data that has been intentionally passed to other organisations, which subsequently suffer a breach."<br />
<br />
His worry remains 'false positives' which underlines the need for accurate realtime auditing and monitoring. "The regulators may also get overloaded with potential data breach reports that turn out to be false alarms, if only 24 hours is allowed for any initial investigation," he warns.<br />
Far from being an imposition, the arrival of the EU Data Breach Directive could serve as a huge opportunity to impose a rational design on security that rewards the best practices and the companies willing to bring them into effect. <br />
<br />
As daunting as it appears, the Directive's biggest plus is its scope, which imposes the same rules across the 27-nation EU zone and beyond. This creates short-term hurdles but the pay-off is potentially huge. For the first time, multi-national organizations will no longer have to interpret a confusing array of data breach and protection rules in different territories, allowing for the sort of policy centralisation that can enhance security. For the first time everyone will be playing by the same rules based on a swift response.  <br />
<br />
It is critical that organizations approach the toughness of the directive head on using the right tools and processes, with automated auditing to the fore.  The world of manual, ad-hoc auditing was always one based on assumptions about risk that now, suddenly, much less certainty attached to them. In a world of uncertain security there is no longer time to waste.]]></content>
    <link href="http://i.huffpost.com/gen/566514/thumbs/s-FACEBOOK-DATA-mini.jpg" type="image/jpeg" rel="enclosure"/>
</entry>
</feed>