Infosecurity Europe 2007.

A selection of papers from exhibitors at Infosecurity Europe 2007, Europe's dedicated Information security event. Now in its 12th year, providing an education programme, new products & services, over 300 exhibitors and 11,600 visitors from every segment of the industry. 24th-26th April 2007, Grand Hall, Olympia. www.infosec.co.uk

The Critical Need for User Defined Scripting

Phillip Pao, F5

An emerging catch phrase in the networking industry is the "application aware network." So what does it mean for a network device to be application aware. Here s one interpretation. An application aware device is one that is capable of performing selected application specific tasks. To do this, the network must have a certain level of application fluency. Network devices must also be flexible enough to accommodate unique, application specific requirements. A key driver that will enable networks to achieve true application awareness is user defined scripting. Scripting is the only realistic way to deliver the rich functionality requirements of a truly application aware network. An application aware networking device must provide complete control of when, how and what to do with application traffic at any point in time within an application transaction. Scripting is an ideal way to deliver this functionality in a flexible and granular way. User adoption of application aware scripting is dependent upon a few critical success factors. These factors include: 1) ease of use, 2) maximizing functionality, and 3) support from a rich user community.

Ease of Use

Why script at all? Why can't application awareness be synthesized for the user and networking decisions be boiled down into simple discrete decisions that are easily controlled in a GUI or single CLI commands? It is certainly true that the most common, simple networking functionality related to various applications, services and protocols can be configured using a GUI or single line CLI. But if deeper application awareness is needed, GUI and CLI methods become cumbersome and complex. As the number of parameters that need to be changed, the number of events that need to be monitored and the number of parameters adjusted based on the condition of events become numerous, scripting becomes the obvious way to implement the desired behavior. As much of an oxymoron as it sounds, ease-of-use is greatly improved using scripts, when implementing more complex, application aware networks.

Flexible, commonly understood scripting syntax is the best way to gain acceptance of scripts in networking solutions. The basic premise of this idea is that if you want the user to easily understand how to write scripts for network gear to make it application fluent, use a language and syntax that application developers are familiar with such as TCL. Regarding the commands themselves, the script commands need to leverage off-the-shelf commands, if possible, as well as be extensible and fast so that performance and functionality are not impaired.

An example of how scripting is typically the easiest way to implement an application aware networking solution is content scrubbing. Let's say a given application transmits payload data such as social security numbers in open text. Rather than re-writing the application and deploying a fix that re-writes the private data on all servers hosting the application, one could implement a resource masking policy that hides the sensitive information, such as a social security number, by replacing that information with a benign substitute or eliminating that information altogether. Let's assume that in order implement this, you need to:

1. Identify a specific characteristic that indicates the contents of an HTTP request actually contains sensitive information (say, a class of uri's)

2. Don't allow the content of those requests to be chunked, to allow for proper content re-writing on the response from the Web Server.

3. Find any instance in the HTTP payload that follows a pattern of 3 numbers, a "-", then 2 numbers, a "-", then 4 more numbers.

4. Replace any of the above patterns found in the payload with "xxx-xx-xxxx" Writing a script, although possibly intimidating to the novice, is the easiest way to implement the solution yet give enough flexibility to accommodate any application specific nuance. For instance, without scripting, how would one easily and flexibly be able to tell the network device what specific characteristics indicate the HTTP request carries a social security number? What if there were many independent characteristics instead of just a class of URIs? Also, what if the social security number could be with or without the dashes? What if they wanted to mask only the first part of the social security number because the last four digits needed to be preserved by the application on the client side? Trying to use a GUI that covers all these nuances would be maddening. If such a GUI were designed, it would be so crowded with parameters that the user would see it as way too confusing.

Maximizing Functionality

Scripts are the most elegant and efficient way to facilitate rich functionality in network devices. Leveraging a standard scripting language, such as Tool Command Language (TCL), to construct networking policies allows standard language functionality to be included in the vendor specific script toolkit by leveraging built in functionality from the off-the-shelf portion of software platforms and/or operating systems. This implementation allows users to use many of the standard script commands, plus a robust set of extensions that the vendor provides to further customize scripts to meet specific requirements. The scripts created can be simple or sophisticated, depending on the content-switching needs and can be a combination of vendor specific commands as well as recognizable standard commands. Scripts can work for virtually any IP protocol to address not only HTTP application challenges but also SIP, FIX, DNS, RTSP, XML and others. Scripts allow enormous flexibility and granularity in functionality. To illustrate this, let's look at performing traffic analysis and generating statistical traffic output. Depending on the purpose, a user could be interested in a number of statistical displays. The user may want statistics of occurrences (e.g. number of connections, etc.) of different traffic types such as:

1. GIF vs HTTP vs FTP vs other traffic types

2. Dynamic vs static traffic

3. Traffic by browser type

4. Traffic by authorization type

5. Traffic by particular URI address used/accessed

6. SSL vs non-SSL traffic

7. Compressed vs Uncompressed traffic Furthermore, the user may want to examine traffic by user groups by counting the number of connections made by certain groups of IP addresses, virtual servers, domains, subclasses or other user groups. In addition to counting the number of connections, the user may want to also count the number of requests, responses, re-written headers, re-directed packets, etc. of any user group. There are dozens of different things you can monitor. Additionally, the user may want to count the number of instances the number of concurrent connections pass a particular threshold or count the number of retransmits that occur over a specified period of time or count the number of responses that exceed a particular size. Again, there are dozens of different things you can monitor. On top of that, the user may want statistic compilations that nest conditional criteria within one another to get more exact statistics. Scripting gives you the power to drill down into the traffic stream to filter out only the traffic of interest and then report on only that traffic. For example:

1. Show the number of connections made by clients in a specific IP range, that carried HTTP traffic, that used Explorer 1.1, and were re-directed to back-up node(s) during a specified time period.

2. Show the number of HTTP requests to a specific Virtual Server from a specific Node Pool, but only for instances when the HTTP traffic had a payload length that was greater than a certain size. These are only a few permutations on how statistical counters may be used. The reporting and diagnostic uses of statistical counters are endless. Designing a GUI to accommodate the potential statistics desired by the user can be quite complex. In order to capture all the top requirements of networking statistics, separate dedicated hardware and software solutions are quite prevalent in the industry. But collecting and analyzing statistics on an in-line, traffic management device is outside the primary focus of most traffic switching/routing vendors so scripting becomes the only realistic, near-term option to provide users with deep diagnostic statistics from their switching gear.

It is important to understand that statistical traffic analysis is only one of many functions users would like to perform on their networking devices. Whole other categories beyond reporting such as implementing granular security policies, fine-tuning application optimization, performing advanced user authentication, protocol/application specific traffic routing or other content-switching activities are equally as complex. Because of the diverse types of functionality required by different users, scripting becomes the only reasonable option to meet the diverse sets of user needs.

Support from a Rich On-Line User Community The range of functionality and depth of flexibility of today's more advanced networking devices necessitates a rich user community to help each other deploy solutions to meet more complex and unique capabilities. Most of the best vendors today already have an open, online community for their users to help them learn about how they can get more out of their technologies, educate them on unique features and functionality, as well as provide additional technical guidance when needed. The goal of a technical on-line product user community is to provide a site about technical topics that is created by developers and network engineers, for developers and network engineers.

A user community is much more than a vendor simply answering questions as a form of online tech support. Many user community members of successful sites are the most advanced architects, administrators, and visionaries in the industry. Successful communities include the usual community tools like forums, blogs and Wikis, but these are simply tools. Communities that thrive provide a virtual place where users are stimulated to share best practices and cool ideas that not only make their lives easier, but make them look like technology rockstars at the same time. Ultimately, what makes a community work is the value that users gain from interacting within the community, yielding something they can not get from vendors directly. Successful community groups pool the collective minds of individual users to take product capabilities well beyond what the manufacturer could do alone. Communities tie together the worldwide set of diverse user applications that no single vendor can fully assimilate and manage on their own.

As scripting becomes more pervasive and complex within network equipment, the need for scripting solutions will grow. New and more diverse ways to apply existing scripting commands will continue to come to light, while vendors will be simultaneously developing more commands for users to leverage using the scripting platform offered on the network device. Vendors will lose track of all the different ways scripts can be applied to their devices.

www.F5.com

ISPs on Front Line as Spam Arms Race Escalates

Paul Thackeray, Barracuda Networks 

ISPs are finding themselves on the front line in the fight against increasingly sophisticated new ways of distributing spain. The latest spam trends, designed to fool traditional spam filtering methods, are sending the amount of spam through the roof--according to the latest industry estimates spam accounts for as much as 80-85% of total email volume. ISPs have to invest heavily in anti-spam solutions simply to ensure email remains a useful tool for users.

So-called "pump and dump" seams where minor stocks are promoted as well as graphics-based spam, are among the latest methods used by spammers in an effort to make a profit from sending spam. The amount of spam traffic being filtered through ISPs increased four-fold in the last months of 2006. From an end-user perspective, although more spam is getting through, for most people, spam levels remain well below five percent of all emails received. This is testimony to the hard work that the industry--anti-spam vendors and ISPs together--have put in behind the scenes.

The reason for the rise in "pump and dump" spam is that it does not require a link back to a Web site or ordering system, making it harder to trace its origins. Furthermore, the authorities have so far not caught any perpetrators. The messages have no constant wording, but instead tend to favour strings of random words or conversational-style prose to introduce the stock ticker value. This means there is not a lot for a conventional Bayesian filter to recognise.

Industry bodies like the London Internet Exchange (LINX) are calling for filters capable of examining token groups in addition to single-word tokens. This would increase detection rates for those emails with words that do not conform to any recognised sentence construction.

In 2006, spammers also began to produce graphics-based spam in order to beat filters that had no optical character recognition (OCR) capability. Analysis by our own labs found that as much as 25 percent of all spam messages, especially developing stock and Viagra spam, contains images. The images are usually combined with text. Again the industry has responded. Anti-spam vendors like Barracuda Networks have been extremely successful at creating fingerprints for this type of image spam. This reduces a lot of the horsepower problems associated with processing image spam. Nevertheless ISPs are investing in more filtering equipment simply to keep pace with the rising tide of spam. Researchers at the University of Cambridge report that in June 2006, one particular British ISP was receiving around 6 million emails a day of which 2 to 2.5 million were legitimate ones. By September, the figure was 12 million a day, rising to 18 million a day in October and peaking at 26 million a day by year end (legitimate email has remained constant throughout at 2 to 2.5 million a day). In the same period their end users have only seen a relatively small rise in the numbers of spam reaching their mailboxes. This is a great compliment to ISPs and the industry as a whole. It is virtually impossible to run an ISP today without a robust, state-of-the-art filtering system.

Most spam in the UK originates from abroad. The other major source is client PCs, often in the home, that are not properly secured. The good news is that legislation is helping to keep the lid on the spam problem within the UK. Examples of UK companies sending bulk email are rare these days--partly because of legislation, partly because it harms the reputation and partly because of the market education efforts of industry bodies like LINX.

Currently the industry appears to have the spam problem pretty much contained. Even though spam volumes are rising sharply, the industry continually fights back through advances in spam-filtering technology.

But we can expect the criminals and spammers to swing the pendulum back in their favour. According to Spamhaus, a leading anti-spam organisation, there are just 220 spam gangs (about 1,000 Internet users) out of a global Internet population of more than a billion. People are now paid to design new kinds of spam. They have their own filters and if their spam is blocked, they simply keep adjusting it until the filter lets it through. There is also more evidence of harnessing botnets--groups of about 10 or so compromised machines--for Google click fraud, sending spam, DoS attacks and for hosting phishing sites. A U.S.-based research company recently reported that as many as 600 new botnets are formed each week.

In summary, the fight against spam is a continual arms race and ISPs are battling daily to stay ahead of a relatively small, but determined number of spam gangs operating on a very large scale. For the moment at least, it seems the problem has been contained, however the trend toward more sophisticated social engineering techniques and increasingly targeted attacks means the race is far from over.

www.barracuda.com

Achieving Trust through Mutual Authentication in a Global Market

Ryan Kalember, VeriSign

A marketplace must be a focus of trust among buyers and sellers--whether the storefront is on the town square or on the Internet. Internet identity theft, phishiag, and on-line financial fraud are attacks on this trust and are compelling drivers for deploying strong authentication for consumers and the organizations that serve them.

As financial institutions and e-commerce sites launch new initiatives to deliver additional services on-line, government agencies have begun to recommend identity protection guidelines. Such guidelines recommend that financial institutions offering Interact-based products and services use effective methods to authenticate the identity of customers. Some consider single-factor authentication methods, as the only control mechanism, to be inadequate, particularly in the case of high-risk transactions involving access to customer information or the movement of funds between parties.

But a radically new approach to protecting digital identities is possible and necessary to prepare online sites for the threats of today and tomorrow. This new approach incorporates a comprehensive defense, and needs to be consistent with the Web Lifestyle of today's consumer by providing a flexible risk-based solution with minimal impact on the user experience. They must be easy to implement, perhaps as server-side only solutions that require no changes for the end user. They must include both rule-based systems and self-learning behavioral engine to identify fraud. Finally, they must address compliance issues while keeping costs low.

For their part, financial services, e-commerce companies, and enterprises need to manage the reputational risk of digitally interacting with consumers' personal data. This challenge demands invisible as well as visible or proactive identity protection, enhanced by network services, to enable credential sharing and provide Interact-level intelligence.

Fraud detection is key to risk-based authentication, where an enterprise can deploy authentication based on the commensurate risk of a given transaction. Ideally, this would provide an invisible means of delivering proactive protection to consumers. Using advanced anomaly detection technology, such a service might detect fraudulent logins and transactions in real-time without affecting a legitimate user's web experience.

The solution must take a self-learning approach to fraud detection, adapting to customer usage habits unique to an individual. Using policies and pattern recognition technology, the service could flag potentially fraudulent activities based on known types of fraud and behaviors not associated with the user. Because such a service would be self-learning, it could adapt to changing criminal behavior without manual intervention. This non-intrusive approach could be implemented without any change to a Web site and remain invisible to the consumer until a fraud is detected.

Organizations must be able to easily issue and/or accept multiple credentials from each user, a capability preferable for higher value, higher risk transactions. They must be able to embrace open standards, and allow standard compliant devices to be used for authentication. They must also include a number of options for supplemental factors, including stand-alone hardware devices such as One Time Password (OTP) tokens as well as "soft" devices such as question/answer and voice enabled OTP. The next step in the evolution to greater identify protection will require support for SMS OTP enabled cell phones.

A shared validation infrastructure operated could enable enterprises to deploy strong authentication without bearing the entire burden of managing and operating its own self standing authentication infrastructure.

A complete credential lifecycle management system, including outsourced provisioning, distribution, and support for end consumers would allow end-users to acquire second factor credentials as well as centrally manage and update these credentials. Enterprises could cost effectively and quickly offer strong authentication to their consumers at a fraction of the cost of building and managing their own complete solution. This would allow organizations to move their focus from security to their core business.

Another powerful mechanism would be the ability to share fraud intelligence across companies and across the Internet. This would encompass two levels of intelligence sharing. The first level would compare patterns of behavior across participating web sites in real time. This would help detect and stop attacks that could not be detected with data from a single site. Ideally, it would not require personally identifiable information to detect fraud, but could use unique pseudonyms to identify end users across web sites. The second level of intelligence sharing could be the addition of Internet level intelligence.

The addition of a shared authentication network could address the cost of implementing multi-factor authentication to a consumer facing an online application. Such a system must allow for an easy way to issue second factors to millions and millions of users. Servicing multiple devices and multiple users would likely require an expensive customer service and maintenance program. A shared network would allow an organization to avoid shouldering the burdens of development, customer support, and system maintenance. Instead, a site could join the network as a relying party and simply rely on the network's credentials that have already been issued, paying a modest cost per user for validations only. A web site could add strong authentication with no additional shipping or customer support costs.

If your business is committed to strong authentication, then you could issue tokens that are usable on the shared network. Issuers would get all of the benefits of relying parties, plus lower transactional costs, opportunities to promote their brand through the token, and better control of their end customers' web experiences.

For consumer authentication to be widely adopted, consumers must be able to use a single second factor authentication device that serves all their online banking, brokerage, healthcare and e-commerce security needs. Without this flexibility, consumers may end up with a "token necklace", a siring of unique tokens issued from different providers that secure unique transactions or websites.

In some cases today, consumers are able to use the same two-factor authentication device wherever they see that shared network vendor's logo--such as VeriSign's Identity Protection (VIP) logo on sites such as eBay and PayPal, where consumers are able to use one VIP token to secure their online purchases.

Over time, consumers will come to view such brand symbols and recognize the reputations of the companies that carry them as truly safe marketplaces for their business. Overtime, organizations open for business on the Internet will come to view these layered security solutions to reputational risk as competitive business advantages.

www.verisign.com

FWIW IM could leave you BBR *

The rise of employees' instant messenger usage continues to threaten organisations

Phil Worms, NetIntelligence

Not so long ago, IM was the domain of the youth and the net savvy enterprise. But as with so many products that begin with such 'humble' origins, they soon migrate from being neat underground tools to becoming indispensable business applications.

As technologies converge, many organisations are seeking to implement IM as an integral component element of CRM utilising IM's web/video conferencing, real time chat and file sharing capabilities.

Gartner suggest that IM 'will rival email in terms of both volume and ubiquity'. And one thing is certain, IM is here to stay. Radicati, the Market Research Group, estimates that IM is being used in 85% of all enterprises and that the number of worldwide IM users will grow to more than 45 Billion by 2008. The reason for the huge growth in IM? It's simple really. As with everything in life, we want things quicker and we want them now. It's hardly coincidental that this communication tool was named 'Instant' Messenger when it first emerged. Why wait a few moments/minutes for that urgent email when you can receive information in real time?

But IM's rapid growth has led to a plethora of security headaches for organisations. A major issue with IM is that it has in the main been adopted into business through employee 'osmosis' rather than through any deliberate policy led decision. As such, many organisations are oblivious to the fact that IM has been deployed within them, giving rise to the problem of controlling & managing a 'phantom' comms network.

Secondly, IM applications were primarily conceived with domestic use in mind and as such are feature/functionality rich but little emphasis has been placed on security in their design. Whilst commercial versions of IM clients do exist, many organisations are finding that their employees prefer to use the consumer versions of IM as it enables them to participate in activities that they would normally avoid using corporate messaging systems (an Osterman Research study revealed that 65% of organisations where IM is present have the consumer variants installed).

For many employees, IM quite often represents a novel way of indulging in little bit of 'matey fun' without affecting their overall productivity, after all an employee can still be 'attending' an official conference call whilst 'chatting to their 'M8s' about the latest Big Brother eviction. But it is this cyber fun that can lead to the real issues for an organisation. Constant education and media awareness has generally led to a change in employee behaviour when using the company email and it is now unlikely that they chose to use email to idly discuss their weekend plans, because they would perceive this as inappropriate use of the company systems and that they may be monitored and caught out.

Faced with the situation of widespread back door deployment of IM, corporate IT management are being forced to deal with this current threat whether they want to or not--a situation not dissimilar to the securing of email systems a few years back. With organisations catch in a such a state of paralysis around this issue, it is hardly surprising that the users of IM now represent a very low hanging fruit for virus creators, spammers and hackers. Spim (spam over Instant Messenger) is predicted to rise to 1.2 billion messages this year alone across both consumer & corporate IM platforms, and evidence suggests that nearly 40% of the top viruses are capable of propagation through IM applications.

With the experiences learned from emall you would think that securing IM would be easy, but unfortunately IM presents a whole raft of 'old threats' delivered in a entirely new package. With IM clients primarily designed with social networking functionality and features in mind rather than security, they are deliberately designed to counter connection difficulties. In fact they are extremely adept at 'navigating' their way through perceived obstacles, such as perimeter network defences, by using unauthorised ports in firewalls--usually described as 'port agility' e.g. the ability to move from port to port in order to find access. So the obvious stop gap solution of blocking and closing firewall ports is simply not enough.

In addition to providing a channel for viruses, worms, trojans etc, this ability to tunnel through perimeter defences offers an effective method of transferring materials in and out of an organisation without alerting security departments or passing through traditional filters. IM, as a real time tool, lends itself to a very informal style of communication.

The sense of community, familiarity and trust that IM builds within it user base probably presents the greatest challenge for corporations to overcome. IM has become the online version of SMS, with users adopting very informal language, little regard for basic common sense and even less regard for the legal liabilities that can arise from their actions. Users can be duped into disclosing confidential business information, compromising themselves by entering into defamatory or inflammatory conversations, and/or sending and receiving inappropriate material e.g. pornography, And most users do not release that most IM clients have conversation recording facilities and even PC sharing capabilities--both of which open up a whole Pandora's box for IT. The IM client will also usually reveal its true IP address during file transfer and chat, leaving the organisation open for hacking or denial of service attack.

Finally, if you add the fact that files transferred over IM are usually devoid of any form of encryption and that all messages can potentially be intercepted 'as is' (particularly as they are forwarded and stored on a third party central server) an organisation's security can be well and truly compromised.

So how does the enterprise secure itself against the threats posed by instant messaging? Unfortunately there is no simple solution--a multi tiered approach must be adopted. Virtually all of the current IM security products and suggested procedures have potential flaws--port agility, SSL tunnelling, encrypted IM conversations, ASP hosted IM platforms can all bypass traditional measures--but some actions can be taken to lessen the threat.

The first and most basic task faced by the enterprise is to formulate, implement and communicate policy concerning IM. Users must know what they can and what they can not do e.g. If IM is to be utilised within the organisation, then a secure dedicated corporately managed IM server should be deployed. A corporate platform will provide organisations with their own network clients & naming conventions which can enable internal threat detection, monitoring & auditing.

If the organisation is to allow IM but decides against a full in-house managed solution, then one common client should be selected. Likewise, properly configured firewalls must be implemented to assist in the management of non corporate IM. Ensuring outbound connections only use authorised ports will reduce some of the threat. Another traditional comfort zone of the IT department is to assume that a locked down desktop e.g. preventing the local installation of applications will prevent IM entering the organisation. This practise is easily circumvented through the use of web sites offering hosted IM, such as e-messenger, providing IM users with the ability to communicate without the need for a local client. Ensuring these sites are blocked through a web filter will prevent access.

So is IM the next major threat to a corporate network? Well, probably not but it certainly is one that needs to be given attention and one that that can not be allowed to remain unchecked.

* FWIW: for what it's worth BBR: burnt beyond repair.

www.netintelligence.com