Security requirements are nonfunctional requirements that strongly influence the architectural design of software systems.
Security requirements and other requirements can conflict with one another. A common example is that security and usability are often at odds with one another, and a balance between the two must be found. Therefore you have to determine how secure do you want it vs how easy should it be to use.
Consider a wireless router. It’s easier to not have to set a password, but it’s not safe at all. Vs. a 16 digit password, with a daily changing pin that has to be entered to access – much more secure, but highly unusable.
Knowing about attack patterns (phishing, SQL injection, cross site scripting as examples) can make it easier to determine what/how to respond with secure methods.
A security model is a formal description of software system security policy. A security model needs to capture the following items: (1) security policy objectives, (2) external interface requirements, (3) software security requirements, (4) rules of operation, and (5) specifications describing model-system correspondence.
To be secure, software must exhibit three properties: dependability (operates under hostile conditions), trustworthiness (system will not behave in a malicious manner), and survivability (continues to operate when compromised).
Security metrics and measures need to focus on assessing these properties.
Threat modeling is a security analysis method that can be used to identify those threats with the highest potential to cause damage to a software-based system. Threat modeling should be done in the earliest phases of a project using the requirements and analysis models.
Building a system and making it secure after the fact is highly inefficient and prone to failure.
Security Analysis was originally found on Access 2 Learn
