Application Security – Another Look At JVM

1) Two year old child in the front seat without any restraint (still very common here)
2) Stops in the middle of the intersection and looks both ways
3) Attempts to insert a 1,000 yen bill into the parking garage ticket dispenser when entering
4) Brags about driving once per week for ten years without incident
5) Double parks right across the street from a fellow double-parking crony
6) Pulls the car wide into opposite lane to make a turn
7) Car is spotless after four successive days of rain and snow

8)

Doesn’t want to take hay fever medicine on a Thursday for the upcoming Sunday drive
9) Pulls into gas station, then opens the hood while holding gas hose; looking for gas cap
10) Applies car wax to the tires, then wonders why the tires turned white

With the recent attention given to various application security issues, it is probably time to take another look at closed runtime environments, or virtual machines. First, with machines clocking at well over 2 gigahertz these days, even a robust Java application is about three to five seconds, sometimes up to ten seconds, slower than it’s native executable counterpart. Second, with the whole computing population waiting several seconds to load (we in Japan apparently wait alot less than our US friends), what’s a few less seconds waiting for a runtime or VM application? Wait, please allow me to answer. ‘Ten times more application security!’

For example, the Java Virtual Machine (JVM) operates a security model that is one layer above the OS security model, which usually means one more layer of defense. Then, the JVM security model is centrally defined across all OS, so designers do not have to design separately for each OS, and inherently, introduce multiple vulnerabilities unique to each platform.

The perfect assertion to these claims are financial institutions. At this point, it is safe to say that 80% or more applications running in finance environments are Java, or web applications that are controlled within a Java security model. The biggest reason for this is develop once, secure universally, test universally, and deploy safely.

Recent hipsters spouting out that Java is dead are dead wrong. In the world of Java, the game has just started, and security will be the biggest deliverable. It’s up to Oracle for the most part, since Java’s open-ness also makes it very appealing for Indy developers. Any web analytics program shows that 90% of Wintel machines run JVM, and remember, OSX shipping with JVM is what made it the developer’s toolkit some years ago. That last statement is dating me somewhat, but fellow Cocoaheads that have been at it for more than six or seven years know exactly how important Java was to OSX and Apple at that time.

Comments? Retorts? Please join in the debate.

Leave a Reply