Architectural Data Flow Analysis for Detecting Violations of Confidentiality Requirements

Diese Arbeit präsentiert einen Ansatz zur systematischen Berücksichtigung von Vertraulichkeitsanforderungen in Softwarearchitekturen mittels Abbildung und Analyse von Datenflüssen.

Die Stärkung von Datenschutzregularien, wie bspw. durch die europäische Datenschutzgrundverordnung (DSGVO), und die Reaktionen der Bevölkerung auf Datenskandale, wie bspw. den Skandal um Cambridge Analytica, haben gezeigt, dass die Wahrung von Vertraulichkeit für Organisationen von essentieller Bedeutung ist. Um Vertraulichkeit zu wahren, muss diese während des gesamten Softwareentwicklungsprozesses berücksichtigt werden. ... mehrFrühe Entwicklungsphasen benötigen hier insbesondere große Beachtung, weil ein beträchtlicher Anteil an späteren Problemen auf Fehler in diesen frühen Entwicklungsphasen zurückzuführen ist. Hinzu kommt, dass der Aufwand zum Beseitigen von Fehlern aus der Softwarearchitektur in späteren Entwicklungsphasen überproportional steigt. Um Verletzungen von Vertraulichkeitsanforderungen zu erkennen, werden in früheren Entwicklungsphasen häufig datenorientierte Dokumentationen der Softwaresysteme verwendet. Dies kommt daher, dass die Untersuchung einer solchen Verletzung häufig erfordert, Datenflüssen zu folgen.

Datenflussdiagramme (DFDs) werden gerne genutzt, um Sicherheit im Allgemeinen und Vertraulichkeit im Speziellen zu untersuchen. Allerdings sind reine DFDs noch nicht ausreichend, um darauf aufbauende Analysen zu formalisieren und zu automatisieren. Stattdessen müssen DFDs oder auch andere Architekturbeschreibungssprachen (ADLs) erweitert werden, um die zur Untersuchung von Vertraulichkeit notwendigen Informationen repräsentieren zu können. Solche Erweiterungen unterstützen häufig nur Vertraulichkeitsanforderungen für genau einen Vertraulichkeitsmechanismus wie etwa Zugriffskontrolle. Eine Kombination von Mechanismen unterstützen solche auf einen einzigen Zweck fokussierten Erweiterungen nicht, was deren Ausdrucksmächtigkeit einschränkt. Möchte ein Softwarearchitekt oder eine Softwarearchitektin den eingesetzten Vertraulichkeitsmechanismus wechseln, muss er oder sie auch die ADL wechseln, was mit hohem Aufwand für das erneute Modellieren der Softwarearchitektur einhergeht. Darüber hinaus bieten viele Analyseansätze keine Integration in bestehende ADLs und Entwicklungsprozesse. Ein systematischer Einsatz eines solchen Ansatzes wird dadurch deutlich erschwert.

Existierende, datenorientierte Ansätze bauen entweder stark auf manuelle Aktivitäten und hohe Expertise oder unterstützen nicht die gleichzeitige Repräsentation von Zugriffs- und Informationsflusskontrolle, sowie Verschlüsselung im selben Artefakt zur Architekturspezifikation. Weil die genannten Vertraulichkeitsmechanismen am verbreitetsten sind, ist es wahrscheinlich, dass Softwarearchitekten und Softwarearchitektinnen an der Nutzung all dieser Mechanismen interessiert sind. Die erwähnten, manuellen Tätigkeiten umfassen u.a. die Identifikation von Verletzungen mittels Inspektionen und das Nachverfolgen von Daten durch das System. Beide Tätigkeiten benötigen ein beträchtliches Maß an Erfahrung im Bereich Vertraulichkeit.

Wir adressieren in dieser Arbeit die zuvor genannten Probleme mittels vier Beiträgen: Zuerst präsentieren wir eine Erweiterung der DFD-Syntax, durch die die zur Untersuchung von Zugriffs- und Informationsflusskontrolle, sowie Verschlüsselung notwendigen Informationen mittels Eigenschaften und Verhaltensbeschreibungen innerhalb des selben Artefakts zur Architekturspezifikation ausgedrückt werden können. Zweitens stellen wir eine Semantik dieser erweiterten DFD-Syntax vor, die das Verhalten von DFDs über die Ausbreitung von Attributen (engl.: label propagation) formalisiert und damit eine automatisierte Rückverfolgung von Daten ermöglicht. Drittens präsentieren wir Analysedefinitionen, die basierend auf der DFD-Syntax und -Semantik Verletzungen von Vertraulichkeitsanforderungen identifizieren kann. Die unterstützten Vertraulichkeitsanforderungen decken die wichtigsten Varianten von Zugriffs- und Informationsflusskontrolle, sowie Verschlüsselung ab. Viertens stellen wir einen Leitfaden zur Integration des Rahmenwerks für datenorientierte Analysen in bestehende ADLs und deren zugehörige Entwicklungsprozesse vor. Das Rahmenwerk besteht aus den vorherigen drei Beiträgen.

Die Validierung der Ausdrucksmächtigkeit, der Ergebnisqualität und des Modellierungsaufwands unserer Beiträge erfolgt fallstudienbasiert auf siebzehn Fallstudiensystemen. Die Fallstudiensysteme stammen größtenteils aus verwandten Arbeiten und decken fünf Arten von Zugriffskontrollanforderungen, vier Arten von Informationsflussanforderungen, zwei Arten von Verschlüsselung und Anforderungen einer Kombination beider Vertraulichkeitsmechanismen ab. Wir haben die Ausdrucksmächtigkeit der DFD-Syntax, sowie der mittels des Integrationsleitfadens erstellten ADLs validiert und konnten alle außer ein Fallstudiensystem repräsentieren. Wir konnten außerdem die Vertraulichkeitsanforderungen von sechzehn Fallstudiensystemen mittels unserer Analysedefinitionen repräsentieren. Die DFD-basierten, sowie die ADL-basierten Analysen lieferten die erwarteten Ergebnisse, was eine hohe Ergebnisqualität bedeutet. Den Modellierungsaufwand in den erweiterten ADLs validierten wir sowohl für das Hinzufügen, als auch das Wechseln eines Vertraulichkeitsmechanismus bei einer bestehenden Softwarearchitektur. In beiden Validierungen konnten wir zeigen, dass die ADL-Integrationen Modellierungsaufwand einsparen, indem beträchtliche Teile bestehender Softwarearchitekturen wiederverwendet werden können.

Von unseren Beiträgen profitieren Softwarearchitekten durch gesteigerte Flexibilität bei der Auswahl von Vertraulichkeitsmechanismen, sowie beim Wechsel zwischen diesen Mechanismen. Die frühe Identifikation von Vertraulichkeitsverletzungen verringert darüber hinaus den Aufwand zum Beheben der zugrundeliegenden Probleme.

This thesis presents an approach to systematically consider confidentiality requirements in software architectures by representing and analyzing data flows.

The strengthening of data protection regulations such as the European General Data Protection Regulation (GDPR) and the reactions of people to data breaches such as the Cambridge Analytica scandal have shown that ensuring confidentiality in software systems is vital for organizations. To ensure confidentiality, it is necessary to consider confidentiality during the whole development process. Especially, early development phases require attention because a considerable amount of issues traces back to issues introduced in these early phases. ... mehrAdditionally, the effort for fixing issues originating from the software architecture increases disproportionately high in later development phases. Data-oriented representations of software systems are popular for detecting violations of confidentiality requirements in early development phases because investigating a violation often requires following the data flow.

Data flow diagrams (DFDs) are commonly used to reason about security in general and confidentiality in particular but plain {DFDs are not sufficient to formalize and automate DFD-based analyses. Instead, DFDs and other Architectural Description Languages (ADLs) need extensions to represent the information required to reason about confidentiality. These extensions often only focus on confidentiality requirements given in terms of one particular confidentiality mechanism such as access control. The resulting single purpose approaches do not support combined mechanisms, which lowers their expressiveness. If the software architect changes the confidentiality mechanism, it is necessary to switch to an ADL supporting that mechanism, which implies a high effort for describing existing architectures in the new ADL. In addition, many analysis approaches do not provide an integration into existing ADLs and development processes, which impedes systematic application of the approaches.

Existing data-oriented approaches either considerably rely on manual activities and high expertise or do not support access control, information flow control and encryption within the same specification artifact. These three confidentiality mechanisms are the most commonly used ones, so it is likely that software architects are interested in using all of them. The manual activities include the identification of violations by inspections and the tracing of data through the system. Both require a considerable expertise in confidentiality.

In this thesis, we address the previously mentioned problems by four contributions: First, we present an extension of the DFD syntax, which represents the required information to reason about access control and information flow control combined with encryption by properties and behaviors within the same specification artifact. Second, the semantics for the extended DFD syntax formalize the behavior of DFDs by label propagation, which supports tracing data automatically. Third, a set of analysis definitions based on the DFD syntax and semantics identifies violations of confidentiality requirements given in terms of the most important variants of access control, information flow control and encryption. Fourth, integration guidelines describe how to use the data-oriented analysis framework given by the previous three contributions together with existing ADLs and their corresponding development processes.

We validated the expressiveness, result quality and modeling effort of our contributions in case studies on seventeen case study systems. The case study systems mostly stem from related work and cover five types of access control requirements, four types of information flow control requirements, two types of encryption and one combination of access control and information flow control. We validated the expressiveness of the DFD syntax as well as of two extended ADLs resulting from applying the integration guidelines and could express all but one case study system. We could also express the confidentiality requirements from sixteen case study systems by the provided analysis definitions. The DFD-based as well as the ADL-based analyses only reported expected results, so the result quality was high. We validated the modeling effort in the extended ADLs for adding and switching a confidentiality mechanism for an existing software architecture. In both validations, we could show that the ADL integrations save modeling effort by supporting the reuse of considerable parts of existing software architectures.

Software architects profit from the increased flexibility in choosing and the lowered effort in switching confidentiality mechanisms. The early detection of confidentiality violations reduces the effort of fixing the underlying issues.