Fulfilling Your Security Requirements | Java Security Solutions

Once you have clearly defined your security requirements, you need to choose how to satisfy them. For instance, you may select to use a third-party security application, or integrate some of the available technologies and implement custom security functionality.

You may want to consider the following suggestions:

Use firewalls and De-Militarized Zones (DMZs) as appropriate. It is a bad idea to connect your system directly to the Internet and open it to attacks. In addition, be careful with what you download to your system.

Cross-Reference
Chapter 21 provides a discussion on firewalls and DMZs.
Since security is in constant evolution and security holes are often addressed in new releases, always use the most current versions of third-party applications and network software.
Perform audits frequently and investigate all anomalies.
Keep current on security issues by looking into sites such as CERT ( www.cert.org ) that announce potential and actual security breaches.
Consider your vulnerability to security breaches such as attacks that can
- Alter system resources. This is a serious attack that compromises data, and probably affects your level of service. The good news is that this type of attack is - in practice - difficult to achieve in most Java environments.
- Compromise a user 's privacy. This is another serious attack that annoys users and has the potential to modify messages and e-mail. Using a combination of technologies gives you strong protection against this type of attack.
- Cause denial of service. This is a moderate attack and one of the most common. A denial of service attack can be accomplished by exhausting system resources such as consuming CPU cycles and allocating all available memory. Java does not provide a way to defend against this type of attack. Recovery may be as simple as rebooting the system - although you may lose some customers in the process.
Cross-Reference
Chapter 2 provides a discussion on different attacks and security vulnerabilities.

The following sections describe some of the available Java technologies that you may consider.

Considering communication and trusted path or channel

As part of the CC, communication is the functional requirement that guarantees the identity of the parties during data exchange. This is a concept called non- repudiation . The most popular technologies are digital signatures and message digests. The trusted path or channel functional requirements address the need for trusted communication between the system and its users (including third-party applications).

Cross-Reference

Chapter 9 discusses message digests, and Chapter 11 describes digital signatures.

Message digests are used to verify that the contents of a message have not been altered . Message digests, however, do not verify the message came from the supposed sender. Since algorithms for the digests are public, anyone can create a message, generate the digest, and then say it came from anyone in the world. In order to authenticate a message and its sender, you need to use digital signatures.

Digital signatures are a way to label messages or objects so that the creator of that message or object can be positively identified to the recipient or user. They also verify that the contents have not been altered.

Tip

If you would like a third party for public key cryptography, products such as JSAFE, J/Crypto, and Cryptix are available. JSAFE offers support for RSA, DES, Triple-DES, RC2, RC4, and RC5. You can find JSAFE information at the www.rsasecurity.com/products/bsafe/index.html site. J/Crypto information can be found at www. baltimore .com/products/jcrypto/index.html . J/Crypto includes X.509 certificates, RC4, Triple-DES, hashes, and key exchange algorithms. Cryptix information can be found at www.cryptix.org and also provides RSA public key cryptography, among others.

The Java Secure Socket Extension (JSSE) is now integrated with the J2SDK v 1.4. It enables secure Internet communications by providing a framework and an implementation for a Java version of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. Some of the functionality included in JSSE is for data encryption, message integrity, and server and client authentication. You can use JSSE to secure data transmission between client and server using any application protocol, such as HTTP or Telnet.

Cross-Reference

Chapter 23 discusses the JSSE framework.

Considering component access

Component access is the functional requirement that controls a user's session, session locking, and access history. Some of the Java technologies that control component access include the class loader, the sandbox architecture, Java protected domains, the byte code verifier, and the different containers (such as the EJB container and the Web container).

When you design a component, you must think about the access rights necessary to access the component. You can specify security roles based on these access rights, and use these roles during deployment Once the component is deployed, the administrator of the J2EE server maps the roles to the users or groups of the default realm - this can be accomplished by using the deploytool .

Note	J2EE has roles and groups that represent a logical grouping of users. A J2EE role is a category of users specific to an application and a group is a category of users for the entire J2EE server.

Java-protected domains allow multiple and unique permissions for applications by enabling the use of permissions or preconfigured settings.

Considering cryptographic support

The cryptographic support requirements address the life-cycle management of cryptographic keys and their access, distribution, and destruction. The Java 2 SDK v 1.4 provides cryptographic services in the java.security and java.net packages.

The Java Cryptography Architecture (JCA) is a framework for cryptographic capabilities in Java programs. These capabilities include support for RSA, digital signatures, and message digests. JCA allows these security components to have implementation independence and, if possible, algorithm independence. Other security components in the Java 2 platform include the Java Cryptography Extension (JCE) that provides key generation and cipher support, and the JSSE API discussed earlier.

Note	The JCE also provides support for encrypted streams; therefore, there are JCE export restrictions.

Considering identification and authentication

The identification and authentication functional requirements address the need to establish and verify the identity of a user. Java Authentication and Authorization (JAAS), Java GSS-API, and Kerberos are some of the Java technologies that address this functional requirement.

Tip	As discussed in previous chapters, there are a several technologies that address the need for identification and authentication, such as digital signatures and certificates for authentication. Also, the security manager and Java-protected domains are used for authorization.

Kerberos v 5 is used for authentication and secure communication of client and server applications, and it is the basis for many authentication systems. The purpose of the Kerberos system is to authenticate one principal to another.

Cross-Reference

Chapter 16 discusses Kerberos.

The Java Authentication and Authorization Service (JAAS) is a set of packages that implements the standard Pluggable Authentication Module (PAM) framework and services to authenticate users (determine who is executing the code) and to authorize (enforce access controls to) users. JAAS is now integrated into the Java 2 SDK v 1.4.

Cross-Reference

Chapter 19 discusses JAAS.

The Java GSS-API is used to secure the exchange of messages between applications. It contains the Java bindings for the Generic Security Services Application Program Interface (GSS-API), which defines a uniform API to security services including Kerberos. The GSS-API is defined in RFC 2853 (found at the www.ietf.org/rfc/rfc2853.txt site).

Cross-Reference

Chapter 17 discusses the Java GSS-API.

Considering security audits

This functional requirement addresses the need to recognize, store, and analyze information about security activities in the system. Auditing is important because it provides a history of events that help identify what happens during an attack or security breach. The revelation of security breaches are usually discovered through audit trails, which flag unauthorized access, indicate variations from normal operations, and help detect violations to the security guidelines and policies.

Tip	Because audit information is very important to your system, protect audit records at the highest level. Auditing has limited support in Java provided by the SecurityManager . There are plans to define a set of standard auditing functionalities for the future.

The security manager component is part of the core Java security architecture. It is responsible for determining whether certain requests to access particular valued resources are to be allowed.

Cross-Reference

Chapter 18 provides a discussion on the security manager.

You can extend the SecurityManager by using the policytool program and setting additional functionality. If you wish to monitor security access, you can set the java.security.debug system property.

Note

There are several concepts related to auditing that you should consider in your system, such as:

Monitoring, for intrusions and violations.

Security auditing, such as internal and external auditors that look for backup controls, contingency plans, and standards.

Audit trails, which keep records of transactions, events, and logs.

Considering user privacy and user data protection

The functional requirement for privacy addresses the need to satisfy the user's privacy needs and is usually satisfied via encryption. Sun's Simple Key Management Internet Protocol (SKIP) allows parties in a communication to agree on an encryption scheme to ensure privacy.

Cross-Reference

Chapter 6 discusses SKIP.

The functional requirement for user data protection specifies the requirements for security functions and policies to protect user data such as access control policies, stored data integrity, and data authentication. The java.security.acl package defines support for access control lists. These can be used to restrict access to resources in any manner desired. The package consists of interfaces (and exceptions). The actual implementations , within Sun's JDK, are provided in the sun.security.acl package.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Secure Programming Cookbook for C and C++: Recipes for Cryptography, Authentication, Input Validation & More

Systematic Software Testing (Artech House Computer Library)

C++ How to Program (5th Edition)

Programming Microsoft ASP.NET 3.5

Professional Struts Applications: Building Web Sites with Struts ObjectRelational Bridge, Lucene, and Velocity (Experts Voice)

Microsoft Visual Basic .NET Programmers Cookbook (Pro-Developer)