The Internet front door to almost every bank and financial services company in the world is guarded by two sets of firewalls defining DMZ. Nearly every e-commerce site sits in a similar DMZ in what has become the de facto standard in Web security architecture.
According to Sun Microsystems Inc., “In today’s tumultuous times, having a sound firewall/DMZ environment is your first line of defense against external threats.” But I would argue that guarding the perimeter is lulling organizations into a false sense of security that results in ignoring the implementation of other security mechanisms in their applications and databases.
In contrast, the Internet front door to MIT doesn’t have a DMZ and pretty much doesn’t even have a firewall. Universities begin with an assumption that everything is open, but these large organizations are arguably no more vulnerable to external threats than banks and financial institutions — and perhaps less vulnerable to internal threats.
A key reason for reduced vulnerability is the approach many universities take to creating authorization and application-level security in the absence of a secure perimeter. For more than a decade, universities have been implementing homegrown systems and working with vendors to ensure that their products don’t make assumptions about working behind a firewall. We look for systems to incorporate application-level security based on verifiable user identities — an approach that continues to gain ground as organizations realize that firewalls alone don’t provide the level of security they need in today’s world.
In your own organization, do you pass around unencrypted passwords and data inside the firewall because you know you’re behind the firewall? Are your application servers available to any request from any-where (because they are behind the firewall) or only to those Web servers that need the applications they implement? Is everyone with access to applications allowed full access, or is each person’s role (customer, authorizer, accounts payable clerk) part of the authorization protocol to applications? These are some of the issues we must face once we realize that firewalls don’t really provide full application security. After all, once the firewall is breached, the outsider is inside, so we can’t treat all insiders alike.
As a result, there is a growing interest in standardizing approaches to secure authorization and application access. Many security architectures at universities (and some corporations) are based on the Kerberos protocol and software (http://web.mit.edu/kerberoshttp://web.mit.edu/kerberos), first developed at MIT in the 1980s and still going strong. In fact, Kerberos is in the background of operating systems from Apple, Sun and Microsoft, but it’s not yet fully implemented in many commercial applications.
In addition to Kerberos, the Shibboleth Project, sponsored by Internet 2 (http://shibboleth.internet2.eduhttp://shibboleth.internet2.edu), is developing software to attack the problem of cross-organizational authentication. The Liberty Alliance is working on standards for cross-organizational authorization in Web services environments (www.projectliberty.org). And Kerberos can already complement or enhance the deployment of Shibboleth or Liberty standards as it evolves in both intra- and interorganizational infrastructures.
The problem of securing the myriad applications and databases within large organizations isn’t going to be solved by developing increasingly secure firewall technology. Firewalls can go only so far; at some point, you’ll have to develop a secure identity structure that’s incorporated into each and every application. And projects such as Kerberos, Shibboleth and Liberty will lead the way.
