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

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

Summary: 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.

SHARE:

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.

Topics: Servers, Collaboration, Hardware, BlackBerry, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

6 comments
Log in or register to join the discussion
  • MS is the only one who can make this work

    I think that the chances of AV/Personal Firewall vendors collaborating to make this happen is next to none. However, MS could solve the issue by requiring all applications that install themselves to register their network behavior locally (along with the other information you described) and providing an API for them to do so. MS could then provide an API for the firewall software to determine which registered program is accessing the network.

    Why go through all the hassle of checking against a public registry that is likely to be huge, when all you care about is the programs that are installed on your local workstation? As long as the necessary metadata about each application is captured when the application is installed/updated, and a method exists for firewall software to check that metadata, the public registry is not needed.
    t_mohajir
  • Approval dialogs just train people to approve them.

    After 20 years as a network and system administrator, I can't count the number of
    times that someone came up to me and asked me to remove a virus because "they
    clicked on that dialog thing AGAIN".

    AGAIN, mind you. They'd been infected before.

    And these were, most of them, programmers.

    I used to get cross with them over this, but after a while I realized that the system
    was working against them.

    They get so many "should I do something stupid" questions from Windows, they
    can't help the reflex to approve them.

    Any time a program pops up a "should I do something stupid" or "should I allow
    something stupid", it's time to consider whether there's a way to design things so
    the stupid operation isn't necessary in the first place.
    Resuna
  • Risks of system-initiated behavior

    A system that sees initial malware traffic automatically escalated to further traffic with arbitrary entities, is itself a malware risk.

    The main protection against that risk is obscurity, i.e. that the "market share" of the system is too small to attract malware resources.

    But if all defense products used a common database and/or search mechanisms that are externalized and open to "creative addition", you could have a bigger problem.

    The real issue is this:

    "for legitimate reasons, other computers out on the Internet can and do initiate connections to PCs as well"

    IMO, if I have zero entities with the right to access my PC remotely, I have zero reason to facilitate any such interaction.

    Breaking that rule for convenience is as foolish as trying to beat the Halting Problem. The main difference between NT and Win9x was that NT was designed as a network client rather than as a stand-alone OS, and because the Internet is made out of networking, it treats it as a network.

    When NT was rolled into mass consumerland, the prompt result was Lovesan, Sasser et al - direct network attacks of the sort previously only experienced in the server community e.g. SQL Slammer.
    cquirke
  • Good ideas for bad dialogs.

    Getting usefully informative dialogs and alerts is a great idea, but perhaps doomed, given coders' propensity to eschew documentation in general and to ignore - whether through ignorance, management constrainsts, or carelessness - treating users like people, in particular.

    I've been seeing this since 8-bit days, and there's been little improvement. After messing about with computers on and off for forty years, while I maintain a certain curiousity and interest, most of the time I just want to fire up the beast and do what I want to do - without having to become a computer boffin in the process simply to deal with all the stuff that does not work well.

    I like the idea of a centralized on-line registry or database of "legit" apps - maybe tie it in with the current sites' info on OS components and such. Thing is, I think it's a good idea, which is why it likely won't happen. [grin]
    kermidge
  • That would be tantamount to

    Squeezing Microsoft and at least half of
    ZDNet membership out of the picture.

    Best to just ignore useless dialogs. Don't
    rock the boat. Don't make any waves. Can't
    we all just get along? Microsoft likes
    things just the way they are.
    Ole Man
  • RE: Firewall redux: Could a public, open software behavior registry squelch

    Do you think that goal can be attained?

    [i]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.[/i]

    There, now I've asked you! But watch out, because I'm about to ask you how. David, [u]how[/u] do you think that goal can be attained? Do you think that goal is [u]most likely[/u] to be attained: by the corporate interests who have ignored you for years, or by open source freelancers who will post the information publicly, thus compelling the corporate interests to compete amongst themselves to be first to use it, and to use it best?

    [i]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.[/i]

    Great ideas.

    [i]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.[/i]

    The deafening silence of the commercial software publishers is screaming "Don't tell me, show me how it's done."
    Absolutely