Definition:

IT Security Requirements describe functional and non-functional requirements that need to be satisfied in order to achieve the security attributes of an IT system.

Type of security requirements:

Security requirements can be formulated on different abstraction levels. At the highest abstraction level they basically just reflect security objectives. An example of a security objectives could be "The system must maintain the confidentially of all data that is classified as confidential".

More useful for a SW architect or a system designer are however security requirements that describe more concretely what must be done to assure the security of a system and its data. OSA suggests to distinguish 4 different security requirement types:

• Secure Functional Requirements, this is a security related description that is integrated into each functional requirement. Typically this also says what shall not happen. This requirement artifact can for example be derived from misuse cases
• Functional Security Requirements, these are security services that needs to be achieved by the system under inspection. Examples could be authentication, authorization, backup, server-clustering, etc. This requirement artifact can be derived from best practices, policies, and regulations.
• Non-Functional Security Requirements, these are security related architectural requirements, like "robusteness" or "minimal performance and scalability". This requirement type is typically derived from architectural principals and good practice standards.
• Secure Development Requirements, these requirements describe required activities during system development which assure that the outcome is not subject to vulnerabilities. Examples could be "data classification", "coding guidelines" or "test methodology". These requirements are derived from corresponding best practice frameworks like "CLASP".

Taxonomy

References

• A good overview on the topic of security requirements can be found in the State of the Art Report (SOAR) on Software Security Assurance.
• In the 2008 Jan/Feb special issue on security of the IEEE Software magazine, the authors present their analysis of current IT security requirements literature.
• The most comprehensive framework on IT security requirements is currently the SQUARE method presented by the SEI of Carnegie Mellon University.

This article derives a definition for IT Security Architecture by combining the suggestions from the previous articles.

In this article we discuss how the evolution of design patterns has shaped the prevalent understanding of security patterns. We then analyse that particularly in the area of security the best practices are also manifested in other ways than only design patterns (e.g. Standard of Good Practice, Security Principles, and Control Catalogues). Finally we conclude that combining the idea of a structured controls catalogue and design patterns (as proposed by OSA) is particularly appealing and helps both the designer as well as the quality assuror and auditor.

History of Design Patterns

The history of design patterns started with the seminal book “A Pattern Language” [1],[2] written in 1977 by Christopher Alexander a professor for architecture in Berkley. The ideas of Alexander were translated into the area of software design by several authors, among them Kent Beck, Ward Cunningham and later Erich Gamma et al. It is interesting to note that Christopher Alexander himself sees the evolution of the design pattern idea in the software development community much more critical than most of software design pattern experts do.
The following is an excerpt of the foreword Alexander wrote for the pattern book of Richard Gabriel:
In architecture, the question I have been asking is very simple: “Can we do better? Does all this talk help to make better buildings?.... Do the people who write these programs, using alexandrian patterns, or any other methods, do they do better work? Are the programs better? Do they get better results, more efficiently, more speedily, more profoundly? Do people actually feel more alive when using them? Is what is accomplished by these programs, and by the people who run these programs and by the people who are affected by them, better, more elevated, more insightful, better by ordinary spiritual standards?"

Today we find patterns for many different areas in IT such as design patterns, architectural patterns and interaction design patterns but also security patterns. All these patterns use very similar pattern languages. It is interesting to observe how close all these pattern languages stick to the original language proposed by Christopher Alexander.

Definitions

The below two citations are only samples, the former discusses the derivation of a design pattern and the latter discusses the structure of a design pattern.
Developer.Yahoo
Patterns are optimal solutions to common problems. As common problems are tossed around a community and are resolved, common solutions often spontaneously emerge. Eventually, the best of these rise above the din and self-identify and become refined until they reach the status of a Design Pattern.

Wiki
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

Let us assume that the notion of "design pattern" can be translated directly to IT security, for example: "A security pattern is a general reusable solution to a commonly occurring problem in creating and maintaining secure information systems". It is then interesting to see how security design patterns can be combined with other ways to describe best practices for securing information systems. Both NIST 800-53 as well as ISO 27001 are best practices that describe technical, organizational as well process controls. While both of them are far more complete than any of the security pattern collections that can be found on the web [3],[4], neither of them leverages the power of visually illustrated design patterns. In the Open Security Architecture community we try to improve the expression power of best practice standards by combining them with visually illustrated (design) patterns.

References

[1] http://en.wikipedia.org/wiki/A_Pattern_Language
[2] http://natureoforder.com/library/scientific-introduction.pdf
[3] http://www.opengroup.org/security/gsp.htm
[4] http://www.securitypatterns.org

Rarely one can find a risk related discussion that is specific to IT risks and that reaches beyond IT Security. This is rather surprising given that most business processes today rely heavily on IT and that risk management is a hot topic in corporate governance as well as a major source of business for compliance consultants.

In this article we look at typical definitions of risk and then inspect what types of risks occur in the IT risk landscape. In the last section we look into the perception of risk, and consider where we can often find blind spots.