Skip to content
Permalink
5f940c45d9
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

AADLPaper_CANS/AADLSecPaper.tex

Go to file
 
 
Cannot retrieve contributors at this time
607 lines (562 sloc) 29.5 KB
Raw Blame
% This is based on the LLNCS.DEM the demonstration file of
% the LaTeX macro package from Springer-Verlag
% for Lecture Notes in Computer Science,
% version 2.4 for LaTeX2e as of 16. April 2010
%
% See http://www.springer.com/computer/lncs/lncs+authors?SGWID=0-40209-0-0-0
% for the full guidelines.
%
\documentclass{llncs}
% Table package needs
\usepackage{tabularx,booktabs}
\usepackage{multirow}
\usepackage[normalem]{ulem}
\usepackage[english]{babel}
% Image package needs
\usepackage{graphicx}
%\usepackage{graphics}
% Equation packages
\usepackage{amsmath}
\usepackage{listings} % Include the listings-package
\usepackage{color}
\usepackage{balance}
\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}
\title{An adversarial risk-based approach to embedded systems security modeling}
%
\titlerunning{AADL Security} % abbreviated title (for running head)
% also used for the TOC unless
% \toctitle is used
%
%\author{Paul Wortman \and John A. Chandy}
%
%\authorrunning{Ivar Ekeland et al.} % abbreviated author list (for running head)
%
%%%% list of authors for the TOC (use if author list has to be modified)
%\tocauthor{Ivar Ekeland, Roger Temam, Jeffrey Dean, David Grove,
%Craig Chambers, Kim B. Bruce, and Elisa Bertino}
%
%\institute{University of Connecticut, Storrs CT 06269, USA}%\\
%\email{I.Ekeland@princeton.edu},\\ WWW home page:
%\texttt{http://users/\homedir iekeland/web/welcome.html}
%\and
%Universit\'{e} de Paris-Sud,
%Laboratoire d'Analyse Num\'{e}rique, B\^{a}timent 425,\\
%F-91405 Orsay Cedex, France}
\maketitle % typeset the title of the contribution
\begin{abstract}
%AADL is a common use language that has been developed and tweaked over the years to allow the ability to
%describe model behavior and specifications, with more recent attempts to define language for security
%requirements and verification. This paper examines previous implementations of behavior, requirements, and
%security in AADL and then goes to propose a new framework for better integration and description of security
%requirements and behavior within the AADL lexicon.
\textbf{Something something abstract}
\keywords{security modeling, security framework, secure system design}
\end{abstract}
\section{Introduction}
Talk about need for a new security framework in AADL. What is missing, what is needed.
What will this paper be bringing to the table?
\section{Motivation and Related Work}
Points to make in this section of the paper:
\begin{itemize}
\item Recap summary of the SSR paper/
\begin{itemize}
\item What has been done by others to expand the security capabilities of AADL?
\begin{itemize}
\item Work to describe behavior, errors, some security properties in terms of verification and validation.
\item Attempts always being made to improve AADL and incorporate more in the description and detail of the language
\end{itemize}
\item What is missing from the work of others?
\begin{itemize}
\item Current language standards used to describe security concepts, requirements, and constraints has not been developed well enough to be `all-encompassing'.
\item Need to develop a method for calculating `estimation metrics' that can be used to compare and contrast generated solutions.
\end{itemize}
\item What needs to be brought to the table for improving AADL into a security modeling language?
\begin{itemize}
\item Account for a security metric that is `relatively deterministic'.
\item Have a basic `unit of measure' that allows for `easy' interpretation of developed/calculated metric.
\item \textbf{Note:} Easiest is a monetary amount (USD). Since everything carries some weight of time (development, testing, production, design), then at some point one will need to convert a unitless metric to a time metric to a monetary metric. (Perhaps a monetary over time unit?).
\end{itemize}
\end{itemize}
\end{itemize}
\begin{lstlisting}[caption={AADL Security Annex Definitions of Encryption~\cite{AADLSecAnnex}},label={lst:AADLSecEncryption}]
encryption : security_properties::encryption_type applies to
{port, virtual bus, bus, memory, access};
encryption_type : type record (
method : security_properties::supported_encryption_method;
algorithm : security properties::supported_encryption_algorithm;
public_key : aadlstring;
private_key : aadlstring;
key : aadlstring;
operation_mode : security_properties::supported_operation_mode;
};
supported_encryption_method :
type enumeration (symmetric, asymmetric, clear);
supported_encryption)algorithm :
type enumeration (tripledes, des, rsa, blowfish, aes, clear);
supported_operations_mode :
type enumeration (ecb, cbc, pcbc, cfb, ofb, ctr);
\end{lstlisting}
% Add in an image of the drawing from the bulletjournal on the process
\begin{figure}
\centering\includegraphics[height=6cm]{./images/aadl_security_framework.png}
\caption{Visualization of Security Framework}
\label{fig:AADLSecFrame}
\end{figure}
The new security framework that this paper proposes would require the following steps to take place:
\begin{enumerate}
\item Creation of a low-level component library that would contain normal and secure version implementations of each base component within the architectural space used for model generation.
\item Formalized description and definition of higher level security requirements that may come from user-defined needs or from the experience of knowledge of security experts.
\item Creation of a mapping process by which security requirements and secure component specifications can be uniformly compared to allow for the generation of potential secure architectural system model solutions to the given inputs.
\item Verification tools to validate mapping implementation solutions.
\end{enumerate}
Other additional aspects of this framework, that could come from the existing tools, extensions, and annexes would include code generated using the secure models. Work towards developing these sorts of tools for secure architectures (e.g. seL4) is already one of the focuses of current AADL security annex work~\cite{AADLSecAnalysis}.
\section{Defining Risk}
The following are the points to make in this section of the paper:
\begin{itemize}
\item Talk about how Risk is defined differently depending on the point-of-view. How will risk be examined for the purpose of this paper?
\begin{itemize}
\item This paper's definition of risk and cost modeling is the core of this paper.
\end{itemize}
\end{itemize}
How to define `Risk'?
\begin{itemize}
\item Needs to be represented as a probability
\begin{itemize}
\item means that this value acts as a 0.00 - 1.00 scale weight.
\end{itemize}
\item Risk generally represented as:
\begin{equation}
Risk = Probability * Impact
\end{equation}
\item How to add `Security' to the risk calculation?
\begin{multline}
`Security Risk' = `Security Metric' * direct attack probability * `cost' weight \\
+ ... + `Security Risk' * indirect attack probability * `cost' weight
\end{multline}
\item Once risk has been defined in the scope/lens of examination, can develop an `Estimation Metric' that can be compared and contrasted with each other to determine the `value'/`worth' of any given design.
\end{itemize}
One can measure risk from the probability of a failure of a given component (e.g. firewall, anti-virus, both), the loss amount for each component failure (e.g. firewall, anti-virus, both, none), and the expected loss (average loss)~\cite{Mukhopadhyay2013}.
\begin{equation} \label{equ:expectedLoss}
Expected Loss = Risk Frequency * Risk Amount \cite{Mukhopadhyay2013}
\end{equation}
Risk is not a certainy, but a proability. (All from \cite{Ferrante2013})
\begin{itemize}
\item Possibility depends on two aspects: (1) threat and (2) vulnerability
\begin{enumerate}
\item Threat - cause of risk (e.g. fire, kidnapping, leakage of sensitive information, etc.)
\item Vulnerability - exiting flaw or weakness which can be exploited and result in an accident
\end{enumerate}
\item Risk states that risk may result in losses for an agent
\begin{itemize}
\item Losses occur because of the consequences of an accident (called Impact)
\end{itemize}
\end{itemize}
Depending on impacted assest `Impact' may be:
\begin{enumerate}
\item Tangible (e.g. loss of revenue or financial penalties)
\item Intangible (e.g. loss of productivity or loss of reputation)
\end{enumerate}
`Asset' = anything valuable to a user/organization.
\begin{itemize}
\item can be (1) a physical object, (2) secrete information, (3) business goal, etc.
\end{itemize}
Risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact.
Complications in Risk Indentification can come from:
\begin{enumerate}
\item Lack of experience and standards - novel and have not yet standardized procedures for dealing within `Cyber-domain'
\item Evolution of System - computer systems evolve fast/quickly, system of an organization can change quickly, new technologies appear very often; changing the landscape of `cyber risks'
\end{enumerate}
Security levels are interdependent depending on implementation and scenarion/situtation.
\section{Introducing the Framework}
Give a detailed description of the framework at this point in time. What is there and what the paper will present.
\begin{itemize}
\item Need to create a matric of weights based on the relative importance of any given solution $s_i$ in comparison to solution $s_j$~\cite{Ferrante2013}.
\item \textit{Importance} is defined as: `case of implementation by a given company/group.
\item Will be partially arbitrary and partially cost analysis.
\item Could also come from the preference/wheel house of a given company.
\end{itemize}
\begin{multline} \label{equ:securityMetric}
`Security Metric' (Security Level) = \\
weight_{component capability 1} * Security Level_{component capability 1} \\
+ weight_{component capability 2} * Security Level_{component capability 2} \\
+ {...} + weight_{component capability n} * Security Level_{component capability n}
\end{multline}
\textbf{Note:} Not sure if `component capability' is the right way to describe different algorithms, elements, properties, and capabilities of these different elements of a system/device. Equation is not necessarily limited to a single use within entire process.
Example of calculating aggregated security metrics of a system (i.e. network security):
\begin{multline} \label{equ:overallSecMet}
`Overall Security Metric' = weight_{anti-virus} * Security Metric_{anti-virus} \\
+ weight_{firewall} * Security Metric_{firewall} \\
+ weight_{element i} * Security Metric_{element i}
\end{multline}
\begin{multline} \label{equ:securityRisk}
`Security Risk' = Security Level * direct attacker probability * cost weight \\
+ Security Level * indirect attacker probability * cost weight
\end{multline}
\begin{multline} \label{equ:estimationMetric}
`Estimation Metric' = `User Risk Type' * `Security Risk' + `implementation cost' + \\
`maintainence cost' + `solution metric' * `requirements weight'
\end{multline}
\section{Exploring a Simple Implementation}
How does a simple examples such as a wireless transmitter get represented in this new framework?
% Add in the table of elements and variations
\begin{table*}[]
\centering
\caption{Table illustrating different component variations}
\label{elementTypes}
\begin{tabular}{@{}llllll@{}}
\toprule
\multicolumn{6}{c}{Component Types Table} \\ \midrule
\multicolumn{1}{c}{\multirow{2}{*}{{\underline{\textbf{Elements}}}}} & \multicolumn{5}{c}{\textbf{Types}} \\
\multicolumn{1}{c}{} & \multicolumn{1}{c}{{\underline{\textbf{I}}}} & \multicolumn{1}{c}{{\underline{ \textbf{II}}}} & \multicolumn{1}{c}{{\underline{\textbf{III}}}} & \multicolumn{1}{c}{{\underline{\textbf{IV}}}} & \multicolumn{1}{c}{{\underline{ \textbf{V}}}} \\
Memory & Unprotected & Protected & Encrypted & Obfuscated & Combo \\
Bus & Unprotected & Encrypted & Non-sniffable & & \\
Processor & Simple & Embedded Encryption & Pure Encryption & & \\
Data & Plain-text & Encryption & Protected & & \\
Port & Normal & Encrypted & Protected & & \\ \bottomrule
\end{tabular}
\end{table*}
\begin{lstlisting}[caption={Example of User-defined Lower Level Components},label={lst:AADLUserDefineLow}]
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;
\end{lstlisting}
\subsection{Expanding Considerations}
What other additional expansions can be made to the simple wireless transmitter example? Additional costs, variables, levels of additional detail.
\begin{lstlisting}[caption={User-defined Higher Level Security Requirement},label={lst:AADLUserDefineHigh}]
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}
\begin{multline} \label{equ:probRating}
`Probability Rating' = weight_{sensitivity of data} * `known vulns metric' \\
+ weight_{exposure} * Security Level Metric_{data?}
\end{multline}
\begin{multline} \label{equ:wealthFunction}
`Wealth Function' = Probability Nothing Happens * Initial Wealth \\
+ Probability Event Happens * (Initial Wealth - Losses) \cite{Ferrante2013}
\end{multline}
`Initial Wealth' can be calculated from the design model generated. \textbf{Note:} `Wealth Function' is focused on the future and use of a given system within an organization.
\section{Examining Attack and Defense with Detail}
Examination of encryption and authentication processes through the lens of the new security framework.
Can create a `correlation matrix' of the inacted defenses and the affect of failure of one defence on the other existing defense (0-1 scaled as well).
\subsection{Expansion of Details}
Expand further on additional details and variables that can affect the modeling of secure system solutions.
\section{Additional Concerns}
Detail out the concerns about for needs of `libraries' of information and other data that will be required for greater formalization of calculated values.
Point is to try and have as few `unitless' metric values due to their arbitrary nature. At least will need to convert values to monetary value at some point since time can equal \$\$\$.
\section{Conclusion}
What has this paper shown? What needs to be worked on moving forward?
%
% ---- Bibliography ----
%
\begin{thebibliography}{5}
\bibitem {Ferrante2013}
Ferrante, A., Milosevic, J., Janju\u{s}evi\`{c}, M.:
A Security-enhanced Design Methodology for Embedded Systems,
International Conference on Security and Cryptography (SECRYPT) (2013)
\bibitem {Mukhopadhyay2013}
Mukhopadhyay, A., Chatterjee, S., Saha, D., Mahanti, A., Sadhukhan, S.k.:
Cyber-risk decision models: To insure IT or not?,
Decision Support Systems, Volume 56 pages 11--26 (2013)
%\bibitem {SysML-Sec}
%SysML-Sec,
%\url{http://sysml-sec.telecom-paristech.fr/}
%
%\bibitem {jurjens2005secure}
%J{\"u}rjens, J.:
%Secure systems development with UML,
%Springer Science \& Business Media (2005)
%
%\bibitem {jurjens2002umlsec}
%J{\"u}rjens, J.:
%UMLsec: Extending UML for secure systems development,
%UML 2002—The Unified Modeling Language, Springer Publishing, pages 412--425 (2002)
%
%\bibitem {SysML}
%SysML,
%\url{http://sysml.org/}
%
%\bibitem {AADLSite}
%AADL,
%\url{http://www.aadl.info/aadl/currentsite/}
%
%\bibitem {AADLV2Overview}
%Feiler, P.:
%SAE AADL V2: An Overview.
%Carnegie Mellon University (2010)
%
%\bibitem {AADLTools}
%AADL Tools,
%\url{https://wiki.sei.cmu.edu/aadl/index.php/AADL\_tools}
%
%\bibitem {Osate2}
%Osate 2,
%\url{https://wiki.sei.cmu.edu/aadl/index.php/Osate\_2}
%
%\bibitem {Osate2Examples}
%Osate 2 Example Repository,
%\url{https://github.com/osate/examples}
%
%\bibitem {UserDaysMay2016}
%User Days - May 2016,
%\url{https://github.com/saeaadl/userdays/tree/master/UserDays/May2016}
%
%\bibitem {AADLResolute}
%Resolute Website,
%\url{http://loonwerks.com/tools/resolute.html}
%
%\bibitem {RDALOverview}
%Blouin, D.:
%AADL Requirements Annex Review,
%\url{http://www.aadl.info/aadl/downloads/committee/feb2013/presentations/aadl\_standards\_requirements\_annex\_review\_06022013.pdf}
%
%\bibitem {gacek2014resolute}
%Gacek, A., Backes, J., Cofer, D., Slind, K., Whalen, M.:
%Resolute: An assurance case language for architecture models,
%ACM SIGAda Ada Letters, Volume 34 Number 3, pages 19--28 (2014)
%
%\bibitem {EMV1}
%Feiler, P.:
%SAE AADL Error Model Annex: An Overview,
%\url{https://wiki.sei.cmu.edu/aadl/images/1/13/ErrorModelOverview-Sept222011-phf.pdf}
%
%\bibitem {EMV2}
%Feiler, P.:
%SAE AADL Error Model Annex: Discussion Items,
%\url{https://wiki.sei.cmu.edu/aadl/images/1/13/ErrorModelOverview-Sept222011-phf.pdf}
%
%\bibitem {BLESS2013}
%Larson, B.R., Chalin, P., Hatcliff, J.:
%BLESS: Formal Specification and Verification of Behaviors for Embedded Systems with Software,
%\url{https://ti.arc.nasa.gov/m/events/nfm2013/pubs/BLESS.pdf}
%
%\bibitem {AADLSecAnnex}
%Delange, J., Feiler, P., Klieber, W., Nam, M., Seibel, J.:
%AADL Security Annex,
%\url{https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/security-annex-May2016.pdf}
%
\bibitem {AADLSecAnalysis}
Delange, J., Nam, M., Seibel, J.:
AADL Security Analysis Tools,
\url{https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/security-analysis-May2016.pdf}
%
%\bibitem {ellison2015extending}
%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)
%
%\bibitem {jeepHack}
%Drozhzhin, A.:
%Black Hat USA 2015: The full story of how that Jeep was hacked,
%\url{https://blog.kaspersky.com/blackhat-jeep -cherokee-hack-explained/9493/}
%
%\bibitem {planeHack}
%Zetter, K.:
%Feds say that banned researcher commandeered a plane,
%\url{http://www.wired.com/2015/05/feds-say-banned-researcher-commandeered-plane/}
%
%\bibitem {superFish}
%Hope, P.:
%Superfish adware weakens security and injects ads on some Lenovo laptops,
%\url{http://www.techrepublic.com/article/superfish-adware-weakens-security-and-injects-ads-on-some-lenovo-laptops/}
%
%\bibitem {lenovoWPBT}
%Sanders, J.:
%Windows and UEFI anti-theft mechanism makes systems less secure,
%\url{http://www.techrepublic.com/article/windows-and -uefi-anti-theft-mechanism-makes-systems-less-secure/}
%
%\bibitem {govHack}
%Olorunnipa, T.:
%Breach of Employee Data Wider Than Initial Report, U.S. Says,
%\url{http://www.bloomberg.com/politics/articles/2015-06-12/white-house-says-personnel-records-possibly-breached-twice}
%
%\bibitem {stageFright}
%Vaughan-Nicholas, S.J.:
%Stagefright: Just how scary is it for Android users?,
%\url{http://www.zdnet.com/article/stagefright-just-how-scary-is-it-for-android-users/}
%
%\bibitem {stageFright2}
%Whittaker, Z.:
%Stagefright is back, and affecting millions of Android devices,
%\url{http://www.zdnet.com/article/new-stagefright-2-0-flaws-affect-millions-of-android-devices/}
%
%\bibitem {androidUpdates}
%Tofel, K.:
%HTC says monthly Android security updates are ``unrealistic'',
%\url{http://www.zdnet.com/article/htc-says-monthly-stagefright-android-security-updates-are-unrealistic/}
%
%\bibitem {androidMarshmallow}
%Jack Wallen, J.:
%The woes of Android updates, and how to fix the process,
%\url{http://www.techrepublic.com/article/the-woes-of-android-updates-and-how-to-fix-the-process/}
%
%\bibitem {googleAndroid}
%Sanders, J.:
%Google finally doubles down on security with monthly Android updates,
%\url{http://www.techrepublic.com/article/google-and-some -android-phone-vendors-introduce-welcome-changes-to-security-update-process/}
%
%\bibitem {aaraj2008analysis}
%Aaraj, N., Raghunathan, A., Jha, N.K.:
%Analysis and design of a hardware/software trusted platform module for embedded systems,
%ACM Transactions on Embedded Computing Systems (TECS), Volume 8 Number 1, page 8 (2008)
%
%\bibitem {denning1996location}
%Denning, D.E., MacDoran, P.F.:
%Location-based authentication: Grounding cyberspace for better security,
%Computer Fraud \& Security, Volume 1996 Number 2, pages 12--16 (1996)
%
%\bibitem {saito2015case}
%Saito, M., Hazeyama, A., Yoshioka, N., Kobashi, T., Washizaki, H., Kaiya, H., Ohkubo, T.:
%A case-based management system for secure software development using software security knowledge,
%Procedia Computer Science, Volume 60, pages 1092--1100 (2015)
%
%\bibitem {denning2015toward}
%Denning, D.E.:
%Toward more secure software,
%Communications of the ACM, Volume 8 Number 4, pages 24--26 (2015)
%
%\bibitem {nguyen2015model}
%Nguyen, P.:
%Model-Driven Security With Modularity and Reusability For Engineering Secure Software Systems,
%University of Luxembourg (2015)
%
%\bibitem {ravi2004security}
%Ravi, S., Raghunathan, A., Kocher, P., Hattangady, S.:
%Security in embedded systems: Design challenges,
%ACM Transactions on Embedded Computing Systems (TECS), Volume 3 Number 3, pages 461--491 (2004)
%
%\bibitem {gokhale2008model}
%Gokhale, A., Balasubramanian, K., Krishna, A.S., Balasubramanian, J., Edwards, G., Deng, G., Turkay, E., Parsons, J., Schmidt, D.C.:
%Model driven middleware: A new paradigm for developing distributed real-time and embedded systems,
%Science of Computer programming, Volume 73 Number 1, pages 39--58 (2008)
%
%\bibitem {perez2006vtpm}
%Perez, R., Sailer, R., van Doorn, L., and others:
%vTPM: virtualizing the trusted platform module,
%Proc. 15th Conf. on USENIX Security Symposium, pages 305--320
%
%\bibitem {yan2015novel}
%Yan, W., Tehranipoor, F., Chandy, J.A.:
%A Novel Way to Authenticate Untrusted Integrated Circuits,
%Proceedings of the IEEE/ACM International Conference on Computer-Aided Design, pages 132--138 (2015)
%
%\bibitem {tehranipoor2015dram}
%Tehranipoor, F., Karimina, N., Xiao, K., Chandy, J.:
%DRAM based intrinsic physical unclonable functions for system level security,
%Proceedings of the 25th edition on Great Lakes Symposium on VLSI, pages 15--20 (2015)
%
%\bibitem {CommonCriteria}
%Common Criteria for Information Technology Security Evaluation,
%ISO/IEC, Number ISO/IEC 15408, July 2015
%
%\bibitem {benzel2005design}
%Benzel, T.V., Irvine, C.E., Levin, T.E., Bhaskara, G., Nguyen, T.D., Clark, P.C.:
%Design principles for security (2005)
%
%\bibitem {lin2013security}
%Lin, C., Zhu, Q., Phung, C., Sangiovanni-Vincentelli, A.:
%Security-aware mapping for CAN-based real-time distributed automotive systems,
%Computer-Aided Design (ICCAD), 2013 IEEE/ACM International Conference on, pages 115--121 (2013)
%
%\bibitem {markose2008systematic}
%Markose, S., Liu, X., McMillin, B.:
%A systematic framework for structured object-oriented security requirements analysis in embedded systems,
% IEEE/IFIP International Conference on Embedded and Ubiquitous Computing, 2008. EUC'08, Volume 1, pages 75--81 (2008)
%
%\bibitem {yu1997towards}
%Yu, E.S.:
%Towards modelling and reasoning support for early-phase requirements engineering,
%Proceedings of the Third IEEE International Symposium on Requirements Engineering, pages 226--235 (1997)
%
%\bibitem {massacci2010security}
%Massacci, F., Mylopoulos, J., Zannone, N.:
%Security requirements engineering: the SI* modeling language and the secure tropos methodology,
%Advances in Intelligent Information Systems, pages 147--174 (2010)
%
%\bibitem {sangiovanni2007quo}
%Sangiovanni-Vincentelli, A.:
%Quo vadis, SLD? Reasoning about the trends and challenges of system level design,
%Proceedings of the IEEE, Volume 95 Number 3, pages 467--506 (2007)
%
%\bibitem {ALISA2016}
%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)
\end{thebibliography}
\end{document}