sig-alternate-sample.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}

% 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}

% Graph generation package
\usepackage{tikz}

\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{PLDI '13}{June 16--19, 2013, Seattle, WA, 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{Framework for Implementing Attacker Based Embedded Systems Security Metrics}
%\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\\
       \affaddr{University of Connecticut}\\
%       \affaddr{1932 Wallamaloo Lane}\\
%       \affaddr{Wallamaloo, New Zealand}\\
       \email{paul.wortman@uconn.edu}
% 2nd. author
\alignauthor
John Chandy\\
       \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}
This paper provides a framework by which developers can implement attacker based embedded system security metrics.  Through using this framework, one can not only design better embedded system security, but can also identify and correct any potential issues early on in the development life-cycle.
\end{abstract}


%
% 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>10010520.10010553.10010562</concept_id>
  <concept_desc>Computer systems organization~Embedded systems</concept_desc>
  <concept_significance>500</concept_significance>
 </concept>
 <concept>
  <concept_id>10010520.10010575.10010755</concept_id>
  <concept_desc>Computer systems organization~Redundancy</concept_desc>
  <concept_significance>300</concept_significance>
 </concept>
 <concept>
  <concept_id>10010520.10010553.10010554</concept_id>
  <concept_desc>Computer systems organization~Robotics</concept_desc>
  <concept_significance>100</concept_significance>
 </concept>
 <concept>
  <concept_id>10003033.10003083.10003095</concept_id>
  <concept_desc>Networks~Network reliability</concept_desc>
  <concept_significance>100</concept_significance>
 </concept>
</ccs2012>  
\end{CCSXML}

\ccsdesc[500]{Computer systems organization~Embedded systems}
\ccsdesc[300]{Computer systems organization~Redundancy}
\ccsdesc{Computer systems organization~Robotics}
\ccsdesc[100]{Networks~Network reliability}


%
% End generated code
%

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

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

\keywords{Embedded Systems Security; Security Metrics; Threat Modeling}

\section{Introduction}
What are the security concerns of embedded systems?  How do the constraints of a system play into these issues?
\begin{itemize}
	\item Introduce new Security Design Framework
	\item Emphasis importance of mapping function
\end{itemize}

\begin{figure}
	\centering\includegraphics[height=6cm,width=0.8\textwidth]{./images/aadl_security_framework.png}
	\caption{Visualization of Security Design Framework}
	\label{fig:AADLSecFrame}
\end{figure}

\section{Related Work}
Related work in the field:

Over the past few decades there have been research towards defining security in a formalized and verifiable manner.  The work has ranged from determining the security requirements of a system to standardizing formal implementation and methods of verification for produced models.  The movement of security concerns from server-like systems to more embedded system architectures has lead to new constraints and considerations that must be accounted for.  
%Further more, as mentioned in Section ~\ref{securityBasics}, as security requirements and implementations change over time the schema for security model generation and verification needs to adapt.

Previous work in defining security requirements range from lesser known languages, such as i* and SI*, to more commonly used one, such as UMLSec and SysML-Sec.  Markose et.~al.~propose an object oriented methodology for structuring security requirements analysis methodology~\cite{markose2008systematic}.  This work focused on deriving requirements based on security use cases at different levels of system hierarchy.  The advantage being that aggregation of the derived security requirements represents the security requirement specification for the entire system.  Other languages that focus on specifying security requirements are `i*'~\cite{yu1997towards} and `SI*'~\cite{massacci2010security}.  The work by Eric Yu~\cite{yu1997towards} aimed to replace the current standard modeling and reasoning support used for determining early phase requirements engineering.  Although the purpose for this work was about organizational environments and their information systems, the `i*' framework applies to business process modeling and redesign, software process modeling, and modeling of embedded systems.  Massacci et.~al.'s work with `SI*' showed not only the effectiveness of agent-oriented methodologies but also was revised and refined to be applicable in the earliest phases of software development processes and cover a broader organizational perspective.

%Section on UMLSec.
UMLSec is an extension to the Unified Modeling Language (UML) for integrating security related information using UML specifications.  UMLSec is centered around secure systems development using specification elements to present recurring security requirements such as secrecy, integrity, and authenticity~\cite{jurjens2005secure}.  The reasoning for J\"{urjens} to use the Unified Modeling Language (UML) was due to it being a de facto standard in industrial modeling with a large number of developers trained in its use~\cite{jurjens2002umlsec}.  Compared to previous notations and languages with similar user community sizes, UML was relatively precisely defined making it a prime candidate.  As a lightweight extension for UML, the UMLSec profiles are defined between the system being modeled and an attacker model that defines the threats posed.  The limitation of this work is that the focus on security requirements is from a networking scope.  While this is effective from a larger industrial standpoint, this implementation does not account for lower level component security requirements or behavior.

%Section on SysML-Sec
SysML-Sec is an environment tool used to design safe and secure embedded systems as an extension of the Systems Modeling Language(SysML) which is a dialect of the Unified Modeling Language (UML)~\cite{SysML-Sec}.  SysML-Sec focuses on both the software and the hardware of the modeled systems.  The originating language, SysML, is a general purpose visual modeling language purposed for system engineering applications~\cite{SysML}.  SysML is defined as a dialect of the UML standard that is able to support the specification, analysis, design, verification, and validation of not only systems but also systems-of-systems.  The nature of SysML-Sec, extending from such well established standard languages, allows for security-aware system architecture definition and exploration along with the definition of attack graphs.  This allows for similar description to the `attacker model' that can be created using UMLSec.  While a powerful tool that includes views from both a system and attacker standpoint, there is still too much of a focus on the impact of security mechanisms over the safety and performance of the overall system to meet our needs of defining security requirements and behavior for both a functional higher level representation and a lower level architectural implementation.

%Secion on why AADL
So why should an individual choose to use AADL rather than any of the other descriptive languages or extensions to their lexicons for defining security requirements and behavior of embedded systems?  AADL is the one tool that is not only as capable and flexible as the other languages (e.g. UML), but also is easier for humans to interact with and understand from both a graphical and written standpoint.  AADL also has a large community of users that have spent the past decade developing, expanding, and improving the language to meet the needs of embedded system designers across a variety of disciplines.  In the following section, the paper will examine the growth of AADL as the user community expands and develops the languages capabilities to describe the function behavior of systems, detail the security requirements of models, and extension to verification tools to validate generated designs.

%In this section, the paper examines the traditional definition of risk followed by a brief explanation of the work by Ferrante et.~al. in preparation for the proposition of defining security risk.
\subsection{Traditional Risk}
\label{sec:traditionalRisk}
% Risk traditionally defined
Risk is generally defined as the potential of gaining or losing something of value.  Value can be seen as physical health, emotional well-being, financial wealth, etc.  Another definition of risk involves viewing risk 
as an intentional interaction made with some uncertainty.  In this scenario, uncertainty is defined as a potential, unpredictable, and uncontrollable outcome; risk is seen as a consequence of action taken in spite of some given uncertainty.  Traditionally, risk is a consideration of losses based on the probability of a given event will occur~\cite{Mukhopadhyay2013,pal2014will,fauntleroy2015cyber,biener2015insurability,armando2004satmc,brucker2012securebpmn,gonzalez2012quantitative,mukherjee2013attributed,marotta2015survey}.  Depending on the point-of-view of the individual measuring risk, its definition and application can vary a significant amount.  
%For example, risk can be the analysis of expected loss %(as shown in Equation~\ref{equ:expectedLoss}).  
%Risk is not a certainty of an event occurring, but a probability that it will happen.  
But to develop an equation for risk one must first define the potential of events and the losses that could be incurred.  Possibility, in risk, depends on two aspects: (1) threat and (2) vulnerability ~\cite{Mukhopadhyay2013}.  Threat is defined as the cause of risk (e.g. fire, kidnapping, leakage of sensitive information, etc.).  Vulnerability is defined as the existing flaw or weakness which can be exploited and result in an accident.  The concept of risk states that risk may result in losses for an agent, user, company, etc.  Losses occur because of the consequences of an accident (defined as Impact).  Depending on the impacted asset, `Impact' may be defined as a tangible (e.g. loss of revenue or financial penalties) or as intangible (e.g. loss of productivity or loss of reputation)~\cite{Mukhopadhyay2013}.  An `asset' can be defined as anything valuable to a user or organization or company.  An asset can be (1) a physical object, (2) secret information, (3) business goal, etc.  As mentioned earlier, risk requires an element of probability, meaning that the probability value acts as a 0.00 -{}- 1.00 scale weight.  Putting everything together, risk is generally represented as follows: 
\begin{equation} \label{equ:riskDefinition}
	Risk = Probability * Impact
\end{equation}

% Define Risk for this paper
For the purpose of this paper, risk will be represented as a combination of probability and impact (as shown in Equation~\ref{equ:riskDefinition}).  
%The reason for this interpretation is that from a security lens, it is much easier to quantify probability and impact.  
In addition to these, we have developed a methodology for evaluating design choices based on impact (risk), cost of the design, and also incorporating the attacker's side of examining any given embedded system.  Without a proper method for defining risk and cost models, one can not verify, evaluate, compare, and contrast designs in a relevant and worthwhile manner.

% Differences can occur when assessing risk depending on the point of view of the individual
%Summarizing, risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact.  
Complications in 
security risk identification can come from a lack of experience and standards or due to the evolution of a system.  The first comes the fact that defining `security risk' is still novel and does not have standardized procedures for dealing within the cyber-modeling domain.  Secondly, the system within an organization can change quickly with new technologies appearing very often; changing the landscape of `cyber risks' and other cyber-domain concerns.  
%Risk can be assessed differently based on how it is examined.  
Depending on where uncertainties originate from, how impacts of actions are measured, and how these variables interact with each other, different variations of risk equations can be developed.  To further complicate possible risk calculations, the equation for interpreting risk can differ based on the role of the individual measuring said risk.  What may be a calculated risk to a defender, could prove to be advantageous to an attacker by causing less risk of being observed or even allow for 
less risky attacks to be performed against a system.  Another example would be that heavy security 
implementation may cause a larger risk value for an attacker, but would produce a minimal risk value for the 
defender.  
%Further examination of attack and defense considerations will be continued in Section~\ref{sec:attackDefense}.

\subsection{Quantitative and Qualitative Security}
% Summary and application of the Ferrante work
% Development of the verification process
To begin developing the verification and selection process, one needs to create a metric of weights based on the relative importance of any given solution $s_i$ in comparison to another solution $s_j$~\cite{Ferrante2013}.  The purpose of these weights is to allow for comparison of varying solution elements, relative to each other, as they are used within embedded system security modeling solutions.  Importance is defined as a ranking that will depend on the case of implementation by a given company/group.  Because this value is dependent on the `source' examining a particular security model, the value will be partially arbitrary and partially cost analysis.  An other influencing factor could also come from the preference/wheel house of a given company or individual.

% Explain the work done by Ferrante et. al.
Borrowing from the work of Ferrante et.~al.~using the Analytical Hierarchy Process (AHP), we examine the process developed for producing weights for various security solutions.  
One must note that there are essentially two values being spoken about in the work by Ferrante et.~al.; first is the generation of a security metric (named security level) and second generation of a weight metric.  The creation of the `security level' metric is a simple mapping of some physical property to a 0.00 -{}- 1.00 scale with 1 being the highest possible security level.  Once one has created these weight ($w$) and security level ($SL$) metrics, these values can be used to produce security metrics about a given embedded systems security model design.  

% Introducing the Security Metric equation
The next consideration is how does one take these produced values and develop a meaningful equation for generating a comparable metric.  Following the examination of the work by Ferrante et.~al.~, their definition of `security metric' is as follows:

\begin{multline} \label{equ:securityMetric}
	Security Metric (SM) = \\
w_{elem1} * SL_{elem1} + w_{elem2} * SL_{elem2} + {...} + w_{elemN} * SL_{elemN}
\end{multline}

Each `element', in Equation~\ref{equ:securityMetric}, can describe different algorithms, elements, properties, and capabilities of the different components of a system or device.  
%It is worth noting that this equation is not necessarily limited to a single use within entire process.  
This same style can be used at higher level abstractions of the same design to produce an overall security metric representing a larger system of components.  Harking back to our discussion of risk, the following is an example of calculating aggregated security metrics of a system (i.e. network security):

\begin{multline} \label{equ:overallSecMet}
	Overall SM = \\
w_{anti-virus} * SM_{anti-virus} + w_{firewall} * SM_{firewall} + {...} + w_{element i} * SM_{element i}
\end{multline}

% Introduction to paper's Security Risk security
This allows for a designer to now create some arbitrary metric to represent whether or not a given design is better or worse at meeting not only the requirements imposed but also in comparison to other available solutions to the same design problem.  While this is a step in the right direction, there no units attached to the overall 
security metrics produced by this work.  Without a proper unit attached to a generated metric, the entire process remains arbitrary and more difficult to use in a relevant and meaningful manner.  %Calling back to the equation proposed in Section~\ref{sec:riskDefinition}, allow us 
We make use of the same techniques Ferrante et.~al.~developed but apply them in a more meaningful, cost-based 
manner.  Thus, instead of focusing on an arbitrary security metric (SM), we focus instead on the security level 
(SL) which can serve as a useful approximation of the probability that an attacker can defeat a particular 
security feature.   In this way it is possible for a `security risk' metric to be generated but also carry a 
recognizable worth. %instead of just an arbitrary number scheme.  
However, these values of cost must come from somewhere, and that is the purpose of the impact variable.  This is because the impact is a representation of the potential loss caused by an event.

% Trouble when incorporating security into risk calculations
Different methods by which security can be incorporated into risk management include: as a weight representing implementation of security solutions, as a probability that a security concern is met or attacked, the 
possibility of a security failure, etc.  Security levels can also be interdependent depending on implementation and scenario/situation.
A degree of `relativity' is required for developing a security metric, because security changes and evolves over time, meaning that the algorithms and methodologies will transform and improve over time.  This change means that the measurement for security must remain important relative to the existing security solution space.  
Ideally embedded system security modeling should have more deterministic interpretations of generated security solutions, but at the current point this is not realistically achievable.

\section{General System Modeling}
\begin{itemize}
	\item Traditional Concerns
	\item Traditional Measurements of Costs
\end{itemize}

\section{Design Oriented Examination of Risk}
\begin{itemize}
	\item Estimation of Attack Risk Behavior
	\item Definition of Security Metric
	\item Present Security Risk Equation Along with Constraints
	\begin{itemize}
		\item Probability of Attack Must be Worth the Cost of the Attack
		\item Constraint Calculation to Determine the `Tipping Point'
	\end{itemize}
\end{itemize}

\begin{figure}
\centering
\begin{tikzpicture} [xscale=3, yscale=1]
%\draw [<->] (0,3) -- (0,0) -- (4,0);
\node at (0.5,3) {MiTM};
\draw [yellow] (0.3,3.2) rectangle (0.7,2.8);
\draw [->] (0.5,2.8) -- (1,2.25);
\node at (1.5,3) {Brute Force};
\draw [yellow] (1.2,3.2) rectangle (1.8,2.8);
\draw [->] (1.5,2.8) -- (1,2.25);
\node at (2.5,3) {Social Engineering};
\draw [yellow] (2.0,3.2) rectangle (3.0,2.8);
\draw [->] (2.5,2.8) -- (3,2.25);
\node at (3.5,3) {SW Vuln};
\draw [yellow] (3.25,3.2) rectangle (3.75,2.8);
\draw [->] (3.5,2.8) -- (3,2.25);
\node at (1,2) {Break Encryption};
\draw [orange] (0.55,2.25) rectangle (1.45,1.85);
\draw [->] (1,1.85) -- (2,1.2);
\node at (3,2) {Root Access};
\draw [orange] (2.7,2.25) rectangle (3.3,1.85);
\draw [->] (3,1.85) -- (2,1.2);
\node at (2,1) {data};
\draw [red] (1.8,1.2) rectangle (2.2,0.8);
\end{tikzpicture}
\caption{Illustrative Example of Attack Vector Tree}
\label{fig:attackTree}
\end{figure}

\begin{figure}
\centering
\begin{tikzpicture} [xscale=3.5, yscale=2]
\draw [<->] (0,1.5) -- (0,0) -- (3,0);
\node [below right] at (3,0) {$p_s*A$};
\node [left] at (0,1.5) {$p_a$};
\draw [dashed, gray] (0,1) -- (3,1);
\draw (1,0) to [out=90,in=180] (3,1);
%\draw [green, domain=0:3] plot (\x, {1 - exp(-\x - 1)});
\draw (1,-0.1) -- (1,0.1);
\node [below] at (1,0) {$c_a$};
\node [left] at (0,0) {0};
\node [left] at (0,1) {1};
\end{tikzpicture}
\caption{Estimation of Attack Risk Behavior}
\label{fig:attackRisk}
\end{figure}

\section{Scenario Examination}
\begin{itemize}
	\item Give Simple Example of Wireless Transmitter System
	\item Show How Metric Works with Traditional Cost Calculations
	\item Comparison of Impact as a Function of Security Risk for Design
\end{itemize}

\begin{figure}
	\centering\includegraphics[height=4.25cm]{./images/encrypted_transmitter_sidebyside.png}
	\caption{Design Implementations of Wireless Transmitter}
	\label{fig:exampleDesigns}
\end{figure}

\begin{table}[]
\centering
\begin{tabular}{|c|c|}
\hline
\textbf{Component} & \textbf{Cost (\$)} \\ \hline
Antenna            & 3                  \\ \hline
IO Bus             & 1                  \\ \hline
Basic Processor    & 15                 \\ \hline
Encryption Processor (AES128)   & 20                 \\ \hline
Encryption Processor (AES256)  & 21                 \\ \hline
%Encryption Module  & 8                  \\ \hline
\end{tabular}
\caption{Table of Individual Part Costs}
\label{tbl:partCosts}
\end{table}

\begin{table}[]
\centering
\begin{tabular}{|c|c|c|c|c|c|}
\hline
               & \textbf{Design 1} & \textbf{Design 2} & \textbf{Design 3} & \textbf{Design 4} & \textbf{Design 5} \\ \hline
\textbf{SL}    & 0.01              & 0.24              & 0.40              & 0.60              & 1.00              \\ \hline
\textbf{$p_s$} & 0.99              & 0.76              & 0.60              & 0.40              & 0.00              \\ \hline
\textbf{$p_a$} & 0.99              & 0.99              & 0.99              & 0.86              & 0.00              \\ \hline
\textbf{SR}    & \$19.80           & \$15.20           & \$12.00           & \$6.92            & \$0.00            \\ \hline
\textbf{Costs} & \$19.00           & \$19.00           & \$19.00           & \$24.00           & \$25.00           \\ \hline
\end{tabular}
\caption{Calculated Values for Wireless Transmitter Example}
\label{tbl:calculations}
\end{table}

\begin{figure}
\centering
\begin{tikzpicture}[xscale=1,yscale=0.33]
\draw [<->] (0,7) -- (0,0) -- (7,0);
\node [left] at (0,7) {$SR$};
\node [below right] at (7,0) {$I$};
%\draw [dashed, gray] (0,5) -- (7,5);
%\node [left] at (0,5) {\$5};
\draw [dashed, gray] (0,6) -- (7,6);
\node [left] at (0,6) {\$6};
%\draw [domain=0:13] plot (\x, {0.7999999*\x});
\draw [domain=0:7] plot (\x, {0.99*\x});
%\node [left] at (0,0) {0};
%\draw [dashed, lightgray] (5.05, 0) -- (5.05, 11);
%\node [below] at (5.05,0) {\$5.05};
\draw [dashed, lightgray] (6.06, 0) -- (6.06, 7);
\node [below] at (6.06,0) {\$6.06};
\end{tikzpicture}
\caption{Comparison of Impact as a Function of Security Risk for Design \#1}
\label{fig:SRvI}
\end{figure}

\section{Modeling an Attacker}
Talk about modeling an attacker:
\begin{itemize}
	\item What are the Considerations from an Attacker's Standpoint?
	\item what are the `calculations' being made by an attacker?
	\begin{itemize}
		\item Attack Cost
		\item Value of Information
	\end{itemize}
\end{itemize}

\section{Expanding Considerations}
\begin{itemize}
	\item Need to Account for Minute Costs Incurred by Physical Properties (e.g. heat, cooling, energy, time)
	\item User Risk Type
	\begin{itemize}
		\item Risk-Based Authentication
		\begin{itemize}
			\item Is the location correct?
			\item Are you in the right area?
			\item Is it the right habit?
			\item How does this change based on the information trying to be accessed?
		\end{itemize}
	\end{itemize}
	\item Problem of `Relatively Deterministic'
\end{itemize}

\section{Conclusion}
\begin{itemize}
	\item Presented New Security Modeling Framework
	\item Need for Development of Standards and Practice Documentation for Security and Metrics
	\begin{itemize}
		\item Allows More Efficient Verification
	\end{itemize}
	\item Design of Automated Tools and Better Translation of Language Between Different Aspects of the Security Framework Model
\end{itemize}
%\balancecolumns % GM June 2007
% That's all folks!
\end{document}