What is SQUARE?
Security Quality Requirements Engineering (SQUARE) was created by the experts from Carnegie Mellon University and the Software Engineering Institute (SEI). This process offers a means for eliciting, categorizing and prioritizing security requirements for systems and applications. It aims at integrating security considerations at the earliest stages of the development process. It helps to document and analyze all security aspects and advise on future improvements and modifications for the analyzed systems.
SQUARE steps
Several steps (nine) can be defined in the SQUARE process, each of which identifies particular inputs, participants, advised techniques and the final output (which can serve as an input for the following step, however, some steps can be performed in parallel). They are the following:
- Agreement on definitions. It is necessary to agree on terminology and definitions to avoid misunderstandings, multiplying meanings and ambiguity in detail. The list of terms includes definitions for each term and its corresponding sources. Finally, among the range one of the definitions for each term is agreed on.
- Security goals identification. At this stage a set of prioritized goals is stated. Otherwise it will be impossible to set up the priority and relevance of the security requirements. At the end of the step no conflicting goals should be left and the team should end up with just one business goal (combined with several security goals).
- Developing artifacts. It is needed to support the security requirements definition. It includes collecting particular types of artifacts, such as the system’s architecture diagrams, use case and misuse case scenarios, attack trees and standardized templates and forms. It is important to get a complete understanding of the project.
- Performing risk assessment. At this step identification of vulnerabilities and threats which the system can encounter and evaluation of the possibility of those threats being involved in actual attacks and the potential outcomes of these attacks take place. It also helps to prioritize security requirements and categorize the threats according to their likelihood.
- Elicitation technique selection. At this step an elicitation technique, which suits the project, is chosen (such as structured interviews, critical discourse analysis, feature-oriented domain analysis, use/misuse cases, quality function deployment, etc.). Several techniques may be suitable for one project.
- Elicit security requirements. This step is supposed to be the key one within the whole process. It is not that hard, as long as most elicitation techniques provide corresponding guidance. However, the team should avoid eliciting vague, ambiguous or ‘stiff’, non-variable requirements. These will be relatively easy to verify when the project is implemented. On the other hand, it is necessary not to confuse implementations and architectural constraints with actual requirements (it is necessary to decide what the system is supposed to do, not how).
- Requirements categorization. At this stage requirements are categorized (as essential, non-essential, system-level, software-level and architectural constraints). As it was already mentioned above, it is necessary to avoid producing architectural constraints.
- Requirements prioritizing. It is not always possible to cover everything and implement every requirement (due to time shortage, lack of resources, etc.), so at this stage of the process the order of the implementation is set up, according to the priority. During the prioritization process some requirements may seem unfeasible, so the team has a choice to dismiss or postpone them.
- Requirements inspection. The final step is one of (if not the most) important elements of the process. Its goal is to find defects in the requirements (which are ambiguities, inconsistencies and mistaken assumptions). Each enlisted requirement should be verified as applicable to the security goals of the project or support another higher-level requirement. In the end, after the process is complete, a security requirement document is produced and handed out.
Conclusion
In any development process, security, functionality and efficiency are crucial, but the goal is hard to reach without mutual agreement on the terms and requirements. Producing an accurate set of requirements and goal prioritizing, what the system or application must do and how, and how the developing team should act to increase security and to avoid mistakes and ambiguity is a critical factor for making projects better, more efficient and secure.
About SmartState
Launched in 2019 and based in Dubai, SmartState is one of the leading DeFi security auditing firms. We conduct security tests and check the code core, smart contracts and blockchain for all types of errors, vulnerabilities and other issues.
Although SmartState gave a start to operations with smart contract auditing of DLT-projects, from the very beginning, we made our services surpass the classic purview of smart contract audit and security testing. We specialize in manual testing, so the SmartState’s tech team of white-hat security professionals measure up a project’s git and offer guidelines and recommendations for its further advancement. Security audit reports review the threats and vulnerabilities with which codebases may be exploited in the future, as the network achieves scalability and expands to accommodate more use cases and functionality.
Stay tuned and find more about us and what we provide on our:
