In the paper, we propose a simple solution: take-down companies should share their raw, unverified feeds of phishing URLs with their competitors. Each company can examine the raw feed, pick out the websites impersonating their clients, and focus on removing these sites.

Since we presented our findings to the Anti-Phishing Working Group eCrime Researchers Summit, we have received considerable feedback from take-down companies. Take-down companies attending the APWG meeting understood that sharing would help speed up response times, but expressed reservations at sharing their feeds unless they were duly compensated. Eric Olsen of Cyveillance (another company offering take-down services) has written a comprehensive rebuttal of our recommendations. He argues that competition between take-down companies drives investment in efforts to detect more websites. Mandated sharing of phishing URL feeds, in his view, would undermine these detection efforts and cause take-down companies such as Cyveillance to exit the business.

I do have some sympathy for the objections raised by the take-down companies. As we state in the paper, free-riding (where one company relies on another to invest in detection so they don’t have to) is a concern for any sharing regime. Academic research studying other areas of information security (e.g., here and here), however, has shown that free-riding is unlikely to be so rampant as to drive all the best take-down companies out of offering service, as Mr. Olsen suggests.

While we can quibble over the extent of the threat from free free-riding, it should not detract from the conclusions we draw over the need for greater sharing. In our view, it would be unwise and irresponsible to accept the current status quo of keeping phishing URL feeds completely private. After all, competition without sharing has approximately doubled the lifetimes of phishing websites! The solution, then, is to devise a sharing mechanism that gives take-down companies the incentive to keep detecting more phishing URLs.

Here is our stab at devising a suitable sharing mechanism. We propose the creation of a members-only sharing club with compensation for net contributors paid for by net receivers. Take-down companies submit real-time copies of their entire feeds to a trusted third party (for the sake of argument, let’s assume that the APWG takes on this role). The APWG collates the individual feeds, marks the source of each submission (i.e., which take-down company) along with a timestamp. The APWG makes the amalgamated feed available immediately to all members. The members pick out phishing URLs impersonating their own clients, while ignoring the rest. Crucially, the expensive task of verifying phishing URLs and initiating take-down continues to be performed by the take-down company.

Periodically, the combined feed is audited to determine the reciprocity of contributions. Take-down companies provide a list of their clients to the auditor. The auditor then computes the number of phishing websites impersonating each take-down company’s clients that are missed by the takedown company but identified by others. The auditor also tallies the time difference for phishing websites that are identified by others first.

For example, suppose bank A1 has hired take-down company A to remove phishing sites on its behalf, and bank B1 has hired take-down company B. Suppose 500 phishing sites impersonate A1, and that A identifies 400 while B identifies an additional 100 sites missed by A. Likewise, suppose another 500 phishing sites impersonate bank B1, and that B identifies 300 while A identifies an additional 200 sites missed by B. B has received a net of 100 useful phishing sites more from A than B has given to A. Consequently, B should pay A a previously-agreed ‘finder’s fee’ for identifying these extra 100 websites.

The ‘finder’s fee’ provides additional incentive for take-down companies to invest in better phishing website detection. Designed properly, such a sharing club can overcome the potential for free-riding that companies such as Cyveillance fret about, while increasing sharing to shorten phishing website lifetimes.

Some subtleties must be mentioned, however. If the finder’s fee is big enough, some companies may be tempted to cheat to minimize their payout. For instance, underperforming take-down companies could claim to have independently discovered missing data from their feed shortly after collecting it from the shared feed. This can be mitigated by adding a credible threat of detection — inserting a few dubious fake phishing URLs that only appear in the shared feed. If the company claims to have ‘independently’ rediscovered these URLs, then they will be caught cheating. Another issue is that the auditing system does incur some overhead, which could be avoided if sharing was made unconditional.

To sum up, we recognize that many take-down companies will be reticent to share. However, we feel that sharing is too important to the goal of tackling phishing to brush aside because of a few inevitable complications. For the good of protecting consumers, the anti-phishing industry should learn to co-operate!

COBIT rivals ITIL from The IT Skeptic

“Everyone is tiptoeing around the fact that COBIT offers a significant competitive body of knowledge (BOK) to ITIL. Sure ITIL goes into more depth in places, but to say COBIT sits over the top is to grossly understate the overlap. COBIT extends a long way down into the “how” and it does it with an intellectual rigour that ITIL lacks.”

Interesting stuff that.  A detailed mapping might help some folks.  Either way, the good news for those keen on understanding risk management is that governance metrics, done right, allow us to understand a part of that “capability to manage risk” we’re always looking for.   Assurance, verification and the acquisition and interpretation of knowledge is king.   Speaking of which….

How To Tell When “Nothing Happens” by Pete Lindstrom

“…problem is that, it isn’t really true that “nothing happens” when you employ some specific security control to prevent an exploit. Not only that, but even when it is difficult to collect data on what didn’t happen, one can devise experiments to tell how frequently that nothing occurred.”

Good analysis is all about the uncertainty.   Speaking of accounting for uncertainty…

Assets Good Until Reached For by Gunnar Peterson

“If you have a 100,000 dekstops or 100,000 servers it hard to manage. You will need to automate and to do that you need to abstract, but you should also realize that its a drawing on a whiteboard not reality. You need abstraction assurance.”

And there’s the trick.  We might call “abstraction assurance” an analog to “confidence” or “uncertainty” in certain priors (metrics) or posteriors (calculated values based on those metrics).  The stronger that abstraction assurance is, the less uncertainty we have in our knowledge and the better our ability to create wisdom from that knowledge (you know, make decisions).

Epstein, Snow and Flake: Three Views of Software Security by Adam Shostack

Adam’s focus is on software security, but the discussion here can be abstracted out into the broader realm of risk management quite nicely.

Two-thirds of firms hit by cybercrime from Security Focus

The US DoJ says that in 2005 (there’s some timely data) 2/3 of their surveyed firms detected at least one cybercrime.  “Cybercrime” is “classified … into cyber attacks, cyber theft, and other incidents.”  Pretty general.  Also from the report:  “Computer viruses made up more than half of all cyber attacks.”

(That sound you hear is me tapping my forehead lightly on large iron object)

Lessons Learned from “Personal” Risk Management By: Christopher Daugherty

“This process is what I call “personal risk management.”  All of us have done it and will continue to do so.  Why is it, then, many companies have ignored following similar principles with the on-going health of the business?  This is a debate with many different answers so I ask you to select the best answer for your employer:

a) Have not ignored as this keeps me awake at night!

b) Please restate the problem, I cannot hear well with my head buried in the sand.

c) We passed our SOX audit so we checked this off the list!

d) We are informed of the challenge but we have a business to run and profits to make

e) Is this what internal audit and risk management has been telling us?”

Several weeks on and I'm still digesting the massive amount of information and insight from the second European identity conference in Munich, organized by Kuppinger Cole. Five days chock-full of content (7 am to 7 pm every day!), 50 exhibitors, 130 speakers, four workshop tracks, five theme tracks, and 25 best-practice sessions. Hundreds of delegates showed up from all over, even though Infosecurity 2008 was raging in London the same week. EIC 2008 was a superbly run event, with the seemingly inexhaustible Martin Kuppinger at the center of the storm.

It's difficult to sum up the content: Internet-scale identity, identity-driven security, federation, single sign-on (SSO), provisioning, context-based authentication, mobile and user-centric identity, SOA, entitlement management, and information risk management all commanded their own tracks. But some unifying themes emerged, chief among them that well-planned and -implemented identity and access management (IAM) is increasingly a must-have if we want to have effective information security, information risk management, and even GRC in today's and tomorrow's enterprises. 2008 may not be the tipping point for IAM, but we're getting close. A few highlights:

• It seemed that every third presentation contained the words "Société Générale" or "Jérôme Kerviel". Nothing like an(other) egregious breach of policy, procedure, and trust to concentrate the mind! Suddenly everyone is rediscovering the Barings debacle of a decade ago and recalling the name "Nick Leeson" — and realizing that, while we have made great technological strides in the past decade, all too often the people and process elements get short shrift. (If the control framework breaks down, it matters little what tech was used to enact it...). So while there was plenty of forward-looking technology-centric discussion, the thread of policy and process ran through every conversation — there was even an entire track session devoted to avoiding internal fraud via rogue trading and the changing threat landscape.
• A lot of the Identity 2.0 discussion was still quite fuzzy. There was little agreement on what mobile identity really means and how companies offering consumer services can provide it to customers, and what the role of mobile operators (who at the moment look like the weak link in the security chain) might ultimately be. User-centric identity is a great idea, but needs to be implemented in a way that gives users meaningful control over their identities and associated credentials in a way that doesn't also shift all of the liability for financial fraud (identity abuse) from institutions to individuals. This has significant implications for things like mobile commerce.
• There was a great physical/logical convergence case study from City College Coventry (UK), which is providing converged smart-card credentials to more than 10,000 students and staff. The card will function as an ID badge across the College, parking pass, building pass, cashless payment card, library card, etc. It will also be required to use any computer, printer, or photocopier connected to the College's network, and will allow lecturers secure access to classroom resources. The College does have the luxury of setting up this system in the context of moving to brand-new facilities, but it shows that if the IT and physical security folks can agree to pull in the same direction, convergence is a wholly attainable goal.
• Results of an enterprise IAM study were presented; one of the most troubling findings was that half of the respondents reported that their biggest obstacle to implementing IAM was that the business was just not ready for it. User management is often in place, but downstream functions like auditing and monitoring are still far from mature in a holistic IAM context. Firms also report big gaps between expected and actual benefits from implementing IAM. That last bit is one reason we advise not trying to do it all at once; rather, break a planned IAM implementation into manageable project chunks, focusing on one set of short-term, tangible, demonstrable benefits at a time.

One panelist put it best: Technology maturity and integration are all well and good, but we need workflow integration and organizational maturity. The need to implement IAM provides an opportunity to share information, define new policies and processes, and streamline existing ones. The CEO and CIO/CSO/CISO need to sit at the same table, commit to eliminating organizational silos, and devise a cooperative approach.

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.

But now that leaves us to the aftermath. After looking at the contest for the first four days we may have figured out a way to potentially stop worm propagation. Unlike tracking this method actually may help companies devise plans on how to reduce the likelihood of worm propagation across their websites. This should put to rest the nay sayers who thought nothing good could come of this contest. The paper is not for everyone - it’s pretty complex (as worms tend to be), but I think the people who have the problem will understand how to use it in their own environments.

That said, there is at least two or three more potential outputs of this contest - including papers on propagation analytics, worm tracking technology, and potentially other things that I’m not privy to. Was it worth it? Absolutely. I couldn’t have been happier with the results. Thanks again to everyone who made it such a success. It was a lot of work, but it was the first step towards large scale worm defense. Again, a huge congrats to Giorgio Maone and Sirdarckcat!

There are three major security-related disciplines here at Microsoft and people outside the company often confuse the three.

• 1. Security feature development
• 2. Security response
• 3. Secure software engineering

The first is all about building security features such as authentication technologies, firewalls and such. This is not SDL. At Microsoft the SDL obviously impacts the design and code that goes into these security features, however.

Next is the response process. All software has security vulnerabilities at some stage, and it's important that quality updates for all supported versions of the software in all supported languages be available as soon as possible. But no sooner! You can't rush a security fix out with minimal testing or on a subset of supported platforms or languages because you run the risk of releasing sub-quality fixes, or protecting some customers, but not all.

Finally, we come to secure software engineering. When we set out on the SDL journey, we realized that we needed to achieve two main objectives. The first is to reduce the number of vulnerabilities that creep into the software's design and code. I want to emphasize this point because this is the single most important goal of the SDL: To reduce the number of vulnerabilities in software products. This is not about who can fix bugs faster, SDL is about reducing the chance that vulnerabilities are added to the software in the first place. Writing lots of code quickly, shipping it and then racing to fix security bugs later is not engineering, it's chaos, and it's not good for customers. A question I like to ask software developers outside of Microsoft is, "what are you doing to reduce the chance an engineer will add a new security bug to the system?" The answer to this question must be holistic and include:

• Education
• Secure design and attack surface reduction
• Threat modeling
• Secure coding requirements (note the word, "requirements" not "best practices")
• Static analysis tools
• Testing requirements
• End-user security documentation.
• Response Planning

In a nutshell, this is a high-level view of SDL process.

The next goal of the SDL is to reduce the impact of security vulnerabilities missed during the software development process. Security is an ongoing arms race where attackers constantly devise new attacks to thwart the defender's defenses. Which means you can never hope for zero security vulnerabilities. We have seen many of these forward-looking defenses in action in Windows Vista, IIS6, SQL Server 2005 and Office 2007.

Look carefully at the list of products I just mentioned, they are all products that had a full release after the implementation of security process improvements at Microsoft. They are not service packs, and this is where I need to make a critically important point about the SDL. To gain the full impact and benefit of the SDL, you must apply the SDL to a product at its inception. With the exception of Windows XP SP2, (which was a security-focused release, but predates the SDL), service packs at Microsoft include fixes and perhaps some opportunistic feature enhancements requested by customers. Such releases cannot get the full benefit of the SDL, because security is not just about bug fixes, it is a holistic property that goes beyond fixing implementation vulnerabilities to encompass sound design and defense in depth.