Security Issues Concerning Document Management

06/01

IXOS SOFTWARE AG Technopark Bretonischer Ring 12 D-85630 Grasbrunn Tel. +49 (89) 4629-0 Fax +49 (89) 4629-1199 email: office@munich.ixos.de

Security Issues Concerning Document Management 06/01 2001 IXOS SOFTWARE AG

Bretonischer Ring 12 D-85630 Grasbrunn Tel. +49 (89) 4629-0 Fax +49 (89) 4629-1199 Email: <office@munich.ixos.de> All rights reserved, including those regarding reproduction, copying or other use or communication of the contents of this document or parts thereof. No part of this publication may be reproduced, transmitted to third parties, processed using electronic retrieval systems, copied, distributed or used for public demonstration in any form without the written consent of IXOS SOFTWARE AG. We reserve the right to update or modify the contents. Any and all information that appears within illustrations of screenshots is provided coincidentally to better demonstrate the functioning of the software. IXOS SOFTWARE AG hereby declares that this information reflects no statistics of nor has any validity for any existing company. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). Trademarks IXOS: IXOS SOFTWARE AG. SAP , R/3 and SAP ArchiveLink are registered trademarks of SAP AG. Acrobat Reader Copyright 1987 Adobe Systems Incorporated. All rights reserved. Adobe and Acrobat are trademarks of Adobe Systems Incorporated which may be registered in certain jurisdictions. Other product names are used only to identify the products and they may be registered trademarks of the relevant manufacturers.

Security issues concerning document management

Table of Contents

TABLE OF CONTENTS................................................................................................... 3 1 SECURITY ISSUES CONCERNING DOCUMENT MANAGEMENT.........................................4 1.1 General Security Concepts..................................................................................5 1.1.1 Encryption techniques......................................................................................5 1.1.1.1 The secret key or symmetric method.............................................................5 1.1.1.2 The public key or asymmetric method...........................................................6 1.1.1.3 Hybrid methods............................................................................................. 6 1.1.1.4 Key properties............................................................................................... 7 1.1.2 Hash values and message digests...................................................................8 1.1.3 Digital signatures.............................................................................................. 8 1.1.4 Certificates....................................................................................................... 9 1.1.5 Public Key Infrastructure (PKI).......................................................................11 1.2 Measures to avoid security breaches................................................................11 1.2.1 Access Control............................................................................................... 11 1.2.1.1 Authentication..............................................................................................11 1.2.1.2 Authorization ..............................................................................................12 1.2.1.3 Authorization via Signed URLs (SecKeys)..................................................12 1.2.2 Intrusion protection......................................................................................... 13 1.2.2.1 Firewalls...................................................................................................... 13 1.2.2.2 Encrypted documents..................................................................................13 1.2.3 Secure Transmission (SSL/TLS)....................................................................13 1.2.4 Data integrity.................................................................................................. 14 1.2.4.1 Digital signatures......................................................................................... 15 1.2.4.2 Checksums.................................................................................................. 15 1.2.4.3 Time stamps................................................................................................15 1.2.4.4 Digital signature via the client interface.......................................................15 1.2.5 Availability (Protection against Denial-of-Service attacks)..............................16 1.3 Summary of security solutions in IXOS products...............................................16

06/01

Security Issues Concerning Document Management:

Security issues concerning document management

When working with documents, important security standards should be met in order to protect the confidentiality of private data, as well as to ensure its integrity and availability. This paper describes the basic security issues and discusses the approaches IXOS takes in its various products to meet security standards. It is meant as an overview only; the details of implementation can be found in the specific product handbooks. The main security topics for document management concern:

Access control Users may only perform those actions for which they have permission. This topic comprises the following issues:

Authentication: how can the user prove they are who they say they are? Authorization: how are the access rights structured which define who is permitted to perform which actions?

Intrusion protection By which means can you avoid users gaining access to data without permission? How can you ensure the data's confidentiality and integrity while it is being transported through the network?

Data integrity How can you guarantee that archived data has not been modified since a specific time? How can you prove that a certain document was created or signed by a specific person? Protection against denial-of-service attacks How can you avoid attacks that impair the availability of the system, for instance by flooding the server with trash requests?

Before we confront these issues, we will begin with an overview of the general concepts and principal encryption techniques which play a major role in making systems secure.

06/01

Security issues concerning document management

1.1
1.1.1

General Security Concepts

Encryption techniques
There are two basic encryption techniques known as:

Secret key or symmetric method Public key or asymmetric method

1.1.1.1

The secret key or symmetric method With this method, all communication partners use the same secret key both for encrypting and decrypting the information to be transmitted (thus symmetric method).

This is a simple and reasonably fast method which relies on the secrecy of the keys alone, i.e. if the attacker succeeds in obtaining the key from one partner, they are capable of decrypting any data transmitted between these communication partners. Thus the main problem is distributing the secret key between the partners. This method is very widespread and commonly used to encrypt data to ensure its confidentiality, regardless of whether the data is then transmitted through a network or simply stored locally. In the latter case, the distribution of the secret key is no problem; in the former case, hybrid encryption methods (see page 6), for instance, can be used to exchange the key. The most widely spread symmetric encryption algorithms are DES, 3DES and IDEA, which each support a different key length. DES, using 56-bit keys, is no longer considered secure, whereas 3DES and IDEA support 112 and 128-bit keys, respectively (see also Key properties on page 7). Furthermore, AES is becoming very common; AES supports various different key lengths. As all communication partners use the same key, authentication is only possible for the group, not however for an individual member of the group. Each individual can prove that they belong to this group by showing their key. However, possession of the key does not prove the identity of an individual member of the group.

06/01

Security Issues Concerning Document Management:

1.1.1.2

The public key or asymmetric method In this case, each communication partner owns both a public key and a private key. The public key is openly distributed to anyone who would like to communicate with this user and can be obtained from some kind of "public telephone book" for public keys. The private key is known only by the user themselves. When user A wants to transmit data to user B, it is encrypted with the help of user B's public key. This encrypted information can now only be decrypted with the help of user B's private key, which only user B knows. Thus, only user B can read the secret information sent to him by user A.

This method relies on so-called one-way functions which can be calculated easily in one direction, whose inverse functions however cannot be calculated with reasonable effort. Note that the problem is not finding the algorithm, but rather calculating it. A slight modification of these functions are so-called trap-door one-way functions whose inverse functions can be calculated with the help of some additional information - the private key. This private key must be kept secret and must not be easily computable with the help of the public key. This is a very secure method, as long as no-one is able to gain knowledge of the private key. This is an essential factor for the security of the data! Another advantage of asymmetric encryption is that no private keys need to be transmitted between communication partners, however it requires more processing time and administration. For each communication partner a pair of keys is needed, which must be created and distributed by a trusted source and maintained within the system (see Public Key Infrastructure (PKI) on page 11). Smart cards are a practical way of storing and distributing private keys without transmission over a possibly insecure system. However, this requires additional hardware on the clientside to read the smart cards. A widely used standard for the public key method is the RSA algorithm, which is the method described above. 1.1.1.3 Hybrid methods Often hybrid methods are used in order to profit from the advantages of both types of encryption and avoid the disadvantages. For instance, you can create a secret key for fast symmetric encryption during the following communication session, and transmit it with the help of a secure asymmetric method.

06/01

Security issues concerning document management

Therefore, the secret key is created by the sender, then encrypted with the recipient's public key, to ensure that only the recipient will be able to decrypt the information sent between the two communication partners. The encrypted key is then sent to the recipient along with the initial communication request. Now the recipient can decrypt the secret key with their private key and can use the secret key to encrypt information during the following communication. Such a hybrid method enables secure and fast encryption. Encryption:

Decryption:

1.1.1.4

Key properties All algorithms that are used to create encryption keys are based on random numbers. Depending on the algorithm, the actual numbers can be more or less random, i.e. if you know the algorithm and for instance the time, date, system ID or other factors often integrated in such operations, you can easily decrease the range of possible numbers that may result from it. In the end, the more bits a key can consist of, the larger the range of possible keys if an optimal random number function is used. Since the security of the (especially private key) encryption methods relies on the complexity of the algorithms needed to calculate the keys from a given document (see The public key or asymmetric method on page 6), security increases with the number of possible keys. So if the key is very short, it is easy to systematically try out every combination possible until a given encrypted document can be decrypted. On the other hand, if the key is long enough, even the most powerful computers existing today cannot handle the calculation in a realistic time span. This does not mean that in the future improved computers still will not be capable to do so. Until February 2000, the only symmetric keys available in commercial US Web browsers and Web server applications outside the US were 56-bit keys (private keys up to 512 bits). However, meanwhile, it is possible to crack 56-bit keys, so that it is no longer recommended

06/01

Security Issues Concerning Document Management:

to use such keys. Nowadays, 128-bit symmetric keys are supported by standard Web software, and up to 1024-bit asymmetric keys. Note: IXOS products have always supported 128-bit symmetric keys.

1.1.2

Hash values and message digests

A Hash value is the result of a one-way Hash function, which defines a string with a specific length from an input string of any length. Important: As it is a one-way function, you cannot draw any conclusions about the original data from the hash value. If you use a special Hash function that prevents output collision (it is highly unlikely for 2 different values to generate the same output), this is called a message digest function, and the result is the message digest. This digest can be compared with a kind of fingerprint for the data - if you use the same function on exactly the same data, you will always get exactly the same result. However, if the input data is slightly changed, the result will always be different.

1.1.3

Digital signatures
Ideally, digital signatures are expected to be the electronic equivalent of a handwritten signature under a document - they should verify the unique identity of the person signing and in addition the integrity of the data since the time of signing. However, as you cannot personally see the person signing or the document being signed, the comparison is somewhat questionable. In Europe, the officially recognized method of creating digital signatures on electronic documents is based on the public key method as described above, together with the message digest. If user A wants to sign a document, he must determine the message digest of the data to be sent, and encrypt the value with his private key. The signed digest is what we call the digital signature - it uniquely defines the document and the person who signed it. Now user A can send the signed document, i.e. the original document together with the encrypted digest (the digital signature) to user B. To ensure that the transmitted document was indeed signed by user A, user B checks the digital signature with user A's public key. Then user B must determine the message digest of the transmitted document. If the transmitted digest is identical to the one determined by user B, it is ensured that:

the original document sent by user A must be identical to the one that user B received, and only user A could have signed the document, as only user A has knowledge of the key used for encryption of the digest.

Note: Generally, verification with this method is only as trustworthy as the person or authority signing, and relies strongly on the confidentiality of the keys.

06/01

Security issues concerning document management

Signature:

Verification:

The advantage of authentication via digital signatures (i.e. with the help of the public key method) is that each user can prove their identity without revealing secret information (their private key). Digital signatures are gaining more and more significance in the legal world: the EU has defined legislation making digital signatures abiding special standards acceptable as legal evidence (Directive 1999/93/EC of 13 December 1999 on a Community Framework for electronic signatures).

1.1.4

Certificates
As mentioned above, digital signatures and, in general, all public key methods rely on the authenticity and confidentiality of the users' public keys. Otherwise, an attacker could send their own public key under the pretense of being user A. If the recipient, user B, cannot determine this fraud and uses this public key to encrypt messages to user A during future communication, the attacker can decrypt any messages user B is supposedly sending user A.

06/01

10

Security Issues Concerning Document Management:

This means that there must be a trustworthy organization that can verify the authenticity of public keys for any user requesting this information. This is implemented using digital certificates, distributed by a Certification Authority (CA) or Trust Center. Digital certificates verify your identity and your associated public key, similarly to the way a driver's license certifies your identity and your signature. Important: Again, the trustworthiness of certificates relies strongly on the trustworthiness of the CA. This initiates a trust-chain, at the end of which a recognized, inherently trustworthy authority must stand in order to obtain security with this method. In order to receive such a digital certificate, you must send your personal data and your public key (if the key pair is not also created by the Certification Authority) to the CA. There your data is verified with various strictly controlled means. If the information is qualified to be trustworthy, a digital file is produced that includes your personal information and your public key in clear text. It is then digitally signed (see Digital signatures on page 8) with the trust center's private key, so that anyone who desires to do so can verify that the document was truly produced and signed by the trust center. This document, together with the digital signature from the CA, is the digital certificate. Most Web browsers and some operating systems (e.g. MS WindowsNT and MS Windows 2000) include the public keys of the most common Certification Authorities at installation, so that certificates from these trust centers can be verified without further exchange of public keys. Now you can send your digital certificate to any communication partner who wishes to verify your identity and requires your public key, and your partners can trust the authenticity of the information by verifying the certificate with their Web browser. Obtaining a digital certificate

The advantage of digital certificates is that anyone can verify your identity without your having to reveal or transmit secret information (the private key) to a third party.

06/01

Security issues concerning document management

11

1.1.5

Public Key Infrastructure (PKI)

A public key infrastructure is a central storage and administration service for public keys or more generally, digital certificates. When you want to employ public key methods for authentication or verification within a network system, there should be a specified authority for the following tasks:

creating keys and issuing certificates (rules for) distributing keys and certificates storing certificates, including the history (see note below) revoking certificates in the case of loss or disclosure of private keys and storing them in the Certificate Revocation List (CRL) answering requests for users' certificates, e.g. to verify a digital signature

Note: Storing the history of all certificates is important, especially in the archiving scenario; otherwise any documents that are signed and stored in an archive can no longer be verified after a new set of keys has been issued to one of the communication partners. In the case of server encrypted documents, the server keys must also be stored in order to enable decryption of the documents in the future. The specified authority is integrated in the public key infrastructure. PKIs can be very complex and are not yet commonly employed.

1.2
1.2.1

Measures to avoid security breaches

Access Control
Access control comprises the issues of which users are permitted to use the system (authentication) and which actions they are allowed to perform when doing so (authorization).

1.2.1.1

Authentication As a first step to secure access, the system must identify and verify the user who requests access. There are several possibilities to perform this verification: Authentication with the help of biometric characteristics (e.g. fingerprints etc.) Although much research is being undertaken in the field of biometric characteristics, these methods are not yet widely practiced and still very costly, and are not in use in IXOS products as yet. Authentication via digital certificates Digital certificates are a secure means of verification, however, this method does demand a certain overhead on the client side for certification, as well as a Public Key Infrastructure (see Section 1.1.1.2 on page 6), which is why it is not used in IXOS products. Authentication via a password The most widely spread method is authentication via a password. Every user who is permitted to access the system is identified by a user ID and verified by a password, which is stored by the access control system. When you want to access the system, you must transmit your user ID and password (if possible encrypted), which are then compared with the stored entries in the access control system. If a corresponding entry is found, you are given access.

06/01

12

Security Issues Concerning Document Management:

Obvious weaknesses of this method are the fact that the secret password must be transmitted through the system, and that it is often easy to obtain knowledge of a user's password. Many users choose obvious names or terms which can easily be guessed by an attacker (e.g. in the course of a so-called dictionary attack, where all entries of a dictionary are systematically tried out) or even simply be found if the password was written down. Nevertheless, this is a quick and easy method for authentication that requires no clientside infrastructure and is thus used for access control to all IXOS application clients. Note: Passwords are always encrypted for transmission in IXOS products. 1.2.1.2 Authorization Once a user has accessed the system, the system must clearly define which actions this user is authorized to perform; most users will not have permission to work with all documents, some tasks are restricted to administrators etc. A common method of administering access rights and permissions is the use of Access Control Lists (ACL). Each object for which access must be controlled owns such a list which includes negative (not allowed) or positive (allowed) permissions for various users or user groups. However, with these lists it is difficult to retrieve information on the permissions granted to a single user, which might be necessary for instance if a user should be removed from all lists. An alternative method is to define profiles with certain rights for various tasks (e.g. modify a document, view a document, delete a document etc.) and then to assign these profiles to the individual users or user groups. That way it is easy to add a new user with tasks similar to those of an existing user - you simply have to assign the same profile to both users. However, in this case you cannot easily identify which users have access to a specific object, for instance who has the right to modify the user profiles. This method is commonly used in R/3 related applications. Both of the described methods can be found in IXOS products. 1.2.1.3 Authorization via Signed URLs (SecKeys) Another very effective mechanism in identifying unknown and unauthorized requests is using access with signed URLs. In this case, the archive server for instance accepts only those requests that were signed by a trusted source (e.g. a special application server). The signature from this trusted source guarantees that the request was initiated by an authorized user. When a client sends a request to the application server, the trusted source checks the access rights and if they exist, signs the URL and sends it to the client. The client can then access the archive server with this URL. The signed URL contains an expiry time, after which it is no longer valid, for instance 2 hours. Technically, this means that the special application server receives a certificate and a private key during installation. The certificate is sent to the archive server, whose administrator must activate the certificate. Then the application server can sign the requests to the archive server with its private key, which the archive server can decrypt with the public key from the certificate. Thus the request was verified and authorized. This imposes additional overhead on the application server, which must administer the private key and certificate and must send the certificate to the archive server. In R/3 applications, the URL signature is called a SecKey, and is issued by the R/3 application server. IXOS-eCONserver (formerly IXOS-ARCHIVE) versions as of 4.1 support this method and can be configured so that unsigned requests are rejected, i.e. only requests from the explicitly authorized R/3 application server are accepted. Thus, even if an attacker obtains a document ID, unauthorized access to the document will be denied.

06/01

Security issues concerning document management

13

Note: SecKeys are momentarily the only means of authorization available between the R/3 application server and the archive server.

1.2.2

Intrusion protection
Although officially access might be restricted by an active access control system, there might be other, hidden, ways to enter the system. Principally, the entire internal system of an enterprise should be physically protected from tampering, e.g. by placing the equipment in locked rooms etc. An additional server acting as a so-called firewall offers extra protection between the internal system and any external gateways. These architectural and physical measures are basic security efforts and are considered prerequisites for systems implementing IXOS products. Additionally, there is a means of protecting the confidentiality and integrity of data despite a potential intrusion on the system: encrypted documents. Finally, precautions should be taken in order to ensure that only authorized transactions are taking place in the system. This means authentication between clients and servers, so that no illegal requests from clients outside the system are answered by the server, for instance (see Authorization via Signed URLs (SecKeys) on page 12).

1.2.2.1

Firewalls A first step in keeping out unwanted intruders is integrating the application server into standard firewalls. If you insert a Web server between the application server and the client, for instance, while using the standard HTTP protocol, you can define a firewall that blocks unwanted requests coming from familiar unauthorized Internet addresses before they reach the application server.

1.2.2.2

Encrypted documents In the archiving scenario there is another possibility to protect documents against unauthorized access bypassing the archiving software: encrypted storage. The encryption is performed by the archive server. As the archive server is responsible for encrypting and decrypting the documents, the archive server also has knowledge of the key (which should be symmetric for performance reasons). This makes sense when the archive server provider is considered to be a trusted source, but an attacker might somehow get hold of the storage media. Encrypted storage via the archive server is not yet implemented for IXOS products, but is planned for the near future.

1.2.3

Secure Transmission (SSL/TLS)

Secure transmission comprises protection of the confidentiality and integrity of data which is transmitted through networks (e.g. the Internet) on the way from the server to the client and vice versa. For this reason, a standard has been established in the Internet: Secure Socket Layer (SSL). Note: The standardized and slightly modified version of SSL is referred to as Transport Layer Security (TLS). These two methods are interchangeable, but not interoperable, i.e. it doesn't matter which method you implement, but all communication partners must use the same one. SSL/TLS is a new software layer that is inserted between the transport (e.g. TCP) and the session (e.g. HTTP) layers:

06/01

14

Security Issues Concerning Document Management:

SSL/TLS encrypts all data that is transported via a TCP/IP connection. When an SSL/TLS connection is established, the client and server authenticate each other with digital certificates, then exchange a secret key for their further communication, using a private key method. The general procedure is as follows: 1. 2. 3. 4. The client and server exchange the current session parameters. The server sends its certificate to the client for verification. Optionally, client authentication may also be performed. The key for the current session only is exchanged between the client and server. Client and server agree on all session parameters and the session key and now encrypt all transmitted data with the secret key - the session is now SSL/TSL-secured.

The SSL/TLS protocol permits secure transmission with the following characteristics:

The communication partners can be authenticated with the help of asymmetrical encryption methods (digital certificates), ensuring the confidentiality of the connection. The connection is trustworthy in terms of data confidentiality and integrity during transmission: after the initial connection has been established and a secret key has been defined and exchanged, all data is encrypted symmetrically, i.e. faster, during transmission. The connection is reliable: the data transport includes an integrity check with secure hash methods (see Section 1.1.2 on page 8).

However, the SSL/TLS protocol creates additional load on the client and server. IXOS-eCONserver supports the use of SSL/TLS. Each logical archive can be individually configured to either use or not use SSL/TLS, or allow both the usage and the non-usage. SSL/TLS requires the use of a key pair consisting of a public and a private key. IXOSeCONserver includes a test key pair, which enables encrypted data transmission. Systems requiring high security should, however, either generate their own key pair or request one from a trust center such as VeriSign or Thawte. The private key is unique and known only to the requester. The IXOS-eCONserver uses SSL/TLS to authenticate itself to the IXOS-eCONcert and IXOS-eCONtext clients. This allows the clients to immediately detect any attempt to redirect a request to another server and answer it with a counterfeit document. Therefore, SSL/TLS requires a key certificate with the Internet address of the application server, signed by a trust center.

1.2.4

Data integrity
Another substantial security aspect when managing documents is to protect the integrity of the stored data. Once the document data has been placed in an electronic archiving system, it is important to control any changes to this data, no matter whether the changes were undertaken by the system itself or by (possibly unauthorized) users.

06/01

Security issues concerning document management

15

1.2.4.1

Digital signatures Digital signatures can be used to authenticate the source of document data (see Section 1.1.3 on page 8), as well as to verify the integrity of the data contained within the document, i.e. that the contents of the current document correspond with the contents of the document when it was signed. This is done with the help of the so-called Hash value or message digest of the document (see Section 1.1.2 on page 8). Thus, in order to prove the integrity of the data, the message digest of the data is calculated and then signed with the private key of the sender or a trusted source (digital signature). At a later time, for instance after transmitting the data to another system, the digital signature is verified with the public key of the sender/trusted source. When the application server has to verify signatures, it requires the additional administration of certificates. IXOS-eCONserver supports the use of digital signatures together with time-stamps and message digests within the archive server.

1.2.4.2

Checksums Checksums are also calculated with hash functions, similarly to message digests, but are not digitally signed. They are used in order to test the integrity of data during transport, for instance to check whether data was written to a CD or WORM correctly. However, checksums can be manipulated more easily than message digests and are thus only useful to ensure the (physically) correct transmission of the data, but not to recognize unauthorized modifications. Since checksums are not signed, they also cannot be used to verify the identity of the person who calculated the checksum.

1.2.4.3

Time stamps Despite the use of digital signatures and the message digest, it is still possible for users to manipulate the transmission of the signed data (for instance by sending the same data again, which can cause major problems in a bank scenario), or to simply exchange the entire document and replace it with another one in an archive. Both of these problems cannot be solved with digital signatures alone. In this case, the use of time-stamps can help. A unique time-stamp is added by a precise and trusted time source at the time of storage and is included in the digital signature. Then at a later time, you can identify documents sent at the exact same time or sent at a later time than expected (for instance when documents are automatically stored at regular intervals). IXOS-eCONserver (formerly IXOS-ARCHIVE) offers the use of time stamps when storing documents as of version 4.0. The time stamp server can be implemented as either a software or a tamper-proof hardware solution. The digital signature and time stamps can be verified with the IXOS viewers.

1.2.4.4

Digital signature via the client interface In some cases, it might be desirable for users to sign their documents via the client interface. Contracts and other legally binding documents, for instance, must be digitally signed by both partners. XML documents represent another special situation. XML documents do not contain display information, so that the information that one user sees on the display and would like to sign might not be exactly the same as the information the communication partner sees. So what exactly are the partners signing? This problem could be solved by extracting the relevant information from the XML document into an ASCII document, which is displayed identically for both users, and which can then be signed. Again, it is necessary to enable the users to sign their documents via the client interface. In order to standardize XML-signatures, a joint working group of the IETF and W3C (XMLSignature WG) is currently developing an XML compliant syntax used for representing the

06/01

16

Security Issues Concerning Document Management:

signature of Web resources and portions of protocol messages (anything that can be referenced by a URI), as well as procedures for computing and verifying such signatures. The possibility to add digital signatures via the client interface is not yet implemented in IXOS products but is being considered for future versions. However, already signed documents can be archived in any case.

1.2.5

Availability (Protection against Denial-of-Service attacks)

Denial-of-service attacks occur when an attacker tries to flood the system with trash requests so that the processing of regular requests is disturbed. Such attacks cannot be avoided entirely. The main problem is that it is not easily possible for the application server to distinguish between "good" or "bad" requests, especially if the attacker is flooding the system with legal, but useless requests. The application server can however protocol the IP addresses of incoming requests, acting as an alarm system in case of abnormal behavior, which can then be tracked by the administrator. The best measure to ensure availability at least within the enterprise is to include an additional Web or proxy server in your network architecture. Thus, the application servers are no longer accessible directly from the Internet, and potential floods of trash requests are blocked by the proxy server, while the application server is still available for requests coming from the intranet. In the case of an archive server, using the cache server also as a proxy server has the additional advantage that frequent requests for the same document are automatically blocked off from the archive server as well. As generally commercial Web sites are not attacked by blocking a specific application or its server, but rather by flooding the whole network access, IXOS products do not contain specific measures for protecting the system against denial of service attacks. All IXOS products with Web access do however support proxy server architectures.

1.3

Summary of security solutions in IXOS products

IXOS products implement the following measures to ensure high security standards for your documents:

Encrypted passwords for authentication of the user Access control lists and user profiles for the administration of access rights and permissions Signed URLs/ SecKeys to verify authorized requests to the archive server. SSL/TLS protocol for individual logical archives and client/server applications, allowing secure data transmission. Encrypted storage of documents in the archive server; server-side encryption is planned for the near future. Digital signatures, message digests and time-stamps to ensure data integrity. Archiving digitally signed e-mails and verification of these signatures after restoring are supported. Digital signatures via the client interface are being considered for future products. The use of additional Web servers and firewalls is recommended by IXOS to avoid denial-of-service attacks.

Note: Documents encrypted by the users themselves should not be archived permanently, as such documents can no longer be read (and are thus useless) if the user loses their key. Consequently, IXOS does not plan to support archiving for user-encrypted documents.

06/01

Security issues concerning document management

17

Overview of security measures implemented in IXOS products

06/01