Security Requirements: Type 15

Security is perhaps the most difficult type of requirement to specify, and potentially the one posing the greatest risk if it is not correct. When you write security requirements, consider the nature of security as it is applied to software and allied products. Shari Lawrence Pfleeger points out that security can be thought of as having three aspects:

• Confidentiality: Data stored by the product is protected from unauthorized access and disclosure.

• Integrity: The product's data is the same as the source, or authority, of the data.

• Availability: The product's data and functionality are accessible to authorized users and can be produced in a timely manner.

Confidentiality

The confidentiality aspect of security means the product's data is not available to anyone except authorized users. You can, of course, achieve this level of security by locking the product in a vault. But if you want people to use it, then you have to provide a key to open the vault and some way to control who or what is allowed to use that key. Locking our products away in vaults is not all that practical, so we tend to use software "locks" that have the same effect. That is, they prevent anyone except keyholders (the authorized users) from accessing the data.

When you write this kind of requirement, you are specify the allowable accesswho is authorized, under what circumstances authorization is valid, and what data and what functions are accessible to each authorized user.

The product shall ensure that only authorized users have access to the [name of] data (or function).

The product shall distinguish between authorized and nonauthorized users.

The term "authorized" may also need some further explanation. For example, are all authorized users authorized all the time? Does access depend on the time of day or the location of the user at the time of access? Must a user collaborate with another authorized user to gain access? In other words, is the authorization conditional? If so, write these conditions as a requirement.

It may also be worth considering this requirement:

The product shall deliver data in a manner that prevents further or second-hand use by unauthorized people.

Availability

Availability means that authorized users are not prevented from accessing the data, and the security devices employed do not hinder or delay the users from getting what they want when they want it. Availability also means the data is, well, available.

That is, the product does not keep it in a way that users cannot get at it. Additionally, you must consider requirements for preventing the loss of data and, should the worst happen, recovering lost or corrupted data.

This begins to overlap with the integrity topic, so let's press on.

Integrity

Integrity means that the data held by the product corresponds exactly to what was delivered to the product from the adjacent system (the authority for the data). In our de-icing example, weather stations send data about temperature and precipitation to the IceBreaker product. The weather station originates the data, and thus is the authority for it. Any copies of this data, such as those held by IceBreaker, must be faithful to the weather station's version. Here is the integrity requirement for the IceBreaker product:

The product shall ensure its road temperature data corresponds to the data transmitted by the weather station.

This may seem obvious, but you should also consider several other allied integrity requirements:

• Integrity requirements to prevent unintentional misuse by authorized users. This is the most common form of data corruption.

• Audit requirements to detect improper usage, either by authorized or nonauthorized users.

• Requirements relating to proving the integrity of the product after some abnormal happening. These happenings can include such things as a power failure, an exceptional operating condition, or unusual environmental conditions such as fire, flood, or bombing.

Auditing

You can also consider normal auditing to be part of the security section of your specification. Most accounting products have a requirement to be audited. The goal here is not necessarily to prevent fraud or misuse, but rather to ensure that no mistakes were made and that the results shown by the product are, indeed, correct. Audit requirements are often written such that the product must leave an audit trail. The precise nature of your audit requirements must be negotiated with your own auditors. Naturally, your auditors are stakeholders for your project.

Audit requirements are standard for any product dealing in money or valuables. Their inclusion often results in requirements for the product to retain its records for a given time. It may also mean that the product keeps data on who has accessed what information. The intention of this kind of requirement is that users may not later deny they used the product or had access to its information.

Description: The product shall retain a journal of all transactions for the statutory period.

Rationale: This is required by the auditors.

. . . And No More

Consider the effect of adding ". . . and no more" to all of your requirements. This phrase means that the product must do no more than the requirement specifies. For example, if the requirement is to find a name and address from a file, then the product must not delete or change the name and address after finding them.

Consider this access requirement:

The product shall allow access to authorized users.

The ". . . and no more" heuristic yields a complementary requirement:

The product shall ensure that only authorized users are able to gain access.

For security reasons, you might consider adding an overriding requirement to your specification:

The product shall not do anything except that which has been specified as a requirement.

Sometimes well-meaning product builders make the product perform faster or be bigger than specified, or they add unspecified features. While these properties may be beneficial to a part of the product, they may well have a detrimental effect on the product as a whole or on the security of the product. Use these ideas to ensure that your development team does not build in extra features or properties without first negotiating their inclusion as requirements.

Immunity is also part of the security requirements. Specify requirements for the product to protect itself against malevolent software such as viruses, worms, Trojan horses, and any of the many other variations on the theme of attacking another computer.

Pfleeger, Charles, and Shari Lawrence Pfleeger. Security in Computing (third edition). Prentice Hall, 2002.

Security is important and should be assigned a priority that reflects the value of misusing the product. For example, if your product is for a bank, or if it processes credit card or financial trading transactions, then the value of misuse (in financial terms) is high. Similarly, if your product is intended for the military, then misuse may result in loss of life (perhaps even your own) or loss of a military advantage. Thus, for financial, military, or life-support products, security has a higher priority, and consumes more of the budget, than for many commercial systems.

You should consider calling in a security expert as a consultant stakeholder. Software developers are not usually trained in security, and the security of some functionality and data is so important that the security requirements are best advised by experts.