Combining Security and Privacy in Requirements Engineering

Background

Security requirements engineering (Mead, Hough, & Stehney, 2005) aims to identify software security risks in early stages of the design process. Privacy requirements engineering (Chiasera, Casati, Daniel, & Velegrakis, 2008) serves to identify privacy risks early in the design process. Recent research studies (Peeger & Peeger, 2009) have shown that privacy requirements engineering is less mature than security engineering and that underlying engineering principles give little attention to privacy requirements. In addition, (Adams & Sasse, 2001) claim that most of the privacy disclosures happen due to defects in the design, and are not the result of an intentional attack. Therefore, although security and privacy risks overlap, relying merely on protecting the security of users does not necessarily imply the protection of their privacy. For instance, health records can be secured from various types of intrusions; however, the security of such assets does not guarantee that the privacy of patients is secure. The security of such records does not protect against improper authorized access or disclosure of records. SQUARE generates categorized and prioritized security requirements following these nine steps (Mead et al., 2005):