Download file

What follows is the transcript of my podcast with Sanjay Mehta, Senior Vice President of Sales and Marketing for Breach Security, where we discuss the ValueClick data breach, what happened, how it was the result of a corporate takeover, and how takeovers often results in unsecure, 'orphaned' applications.

Can you give me a general overview of the ValueClick security breach?

Sure. There were three main components in that breach. The first was just a simple violation of the CAN-SPAM Act, essentially centered around deceptive emails. The folks at ValueClick were passing out emails that were touting free gifts, pretty high dollar items like iPods or laptops. When consumers clicked through those ads to go to the websites to claim their free prizes, they were assaulted, if you will, with a large number of extra steps to go through including solicitation of paid for goods.

So that was the first area, and the area that the TFTC was originally tipped off on. The next was non-standard encryption. So they’re very well known standards for protecting sensitive information with encryption today. ValueClick was using something that is essentially was just a customer built character substitution. So if you watch any modern day movies where people are hunting treasure maps and trying to substitute characters, they were using a fairly similar method.

It doesn’t really encrypt the data, it just obscures it and anybody with even moderate skills can essentially translate that back and get the clear text data, so that was the second area. And then the third one was they were vulnerable to a very common type of application specific attack called the “SQL injection” where essentially somebody with malicious intent can put in certain character sets, if you will, to dump information out of a database or other data store.

Was ValueClick following acceptable security practices?

No, they really weren’t. So the spam thing is really a different issue, right. They are well known pieces of legislation on how companies can email solicit their customers, and they need to identify who they are, and the email address itself needs to be legit, and the physical address needs to be included so people know they’re dealing with a legit business so they made violations on that.

On the security front, the two areas, again, were the weak encryption and the SQL injection. So the application security phenomenon is, in general, new. It’s only been out two or three years in terms of real customer adoption. It’s been a topic of media and press on data leakage over a similar period of time, but more and more folks are rolling web apps out. So there are very commonly known industry bodies, if you will, where you can go get information on how to live up to best practices.

The most commonly referenced one is something called “OWAS”, the Open Web Application Security Project. And that gives the top ten things you need to be concerned about and things you need to do if you’re doing business on the web, two of those being SQL injection protection and encryption, and ValueClick came up short on both of those accounts.

So looking back, what should VauleClick have done to prevent this from happening?

A few things. Part of their challenge is something that a lot of companies face today, which is the application in question was one that they acquired from E-Babylon. So in today’s world where we’re all geared up for high competiveness and rapid growth, acquisition is a pretty typical growth strategy. When ValueClick acquires somebody or even “Bank A” acquires “Bank B”, you inherit a bunch of applications that you know very little about.

And as part of that competitiveness aspect to streamline the business, you let a bunch of people go. So these applications get inherited and then they’re what I called “orphaned”, right. The people who wrote the applications, the people who were previously responsible for securing the applications are no longer with the company, the applications are mission critical, they’re driving business and they need to stay online.

So now, you have new folks responsible for securing these things that they know nothing about. ValueClick was essentially a victim of that phenomenon where they brought over these apps from E-Babylon, they had poor encryption, they had susceptibility to very common vulnerabilities, and they needed to keep it online.

So what they should’ve done is sat down and gone through a comprehensive review of how that application’s protected, what it was, how often it changed, what its business features were, etc, and then deployed some sort of defense in-depth approach to secure the application. They’re -- an application security, there’s no silver bullet, it’s no different than network security.

You need a defense in-depth approach that starts with training your developers how to write securely, reviewing that throughout the development process to make sure code is being written in a secure fashion according to your corporate standards and industry best practices.

And then, once in production, making sure that you have the tools and techniques in place to detect the changes to the application and how that might be introducing new vulnerabilities. And also, just understanding what’s going on in the outside world and who’s targeting your application and your corporate data.

Now, with the FTC fine against ValueClick, what do companies need to know about complying with the government security requirements?

In the world of payment, in the world of web transactions, it’s actually much broader than just the FTC. So the government certainly has legislation around this and there’s certainly some precedent around fines. The more prominent movement is actually sponsored by the major card brands, and that’s PCI, the Payment Card Industry Initiative and they have something called the “Data Security Standard”.

And essentially, everybody’s pointing back to the same thing. So pointing back to something like the OWAS, that I referenced, at owasp.org, and complying with best practices to security web applications. Everybody’s looking at the same standards so it’s not hard for a merchant or anybody else doing business on the web to comply with multiple standards regardless of where they’re coming from as long as they do [0:05:43] best practices.

So the fines with PCI have been pretty severe. Companies are violating that, they’re getting fined $30,000 a month, they rates on credit card transactions are going up, and in the worst case, you’re actually getting dropped so you can't take cards anymore. So whether it’s a FTC fine that could result in millions of dollars of various things or actually losing your business, companies need to step up and protect their web applications the same way they protect their networks.

What part does your company, Breach Security, play in this process?

Yeah, Breach Security is squarely focused on the solving the problem of web applications security. So if you think of a network, networks are by and large static. Company to company, you have border routers, firewall, switches, load balancers, etc. And if somebody wants to attack a network, they attack it in roughly the exact same way.

So if you think back to five, six, seven years ago when all heard about the SQL Slammers, and the Blasters, and the NIMDAs, and the Code Reds, they were very wide spread mass propagating worms designed to wreak havoc across lots of networks simultaneously. If you think about the web application security world, every web app is unique. So instead of ValueClick, for instance, they’ve grown through acquisition.

Let’s say they have a 100 applications, for the sake of argument, each of those applications, even if built on a common framework of tools, has a unique purpose in the way an end user interacts with it is different. So to protect that web application, you need to understand its unique intricacies if you will.

So Breach Security focuses on delivering a suite of web application security solutions that not only have great detection of what’s going on from the outside world, right. Who’s trying to attack you? What vectors are they taking? But also understanding how the application itself works so you can protect it in the best way, and also complete the lifecycle so security folks can have cogent conversations with application developers about actual flaws not theoretical vulnerabilities so code can be secured at the core.

Now, so what do you see for the future then of application security?

Yeah, I think to broaden the question a little bit, folks are finally starting to look at security a little differently. Historically, we’ve looked at stovepipes of technology. So we’ve said, oh, we need a firewall. Oh, we need intrusion detection. Oh, I’d like to consolidate my data path a little bit so I’m going to jam all these various things into some sort of UTM device or a switch. But applications are bringing a whole business context into it, which is I need to do business on the web for the following reasons.

And to do that, I need to enable certain classes of users to do certain things. I need end users or consumers to come in. I need my extranet business partners to come in. I need my inside guys to come and access the web applications, all for different purposes. So I need different authentication routines. I need different authorization routines. And then once people come within those gates of authorization, I need to make sure that they’re only doing what they’re allowed to do.

So in web application, development, and production apps, people are taking a different look at the problem, which is what’s the core value here I need to deliver and then how do I secure that entire value chain from start to finish across my various constituencies? So I think that the market’s going to start consolidating, if you will, around a different mindset which is; it’s not all about jamming more stuff into a network, it’s about finding a business problem and then making sure that you can deliver secure access for that business problem and the easiest way.

Some of the interesting shifts noted this year are: 17% of the respondents came from Africa, Latin America, and Oceania (it must be a quite an eye-opener going online for the first time and seeing all the great and not-so-great things on the wild wild web) . Also, a majority of people see the growing need for security education. Some of the key findings follow below:

* Respondents came from the three major regions of the world: Americas (41%), Europe, Middle East and Africa (EMEA) (25%), and Asia-Pacific (34%). It is also interesting to note that this year, respondents from Africa, Latin America, and Oceania comprised 17% of the total respondents.

* Respondents from the Americas see a growing demand for education in security administration (53%), applications and systems development for security (39%) and telecommunications and network security (34%).

* Respondents from EMEA (Europe, Middle East, Asia) see a growing demand for security administration (40%), business continuity and disaster recovery planning (29%) and privacy (29%).

* Respondents from Asia-Pacific see a growing demand for security administration (54%), applications and systems development for security (36%) and telecommunications and network security (34%).

* Three-quarters of respondents see viruses and worm attacks as a top/high threat. Next in line for concern are hackers and inside employees as potential security threats.

* Three quarters of respondents view the impact of service downtime (73%) and damage to the organization’s reputation (71%) as top/high priorities. In addition, customer issues related to privacy violations (70%) and customer identify theft (67%) are a top/high priority.

The full report can be found The right here.

According to the announcement, which they're calling SearchScan, will start issuing warning on suspect sites. Launched in beta today, and the early reports from many analysts are that it's at least a move in the right direction. And the fact that most of our web interactions, good or bad, start at the search (the fact that it usually starts with a google search is another story altogether), I would have to agree.

The warning will appear as a bright red icon given the nature of the suspected threat, saying things like "Warning" Dangerous download" or "Unsolicited emails." Placing your cursor over the warning will provide even further details.

"Getting this launched is really crticial to keeping the Internet on its growth track," said Priyank Garg, director of product management for Yahoo Search. "This can help to go a long way to making consumers feel more trusted and feel safer when they're interacting with Web sites."

It is important to note that Searchscan, part of McAfee's SiteAdvisor, will not offer all of SiteAdvisor's features, but which can be bought in full from McAfee.

Now if they could only include some type of warning label when surfing certain woman on certain dating sites...that sure would have saved me some time and misery.

There is an interesting article over at Dark Reading on the massive disruptions Web 2.0 is causing to the whole idea of security. In a speech at Interop '08, Gary Hodge, executitve vice president at CTO at U.S. Bank, said, "After years of keeping them protected from the outside world, we're now exposing our internal systems to our customers; it totally changes the way we look at security. Now, we have 3.5 million customers who are accessing our systems legitimately -- plus that group of bad guys who are trying to break in."

It's almost like the change of warfare from the old days to now: in the old days, the bad guys faced off against the good guys in an area away from the general population Today, warfare happens on the busiest commercial streets, the good guys mixed up with the bad, which means to succeed, you have to protect yourself from everybody.

Perhaps the most significant disruption is the simple fact that, with so much SaaS and Web 2.0 now a significant part of an employees legitimate work day (to say nothing of illegitimate, or semi-legitimate), the browser in essence has become the new operating system.

Said John McNulty, chairman and CEO of Secure Computing, "Securing the network at the perimeter used to work. That's not going to work anymore."

Listen to or download the 3:01 minute podcast below:

Download file

What follows is a transcript of my podcast with Paul MacKay, worldwide sales leader of IBM’s WebSphere, where we discuss event processing: what it is, how it can benefit your business, and finally, the role event processing plays in SOA.

First of all, why don’t you give me a quick overview of what Business Event Processing is.

Well, Peter, Business Event Processing is really a software technology that provides the ability to sense when electronic signals indicating an actionable business situations have occurred and to coordinate the right response at the right time.

Now, exactly what is the benefit of Business Event Processing?

Well, Business Event Processing provides tremendous benefit in that it enables real-time patterns of events coming from disparate sources throughout a corporate infrastructure to be detected and to be evaluated and acted upon. But in addition to that, what Business Event Processing does is it abstracts the level at which the specification of these patterns are formed making it possible for business personnel themselves to take responsibility for designing, deploying and maintaining their own Business Event Processing patterns, that’s the real benefit.

The real benefit results in the much more rapid time to market, and much more rapid response to change, and empowering the business user to be able to take responsibility for the implementation of its own Business Event Processing needs.

I can certainly see how companies would be interested in something like that. Now, what exact role does Business Event Processing play in SOA?

Well, SOA focuses on the user’s view of a system at a conceptual level. SOA is really an extension of Object-Oriented Programming ideas, the principle of modularity, the design of an organization of the related services into a single service server module. So it relates services into groups of server modules. And event processing is a completely different ability.

Event processing is at the level of business events now entering the picture with a conceptual paradigm for remote access. A user no longer needs to access a service. Instead, a user can access services by sending and receiving events asynchronously. So they’re really complimentary, completely complementary paradigms doing completely different things. And together event processing and Service Oriented Architecture cover the entire waterfront of businesses needs.

Listen to or download the 6:27 minute podcast below:

Download file

What follows is a transcript of my podcast with Ruma Sanyal, Director of Worldwide Product Marketing for BEA's WebLogic Time and Event Driven Products, where Ruma explains all the buzz about Event Processing, how Event Processing works with SOA, BPM, and other implementations, and finally, how someone can get started with Event Processing.

Can you give me a quick overview of what Complex Event Processing is?

Sure. The straightforward definition of Complex Event Processing is as follows: Complex Event Processing correlates events into patterns that may present a threat or opportunity. Typically, processing vast amounts of data in real time. So although this is a great starting definition, I do want to add some color to that.

We prefer using the term “Event Processing” at least at BEA and when we speak with customers to refer to this area. We have found that in our discussions with customers and prospects that the term “Complex Event Processing” often conjures up images that it is a complex technology or the events involved have to be complex, etc.

So event processing we have found, is the term that is becoming popular as the umbrella term to describe simple event processing, which is events at a time with or without mediation, event driven architecture, event processing in the context of SOA, Service Oriented Architecture, and Business Process Management, BPM. As well as high performance often mission critical event processing, which is called “Complex Event Processing”, which is also perhaps the most interesting type of event processing and almost always the ultimate goal of any type of event processing.

So let's focus on this type of event processing for a minute. Typically, this includes high volumes of continuously or 'burstilly' streaming events that are of consequential to business, emanating from within, and are outside the business. These events from various sources have to be filtered, aggregated, correlated in real-time into a pattern that may represent a threat or opportunity to the business.

After that, a business process management system, or a custom application, or a human being might take an action to respond appropriately. Complex Event Processing systems need very special capabilities, ability to handle an order of magnitude highest performance in throughput, processing, and an ability to respond in real-time.

So CEP, typically, is the upstream capability that is sensing events coming in. And once filtered and aggregated, these get funneled to other systems. So the performance has to be off the higher order.

And it seems like everywhere you look nowadays, you see something about Complex Event Processing. Why all this buzz?

Sure. The volume of data bombarding an enterprise is increasing exponentially. So Gartner estimates that today a large enterprise is being hit with 10,000 to ten million events per second. Network bandwidths are not constrained any more, transaction volumes have increased tremendously, new types of transactions and interactions are emerging so you need to be able to handle tremendous amount of data.

Now, if you look at it from a slightly different angle from a technology evolution perspective, about 50% of the enterprises are well underway in their SOA implementation, another 40% have specific plans. Once all these services get invoked at the various layers of the enterprise, there will be tremendous amounts of data flowing through the enterprise backplane and event processing is the only technology, reasonable technology and cost effective technology that can take advantage of that.

So that's sort of from the supply side of data. And then from the demand side, couple that with the fact that customers and markets are becoming increasingly impatient in terms of standard of service and how service needs to continuously improve. A very simple example of that is expectations around overnight delivery.

The SLA for that has increased tremendously. Also, the final kicker is cost containment. Feeling the heat of globalization, enterprises are increasingly focused on cost and CEP is the only technology that can address the data volume and the response time issues that I just referred to without putting in place really costly homegrown solutions.

Now, does this mean customers implementing SOA, or BPM, or BAM, or integration, do they have to start all over again?

Oh no, they don't, not at all. We have conducted a primary market research survey in fall of 2007 with, in fact, ebizQ, you guys, asking people about their event processing implementation goals. And of the 450 respondents, 70% said that they have implementation plans with their SOA, BPM, or BAM projects for event processing. This is absolutely the right approach.

Event processing is not a rip and replace technology but complementary to SOA and BPM. And as far as BAM is concerned, it is one of the first and foremost applications, you know, that uses applications as leveraging event processing. If you talk to Gartner's Roy Schulte, he will concur. Also, BAM is very complementary and almost required for a BPM implementation.

So you can see how these are all sort of tied together and they should all be thought of as complementary technologies coexisting with each other and interfacing with each other.

Excellent. So how does someone get started with event processing?

So I sort of have a three-pronged advice. Here's sort of my advice based on what I've seen that works well with customers. Number one, think about your business with an event limb, think about events, their sources, their consumers, and things of that nature. Then number two, if you are implementing a SOA or a BPM project, think about which part of it lends well to event processing.

Are parts of some of your business process going to benefit from real-time information and real-time action? I think absolutely. Your challenge is to identify those. Can your services be represented as events and do they need to be? The answer in certain cases is absolutely. And then number three, identify a small project.

Typically, I have seen what really works well is a BAM implementation. Say for a particular business function like your sales order, implement event processing for such a project and prove success to the rest of the organization; it's that easy.

For one, the companies that admitted to being frequently hacked outsource at least some of their software development. Germans were the least likely to outsource their code, while Americans were the most likely (40% outsourcing for Germans, 61% for the United States of Somewhere Else). Note: to listen to my podcast on the subject of outsourcing and application security, click here.

66% of respondents said they were either using or in the process of adopting SOA, (with the fewest in the UK, and the most in Germany), but admitted that they little understood the threats SOA would introduce.

Finally, data protection is the key motivating factor behind companies getting serious about application security.

Gotta say, it makes sense to me.

An interesting post over at Security Fix goes into detail on the recent Hannaford breach, from which 4.2 million credit and debit cards were stolen from store networks.

And what makes this story interesting is that Hannaford was no TJX, as in they weren't just leaving their data tucked behind the store sock display and in open site. In fact, Hannaford had been compliance certified in both 2007 and again in early 2008, but what that proves is PCI simply isn't extensive enough.

Simply put, PCI compliance is mostly written for e-tailers, and not for bricks and mortar type of business with most of their assets existing offline (which is a little harder to pin down with a simple software fix). As the perps haven't been caught yet (if someone calls up and tries to charge a Yacht on their credit card without even looking at it, call the authorities), experts are currently speculating that it was likely an inside job.

So how'd they do it? Most security defenses can be compared to a candy bar, i.e. crunchy on the outside, creamy and data richy in the center, and once the intruders gained access, it's easy for them to get around and do their damage, which in Hannaford's case enabled the infiltrators to install malware on the point-of-sale systems of 294 stores and simply collect all the credit and debit card number as each transaction was authorized (to listen to my podcast on this very subject, click right here).

How do you stop it? Network segmentation. Said Avivah Litan of Gartner Inc., "The PCI standards don't recognize that there's no good reason for a company's stores to be able to talk to one another when it comes to [processing] card data. The fact that malware was spread across almost 300 stores shows there wasn't good network segmentation in place at Hannaford."

For Hannaford, it's back to the security drawing board. They're putting military strength security in place, so the next time you accidentally find a stun-grenade in that bushel of apples you brought home from the supermarket, you know who to blame.

Download file

What follows is a transcript of my podcast with Jack Danahy, Founder and Chief Technology Officer of Ounce Labs and one the industry’s most prominent advocates for software security assurance. In this podcast we discuss the security perils of outsourcing application development, whose responsibility it is to assure that applications are secure, how to actually make sure they are secure, and what Jack thinks the future of application outsourcing is both in terms of risk and reward.

What are some of the main security problems that arise when a company outsources their application development?

I would probably characterize them in two buckets and the first is communication. And we learned this early on as outsourcing was taking off in terms of functionality that organizations had to be pretty specific about what they wanted, if they wanted to get the most value out of the outsourcing. So it’s sort of – say to the first one is communication and the second one is enforcement where functionality is something again, which can be designed for.

It can also be fairly easily tested for and people know how to do that well. In security, the combination of these two things takes a slightly different form. A lot of organization haven’t really stopped themselves internally to think about what security means for an application, or business purpose to which they’re going to an outsourcer, nor have they thought hard about how they’re going to check to make sure that those things have been done.

So sometimes, what we’re seeing most is a lack of communication of what exactly an application is going to do and what’s going to require in terms of security. And then on the back end, they’re often times is a lack of sufficient enforcement technique and technology to be certain that the application has delivered satisfies those security requirements.

Great. Isn’t it the responsibility of the company developing the application to make sure it is secure?

Yeah, I think that’s exactly the right point. And the problem is that security is not a word that means the same thing for every application or to every organization. So I’ll give you an example. If I’m simply hosting up a website, and all its going to be doing is soliciting market feedback for something, and is fairly straightforward, and is not taking in private information, or exposing private information, then its level of security is by its nature going to naturally be lower than will be an application which is being developed perhaps to do payment, or transaction processing, or point-of-sale.

So as a result, the outsourcing group that’s responsible for developing the application, may very well develop a perfectly secure application for some definition of security, but it may not fully understand the business purpose of the application is going to be put to. And as a result, it may not be secure enough for that purpose. So the answer is, yes, they should design a secure application, but back to my earlier point on communication, it’s the responsibility of the organization asking them to build it to define what that means.

How common is it to have security vulnerability in an outsourced application?

I think, first off, its very, very common to have security vulnerabilities in a lot of different kinds of applications. One of the reasons why Ounce Labs is having the success we are is because a lot of organizations recognize that great applications meant to do a certain job whether it was perhaps not intended to be networks automatically, or that was intended to take in less secure data, and either the landscape, or the information needed has changed, aren’t necessarily designed to be as secure as they should be.

So this is not simply within the purview of outsourced applications but it’s pretty general. Outsourced applications are even more problematic, mainly, because of the fact that the organization developing it sometimes misses on the requirements for security for the groups that are actually asking them to build it.

And a good example of this would be any number of the outsourced applications that have resulted in some of the private information leakage. And many even times, it’s a well-built application that simply didn’t understand that the information was going to be a private style information.

How can a company make sure their applications then are free of vulnerabilities when they’re outsourcing?

I think one of the things we want to talk about in terms of an outsourced application when we talk about vulnerabilities is the first version, or the first flavor of vulnerabilities we care about, are those which sort of omitted problems, right. So I forgot to tell the provider that this information is going to be private and they should make sure that they never store it, or they only store it encrypted, or something like that.

And so the great way to do that is just tell them up front. The information that’s coming in this particular part of the application is going to be private, its confidential for me, or its going to be private from the user, so please be sure when you build your application that only authorized people can touch it, and only the people who the people who are sending it in really know what it looks like, and if you have to store it, its stored in a safe manner. Right.

So that is one of the big places where adding this kind of value can help by giving them that information upfront. Once the software arrives, best efforts being what they are, it’s still the responsibility of the organization who’s going to be running the software to ensure that the software as delivered is going to meet those security requirements.

So we definitely recommend using software analysis technology such as Ounce Labs to go through that application and be able to very conclusively say every time this data comes in, its encrypted, or its always destroyed and never stored, or that the authorization model is sufficient to make sure that the wrong people don’t have access to it.

So it’s this combination of being upfront, and taking the time, and sort of having sort of the internal rigor to define clearly for the outsourcer what it should look like, and then having both within your contract language as you define those requirements, this capacity to do enforcement, and then actually doing the enforcement on the back end so when it lands you can check to make sure it’s what you thought it was.

What are some of the warning signs that you might not want a company to develop your applications?

Well, a lot of what we see is some really substantial, favorable traction among the outsourcing community for taking on this style of requirement gathering this additional rigor in the development process.

But if you run into a company that says that they do not want to be held to this, that they don’t want the contract language to say that you’re going to reserve the right to check the code to make sure that it’s secure, or that you’re going to be asking them to do a specific set of things that you will later enforce within the contract with languages and sometimes with cost recovery. If they’re unwilling to accept that, that should really raise a massive warning flag because either number one, their expectation is that they’re likely to make makes a mistake and not deliver it.

Or number two, that their existing processes are pretty rigidly defined and so it’s difficult for them to move off of those to support your needs from a security perspective. Or number three, that they have a lot turnover perhaps in terms of their personnel and so they don’t have a sense of confidence that the actual people who will be doing the development are capable of manufacturing an application to the standards that you’ve given them.

So the main warning sign we look for are organizations, which are reticent to support what, I think, are very, very straightforward security requirements, which look a lot like functional requirements that most organizations are happy to take on.

Now, what do you see as the future for both outsourcing in terms of both the risk and the rewards?

Well, I think that there continues to be a great deal of motion not just from the cost-saving perspective, which clearly is one of the early drivers of outsourcing but the capacity of outsourcing to allow organizations to focus more directly of their core businesses. So financial services institutions can focus on great financial attractions with their partners, or healthcare agencies can focus on healthcare and not on application development.

So I think that the ongoing rewards will remain largely the same as they have been with his capacity of folks in your core business and achieve these cost savings. And I think the risks as more organizations begin to treat security as a fundamental almost functional requirement, I think, what you’ll find a happening is that the risks will actually go down.

I don’t think the risk are going to increase because I think the biggest risks existed when organizations didn’t feel comfortable asking for more secure applications, didn’t feel comfortable in their definition. In order to feel comfortable, sort of demanding that they be allowed to reserve the right to audit these things after they get delivered.

So I think what you’re actually going to see is that the rewards will continue to maintain their value and that the risks will actually decline as organizations take advantage of the knowledge that they can as for specific security characteristics which will protect them from liability, and that they will actually be able to enforce those when they come over the wall so that they will be more with in keeping their own internal and external compliance guidelines.

And if you look at all the password tollbooths needed to access all the various places on the info superhighway, it start to look more like driving the Garden State Parkway down to the Jersey Shore (which has something like a million tollbooths).

Enter OpenID, which, with a two-part authentication process, promises single-sign on across the web. The only problem is that at this point, across the web is not all that extensive at this point. But recently, both Yahoo and Blogger have joined the ranks of OpenID providers, which means you can use your Yahoo or Blogger passwords for those sites to log onto OpenID.

While it's still not complete, as neither site allows you to log on to their sites using OpenID, it's a start. Now if you could only remember your Yahoo password.

According to an article at Security Focus, while the US Department of Justice has had some success going after online money laundering sites in countries that continue to be hacker havens, just as many spring up to meet demand.

"Our hopes are that, at some point, we can bring Russia on board with these cybercriminal investigations," Cox said. "In the past, we had written off Russia and Romania (thinking) we would never get cooperation from them."

The DOJ has also beefed up it's cybercriminal resources, growing from 10 attorneys in 2000 to 30 today (while you could figure the increase in cybercrime dwaf that growth). But you can also point to the recent arrest of 11 Romanians as some evidence that the US is having some success in getting the more cyberlawless countries to cooperate.

But still, it's a mighty big world wide web, and while you do need online law enforcement, trying to stop cybercrime by stopping the criminals is like trying to stop cancer by outlawing it.

According to eWeek, Paypal, which is one of most often imitated sites in phishing attacks, is in the process of blacking any transaction using a Web browser that doesn't have anti-phishing protection.

PayPal, one of the brands most spoofed in phishing attacks, is working on a plan to block its users from making transactions from Web browsers that don't provide anti-phishing protection. PayPal, which is eBay owned, said that they will no longer support browsers that do not have blocking for identity theft-related Web sites or use EV SSL (Extended Validation Secure Sockets Layer) certificates.

In a white paper that details the five-pronged plan, PayPal specifically mentioned a specific group of customers who continue to use old and 'unsafe' browsers. "At PayPal, we are in the process of reimplementing controls which will first warn our customers when logging in to PayPal of those browsers that we consider unsafe. Later, we plan on blocking customers from accessing the site from the most unsafe—usually the oldest—browsers," he declared.

Among the 'unsafe' browsers mentioned were old and no-longer-supported versions of Internet Explorers, as well as Apple's Safari browers, which has no anti-phishing protection, and does not support EV SSL certificates. And while EV SSL certificate is not completely fail safe, PayPal believes it does offer a fairly easy and quick safe and unsafe site visual when surfing sites on the Web (and would likely be improved upon). In a separate announcement, both Firefox and Opera browsers have announced their intention to start supporting EV SSL.

Now let's hope PayPal doesn't start banning people that continually make tacky purchases on eBay. Which reminds me, I wonder how much that purple Elvis Lava Lamp is selling for now?

In another sign that this is in fact the direction the industry is going, last week Microsoft announced at RSA that they were looking to take a back-to-basics approach to security (is that sort of like saying 'Turn around and run from Vista as fast as possible!). According to Search Security, Microsoft is looking to prevent future infections and attacks by using features like whitelisting, futher integration of TPMs and more use of code signing.

While these approaches have already been put to use in Windows XP and Vista, Microsoft continues to search for ways to make the OS as well as core application smarter and more efficient in order to block the threats as early as possible, while making them more automated and less intrusive.

"The threats are more complex. It's a maze now. We're seeing on average about a thousand new threats every day," said Vinny Gullotto, head of Microsoft's Malware Protection Center. "I'd say back in the days of LoveLetter and Nimda, we would see about 500 a month. Signature-based technology should be a final backstop. Behavior monitoring should be the main defense."

Still, Microsoft acknowledged that targeted threats like rootkits and custom Trojans used in many spear-phishing attacks represent a unique problem that won't be solved by signature-based tools. And Gullotto predicted that we have not even seen the peak of the problem just yet.

According to Intel, their return on Security Investment (ROSI) has a much higher level of accuracy then any other method currently being used. And while they admit that it's not a one size fits all metric, and most companies only want value measured their way, they say it does offer an empowering view of security value, which is likely a much better approach in the boardroom then the typical security sales pitch of, "Do this or else."

Intel breaks it down into five different topics, which are:

1) Practical Aspects of Measuring Security

2) Getting a Return on IT Security Investment

3) Managing the Effort to Measure Security

4) The Problem of Measuring Information Security

5) The Four Dirty Questions of Measuring Information Security

Definitely a recommended read right here.

According to Symantec's most recent Internet Security Threat Report, the security industry is very near the tipping point (and by that I don't mean the point where you start thinking of rewarding the wait-service for their exceptional service).

As spelled out by Symantec, the tipping point in security comes when the number of legitimate programs are outnumbered by malicious or illegitimate ones. And in Symantec's last security report, they identified 1,122,311 unique threats, of which 711,912 were known to be created in 2007, which represents a 468 percent increase from 2006.

Why this is significant is, in terms of proper white listing and black listing, with so many ill intentioned programs looking to do damage, it makes black listing all that badware virtually impossible, and leaves white listing as the only sane alternative. And from those numbers, it clearly looks like we've passed the security tipping point, and maybe not in the too distant future TIPS will mean too insure proper security.