Nowadays, the use of agile software development methods like Scrum is common in industry and academia. Considering the current attacking landscape, it is clear that developing secure software should be a main concern in all software development projects. In traditional software projects, security issues require detailed planning in an initial planning phase, typically resulting in a detailed security analysis (e.g., threat and risk analysis), a security architecture, and instructions for security implementation (e.g., specification of key sizes and cryptographic algorithms to use). Agile software development methods like Scrum are known for reducing the initial planning phases (e.g., sprint 0 in Scrum) and for focusing more on producing running code. Scrum is also known for allowing fast adaption of the emerging software to changes of customer wishes. For security, this means that it is likely that there are no detailed security architecture or security implementation instructions from the start of the project. It also means that a lot of design decisions will be made during the runtime of the project. Hence, to address security in Scrum, it is necessary to consider security issues throughout the whole software development process. Secure Scrum is a variation of the Scrum framework with special focus on the development of secure software throughout the whole software development process. It puts emphasis on implementation of security related issues without the need of changing the underlying Scrum process or influencing team dynamics. Secure Scrum allows even non- security experts to spot security issues, to implement security features, and to verify implementations. A field test of Secure Scrum shows that the security level of software developed using Secure Scrum is higher then the security level of software developed using standard Scrum.
S-Scrum @cite_6 is a security enhanced version of Scrum . It modifies the Scrum process by inserting so called spikes. A spike contains analysis, design and verification related to security concerns. Further, requirements engineering (RE) in story gathering takes effect on this process. For this, the authors describe to use tools like Misuse Stories @cite_1 . This approach is very formalistic and needs lot of changes to standard Scrum, hence hinders deployment in environments already using Scrum. Secure Scrum in contrast does not change standard Scrum.
@cite_1 @cite_6
2153177282 1563103026
Use case diagrams (L. , 1992) have proven quite helpful in requirements engineering, both for eliciting requirements and getting a better overview of requirements already stated. However, not all kinds of requirements are equally well supported by use case diagrams. They are good for functional requirements, but poorer at e.g., security requirements, which often concentrate on what should not happen in the system. With the advent of e- and m-commerce applications, security requirements are growing in importance, also for quite simple applications where a short lead time is important. Thus, it would be interesting to look into the possibility for applying use cases on this arena. The paper suggests how this can be done, extending the diagrams with misuse cases. This new construct makes it possible to represent actions that the system should prevent, together with those actions which it should support. To care for security in early stages of software development has always been a major engineering trend. However, due to the existence of unpreventable and accidental security faults within the system, it is not always possible to entirely identify and mitigate the security threats. This may eventually lead to security failure of the target system. To avoid security failure, it is required to incorporate fault tolerance (i.e. intrusion tolerant) into the security requirements of the system. In this paper, we propose a new technique toward description of security requirements of Intrusion Tolerant Systems (ITS) using fuzzy logic. We care for intrusion tolerance in security requirements of the system through considering partial satisfaction of security goals. This partiality is accepted and formally described through establishment of a Goal-Based Fuzzy Grammar (GFG) and its respective Goal-Based Fuzzy Language (GFL) for describing Security Requirement Model (SRM) of the target ITS.