Should security requirements be defined by the organization, or by IT?
The organization and IT must both be involved in defining business security requirements. Architects must understand the business context in order to choose the optimal security controls. For example, only organizational decision makers can define which information should have limited access, and which roles or individuals should be allowed to access it. Once an architect understands the kinds of restrictions the organization wants to place on access to portions of its information, the architect can then recommend the security controls that will help ensure that the information remains secure.
Some security measures are mandated by regulatory bodies. For example, to enforce the privacy aspects of HIPAA (the Health Insurance Portability and Accountability Act), architects need the assistance of subject matter experts and decision makers to understand how an organization intends to comply with the law.
Some security requirements are defined internally by IT. For example, many organizations have security requirements related to sensitive software development procedures, such as preventing fraud or harm when code is migrated into production. Separation of duties would be an appropriate security control for these requirements; it means that a person who develops a piece of code cannot also move that piece of code into the production environment.
In an important form of risk management, you need to prioritize security requirements to determine the appropriate level of security. Project teams should evaluate the likelihood of security threats (such as unauthorized access to data or network resources), identify the appropriate security controls to mitigate the risk, and test early and often to ensure that the controls are established.
Many organizations involve a business risk officer as well as an information security officer in decisions about the appropriate level of security enforcement. Establishing and maintaining security can be costly. For those security requirements not arising from regulation, or to protect health or human safety, risk and security officers may have to make trade-offs between the costs of achieving security and the likelihood of a breach.
Ian Alexander, Gary McGraw, and others explain how to define scenarios that describe how someone might make a system do something it was not intended to do, sometimes without leaving any trace of the hostile action. These scenarios can then be incorporated into penetration testing. Some of these scenarios may be highly technical, but even the most technical scenario must have a business context and must support a business need. Ideally, architects will work with business analysts and organizational decision makers to define these kinds of scenarios. In doing so, they will often uncover additional business-based security requirements.
 Sometimes these scenarios are called “misuse cases” or “abuse cases,” although both these terms have also been used by others — in the past — to refer to badly written use cases. The term “misuse cases” seems to have taken hold. See http://www.owasp.org/index.php/Detail_misuse_cases. The initiating actor in misuse cases is often called “the hostile user” or “the attacker.”
This was first published in April 2011