I spent last week in San Francisco at the RSA Conference, the IT security show equivalent of the Super Bowl. All the big security players exhibited with booths ranging from big and impressive to the supremely bizarre.  

In speaking with attendees, vendors, and analysts (hear my podcast with BankInfoSecurity), I discovered that most in the industry equate security with keeping the "bad guys" out. Sure, everyone needs firewalls, intrusion detection, and antivirus. But what about the "good guys" that need to get in?

In today's business world of partnerships, collaboration, outsourcing, and remote office workers, there is an increasingly complex and diverse population of "good guys" that need to get access to secure systems. Using technology that was designed to keep people out to now let people in is proving to be both frustrating and costly. The consensus is that there must be a better way.

In the closing RSA keynote, Al Gore cited a company that sought to phase out the harmful chemicals that they used to clean their circuit boards. The company first asked, "What alternatives are there?" Then, one day, an engineer asked a new question: "How do the circuit boards get dirty in the first place?" That question, and the resulting answer, created a new type of circuit board that has proven immensely profitable to the company.

This reminded me of my conversation with another speaker at the show named Alan Karp from HP Labs, Ph.D. in Astronomy.

Alan contends that the fundamental approach that vendors use to solve the issue of remote access is flawed by design. The typical approach—one he refers to as Identity-Based Access Control—associates credentials to a username. The flaw is the inability to classify a user as a "good guy" or a "bad guy" by his identity alone; it is also determined by what the user does, i.e., his actions.

Alan has published research on his approach to remedy this problem by combining identity with upfront policies that determine when, what, where, and why. I found this especially interesting because this is a similar approach to what we use at Axeda for our products.

For example, as a vendor, you may want to access systems within your customers' secure networks, but your customers want to approve when you can login, what you can do once you are logged in, and also know why you are on their network. Adding the ability to process business policies prior to granting remote access puts customers in control and adds context to remote user activity. That's a much-needed element for compliance reporting.

This approach makes perfect sense when you step back and think about it, but sometimes it takes a different perspective (from a rocket scientist no less) to figure out a better solution.