| Oracle® Fusion Middleware Deployment Planning Guide for Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0) Part Number E28974-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Deployment Planning Guide for Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0) Part Number E28974-01 |
|
|
PDF · Mobi · ePub |
How you secure data in Directory Server Enterprise Edition has an impact on all other areas of design. This chapter describes how to analyze your security needs and explains how to design your directory service to meet those needs.
This chapter covers the following topics:
The most typical threats to directory security include the following:
Eavesdropping. Information remains intact, but its privacy is compromised. For example, someone could learn your credit card number, record a sensitive conversation, or intercept classified information.
Unauthorized access. This threat includes unauthorized access to data through data-fetching operations. Unauthorized users might also gain access to reusable client authentication information by monitoring the access of others. The Directory Server Enterprise Edition authentication methods, password policies, and access control mechanisms provide effective ways of preventing unauthorized access.
Tampering. Information in transit is changed or replaced and then sent on to the recipient. For example, someone could alter an order for goods or change a person's resume.
This threat includes unauthorized modification of data or configuration information. If your directory cannot detect tampering, an attacker might alter a client's request to the server. The attacker might also cancel the request or change the server's response to the client. The Secure Socket Layer (SSL) protocol and similar technologies can solve this problem by signing information at either end of the connection.
Impersonation. Information passes to a person who poses as the intended recipient.
Impersonation can take two forms, spoofing and misrepresentation.
Spoofing. A person or computer impersonates someone else. For example, a person can pretend to have the mail address jdoe@example.com, or a computer can identify itself as a site called www.example.com when it is not.
Misrepresentation. A person or organization misrepresents itself. For example, suppose the site www.example.com pretends to be a furniture store when it is really just a site that takes credit-card payments but never sends any goods.
Denial of service. An attacker uses the system resources to prevent these resources from being used by legitimate users.
In a denial of service attack, the attacker's goal is to prevent the directory from providing service to its clients. Directory Server Enterprise Edition provides a way of preventing denial of service attacks by setting limits on the resources that are allocated to a particular bind DN.
A security policy must be able to prevent sensitive information from being modified or retrieved by unauthorized users, but easy enough to administer.
Directory Server Enterprise Edition provides the following security methods:
Authentication. Provides a means for one party to verify another's identity. For example, a client gives a password to Directory Server during an LDAP bind operation. As part of the authentication process, password policies define the criteria that a password must satisfy to be considered valid, for example, age, length, and syntax. Account inactivation disables a user account, group of accounts, or an entire domain so that all authentication attempts are automatically rejected.
Encryption. Protects the privacy of information. When data is encrypted, the data is scrambled in a way that only the recipient can decode. The Secure Sockets Layer (SSL) maintains data integrity by encrypting information in transit. If encryption and message digests are applied to the information being sent, the recipient can determine that the information was not tampered with during transit. Attribute encryption maintains data integrity by encrypting stored information.
Access control. Tailors the access rights that are granted to different directory users, and provides a means of specifying required credentials or bind attributes.
Auditing. Enables you to determine if the security of your directory has been compromised. For example, you can audit the log files maintained by your directory.
These security tools can be used in combination in your security design. You can also use other features of the directory, such as replication and data distribution, to support your security design.
Directory Server Enterprise Edition supports the following authentication mechanisms:
The same authentication mechanism applies to all users, whether the users are people or LDAP-aware applications.
Apart from the authentication mechanisms described above, this section also includes the following information about authentication:
Anonymous access is the simplest form of directory access. Anonymous access makes data available to any directory user, regardless of whether the user has authenticated.
Anonymous access does not allow you to track who is performing searches or what kind searches are being performed, only that someone is performing searches. When you allow anonymous access, anyone who connects to your directory can access the data. If you allow anonymous access to data, and attempt to block a user or group from that data, the user can access the data by binding to the directory anonymously.
You can restrict the privileges of anonymous access. Usually, directory administrators allow anonymous access only for read, search, and compare privileges. You can also limit access to a subset of attributes that contain general information such as names, telephone numbers, and email addresses. Do not allow anonymous access to sensitive data, such as government identification numbers, home telephone numbers and addresses, and salary information.
Anonymous access to the root DSE (base DN "") is required. Access to the root DSE enables applications to discover the capabilities of the server, the supported security mechanisms, and the supported suffixes.
If anonymous access is not set up, a client must authenticate to Directory Server to access the directory contents. With simple password authentication, a client authenticates to the server by providing a simple, reusable password.
The client authenticates to Directory Server through a bind operation in which the client provides a distinguished name and credentials. The server locates the entry that corresponds to the client DN, then checks whether the client's password matches the value stored with the entry. If the password matches, the server authenticates the client. If the password does not match, the authentication operation fails and the client receives an error message.
Note:
The drawback of simple password authentication is that the password is transmitted in clear text, which can compromise security. If a rogue user is listening, that user can impersonate an authorized user.
Simple password authentication offers an easy way of authenticating users. However, you need to restrict the use of simple password authentication to your organization's intranet. This kind of authentication does not offer the level of security that is required for transmissions between business partners over an extranet or for transmissions with customers on the Internet.
A secure connection uses encryption to make data unreadable to third parties while the data is sent over the network between Directory Server and its clients. Clients can establish secure connections in either of the following ways:
Binding to the secure port by using the Secure Socket Layer (SSL)
Binding to an insecure port with anonymous access, then sending the Start TLS control to begin using Transport Layer Security (TLS)
In either case, the server must have a security certificate, and the client must be configured to trust this certificate. The server sends its certificate to the client to perform server authentication, using public-key cryptography. This results in the client knowing that it is connected to the intended server and that the server is not being tampered with.
Then, for privacy, the client and server encrypt all data transmitted through the connection. The client sends the bind DN and password on the encrypted connection to authenticate the user. All further operations are performed with the identity of the user. The operations might also be performed with a proxy identity if the bind DN has proxy rights to other user identities. In all cases, the results of operations are encrypted when these results are returned to the client.
When establishing encrypted connections over SSL or TLS, you can also configure the server to require client authentication. The client must send its credentials to the server to confirm the identity of the user. The user's certificate, not the DN, is used to determine the bind DN. Client authentication protects against user impersonation and is the most secure type of connection.
Certificate-based client authentication operates at the SSL, TLS layer only. To use a certificate-based authentication ID with LDAP, you must use SASL EXTERNAL authentication after establishing the SSL connection.
You can configure certificate-based client authentication by using the dsconf get-server-prop command. See dsconf for more information.
Client authentication during an SSL or TLS connection can also use the Simple Authentication and Security Layer (SASL), a generic security interface, to establish the identity of the client. Directory Server Enterprise Edition supports the following mechanisms through SASL:
DIGEST-MD5. This mechanism authenticates clients by comparing a hashed value sent by the client with a hash of the user's password. However, because the mechanism must read user passwords, all users wanting to be authenticated through DIGEST-MD5 must have {CLEAR} passwords in the directory.
GSSAPI. The General Security Services API (GSSAPI) is available only on the Solaris Operating System. It allows Directory Server to interact with the Kerberos V5 security system to identify a user. The client application must present its credentials to the Kerberos system, which in turn validates the user's identity to Directory Server.
EXTERNAL. This mechanism authenticates a user in LDAP based on the credentials specified by an external security layer, such as SSL or TLS.
For more information, see Using SASL DIGEST-MD5 in Clients in Administrator's Guide for Oracle Directory Server Enterprise Edition and Using Kerberos SASL GSSAPI in Clients in Administrator's Guide for Oracle Directory Server Enterprise Edition.
You can temporarily prevent authentication by inactivating a user account or a set of accounts. When the account is inactivated, the user cannot bind to Directory Server, and authentication operations fail. For more information, see Manually Locking Accounts in Administrator's Guide for Oracle Directory Server Enterprise Edition.
In this version of Directory Server, authentication failures with a password are monitored and replicated. This enables rapid, global account lockout after a specified number of authentication attempts with an invalid password. Global account lockout is supported in any of the following cases:
Client applications bind to a single server in the topology only
The topology does not include any read-only consumers
Directory Proxy Server is used to control all bind traffic
Imagine a situation where all bind attempts are not directed to the same server, and the client application performs bind attempts on multiple servers faster than lockout data can be replicated. In the worst-case scenario, the client would be allowed the specified number of attempts on each server where the client attempted to bind. This situation would be unlikely if the client application were driven by input from a human user. However, an automated client built to attack a topology could exploit this deployment choice.
Prioritized replication can be used to minimize the impact of asynchronous replication latency on intrusion detection. However, you might require account lockout immediately after the specified number of failed bind attempts. In this situation, you must use Directory Proxy Server to route all bind attempts on a particular entry to the same master replica. For information about how to configure Directory Proxy Server to do this, see Operational Affinity Algorithm for Global Account Lockout in Oracle Directory Server Enterprise Edition Reference.
To retain a strictly local lockout policy in a replicated topology, you must maintain compatibility with the 5.2 password policy. In this situation, the policy in effect must not be the default password policy. Local lockout can also be achieved by restricting binds to read-only consumers.
For detailed information about how global account lockout works, see Global Account Lockout in Oracle Directory Server Enterprise Edition Reference.
Directory Server provides user account host mapping, which associates a network user account with a Directory Server user account. This feature simplifies the management of both user accounts. Host mapping is required for users who are externally authenticated.
Proxy authorization is a special form of access control. Proxy authorization or proxy authentication is when an application is forced to use a specific username/password combination to gain access to the server.
With proxy authorization, an administrator can request access to Directory Server by assuming the identity of a regular user. The administrator binds to the directory with his own credentials and is granted the rights of the regular user. This assumed identity is called the proxy user. The DN of that user is called the proxy DN. The proxy user is evaluated as a regular user. Access is denied if the proxy user entry is locked or inactivated or if the password has expired.
An advantage of the proxy mechanism is that you can enable an LDAP application to use a single bind to service multiple users who are accessing Directory Server. Instead of each user having to bind and authenticate, the client application binds to Directory Server and uses proxy rights.
For more information, see Chapter 6, Directory Server Access Control, in Administrator's Guide for Oracle Directory Server Enterprise Edition.
A password policy is a set of rules that govern how passwords are administered in a system. Directory Server supports multiple password policies, as well as a default password policy.
Several elements of the password policy are configurable, enabling you to design a policy that suits the security requirements of your organization. Configuration of the password policy is described in Chapter 7, Directory Server Password Policy, in Administrator's Guide for Oracle Directory Server Enterprise Edition. The individual attributes available for configuring password policies are described in the pwpolicy man page.
This section is divided into the following topics:
Password policy options
Password policies in a replicated environment
Password policy migration
The following password policy options are provided:
A default password policy is applied. The parameters of this default policy can be changed.
An additional, specialized password policy can be applied to a particular user.
An additional, specialized password policy can be applied to a set of users by using the CoS and Roles functionality. Password policies cannot be applied to static groups.
Configuration information for the default password policy is not replicated. Instead, it is part of the server instance configuration. If you modify the default password policy, the same modifications must be made on each server in the topology. If you need a password policy that is replicated, you must define a specialized password policy under a part of the directory tree that is replicated.
All password information that is stored in the user entry is replicated. This information includes the current password, password history, password expiration dates and so forth.
Consider the following impact of password policies in a replicated environment:
A user with an impending password expiration receives a warning from every replica to which the user binds before changing his password.
When a user changes his password, the new password might take a while to be updated on all replicas. A situation could arise where a user changes his password and then immediately rebinds to one of the consumer replicas with the new password. In this case, the bind could fail until the replica receives the updated password. This situation can be alleviated using prioritized replication to force password changes to be replicated first.
The Directory Server Enterprise Edition password policy configuration settings differ from the password policy configuration settings provided with the 5.2 version of Directory Server. If your topology includes servers that run different versions of Directory Server, see Password Policy in Upgrade and Migration Guide for Oracle Directory Server Enterprise Edition for information about how to migrate password policy settings.
Identity Synchronization for Windows synchronizes user account information, including passwords, between Directory Server and Windows. Both Windows Active Directory and Windows NT are supported. Identity Synchronization for Windows helps build a scalable and security-enriched password synchronization solution for small, medium, and large enterprises.
This solution provides the following:
Synchronization of account creation, modification, inactivation, and deletion between Active Directory, Windows NT, and Directory Server
Integration with disparate and proprietary directory sources to synchronize native password changes
For more information about using Identity Synchronization for Windows in your deployment, see the Deployment Planning Guide for Identity Synchronization for Windows.
Encryption helps to protect data in transit, as well as stored data. This section describes the following methods of data encryption:
Security design involves more than an authentication scheme for identifying users and an access control scheme for protecting information. You must also protect the integrity of information between servers and client applications while it is being sent over the network.
To provide secure communications over the network, you can use both the LDAP and DSML protocols over the Secure Sockets Layer (SSL). When SSL is configured and activated, clients connect to a dedicated secure port where all communications are encrypted after the SSL connection is established. Directory Server and Directory Proxy Server also support the Start Transport Layer Security (Start TLS) control. Start TLS allows the client to initiate an encrypted connection over the standard LDAP port.
For an overview of SSL and TLS in Directory Server, see Chapter 5, Directory Server Security, in Oracle Directory Server Enterprise Edition Reference.
Attribute encryption concerns the protection of stored data. This section describes the attribute encryption functionality, and covers the following topics:
Directory Server Enterprise Edition provides various features to protect data at the access level, including password authentication, certificate-based authentication, SSL, and proxy authorization. However, the data stored in database files, backup files, and LDIF files must also be protected. The attribute encryption feature prevents users from accessing sensitive data while the data is stored.
Attribute encryption enables certain attributes to be stored in encrypted form. Attribute encryption is configured at the database level. Thus, after an attribute is encrypted, the attribute is encrypted in every entry in the database. Because attribute encryption occurs at the attribute level (not the entry level), the only way to encrypt an entire entry is to encrypt all of its attributes.
Attribute encryption also enables you to export data to another database in an encrypted format. The purpose of attribute encryption is to protect sensitive data only when the data is being stored or exported. Therefore, the encryption is always reversible. Encrypted attributes are decrypted when returned through search requests.
The following figure shows a user entry being added to the database, where attribute encryption has been configured to encrypt the salary attribute.
The attribute encryption feature supports a wide range of encryption algorithms. Portability across different platforms is ensured. As an additional security measure, attribute encryption uses the private key of the server's SSL certificate to generate its own key. This key is then used to perform the encryption and decryption operations. To be able to encrypt attributes, a server must be running over SSL. The SSL certificate and its private key are stored securely in the database and protected by a password. This key database password is required to authenticate to the server. The server assumes that whoever has access to this key database password is authorized to export decrypted data.
Note that attribute encryption only protects stored attributes. If you are replicating these attributes, replication must be configured over SSL to protect the attributes during transport.
If you use attribute encryption, you cannot use the binary copy feature to initialize one server from another server.
While attribute encryption offers increased data security, this feature does impact performance. Use attribute encryption only to encrypt particularly sensitive attributes.
Sensitive data can be accessed directly through index files. Thus, you must encrypt the index keys corresponding to the encrypted attributes, to ensure that the attributes are fully protected. Indexing already has a performance impact, without the added cost of encrypting index keys. Therefore, configure attribute encryption before data is imported or added to the database for the first time. This procedure ensures that encrypted attributes are indexed as such from the outset.
Access control enables you to specify that certain clients have access to particular information, while other clients do not. You implement access control using one or more access control lists (ACLs). ACLs consist of a series of access control instructions (ACIs) that either allow or deny permissions to specified entries and their attributes. Permissions include the ability to read, write, search, proxy, add, delete, compare, import and export.
By using an ACL, you can set permissions for the following:
The entire directory
A particular subtree of the directory
Specific entries in the directory
A specific set of entry attributes
Any entry that matches a given LDAP search filter
In addition, you can set permissions for a specific user, for all users that belong to a group, or for all users of the directory. You can also define access for a network location, such as an IP address or a DNS name.
This section provides an overview of the Directory Server access control mechanism. For detailed information about configuring access control and ACIs, see Chapter 6, Directory Server Access Control, in Administrator's Guide for Oracle Directory Server Enterprise Edition. For information about the architecture of the access control mechanism, see How Directory Server Provides Access Control in Oracle Directory Server Enterprise Edition Reference.
The default behavior of Directory Server is to deny access unless there is a specific ACI that grants access. therefore, if no ACIs are defined, all access to the server is denied.
When you install Directory Server or when you add a new suffix, several default ACIs are defined automatically in the root DSE. These ACIs can be modified to suit your security requirements.
For details on the default ACIs and how to modify them, see How Directory Server Provides Access Control in Oracle Directory Server Enterprise Edition Reference.
Starting with 6.x, Directory Server includes two major changes to ACI scope.
Ability to specify the scope of an ACI. In Directory Server 5.2, you could not specify the scope of an ACI. ACIs automatically applied to the entry that contained the ACI and all of its subtree. Therefore, it was necessary to use deny ACIs in several cases. Deny ACIs can be difficult to manage, particularly when a deny ACI and an allow ACI apply to a single entry.
Starting with Directory Server 6.x, you can specify the scope of an ACI, that is, you can use allow ACIs to control access. Although, deny-based access control might sometimes be unavoidable or simpler to configure, the use of deny ACIs is generally discouraged. For information about how to specify the scope of an ACI, see Chapter 6, Directory Server Access Control, in Administrator's Guide for Oracle Directory Server Enterprise Edition.
Root ACIs now apply to the root entry and its entire subtree. In Directory Server 5.2, ACIs located in the root DSE applied to the root entry only and not its children. ACIs placed in any other entry applied to the entry that contained the ACI and all of its subtree. In Directory Server Enterprise Edition ACIs placed in the root entry are treated like ACIs placed anywhere else.
The new root ACIs have an obvious security advantage. Administrators no longer have to bind as the Directory Manager to perform certain operations. Administrators can now be forced to bind by using strong authentication such as SSL. When configuring ACIs that are intended to apply only to the root entry, the scope of the ACI must now specifically be set to base.
The change in ACI scope has implications for migration. If you are migrating to Directory Server 7.0 from a 5.2 version of Directory Server, see Changes to ACIs in Upgrade and Migration Guide for Oracle Directory Server Enterprise Edition.
The access control model provided by Directory Server can grant access to users through many different mechanisms. However, this flexibility can make your security policy fairly complex. Several parameters can define the security context of a user, including IP address, machine name, time of day, and authentication method.
To simplify the security policy, Directory Server enables you to request and list the effective access rights that a given user has to specified directory entries and attributes. For more information, see Viewing Effective Rights in Administrator's Guide for Oracle Directory Server Enterprise Edition.
The following tips can simplify your directory security model and improve directory performance:
Minimize the number of ACIs in your directory, and use macro ACIs where possible.
Although Directory Server can evaluate over 50,000 ACIs, managing a large number of ACI statements can be difficult. Excessive ACIs can also have a negative impact on memory consumption.
Balance allow and deny permissions.
The default rule is to deny access to any user who has not been specifically granted access. However, you can reduce the number of ACIs by using one ACI that allows access close to the root of the tree and using a small number of deny ACIs close to the leaf entries. This approach can prevent excessive allow ACIs close to the leaf entries.
Identify the smallest set of attributes on any given ACI.
If you allow or deny access to a subset of attributes on an object, determine whether the smallest list is the set of attributes that are allowed or the set of attributes that are denied. Then express your ACI so that you are managing the smallest list.
For example, the people object class contains dozens of attributes. To allow a user to update just a few attributes, write your ACI so that it allows write access for just those few attributes. To allow a user to update all but one or two attributes, create the ACI so that it denies write access for those one or two attributes.
Use LDAP search filters cautiously.
Search filters do not directly name the object for which you are managing access. Search filters can therefore result in unexpected results especially as your directory becomes more complex. If you use search filters in ACIs, run an ldapsearch operation with the same filter. This action will ensure that you know what the results of the changes mean to your directory.
Do not duplicate ACIs in different parts of your directory tree.
Look for overlapping ACIs. Imagine that you have an ACI at your directory root point that allows a group write access to the commonName and givenName attributes. Imagine also that you have another ACI that allows the same group write access to just the commonName attribute. In this scenario, consider reworking your ACIs so that only one attribute grants write access for the group.
As your directory grows more complicated, accidental overlapping of ACIs becomes increasingly common. If you avoid ACI overlap, security management becomes easier and the total number of ACIs in your directory is reduced.
Name your ACIs.
While naming ACIs is optional, giving each ACI a short, meaningful name makes managing your security model easier.
Use standard attributes in user entries to determine access rights.
As far as possible, use information that is already part of standard user entries to define access rights. If you must create special attributes, consider creating the attributes as part of a role or Class of Service (CoS) definition. For more information about roles and CoS, see Chapter 11, Directory Server Groups and Roles, in Oracle Directory Server Enterprise Edition Reference and Chapter 12, Directory Server Class of Service, in Oracle Directory Server Enterprise Edition Reference.
Group ACIs as closely together as possible.
Limit ACI placement to your directory root point and to major directory branch points. If you organize ACIs into groups, the total list of ACIs is easier to manage and the total number of ACIs can be kept to a minimum.
Avoid using double negatives, such as deny write if the bind DN is not equal to cn=Joe.
Although this syntax is acceptable to the server, the syntax can be confusing for an administrator.
Connection rules enable you to prevent selected clients from establishing connections to Directory Server. The purpose of connection rules is to prevent a denial-of-service attack caused by malicious or poorly designed clients that connect to Directory Server and flood the server with requests.
Connection rules are established at the TCP level by defining TCP wrappers. For more information about TCP wrappers, see Client-Host Access Control Through TCP Wrapping in Administrator's Guide for Oracle Directory Server Enterprise Edition.
Directory Proxy Server connection handlers provide a method of access control that enables you to classify incoming client connections. In this way, you can restrict the operations that can be performed based on how the connection has been classified.
You can use this functionality, for example, to restrict access to clients that connect from a specified IP address only. The following figure shows how you can use Directory Proxy Server connection handlers to deny write operations from specific IP addresses.
Figure 7-2 Directory Proxy Server Connection Handler Logic
A connection handler consists of a list of criteria and a list of policies. Directory Proxy Server determines a connection's class membership by matching the origination attributes of the connection with the criteria of the class. When the connection has been matched to a class, Directory Proxy Server applies the policies that are contained in that class to the connection.
Connection handler criteria can include the following:
Client physical address
Domain name or host name
Client DN pattern
Authentication method
SSL
The following policies can be associated with a connection handler:
Administrative limits policy. Enables you to set certain limits on, for example, the number of open connections from clients of a specific class.
Content adaptation policy. Enables you to restrict the kind of operations a connection can perform, for example, attribute renaming.
Data distribution policy. Enables you to use a specific distribution scheme for a connection.
For more information about Directory Proxy Server connection handlers and how to set them up, see Chapter 20, Connections Between Clients and Directory Proxy Server, in Oracle Directory Server Enterprise Edition Reference.
Roles and CoS require special consideration with regard to security.
Not every role is suitable for use within a security context. When creating a role, consider how easily it can be assigned to and removed from an entry. Sometimes, users should be able to add themselves to or remove themselves from a role. However, in some security contexts such open roles are inappropriate. For more information, see Directory Server Roles in Oracle Directory Server Enterprise Edition Reference.
Access control for reading applies to both the real attributes and the virtual attributes of an entry. A virtual attribute generated by the Class of Service (CoS) mechanism is read like a normal attribute. Virtual attributes should therefore be given read protection in the same way. However, to make the CoS value secure, you must protect all of the sources of information the CoS value uses: the definition entries, the template entries, and the target entries. The same is true for update operations. Write access to each source of information must be controlled to protect the value that is generated from these sources. For more information, see Chapter 12, Directory Server Class of Service, in Oracle Directory Server Enterprise Edition Reference.
Firewall technology is typically used to filter or block network traffic to and from an internal network. If LDAP requests are coming from outside a perimeter firewall, you need to specify what ports and protocols are allowed to pass through the firewall.
The ports and protocols that you specify depend on your directory architecture. As a general rule, the firewall must be configured to allow TCP and UDP connections on ports 389 and 636.
Host-based firewalls can be installed on the same server that is running Directory Server. The rules for host-based firewalls are similar to the rules for perimeter defense firewalls.
You can create and run server instances as a non-root user. By running server instances as a non-root user, you limit any potential damage that an exploit could cause. Furthermore, servers running as non-root users are subject to access control mechanisms on the operating system.
For more information about designing a secure directory, see the following resources:
Sun Developer Security Resources http://developers.sun.com/techtopics/security/index.html (http://java.sun.com/javase/technologies/security/)
Understanding and Deploying LDAP Directory Services. T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999
SecurityFocus.com http://www.securityfocus.com/ (http://www.securityfocus.com/)
Computer Emergency Response Team (CERT) Coordination Center http://www.cert.org/ (http://www.cert.org/)
|
 Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
