Framework for Design Exploration of Secure ...

Download PDF
3 downloads 0 Views 264KB Size Report
Comment
Paul A. Wortman, John A. Chandy1 ... E-mail address: paul[email protected] ..... Feiler, P.: Automated Assurance of Security-Policy Enforcement In Critical ...
2018 Conference on Systems Engineering Research

Framework for Design Exploration of Secure Embedded System Development Paul A. Wortman, John A. Chandy1 Dept. of Electrical and Computer Engineering, University of Connecticut, Storrs, CT USA

Abstract As development and implementation of the Internet of Things (IoT) and embedded systems technologies increases, there is the need for a design framework that allows for thorough exploration of potential designs while detecting any potential risks and security violations. Without verification and validation, assuring that system security requirements are properly enforced becomes as tedious as it is hazardous. Our work proposes the use of a novel security development framework for exploration of secure embedded system designs. In this manner we are able to ensure that security functional and architectural requirements are maintained without the introduction of additional risk factors. © 2018 P.A. Wortman and J.A. Chandy.

Keywords: secure systems design; AADL;

1. Introduction As new technologies and techniques continuously become developed, there will be an equal eagerness to implement these new designs and methods. Complications of these developments will arise in the form of combining these various elements into a single functional design. The essence of this stems from the fact that no device or system operates independent from other individuals or systems. As such, when developing a new design solution, we need to recognize how each entity operates as well as what their scope of operation is. The focus of this paper is to propose a design framework for the exploration of early design choices to minimize risk, redesign costs, and ensure that all security requirements are met. For this purpose, we will heavily lean on an examination of the overall framework, the use of the Architecture Analysis and Design Language (AADL) as the descriptive language, as well as evaluation of generated designs. In this manner we are able to minimize the introduction of additional risk, security flaws, and policy violations when combining design elements. Early work on secure system development and modeling integrated security related information, elements, and requirements into the Unified Modeling Language (UML) and off-shoots (e.g. UMLSec, SysML Sec) to include details of integrity and authenticity as well as security aware architecture to improve secure system design18,19,20. Sadeghi et. al. worked to prove narrow forward privacy for RFID systems 21. In a similar vein Abidin et. al. worked to provide better forward security for improving a biometric authentication protocol 22. By contrast Dong and Kiefer worked on new security policies for improved server client privacy23. However, this prior work does not adequately capture quantifiable metrics to enable a systematic approach to secure system design. In this paper, we present a security design framework that uses risk and impact as quantifiable metrics for a security design that goes beyond just access control. The contributions of our work are as follows: • A design exploration framework for ensuring security based functional and architectural needs are met. • Examples of AADL code for the definition and verification of various security properties to show the ease of writing security evaluations.

1

* Corresponding author. E-mail address: [email protected]

® 2018 P.A. Wortman and J.A. Chandy.

Paul A. Wortman and John A. Chandy

2

• Showing a clear path for development of a mapping system to combine secure component models with embedded systems requirements. AADL, like most modeling languages, must be able to describe not only the requirements of a system, but also the constraints, capabilities, and costs of various implementations and methods for the purpose of modeling a gamut of different designs. Coupling this already large space with security causes the considerations and influences on the problem to grow considerably. Our paper chooses to examine the field of modeling embedded system security through the lens of the Architecture Analysis & Design Language (AADL). One needs to develop a verification and selection process for taking all of the catalogued information and possible solutions to then compare and contrast solutions that meet user-defined security requirements while categorizing solutions that are maintaining within external constraints and the capabilities of the architectural components being used to produce a best fit; measured by this paper's verification and selection process. To begin this approach, we first need to define the constraints of the system, describe critical considerations, and standardize a method by which we can produce a comparable metric for generated embedded system security model designs. 2. Proposed Framework We first introduce our larger security design methodology that can be applied to the larger process of embedded system security design. From this framework we show where the need for the modeling of functional security requirements that can be measured and validated. The method by which we develop our design-oriented examination of risk is reviewed and then applied to our adversarial model. The adversary influenced risk metric is shown to also be compatible with common monetary evaluations of embedded system design. We start our discussion of our proposed risk framework with a consideration of a methodology in which to explore the design space. We envision a design methodology built on Platform-based design (PBD)1 where one can take the functional space (including security requirements) and the architectural space (components and capabilities) in order to develop a mapping function that can produce solutions to a given design problem. These implementation solutions are then formally verified against the originating constraints of the system. Once the implementations are verified, code generation tools are used to produce a more detailed model that can be examined via vulnerability analysis. A visualization of the design process is shown in Figure 1. In order to enable this framework, the following steps are required:

Figure 1. Visualization of our Security Design Framework

1) Creation of a low-level component library that would contain several implementations of each base component within the architectural space used for model generation. This library serves as the basis for the modeling capabilities and architectural knowledge of the design team. Each component would have various features and capabilities including security aspects. These details determine the functional capabilities and constraints of each component solution. 2) Formalized description and definition of higher level security requirements that may come from user-defined needs or from the experience and knowledge of security experts. Currently, high-level needs are manifest in a vague form of `my data must be secure'. From a design perspective, this is not very useful. We favor metrics based requirements that capture risk and the value of assets to both the defender and adversary. Formalized definitions can be used to abstract these higher level quantifiable constraints into architectural implementations. 3) Creation of a mapping process by which security requirements and secure component specifications can be uniformly verified and selected to allow for the generation of potential secure architectural system model solutions to the given inputs. The mapping process is responsible for producing various system design implementations that meet the functional requirements of the system while maintaining realistic architectural constraints. It is in this step that having an evaluable security metric allows for the generation of different security-based embedded system design models. 4) Verification tools to validate mapping implementation solutions. This step is where each produced design

Paul A. Wortman and John A. Chandy

3

implementation is compared and contrasted to the original design specifications (i.e. functional and architectural constraints) to determine the best solutions of those presented. These instances can then be used as part of a genetic algorithm to thoroughly explore a given design space. Through the use of automated tools, we can move to exhaust this design exploration through the aid of computers. We have proposed a vision of the overall design process, but in this paper, we particularly focus on steps 1 and 2 - modeling components and requirements. Specifically, we focus on how to model security goals and requirements in such a way that they can be measured and validated. 3. AADL as Security Modeling Language The Architecture Analysis & Design Language (AADL) is traditionally used for the specification, analysis, automated integration and code generation of real-time performance-critical distributed computer systems2,3. The `performance-critical' aspects of a system include timing, safety, schedulability, fault tolerance, and security. AADL works to provide a new language vehicle for allowing analysis of system designs prior to development. The advantage being that the language and associated tools allow for developers to model, analyze, and generate embedded real-time systems while supporting model-based engineering concepts. Due to AADL's wide adoption and use in real-time embedded system design, there is a large-scale of available tools already developed by the user community4. Although security was not an initial concern in the development of the AADL language, there has been recent work made to extend the language to include behavioral and security-centric capabilities. These developments have occurred in a variety of annexes, most recently the security annex extensions, alterations, and expansion of security analysis tools that have been occurring throughout the past two years; starting in 2016 5-9. Current language standards used to describe security concepts, requirements, and constraints has not been developed well enough to be `all-encompassing'. The motivations of security-based expansion of AADL center around three core purposes 8. First is to detect security policy violations early. Second is to assure that the system implementation correctly enforces policies and that no security risks are introduced by the runtime architecture. Lastly is to automate the execution of security assurance plans. Recent work by Ellison et. al.5 has extended the security centric properties of AADL to include user-defined `AccessGroup' and `AccessMode' properties that are used for evaluating and validating an existing system model based on user expectations of functionality. The extension adds different security types (e.g. unclassified, confidential, secret, top secret). When implementing these extended security properties, one must determine the viability of a system given confidentiality requirements of data objects and security clearance by users. These security extensions allow for analysis of the modeled system to ensure processes and threads are mapped to appropriate hardware, communicate over secured channels, and store data in protected memory as well as deriving minimum security requirements for a given software architecture. While these two properties are effective at validating that a system will retain some arbitrary level of security, this is still not the level of detail that effectively allows for modeling of component specifications. Table 1. Illustration of Different Component Variations. Component Types Table Types Elements

I

II

III

Memory

Unprotected

Protected

Encrypted

Bus

Unprotected

Encrypted

Nonsniffable

Processor

Simple

Embedded Encryption

HW Encryption

Data

Plaintext

Encrypted

Protected

Port

Normal

Encrypted

Protected

IV Obfuscated

V Combo

There are certain improvements of AADL that we believe are a step in the right direction. Including a numerical value to ‘security levels’ allows for quantitative analysis of this property through a system's design. The concept of exposure (e.g. how exposed a component or system is) as a numerical value allows one to determine the possibility of attack within a design. Both of these additional properties open the door to formalize a verification of potential security hazards and complications that may arise further down the development cycle or even once out in the field. One problem with the approach, however, is the move to describe the security aspect of `trust' as a non-binary value; as one cannot say that they trust a component, or system, 80% of the time whereas reliability can be easily described as a percentage. While the released work6 states that this scale is representative of proof of a component's correctness, we believe that this merging of concepts does not accurately reflect security concerns and does not allow for accurate verification and validation of security requirements and behavior. Having the language to describe and define the correctness of a component is advantageous, this is not the same as trust but should rather be seen as a combination of trust and reliability.

Paul A. Wortman and John A. Chandy

4

4. Security Risk Modeling and Evaluation In this section we discuss how components and security properties are modeled in the AADL language, explore how security requirements are defined, and speak upon the evaluation of mapped designs constructed from the architecture and functional needs. These aspects form the crux of our proposed secure embedded system design framework and allow for its automated use and execution in system design and development. 4.1 Component Security Models As part of the proposed design framework, we need to have defined component security models, so that the design process can make selections that optimize not only functional requirements but also security requirements. In order to formalize this framework, we need to produce a form of component library that represents the possible combinations, or solutions, that a designer or developer can pull from to generate new implementation models. Listing 1 shows an example of how we use AADL to define properties on a processor and an encrypted transmitter. A system design will have a combination of components to meet the desired functional and security requirements. Table 1 shows defined potential component types that would populate the architectural space of this new security framework. Each element in the table has distinct variations that have their own unique security properties. For example, the method by which a designer implements memory is reliant on the technology available as well as any cost constraints. A developer could decide to protect memory by creating physical boundaries for access (e.g. use a trusted platform module (TPM)), or perhaps ensure that memory is encrypted to prevent an attacker from being able to leverage access due to an exploit. Furthermore, one can choose to obfuscate memory operations (e.g. ORAM) to thwart side-channel attacks or implement a combination of all these techniques in an effort to improve security of a given system component. Depending on the combination of component types, one will need to define these distinctive characteristics of the system. A system is defined as a grouping of elements that serve a given purpose that are created via the combination of different components to perform a specific task or function. Furthermore, this new system can be abstracted into a `single layer' device object model. Variations in the models come from mixtures of different design decisions to form larger systems; each expressed with unique properties and functions. A regular or simple system has no encryption, no data access control, no assurance of “security level maintained''. In this implementation one can interpret everything is at the “default” lowest level of “security'' that can be assured. An encrypted system has at least security implementation at some level; on the input or output, bus, memory or processor. Any mixture of the aforementioned ‘levels’ of encryption is possible, but must be verifiable; due to the need of verifying security. A protected system contains elements that either interact or are responsible for access control to “secure'' data, information, or services. system implementation transmitter.encrypt_i -- Subcomponents of the transmitter subcomponents ant_in : system recv_antenna.normal_i; ant_out : system trns_antenna.encrypt_i; encrproc : processor procbase.encryptembedded_i; -- Connection definitions of the transmitter connections c0 : port ant_in.wired_out -> encrproc.input_port; c1 : port encrproc.output_port -> ant_out.wired_in; -- Flow path definition for the transmitter flows f0 : end to end flow ant_in.f0 -> c0 -> encrproc -> c1 -> ant_out.f0; -- Additional properties of the transmitter properties securityspecs::has_encryption => true; end transmitter.encrypt_i; processor implementation procbase.encryptembedded_i properties securityspecs::has_encryption => true; securityspecs::encryptmodule_class => embedded; securityspecs::encryption_class => AES; securityspecs::encryption_variation => b256; securityspecs::has_PUF => false; securityspecs::has_TPM => false; securityspecs::has_encryptedflash => false; securityspecs::isTamperProof => false; end procbase.encryptembedded_i; Listing 1. Example of User-defined Lower Level Components

4.2 Security Requirements Model Security requirements are traditionally very vague and undefined. For the most part, they define that either “data must be secure”

Paul A. Wortman and John A. Chandy

5

or certain access controls – for example, which users have access to which data. We require a quantifiable metric against which to measure the quality of a design. Ferrante et al came up with a notion of a security level (SL) which arbitrarily assigned a 0-100 value to a component10. A more satisfying metric is the notion of risk – i.e. the combination of probability of attack and the impact/cost of the attack. While traditional views of risk only deal with a single source of probability, the examination of security risk is more involved due to multiple sources of probability. This starts with an understanding of attacks from the adversary's perspective. Each possible attack vector upon a system is dependent on a series of exploits, meaning that as multiple steps are taken to perform a successful data exfiltration attack, one needs to accurately aggregate the individual costs of each event in the process; having its own event probability and cost. Beyond the notion of an attack vector, the traditional view of risk also does not account for an attacker's motivations. Therefore, the risk metric must also capture the level of embedded system security risk influenced by both the potential of attack as well as impacted loss. Security risk (SR) of a given solution is influenced by both the monetary value that an attacker places upon the presented system as well as what is required by the defender to recover from a successful attack. Through the use of the resulting metric a developer can tailor their design to better protect systems while also presenting a higher cost to an adversary willing to expend resources. The SR value allows for the approximation of a monetary value of the security strength of any potential design solution. However, while the calculated metric does begin to influence implementation decisions, it still requires incorporation into the overall cost of manufacture, operation, and maintenance. Thus, as part of the security requirements, the system specifications must also specify the attack impact and value on a system’s service. Listing 2 shows an example of how AADL could be used to specify security requirements on a wireless sensor service. Security prerequisites are specified in terms of value of a service feature to an attacker and impact to the system user if the service was to be compromised. For example, if the wireless sensor leaks data, the system user will lose $1000. At the same time, the leaked data is worth only $800 to an attacker. In a more detailed requirements listing, these values may be more granular and also specify different values to different attackers. Unfortunately obtaining these attack values can be a tedious process as it is difficult to obtain data relating to value and impact of attacks on critical systems from larger corporations; understandably due to the sensitive nature of the information. To properly arrive at meaningful values for these security properties one must recognize and pinpoint the impact and costs of attacks upon a given system. These costs include damage to one’s reputation, time required to repair or even fathom the extent of the impact, loss of proprietary knowledge, or even additional expenditure of resources (e.g. power consumption). Furthermore, depending on the system being examined or the operational parameters of its purpose, these considerations can greatly vary. For instance, the concerns placed upon the design of a secure embedded system are going to be remarkably different than those for a secure network architectural configuration. The amount of exposure of each component, ease of access for the system at large, power consumption of individual elements, even the methods and costs that an attacker would have to pay to successfully exploit vulnerabilities will differ. Without exception the economics vary based on the situation and require detailed knowledge to accurately represent costs and impacts. One should note that as with any of these properties, the AADL code block shown in Listing 2 shows a simplified single pay cost but it could easily incorporate aggregate costs due to multiple attackers or defenders of a given system or even temporal centric value based on run time and resource usage. Bereft of these considerations a designer or developer cannot accurately ensure that the security requirements of a produced design have been met. Depending on the value of data elements to different attackers (e.g. hacker, information broker) then an aggregate cost of these impacts must be considered. The same can be said of the defensive security considerations. For example: a company may be defending the personally identifiable information (PII) of several customers. In the scenario where that information is stolen there are two considerations for impact. The first is the cost, in terms of reputation and recovering for the company hosting this service while the second are the individual costs to each customer. In the case of the latter, these values can greatly range depending on the sensitivity of the information as well as the degree of damage that a malicious actor can cause (e.g. loss of reputation, increase in debt). abstract implementation sysreq.wireless_sensor_i subcomponents serv_ADConv: abstract sysserv.ADConv_i { servatrb::dynamicRange => 0..5 V; secatrb::integrity::atkImpact => 300; }; serv_wrlsTrans: abstract sysserv.wrlsTrans_i { servatrb::distance => 100 m; secatrb::authentication::atkValue => 600; secatrb::authentication::atkImpact => 400; secatrb::authorization::atkImpact => 1200; secatrb::dataleakage::atkImpact: => 1000; secatrb::dataleakage::atkValue: => 800; }; fnc_data: abstract security_props.data_i { dataatrb::data_class => Sensor; secatrb::atkImpact => 800; properties secatrb::hasProtection => false;

Paul A. Wortman and John A. Chandy

6

secatrb::AuthGroup => Employees; end sysreq.wireless_sensor_i; Listing 2. User-defined Higher Level Security Requirement

4.3 Design Mapping and Evaluation Model The mapping process is a difficult and intricate element of the model that requires automation. In its current state the mapping step requires that a system expert produces a design, or series of designs, for a given secure embedded system. From the produced models, the next step is to derive the attack tree and impacts that correspond to the vulnerabilities and security properties of each scheme. The final step is to then compare and contrast the gathered information to determine if the original requirements are still met. In this section we examine the mapping step of our proposed framework as well as the additional steps of evaluating the produced designs for refinement of the mapping function. The security requirements of a system are used by a designer to select components from the component library described in Section 4.1 to optimize the functional and security requirements. It is possible to develop a mapping process that will not only account for the needs of the modeled system but also take into account the constraints of embedded systems. These constraints originate both from the user-defined requirements and needs of the system, but also from the architectural limitations of the components available to form the base of the existing design space. To accurately represent these costs, one has to write in the corresponding properties into the AADL language; which will then be used in the mapping of these various architectural schemes to produce a series of final designs. The other half of this mapping process is to incorporate any number of functional requirements imposed upon the system. As stated before in Section 2, these can be vague and poorly defined. In this scenario the developer will need to make decisions on how to best implement these functional needs in more concrete methods. Using the Platform-based design method, we abstract these functional aspects into more detailed implementations. Once an appropriate level of tangible functional implementation has been reached, this is combined with the architectural models as input to the mapping process. The mapping element then combines these two aspects using special consideration towards the original constraints of the system in order to produce a series of final design mappings. These are then evaluated in terms of the original functional and architectural needs as well as the potential security risk cost and impacts. From this evaluation we then further refine the constrains of the mapping function to produce a more polished series of potential design solutions. However, in its current form we still require the use of a security expert and their knowledge. With respect to security, as the designer evaluates a potential system design (combination of components), a possible attack tree will be constructed against all potential valuable assets and services in that system. For each asset and service under consideration, we evaluate the potential attack vectors in the tree with respect to their probabilities and costs. A determination can be made if these design/implementation costs are greater than that the attack impact or vice versa the attack costs are less than the value to the adversary. In other words, we construct the attack value and impacts as quantifiable constraints in our design selection strategy. The security constraints are structured from a requirements specification (as in Listing 2) that assigns potential impact or value costs for every asset. Thus, the mapping process for our Listing 2 example, would have constraint as follows: 𝐶𝑑 (𝑑𝑎𝑡𝑎) < $1000 𝐶𝑎 (𝑑𝑎𝑡𝑎) > $800 where 𝐶𝑑 (𝑑𝑎𝑡𝑎) is the cost of the defensive measures needed to protect against data leakage and 𝐶𝑎 (𝑑𝑎𝑡𝑎) is the the cost (to the attacker) to exploit vulnerabilities in these defensive measures. The first constraint says that the cost of the defensive measures should be less than the value of the asset (data). In other words, it makes no sense to spend more on defensive measures than the value of the asset. Likewise, the second constraint says that while there may still be vulnerabilities in the designed system, the cost for an attacker to exploit these vulnerabilities will be higher than the value of the attack – thus making the attack needless. For example, the defensive measures may have locked down on all “standard” exploits thus leaving only vulnerabilities in hardware that can be exploited with expensive IC decapping and probing. Determining these 𝐶𝑎 and 𝐶𝑑 costs is dependent on the design being evaluated. Using actual costs is much more concrete than a 0 to 100 scale, because it allows for each potential design to be evaluated individually rather than all together in a single scale. The defensive costs are the aggregation of amortized system design costs, implementation costs, ongoing costs, etc. allocated to defense of a particular asset. The attack costs are determined by evaluating the attack tree and using probabilistic weights and estimates of exploits of each node in the attack tree. With these probabilities and costs (both attack and defensive), one can then arrive at risk values for a system design under consideration. The various costs (e.g. risk, operational, maintenance) produce a monetary metric that effectively compares each design in terms of security requirements met. These metrics are then used to further refine the constraints of the mapping process based on the favorability of each design to the original functional and architectural requirements. Additional constraints take the form of architectural limitations due to the types of components available to a given designer, functional restrictions due to the type of system or operational scenario of a proposed scheme, or the cost of materials due to the budget allotted to the design project. Furthermore, these constraints can be expanded to include the type of users that are interacting with the system, assumptions made based on the accessibility of each developed device (e.g. sensors in a network), or even the roles of multiple attackers or defenders of a system. All of these security considerations carry a weight and cost that must be fed back into the mapping process to better refine the

Paul A. Wortman and John A. Chandy

7

constraints and produce an improved design model. While currently this mapping process requires human input to produce each mapping of functional and architectural needs, our evaluation scheme allows for a method of ensuring that requirements are met as well as determining the risk and impact of each design. The next steps in further developing this aspect of our framework depends upon automating the process. Through automation we will be able to more thoroughly explore the design space of any given secure embedded system development project. 5. Verification and Validation Approaches While the focus of our paper is not on verification of a design, it is worthwhile to discuss some approaches to verify that a design has met the security requirements outlined in Section 4. The core of the existing Automated Assurance of Security Policy Enforcement (AASPE) work centers around the use of security levels/types, checks that are written using Resolute, as well as simple use of different security properties (e.g. exposure) for a given system. For the purpose of our proposed framework, we steer the conversation towards the use of Resolute as an evaluation and validation tool. When examining the security-based extensions to AADL, Resolute would make an effective method of verification and validation that a produced security model meets all of the required user-defined security assurances. These could range from networking connectivity requirements to dependencies on correctly implemented access control parameters. The disadvantage of this tool, in its current state, is that the assurance checks are relatively simple and there has been little to no documentation on the user-community's efforts to improve the tool for securitycentric applications of modeling. An example of one such security check is shown by Listing 3 examining that all connections between given components maintain an expectation of encryption. package arch_resolute_checks public annex resolute {** check_encryption_flow(comp : component) (property(source(conn), securityspecs::has_encryption)) = (property(destination(conn), securityspecs::has_encryption)) **}; end arch_resolute_checks; Listing 3. User-defined Resolute Checks

As one can see from the above example, the language of the security check is relatively simple. While Listing 3 does improve the detection of security architecture violations, it is limited in terms of the type of verification it can perform. This stems from the method by which properties can be compared and contrasted. Resolute is an excellent tool for ensuring security properties match and that architectural requirements are met. However, there are aspects of a secure embedded system (e.g. security policy and behavior) that cannot be modeled using Resolute alone. In these cases, other tools such as Architecture-led Incremental System Assurance (ALISA)17, ASSPE9, and Behavior Language for Embedded Systems with Software (BLESS) must be implemented to ensure detection in security functional and behavioral violations as early as possible. Further work is needed to develop Resolute, or other annex tools, to account for security assurances through verification and validation solutions. Furthermore, standardization of the dialect must take place to allow for ease of communication of ideas, specifications, requirements, and expected behavior. Otherwise the advantages of this new security framework would not outweigh the cost and time spend learning the syntax and tools required. Through BLESS we can improve each model to evaluate not only the functional and architectural properties, but also ensure secure behavior of the system. An example of such a linguistic implementation of BLESS properties in shown in Listing 4. The main point to illustrate is that depending on the data model used by a given device design, the device should act differently. Limitations of this BLESS expansion are that a knowledge base of formal verification is required to write the necessary proofs. Overall the incorporation of these tools does allow meaningful expansion of security modeling. However, there are concerns that stem from limitations of the tools, complications that arise in learning to use it, or even formalization of practices and implementation. As with any model, if it is made too complex than a great deal of effort is placed in a design that cannot be very flexible. On the other hand, without enough detail the model is far too generic and cannot properly represent the developed system. In this scenario the focus of the model could be around policy specification and enforcement. In summary, we require the development of a formal method to design and develop different levels of security properties and functionality for improving system design and understanding. data auth_method properties Data_Model::Data_Representation => Enum; Data_Model::Enumerators => ("None","shared","user","key");

Paul A. Wortman and John A. Chandy

8

BLESS::Types => "enumeration (None, shared, user, key); end auth_method ... device authenticator features auth : in data port auth_method; auth_status : out data port auth_rating; ... end authenticator ... device implementation authenticator ... annex BLESS {*** ... if (auth=None)~> auth_status!(Fail) [] if (auth=shared)~> auth_status!(Weak) [] if (auth=user)~> auth_status!(Average) [] if (auth=key)~> auth_status!(Strong) [] ... ***}; end authenticator.impl; Listing 4. AADL BLESS Definition Example

6. Conclusions and Future Work In this paper we explore our proposed framework for effectively modeling secure systems using AADL as the defining language. Through our work, one can easily extend any model to not only work at the scope of a network or individual proprietary system but also expand it to contain desired security properties. Our proposed framework is very customizable to any situation that requires modeling. Our future work includes development of behavioral checks for security behavior, maturation of the mapping process for generating design solutions, and formalization of security verification and evaluation functions. References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

Sangiovanni-Vincentelli, A.: Quo Vadis, SLD? Reasoning About the Trends and Challenges of System Level Design, Proceedings of the IEEE (March 2007) AADL, http://www.aadl.info/aadl/currentsite Feiler, P.: SAE AADL V2: An Overview. Carnegie Mellon University (2010)
 AADL Tools, https://wiki.sei.cmu.edu/aadl/index.php/AADL\ tools Ellison, R., Householder, A., Hudak, J., Kazman, R., Woody, C.: Extending AADL for Security Design Assurance of Cyber-Physical Systems, Software Engineering Institute, CMU/SEI-2015-TR-014 (2015) Delange, J., Feiler, P., Klieber, W., Nam, M., Seibel, J.: AADL Security Annex, https://github.com/saeaadl/userdays/blob/master/UserDays/ May2016/security- annex- May2016.pdf Delange, J., Nam, M., Seibel, J.: AADL Security Analysis Tools, https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/ security- analysisMay2016.pdf Feiler, P.: Automated Assurance of Security-Policy Enforcement In Critical Systems https://insights.sei.cmu.edu/sei blog/2018/02/ automated- assurance- ofsecurity- policy- enforcement- in- critical- systems. html AASPE AADL Github, https://github.com/cmu-sei/AASPE Ferrante, A., Milosevic, J., Janjusévic`, M.: A Security-enhanced Design Methodology for Embedded Systems, International Conference on Security and Cryptography (SECRYPT) (2013) Jürjens, J.: Secure systems development with UML, Springer Science & Business Media (2005) AADL, http://www.aadl.info/aadl/currentsite Feiler, P.: SAE AADL V2: An Overview. Carnegie Mellon University (2010)
 Ellison, R., Householder, A., Hudak, J., Kazman, R., Woody, C.: Extending AADL for Security Design Assurance of Cyber-Physical Systems, Software Engineering Institute, CMU/SEI-2015-TR-014 (2015) Delange, J., Feiler, P., Neil, E.: Incremental Life Cycle Assurance of Safety-Critical Systems, 8th European Congress on Embedded Real Time Software and Systems (ERTS 2016) Feiler, P.: Automated Assurance of Security-Policy Enforcement In Critical Systems https://insights.sei.cmu.edu/sei blog/2018/02/ automated- assurance- ofsecurity- policy- enforcement- in- critical- systems. html Alisa User Guide, https://rawgit.com/osate/alisa/develop/org.osate.alisa. help/contents/00- Main.html SysML Sec, http://sysml-sec.telecom-paristech.fr Jürjens, J.: UMLsec: Extending UML for secure systems development, UML 2002 The Unified Modeling Language, Springer Publishing, pages 412–425 (2002) Jürjens, J.: Secure systems development with UML, Springer Science & Business Media (2005) Sadeghi, A., Visconti, I., and Wachsmann, C.: Anonymizer-enabled security and privacy for RFID, International Conference on Cryptology and Network Security, pages 134-153 (2009) Abidin, A., Matsuura, K., Mitrokotsa, A.: Security of a privacy-preserving biometric authentication protocol revisited, International Conference on Cryptology and Network Security, pages 290-304 (2014) Dong, C., and Kiefer, F.: Secure set-based policy checking and its application to password registration. (2015)