Modeling Secure Systems and Security Guarantees
In KASTEL, methods for eliciting and analyzing security requirements for a system under development are explored. One of the major goals of this research is to make the security of a system under development as transparent as possible, i.e., one should easily see that the final implementation fulfills the various security requirements.
For that matter, a method that facilitates describing the process from the ambiguous security requirements of the various stakeholders to the manageable technical requirements of the system under development has been designed and investigated.
This method was applied for analyzing the security requirements of firewalls. This led to the development of a prototypical implementation for this use case.
When eliciting and realizing security requirements, not only technical requirements arise but also requirements relating to the legal certainty and social acceptability of technical implementations. Therefore, the afore-mentioned method demands that legal issues are taken into account already during requirements elicitation.
Furthermore, it was explored how to align the guarantees given by the various sub-fields of computer science. This research is motivated by the fact that typically many experts from different sub-fields are collaborating in the development of complex technical systems. Ultimately, each expert provides guarantees for a particular aspect of the system. However, it should be clear to all experts what the various guarantees given by them imply for the security of the system as a whole.
Identifying Security Requirements
When developing a technical system, one must take into account the requirements of the various stakeholders. In particular, the various security requirements have to be fulfilled. However, already the elictaton and analysis of system requirements has proven to be difficult. For instance, there can be conflicts among the various requirements elicited. The various trade-offs that might arise have to be identified in this case.
Identifying the security requirements of complex systems is a particularly delicate task. New methods are required here. Therefore, new methods for identifying and analyzing security requirements are being developed and explored in KASTEL.
In this context, a major challenge is to make the security of the system as transparent as possible for all stakeholders, i.e., a stakeholder should easily see that the implementation fulfills the various security requirements. Furthermore, the technical experts involved in the development of the system should also understand what the various security guarantees given by them imply for the security of the system as a whole.
Decomposing Ambiguous Security Requirements into Manageable Security Requirement
The requirements expressed by the stakeholders are generally too ambiguous for a technical implementation. Therefore, a model was developed for describing the process from the security requirements of the stakeholders to the precise technical requirements of the system under development.
In this model, one starts from the assets of a stakeholder. Assets are resources that are of some particular (tangible or intangible) value for a stakeholder. A stakeholder's assets can be potentially harmed by the system under development. This leads to the notion of softgoals. Softgoals specify which property of a particular asset must be preserved. For instance, a stakeholder can demand that his personal data are
kept secret. The notion of softgoals is used to model the phase of requirements elicitation, where the various security requirements of the stakeholders are identified. Here, it is assumed that stakeholders, being technical laymen, can phrase their requirements only in the form of softgoals, i.e. in the form
Property Y of asset X must preserved.
As softgoals are expressed using an informal language, it is difficult to directly implement them in a technical system. For that reason, the notion of hardgoals was introduced. Hardgoals are defined as necessary conditions for the system under development with respect to the elicited softgoals. For example, the requirement
Communication must be confidential! is a hardgoal with respect to the softgoal
Data must be kept secret! and with respect to the mechanism
Data transmission (that belongs to the functional specifications of the system under development). Since hardgoals are expressed as precise requirements for a system under development, they are easier to implement and verify.
Application: Secure Firewalls
The requirements for firewalls were analyzed in KASTEL using the above-mentioned model. Motivated by current developments, it was explored how a secure firewall can be constructed from multiple untrusted firewalls. In collaboration with partners from the industry and the FZI Research Center for Information Technology Karlsruhe, a prototype was developed and presented at CEBIT 2014. This prototype can be currently found at the FZI House of Living Labs.
To incorporate requirements originating from legal issues, the above-mentioned model considers the legislator as an additional stakeholder who takes part in the requirements elicitation phase introducing legal requirements. A common base for softgoals and laws is provided by the notion of assets introduced above. Like softgoals, laws also originate from specific assets that are to be protected. Contrary to softgoals, laws cannot be modified so as to resolve conflicts with other softgoals, however. For this reason, the notion of obligations was introduced. Obligations are non-negotiable requirements that are defined on the same level of abstraction as softgoals.
Decomposing Manageable Security Requirements into Subfield-specific Problems
Identified hardgoals can only be fulfilled by combining the methods and technologies from different sub-fields of computer science. For this reason, KASTEL has developed a method for decomposing hardgoals into sub-field-specific problems. This decomposition is based on the observation that each sub-field can be characterized by means of so-called ``separating assumptions''. Such assumptions are essential for the applicability and security of a sub-field's mechanisms, but the underlying research questions are not addressed by this sub-field. Separating assumptions define the boundaries between sub-fields. They describe questions which a sub-field factors out. These assumptions can also be considered as hardgoals which have to be addressed by another sub-field. Thus, a separating assumption of a sub-field relies on the existence and security of mechanisms from another sub-field.
Hardgoals (including the ones implied by separating assumptions) are fulfilled by so-called black box mechanisms. A black box mechanism is viewed as a
black box from the perspective of other sub-fields, i.e., a place holder for a class of mechanisms satisfying the considered hardgoal. The specific form of this mechanism must be specified by the respective experts. Typically, a black box mechanism implies further hardgoals due to the various separating assumptions made for this mechanism. All separating assumptions must be explicitly documented in order to make the security of a system comprehensible and verifiable at any time.
First instantiations of this decomposition scheme comprise use cases from the areas of cloud computing and smart video surveillance (see illustration for the use case from the area of cloud computing).