PBDSecModeling.tex

% This is "sig-alternate.tex" V2.1 April 2013
% This file should be compiled with V2.5 of "sig-alternate.cls" May 2012
%
% This example file demonstrates the use of the 'sig-alternate.cls'
% V2.5 LaTeX2e document class file. It is for those submitting
% articles to ACM Conference Proceedings WHO DO NOT WISH TO
% STRICTLY ADHERE TO THE SIGS (PUBS-BOARD-ENDORSED) STYLE.
% The 'sig-alternate.cls' file will produce a similar-looking,
% albeit, 'tighter' paper resulting in, invariably, fewer pages.
%
% ----------------------------------------------------------------------------------------------------------------
% This .tex file (and associated .cls V2.5) produces:
%       1) The Permission Statement
%       2) The Conference (location) Info information
%       3) The Copyright Line with ACM data
%       4) NO page numbers
%
% as against the acm_proc_article-sp.cls file which
% DOES NOT produce 1) thru' 3) above.
%
% Using 'sig-alternate.cls' you have control, however, from within
% the source .tex file, over both the CopyrightYear
% (defaulted to 200X) and the ACM Copyright Data
% (defaulted to X-XXXXX-XX-X/XX/XX).
% e.g.
% \CopyrightYear{2007} will cause 2007 to appear in the copyright line.
% \crdata{0-12345-67-8/90/12} will cause 0-12345-67-8/90/12 to appear in the copyright line.
%
% ---------------------------------------------------------------------------------------------------------------
% This .tex source is an example which *does* use
% the .bib file (from which the .bbl file % is produced).
% REMEMBER HOWEVER: After having produced the .bbl file,
% and prior to final submission, you *NEED* to 'insert'
% your .bbl file into your source .tex file so as to provide
% ONE 'self-contained' source file.
%
% ================= IF YOU HAVE QUESTIONS =======================
% Questions regarding the SIGS styles, SIGS policies and
% procedures, Conferences etc. should be sent to
% Adrienne Griscti (griscti@acm.org)
%
% Technical questions _only_ to
% Gerald Murray (murray@hq.acm.org)
% ===============================================================
%
% For tracking purposes - this is V2.0 - May 2012

\documentclass{sig-alternate-05-2015}

\usepackage{listings}	% Include the listings-package
\usepackage{color}
\usepackage{balance}
\usepackage{tabularx,booktabs}
\usepackage{multirow}
\usepackage[normalem]{ulem}
\useunder{\uline}{\ul}{}

\definecolor{darkgreen}{rgb}{0,0.5,0}
\definecolor{mygreen}{rgb}{0,0.6,0}
\definecolor{mygray}{rgb}{0.5,0.5,0.5}
\definecolor{mymauve}{rgb}{0.58,0,0.82}
\lstset{ %
  backgroundcolor=\color{white},   % choose the background color; you must add \usepackage{color} or \usepackage{xcolor}
  basicstyle=\ttfamily\scriptsize,        % the size of the fonts that are used for the code
  breakatwhitespace=false,         % sets if automatic breaks should only happen at whitespace
  breaklines=true,                 % sets automatic line breaking
  captionpos=b,                    % sets the caption-position to bottom
  commentstyle=\color{mygreen},    % comment style
  deletekeywords={...},            % if you want to delete keywords from the given language
  escapeinside={\%*}{*)},          % if you want to add LaTeX within your code
  extendedchars=true,              % lets you use non-ASCII characters; for 8-bits encodings only, does not work with UTF-8
  frame=single,                    % adds a frame around the code
  keepspaces=true,                 % keeps spaces in text, useful for keeping indentation of code (possibly needs columns=flexible)
  keywordstyle=\color{blue},       % keyword style
%  language=C,                 % the language of the code
  morecomment=[l]{--},
  morekeywords={property,set,is,type, constant, enumeration, end, applies, to, inherit, of, *,...},            % if you want to add more keywords to the set
  numbers=left,                    % where to put the line-numbers; possible values are (none, left, right)
  numbersep=5pt,                   % how far the line-numbers are from the code
  numberstyle=\tiny\color{mygray}, % the style that is used for the line-numbers
  rulecolor=\color{black},         % if not set, the frame-color may be changed on line-breaks within not-black text (e.g. comments (green here))
  showspaces=false,                % show spaces everywhere adding particular underscores; it overrides 'showstringspaces'
  showstringspaces=false,          % underline spaces within strings only
  showtabs=false,                  % show tabs within strings adding particular underscores
  stepnumber=1,                    % the step between two line-numbers. If it's 1, each line will be numbered
  stringstyle=\color{mymauve},     % string literal style
  tabsize=2,                       % sets default tabsize to 2 spaces
  title=\lstname                   % show the filename of files included with \lstinputlisting; also try caption instead of title
}

\begin{document}

% Copyright
%\setcopyright{acmcopyright}
%\setcopyright{acmlicensed}
%\setcopyright{rightsretained}
%\setcopyright{usgov}
%\setcopyright{usgovmixed}
%\setcopyright{cagov}
%\setcopyright{cagovmixed}


% DOI
%\doi{10.475/123_4}

% ISBN
%\isbn{123-4567-24-567/08/06}

%Conference
%\conferenceinfo{CODES '16}{October 2--7, 2016, Pittsburgh, PA, USA}

%\acmPrice{\$15.00}

%
% --- Author Metadata here ---
%\conferenceinfo{WOODSTOCK}{'97 El Paso, Texas USA}
%\CopyrightYear{2007} % Allows default copyright year (20XX) to be over-ridden - IF NEED BE.
%\crdata{0-12345-67-8/90/01}  % Allows default copyright data (0-89791-88-6/97/05) to be over-ridden - IF NEED BE.
% --- End of Author Metadata ---

\title{Security Requirements, Properties, and Translation in Embedded System Design}%\titlenote{(Produces the permission block, and copyright information). For use with SIG-ALTERNATE.CLS. Supported by ACM.}}

%\subtitle{[Extended Abstract]
%\titlenote{A full version of this paper is available as
%\textit{Author's Guide to Preparing ACM SIG Proceedings Using
%\LaTeX$2_\epsilon$\ and BibTeX} at
%\texttt{www.acm.org/eaddress.htm}}}
%
% You need the command \numberofauthors to handle the 'placement
% and alignment' of the authors beneath the title.
%
% For aesthetic reasons, we recommend 'three authors at a time'
% i.e. three 'name/affiliation blocks' be placed beneath the title.
%
% NOTE: You are NOT restricted in how many 'rows' of
% "name/affiliations" may appear. We just ask that you restrict
% the number of 'columns' to three.
%
% Because of the available 'opening page real-estate'
% we ask you to refrain from putting more than six authors
% (two rows with three columns) beneath the article title.
% More than six makes the first-page appear very cluttered indeed.
%
% Use the \alignauthor commands to handle the names
% and affiliations for an 'aesthetic maximum' of six authors.
% Add names, affiliations, addresses for
% the seventh etc. author(s) as the argument for the
% \additionalauthors command.
% These 'additional authors' will be output/set for you
% without further effort on your part as the last section in
% the body of your article BEFORE References or any Appendices.

\numberofauthors{2} %  in this sample file, there are a *total*
% of EIGHT authors. SIX appear on the 'first-page' (for formatting
% reasons) and the remaining two appear in the \additionalauthors section.
%
\author{
% You can go ahead and credit any number of authors here,
% e.g. one 'row of three' or two rows (consisting of one row of three
% and a second row of one, two or three).
%
% The command \alignauthor (no curly braces needed) should
% precede each author name, affiliation/snail-mail address and
% e-mail address. Additionally, tag each line of
% affiliation/address with \affaddr, and tag the
% e-mail address with \email.
%
% 1st. author
%\alignauthor
%Paul Wortman \\ %\titlenote{Dr.~Trovato insisted his name be first.}\\
%       \affaddr{University of Connecticut}\\
%       \affaddr{1932 Wallamaloo Lane}\\
%       \affaddr{Wallamaloo, New Zealand}\\
%       \email{paul.wortman@uconn.edu}
% 2nd. author
%\alignauthor
%John A. Chandy \\ %\titlenote{The secretary disavows any knowledge of this author's actions.}\\
%       \affaddr{University of Connecticut}\\
%       \affaddr{P.O. Box 1212}\\
%     \affaddr{Dublin, Ohio 43017-6221}\\
%       \email{john.chandy@uconn.edu}
% 3rd. author
%\alignauthor Lars Th{\o}rv{\"a}ld\titlenote{This author is the
%one who did all the really hard work.}\\
%       \affaddr{The Th{\o}rv{\"a}ld Group}\\
%       \affaddr{1 Th{\o}rv{\"a}ld Circle}\\
%       \affaddr{Hekla, Iceland}\\
%       \email{larst@affiliation.org}
%\and  % use '\and' if you need 'another row' of author names
%% 4th. author
%\alignauthor Lawrence P. Leipuner\\
%       \affaddr{Brookhaven Laboratories}\\
%       \affaddr{Brookhaven National Lab}\\
%       \affaddr{P.O. Box 5000}\\
%       \email{lleipuner@researchlabs.org}
%% 5th. author
%\alignauthor Sean Fogarty\\
%       \affaddr{NASA Ames Research Center}\\
%       \affaddr{Moffett Field}\\
%       \affaddr{California 94035}\\
%       \email{fogartys@amesres.org}
%% 6th. author
%\alignauthor Charles Palmer\\
%       \affaddr{Palmer Research Laboratories}\\
%       \affaddr{8600 Datapoint Drive}\\
%       \affaddr{San Antonio, Texas 78229}\\
%       \email{cpalmer@prl.com}
}
% There's nothing stopping you putting the seventh, eighth, etc.
% author on the opening page (as the 'third row') but we ask,
% for aesthetic reasons that you place these 'additional authors'
% in the \additional authors block, viz.
%\additionalauthors{Additional authors: John Smith (The Th{\o}rv{\"a}ld Group,
%email: {\texttt{jsmith@affiliation.org}}) and Julius P.~Kumquat
%(The Kumquat Consortium, email: {\texttt{jpkumquat@consortium.net}}).}
%\date{30 July 1999}
% Just remember to make sure that the TOTAL number of authors
% is the number that will appear on the first page PLUS the
% number that will appear in the \additionalauthors section.

\maketitle
\begin{abstract}
In the course of normal embedded system development and design, security is usually not considered or incorporated until late in the process.  While there are tools and methodologies that tackle aspects of this issue, there is nothing that brings a `complete' solution.  Platform-Based Design (PBD) has been introduced as a design process that centers around minimizing the costs of
developing and manufacturing systems through the use of a
``meet-in-the-middle'' methodology.   However, there is a lack of design methodology for doing platform-based design of
security elements, except for conceptual use in some specific niche areas.  This paper introduces a generalized system design framework based on PBD that is centered around
using an extension of the AADL modeling language to properly incorporate security into system design requirements and component specifications.  The purpose is to lay the foundation for a framework that will implement security in a documented, rigorous, and standardized way.
\end{abstract}

%Use elsewhere?:
% Successive refinements of
%specifications meet with abstractions of potential implementations;
%the goal being to obtain the same level of abstraction as is written
%into good coding functions~\cite{sangiovanni2002defining}. 

%
% The code below should be generated by the tool at
% http://dl.acm.org/ccs.cfm
% Please copy and paste the code instead of the example below. 
%
\begin{CCSXML}
<ccs2012>
<concept>
<concept_id>10002978.10003001.10003003</concept_id>
<concept_desc>Security and privacy~Embedded systems security</concept_desc>
<concept_significance>500</concept_significance>
</concept>
<concept>
<concept_id>10002978.10002986.10002988</concept_id>
<concept_desc>Security and privacy~Security requirements</concept_desc>
<concept_significance>300</concept_significance>
</concept>
<concept>
<concept_id>10002978.10002986.10002989</concept_id>
<concept_desc>Security and privacy~Formal security models</concept_desc>
<concept_significance>100</concept_significance>
</concept>
</ccs2012>
\end{CCSXML}

\ccsdesc[500]{Security and privacy~Embedded systems security}
\ccsdesc[300]{Security and privacy~Security requirements}
\ccsdesc[100]{Security and privacy~Formal security models}


%
% End generated code
%

%
%  Use this command to print the description
%
\printccsdesc

% We no longer use \terms command
%\terms{Theory}

\keywords{secure systems design, AADL, platform based design}

\section{Introduction}
\label{securityBasics}
Secure systems design is a formidable and troublesome obstacle that is not well understood and even more poorly implemented.  From examples of Jeep Cherokee's security weaknesses~\cite{jeepHack}, airplane hacker scares~\cite{planeHack}, adware implementation weaknesses~\cite{superFish, lenovoWPBT}, government employee data breaches~\cite{govHack}, code implementation concerns~\cite{stageFright}, and other update security concerns~\cite{googleAndroid, androidMarshmallow} one can see that a lack of standardized security design and implementation can render catastrophic failure.  This issue is further exacerbated by how vast the problem space is (e.g. secure software, trusted platform modules, new authentication methods)~\cite{aaraj2008analysis, denning1996location, %mapayi2013evaluating, lin2015security, shi2013new, son2015software, 
saito2015case, denning2015toward, nguyen2015model, ravi2004security, gokhale2008model, perez2006vtpm, yan2015novel, tehranipoor2015dram}.


Security is always evolving as knowledge
of encryption techniques, authentication technologies, access control methods and other security mechanisms change over
time.  From a system design standpoint, one has to balance security needs with traditional system design properties.
%  Similarly tolerance, chip capabilities, power distribution of hardware design, signal lag and crosstalk are important in terms of hardware considerations.  
The primary cost of incorporating security into the design process and actually operating a secure system is time.  There are the monetary and hardware costs of security development and implementation, but even those aspects all have a time cost coupled with them.  A lack of formal definition of standards lends to the heavy time cost of designing and implementing a security framework.  One needs to settle on an effective methodology that has enough rigidity to act as a standard, but still maintains a degree of flexibility to allow for further expansion and future development.  Security must be paramount in design from the very beginning of any development cycle.

Security has many facets to it: failure, processes, security mechanisms, security principles, security policies, trust, etc.  Security vulnerabilities are mainly due to incorrect implementations or incorrect assumptions about functionality, both of which are easily avoided by rigorous planning and design.  Further complications can arise when implementing different concepts and methods for creating layers of security.  The key aspects to simplifying this daunting field are standardization of encryption algorithms, authentication methods and communication protocols.  Work made towards this goal include a framework for the derivation of system requirements by the Common Criteria standard~\cite{CommonCriteria}, review and analysis of fundamental security principles over more than four decades of research and development in information security technology~\cite{benzel2005design}, and work to include security into systems that had not been designed for security~\cite{lin2013security}.  While there are existing tools for the validation and verification of existing security models (e.g. Resolute for AADL), there is a severe lack of tools to generate security models.  

A key contribution of this paper is to present a design framework built around security aware requirements and specifications.  Embedded systems design has always been a difficult problem even without considering security.  However, platform-based design~\cite{sangiovanni2007quo} has shown itself as an effective methodology to make traditional embedded systems design more tractable.  Thus, in presenting our framework, we use platform-based design as the underlying design methodology and extend it to include security design as well.
%This paper aims to exemplify use of PBD's mapping function for performing secure embedded design.  

The paper is organized as follows: Section~\ref{sec:background} presents a short introduction to platform-based
design and introduces the AADL as a design modeling language that can be extended to support the modeling of
security primitives.  In Sections~\ref{sec:requirements} and~\ref{sec:components}, we explore the use of
detailed security models in component and platform specifications along with the complications and constraints
that arise.  Section~\ref{sec:mapping} examines the mapping problem in the context of secure system design and
the considerations that come into play while developing a mapping function.  Finally, we close in Section
\ref{sec:conclusions} with final thoughts and conclusions of the work presented along with future work of this
research.

\section{Background}
\label{sec:background}
\subsection{Platform-Based Design}
\label{sec:PBD}
In platform-base design (PBD), the partitioning of the design into hardware and software is
not the essence of system design as many think, rather, it is a
consequence of decisions taken at a higher level of
abstraction~\cite{sangiovanni2007quo}.  
Higher level decisions lend to the design traits that are
requirements at lower levels.  Additional levels of abstraction (along with
virtualization tools for design space exploration) can simplify
the design process.  Abstraction levels also deal with critical
decisions that are about the architecture of the system~\cite{sangiovanni2007quo,
  pellizzoni2009handling}.  These critical paths can be determined based on
`pivot-points' or characteristics that restrict the behavior and
function of a given element/component, or based on requirements
for functional behavior requested by the end-user.  In
certain scenarios, these critical decisions can be centered around
`safety-critical' elements, as seen in embedded systems
deployed in the medical market (e.g. pacemakers).  In
Figure~\ref{fig:RecursivePBD}, each layer supports a design stage
where the performance indexes that characterize the architectural
components provide an opaque abstraction of lower layers that allows
accurate performance estimations to be used to guide the mapping
process~\cite{sangiovanni2007quo}.

Generally the mapping of a function instance towards a platform instance leads to a larger subset of platform instances branching from a single function instance; as seen in Figure~\ref{fig:RecursivePBD}.  Of course, this relationship works in the reverse manner as well; a single platform instance maps to a subset of function instances.  Although one can think of the mapping process as happening in one direction, or the other, platform-based design is a ``meet-in-the-middle'' approach.  A designer or developer works towards merging two platforms (e.g. software functionality and hardware architectures) where the resulting `middle-ground', or mapping, is its own `mapping instance'.

Before one can establish the mapping function between the functional and architectural spaces, one must first thoroughly define both the high level requirements from a design perspective as well as the lower level component specifications.  Without this rigorous documentation, it would be impossible to instantiate either of these design spaces or even begin to formulate a mapping function.  Without a standardized mapping function, one can not implement new designs that meet the requirements of the system through the functional behavior of component combinations.

These standardizations, or `contracts', are what allow developers to comprehend the current abstraction level's behavior along with how developmental changes affect functionality at varying levels of abstraction.  For the purpose of discussion, the term `contract' is seen as any form of rigorous standardization that dictates the behavior of system elements at various abstraction levels.  In essence, without thorough knowledge and documentation of these requirements (both from a functional and architectural standpoint), one can not begin implementing platform-based design or gain the added benefit of its abstracted methodology.
From a security perspective, these 'contracts' have not been well-defined and in Section~\ref{sec:components} we present some modeling approaches to fully express security properties and abstractions within the context of PBD contracts.

\begin{figure}
	\includegraphics[width=0.5\textwidth]{./images/recursivePBD.png}
	\caption{Visualization of Recursive PBD Model~\cite{sangiovanni2007quo}.}
	\label{fig:RecursivePBD}
\end{figure}

Designs with
different requirements and specifications may use different
intermediate platforms, hence, different layers of regularity and
design-space constraints per scenario.  The trade-offs involved in the
selection of the number and characteristics of platforms relates to
the size of the design space to be explored and the accuracy of the
estimation of the characteristics of the solution adopted.  The
identification of precisely defined layers where the mapping processes
takes place is an important design decision and should be agreed upon
at the top design management level or during the initial early design
phase of the system~\cite{sangiovanni2007quo}.    

PBD is built around having detailed functional requirements mapped to platforms with rich component 
specifications.  Devoid of detailed component specification, or a language with which to describe these element
properties, one does not have a foundation upon which to construct larger design combinations or the resulting
behavior and functional properties of implementations.  While there are many system and architecture modeling
languages available for use in detailing PBD requirements and specifications (such as SysML, UML, SML, AADL,
Modelica, etc.), none of them adequately express security needs.  In our work, we have chosen AADL as a starting
point because of some very minimal initial extensions to the AADL language to support security requirements
modeling.  In the following section, we introduce AADL as a descriptive modeling language and some of
its current security extensions.

\subsection{AADL}
\label{sec:AADL}
The Architecture Analysis \& Design Language (AADL) is an architecture description language standardized by the Society of Automotive Engineers (SAE).  AADL is purposed to capture system architectures with design requirements, validating that architecture, and performing early analysis to detect errors and other issues to avoid late re-engineering efforts.  AADL contains constructs for modeling both software and hardware components; hardware components named as ``execution platform'' components within the standard.  The produced architecture models can then be used either as a design documentation, for analysis or for code generation.  System and software architecture is defined through the use of specialized components with interfaces and the description of the interaction of these components with the execution environment (e.g. processor, buses).  This functionality can be further extended through different mechanisms; user-defined properties for integrating customized constraints or existing AADL Annexes.   

These inherent properties and purposed functionality of AADL make it a prime candidate as the descriptive language used to allow for platform-based design of security architecture models.  AADL requires thorough definition of both functional requirement specifications along with detailed description of the element specifications.  Although security was not an initial concern in the development of the AADL language, there has been work made to extend the language to include security-centric capabilities.  Recent work by Ellison et.~al.~\cite{ellison2015extending} 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.   The extension adds different security types (e.g. unclassified, confidential, secret, top secret) that apply to AADL elements.  The following are examples of the extension of the AADL language~\cite{ellison2015extending}.
\begin{lstlisting}
-- Property intended to be customized by modelers.
-- Parameterizes the security property definitions.
property set Security_Types is
  -- Military levels by default
  Classifications:
  type enumeration (unclassified, confidential,
                    secret, top_secret);

  -- This must be first element of Classifications
  Default_Classification:
    constant Security_Types::Classifications =>
      unclassified;
	
  -- Default set of categories
  Categories:
    type enumeration (A, B, C, D);
end Security_Types;

property set Security_Attributes is
  Class: inherit Security_Types::Classifications =>
    value(Security_Types::Default_Classification)
    applies to (data, subprogram, thread, 
                thread group, process, memory, 
                processor, bus, device, system, port,
                server subprogram, parameter, 
                port group);
  Category: inherit list of Security_Types::Categories => ()
    applies to (data, subprogram, thread, 
                thread group, process, memory, 
                processor, bus, device, system, port, 
                server subprogram, parameter, 
                port group);
  -- ...
end Security_Attributes;
\end{lstlisting}

The defined properties apply to all component and feature categories; i.e., all subjects and objects.  One can notice that the default security level is set to the lowest level.  If not otherwise specified, subcomponents and features inherit their security level from their container.  This allows for the creation of safe default property values with minimal work.  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.  It also allows one to derive minimum security requirements on hardware components given a 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.  Further extensions to the AADL language are expected~\cite{SecurityInAADL}, but the focus of this language extension is for system analysis and code generation while not focusing on low level element properties and how to map them to higher level system requirements.  As such, in this paper, we are proposing a security framework that can be adopted as an extension to AADL.

In order for the higher level functional requirements to be translated into lower level component specifications, two things need to occur: thorough documentation of the higher level requirement specifications and detailed description of the component specifications.  Platform-based design requires the definition of both the functional space (high-level requirements) and the architectural space (low-level requirements).  AADL allows for users to examine systems from a requirements specification and from elements property specifications.  Therefore it should be obvious that one can use AADL as a description language for detailing out the functional and architectural spaces that platform-based design can use to map solutions.  One can see similar adoption in the expansion of AADL to include security through a `contract-based design' model for the validation and code generation of produced security architectures~\cite{ThomasNoll}.
We examine these two needs - requirements specifications and component specifications - in the following two sections.

%The paper now moves from exemplifying the applicability of the AADL lexicon for generic system modeling to examining our proposed approaches to component specifications for security and extension to AADL to support that.

\begin{figure*}
	\centering\includegraphics[height=6.87cm]{./images/development_flow.png}
	\caption{Illustration of Platform-Based Design of Security Models.}
	\label{fig:DevelopmentFlow}
\end{figure*}

\section{Security Requirements Capture}
\label{sec:requirements}

To begin constructing a security framework for the purpose of generating effective security architecture models, one must first define the requirements of a system.  We will propose a set of cost-based security requirements that can be used to abstract the functional requirements into a mapping function and go beyond the simplistic access control model defined in the current security extensions in AADL.  These requirements will eventually map to lower level element properties, but without a rigorous definition and description of these higher level requirements it is not possible to develop measurable security metrics or even define the arbitrary scale by which these metrics are calibrated and refined.  Introducing the methodology one will use to determine the initial framework requirements is yet another layer of rigor that needs to be established.

\subsection{Security Theory/Policies}
\label{securityPolicies}
Security policies are used to describe high level requirements using language that allows for behavior in all scenarios to be regulated.  The advantage being that security policies and methodologies can be described with lower-level element abstractions derived from architectural space properties.  This is where Platform Based Design mapping can produce generated designs to be used for validation of generated cyber-physical system models.  

%Information protection, required by a security policy (e.g., access control to user-domain objects) or for system self-protection (e.g., maintaining integrity of kernel code), must be protected to a level of continuity consistent with the security policy and the security architecture assumptions; thus providing `continuous protection on information'.  No guarantees about information integrity, confidentiality or privacy can be made if data is left unprotected while under control of the system (i.e., from creation, storages, processing to interruption, and shutdown); one cannot claim to have a secure system without securing all aspects.

%To allow detailed discussion of security theory and policies, this paper uses the work of Benzel et.~al.~\cite{benzel2005design} to color the perspective on security.  The principle of `Least Common Mechanisms' states if multiple components in the system require the same function of a mechanism, then there should be a common mechanism that can be used by all of them.  The benefit of this being to minimize complexity of the system by avoiding unnecessary duplicates.  Furthermore, modifications to a common function can be performed (only) once and impact of the proposed modifications allows for these alterations to be more easily understood in advance.  The principle of `Reduced Complexity' states that the simpler a system is, the fewer vulnerabilities it will have.  From a security perspective, this simplicity makes it easier to understand whether an intended security policy has been captured in system design.  At a security model level, it can be easier to determine whether the initial system state is secure and whether subsequent state changes preserve the system security.  At the lowest level of secure data, no computer resource should be shared between components or subjects unless it is necessary to do so; the concept behind `Minimized Sharing'.  To protect user-domain information from active entities, no information should be shared unless that sharing has been explicitly requested and granted.  Minimized sharing influenced by common mechanisms can lead to designs being reentrant/virtualized so that each component depending mechanism will have its own virtual private data space.  As can be seen, there are conflicts within just these simple concepts and principles for the local scope of trustworthiness of a security component.  The principles of least common mechanism and minimal sharing directly oppose each other, while still being desirable aspects of a system.  Minimizing system complexity through the use of common mechanisms does lower hardware space requirements for an architectural platform, but at the same time does also maximize the amount of sharing occurring within the security component.  A designer must balance these two principles, but in the end the true design question is: what information is safe to share and what information must be protected under lock and key and how to then communicate that information with high security and fidelity.

We define security requirements in terms of services provided by an embedded system.  These services essentially translate to functional requirements of the system.  For example, a sensor mote may provide services such as A/D conversion, wireless transmission, remote management, etc.  These services have associated functional specifications - 0-5V dynamic range, 100m transmission distance, etc.  In addition, we add security requirements for each service that specify access control policies, privacy rules, integrity requirements, etc.  Beyond service-based requirements, each system can specify requirements with respect to data contained in the system whether persistent or transient.

\subsection{Requirements Metrics}
\label{determineMetrics}
In order to make these requirements concrete, we need ways to quantify these requirements.  One could look to reliability-based methodologies as a way to develop measurable security requirement metrics.  For example, one usually specifies mean-time-to-failure for reliability or probability that a system is functioning for availability.  These metrics are inherently probabilistic definitions.   Similarly, for security, we could state requirements that the system must provide security mechanisms such that the data can not be stolen for at least $X$ years on average or has a $Y\%$ chance of being kept secure.  Unfortunately, non-deterministic guarantees for security are not very satisfying.  Moreover, it is not clear that there is enough statistical data to build probabilistic models that could even provide these estimates.  Especially since most security mechanisms are dependent on computational complexity, any time estimates are dependent on an understanding of computational capability in the future.  One need only look over the history of encryption standards to see that Moore's law can often outstrip the lifetime of encryption algorithms.

Another approach is to specify requirements that establish bounds on the amount of resources an attacker must expend to compromise the system - e.g. data privacy is ensured against any attack consuming $\leq X$ resources (money, CPU cycles, time, etc).  In both of these instances the developer or designer is striking a balance between the requirement specifications provided and varying implementation schema for producing the desired functionality.  The overarching concern at this level of thinking is how to protect access to the system or information; which is at the core of all security design.

A central challenge in developing standards of security is defining the scale by which security metrics are measured and validated.  Difficulty in interpreting different scopes originates from how a designer or developer characterizes higher level requirements for lower level abstractions or vice versa.  In other words, the source of metrics used to evaluate how `secure' data, or a system, is will completely depend on the constraints and initial conditions that are decided upon for a given model or scenario.  

At a high level, a system-level requirement is that the ``system is secure'', but how do we represent that as a quantifiable requirement?  To begin tackling this question one must first
define what ``system is secure'' means in terms of measurable metrics.  First,
``system is secure'' at its core means no unauthorized access or alteration to data or services.  The mechanism of
attack may be subversion of authentication or access control, side channel attacks, exploitation of
cryptographic weaknesses, etc.  At the requirements level, the actual mechanism does not matter.  As for metrics for
security, there are a couple ways in which one can define these terms: (1) an attacker must spend \textit{X}
dollars before being able to obtain unauthorized access to the system or (2) an attacker must spend \textit{Y}
time before being able to obtain unauthorized access to the system.
%, (3) an attacker must observe operation of a
%system \textit{Z} times before being able to understand system operation.  It should be noted that the third
%scenario is a subset of the previous two cases; for example: one may use continued observation to determine the
%function of obfuscated sections of a system.  
%In that scenario one is taking ``safe/secure'' data could be interchanged with code functionality being ``secure/obfuscated''.

%\subsection{Cases}
To illustrate the considerations that arise when examining the aforementioned lenses for defining security terms, we take a brief look at the two proposed definitions.  In the first case an attacker is required to spend money (``\$'') to access a secure system.  The expectation in this scenario is that an attacker is buying the ability to ``break'' or ``unlock'' the system.  `Ability' is defined as the use of hardware, software, tools, or human experience.  With this definition in mind, the assumption made is an in-depth knowledge is not required because a malicious party can simply ``buy'' the needed experience from or through other contacts.  
%This assumption does not always hold true as an attacker could be well skilled/educated and only requires buying the correct equipment for the scenario.  
The second case requires an attacker to spend a specific amount of time before being able to access a secure system.  Time may include the time to learn any required knowledge, to observe operation of a
system to understand functionality.  This value of time may also be tied to the ``runtime'' required to execute a successful attack; due to focus of the attack and ``power'' of equipment used.  It should be noted that this time measurement does carry a diminishing return due to how technology evolves and the timeliness of an attack.  A key assumption in this scenario is the monetary cost of carrying out a successful attack is negligible in comparison to the necessary time constraint for performing the attack.  `Runtime' is defined as the time required to learn, tailor and execute a successful attack.  `Successful' is taken as being able to access the desired data or code functional behavior.  The major assumption is that the attacker is skilled and knowledgeable.  Of these two scenarios, examining time costs as the driving metric is most advantageous due to the inherent time cost that comes with security design.

This paper incorporates cost-based requirement specifications into security architecture development, with the
belief that this will allow for deterministic modeling of functional behavior.  This 'cost' has two different meanings based on the perspective of the attacker or defender.  Value to an attacker
is dependent on the risk inherent in performing the attack and the intrinsic value of the attack itself.  For
example, credit cards numbers can be sold for a few dollars whereas a botnet may have a value of a few hundred
dollars.  For defenders, the cost of an attack is not necessarily the same as the value accrued to an attacker. 
It comes from the risk produced by a combination of the probability of an attack occurring and the internal value
placed upon the attack.  For example, the loss of a credit card number may incur a \$50
cost to provide affected customers with identity protection services and an impact on the company reputation. 
As a system designer, one must design a system such that any security measures are cheaper than the impact of the attack.  In addition, the security measures must also provide sufficient complexity such that the
attacker's cost to attack the system are greater than the value of the attack to the attacker.   

However, before this can be
effectively implemented, one must first have rigorous standards for component specifications of security along
with detailed documentation of metrics used to evaluate and validate security properties at varying levels of
abstraction.
Therefore, the requirements must specify two constraints: the attacker's ``attack value'' as well as the system's ``attack impact''.  The design should have sufficient complexity such that the probability of attack in combination with the complexity of the attack is greater than the attack value and the probability of attack in combination with the cost of the security measures is less than the attack impact.  These metrics could be expanded with time value calculations that incorporate time as a metric.  For example, the security measures could increase the attack complexity such that the increased time to attack decreases the value of the attack.  Each service provided by the system must define these metrics.
In the following section, we show an example of the representation of these metrics.

\subsection{Requirements Lexicon Example}
\label{sec:reqlex}
To show the ease of use for AADL, we implement a user-defined abstraction of the system functional properties for the sensor mote, postulated in Section~\ref{securityPolicies}, that functions as part of an abstracted transmitter system.  First we propose that this simple transmitter could be part of a larger network of sensors used for monitoring the structural integrity of a bridge, or other public work.  Basic needs of such a system would entail the need for encryption, class of data being exchanged, authentication used for access, authorization lists for users, along with implementation of access control lists as required.
User definition of sensor implementation example:
\begin{lstlisting}
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: => 800;
          secatrb::dataleakage::atkValue: => 800;
          };
    fnc_data: abstract security_props.data_i {
          dataatrb::data_class => Sensor;
          secatrb::atkImpact => 800;
  properties
    secatrb::hasProtection => false;
    secatrb::AuthGroup => Employees;
end sysreq.wireless_sensor_i;
\end{lstlisting}

This example shows a sample of requirements for a wireless sensor with two services - A/D conversion and wireless
transmission.  There are service functional requirements designated by {\tt servatrb} - e.g. dynamic range of
the A/D or transmission distance of the wireless transmitter.  In addition, for each service there are potential
security vulnerabilities of concern as designated by {\tt secatrb}.  For example, for the wireless transmitter
there are attributes that assign values and impacts due to an attack of the authentication schemes.  Note that
all vulnerabilities must have an impact cost.  If there is no cost due to an impact, there is no reason to
develop security measure to protect against that attack.  However, not all vulnerabilities necessarily have any
value to defenders.  For example, there may be a significant impact if the A/D data integrity is compromised,
but there is no value to an attacker to do that.  Notice also that the A/D service specifies only integrity as
an issue.  Thus, in this case, the requirements state that there is no impact if an attacker actually authorizes itself to use the A/D
service.  Data that may be present in the system are represented separately as part of a data\_class with similar value and impact security attributes.
%Sensor mote implementation requirements are split between subcomponents used to detail service and data properties and the properties to describe requirements of the larger wireless sensor mote system.  Our AADL extension portrays user-defined service, data, and security attributes that corporate the functional requirements of a theorized sensor mote implementation.  
Due to the malleable nature of AADL, the `data\_class' and `AuthGroup' are extensible by the user; a user can create classes and types as needed.

\section{Component Security Properties}
\label{sec:components}
Beyond requirements, the second piece of the platform based design approach is the expression of security
properties in the components and platforms.  These architectural space security specifications can then be
abstracted along with the requirements as input for mapping into a single effective design.  As with the
requirements, we will use AADL as a modeling language to express the capabilities of the available platform or
components.  Let us create a simple low-level group of AADL security property applicable items to further expand the security properties of those elements for the purpose of presenting the foundation of a new framework.  The new simplified list of elements is as follows: data, memory, processor, bus, device, system, and port.  In order to make use of this new architectural space, one must determine the security-centric component specifications that will be used to describe the element behavior, component properties, and security specifications (as shown in Figure~\ref{fig:DevelopmentFlow}).  Figure~\ref{fig:EmbeddedSystem} is provided as a visual map of the elements.

\begin{figure}
	\includegraphics[width=0.5\textwidth]{./images/embedded_system_layout.png}
	\caption{Embedded System Layout.}
	\label{fig:EmbeddedSystem}
\end{figure}

\subsection{System}
\label{system}
A system is defined as a grouping of elements that serve a given purpose.  This grouping is created via the combination of different circuit elements to perform a specific task or function.  Further more, this new system can be abstracted into a `single layer' device object model.  

It should be noted that variations come from a mixture of different element groupings that come together to form one larger system element; due to the nature of a system there is a lot more granularity that can be used to express the properties of said system element.  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 encryption implemented to some degree.  It could be encryption 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.  The implementation would be similar to the AADL extensions mentioned in Section~\ref{sec:AADL}.  ``Systems'' are inherently problematic \textit{because} this is where in depth analysis must be done; without this there can be no assurance that a ``device'' (e.g. ``flattened layer'' of a ``system'') has a certain level of security or trust.

\subsection{Device}
\label{device}
A device is seen as a grouping of elements that has been ``flattened'' to a much simpler ``single layer'' (e.g. depth of 1) module used to express an abstracted representation of a given `system' element.  Devices are simple; in that they have basic input/output net(s) and some given functional properties and behavior.  A regular or simple device has no encryption, data access control, and the security or trust level is at the lowest default.  An encryption device with a ``noticeable'' level of encryption must be measurable and must be able to be validated by standard methods (i.e AADL Resolve verification tool).  A protected, or access control, device must have, or use, some measurable degree of access control.  This can manifest as either external access control to the given device or as internal access control of data/information that reacts to the device element's input net.  The ``assurance level'' of `devices' are directly linked to their ``system level'' representation.  Without a ``system level'' representation a device can not be measured or validated to any degree of security or trust.  Due to the arbitrary way in which security/trust is measured the different levels of security can be just about anything so long as a uniform implementation use of the decided on scale is a must.  Examples of such scales include: the default military levels (unclassified, confidential, secret, top secret) and an arbitrary 1-10 scale (1 being worst and 10 being best, or vice-versa).

\subsection{Component Lexicon Example}
Having speculated functional requirements in Section~\ref{sec:reqlex}, we move to describe the components that are used to populate the architectural space.  Following from the transmitter example, we postulate a user-defined implementation of a processor with embedded encryption capabilities.  Security centric properties are shown for exemplifying other user-defined security properties.
\begin{lstlisting}
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;
\end{lstlisting}
This processor implementation declaration is designed to show the ease by which a user can alter the AADL language to create non-standard properties representing necessary security component specifications.  The embedded processor implementation has encryption, uses an embedded module, makes use of AES-256, has no PUF or TPM implementation, does not use encrypted flash, and has no tamper proofing.  Flexibility in the language allows for ease in alteration of written models and user-defined properties and module structures.

\section{The Mapping Problem}
\label{sec:mapping}

The first step in formulating a framework is to define the inputs; these being the requirement specifications that rule the behavior of the system and the component definitions and properties that underpin all functional implementations.  As with the examinations of a transmitter device, there are a multitude of decisions and implementations that can take place at varying degrees of abstraction.  The most arduous part of this process is bridging the AADL illustrations of the functional and architectural spaces.  Each have their own language and form that need a common metric to translate the function and behavior of both spaces into a single design.  The goal is to layout the ground work for producing design implementation variations based on requirements, element properties, and component functionality available.  The next step is to describe the mapping process that will need to combine these two spaces into a single design (or series of designs; based on requirement or property needs), along with other considerations and concerns that need to be taken into account during the mapping process.  One can examine the mapping process as being considerations that need to be defined and vetted.  

Implementations of the mapping function require examination of different scenarios that can occur in the design
process due to constraints of a given system and/or due to optimizations required, or desired, by developers and
users.  At different levels of abstraction, along with different implementations, there are different challenges
and concerns that need to be tackled by a developer or designer.  These include optimization and constraint
concerns that have influenced the types of technology and properties that are chosen to meet a desired design or
used to abstract behavior and functionality.

\subsection{Mapping Implementation Example}
When implementing abstractions of the functional and architectural spaces there are two major issues that need tackling: (1) proper exploration of the entire design space and (2) optimization of the abstractions.  Having the security component specifications defined in a meaningful way allows for examination of trade-offs and allows for implementation of the mapping function. 

\subsubsection{Lowest Level}
Secure system design is probably the most involved at the lowest level of design (architectural space).  The reason being that design of new systems, devices, and modules requires the examination of a plethora of security properties for different elements, along with investigation of how these properties combine and the negative and positive effects of said combinations.  The exploration of this security design base is not just limited to the security properties of the element, but must also include the physical element properties such as heat distribution, power consumption, etc.  These issues are further exacerbated when designing for embedded systems due to the extreme constraints that these ubiquitous devices must maintain. 

\begin{figure}
	\includegraphics[width=0.5\textwidth]{./images/encrypted_transmitter.png}
	\caption{Varying Design Implementations of Simple Encrypted Transmitter: (1) Simple Design, (2) Pure Encryption with Separate I/O Buses, (3) Pure Encryption with Shared Bus, (4) Embedded Encryption with Separate I/O Buses.}
	\label{fig:SimpleExample}
\end{figure}


For example: designing an IoT device that must encrypt sensor data before transmitting said information back to a central base station; using Figure~\ref{fig:SimpleExample} as a reference.  Common expectations for this device include: reliability of `data passing', minimal power consumption, and optimized speed of encryption.  Each of these requirements are relatively simple to meet, but when paired together in the design of a system they can cause contradictions.  For example, a simple system that is both well managed from a power consumption standpoint but also minimizes the time spent performing encryption.  
One can assume that encryption is either an embedded element of the system's processor \textit{or} the processor has been fully optimized for cryptographic processes.  In the ideal case, a developer may choose the `pure encryption' model of a system processor to minimize encryption time to help maximize data throughput, which may also aid in system reliability.  However, due to this design choice, the `pure encryption' processor may heavily sacrifice power efficiency in favor of other constraints.  Therefore a developer may prefer use of an `embedded encryption' processor for more manageable power efficiency, or perhaps one is able to develop a `pure encryption' processor that is optimized for power efficiency constraints.  We postulate an implementation of the transmitter system in the AADL lexicon.

\begin{lstlisting}
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;
\end{lstlisting}
By no means is this the only possible design decision, frankly just a simplified illustration of design implications.

While developing a secure design architecture for a simple encryption device has its challenges, these problems grow exponentially when developing larger, more complex, systems.  As outlined in Section~\ref{system}, the combination of various low-level elements can lead to a variety of system properties and behaviors.  While some resulting properties are more simplistic such as input/output bus behavior, 
%and property expectations, 
others are more widely effected by design element decisions (e.g. processor, data, memory encryption).  Further more, these `system' groupings of elements need to be described with such language as to allow their individualistic element properties to be translated into abstracted `device' properties.  Without a fully encompassing view of architectural space behavior and the requirement specifications of the function space, one is unable to reap the benefits of combining platform-based design with the AADL language specification to thoroughly explore the security design space.

\subsubsection{Abstracted Levels}
How does one go about characterizing elements and properties in meaningful ways that can translate into assurances and guarantees for various abstraction levels?  Encryption could be defined as the ``protection'' of data via ``obfuscation of data''.  ``Protection'' can be defined as some form of access control mechanism dictating which users or processes can access or manipulate data.  Some mixture of these two (i.e. encryption and protection) can be implemented and used to describe a system, but it can be difficult depending on what ``scale'' each property uses to measure or compare values.  It must be noted that despite the focus on security-based properties, even these elements (i.e. encryption) carry other functional properties that affect a given system (e.g. heat/power usage).  Despite this fact it would still be possible to use ``element property'' arithmetic to translate the model to formal verification tools (e.g. Hoare Logic).  Mixtures of assurances and guarantees need formal definition because as abstracted levels are defined, these properties need to translate across the same abstracted levels.  

In a similar vein, one must break down the high-level requirements for a system design into subgroups that can be better defined or implemented using lower level abstractions.  It is here that one should see the advantage of using a platform-based design methodology to both build up the language to abstract the architectural space towards ``higher'' levels and to solidify requirements of the functional space creating ``lower'' level abstractions.  Meet in a middle mapping can be used recursively to effectively explore the entire design space for optimal constraint solutions.  But even this requires time and effort to figure out an effective and convenient language methodology for generating any new model.  The next section examines the mapping function and complications that can arise in its definition.
  
\subsection{Automated Mapping Considerations}
Creating a model for a new system is not a simple process.  Without any form of automation, it requires that a knowledgeable individual or team to account for a large number of potential constraints: power consumption, heat production and distribution, operating range, throughput, and reliability.  To make this process even more complicated, the developer(s) need to also account for any lower-level elements that will not work well with each other.  One way a developer can get around this is to add negative penalties to problematic designs that could either not produce the properties desired or that creates a negative effect upon the system.  A designer could make use of  various optimization approaches such as nonlinear/linear programming, genetic algorithms, etc. as a methodology 
for determining the most advantageous of design solutions generated.  With the addition of security, optimization becomes far more complicated as security overhead will need to be accounted for along with adaptability for the security implementation to grow and evolve with the needs and development of the parent system.  Since security requirements can be described, or defined, in a variety of ways, security optimizations can change depending on the operational constraints.

Security component definitions relate to the security properties that different components have based on the definitions of their behavior and functionality.  Security properties, at the component definition level, include more physical properties of the varying components: reliability, confidentiality, uniqueness.  A processor's properties could manifest as cryptographic functionality, is the component a TPM~\cite{aaraj2008analysis, perez2006vtpm}, secure key storage/protection, PUF availability~\cite{tehranipoor2015dram}, uniform power consumption as a countermeasure to side-channel attacks~\cite{danger2009overview}, unexposed pins using a ball grid array (BGA), specific power drain/usage restrictions for operational functionality, anti-tampering or anti-reverse engineering properties of a component, etc.  A developer or designer will need to determine just how low-level the architectural space will go, along with the properties that must be noted and maintained at such a level.  Further more, the exploration of this design space will lead to creating higher-level implementations and functionality that is derived from the lower-level components.

The following theorizes different ways and methods by which a developer can go about mapping the higher-level functional space to the lower-level architectural space, or vice versa.  Common concerns in implementation are rooted in existing system constraints, how a designer or developer handles edge cases, and how those generated solutions are evaluated and ranked.  These scenarios include: how to implement efficient cryptographic measures, how do power consumption and battery life affect the reliability of a given device, are the advantages of a given solution outweighed by inherited constraints.  Furthermore, extending these concerns to an automated implementation: how does one track proposed solutions, how are these generated solutions compared and evaluated, are there penalties for `undesired' designs, and how does one define and measure these penalties.

\subsubsection{Element Properties}
Examination of different properties that system or device elements can have and how they manifest depending on design constraints, optimizations, and implementation decisions is central to the discussion as to why certain architectural space elements should be chosen over others.  As with VLSI, the nature of the issue depends on desired functionality, behavioral properties, and scenario of operation that a given element, or abstraction, must fulfill.

Ports can be subdivided, by functionality, as being either single-direction or bidirectional.  The advantage is one could use single-direction and bidirectional ports to implement different ``security levels''.  This could easily be extended as a manner of protection to ensure that the flow of information within a system only moves in the desired direction.  Memory and data storage is another section that can be equally divided depending on desired behavioral functionality.  Use of volatile memory for holding sensitive variables or data could carry an additional `security benefit'.  One could model memory to power down or clear after key usage.  Expectation is developers would most likely find this variety of memory is only effective when used for sensitive, non-critical data.  Further sublimation of these concepts and subdivisions of proposed low level elements requires implementation and analysis to determine how these properties and functional behaviors may effect different abstraction levels within the security model.  The methods by which different security elements are combined and the approach used for their combination can cause previously accepted techniques to fall apart due to mismatched assumptions or understanding of functional implementation.  The requirement to re-evaluate design when decisions are made is why working to automate the process is paramount for thorough exploration of the architectural design space.

\subsubsection{Security Policy Composition}
Rigorous definitions of input/output nets for components and the methods for communication must be documented and distributed as the standard methods for communicating.  Service, defined in the scope of a network, refers to processing or protection provided by a component to users or other components. E.g., TCP/IP, encryption, firewall.  Since these services, and their actions, are central to the operational behavior of a secure system, there are a series of considerations, principles, and policies that one must acknowledge.  Principle of Secure Communication Channels states that when composing a system where there is a threat to communication between components, each communications channel must be trustworthy to a level commensurate with the security dependencies it supports; how much is the component trusted to perform its security functions by other components.  Use of a channel may be restricted by protecting access to it with a suitable access control mechanism.  End-to-end communications technologies may be used to eliminate security threats in the communication channel's physical environment.

Security policies may require granularity for dictating element or system functionality when in isolation versus when synced with a network.  `Self-Reliant Trustworthiness' means that systems should minimize their reliance on external components for system trustworthiness.  A corollary to this relates to the ability of a component to operate in isolation and then resynchronize with other components when it is rejoined with them.  If a system were required to maintain a connection with another external entity in order to maintain its trustworthiness, then that very system would be vulnerable to drops in communication channels.  Thus from a network standpoint, a system should be trustworthy by default with the external connection being used as a supplement to the component's function.

In all of this, a developer must consider how each of these policies and principles will reverberate through each layer of abstraction and manifest as functional behavior or properties of a device.  As constraints are determined and applied, the methods of implementation will change and the generated security architecture and models must be evaluated and ranked for supplementary refinements of the design.

\section{Conclusions and Future Work}
\label{sec:conclusions}
In summary, in order to effectively design embedded systems, it is absolutely necessary that we are able to
capture the system security requirements and in order to translate those requirements to designs the
platforms/components must be well defined with respect to their security capabilities and properties.  We have
expanded the AADL language to account for security properties and policies that affect form and function of a
system from its lowest level elements.  We have also presented a formalization of the higher level requirements,
and the most advantageous method is to model cost-based requirements where the driving factor is time.  With
this information it is possible to begin tackling the complicated problem of developing a mapping function
between these two spaces.  The proposed design framework model can serve as the jumping point for establishing a
formal mapping function.  While this issue can appear tortuous, it is one that needs to be solved.  Through this
paper's examination of these complications, the foundations have been laid so that
the focus of further investigations can be purposed at producing an automated method for security architecture
model development and design.

Ideally, industry is looking for assurances that one can do different things to ensure different security levels.  Do `x' number of things by default to ensure a certain level of security.  While this would be advantageous from a business standpoint, such a view of security is problematic.  At the most basic level, security is more binary than anything else; a system is either secure or vulnerable.  One can not have a system that is a little less, or a little more, vulnerable.  Although, in terms of design development, it is possible that certain areas of a design architecture can be more, or less, aggressive in their implementation of security standards.  For this reason, one needs a set of rigorous standards that can be followed to ensure the security of a system and protection of its data and information.  These standards need to be written in a descriptive enough language to allow for resilience of the design, yet flexible enough to allow for expansion and customization of security behavior and implementation.

Creating, defining, and implementing a new security modeling framework is no simple task.  As such, this paper
has laid the groundwork for expanding the AADL language to allow for platform-based design of security
centric embedded, real-time system modeling.  Future work for this line of research includes: formalizing the
security properties of low-level elements that can be used for translating high-level requirements into
meaningful element models/systems/devices, defining the higher-level requirements into the AADL language,
creating translation schemes for interpreting the requirement specifications into element security features and
vice-versa, thus creating the foundation for developing an effective mapping function that can automate security
model generation; and better standardize how the community tackles these concerns from the very beginning of
design.
%Furthermore, AADL has announced the release of additional security tools for the AADL language in the Spring 2016.  While these tools maybe extraordinarily useful they too may not yet be perfect.  Therefore it would be in the best interest to examine these new tools upon release, compare them to the framework proposed here, and see what aspects of each framework/language extensions benefit, or hinder, the thorough exploration of the security design space.  Only with this extensive exploration and system security architecture analysis can the research community better their secure system development and improve security tools for generation and examination.  
In this paper, we have shown the advantage of combining platform-based design and the AADL modeling language to allow for greater exploration of design spaces while including the necessary security considerations that have become more and more paramount as embedded systems/IoT become more widespread and create larger and larger interconnected networks of ubiquitous devices.
%\end{document}  % This is where a 'short' article might terminate

%ACKNOWLEDGMENTS are optional
%\section{Acknowledgments}
%This section is optional; it is a location for you
%to acknowledge grants, funding, editing assistance and
%what have you.  In the present case, for example, the
%authors would like to thank Gerald Murray of ACM for
%his help in codifying this \textit{Author's Guide}
%and the \textbf{.cls} and \textbf{.tex} files that it describes.

%
% The following two commands are all you need in the
% initial runs of your .tex file to
% produce the bibliography for the citations in your paper.
\balance
\bibliographystyle{abbrvurl}
\bibliography{sigproc}  % sigproc.bib is the name of the Bibliography in this case
% You must have a proper ".bib" file
%  and remember to run:
% latex bibtex latex latex
% to resolve all references
%
% ACM needs 'a single self-contained file'!
%
%APPENDICES are optional
%\balancecolumns
%\appendix
%%Appendix A
%\section{Headings in Appendices}
%The rules about hierarchical headings discussed above for
%the body of the article are different in the appendices.
%In the \textbf{appendix} environment, the command
%\textbf{section} is used to
%indicate the start of each Appendix, with alphabetic order
%designation (i.e. the first is A, the second B, etc.) and
%a title (if you include one).  So, if you need
%hierarchical structure
%\textit{within} an Appendix, start with \textbf{subsection} as the
%highest level. Here is an outline of the body of this
%document in Appendix-appropriate form:
%\subsection{Introduction}
%\subsection{The Body of the Paper}
%\subsubsection{Type Changes and  Special Characters}
%\subsubsection{Math Equations}
%\paragraph{Inline (In-text) Equations}
%\paragraph{Display Equations}
%\subsubsection{Citations}
%\subsubsection{Tables}
%\subsubsection{Figures}
%\subsubsection{Theorem-like Constructs}
%\subsubsection*{A Caveat for the \TeX\ Expert}
%\subsection{Conclusions}
%\subsection{Acknowledgments}
%\subsection{Additional Authors}
%This section is inserted by \LaTeX; you do not insert it.
%You just add the names and information in the
%\texttt{{\char'134}additionalauthors} command at the start
%of the document.
%\subsection{References}
%Generated by bibtex from your ~.bib file.  Run latex,
%then bibtex, then latex twice (to resolve references)
%to create the ~.bbl file.  Insert that ~.bbl file into
%the .tex source file and comment out
%the command \texttt{{\char'134}thebibliography}.
%% This next section command marks the start of
%% Appendix B, and does not continue the present hierarchy
%\section{More Help for the Hardy}
%The sig-alternate.cls file itself is chock-full of succinct
%and helpful comments.  If you consider yourself a moderately
%experienced to expert user of \LaTeX, you may find reading
%it useful but please remember not to change it.
%\balancecolumns % GM June 2007
% That's all folks!
\end{document}