Security Patterns Repository

Patterns

all | design | requirement | architectural | implementation | procedural

(source: KE01)

Many Web compromises and defacements occur because of unnecessary and potentially vulnerable services present on the Web server. Default installations of many operating systems and applications are the source of many of these services. This pattern advocates building the server from the ground up: understanding the default installation of the operating system and applications, simplifying the configuration as much as possible, removing any unnecessary services, and investigating the vulnerable services that are a part of the Web server configuration.

(source: KE01)

Many security problems can be avoided during system design if components, languages, and tools are selected with security in mind. This is not to say that security is the only criterion of concern – merely that it should not be ignored while making these decisions. This pattern provides guidance in selecting appropriate Commercial-Off-the-Shelf components and in deciding whether to use build custom components.

(source: KE01)

In order for developers to make consistent, intelligent development choices regarding security, they have to understand the overall system goals and the business case behind them. If the security goals are not documented and disseminated, individual interpretation could lead to inconsistent policies and inappropriate mechanisms.

(source: KE01)

Web servers and application servers are extremely complex, and complexity is a major impediment to security. In order to help manage the complexity of Web server and application configurations, developers and administrators must document the initial configuration and all modifications to Web servers and applications.

(source: KE01)

When enrolling users for a Web site or service, sometimes it is necessary to be used to establish a shared secret, which can then be used to establish identity during enrollment. validate identity using an out-of-band channel, such as postal mail, telephone, or even face-to-face authentication. The out-of-band channel can

(source: KE01)

When enrolling users for a Web site or service, it is always easier to allow some other party to take on the difficult task of authenticating user identity. When a third-party service is available and sufficiently reliable, the Web application can offload this task on the third party. This approach is becoming more common as third-party services become available. The most common form of transaction authentication—credit card authentication—is a form of third-party validation.

(source: KE01)

When enrolling users for a Web site or service, sometimes it is sufficient to validate identity using a pre-existing shared secret, such as a social security number or birthday. The use of a pre-existing shared secret enables enrollment without prior communication specific to setting up an account.

(source: KE01)

When enrolling users for a Web site or service, sometimes it is not necessary to validate the identity of the enrolling user. When there is no initial value involved in the Web site or service for which enrollment is occurring, validation is an unnecessary procedure and can be eliminated.

(source: KE01)

Applications and components offer a variety of capabilities to log events that are of interest to administrators and other users. If used properly, these logs can help ensure user accountability and provide warning of possible security violations. The Log for Audit pattern ties logging to auditing, to ensure that logging is configured with audit in mind and that auditing is understood to be integral to effective logging.