## 6 Case Study
### Case MFA  
The projects in the CS department ranged from individual research and collaborations for papers to third-party-funded research and classified projects with industry partners. The department operated some kind of project management software, such as Jira, and a versioning system, for example, GitLab. Even though only rudimentary risk management was enabled (risks were known and partly mitigated, but not monetary quantified), the risk of incidents with, and without, MFA was regarded. As a result, the questions were \"Should we improve the security with MFA?\" and \"If so, how should we introduce MFA?\". The business goals and decisions are based on business risks. These depend on, for example, the organizational structure of projects, regulations for classified projects, and, consequently, costs of incidents. As a result, different groups (professors, project managers, system administrators, and project members among others) exist, as shown in Figure 6. Green corresponds to OK, orange represents a lower threat, orange to red is a medium threat, red shows a higher threat, and blue indicates that it is not used. The security controls were adapted from NIST SP 800-53 and 800-63. Regarding the layers of SABSA, we see the following. **Contextual Layer:**: First, stakeholders, policies, and processes for authentication and MFA were identified. In addition, the role concept and required trust were outlined. Figure 6: User groups per infrastructure group. The CS department had a role concept but it frequently changed with the different assignments to projects. As the role concept was not up-to-date, a hierarchical concept for updating and verifying it was introduced. **Conceptual Layer:**: MFA exists in different variants (architectures, factors, vendors, etc.). Either way, additional factors should increase security, which is possible with appropriate monitoring and independency of factors. In order to decide on the actual implementation, the different variants were outlined and discussed. **Logical Layer:**: The assets relate to the data, identities, and the relation between them. Privileges should be only granted if necessary for work. In consequence, trust in the users must be as high as required by the data. While most projects, courses, and theses only need a normal level, classified projects and specific servers are much more restricted with a high level of trust and a limited user group. **Physical Layer:**: So far, a self-service portal exists, where users can edit their profiles, request certificates, and more. This self-service portal could be adapted to manage further devices required for MFA. In addition, a user interface, either per application or as a central element, is required. Here, usability is an important issue, as people try to bypass security measures if they feel these are a burden. Consequently, increasing security might even result in the opposite. Last, but not least, the security of each variant with its components was analyzed. TOTP seemed like a good variant of MFA as the users can decide between smartphone apps and password managers with the functionality, among others. On the other hand, the employees might request employer-provided smartphones, which, in consequence, need to be managed as well. **Component Layer:**: Here, the functions and components were evaluated. Jira, for example, integrated with GitLab used for versioning. Both web applications can require MFA in form of TOTP. In contrast, using \(git\) on the command line does not enable it. In addition, with TOTP, smartphones for the corresponding employees and their management were discussed. The stakeholders came to the conclusion that only professors, project managers, and members of classified projects (see red color in Figure 6), as well as administrators, required MFA. The consequences of rolling it out on all employees would be higher costs and effort (service desk and device management among others).