Architectural Data Flow Analysis for Detecting Violations of Confidentiality Requirements

Software vendors must consider confidentiality especially while creating software architectures because decisions made here are hard to change later. Our approach represents and analyzes data flows in software architectures. Systems specify data flows and confidentiality requirements specify limitations of data flows. Software architects use detected violations of these limitations to improve the system. We demonstrate how to integrate our approach into existing development processes

Architectural Data Flow Analysis for Detecting Violations of Confidentiality Requirements

Software vendors must consider confidentiality especially while creating software architectures because decisions made here are hard to change later. Our approach represents and analyzes data flows in software architectures. Systems specify data flows and confidentiality requirements specify limitations of data flows. Software architects use detected violations of these limitations to improve the system. We demonstrate how to integrate our approach into existing development processes

Architectural Data Flow Analysis for Detecting Violations of Confidentiality Requirements

Software vendors must consider confidentiality especially while creating software architectures because decisions made here are hard to change later. Our approach represents and analyzes data flows in software architectures. Systems specify data flows and confidentiality requirements specify limitations of data flows. Software architects use detected violations of these limitations to improve the system. We demonstrate how to integrate our approach into existing development processes

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. Frü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

Fault tolerant architectures for integrated aircraft electronics systems, task 2

The architectural basis for an advanced fault tolerant on-board computer to succeed the current generation of fault tolerant computers is examined. The network error tolerant system architecture is studied with particular attention to intercluster configurations and communication protocols, and to refined reliability estimates. The diagnosis of faults, so that appropriate choices for reconfiguration can be made is discussed. The analysis relates particularly to the recognition of transient faults in a system with tasks at many levels of priority. The demand driven data-flow architecture, which appears to have possible application in fault tolerant systems is described and work investigating the feasibility of automatic generation of aircraft flight control programs from abstract specifications is reported

Methodology for object-oriented real-time systems analysis and design: Software engineering

Successful application of software engineering methodologies requires an integrated analysis and design life-cycle in which the various phases flow smoothly 'seamlessly' from analysis through design to implementation. Furthermore, different analysis methodologies often lead to different structuring of the system so that the transition from analysis to design may be awkward depending on the design methodology to be used. This is especially important when object-oriented programming is to be used for implementation when the original specification and perhaps high-level design is non-object oriented. Two approaches to real-time systems analysis which can lead to an object-oriented design are contrasted: (1) modeling the system using structured analysis with real-time extensions which emphasizes data and control flows followed by the abstraction of objects where the operations or methods of the objects correspond to processes in the data flow diagrams and then design in terms of these objects; and (2) modeling the system from the beginning as a set of naturally occurring concurrent entities (objects) each having its own time-behavior defined by a set of states and state-transition rules and seamlessly transforming the analysis models into high-level design models. A new concept of a 'real-time systems-analysis object' is introduced and becomes the basic building block of a series of seamlessly-connected models which progress from the object-oriented real-time systems analysis and design system analysis logical models through the physical architectural models and the high-level design stages. The methodology is appropriate to the overall specification including hardware and software modules. In software modules, the systems analysis objects are transformed into software objects

Evaluating the impact of hierarchical deep-water slope channel architecture on fluid flow behavior, Cretaceous Tres Pasos Formation, Chile

2021 Spring.Includes bibliographical references.Channelized deep-water reservoirs inherently contain sub-seismic scale heterogeneity, resulting in uncertainty when evaluating reservoir connectivity and flow patterns. Stratigraphic architectural features, including stacked channel elements, channel element fill, mass transport deposits (MTDs), and channel base drapes, can have a complex and significant impact on fluid flow pathways. While this detailed stratigraphic architecture can be difficult to capture at the development scale, it can be effectively modeled at the sector scale using high-resolution outcrop data. The characterization of flow behaviors and reservoir performance at this finer scale can then be used in the construction of lower-resolution development-scale simulations. This study uses a three-part sensitivity analysis to test how fluid flow behavior responds to channel element stacking patterns, net to gross ratio, channel base drape coverage, and MTD properties. First, simplified models are used to isolate key flow behaviors. Then, field data is incorporated from the seismic-scale Laguna Figueroa outcrop of the Cretaceous Tres Pasos Formation, Magallanes Basin, Chile to construct a deterministic outcrop model that incorporates realistic stacking patterns and architectural features, including MTDs. Finally, stochastic object-based methods are used to try to replicate the flow characteristics of the outcrop model using established geostatistical methods and limited data input. Fluid flow was simulated using a constant flux aquifer at the base of the model and three producing wells at the top, and the results of the three modeling methods were compared in an effort to elucidate key flow behaviors