SSL Myth Busting: Java Authentication and Authorization Services (JAAS) Framework Handles All Protocols and Mechanisms Securely [Nope.]

Onto the next post in our series debunking SSL myths. Today’s myth: Java Authentication and Authorization Services (JAAS) framework handles all protocols and mechanisms in a secure manner. The Internet resources and SOA Web pages are Web applications. As such, they make use of the JAAS framework, which is a user-centric authentication and authorization collection of Eclipse plug-ins to manage authentication and authorization within an application built on the Rich Client Platform framework. The plug-ins provide an implementation of the JAAS API and can be extended by developers to support their own security needs. The code snippet below shows how easy it is to disable every authorization check in a system implementing JAAS. public pointcut hackJAAS(); : call( * AccessController.checkPermission(..) ); void around() : hackJAAS() { //Do nothing. No proceed-call. } The reason this is such an easy task is that JAAS is a standardized framework. To perform an authorization check, a user must call AccessController.checkPermission. Yet, everyone knows this—both lawful programmers and hackers. That means that if an application uses JAAS, a hacker automatically know which code they need to disable. The hacker doesn’t need to see the source code, nor do they need to see any kind of documentation. The Norwegian Information Security Laboratory does an excellent job of explaining the technical details of this vulnerability, if you’d like more information. For now – another myth...

FDE and VPN: Don’t Throw out the Security Baby with the Legacy Bathwater, Part 2

Editor’s Note: This is part 2 in a series, “FDE and VPN: Don’t Throw out the Security Baby with the Legacy Bathwater.” For part one, click here. What’s the alternative to VPN? For adequate security, Welch seems to be relying on HTTPS (hypertext transfer protocol secure). HTTPS combines conventional Web HTTP with security protocol SSL/TLS (secure-sockets layer/transport-layer security). HTTPS is built into every modern Web browser, and generally is easy for end-users. HTTPS, however, has its limitations. It can put more of a burden on administrators and is only for applications that exist as Web applications running through an HTTPS server. After a couple of decades of experience and refinement, that’s the fundamental trade-off for VPNs. There’s a significant, if well-quantified, initial cost to establish the VPN between the home network and the first remote location. With that first connection in place, though, the remote location can network just as though “at home” with a minimal impact on performance. The slowdowns which plagued the first generation of VPNs have nearly disappeared. In isolation, a VPN-free solution for one particular access is probably easier to set up, on both the server- and client-sides. In the absence of a VPN, though, each additional application might require an HTTPS redirect, a slight firewall reconfiguration, an additional or reconfigured server-side SSL certificate, and perhaps expanded licensing (many software licenses categorize a remote work location as an additional “site”). Room for both It’s easy to conclude, then, that there’s need for networking toolkits to include both VPN and VPN-free choices. Younger and smaller organizations might need to support only a small number of applications...

What We're Reading, Week of 11/14

Dark Reading, Survey: Half of Firewall Rules Improperly Configured PC World, Lock Down Your Wi-Fi Network: 8 Tips for Small Businesses InformationWeek, The iPhone 4S: Ready for Business Infosec Island, Ten Tips to Stay Safe on Cyber...

What We’re Reading, Week of 11/14

Dark Reading, Survey: Half of Firewall Rules Improperly Configured PC World, Lock Down Your Wi-Fi Network: 8 Tips for Small Businesses InformationWeek, The iPhone 4S: Ready for Business Infosec Island, Ten Tips to Stay Safe on Cyber...

FDE and VPN: Don't Throw out the Security Baby with the Legacy Bathwater, Part 1

By Cameron Laird In “Die, VPN! We’re all ‘telecommuters’ now–and IT must adjust,” John C. Welch accurately describes much of the changing landscape through which corporate computing is traveling now: Work is as likely to take place outside the office as in; Work in some domains has become as likely to take place on an employee’s device as one owned by the corporation; A large percentage of all work can be done through the Web; and “Endpoint” (in)security is nothing short of horrifying: the data equivalents of bars of gold are regularly walked unescorted through neighborhoods so bad they can’t help but end up in the wrong hands. The situation is unsustainable; what should be done? Welch’s conclusion: adopt full-disk encryption (FDE)–and ditch VPNs. His arguments for FDE have merit. The ones against VPN? Well, I expect to use VPNs for a long time into the future, and you should, too. Here’s why: What is VPN? First, let’s review the basics: information technology (IT) departments are responsible for computing operations. Computers have, in general, the capacity to make general-purpose calculations. This means both that IT is called on to perform a wide, wide range of tasks–everything from routing telephone connections in a call center, to control of machine actions in a steel plant, to running accounting programs in a hair salon–and also that there is inevitably more than one technique to complete each task or fulfill each requirement. Even the simplest analysis of the “remote problem” exhibits these characteristics. Let’s begin with Welch’s starting point: much of the work of the future will be done outside the conventional workplace,...