Computer and network security is a growing concern for many companies. As the amount of data transmitted over networks increases, the need for secure connections increases. No doubt about it, security will be a way of life for system administrators. In
the near future, understanding basic security concepts will be a fundamental requirement for system administrators. As companies make the transition to more secure systems, some problems will arise. The military-level security integrated into Notes will
be, for many companies, the feature that is least understood and causes the most problems. Before going any further, a basic introduction to network security and Notes is in order. This chapter introduces you to
Because Notes security techniques are new to most administrators, this chapter covers only the basic conceptswithout discussing specific tasks required to administer Notes security. Chapter 4, "Advanced Security Issues," covers issues
that are important only to specific companies. Chapter 18, "Administering Notes Security," details each of the tasks involved in maintaining a secure Notes network.
Authentication is the process of identifying users. Every time a user attempts to access a server, his or her identity is verified. Access control involves limiting what users can do once they have identified themselves. Authentication and
access control are two fundamental concepts you must understand before you can administer Notes security effectively.
Authentication is the cornerstone of every security system. A weak authentication scheme cannot be overcompensated by a fancy access control system. If someone can fake an identity, it doesn't help to limit access based on identities. Passwords and ID
badges are two common examples of authentication techniques. Although authentication technology can be very complex, all systems fall into one of three categories. In increasing order of security, they are
Most systems to date have relied on "something you know," such as passwords. There are many problems with this approach; it's just too easy to guess at things that people must remember.
Systems using passwords were built that way because there were few options. In the past, systems that relied on "something you have" were impractical, inconvenient, and expensive. But recent advances in encryption technology have made it
practical to build systems that rely on something you have. Notes was one of the first major software products to integrate this level of security directly into the product. Notes uses names, encryption keys, and certificates to authenticate users. Each of
these items is discussed in detail in this chapter.
Access control lists (ACLs) are the most common way of limiting access to computer system resources. Nearly every computer system built over the last two decades has used ACLs in one form or another. Access control lists are simply a list
of names. Each name is associated with a set of permissions, which give the named user certain rights and privileges. A user who isn't listed in an access control list can't gain access to the resources protected by the ACL. Notes uses ACLs to
protect documents, databases, and servers.
Notes uses a variety of names for all the ACLs it supports. Document ACLs are called ReaderNames fields, read access lists, or AuthorNames fields. Server ACLs are called server access lists. Only database ACLs are actually
called ACLs.
History has seen many encryption schemes come and go. The simplest form of encryption is to simply exchange one character for another. Puzzles based on this concept are available in many Sunday newspapers. Obviously, an encryption scheme that can be
cracked over danish and coffee isn't very secure. Nevertheless, advanced encryption schemes rely on this same basic concept of substituting one set of characters for another. Instead of substituting one character for another, modern encryption schemes
essentially substitute one string of a hundred words for another string of a hundred words. The idea is to make it nearly impossible to guess the substitution pattern.
When most people think about encryption, they think of systems in which both the sender and receiver of a message share some common secret. This secret, also known as a key, is used by the sender to scramble a message and the receiver to
descramble the message. Public key encryption uses a pair of matched keys, one public and one private, to provide privacy and authentication. Before using any public key system such as Notes, a user must generate a pair of keys. For Notes users,
this process is done by an administrator when an ID file is created. (Notes can generate a set of keys in a few seconds.) The keys are stored in the ID file. In essence, the ID file becomes the users private key.
Once generated, a public/private key pair are forever linked. One is useless without the othera message encrypted with a public key can only be decrypted with the matching private key (see Figure 3.1). A message encrypted using a public key
cannot be decrypted using the public key. This process is counterintuitive for most people. Many people's intuition is that a message encrypted using a key should be able to be decrypted using that same key. This isn't true for public key
encryption.
Figure 3.1.
Public key encryption uses a pair of keys to encrypt and decrypt messages.
Because one of the keys is kept private, it can be used to identify a specific user. The private key is the "something you have" that Notes uses to uniquely identify a user.
All Notes security is based on the assumption that private keys are well protected. There are ways you can recover from a lost or stolen key, and Notes does help by protecting private keys with a password, but a secure Notes network cannot be maintained
if private keys are easy to steal.
Notes ACLs use names to restrict access to a server, database, or document. The preceding section described how Notes uses private keys, which are just large prime numbers, to uniquely identify a user. In order for this to work, there must be some
mechanism that connects a private key to a name. Otherwise, anyone could create a random key, attach a forged name, and gain access to any Notes resource. Notes, like all other public-key encryption schemes, uses certificates to bind a set of keys to a
name. Certificates are electronic stamps that bind together a name, a set of keys, and the name of the certifier issuing the certificate. Notes stores certificates in ID files and in the Public Address Book.
All certificates must have a name. Certificates are commonly named after the organization that issued the certificate. Notes also enables you to create a tree structure of certificates (see Figure 3.2). Certificates that are part of a tree are known as
hierarchical certificates. Non-hierarchical certificates are also known as flat certificates.
Hierarchical certificates are divided into two categories. The root certificate is known as the organizational certificate. Every other node in the tree represents an organizational unit certificate. Creating the naming scheme for your
tree of certificates is a major planning step when initially deploying Notes. Each certificate in the tree can be used to stamp ID files. When a user is first stamped by a certificate, the name of the user is combined with the name of the certificate. For
example, when user Leslie Lesnick is certified by Marketing/L3Comm, her full name becomes Leslie Lesnick/Marketing/L3Comm.
Figure 3.2.
You can create a tree of certificates in Notes.
A certificate is generated by a certifier, using the certifier's private key. In Notes, the certifier's private key is contained in the CERT.ID file. The CERT.ID file is automatically generated when you install the first Notes server. Anyone with access
to the CERT.ID file could use it to issue certificates. Recovering from a lost or stolen CERT.ID file can be a very large task if not properly planned beforehand. Chapter 5, "Building a Deployment Plan," shows you how to plan for this
contingency. No one can afford to ignore this issue; eventually, the person in your organization who has been issuing certificates will leave, sometimes under hostile circumstances. If you haven't taken precautionary steps to minimize the risk of this
former certifier getting access to your Notes network, you will have to invalidate all certificates ever issued by that certifier.
Most administrators use the name of the organization for both the top-level certificate and the Notes domain. This practice has confused many administrators into thinking that there is some connection between Notes domain names and certificates. There is no connection between domain names and certificates. Domains are nothing more than a collection of servers; domain names have nothing to do with security. You can add, change, and delete domain names without having to worry about recertifying users and servers within that domain.
Notes provides two-way authentication. The server checks the identity of the user and the user checks the identity of the server. This second check is important when Notes is used over public networks such as the Internet. If users didn't have the
ability to verify the identity of servers, someone could impersonate a server and gain access to confidential information.
When a user first contacts a server, both the server and user exchange certificates. Each party must have a certificate that is trusted by the other party. In Notes, a certificate is trusted if and only if a copy of the certificate is contained in the
local ID file and the certificate is either a hierarchical certificate or is a trusted flat certificate. For example, in Figure 3.3 Leslie Lesnick is accessing the server Mail/Marketing/L3Comm. Both Leslie Lesnick and Mail have a copy of the
Marketing/L3Comm hierarchical certificate. Authentication succeeds and a session is established.
Figure 3.3.
Leslie Lesnick and the server Mail share a certificate.
ID files don't have to contain the same certificate; they only need to have a common ancestor. This enables all the users and server within an organization to communicate. In Figure 3.4, Leslie Lesnick can contact the Server1 server, although she
doesn't have the same certificate as Server1. Both Leslie Lesnick and Server1 have L3Comm as an ancestor, so each trusts the other's certificate.
Figure 3.4.
Leslie Lesnick and Server1 share an ancestor, L3Comm.
ID files can hold more than one certificate. This situation arises most often when two servers from different companies need to communicate. ID files from different organizations must exchange certificates before they can communicate. A hierarchical
certificate received from another organization is known as a cross certificate. In Figure 3.5, both Server1/Sales/L3Comm and RandD/Denver/Acme must receive a cross certificate before communicating.
Figure 3.5.
Servers from different organizations need cross certificates before communicating.
Always exchange cross certificates at the lowest level possible. This method provides the highest level of security. In Figure 3.6, Server1/Sales/L3Comm needs to communicate with Mail/HR/Columbus/Acme but shouldn't communicate with
Contracts/Legal/Columbus/Acme. When creating a cross certificate, the Acme administrator should use the HR/Columbus/Acme certificate, not just the Columbus/Acme certificate. If L3Comm was cross-certified using the Columbus/Acme certificate, any ID with
this certificate as an ancestor, including Contracts/Legal/Columbus, could be accessed by Server1/Sales/L3Comm.
Figure 3.6.
Server1 can access Mail, but not Contracts.
Even though the whole point of certificates is to bind names and keys together, by default Notes doesn't check that a public key stored in the local Name and Address Book is the same one in the ID file of the person or server accessing the system. Doing
this check slows the system and is unnecessary. Notes uses a challenge/response sequence to authenticate users and servers. When a user (or server) contacts a server, the user sends a random number to the server. The server encrypts the number, using its
private key, and returns the encrypted number to the user. The user decrypts the number using the public key of the server, which is available in the Name and Address Book. If the decrypted number matches the challenge number, the user is assured that the
correct server has been reached. The process is then reversed and the server challenges the user. The certificate check is then done to validate the identities associated with the keys.
Notes uses a variety of access control lists (ACLs) to control access to servers, databases, and documents. Most Notes ACLs can accept either a common name or the full hierarchical name. Providing the full hierarchical name provides better security and
is the recommended approach. The following sections discuss the ways you can use Notes ACLs.
Access to servers is controlled with ACLs. Each server has many ACLs. These lists are all part of the server document in the Name and Address Book. These lists include
Most administrators don't think of all these lists as ACLs. Many of these lists are very specialized, controlling access to a small part of Notes. No matter what they are called, these lists all function as ACLs. They are lists of names that control
access to system resources.
You can allow unauthenticated access to a server. In this case, Notes bypasses the authentication challenge and accepts the name provided by the user or server. Notes keeps track of users that are unauthenticated, giving all such users the name
Anonymous, and allows you to set access levels for these users. You don't leave your system completely defenseless just because you allow unauthenticated access; unauthenticated access is useful for setting up public servers and databases. Because
unauthenticated users don't need a certificate in common with the server, the server administrator doesn't need to bother with cross-certifying anyone who wants to access the server.
You can control access to Notes databases in a variety of ways. Your options range from preventing a user from even knowing that a database exists to allowing completely open access to all parts of a Notes database. Using various techniques, you can
You can hide the existence of a database by not listing the database's name in any catalog or in the Open Database dialog box. This method forces the user to know the full path and file name for the database. This technique isn't secure, but is often
effective, and is generally used when testing a new database before making it available for production use. An administrator copies the new database to the production machine and tests it in the actual environment.
Notes allows administrators to limit access to securely hide a database. With directory redirectors, you can set up secure directories that can only be accessed by specific people and servers. Directory redirectors are text files with a .DIR
extension. When Notes encounters a file with a .DIR extension in the Notes data path, it treats the indicated directory as a subdirectory of the current directory. The first line should give the full path of the secure directory. Other lines should list
the names that are allowed to access this directory. Here is an example of a simple redirection file:
c:\secure\database Andrew Dahl\Consulting\L3Comm
For example, if only people in marketing should be allowed to view databases in the Marketing subdirectory, you would create a .DIR file called Marketing.DIR. In this file you would place the full path name for the location for Marketing databases. In
the next line you would place ACME/Marketing/* and only people with names that match would be allowed to access any databases in that subdirectory.
The primary method of controlling access to a database is the access control list (ACL). Each name in an ACL is granted some permissions and denied others. Every Notes database has its own ACL. ACLs aren't shared across databases. Figure 3.7 shows an
example of an ACL.
Figure 3.7.
A Notes access control list.
Database access control lists only control access to a single database. They aren't shared across different databasesor replicas. Notes Release 4.0 contains features that enable an administrator to force ACLs of replicas to be identical and to
keep ACLs in sync with the Name and Address Book.
The following roles and privileges can be assigned using the access control. There are several options for each access level that can be used to fine-tune access for a particular group.
All database ACLs must have a default entry and at least one manager. Notes doesn't let you delete the -Default- entry or delete or change the last person with manager access.
In addition to the -Default- entry, there is one other special entry, Anonymous, which can be included in an ACL. Use Anonymous to set the access level for
unauthenticated users. If you give anonymous users anything other than reader access, their unauthenticated names can appear in the documents that they create. The actual name used by an unauthenticated user would be placed in the document, not the word
anonymous.
Users are listed in ACLs to give them specific privileges. Servers are listed in ACLs to determine which data will be replicated. This often overlooked point is the root of several common replication problems. For example, if a server is given only
reader access, it could receive updates, but not send any updates.
Servers that aren't listed in a database ACL can't replicate the database (assuming a default of no access). Servers without manager access cannot replicate ACL changes. The default access for servers within a domain should be manager for all databases to ensure that ACL changes are propagated to all replicas.
One of the steps of designing your Notes network is to plan your default ACLs. A default ACL is the ACL given to a database when it is first implemented. Notes automatically creates a default ACL when a database is created. Chapter 5, "Building a
Deployment Plan," shows you how to create default ACLs for your organization. Proper default ACLs are an important part of minimizing security problems.
Groups and wild cards are two techniques you can use to ease the administrative burden. Groups are simply collections of names. User names, server names, and other groups can all be included in a group. You create groups using the Public Name and
Address Book, but use them in ACLs (and mail addressing). Always use groups rather than individual names in ACLs.
If you have set up your certificate hierarchy so that members of a department or geographic region are certified by a common certifier, it may be easier to use wild cards than to set up a group. For example, if you wish to restrict access to all members
of the legal department, enter */Legal/Acme in the ACL. Wild cards are even easier to use than groups because you don't have to manage any entries in the Name and Address Book. But wild cards require you to plan ahead. If you
don't have a consistent naming scheme across the entire organization, wild cards aren't effective.
When you use groups and wild cards in ACLs, the possibility arises that a person may appear more than one time. Notes resolves any conflicts by giving a user or server the highest level of access of any of its entries. The only exception is when the
name is explicitly listed in the ACL and isn't just part of a group. In this case, Notes gives the access listed for the name and ignores the group entries.
Roles protect access to specific forms, subforms, views, or fields. For example, a purchase order application may have specific individuals who are authorized to approve purchase order. Database designers can create an Authorizers role in the ACL and
protect a signature field so that only Authorizers can sign the field.
Historically, roles aren't used often. You can accomplish the same goals by using groups, often with less administrative overhead. In the purchase order example, you could just as easily create a group called Authorizers and use the group to protect the
field. Roles also require the database designer and database manager to work together to define and manage the roles.
The disadvantage to groups (as opposed to roles) is that you can end up creating thousands of groups that are specific to individual databases. This can clutter up the Name and Address book and make it hard to manage. In addition, database managers need
the ability to edit group documents in the Name and Address Book that are used in their databases. This can create security problems when too many people have access to the Name and Address Book. This is less of a problem for small organizations where a
single person is the server administrator and database administrator. In large organization with many different database administrators, giving database managers access to the Name and Address Book will be a problem.
Using roles is better than listing specific names inside forms, views, and fields properties. Changing an individual's name is easier when that name appears in fewer places. By including an individual's name inside documents and fields, you are
increasing the workload necessary to maintain the system.
The other advantage offered by roles is that roles clearly point out something very important about a database; the existence of special roles. Because very few databases have protected forms, views, or fields, it is natural to overlook the few
databases that do use them. Because roles are unusual, using them can lead to problems when applications are updated. If the designer isn't clearly reminded of the roles present within an application, he may accidentally unprotect a form, view, or field.
Roles are listed in the database ACL and can serve as a reminder to designers.
You can protect your database designs from being changed. This feature is necessary to support third-party Notes applications, but any organization can take advantage of this feature. You have the option to hide the design of any database. Hiding the
design prevents anybody, including those with manager access, from viewing or changing the design of that database. You can set a password on the design of the database so that any user who knows the password can update the design of the database. By
protecting the design of all your databases with a password, you can prevent unauthorized or unintended updates to your database design.
Database designers can limit access to specific design elements without hiding the entire design. The options available are
Hiding access to views doesn't prevent a user from viewing documents that appear in that view (see Figure 3.8). A user could always view those documents in a different view. To absolutely prevent users from accessing a document, you need to use
document-level security.
Figure 3.8.
You can limit access to a view by using view properties.
You also can hide the view, not just the documents within a view. This doesn't prevent a user from copying the database, gaining manager access, and unhiding the view.
Form-create access lists are only meant to provide a cleaner interface. Forms with a create-access list aren't listed in the Create menu for users who don't have the ability to create that form. However, the user can use another program to create a
document with the restricted form name.
Sections aren't a true security feature. Data appearing in protected sections can still be changed, using a different form. If you need to protect specific fields, you must use encryption.
You can control on a document-by-document basis who has the right to update, delete, or view each document. In addition, you can control, for each type of document in the database, who has the right to create a document of that type. There are two ways
you control access to individual documents: with ReaderNames fields and with AuthorNames fields.
ReaderNames fields are a special category of field provided by Notes specifically to control who can read a document. ReaderNames fields contain lists of user IDs or group names. Only people who are listed in the ReaderNames field or a group in
the ReaderNames field can read that document. If a document has a ReaderNames field and a user isn't listed in that ReaderNames field, that document doesn't appear in any view or folder. Keep in mind that ReaderNames fields should be used only as a
security feature.
Of course, if a document contains a ReaderNames field, and a user isn't listed in that ReaderNames field, he or she can't replicate that document. This fact tempts many people into using ReaderNames fields as a method of minimizing their replication costs. Don't do it! Only use ReaderNames fields when you actually want to secure access to that document. Using ReaderNames fields as a means of minimizing replication costs is inefficient and puts a great burden on your administrators. If you want to minimize replication costs, use selective replication, not ReaderNames fields.
AuthorNames fields are checked only for users who have author access to the database. If a user has editor access to a database, he can edit any document that he can view, regardless of whether that document has an AuthorNames field. If a person has
only reader access to a database, he cannot edit any documents, even if he is listed in the AuthorNames field. A person with author access to a database who is listed in an AuthorNames field in a document can edit that document. Author name fields are a
method of providing people who have only author access the ability to edit their own documents.
AuthorNames fields are used primarily in workflow applications. For example, Charlie creates a document that gets placed in a centralized workflow database. Several other people in Charlie's department are also submitting documents into the workflow
database. You want to give Charlie the ability to edit only the documents that he creates. The way to accomplish this is to give author access to the workflow database and list him in an AuthorNames field in every document that he creates. Although he can
view work done by other people, he can't change it.
Views can have both an edit-access list and a read-access list. You can restrict who can edit documents in a view by using view-edit-access lists. Only names that appear in the view-edit-access list can edit the documents that appear in the view.
Read-access lists restrict who can read documents that appear in a view. In reality, these features don't protect documents, because a user can create a private view that lists a document and edit or read it from the private view.
There are three ways to control access to field level information in Notes; encryption, field hiding, and protected sections. Only encryption truly protects data. Field hiding and protected sections are useful in creating a good interface and in
preventing users from making mistakes. If you want to encrypt fields, you need to plan some way of distributing encryption keys only to the people who should have access to the data.
Release 4.0 of Notes introduces the concept of local security. Local security isn't a security feature, but rather a user-interface feature. In the past, people who made replicas of the database on their own machines were given manager access to that
database regardless of any entries in the access control list. They could delete any document and update documents at will. However, because they weren't listed as managers on the server copy of the database, those changes wouldn't replicate, causing a
great deal of confusion. With Notes Release 4.0, if a person is listed as having only author access to a databaseeven if he creates a replica of that database on a laptopthe user interface will behave as if he has only author access. This helps
prevent user confusion.
Even with local security, there is no way to protect data once someone has a copy of the database. Although security is enforced at the user interface, a determined person could easily gain access to the data in a local replica. The only way to protect
a database that someone has copied onto his own hard drive is to encrypt that database. If you are very concerned about the security of data on your laptops, the only way to protect that data is to encrypt that database on the hard drive. This method is
still a long way from crack-proof, but very few people or organizations have the time or the skill to break through the Notes encryption.
Encryption is the only effective way to protect confidential information. All other ways of limiting read access to data can be compromised if someone manages to get a copy of the database. Even encryption can be broken by someone with enough
experience.
Encryption, like roles, is a seldom used feature in Notes. Many administrators will never have to deal with encrypted databases, documents, or fields.
Notes enables you to encrypt fields within a document by using an encryption key. All fields within a document must be encrypted using the same key. Unencrypted fields in a document that contains encrypted fields are still readable by anyone.
You can force Notes to encrypt all documents created with a specific form. Designers can do this in two ways:
You should place encryption keys in a form when you know exactly which key should be used to encrypt the form. Keywords let you create a form that can be encrypted with any one of several keys. When a form is set to automatically encrypt a document, all
encryptable fields in the form are encrypted when the document is saved. A user must have access to the encryption keys in order to create and save a document containing encrypted fields. If you take an existing form and add automatic encryption to it,
however, existing documents created with that form remain unencrypted.
Notes also provides an easy way to encrypt the body of mail messages. Encrypt mail when you want to maintain privacy. Only the recipient of an encrypted message can read the message, if you encrypt the body of the message using the recipient's public
key. Because only the recipient has a copy of the matching private key, only the recipient can decrypt and read the message.
No way exists to prevent a user who can read data from physically copying the data by hand and distributing it. Although you can't prevent someone from copying data to paper by hand, Notes does allow administrators to prevent computerized copying. Often
all you want is to discourage users from copying data. Using form properties, you can prevent anyone from printing, forwarding, or copying (or cutting-and-pasting) data from a document created with that form.
Several Notes features are commonly used as security features, when they are in fact only user-interface features, providing no real security. These features include
The only way to limit access to documents is to use document-level access lists or to encrypt the document. Likewise, fields truly can be protected only when they are encrypted.
Authentication and access control are the basic theoretical foundations for all modern network security. Notes uses an advanced form of authentication, based on possession of a specific file. The elements of Notes security are
Most administrators will spend a considerable amount of time managing all the various ACLs in Notes. Proper planning is required to minimize administrative overhead and security problems. Chapter 5, "Building a Deployment Plan," and Chapter
18, "Administering Notes Security," show you how to plan an effective security system that minimizes administrative effort.
Notes security is a major step forward for most organizations. Most organization's policies and procedures are set up to handle security based on something the user knows, such as a password. Notes security is based on something the user owns: an ID
file. Chapter 4 covers the implications of this kind of security system for your organization along with some advanced Notes security features.