Analyzing the Security Significance of System Requirements

Safety and security are highly related concepts [1] [2] [3]. Both deal with the protection of valuable assets from harm, and both do this by avoiding, detecting, and responding to incidents that can cause such harm. In both cases, the dangers (hazards and threats respectively) that can cause or enable such incidents to occur are identified and the associated risks are analyzed in order to ensure that these risks are mitigated to acceptable levels. Safety engineering is typically concerned less with requirements than with its downstream activities (e.g., architecting, design, coding, testing) because much of hazard analysis is based on the existence of an architecture, the components of which can cause accidents if they fail. Yet one central safety engineering technique is to categorize the system requirements based on their safety significance and use this categorization to determine the associated level of development processes necessary to assure a corresponding acceptable level of safety risk. Based on the similarity between safety and security, this position paper advocates using a similar process to categorize the security significance of non-security requirements and use this information to ensure that an adequate development process is used to assure an acceptable level of security risk.