A logon identifier is another name for a user account. The account is uniquely identified and matched to the user. Every time the user logs on, this account is used, which helps enforce several other controls.

A logon identifier is needed for access control. If every user logged on with an account named “Bob,” then every user would have the same access. The user’s real name doesn’t matter. Permissions granted to “Bob” are granted to all users who log on with the Bob account.

However, if every user logs on with a different account, permissions can be assigned individually. Users who need access to resources are granted the access, and users who don’t need access aren’t granted the access.

Audit logs, which record who, what, where, and when details, use logon identifiers. The “who” comes from the logon identifier. Users log on with their own account, and any auditable actions are recorded with this account information.

The logon identifier also provides nonrepudiation, which means users cannot believably deny they took an action if it is logged with their logon identifiers.

Most systems include session time-out controls, which help ensure that an unauthorized user doesn’t have access to a session without providing credentials.

An example of a simple session time-out control is a screen saver. A screen saver can be configured to start after 10 minutes of inactivity and to require users to log on again after the screen saver has started. That way, if a user walks away from a computer without locking it, the screen saver will start after 10 minutes and lock the system.

Many websites include session time-outs. For example, many banking sites will close the session after 20 minutes. After credentials have been provided to log on to the banking site, as long as the user is active on the site, the session remains open. This feature allows different pages to be viewed without logging on again.

However, if the webpage is left open but is inactive for 20 minutes, the time-out control will close the webpage and clear out the session data. To access the page again, logon credentials must be entered again.

Similarly, if a session on a public computer is inactive for 20 minutes, it will close, which helps prevent unauthorized users from accessing the site.

Operating systems and network devices include the capability to record different types of events. Recording events and regularly reviewing the logs can help identify what is occurring. Logs can be used to investigate security events and to troubleshoot problems.

Logs typically record the following details on events:

• Who did it
• What happened
• Where it happened
• When it happened

This information is often shortened to who, what, where, and when. The logon identifier identifies who took the action, the system identifies what happened and where it happened, and a clock provides a timestamp to record when it happened.

Several types of logs are present in any network. Desktop and server operating systems include logs; firewalls include logs to track allowed and blocked traffic; and network server applications, such as Domain Name System (DNS), log events. Logging can be enabled or enhanced on just about any system.

System logging tracks different types of events on the operating system. For example, Microsoft Windows operating systems include the System log to record system events. These events include when services start or stop or when the system starts or stops. These events are categorized as errors, warnings, and information events.

Security logging focuses on security events. Some security events are automatically logged. However, logging can be configured to record additional auditable events. For example, auditing on folders could be enabled to show whether anyone accessed a folder holding sensitive data. This type of auditing would record the details of anyone reading, modifying, or deleting data.

Not all events should be logged, though. Instead, logging should include only what is important. Logging too many events takes up extra resources, which include processing power to capture and log the events and disk space as the log fills up.

Application developers use data range and reasonableness checks to help ensure they are receiving valid data. Developers can’t ensure the data is accurate, but they can ensure the data is valid.

Valid data follows a specific format, for example, a text box that expects a five-digit U.S. ZIP Code. The only valid characters are five numbers. If the user enters anything other than five numbers, the data is not valid.

Along the same lines, for example, the user’s ZIP Code is 23456. If the user accidentally enters 33456, the application can’t tell that the ZIP Code is incorrect. Because 33456 is a valid five-digit number, it will pass the validation test.

Validation checks appear on websites. The user is prompted to enter certain data, such as a name and an email address. If the user misses or enters something incorrectly, the website complains to the user, such as showing a red asterisk with an error explanation. The explanation may say something like “You must enter an email address.”

Data range checks ensure data is within a certain range. For example, users may be asked to enter a number between 1 and 100. The data range check ensures the number is between 1 and 100. If the entered data is outside the valid range, it is not used. Instead, the user is prompted to try again.

Similarly, a date range can verify that dates are within a certain range. For example, a birth date could be used to ensure someone is over a certain age. It compares the current date with the birth date. If the user is too young, the website could redirect the user to an error page.

Reasonableness checks ensure that the entered data is reasonable. For example, how many letters would be expected in a first name, and what types of characters are valid in a first name are defined.

The parameter might be that a first name can’t have more than 25 characters nor contain numbers. Therefore, when a user enters data for a first name, it could be checked against this parameter.

Reasonableness checks can be used for any type of data. The data simply needs to be defined. For example, if a reasonableness check is used for a first name, what constitutes a first name needs to be defined. Thus, five letters as a maximum for a first name isn’t acceptable.

Firewalls and router software are used as technical controls in a network. They control the traffic by allowing some traffic and blocking other traffic.

Many firewalls and routers use an implicit deny philosophy, meaning all traffic is blocked unless it is explicitly allowed. To identify allowed traffic, firewalls use rules, and routers use access control lists (ACLs).

A router provides basic filtering of traffic, based on:

• Internet protocol (IP) addresses
• Ports
• Some protocols

In FIGURE 9-1, the router can be configured to allow traffic from any hosts with IP addresses on subnets 1, 2, or 3. Ports are used to identify protocols. For example, the Hypertext Transfer Protocol (HTTP) uses port 80. An ACL can be configured to allow HTTP traffic to the intranet web server on subnet 1. The Simple Mail Transfer Protocol (SMTP) uses port 25. An ACL can be configured to allow SMTP traffic to the email server on subnet 2.

The firewall starts with basic routing capabilities. However, most firewalls are much more advanced. Router ACLs can evaluate only a single packet at a time. However, a firewall can evaluate the entire conversation. Once a session has been established between two hosts, the firewall can evaluate all the traffic between them, which is referred to as a stateful evaluation.

Rules created on the firewall allow a network to be protected from external attacks. By allowing only specific traffic, the capabilities of attackers from the Internet are limited.

Encryption changes plaintext data into ciphered data. For example, the word password is in plaintext, but encrypted it may look like this: MFIGs3x/$6o0D.

Data can be encrypted at rest or when transferred. At-rest data is any data stored on media, such as a hard drive or a USB flash drive. If a user stores sensitive data on a laptop computer, the data can be encrypted to protect it. If the laptop is lost or stolen, there is less chance the data will be compromised. Similarly, data stored on a USB flash drive can be encrypted. If the USB drive is lost or stolen, the encrypted data will be difficult for anyone to read.

Attackers and administrators can capture and read data sent over a network. For example, Wireshark is a free packet analyzer that can capture data sent over the network. Once the data has been captured, the process to open and analyze the individual packets is trivial. Wireshark allows individuals to read any data sent over the network in cleartext.

Encrypted data is not impossible to decrypt given enough resources and time. However, encryption algorithms are designed to make decryption too difficult and take too much time to make it worthwhile.

For example, years ago, the Rivest, Shamir, Adelman (RSA) encryption, which was used on the Internet, employed 40-bit keys, which, in their time, were secure. However, in 1997, a student at UC Berkeley cracked a 40-bit RSA key in three and a half hours, and, today, it can be done in minutes. Currently, 1024-, 2048-, or 4096-bit keys are commonly used with RSA. According to RSA, 1024-bit keys have been cracked, and 2048-bit keys can be sufficiently used until 2030. NIST recommends 2048-bit keys for RSA.

Encryption is classified as either:

• Symmetric—This encryption uses one key. As a simple example, a key of 53 could be used to both encrypt and then decrypt data. Keys are much more complex than just a two-digit number, however. Strong symmetric algorithms use 256 bits.
• Asymmetric—Asymmetric encryption uses two keys. One key is called the public key, and the other key is called the private key. These two keys are matched to each other. Any data encrypted with the public key can be decrypted only with the matching private key. Any data encrypted with the private key can be decrypted only with the public key.

Advanced Encryption Standard (AES) is the primary symmetric encryption protocol used today. In the 1990s, NIST asked for developers to submit cryptographic algorithms for evaluation. After a lengthy evaluation, NIST selected and ratified AES in 2000 as a standard.

AES is fast and efficient. It’s quick even when encrypting small amounts of data, such as on USB flash drives, and doesn’t need as much processing power as some older encryption algorithms.

Despite its strength, encryption shouldn’t be considered foolproof. Encryption algorithms continue to improve, but so do cryptanalysis techniques designed to crack algorithms. The National Security Agency (NSA) has a relevant saying: “Cryptanalysis always gets better. It never gets worse.”

A public key infrastructure (PKI) is created to provide support for certificates. Even though the PKI has several elements, the purpose of all the elements is centered on certificates. Some of the elements of a PKI are:

• Certificate authority
• Certificates
• Public and private keys
• Web of trust

A certificate authority (CA) issues and manages certificates and can be public, such as VeriSign. A CA can also be private. A private CA is created within a company, and it issues certificates internally.

Systems have a listing of CAs that they trust. If a system trusts a CA, it automatically trusts any certificates issued by the CA. This situation is similar to driver’s licenses issued by a department of motor vehicles (DMV). If a driver’s license is presented as identification, people trust it as valid because the DMV is trusted. All driver’s licenses issued by the DMV are automatically trusted. Similarly, all certificates issued by a trusted CA are automatically trusted.

Certificates are used for identification and to aid in encryption. Certificates include details on the entity that received the certificate. For example, if the certificate was issued to a server, the certificate would include details on the server, such as its name. The server is able to present the certificate as proof of its identity.

Public and private keys, which are matched, are used with a PKI. Data encrypted with one of the keys can be decrypted only with the matching key. A public key is embedded in the certificate and passed to others. The private key always stays private.

For example, a certificate is issued to a web server. When a user connects to the web server and starts a secure session, the server sends the certificate to the user. The certificate includes a public key. The user can encrypt data with the public key and send it to the server. Because the server holds the private key, it can decrypt the data. Because no other entity has the private key, no one else can decrypt the data.

Certificates are also used with a digital signature, which provides authentication, nonrepudiation, and integrity.

For example, an email can be signed with a digital signature. The receiver has verification that it was sent by the signer and not someone trying to impersonate the signer. A digital signature is created in two steps:

• A message hash is created.
• The hash is encrypted with the sender’s private key.

FIGURE 9-2 shows that a hash is simply a number created by running an algorithm. For example, a simple hash for the message “Hello” could be 77. No matter how many times the algorithm is run, the hash would always be 77. The hash is then encrypted with the sender’s private key. The result may be Wozj4W902.

The encrypted hash is sent with the message. The receiver has the public key, which is then used to decrypt the hash. This sequence provides three security benefits:

• Authentication of the sender—The matching public key decrypted the hash, which verifies that the message was encrypted with the sender’s private key because only the sender has access to the private key.
• Nonrepudiation—The sender cannot deny sending the message. Again, only the sender has access to the sender’s private key. No one else could have encrypted the hash if the sender’s matching public key decrypted it.
• Integrity—The recipient can calculate the hash on the message and decrypt the received hash. If both hashes are the same, this verifies that the message was not modified.

A digital signature is not possible without a PKI because it requires matching public and private keys. The public key must be able to be packaged into a certificate. A CA is needed to issue the certificates.

A web of trust is used in Pretty Good Privacy (PGP)- and OpenPGP-compatible systems to ensure that the binding between a public key and its owner is authentic. It is an alternative to the PKI, which relies on a CA. A web of trust is based on a decentralized trust model, as opposed to a CA’s centralized trust model.