Are Good Security and Web 2.0 Incompatible?

There are far too many numbers in this TechNewsWorld story, which reports results of a survey on Web 2.0 threats conducted by Forrester Research for Secure Computing. The survey, released in conjunction with the introduction of the vendor’s Secure Web 2.0 Anti-Threat (SWAT) initiative, shows that IT folks are unaware, untrained and don’t have consistent policies for this dangerous and increasingly popular way to use the Internet. SWAT aims to raise awareness of the issues, offer tips and in other ways help companies protect themselves.

The story quickly devolves into a sea of percentages. The saving grace is that the big picture is aptly summed up by Ken Rutsky, Secure’s executive vice president of product marketing:

The report reveals a security blind spot. Some 90 percent of enterprise organizations are still deploying security measures designed for the last generation of attacks.

This Computerworld piece uses data — thankfully, more selectively — from what appears to be a different Forrester survey. The piece focuses on the initial reluctance, and now apparent grudging acceptance, of Web 2.0 by IT. Like wireless and other emerging technologies, IT ultimately must bend simply because the folks they serve are using the new approach.

The piece features several short and interesting vignettes on different companies’ approaches and offers eight steps for Web 2.0 proponents to take in order to implement a secure and beneficial platform. They should create awareness; find supporters in the company; get IT on their side and present a proposal to senior management. Web 2.0 fans also should work closely with business units; compile and distribute best practices; resist the urge to force adoption and be patient. IT, for its part, is well advised to seek and create alliances with Web 2.0 proponents who are wise enough to take up these procedures.

In a related story, Computerworld reports on comments by Christian Christiansen, an IDC analyst, at a recent Kaspersky Lab’s conference on cybercrime. Christiansen identifies two overlapping threats to corporate security. The line between employees’ online personal and business lives is increasingly porous. At the same time, employees don’t follow their employers’ security policies — probably because they don’t know what they are. The bottom line is that all sorts of things people do at work and at home — including the connection of untested devices and the use of possibly malevolent Web 2.0 sites — can compromise security.

Those seeking more specifics about the threats — the statement that “Web 2.0 is dangerous” is as nebulous as it is threatening — should look at video. vnunet.com says that Chris Rouland, the CTO of IBM’s Internet Security Systems (ISS), made a presentation at the annual summit of the George Tech Information Security Center in which he suggested that video may be the next big target.

More sophisticated Web 2.0 networks hide less fully developed applications and devices that are latent or active threats to security, according to this piece at eChannelLine. The writer, using research from WatchGuard, maintains that the placement of servers running collaboration, VoIP and other advanced services in data centers heightens the risks. These servers are not as mature as older applications and are therefore more vulnerable to clever hackers. This, combined with the fact that the goal is to create more open and interactive networks, means there are more opportunity for hackers.

ZDNet Australia uses the subpoena of Facebook by the Attorney General of New York State for failing to adequately protect young subscribers as a jumping off point for a look at consumer use of Web 2.0 applications. This is an important issue for IT security staffs because it is a given that employees will use consumer services for work purposes or, at least, on the same devices they use in their jobs.

These social sites often are free in exchange for permission to use tracking and data aggregation tools. The problem is a microcosm of Web 2.0 in general: What the site is trying to achieve involves actions or policies that are the exact opposite of good security practice.

Making JavaScript Safe with Google Caja

Douglas Crockford continues to bang the drum for securing JavaScript in his latest post:

It is possible to make secure programming languages. Most language designers do not consider that possibility. JavaScript’s biggest weakness is that it is not secure. That puts JavaScript in very good company, but it puts web developers in an untenable position because they cannot build secure applications in an insecure language. JavaScript is currently going through a redesign that is again failing to consider the security of the language. The new language will be bigger and more complex, which will make it even harder to reason about its security. I hope that that redesign will be abandoned.

A more fruitful approach is to remove insecurity from the language. JavaScript is most easily improved by removing defective features. I am aware of two approaches that allow us to build secure applications by subsetting the insecure language.

The first approach is to use a verifier. That is how ADsafe works. A verifier statically analyzes a program, and certifies that the program does not use any of the unsafe features of the language. This does not guarantee that the program is safe, but it makes it possible to make programs that are safe. Any program can compromise its own security. The improvement here is that a program’s security is not compromised by the language it is written in.

The second approach is to use a transformer. A transformer verifies, but it also modifies the program, adding indirection and runtime checks. The advantage of transformers is that they allow the use of a larger subset of the language. For example, ADsafe does not allow the use of the this parameter. A transformer can allow this because it can inject code around it and its uses to ensure that it is never used unsafely. The benefit is that it is more likely that existing programs could run in a safe mode with little or no modification. I think that is a dubious benefit because programs that are not designed to be safe probably are not. The downside is that the final program will be bigger and slower, and debugging on the transformed program will be more difficult.

Both approaches work. But we still need to fix the browser.

A new project, Google Caja, is trying to do source-to-source translation to secure things:

Using Caja, web apps can safely allow scripts in third party content.

The computer industry has only one significant success enabling documents to carry active content safely: scripts in web pages. Normal users regularly browse untrusted sites with Javascript turned on. Modulo browser bugs and phishing, they mostly remain safe. But even though web apps build on this success, they fail to provide its power. Web apps generally remove scripts from third party content, reducing content to passive data. Examples include webmail, groups, blogs, chat, docs and spreadsheets, wikis, and more.

Were scripts in an object-capability language, web apps could provide active content safely, simply, and flexibly. Surprisingly, this is possible within existing web standards. Caja represents our discovery that a subset of Javascript is an object-capability language.

FBJS is also trying to do some of this too. Got some time on Friday to look around some code? Take a look at some Caja.

Show IP access lists attached to an interface

When developing yet another Tcl script, I've stumbed across an interesting show command: the show ip access-list interface name introduced in IOS release 12.4(6)T displays the contents of the inbound and outbound IP access-list applied to the specified interface. The really nice part is that the ACL statistics (number of matches displayed next to the ACL lines) are kept and displayed per-interface.

For example, this is the printout from one of my test routers:

R2#show ip access-list 101
Extended IP access list 101
    10 permit ip any any (1900 matches)
R2#show ip access-list interface tunnel 0
Extended IP access list ICMP in
    10 deny icmp any host 10.0.1.2 echo
    20 deny icmp any host 10.2.0.2 echo
    30 permit ip any any (2279 matches)
Extended IP access list 101 out
    10 permit ip any any (10 matches)

Securing Networks with Cisco Routers and Switches

We have just released the new version of the Securing Networks with Cisco Routers and Switches (SNRS) remote lab exercises. They are an ideal companion to books or e-learning material if you're preparing for the CCSP exam. You can also use them as a great practice environment if you have to support security-related IOS features in your network, but simply don't have the extra equipment to test them out before deploying them.

As a side note, what really amazes me is the fact that Cisco has rolled out a mainstream certification course that supports pretty recent features (up to IOS release 12.4(6)T), including control-plane policing, management-plane protection, zone-based firewalls and Web VPN.

More information is available here.