oliage Software Systems has put Enterprise Java and .NET through their security paces, and what they discovered can help you decide which platform offers the more secure environment for your applications.
Foliage, a Massachusetts-based provider of custom software and systems integration services, presented detailed findings from its comparative security analysis of J2EE and .NET at last week’s RSA Security Conference in San Jose, Calif. The company has completed more than 150 projects for clients in various sectors?projects which usually involve integration of disparate systems on multiple, chiefly Microsoft and Java-based, platforms. Principal Engineer Denis Piliptchouk and Engineering Director Vince Dovydaitis conducted a battery of “side-by-side” tests to produce a comprehensive assessment of the two platforms’ security; they spoke with DevX earlier this week to walk us through the highlights of their conclusions.
Dovydaitis and Piliptchouk categorized their findings into six security aspects:
- Code containment and execution
- Code and data protection
- Secure communication
- Code-based access control
- Role-based access control and user authentication
- Auditing and tracking
They found that .NET holds an advantage in the area of code containment and execution. Dovydaitis said .NET’s application domains are less permeable than Enterprise Java’s, and Java’s protection domain mechanism doesn’t look as strong as what Microsoft is offering.
Piliptchouk said that .NET’s code verification is stronger by default for local applications. Because a JVM verifies only remotely loaded code by default, Piliptchouk pointed out that “you can run a Java program locally without any security manager at all.”
Code and Data Protection
The engineers found that neither platform offered a significant advantage in source code and data protection. Piliptchouk acknowledges that each platform has its strengths and weaknesses in this area. For example, cryptography on .NET relies on the developer properly configuring CAPI and on a proper Windows Crypto API configuration because it’s so closely tied to Windows. Dovydaitis said that the variety of plug-ins and components available for Java makes it the more flexible platform. But in the end, this category is locked in a draw.
Secure Communication
Enterprise Java is the “hands down” winner for secure communication, according to Dovydaitis and Piliptchouk. .NET developers will need to use IIS for communication protection?and that doesn’t bode well for the platform’s communication security. “IIS might be the most attacked server software in the world,” said Dovydaitis.
Code-Based Access Control
.NET’s close ties to Windows are an asset for code-based access control. The Windows connection gives the new platform a richer set of permissions and evidences than Enterprise Java has. Java is more stripped down due to its platform independence, however, Java’s code-based access control is more mature and offers more configurable policy levels. Still, the engineers give a slight edge to .NET in this category.
Both men approve of .NET’s hierarchical code groups and its allowance for targeted code checks. “.NET seems to have learned a lot from Java security [in the years leading up to its release],” said Piliptchouk.
User Authentication and Role-based Access Control
While .NET offers good authentication out of the box, Piliptchouk was careful to stress how its close ties to IIS hinder its flexibility. “Java code is a little easier because it’s more modifiable,” he said.
Dovydaitis said he believes JAAS is “better than anything available on .NET.” Because JAAS is available for developers to modify and then plug in (“pluggable” authentication modules for Unix, NT, etc.), it provides rich customization, making Enterprise Java’s authentication preferable to .NET’s. .NET is “touting role-based access control as a new thing,” said Dovydaitis. “Unfortunately, it doesn’t get the job done.”
For the Foliage Software engineers, both platforms lack the type of advanced user-based access control their clients need?particularly with respect to permission delegation for users. Dovydaitis said in his more complex role-based access control projects, “we have to build in our own layer of security for determining [user-based] access control.”
Auditing and Tracking
“Neither platform offers much support for secure authentication and tracking,” said Dovydaitis. Although JDK 1.4 introduces a logging package, it offers no secure facilities. .NET offers a managed wrapper around Windows EventLog, but that’s as far as its auditing features go. Consequently, .NET applications are restricted to EventLog’s functionality and limitations, Piliptchouk said
| |||||||||||||||||||||||||
Both platforms provide sound designs and deliver similar functionality, including their allowance for plug-in components, but they have inherent differences due to their vendor/OS bindings. .NET binds tightly to the Windows platform for many of its security services, while the Java platform is specification-based and platform independent. Of course, any sizable project using Java or J2EE products will invoke vendor-specific functionality, but Java’s ability to be customized generally translates into better flexibility. At the same time, .NET is stronger out of the box in many aspects because it offers Windows security features by default.
A significant drawback for of Java is having many bodies participating in its design process, which leads to an inefficient, piecemeal evolution of specifications. Java specifications end up needing custom features before they’re of any use. .NET’s security is more streamlined and cohesive by comparison because its design and implementation are centralized. And unlike past Microsoft platforms, .NET shows evidence of having been designed with security demands in mind.
As the more mature technology, Java does offer more stability. Various enterprise Java products have been deployed, tested, and verified for years on multiple platforms by developers and users all over the world. Conversely, .NET just came into the world after about a year of extensive beta testing. Only now, after full release, will its architecture really be subjected to true field tests by the programming community at large, which inevitably will lead to the discovery of security design flaws and programming bugs.
The Enterprise Security Wish ListDovydaitis and Piliptchouk came away from their assessment with a wish list for the enterprise security that both .NET and Java offer. As in-the-trenches developers who have to answer the call whenever a Foliage client faces a security breach, they have critical requests for Microsoft and the Java vendors.
First and foremost, they want secure code. “We can’t build trusted applications on buggy platforms,” explains Dovydaitis. “All the features of the languages we’re discussing are only as good as the people who wrote them and [their stability depends on] how rigorously verified all these features are.”
Next, both platforms need to develop frameworks for more complex role-based access controls for users. The example the engineers gave was support for permissions delegation. For instance, if a doctor in a healthcare organization is the only person with access to certain data, he or she ought to be able to delegate permissions to coworkers as the organization’s access relationships become more complex?without needing to rely on developers for additional coding.
Finally, .NET and Java must provide much better support for auditing and tracking transactions. Both are inadequate in their solutions. With .NET, developers can use the Windows mechanisms but they need to go outside the .NET framework to get them. Java is adding a logging package, but it is not secure.
