Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

CHAPTER 3: Important “Ilities” in Web Co... > Confidentiality, Integrity, and Avai...

Confidentiality, Integrity, and Availability

Confidentiality, Integrity, and Availability The critical “ility” characteristics of Web commerce computing platforms and networks build upon the fundamental information system security concepts of confidentiality, integrity, and availability (the C-I-A triad). Confidentiality Confidentiality refers to the prevention of intentional or unintentional unauthorized disclosure of information involved in Web commerce transactions. This information includes configuration settings, logic, and interfaces. Web commerce platforms must be protected from reconnaissance probes, denial of service (DoS) attacks, viruses, Trojan horses, man-in-the middle exploits, and a variety of other emerging threats. Encryption is commonly used to preserve confidentiality in encapsulated data and software. The following are examples of the use of encryption in Web commerce transactions: Software may need access to a database. A possible scheme for protecting the database user password is to encrypt the password and store it in a protected file. The decryption key should be supplied to the software via a command line or protected file, and the salt (random bits that are used as an input to derive the cryptographic key) should be embedded in the code itself. In this way, the software requires the decryption key, salt, algorithm, and encrypted password to gain access to the database. An additional approach to meeting encryption requirements in scalable implementations is to encrypt data on-the-fly and store it in files across a number of systems in order to provide for backup and failover. Following this operation, a “reference” to the key material that was used for encrypting in the file header itself is stored, usually in clear. The next step is to create an HMAC of the entire payload and store it along with the file for integrity verification purposes, to ensure the content has not been modified. The key material is stored in a hardware security module (HSM) and protected by various access control mechanisms. In this approach, an entity attempting to decrypt the stored file contents needs to use the “reference” to the key material, and have authorization to obtain the key. An individual would not have the permission to store or transmit the data once decrypted (i.e. clear data always stored in RAM). At no point in the process will the actual key material leave the HSM facilities. Software needs to generate a random number for cryptographic or security purposes. A secure random number should comply with the statistical random number generator tests specified in FIPS 140-2 Security Requirements for Cryptographic Modules, Section 4.9.1, and must produce nondeterministic output. To ensure the confidentiality of configuration data and include files in a Web application, the configuration data and include files should be placed outside the Web application root directory that is served by the Web server. This will prevent the Web server from serving these files as Web pages. The documentation for the Web and/or application server should be consulted to allow or disallow access to files outside the document root. Integrity Integrity refers to the prevention of unauthorized modification (corrupting, tampering, overwriting, inserting unintended logic, destroying, or deleting) by valid entities (persons or processes) and of all modifications by invalid, unauthorized entities. Integrity is maintained by specifying means to recover from detectable errors, such as deletions, insertions, and modifications. The means to protect the integrity of information includes access control polices and decisions on who can transmit and receive data and which information can be exchanged. Derived requirements for integrity should address the following: Validation of the data origin Detection of alteration of data Determination if the data origin has changed The integrity of data stored on different media should also be ensured by monitoring the stored information for possible errors. The criteria and methods used in monitoring the stored data for errors should be determined in advance to make certain that they are effective and reliable as well as defining the actions that need to be taken in the event of a discovery of an integrity error. Using a cryptographic hash function is a common way of ensuring the integrity of data and software components. A cryptographic hash function takes an arbitrary block of data as input and returns a fixed-size string or hash value such that an accidental or intentional change to the data will almost certainly change the hash value. The ideal hash function has four main properties: It is easy to compute the hash for any given data. It is difficult to construct a text that has a given hash. It is difficult to modify a given text without changing its hash. It is unlikely that two different messages will have the same hash. FIPS 180-3 Secure Hash Standard specifies algorithms for computing five cryptographic hash functions: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. NOTE In recent years, several of the non–NIST-approved cryptographic hash functions have been successfully attacked, and serious attacks have been published against SHA-1. Therefore, NIST held a competition for a new Secure Hash Standard, to be called SHA-3. The competition was closed on October 31, 2008, and, as of this writing, NIST is in the process of evaluating the 14 second-round candidates. Hash functions are discussed in more detail in Chapter 5. Availability Availability means that Web commerce software and hardware must be operational and accessible to its intended, authorized users (humans and processes) whenever required. Software under attack must be survivable or resilient. Survivable software is resilient enough to resist (i.e., protect itself against) or tolerate (i.e., continue operating dependably in spite of) most known attacks plus as many novel attacks as possible. It must also recover as quickly as possible and with as little damage as possible from those attacks it can neither resist nor tolerate.1 High-availability or life-critical systems must be especially fault-tolerant. Fault-tolerant software and hardware should have the following properties: No single point of failure No single point of repair Fault isolation to the failing component Fault containment to prevent propagation of the failure Availability of fallback or reversion modes Software that is susceptible to an Internet denial-of-service (DoS) attack can respond through containment, graceful degradation, or automatic fail-over. In a containment response, software with more than a single connectivity point may disconnect the affected connectivity point. Through graceful degradation, the software may vary its response times to subsequent requests, resulting in a lower quality of service, but preserving a degree of availability. Software receiving a large number of requests may even fail-over to a higher-availability service. While availability is being preserved, confidentiality and integrity have to be maintained.

  

You are currently reading a PREVIEW of this book.

                                                                                                                    

Get instant access to over $1 million worth of books and videos.

  

Start a Free Trial


  
  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint