10.1.1.137.3255

10.1.1.137.3255 - JOURNAL OF OBJECT TECHNOLOGY Online at...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
J OURNAL OF O BJECT T ECHNOLOGY Online at www.jot.fm . Published by ETH Zurich, Chair of Software Engineering © JOT, 2003 Vol. 2, No. 1, January-February 2003 Cite this column as follows: Donald Firesmith: Engineering Security Requirements , in Journal of Object Technology, vol. 2, no. 1, January-February 2003, pages 53-68. http://www.jot.fm/issues/issue_2003_01/column6 Engineering Security Requirements Donald G. Firesmith , Firesmith Consulting, U.S.A. Abstract Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements. This article defines the different types of security requirements and provides associated examples and guildlines with the intent of enabling requirements engineers to adequately specify security requirements without unnecessarily constraining the security and architecture teams from using the most appropriate security mechanisms for the job. 1 SECURITY REQUIREMENTS The engineering of the requirements for a business, system or software application, component, or (contact, data, or reuse) center involves far more than merely engineering its functional requirements. One must also engineer its quality, data, and interface requirements as well as its architectural, design, implementation, and testing constraints. Whereas some requirements engineers might remember to elicit, analyze, specify, and manage such quality requirements as interoperability, operational availability, performance, portability, reliability, and usability, many are at a loss when it comes to security requirements. Most requirements engineers are not trained at all in security, and the few that have been trained have only been given an overview of security architectural mechanisms such as passwords and encryption rather than in actual security requirements. Thus, the most common problem with security requirements, when they are specified at all, is that they tend to be accidentally replaced with security-specific architectural constraints that may unnecessarily constrain the security team from using the most appropriate security mechanisms for meeting the true underlying security requirements. This article will help you distinquish between security requirements and the mechanisms for achieving them, and will provide you with good examples of each type of security requirement. In today’s world of daily virus alerts, malicious crackers, and the threats of cyber- terrorism, it would be well to remember the following objectives of security requirements:
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
ENGINEERING SECURITY REQUIREMENTS 54 J OURNAL OF OBJECT TECHNOLOGY V OL. 2, NO. 1 Ensure that users and client applications are identified and that their identities are properly verified. Ensure that users and client applications can only access data and services for
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 05/31/2011 for the course ECON 101 taught by Professor Klute during the Spring '11 term at MIT.

Page1 / 16

10.1.1.137.3255 - JOURNAL OF OBJECT TECHNOLOGY Online at...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online