|
| |
| Sun Java System Calendar Server 6 2004Q2 Deployment Planning Guide | |
Chapter 6
Designing a Secure Calendar ServerThis chapter provides an overview of security methods, describes common security threats, and outlines the steps in analyzing your security needs.
This chapter contains the following sections:
Creating a Security StrategyCreating a security strategy is one of the most important steps in planning your deployment. Your strategy should meet your organization’s security needs and provide a secure calendar environment without being overbearing to your users.
In addition, your security strategy needs to be simple enough to administer. A complex security strategy can lead to mistakes that prevent users from accessing their mail, or it can allow users and unauthorized intruders to modify or retrieve information that you don’t want them to access.
RFC 2196, the Site Security Handbook, lists five steps to developing a security strategy:
- Identify what you are trying to protect.
For example, your list might include hardware, software, data, people, documentation, network infrastructure, or your organization’s reputation.
- Determine what you are trying to protect it from.
For example: unauthorized access to calendars, events or tasks.
- Estimate how likely threats are to your system.
If you are a large Service Provider, your chances of security threats could be greater than a small organization. In addition, the nature of your organization could provoke security threats.
- Implement measures that will protect your assets in a cost-effective manner.
For example, the extra overhead in setting up an SSL connection can put a performance burden on your Calendar deployment. In designing your security strategy, you need to balance security needs against server capacity.
- Continuously review your strategy and make improvements each time a weakness is found.
Conduct regular audits to verify the efficiency of your overall security policy. You can do this by examining Calendar Server log files. For more information, refer to the Sun Java System Calendar Server Administration Guide.
Your security strategy should also plan for:
Physical Security
Limit physical access to important parts of your infrastructure. For example, place physical limits on routers, servers, wiring closets, server rooms, or data centers to prevent theft, tampering, or other misuse. Network and server security become a moot point if any unauthorized person can walk into your server room an unplug your routers.
Server Security
Consider using security products (for example Solaris™ Security Toolkit) to harden the operating system. Also, remove services and facilities that you do not use (for example, telnet, ftp, and rlogin access to a server).
In a multi-tiered environment, configure back-end servers such that they will only provide the appropriate services to known front-end servers.
Limiting access to important operating system accounts and data is also part of any security strategy. Protection is achieved through the authentication and access control mechanisms available in the operating system.
In addition, you should install the most recent operating environment security patches and set up procedures to update the patches once every few months and in response to security alerts from the vendor.
Network Security
Limiting access to your network is an important part of your security strategy. Normally, overall access to networks is limited through the use of firewalls. However, email must be made available outside your site. SMTP is one such service.
To secure your network, you should:
- Turn off all operating system-provided services that listen on ports that you do not use.
- Replace telnet with sshd, if possible.
- Place your server behind a packet filter, which drops external packets with an internal source IP address. A packet filter forbids all connections from the outside except for those ports that you explicitly specify.
Calendar Security OverviewSecurity plays a key role in the day-to-day operations of today’s enterprise. Breaches in security can not only compromise trade secrets, but can also result in downtime, data corruption, and increased operation costs. Calendar Server provides a number of security levels to protect users against eavesdropping, unsanctioned usage, or external attack. The basic level of security is through authentication. Calendar Server uses LDAP authentication by default, but also supports the use of an authentication plugin for cases where an alternate means of authentication is desired. Furthermore, integration with Identity Server enables Calendar Server to take advantage of its single sign-on capability.
Security involves not only ensuring the integrity of users. It also means ensuring the confidentiality of data. To this end, Calendar Server supports the use of SSL encryption for login, or both login and data. In other words, only the login may be encrypted, or the entire session including the login may be encrypted, from the Web client to the server.
Integration with the Java System Portal Server, Secure Remote Access product also provides SSL encryption, but through a proxy gateway. In addition, integration with the portal gateway provides a URL rewriting capability to further insulate Calendar Server from external entities. Calendar Server can be deployed with the portal gateway such that there is no direct connection to the Calendar Server without going through the gateway. In this case, every URL is rewritten, thus obfuscating the true URL of the Calendar Server. Even though a user is authenticated, that does not mean that the user should have access to other calendar users’ data.
Within a calendar domain exist other layers of security to prevent authenticated users from unauthorized access to other authenticated users’ calendar data. One security measure is through the Calendar Server access control entries. Access control enables calendar users to specify who can see their calendars, who can schedule events into their calendars, who can modify their calendars, and who can delete events from their calendars. Access control also enables a user to select who can act on his behalf to respond to invitations, schedule or modify events, and delete events. Finally, access control can be used to span domains of users, thus preventing (or enabling) users in one domain from scheduling events with users of another domain.
However, in addition to access control, Calendar Server provides an additional level of security at the database protocol level for deployments that separate the calendar front end from the database back end. This level of security is referred to as Database Wire Protocol (DWP) authentication, and utilizes a user name/password pair to authenticate a DWP connection. The userid/password paris on both the front end and database back end must be identical for a DWP connection to be authenticated.
Monitoring Your Security Strategy
Monitoring your server is an important part of your security strategy. To identify attacks on your system, monitor message queue size, CPU utilization, disk availability, and network utilization. Unusual growth in the message queue size or reduced server response time can identify some of these attacks. Also, investigate unusual system load patterns and unusual connections. Review logs on a daily basis for any unusual activity.
Planning User AuthenticationUser authentication enables your users to log in through their calendar clients to retrieve their calendar information. Methods for user authentication include:
Plain Text and Encrypted Password Login
User IDs and passwords are stored in your LDAP directory. Password security criteria, such as minimum length, are determined by directory policy requirements. Password security criteria is not part of Calendar Server administration. To understand directory server password policies, see the Sun Java System Directory Server Deployment Planning Guide:
Both plain text and encrypted password login can be used.
Certificate-based Authentication with Secure Sockets Layer (SSL)
Calendar Server uses the SSL protocol for encrypted communications and for certificate-based authentication of clients and servers. This section describes certificate-based SSL authentication.
SSL is based on the concepts of public-key cryptography. Although TLS (Transport Layer Security) is functionally a superset of SSL, the names are used interchangeably.
At a high-level, a server which supports SSL needs to have a certificate, a public key, a private key, certificate, key, and security databases. This helps assure message authentication, privacy, and integrity.
To authenticate with SSL, the calendar client establishes an SSL session with the server and submits the user’s certificate to the server. The server then evaluates if the submitted certificate is genuine. If the certificate is validated, the user is considered authenticated.
If you use SSL for authentication, you need to obtain a server certificate for your Calendar Server. The certificate identifies your server to clients and to other servers. Your server can have more than one server certificate with which it identifies itself. Your server can also have any number of certificates of trusted Certification Authorities (CAs) that it uses for client authentication.
For more information on SSL, see the Sun Java System Calendar Server Administration Guide:
http://docs.sun.com/doc/817-5697
Understanding Security MisconceptionsThis section describes common messaging misconceptions that are counterproductive to the security needs of your deployment.
At best, hiding product names and versions hinders casual attackers. At worst, it gives a false sense of security that might cause your administrators to become less diligent about tracking real security problems.
In fact, removing product information and version numbers makes it more difficult for the vendor support organization to validate software problems as being that of their software or that of other software.
A determined individual can use other protocol behaviors to determine the vendor name and version regardless of any attempt to hide it.
Other Security ResourcesFor more information on designing a secure Messaging deployment, review the Computer Emergency Response Team (CERT) Coordination Center site: