Data-Driven Software Architecture for Analyzing Confidentiality

Abstract

Preservation of confidentiality has become a crucial quality property of software systems that software vendors have to consider in each development phase. Especially, neglecting confidentiality constraints in the software architecture leads to severe issues in later phases that often are hard to correct. In contrast to the implementation phase, there is no support for systematically considering confidentiality in architectural design phases by means of data processing descriptions. To fill this gap, we introduce data flows in an architectural description language to enable simple definition of confidentiality constraints. Afterwards, we transform the software architecture specification to a logic program to find violated confidentiality constraints. In a case study-based evaluation, we apply the analysis to sixteen scenarios to show the accuracy of the approach.

Modeling Data Flow Constraints for Design-Time Confidentiality Analyses

“…This can be defined as data flow constraint. We annotate the roles in Figure 1 similarly as in [4]: User, TravelAgency, Airline. Credit card details are only released for the User role.…”

“…To cope with confidentiality early in design time, datadriven analyses have been proposed [4], [5]. These approaches are based on Data Flow Diagrams (DFDs) which are commonly used in threat modeling because security "problems tend to follow the data flow, not the control flow" [6].…”

“…These approaches are based on Data Flow Diagrams (DFDs) which are commonly used in threat modeling because security "problems tend to follow the data flow, not the control flow" [6]. By modeling data sources, sinks and data processing and verifying constraints at design time, e.g., by transforming the model to logic programs [4], confidentiality issues can be detected and repaired earlier which can reduce cost significantly [7].…”

“…Thus, constraint definitions need to target the flow of selected classes of confidential data directly which is a more fine-grained approach than using standardized metrics whose expressiveness is limited. Data-Driven Software Architectures (DDSAs) [4] use characteristics to annotate data and data processors on architectural level while constraints are defined by utilizing the underlying formalism. This requires the architect to switch between the abstraction layers of the architecture and analysis.…”

“…C2 Second, we present a mapping to the underlying formalism which is compliant to the mapping of the modeled software architecture. We also define a mapping of analysis results back into the architectural domain which lacks in related work [1], [4], [13]. The contribution of this paper in Section V includes the presentation of relations between modeling and analysis which represents a difficult problem due to additional dependencies.…”