Identifying and analyzing security requirements is considered to be an essential part of the requirements engineering process. Several techniques have been introduced for capturing and modeling such requirements. Once identified, security requirements must be translated into designs that suggest how domain actors can securely fulfill operational goals under varying contexts and risk assumptions. We propose a model-driven approach for automatically generating workflows that fulfill information exchange goals while complying with specified security requirements. Goal-oriented security requirements models, augmented with descriptions of contextual and threat assumptions, are combined with reusable domain-agnostic workflow patterns, which model ways for securely performing common information exchange tasks. The resulting combined models are used by an automated reasoner to generate workflows that meet security requirements. The approach and toolset can be used by requirements analysts to systematically generate secure designs from requirements, in a way that relies less on their technical expertise in security and more on established best practices embodied in the patterns. We present the basic components of our approach via examples and describe future research directions.
Identifying and analyzing security requirements has long been considered to be an essential
part of the requirements analysis process [
and Vulnerability
iStar Model Recommended Workflow Design 6
STS-ml Information Model AI Planning Spec Assumptions
Model
5
Secure Workflow Patterns
Attack Tree
Patterns
We propose a model-based framework for systematically generating cryptography-enabled business workflows that domain actors can follow in order to fulfill their information exchange goals while also satisfying security requirements. The framework depends on the availability of expertly developed patterns that describe families of workflows for fulfilling common information exchange tasks. Security requirements are captured using a goal-oriented security requirements modeling language and analyzed via the development of attack trees that can compromise them, while the level of sophistication of the attacks to be defended against is captured though a set of vulnerability assumptions. The developed models are combined and translated in an automatable way into an Artificial Intelligence (AI) planning specification and an AI planner is used to automatically identify workflows that indicate security steps domain actors need to take while fulfilling information exchange goals. Using such a tool, designers can develop business workflows in a systematic, requirements-driven way, while respecting the properties and limitations of the security primitives their designs employ.
Consider the example of a small-sized residential building contractor requesting quotes, submitting orders, and sending payments to various material suppliers. Typically, the contractor submits orders for materials, and once the materials have been delivered, an invoice is sent with a payment information, often in the form of a bank account number for sending a wire transfer. The contractor performs such interactions via email, which, however, introduces several threats, including the submission and fulfillment of unauthorized orders through spoofing, and invoice fraud, i.e., submission of a tampered invoice, where the payment information has been altered.
The proposed framework is aimed at allowing analysts or IT support professionals who work with clients such as the above contractor to systematically generate secure workflow designs to fulfill information exchange needs of their clients, without having in-depth knowledge of the involved security technologies. An overview can be seen in Figure 1. The analysts go through a sequence of steps for developing goal models describing the specific information exchange needs (Step 1) and enriching them with additional security requirements (Step 2), and assumptions describing the level of attack to be protected against (Step 3). Having captured these requirements, analysts match elements of the domain-specific models with generic secure workflow and attack tree patterns from a collection of such developed and supported by the community of experts (Step 4). The enriched models and the patterns are then transformed into a formal specification in a way that can be automated (Step 5). From this specification an automated reasoner generates a workflow (Step 6) which includes the steps necessary for the performance of the information exchange tasks, appropriately enriched with cryptographic tasks to attain the captured security goals. We ofer more details about these steps below.
Steps 1 and 2: Goal Models and Security Requirements. We adopt iStar 2.0 [
Step 3: Domain and vulnerability assumptions. Predicates are added representing two kinds of assumptions. Domain assumptions are practical aspects of the domain that may afect the applicability of security controls or attacks against them, such as HasEmailAddress(contractor, supplier) or DigitalFile(invoice). Vulnerability assumptions represent worst-case states of afairs in which possible attacks have been successfully carried out. For instance, we may assume that the supplier’s email account will eventually be compromised (IsCompromised(supplier, emailAccount)) or that their terminal will be hacked (HasRootkit(supplier, cellphone)). Asserting a vulnerability assumption indicates that an attacker is motivated enough to bear the cost of the corresponding attack given the business context and the anticipated benefit.
Step 4: Integrate Patterns. A number of security workflow patterns embodying best practices
for fulfilling information exchange requirements are assumed to be available for adoption and use.
Each such pattern is identified by a generic functional goal, such as Transmit Document [Sender,
Recipient, Document], which is decomposed into an AND/OR goal tree that describes alternative
ways to fulfill the goal under various levels of security (from insecure to very secure). During
matching, analysts simply connect their domain specific information exchange goals, such as
Send Invoice to Contractor into an appropriately instantiated pattern root – in our case, Transmit
Document [supplier, contractor, invoice]. In addition, a set of expert/community maintained
attack trees [
Steps 5 and 6: Compile and Reason. The information gathered in the above steps is
compiled into an AI planning specification that allows automated extraction of a workflow that
(a) fulfills the information exchange requirement and, (b) picks a workflow pattern instantiation
that makes the attack tree corresponding to the required security service under the specified
vulnerability and domain assumptions infeasible. We utilize a Hierarchical Task Network (HTN)
Planner, SHOP2 [
Examples. In our invoice exchange example, assume that we want protection against
unauthorized altering of the document – e.g., unauthorized change of the bank account to
which payment must be made. The corresponding security service requirement, Integrity, is
specified in the part of the STS-ml model that describes this exchange (Step 2). Subsequently,
the workflow pattern Transmit Document [supplier, contractor, invoice] and the associated attack
tree concerned with integrity Compromise Integrity [supplier, contractor, document] are adopted
(Step 4). The reasoner (Steps 5 and then 6) will produce workflows in the form of recommended
task sequences. The level of security in these workflows, however, depends on the vulnerability
and domain assumptions (Step 3). If we make no vulnerability assumptions, a simple plan
that involves emailing the invoice in plaintext may be recommended – the most usable option.
However, we may assume that there are actors motivated and able to perform the attack. One
attacker approach is to compromise the sender’s and/or recipient’s email accounts to allow
tampering to happen. We hence assume that email accounts are vulnerable. In that case, the
reasoner will sacrifice usability and recommend participants to digitally sign and verify the
invoice after also engaging in key generation and exchange tasks. If, on the other hand, the
Confidentiality service was deemed needed at the STS-ml level, plans will include encryption and
decryption of the message. Importantly, the type of authentication and encryption techniques
(symmetric or asymmetric) may depend on the presence of a secure channel for exchanging a
secret key or practical aspects such as the software available at each side, represented through
vulnerability and domain assumptions, respectively. Examples showing more framework details
and how exactly the reasoning output looks like can be found in the associated repository [
The proposed framework aims at systematizing and automating generation of secure business
workflow designs that are compliant to given security requirements, sound from a security
perspective, and minimal vis-à-vis the security goals and threats – i.e., they do not include
usability-compromising security steps that are unnecessary. Our approach extends existing
methods for goal-oriented modeling and reasoning with security requirements, e.g., [
Our so far work has focused on employing basic cryptographic primitives for information
exchange, where we have been able to generate proof-of-concept patterns and reasoning
scenarios – see [
There are some key challenges in realizing this vision. One is identifying the right level of model expressiveness while keeping automated reasoning tractable. The latter can be assisted by stronger search control ofered by both HTNs and alternative reasoning systems through, e.g., explicating exemplar workflows versus leaving the reasoner to construct such. A second challenge is to establish a range of patterns and generic attack trees that are valid with respect to the security techniques they represent. This step requires consultation with experts and the literature, followed by testing of the reasoning outputs for correctness. Finally, critical to the empirical evaluation and application of the framework is the development of tools both for usable model development and synthesis and for fully automating the translation component.