This chapter covers the features of Java and .NET security that make interoperability easier. It also discusses different technologies (such as authentication in the Presentation tier) and the open standards (such as Web services security) where Java and .NET applications can interact. Finally, two interoperability strategies are discussed.

This chapter is from the book

Security by Default

Security exploits and vulnerabilities are often causes of huge financial loss
and disruption of business services. The Computer Security Institute (refer to
[CSI] for details) has reported a worldwide financial loss of circa US$130
million that resulted from virus, unauthorized access, and theft of proprietary
information in 2005, a US$7.3 million loss (compared to US$65 million loss in
2003) due to denial of service attacks, and an average US$355,552 (2005) loss
per incident for proprietary information theft in 2003. A business application
that was considered "secure" running on a Unix or Windows platform (for
example, protected by firewall and anti-virus application) is not necessarily
vulnerability-free when exchanging sensitive business data with another business
application running on a different platform. This is because the interoperable
solution is exposed to security vulnerabilities if one of the applications
(either the sender or recipient) is exploited or is being attacked by
hackers.

There are historic incidents of vulnerabilities in the Windows platform (such
as flaw authentication [WindowsAuthFlaw]) or Java platform (such as a flaw in
the JVM in [JavaVMFlaw]). These incidents are critical and can become the
"Achilles’ heel" (a critical problem that causes financial loss or
disruption to the business service) for the mission-critical Java EE .NET
interoperable solutions. Although the individual vulnerability incident may not
be a direct root cause to security exploits of a Java EE .NET interoperable
solution, any vulnerability exposed on either Solaris OE, Unix, Linux, or
Windows platform becomes a "weakest link" to the security of the
interoperable solution.

Message alteration changing the message header or body
during the transit.

Attachment alteration changing the SOAP attachment
during the transit.

Confidentiality the capability to ensure no
unauthorized access is made to the message.

Falsified messages the message is falsified by using a
different identity of the sender.

Man-in-the-middle the message is being spoofed or
tampered with during transit.

Principal spoofing the information about the user or
subject is being spoofed during transit.

Repudiation the sender or recipient denied or
repudiated about the message being sent or received.

Forgedclaims the claim about
sending the message is forged by tampering with the message content.

Messagereplay(or
replay of message parts) the message was once spoofed and modified for
resending the message.

Denial of service a malicious action to replay a
message continuously or to overload the target service provider until the
service provider is out of service.

To make a Java EE .NET interoperable solution secure by default,
security architects and developers should consider the following security
requirements. Also refer to [WSI-countermeasure] for the details of security
scenarios and the counter-measures to the security threats.

Always Customize Security Settings Do not take the
default security settings of vendor products in the operating environment. Many
business applications are not designed and deployed with security by
default—they are designed with unused system services turned on when
deployed, which may be open to security exploits and vulnerabilities that can
severely impact the interoperable solution.

Use Open Standards for Interoperability Web services
security is currently an open standard for SOAP-based Web services. WS-I Basic
Security Profile (BSP) 1.0 addresses these security threats. In essence, BSP 1.0
extends Web services security to handle SOAP attachments. These standards ensure
that the applications are interoperable.

UseStrong Authentication
Mechanisms.

Use Secure Transport Mechanisms Use of secure transport
mechanisms such as SSL/TLS should address principal spoofing.

Use Digital Signature Use of digital signature should
address the security risks of message alteration, attachment alteration,
confidentiality, repudiation, and forged claims. Signing the SOAP message header
once, creation time, and optional user data over secure transport layer such as
SSL/TLS are able to address the security risk of message replay.

Use Encryption Use of encryption should address the
security risks of confidentiality.

This chapter recapitulates the features of Java and .NET security that make
interoperability easier. It also discusses different technologies (such as
authentication in the Presentation tier) and the open standards (such as Web
services security) where Java and .NET applications can interact. Finally, two
interoperability strategies are discussed.