Security Patterns Repository

Patterns

all | design | requirement | architectural | implementation | procedural

(source: SBHBS06)

In some cases a modest level of I&A is needed when a preceding registration step is not possible or not cost-effective. A common approach in these cases is to use ‘func- tional’ information about the person, that is, information that was acquired in the normal course of business. Such information usually includes both public items, such as name or e-mail address, and private items or secrets, such as the individual’s mother’s maiden name. This pattern helps you to define the requirements for I&A when pre-registration is not used.

(source: SW07)

Use the user authentication requirement pattern to specify that a person must make their identity known to the system before they can access anything non-public or anything for which they cannot remain anonymous (in short, anthing for which they must log in).

(source: SW07)

Use the user registration requirement pattern to specify how new users are registered (set up in the system), with emphasis on capturing those details by which a user can later be authenticated (log in).

(source: KETEH01)

The Validated Transaction pattern puts all of the security-relevant validation for a specific transaction into one page request. A developer can create any number of supporting pages without having to worry about attackers using them to circumvent security. And users can navigate freely among the pages, filling in different sections in whatever order they choose. The transaction itself will ensure the integrity of all information submitted.

(source: SBHBS06)

A vulnerability is a weakness that could be exploited by a threat, causing the violation of an asset’s security property. Conducting an enterprise vulnerability assessment helps to identify the weaknesses of the enterprise’s assets and the systems that enable access to them, and evaluates the severity if a vulnerability were to be exploited.