Firewall redux: Could a public, open software behavior registry squelch useless dialogs?

In response to yesterday's Tech Shakedown of McAfee's personal firewall product for issuing a useless dialog -- one that asks me to allow or block some behavior but that doesn't give me any idea, clues, or hints as to which of those two options to pick -- one ZDNet reader has reminded me of the need or lack thereof for outbound blocking in a personal firewall.

Personal firewalls can inspect traffic going in and/or out of your PC and, should any of that traffic violate a particular firewall's rules, that traffic can be denied passage. Monitoring inbound traffic (vs. outbound) is probably the highest priority for personal firewalls and the people who use them. All though most PC users see their computers as "clients" and the other computers they connect to as "servers," the truth is that, for legitimate reasons, other computers out on the Internet can and do initiate connections to PCs as well. In this respect, the PC essentially becomes a server.

For another computer to connect to yours, some software component on your computer is usually actively listening for an inbound connection request. That software could be legitimate software. Or, it could be software that was surreptitiously placed there by some malware. In either case though, when some software component is waiting for an inbound connection like that, it represents a potential vulnerability that hackers can take advantage of, especially if the developer of that component isn't proficient in certain security techniques.

Using special developer techniques to secure such components is one layer of security. A personal firewall that watches for attempts to connect to your computer is another. When such an attempt happens, personal firewalls check their rule sets to see if the connection should be allowed or not. If the firewall traps a connection attempt and can't find a rule for what to do next (allow or deny it), the end-user is usually prompted with a dialog that says something like "Hey there! I'm your firewall and a computer located at XYZ address is trying to connect to your computer." In many cases, not only does the dialog offer the user a chance to block or deny that specific attempt, but also all future attempts as well (the net result of which is essentially a new firewall rule).

If we studied the traffic flowing in and out of our PCs, we'd probably find that majority of inbound traffic is in direct response to some outbound request or solicitation. For example, when you use your browser to check the home page of CNN.com, CNN.com sends far more traffic to your PC than you sent to CNN.com. Or, when Outlook checks a mail server to see if there's new mail. Or, when your RSS reader pings the RSS feeds that you've subscribed to in order to see if there are any new items to retrieve. Anytime inbound traffic is in direct response to some outbound solicitation, firewalls should allow it. But when inbound traffic is not in response to such solicitations, that traffic merits more attention and usually gets it. But relative to inbound responses to solicitations and the outbound solicitations themselves, unsolicited inbound traffic is probably the rarest form of traffic going to or from your PC. Therefore, it's the easiest to keep an eye on and involves the fewest interruptions to the end user (particularly when there's no pre-existing rule regarding an inbound connection attempt).

In contrast, if a firewall were to apply the same scrutiny to all outbound traffic, end-users would likely experience an initial flurry of dialogs to determine if that traffic should be allowed. As the end-users' responses to these dialogs are added to the rule sets in the firewalls, the barrage would slowly wind down to a trickle. But even so, some security experts including those at Microsoft have argued that checking outbound traffic would sully the end user's experience because of dialog frequency. Microsoft has also argued that the other layers of security that are in place for most users are enough to cover the main purpose of outbound blocking: to prevent a software component from surreptitiously communicating sensitive information to a third party without your knowledge (often the domain of spyware).

For example, between measures found in anti-virus software and the operating system -- particularly in Vista which intercepts all attempts to install software whether the user has administrative privileges or not -- the likelihood of software being surreptitiously installed on a system, or that of an existing legitimate software component getting hijacked by some form of malware, has been significantly reduced. But is it eliminated altogether? That's the question. Because if it isn't, might outbound blocking be warranted? Would "better safe than sorry" make sense?

While that debate can be left for discussion, I feel it's important to circle back to one issue that shouldn't be a determining factor in answering the question: the notion that the resulting dialog boxes will ruin the computing experience. Actually, I agree. Today, given the mediocre implementations of these dialogs for both inbound and outbound blocking, it does ruin the computing experience. Just less so when only inbound traffic is watched because so little of what needs to be scrutinized is unsolicited (equates to fewer meaningless dialogs).

Raising these dialog boxes to the next level where the majority of them are actually useful and lead users into making a solid, informed decision should be the goal. If you ask me, that goal can be attained. It's just up to the community of solution providers to decide that this is something worth working on together, rather than against.

Going back four or five years now, I've communicated this idea to the various personal firewall providers. In fact, I wrote about it back then as well. In response, they've invariably told me about some newfangled technology or intelligence they've developed that will finally eliminate the problem of useless dialogs. They see their ability to provide accurate actionable information in these dialogs as a potential competitive advantage over other solution providers and as such, continue to work on the problem alone rather than with the rest of the industry.

In fact, just today, McAfee released version 8.0 of it's Security Center which includes version 8.2 of the company's Personal Firewall product and to help automate the firewall's decision making process (so users don't have to), it now checks-in with a McAfee-run database that's internally (at McAfee) referred to as hackerwatch (it doesn't appear to have any relationship to HackerWatch.com, but who knows with appearances these days?).

If security solution providers decided to work together, one thing that might result would be a Public Software and Internet Behavior Registry. The idea is relatively simple. Rather than each vendor working on their own to figure out what all the software out there should and shouldn't be allowed to do, establish a database to which developers can contribute a structured description of their software's or Web site's Internet behavior.

Here's a real world example of how this might work. Let's take Research in Motion's BlackBerry Desktop Software as an example. In the course of doing what it does, this software which runs on a BlackBerry user's PC may not only communicate with an external e-mail server, it may also communicate with a company's BlackBerry Enterprise Server (the server that interfaces the BlackBerry infrastructure with a company's corporate e-mail infrastructure). It's exactly the sort of outbound communication that an outbound blocking firewall will warn the end-user about. But, in many cases, the resulting dialog box will be cryptic in nature. Although the dialog may attempt to identify the "offending" software component, it will likely use a filename (sometimes referencing the path to the component) rather than a friendly name that users will recognize as a component that their system should be running.

Not only might the name of the software component be unrecognizable to mortals, the dialog may offer the IP addresses of the servers it's trying to contact, but no other guidance as to whether it should be communicating with those servers. Given the plethora of software and software components out there, it would be impossible for a single security vendor to know what behavior is expected of all the software components that are out there.

But imagine if the dialog box offered the following:

• The technical name for the software component
• The exact version of the software component
• A friendly name for the software component. For example, "BlackBerry Desktop's Synchronization Component."
• A text description of the software component. For example, "This software is responsible for synchronizing BlackBerry e-mail and calendar data with the e-mail and calendar data found in an external e-mail system. That e-mail system could be a Microsoft Exchange Server, a Lotus Notes server, or a POP3-based e-mail service on the Internet."
• A text description of the expected network behavior of the component. For example, "To do it's job, this component may communicate with as many as two other computers or domains. First, the BlackBerry Enterprise Server if it exists or your email service providers server. Second, the Research in Motion domain. If the outbound communication that was trapped is with either of these entities, it is considered normal behavior for this component and you should allow it. Please verify that the IP address of the target system (a) is your BlackBerry Enterprise Server, or (b) is your e-mail service provider, or (c) is a part of Research in Motions Domain. In this example, it should advise the user to check with their e-mail administrators for accurate IP address data for their e-mail and BlackBerry enterprise servers.
• A To-Do list "To verify if this is expected behavior, feel free to use one or more of the confidence checking tools below to give you more actionable information."
• An IP address checker A link that users can use to double check the domain to which the target IP address conforms.
• A component integrity checker A link that invokes an integrity check that compares the signature of the component in question with the vendor's original signature for that component.
• A scan-on-the-spot command If the firewall came as a part of a package that includes anti-virus capabilities, offer the ability to scan the software component in question on the spot.
• A "Research this on the Web" link that pre-populates an Internet search engine with some relevant keywords to see if more information about the software component can be found on the Web.

Feel free to chime in on other ideas for what should be included. But, the key here is that this is the sort of information that (a) would be really useful in responding to the dialog boxes and (b) that no single personal firewall solution provider can possibly generate on their own for every software component out there. So, the way to solve that problem is to develop a public registry to which the developers can contribute this information themselves. After all, who knows better about what the software is supposed to do than the developers? If those developers know that all personal firewall vendors will be checking against that registry, they'll be motivated to contribute the necessary information since it will benefit the users of their products which is good for customer satisfaction.

Today, such a registry doesn't exist. The closest thing to it that I know of is an online database that has been created by UniBlue called the Windows Process Library. UniBlue's extremely cool WinTasks 5 relies on that database as well, but end users like you and me can freely access the Web version to research certain Windows processes to find out more about the components that a firewall may be trapping. In fact, I didn't know about the Process Library until, a long time ago, I was trying to figure out what the Windows component LSASS.exe does. Why? Because my personal firewall was trapping it. Googling LSASS is what led me to the Windows Process Library.

But even that Library isn't really enough. For starters, there are other operating systems besides Windows. Additionally, software behavior isn't the only thing that could be recorded in the database. So too could the behavior of Web sites. For example, to the extent that certain business processes route you to different systems and servers in the course of completing those processes or transactions, that business process and the specific systems that your system must visit could be databased as a "behavior" and, when it comes time to actually visit some Web site like a banking site, what happens next from a process point of view could be compared with the record of what's supposed to happen. The personal firewall could play a central role as users are routed to different systems that their PCs are forced to visit.