ANSWER

SQUARE stands for Security Quality Requirements Engineering.  It is a requirements engineering process developed by Carnegie Mellon University’s Software Engineering Institute (SEI) which focuses on eliciting and documenting security requirements.  Since security requirements are often not given the focus that they deserve and since trying to incorporate security requirements later in the software development lifecycle costs more than planning for them upfront, the SEI developed a nine-step process to ensure that quality security requirements can be gathered, categorized, prioritized, and validated early on in the software development lifecycle.  These nine steps are:

1. Agree on definitions – There are a lot of security related terms that can be ambiguous or interpreted multiple ways.  Therefore, the team should start by creating a list of those terms which will be used during discussions and requirements elicitation meetings.  Each term and its definition should be documented and communicated to the group.  A few examples might be access control, denial-of-service attack, integrity, spoof, SQL injection, vulnerability, and worm.
   
2. Identify security goals – Security goals are statements that reflect high level goals of the business and stakeholders regarding the security of the system.  In addition to being at a higher level that security requirements, they tend to be broader in interpretation and are often less testable.  Each security goal later leads to one or more security requirements. An example of a security goal might be “the confidentiality of personnel records must be maintained”.
   
3. Develop artifacts – Various system artifacts should be collected and developed which support the SQUARE process.  These include system architecture diagrams, use cases and use case diagrams, misuse case diagrams, attack trees, etc.
   
4. Perform risk assessment – Identify the system threats that exist and determine how likely they are to materialize.  Additionally, if they were to materialize what are the potential consequences of such an attack.  This provides the rationale for countermeasures that are developed later and aids in the prioritization of security requirements.
   
5. Select elicitation techniques – Determine which requirements elicitation techniques will work best for the given system, project team, and project environment.
   
6. Elicit security requirements – Elicit and document measurable and verifiable security requirements.
   
7. Categorize requirements – SQUARE categorizes each security requirement into categories such as Essential System Level, Non-Essential System Level, Essential Software Level, Non-Essential Software Level, Architectural Constraint
   
8. Prioritize requirements – Due to lack of resources, time or changes in project goals, not all requirements make sense to implement.  The project team must evaluate and prioritize each requirement based on all of the information know about it, including the risk assessment of the associated threat.
   
9. Inspect requirements – The final step is to inspect the requirements to ensure that they are accurate and verifiable.  The goal of the inspection step is to remove any ambiguities, inconsistencies, or mistaken assumptions within the requirements.  The formality of this inspection may vary from Fagen Inspections to peer reviews of the requirements.