The Security Skeptic

Dark Reading's Kelly Jackson Higgins wrote an interesting article following the announcements that three top level domains - arpa, org, and uk - will soon adopt DNSSEC. Kelly interviews me and several colleagues to gauge the significance of these announcements. Find the article here.

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID686 by Dave Piscitello  

A recent article in ISSA Journal describes risk-based authentication, a technique that adjusts the credentials an individual must provide to verify his identity based on the threat that the party attempting to authenticate is an imposter. The author describes many bases on which the risk of impersonation is gauged, including the weekday, time and location from which the party is authenticating, whether the party frequently connects from this location, the endpoint device the party uses to connect (i.e., a computer that the user has registered with the authenticator), etc. Anomalies in any of these and other criteria cause the authenticator to add challenges to the baseline authentication method. The added challenges are designed to increase confidence that the party is whom he claims to be, i.e., personal questions that only the authorized party in theory can answer. In principle, the more this session attempt deviates from the user's norm, the higher the risk, and hence the user must provide greater reassurance to the authenticator. A breaking point can be implemented: too many anomalies and the party will be blocked from connecting.

I like the concept, but it's too narrow. In addition to authentication, I'd like to see authorization be risk-based as well. There are many circumstances where the risk of disclosure, potential for coercion, etc. might be sufficiently high to warrant an "access denied from your location, at this time" action. Prior to authentication, the risk of accessing sensitive information from the endpoint device used should play a factor; for example, while an employee might be permitted access to email from a public computer, it may be appropriate to deny access to a database from that computer.

I described a "continuum of trust" at several seminars that complements this thinking. The actions involved in asserting trust (assessing risk) are illustrated below:

Using the risk-based strategy, begin by determining the risk associated with the device, location, day and time, etc. If the risk is acceptable, allow the user to authenticate, using the risk analysis described earlier. Continue by enforcing access controls on data requested, again according to risk.

The last component, exit control, is not risk assessment, but risk mitigation. Make certain that nothing that would disclose the user's credentials, activities, and of course the data accessed remain on the endpoint device before closing the session.

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID685 by Dave Piscitello  

Participate in any mailing list about firewalls and you will routinely find someone who'll post a query, "Are firewalls obsolete?" A recent post asked the question with a somewhat contemporary twist: Are firewalls obsolete in a world involving enterprise Webservice SOA?

This and all firewall obsolescence questions invariably call attention to the elephant in the conference room no one cares to talk about.

Firewalls are middleboxes (RFC 3234 classifies all sorts of firewalls as middleboxes and RFCs, even Informational, are more reliable sources than Wikipedia, right? ). Firewalls are one element in a line of defense. From an attacker's viewpoint, firewalls represent one line of defense that must be breached (for some set of attacks). Today, even the stone stupid attackers burn very few brain and CPU cycles attempting to breach IP firewalls. It is much easier to go after web services and web application code that is written by folks with little security clue, who use grossly generous language constructs, and compound the crime by ignoring the precious few OS and web server access control mechanisms they could employ if they'd taken a minute to read the man pages. (Two of my favorite quotes regarding web application development and secure coding come from Paul Melson's, who claims web services are an "epic fail from the beginning" and Marcus Ranum, who calls them "bad ideas happening fast".)

Each time a question of this kind is raised, it provides yet another opportunity to illustrate to even the most obdurate network designers that "the perimeter will save us" is a security principle that was long ago overtaken by events. This is a good thing: and after only two decades, we are actually turning our attention to considering remedies closer to communications endpoints.

The problem we still face is one of addiction. The historical comfort and debatable success that perimeter enforcement solutions provided created "a box in the middle will cure our application woes" mentality that persists today. What we really get each time we substitute a middlebox for secure programming and secure OS (implementation and configuration) is symptomatic relief, not cure.

The security industry is eager to build middleboxes that don't quite cure the woes but narcotize users sufficiently that they are happy to buy expensive boxes, flog configurations, study traffic logs, buy more boxes, flog configurations... Feed the addiction. As long as users are buying the drugs and doping themselves senseless so they can ignore the root causes at the endpoints, we shouldn't anticipate that things will improve dramatically.

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID684 by Dave Piscitello  

Apparently, when in Ronald Reagan National Airport, the answer depends on where you buy your donut.

This morning, I queued to buy coffee from a kiosk called Primo Cappucino in anticipation of my DCA-CLT departure. The coffee was reasonably priced and turned out to be very good. The donuts however, were $4.00, which seems extraordinarily high, even for DC. I don't know if they were good because the ROI on a $4.00 donut seems small.

About one in three customers ahead of me were buying donuts. Glancing about, I noticed a Dunkin' Donuts cart not more than 25 feet from the cashier at Primo Cappucino. I'm still not interested in a donut, but I couldn't resist learning whether Dunkin' Donuts was (ahem) price competitive with Primo Cappucino. I'm imagining a sign that says, "Donuts, $4.00 each, $44.95 per dozen" and thinking of the rioting in the streets of Anytown USA if such a sign appeared anywhere but DCA.

$.78 for a donut at Dunkin' Donuts, or approximately 1/4 of the price you pay at a shop less than 10 yards away.

I walk to one of the standing tables to stir my coffee and people watch. I want to gauge the sorts of people who are buying donuts at each location. A woman in business attire approaches the table, coffee and a Dunkin' donut in hand and asks if she could share the table. I say, "Yes, but only because you were clever enough to buy a donut for $.78 instead of $4.00...".

She grins and says, "stupid is as stupid does..." and joins me in the donut watch.

We both lamented the fact that we could not stay long enough to learn whether the servers stroll over to Dunkin' Donuts when the supply runs out at Primo Cappucino...

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID683 by Dave Piscitello  

My article, Are Commercial Firewalls Ready for IPv6?, is now available at USENIX ;login: online. USENIX has a very practical Copyright : authors own the copyright to their works and grant USENIX permission to publish it in ;login: and on the Web. USENIX owns the copyright on the collection that is each issue of ;login:

Rik Farrow, ;login: editor, has graciously provided a PDF file from the published version, which contains the issue version and date at the bottom of alternate pages.

Happy reading!

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID682 by Dave Piscitello