Posts Tagged ‘IT infrastructure’

Dark Reading’s Kelly Jackson Higgins is reporting that many providers and vendors, including Google, AT&T, Facebook and others – plan to officially go live with IPv6 on this year’s IPv6 Day (June 6). This might sound familiar, as it was last June that more than 400 organizations — including Google and Facebook – enabled IPv6 standards on their websites. Last year, no major outages were reported, paving the way for this year’s official switch.

Even so, an ongoing concern has been whether our technology infrastructure is ready for IPv6. Rainer Enders, CTO of NCP engineering, posed this very question last year in the column “We Need Infrastructure Before IPv6 Becomes a Real Problem” on CTOEdge. Drawing upon his personal experience, Enders illustrated the stark technical reality facing IPv6 implementation:

I live in Walnut Creek, a community less than 30 miles from San Francisco — arguably, the epicenter of technology and innovation in the world. And yet, my community isn’t yet equipped to handle IPv6 or high-speed Internet protocols. If we — just a stone’s throw from Silicon Valley — can’t transition easily to technological innovations, how can we expect anything more from the rest of the country? 

Now, in an encouraging next step, the Internet Society has announced that “Major Internet service providers (ISPs), home networking equipment manufacturers, and web companies around the world are coming together to permanently enable IPv6 for their products and services by 6 June 2012,” reports ZDNet’s Steven J. Vaughan-Nichols.

He adds:

In a statement, the Internet Society’s CTO, Leslie Daigle, said, “The fact that leading companies across several industries are making significant commitments to participate in World IPv6 Launch is yet another indication that IPv6 is no longer a lab experiment; it’s here and is an important next step in the Internet’s evolution. And, as there are more IPv6 services, it becomes increasingly important for companies to accelerate their own deployment plans.”

What this means, exactly, according to the Internet Society is that ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers.”

 Readers, what are your thoughts – is this a step in the right direction? Stay tuned as we feature more experts weighing into the next steps on IPv6 ultimate roll-out.

By Daniel P. Dern

What does the coming of IPv6 mean for companies relying on IPsec for secure site-to-site and remote VPN connections to the company network?

“Nothing would change,” says Rainer Enders, CTO, Americas, for NCP engineering. “From an end-user point of view, there is zero impact at the application layer. Using IPv6 instead of IPv4 will be transparent to the user.”

What does this mean for IT admins responsible for provisioning and administering IPsec VPNs and VPN capability? “You still have to have your VPN application in place, and that application has to be managed, monitored, and controlled,” says Enders. “You want to make sure you have the right technology deployed, for instance at the operating system, patch, and security level.”

IPv6 increases the need to have the appropriate security technology for VPNs and other networking activity, Enders notes. “Static firewalls work fairly well in an IPv4 environment, because there are other layers of protection, such as private addresses. However, with IPv6, the world is ‘flatter’ and much better connected. So IT admins will want a managed-client firewall, and take more security precautions, to focus more on protecting devices.”

Stay tuned for Part 2 on how a company can add IPv6 support.

By Nicholas Greene

We already know that IPsec is here to stay, especially since it’s such an integral part of IPv6. So, how did IPv6 become so ingrained with IPsec? Why was IPsec developed in conjunction with IPv6, and how did it get to where it is today? To answer these questions, let’s quickly revisit the origins of IPsec.

Let’s go back to the 1990s, when (as most people think)  IPv6 was first being developed because of IP address exhaustion. But in reality, along with the address exhaustion, something else was abundantly clear to the Internet Engineering Task Force (IETE). During its inception, the Internet was a relatively private technology. Truth be told, I don’t think the original technology was ever intended to become the public platform that it is today. And as most people involved with networking will tell you, security for a private network is a very different beast than from public network security. A public security remedy is what the IETF ultimately realized was lacking as the Internet became increasingly public.

“The obvious need for securing content at layer three [the ‘network’ layer of the seven-layer OSI networking model] was what spurred the development of IPsec,” said Paul Hoffman, head of the VPN Consortium. “There is security for each protocol at each layer, and IPsec is for that IP.” See, as the Internet grew, a number of applications and protocols began to appear that SSL wasn’t really equipped or designed to deal with.

Essentially, SSL at the time, wasn’t well-suited for public networks.  There were two reasons for this. The first one: SSL was — and still is — software dependent, meaning it’s only able to secure specific applications. So SSL worked for the small, private networks, but this posed a problem with the birth of the Internet as we know it today. Since SSL wasn’t designed to work with the new applications, it couldn’t secure them. Granted, SSL/TLS nowadays can work for public networks, but back then, not so much.

Here’s the second reason. While SSL was suitable for establishing remote connections between systems, it provided no way of securing those remote connections against attack from the higher layers. The fact that these connections were so often insecure left the user’s machine — and data — vulnerable to outside access.

In light of these realities, a new security protocol became necessary. This excerpt from the TCP IP Guide explains:

“What was really needed was a solution to allow security at the IP level so all higher-layer protocols in TCP/IP could take advantage of it. When the decision was made to develop a new version of IP (IPv6), this was the golden opportunity to resolve not just the addressing problems in the older IPv4, but the lack of security as well.”

I’ve got to hand it to the folks at the IETF- they’ve got rather incredible foresight. They saw it all coming, and swooped in to kill two birds with one stone, tackling both the address exhaustion and the network security issue with IPv6. Of course, since they knew that network security would probably become a problem long before address exhaustion, we’re just now beginning to see the last of the 32-bit IPv4 addresses assigned.

I’ve noticed a bit of confusion as to the status of IPsec in the Internet Protocol Suite- namely, as to whether or not it’s mandatory in IPV6. I was told by Paul Hoffman that it’s never been mandatory…even though most sources cite it as a mandatory element. Why the contradiction?

Turns out, there’s actually some rather confusing wording related to IPsec’s status in IPV6.

Essentially, IPV6 lists IPsec implementation as mandatory. What this means is that IPV6 has to have IPsec available…but sysops don’t actually have to deploy that implementation. Either way, it’ll still be present in IPv6, should anyone choose to deploy it. So, ultimately, IPsec is definitely here to stay.

Remote AccessAs part of an ongoing series, VPN Haus is asking average users about their frustrations with remote access. Most people we speak to attest that remote access has offered remarkable flexibility that simply wasn’t possible before. But as remote access has become more ubiquitous, so has confusion and annoyance.

“You can use SSL which is much simpler to manage and more bandwidth friendly. It is also easier on the end user. They don’t need to remember to connect the VPN first,” says Justin Fox an IT administrator for a small business.

We completely sympathize with Fox’s vexation – but SSL isn’t necessarily a catch-all. SSL is fine for intermittent remote access, but for those who need to connect remotely regularly, SSL is, well, hopelessly underwhelming. So, what’s this newer, faster, better alternative to SSL? IPsec VPN. Yes, you read that right. There’s a new crop of VPN options that are redefining the very idea of “ease of use.”

Case in point, Die Mobiliar*, the oldest private Swiss insurance company, recently updated its VPN solution. Understandably, the company was worried about usability for its end-users – but ultimately, it found a remote access technology with a simple, graphical user interface for end-users and a one-click central management for the IT department. Who says you can’t please everyone?

Readers, what are your thoughts on the new generation of VPN solutions?

*Full disclosure, Die Mobiliar is an NCP customer.

By David Torre

Guest Contributor

Internal information security policies have existed within the enterprise since the dawn of the information technology era. Viewed by many as a necessary evil and simply a check box compliance item, the overall value of a well-written internal security policy has become, perhaps ironically, now more important than ever in a world saturated with digital information.

Traditionally, internal policies were developed to demonstrate an organization’s commitment to information security, and to provide clear and consistent computing guidelines for which all employees must abide by. Even today, such time-honored objectives still remain relevant. Yet as mobile and cloud computing continue to shape the information technology landscape, it has become increasingly difficult for information-wielding knowledge workers to protect the organization’s most cherished asset: intellectual property.

As if protecting trade secrets from peering outsiders weren’t challenging enough, security professionals are also faced with threats that originate from within the enterprise. While tales of malicious insiders or corporate espionage make for intriguing conversation, most of us working from the trenches have discovered that perhaps the most significant risk to the organization is that of the naive end-user; one who cannot easily discern between safe and unsafe information handling practices. Consequently, this presents a dilemma of where to draw the line of acceptable levels of security aptitude. Take for example a cloud-based solution which is blatantly advertised as being “enterprise-friendly,” or a consumer smart phone that ships with a “Connect to Exchange Mail Server” icon on the home screen. It’s easy to see how users may become perplexed when attempting to determine where the corporate IT boundary ends, and where the still somewhat “wild” Web 2.0 frontier begins.

Fortunately, a clearly defined security policy can forge the foundation needed to cope with present information challenges. Such internal policies can, and should, go beyond the traditional form of abstract language lurking deep within the dusty corners of the corporate Intranet and instead foster an environment of understanding and education. In essence, the function of an internal security policy is somewhat two-fold. On one hand, it legitimizes the importance of information security and provides security staff with the power of enforcement with documented repercussions for those who choose not to comply. Conversely, the very same policies are advantageous for the end-user as they provide clear-cut guidelines which not only aid in risk reduction, but may actually empower the user community to stay competitive by making intelligent information handling decisions that are congruent with overall corporate business strategy.

Of course, some internal policies are driven by legal or regulatory compliance obligations. Common areas include Payment Card Industry, HIPAA, and SOX to name only a few. Yet just because policy supports legal or regulatory requirements does not mean the policy itself needs to read like a legislative bill. Composing the policies in straight forward language everyone understands will ensure compliance is maintained.

In summary, strong internal security policies are the cornerstone of an information security management system. By providing unambiguous guidelines for corporate computing and information handling, such policies ultimately reduce risk, and increase employee awareness.

David Torre is a security consultant and CTO of Atomic Fission. He is based in the San Francisco Bay Area.

[tweetmeme source=”vpnhaus” only_single=false]