InfoSec 2008: Key takeaways from Europe's biggest security event

Infosecurity Europe is the continent's premier dedicated information security event. InfoSec, held the 22nd-24th of April at London's Grand Hall, Olympia, saw some 300 security vendors exhibiting and more than 12,500 security folks visiting. Next year will be at the bigger Earls Court. Last year had fewer attendees, but the benefit of a clear key topic: data security.

So, what was the buzz about this time around? Well, for starters there was no single topic that stood out, but instead InfoSec 2008 was a complex smorgasbord of all past and present security and risk management themes. Certainly, deperimeterization, endpoint protection, data-driven security, and compliance strategies were very visible, but at the same time many network security solutions and antivirus stuff were pushed heavily. Some of the traditional security heavyweights were, you guessed it, widely visible and audible and included the likes of McAfee, Sophos, Kaspersky, Juniper Networks, etc.

Many of the attendees and vendor representatives I talked to seemed to echo the notion that the dynamics of the market are changing. As security managers are overwhelmed by complexity and the daily grind of updating, patching, and fixing holes - many tend to retreat to something of a "wait and see" mode. Yet people begin to acknowledge that technology driven, perimeter-based security is largely a thing of the past and either gets operationalized or outsourced. Most people in the industry begin to see the early contours of a new security and risk paradigm. Visionary folks see this promised land of information security and risk management being in the green valley of business-driven risk management, where data, identity, policy, and compliance are crucial cities (elements).

Which of these cities (elements) will be biggest and most important almost entirely depends on where you are coming from as a vendor and what your primary differentiator is in the marketplace (nothing new here...). Sure, we will see more unified solutions and suites that contain most established security features. Sure, we will have small start-ups addressing the latest threats and more tricky challenges - and then we will see the vendor Darwinism that we are accustomed to.

But for security professionals a key challenge lies in understanding that there is a paradigm shift happening outside of the technology/vendor realm which will require out-of-the-box thinking for many of us. There are a few steps you can take to prepare yourself, though: First off, take a crash course in business speak (as opposed to the tech talk we are all accustomed to), secondly, get your corporate ducks in a row by forming alliances and partnerships with other departments (e.g. legal, HR, key business lines) that you haven't worked with on a regular basis before; third: articulate the business benefits of addressing new security challenges (and be easy on the scare tactics here), and finally introduce technology not as the be-all-end-all but rather as the linking layer between people and processes which are what matter most in any organization. If you then learn how to demonstrate that a new data security product or a fresh start on identity management is going to help your company add to the bottom line - then you are on the right track to the nirvana of security and risk management.

Hitachi acquires M-Tech Information Technology

The number of pure-play vendors in user account provisioning decreased on April 7, 2008 when Hitachi announced that it acquired M-Tech Information Technology, and changed the name to Hitachi ID. Although Hitachi has been lacking an identity and access management (IAM) pedigree, this move can prove important due to the following reasons:
1) Using IAM for provisioning of physical resources and hardware resources.
2) Extending enterprise role definitions to previously uncharted verticals and cultures.
3) Evangelizing user account provisioning and IAM in Japan and other APAC regions.
4) Hitachi becoming a major player in Japanese SOX (JSOX) implementation.

Needless to say, the above will hinge on Hitachi's ability to retain and grow the existing customer base of M-Tech IT in North  America and Europe, and also on  Hitachi's ability to compete against EMC's selling of  Courion and RSA products. How Hitachi will create an access and adaptive access management (Web and desktop) portfolio to complement its identity management and provisioning portfolio also remains to be seen.

UBS Explains Risk Management Gone Wrong

Big news in risk management this week as UBS released a report to shareholders describing the situation that has led to roughly $37 billion in write-downs so far related to the company's subprime exposures (see articles in Reuters , Forbes , the Wall Street Journal , and BusinessWeek).

Overarching causes described in the report are not surprising; control failures, an overly aggressive focus on short-term growth, and excessive risk taking are among the high level issues addressed. Also in the report, however, are scores of more detailed explanations of control failures in more than 20 different categories. Specific problems on the list include:

• Gaps in risk management expertise
• Failure to respond to wider industry concerns
• Lack of comprehensive Subprime risk assessment
• Complex and incomplete risk reporting
• Inadequate systems (related to infrastructure investment)
• Lack of strategic coordination
• Asymmetric risk/reward compensation

The list goes on, providing a substantial study guide for risk managers and auditors on problems to avoid. And because of the unfortunately massive losses due to these failures, the report also offers a bit of cost justification support for your new, broad risk management initiatives.

Update: added link to the UBS report

End user security psychology, part II: Can knowledge-based authentication be effective?

Another post on Finextra discusses some recent research out of New Zealand that determined that the longer an authentication process drags on -- the more gantlets a user needs to run before being let in a site's front door -- the less secure those users perceive the site is.

Implementations of knowledge-based authentication (KBA) -- asking "secret", out-of-wallet questions that presumably only the end user knows the answers to -- on the Web have been on the rise in the past few years, particularly in online financial services, as part of efforts to fulfill FFIEC guidelines for additional risk mitigation measures that address the inadequacies of single-factor authentication. The concept of layered authentication -- the riskier the transaction, the more stringent the authentication measures -- is related to this, and KBA can be readily (and simplistically) adapted to layered authentication by simply increasing the number of secret questions that the system asks.

Of course, as a standalone method of authenticating users at login, asking out-of-wallet questions in addition to username and password doesn't rise to the level of strong (two-factor) authentication, since they're all variations on "what you know". So from a security standpoint it's difficult for KBA to really provide identity assurance. But isn't ease of use and peace of mind for end users that's driving financial institutions to implement KBA? (Let's put aside for a moment any cynicism about KBA being a cheap alternative for the FI.)

Apparently, though, there's a point at which users' confidence that the bank is protecting their assets tips over into suspicion that the bank's security isn't up to snuff or even that a fraudster is pumping them for personal information. And then there's the annoyance factor: the inconvenience in terms of the time and effort to remember all of the PINs, passwords, and answers and jump through those hoops. It's as if the typical Internet banking customer is a tender orchid needing just the right conditions to flourish.

The only problem is that in most cases this isn't true. Buck up and spend the cash on a real two-factor authentication system, mandate its use, and customers will adapt -- even thrive. There are enough different methods of two-factor out there that the difficult decision should not be whether to implement two-factor, but which form factor to choose.

Virtualization and security - are we missing the wood for the trees?

I've sat through a number of presentations and sessions about security and virtualization in recent times and can't help thinking that people are falling into the old trap of going after the possible rather than the probable.

Most discussions I've seen around security and virtualization center around subtle threats to the hypervisor layer, and whether its possible to jump from one virtual machine to another. Then there are the circular discussions about whether its provably more secure to perform AV and intrusion inspection from inside the virtual machine, or have the host perform all the functions.

All pretty tedious if you ask me. I reckon we've some much bigger problems in a virtual world.

Isn't it more of a problem that in a virtual world its harder to keep track of what business activities happen where? Isn't the patch and vulnerability management process exponentially more complex when you're instantiating and destroying virtual machines left right and center? How do you determine what risks you're introducing if you move a virtual machine from one place to another? How do we track all this and demonstrate it to our friendly auditors when they come a-knocking?

I reckon we need to elevate the level of conversation to talk about the real risk consequences of virtualization, and what it does to the security business model.

Don't get me wrong, we do need to consider these more subtle virtualization threats, but rather than talking about them in isolation, we can incorporate them into wider conversation. This can then include the slew of new deployment, implementationm and licensing options virtualization introduces for security services, and devise a more business oriented way to establish who does what, where, and when for optimal security and cost.

What can we learn from Hannaford & TJX?

The Hannaford data breach was of course all over the news last week. It is reported that Hannaford's internal practices were considered PCI compliant, yet they suffered a massive data breach. It begs the question whether PCI requirements were sufficient.

While many companies still lag behind in terms of achieving PCI compliance, quite a few organizations have gone above and beyond to protect their critical operations. I call those "next practice" adopters (as opposed to best practice). For instance, PCI requires that you scan your computing assets quarterly. Many of the next practice companies would scan their most critical assets weekly or even daily.

So, what should you consider as your critical assets. Here is a list to get you started:

- Web applications (those that handle online transactions)

- Web servers (those that interface with external Web users)

- Database servers

- Application servers that serve up your core applications

- Firewall (between DMZ and the Internet)

- VPN servers

Your list may defer, depending on your business operations. For instance, some businesses operate SCADA system, and that would be their critical asset. But the above list is a good place to start thinking about your critical network assets and how you should management vulnerabilities both at the network layer and in the applications.

For more information, see the Forrester report: "Operationalizing Application Vulnerability Management".

How Unsecure Is The Web?

In the course of doing research for my upcoming Internet threat report, I came across some worrisome statistics. A Google researcher recently reported approximately 1.3% of all Internet queries would return at least one URL that contain malicious content. A year ago, March 2007, this number was 0.3%. The same report also indicates that 6,000 out of the top 1 million most popular URLs, have been, at one point or another, classified as malicious.

These statistics are indeed worrying. The top one million URLs are the most frequently visited sites, and the fact that a non-trivial percentage of them could be malicious is a previously unknown phenomenon. This underscores the rising difficulty of Web threat detection and defense. The latest statistics from the anti-phishing working group have that the average life time of a phishing site is now at three days (2006 statistic was 4.5 days). Not only are Web threats more wide spread, they are more dynamic as well.

Companies who are using URL filtering and anti-virus only will continue to lose ground, in the face of the more dynamic and stealthy threats. You must consider proactive, real-time malware detection methods to complement your other, more static threat protection mechanisms.

K.I.S.S. the castle (analogy) good-bye! Okay, done - now what?

Think for a moment about the very simple, used-to-death castle analogy with its walls, gates, guns, guards, etc. and how these parts related to early network security. The analogy certainly had its shortcomings already back then – but it nevertheless got popular because of its inherent simplicity.

In today’s complex data and identity driven world of security and risk management, the old castle simply doesn’t cut it any longer. Just think of examples like the skyrocketing amount of data “crown jewels” all over the place (not just in the tower), the almost constant transport of these assets to places in and mostly outside of the castle, and the fact that insiders/peasants pose a much bigger risk than external attackers. Also, there is not just one king today, everybody has something protect-worthy (data, identities, etc.) and the same person can in fact have multiple identities. Sure, you can add bits and pieces into the old castle metaphor, but it quickly becomes too complex and therefore useless as an analogy.

So, while most members of the security academia have given up on the castle some time ago, the question is: Can we provide a simple, yet somewhat holistic concept of modern security and risk management?

Fact is, that we as security professionals struggle to explain to non-security folks what it is we are doing and why we are doing what we are doing. A bit of insurance talk, a sprinkle of metrics, lots of tech explanations, and certainly a huge portion of scare tactics are still our most often applied tools. But we all know – and experience on a daily basis – that we are not making ourselves clear to LOB managers, executives, and other non-technical people.

So, is there a single, all encompassing metaphor any longer? Or will we inevitably end up comparing the complexity of today’s security and risk landscape to, well the “real” world? But then again, wouldn’t that ‘metaphor’ fall short of the main reason for why we use analogies – namely simplification? Hence, wouldn’t that be utterly useless?

Or, instead of trying to construct a next-gen analogy, do we simply have to become better at articulating ourselves? Are a non-tech language, simple words, and context going to be enough to get our message across? Or should partial analogies be thrown into our new communication mix? Or does everything ultimately boil down to K.I.S.S.?

IT Risk Management

IT risk management is a nebulous topic at best. There are many different ideas as to what risk means and how it should to be applied within an IT organization. In an effort to bring some consistency and clarity to this discipline, Forrester is developing an IT risk management framework. Once developed, the framework will help IT organizations identify major risk areas, identify scenarios linking risks and controls, and establish a common risk language to clearly communicate with business leaders.

In order for the framework to have a solid risk-based foundation we will be using many of the principles of COSO. In particular, the framework will be based on event identification, risk assessment, risk response, and control activities. The IT context is established by utilizing the ITIL framework for IT service delivery. IT services are used to identify risk events. Scenarios are developed for each identified risk outlining the actions necessary to realize the risk. Controls are then mapped to each scenario to either prevent or detect the actions.

Since COSO and ITIL will be used to develop the framework, a common industry-agnostic set of key risk indicators can be established and bring some consistency and clarity to IT risk management.

The Hannaford PCI Fallout

By now, most people have heard about the data breach at Hannaford. Here are some thoughts regarding potential fallout:

1) PCI standard may change. Much depends on Hannaford disclosing the control failures leading to the data breach. The standard may be strengthened to address control areas that may have been overlooked. Should the controls that failed not be part of the current PCI standard, they will most likely be added in the future. Should the controls already exist in the standard, they may be re-written for clarity or greater implementation details may be needed.

2) PCI compliance auditors may be scrutinized. It is unclear at this point in time if the methodology used by Hannaford’s auditors was inadequate. The payment card industry may re-evaluate its criteria for certification and impose more stringent requirements. They may follow in the footsteps of the PCAOB and release audit guidelines to increase the consistency of compliance audits.

3) Lawsuits abound. Cardholders may form a class action lawsuit against Hannaford for failing to protect their information. Hannaford may sue its PCI auditors for damages caused by inadequate audits.

4) Organizations may want a second opinion. Organizations governed by PCI may, in the short term, pay for additional reviews of their controls from sources other than their normal PCI auditors in order to gain further assurance they have effective controls in place. PCI audit and consulting companies may see a dramatic short term increase in business.