diff --git a/SecurityRiskPaper.pdf b/SecurityRiskPaper.pdf new file mode 100644 index 0000000..bdeadcd Binary files /dev/null and b/SecurityRiskPaper.pdf differ diff --git a/AADLSecPaper.tex b/SecurityRiskPaper.tex similarity index 92% rename from AADLSecPaper.tex rename to SecurityRiskPaper.tex index bfc4b9b..779f36e 100644 --- a/AADLSecPaper.tex +++ b/SecurityRiskPaper.tex @@ -110,11 +110,11 @@ Modeling security risk for use in systems design is a difficult problem that has methodologies and techniques %(e.g. Platform Based Design) that aid in the development and improvement of security modeling approaches. For example, Platform-based design~\cite{Vincentelli2007} is a prime example of how one can take the functional space (including security requirements) and the architectural space (components and capabilities) and develop a mapping function that can produce solutions to a given design problem. As shown in Figure~\ref{fig:recursivePBD}, one can then take the mapped solution and use this as the new functional (or architectural) space for the next iteration of solution mapping. -\begin{figure} - \includegraphics[height=6.5cm,width=\textwidth]{./images/recursivePBD.png} - \caption{Visualization of Recursive PBD Model~\cite{Vincentelli2007}} - \label{fig:recursivePBD} -\end{figure} +%\begin{figure} +% \includegraphics[height=6.5cm,width=\textwidth]{./images/recursivePBD.png} +% \caption{Visualization of Recursive PBD Model~\cite{Vincentelli2007}} +% \label{fig:recursivePBD} +%\end{figure} In order to use a design process such as this, we need to be able to have metrics that are able to evaluate the quality of a design solution in relation to the quality of other possible design solutions. How does one begin to place metrics on an arbitrary measure like security risk? Risk is generally treated as a probability that an event will occur. To understand risk from an embedded systems security modeling standpoint, one must first determine how to define risk in a meaningful manner, and how to then apply this metric to the situation that involved said `security risk' (more on this topic will be explored in Section~\ref{sec:riskDefinition}). Quantitative aspects of security will be relatively simple to incorporate with risk calculations. How does one define qualitative aspects of security? One method that can be used to assign a quantitative value to a qualitative property is to use a relative ranking system to scale all available @@ -387,9 +387,9 @@ One then takes Equation~\ref{equ:expandedRisk} and now accounts for an aggregati {SR}_i = \sum\limits_{j=0}^K (1 - e^{-(p_{s_{ij}}*A_i - c_{a_{ij}})})*p_{s_{ij}}*I_i \end{equation} -where K is all the contributing attack vectors for a given asset. Thus, Equation~\ref{equ:aggregatedRisk} represents the aggregation of all contributing attack vectors towards the potential compromise of a specific system asset. +where K is all the contributing attack vectors for a given asset. Thus, Equation~\ref{equ:aggregatedRisk} represents the aggregation of all contributing attack vectors towards the potential compromise of a specific system asset. This security risk metric, essentially, represents the calculated cost of a device over a lifetime. -\section{Generating an Estimation Metric} +\section{Generating Estimations} \label{sec:framework} Now that we have presented a meaningful manner of representing security risk as a metric, we move to show that the introduced security framework is an ideal fit for continuing development and improvement of embedded system security modeling techniques and methodologies. %What does the proposed framework bring to the table that lacked in previous security framework designs? @@ -412,15 +412,17 @@ Ideally verification of a design should be done through validation of the requir % Introduce paper's Estimation Metric equation %While having an equation for security risk is great, this does not allow for a representation of a system as a whole. -Additional aspects that must be taken into account include costs of implementing a given solution, the cost of maintaining a given solution, how a generated solution's ranking will change based on the user type interacting with the system, operational costs of a given solution, as well as determination of the number of requirements met, or not met, by any chosen design solution. Taking these aspects into account, this paper proposes the following equations to calculate an overall cost and `estimation metric' for any produced embedded system security modeling design. +Additional aspects that must be taken into account include costs of implementing a given solution, the cost of maintaining a given solution, how a generated solution's ranking will change based on the user type interacting with the system, operational costs of a given solution, as well as determination of the number of requirements met, or not met, by any chosen design solution. Taking these aspects into account, this paper proposes the following equations to calculate an overall cost +% and `estimation metric' +for any produced embedded system security modeling design. \begin{equation} \label{equ:cost} Costs = c_i + c_{si} + c_m + c_o \end{equation} -\begin{equation} \label{equ:estimationMetric} - Estimation Metric = SR+Costs -\end{equation} +%\begin{equation} \label{equ:estimationMetric} +% Estimation Metric = SR+Costs +%\end{equation} Some of the values for Equation~\ref{equ:cost}, implementation and maintenance costs ($c_i$ and $c_m$ respectively), are expected to be flat costs that are pre-calculated by a company or business since these values will be specific to the given organization. An important difference between these values are that the $c_m$ and $c_i$ values do not incorporate the operational costs of the design, they only account for the cost of initial implementation of a system design and the cost of performing upkeep for said design. The $c_{si}$ variable represents any cost due to implementing security aspects into the design. The operational cost ($c_o$) is a value coming from a given individual or company; based on a monetary cost over time unit of measurement. @@ -433,7 +435,7 @@ Now that aspects of this framework's verification and selection process have bee \section{Exploring a Simple Implementation} \label{sec:simpleExample} -This paper now moves to showing a simple implementation of the security framework's verification and selection process to produce a meaningful `estimation metric' that can be used to compare design decisions. The purpose of this examination is to give a concrete example of the verification equations being used to rank a set of produced solutions to a chosen design problem, as well as illustrate how one may go about developing some of the required rankings. When initially designing a system, there are a large number of considerations that must be taken into account. From power consumption requirements, architectural needs, spacing of parts, and weight of the developed device. When incorporating security elements, the problem becomes larger. +This paper now moves to showing a simple implementation of the security framework's verification and selection process to produce a meaningful estimation that can be used to compare design decisions. The purpose of this examination is to give a concrete example of the verification equations being used to rank a set of produced solutions to a chosen design problem, as well as illustrate how one may go about developing some of the required rankings. When initially designing a system, there are a large number of considerations that must be taken into account. From power consumption requirements, architectural needs, spacing of parts, and weight of the developed device. When incorporating security elements, the problem becomes larger. %For example, allow this paper to assume that the elements in Table~\ref{elementTypes} have numerous variations that can be simplified into a few types. % Add in the table of elements and variations @@ -517,21 +519,22 @@ These different aspects can be compared by assigning weights for allowing relati Before being able to calculate out the estimation matrix for our wireless transmitter example, we make some simplifications and assumptions to smooth the process. First we will take the assumption that there will be three separate implementations of encryption for the wireless transmitter: AES256 (MIPS), AES128 (MIPS), and no encryption. Drawing from the work by Ferrante et.~al.~, the corresponding security level (SL) values are {1.00, 0.60, 0.10} respectively. Since we have simplified the example to having a single requirement (i.e. encryption of data), then the weight value used for calculating the Security Metric (SM) is 1.00. Now that we have values for SL and the weight, we can move to calculating the SM value for our different encryption scenarios. However, first we must make some assumptions about the impact ($I$), attack cost ($c_a$), and the value to an attacker ($A$). For the $I$ value we make the assumption that some company may find that the data collected by this wireless transmitter is worth \$20 if lost. % XXX is the cost weight really the impact? Should you use impact or $i$ as the variable name? -The $A$ value is assumed to be \$30 per `unit' of stolen data and the $c_a$ is assumed to be \$10 per attack attempt. Using Equation~\ref{equ:expandedRisk}, one finds that the SR values shown in Table~\ref{tbl:securityRisks}. -% for the {AES256, AES128, None} encryption implementations are {0, 2.73, 15.84} respectively. +The $A$ value is assumed to be \$30 per `unit' of stolen data and the $c_a$ is assumed to be \$10 per attack attempt. Using Equation~\ref{equ:expandedRisk}, one finds that the SR values +%shown in Table~\ref{tbl:securityRisks}. + for the {AES256, AES128, None} encryption implementations are {0, 2.73, 15.84} respectively. -% Table showing the calculated security risk -\begin{table}[] -\centering -\label{tbl:securityRisks} -\begin{tabular}{|c|c|c|c|} -\hline - & \multicolumn{3}{c|}{Encryption Standard} \\ \cline{2-4} - & AES256 & AES128 & None \\ \hline -Security Risk & 0 & 2.73 & 15.84 \\ \hline -\end{tabular} -\caption{Calculated Security Risk for Wireless Transmitter} -\end{table} +%% Table showing the calculated security risk +%\begin{table}[] +%\centering +%\label{tbl:securityRisks} +%\begin{tabular}{|c|c|c|c|} +%\hline +% & \multicolumn{3}{c|}{Encryption Standard} \\ \cline{2-4} +% & AES256 & AES128 & None \\ \hline +%Security Risk & 0 & 2.73 & 15.84 \\ \hline +%\end{tabular} +%\caption{Calculated Security Risk for Wireless Transmitter} +%\end{table} From this point, we make further assumptions about the implementation cost ($c_i$), security implementation cost ($c_{si}$), the maintenance cost ($c_m$), and operational cost ($c_o$) since these values would come from metrics internal to a company or organization. $c_i$ is taken to be an aggregation of the individual cost of parts. @@ -556,7 +559,7 @@ Encryption Module & 8 \\ \hline The cost per design, using costs from Table~\ref{tbl:partCosts}, from 1-{}-4, are {19,28,24,34}, respectively. $c_{si}$ is taken to be \$10 for AES256 and \$6 for AES128, $c_m$ is taken to be \$50 in drive out cost, and $c_o$ is assumed to be \$3 in operative power costs. %per 12 hours of operation (\textbf{How to ignore time aspect?}). %The $w_r$ value is assumed to be 1.00 if the system is encrypted and 0.10 is not; since the effect of not meeting requirements can be viewed more clearly. -Taking the calculation of the estimation metric (EM) from Equation~\ref{equ:estimationMetric}, we produce the contents of Table~\ref{tbl:calculations} which represents the calculated costs and security risk metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None}. +%Taking the calculation of the estimation metric (EM) from Equation~\ref{equ:estimationMetric}, we produce the contents of Table~\ref{tbl:calculations} which represents the calculated %costs and security risk metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None}. % and how different User Risk Types (URT) also further influence the metric. %% Please add the following required packages to your document preamble: @@ -585,39 +588,60 @@ Security Risk & 15.84 & 0 & 0 & 2 \\ \hline \caption{Calculated Values for Wireless Transmitter Example (Units USD)} \label{tbl:calculations} \end{table} + +From these produced numbers, a developer can apply further constraints to the design selection process by mandating that costs be kept below a certain level while minimizing security risk or vice versa. For example, a development team could compare how a growth in the impact ($I$) value changes the cost value reflected by the security risk (Equation~\ref{equ:expandedRisk}) metric. Ideally a developer is looking for the point where as $I$ grows, the value of $SR$ should cross the $c_{si}$ threshold, thus indticating that the cost of additional security is warranted. In the case of comparing designs 1 and 2 of the wireless transmitter, one finds that the difference in cost is \$9; taken to be the $c_{si}$ threshold. Using the values for Design 1 of the wireless transmitter, one finds that the once the $I$ value becomes \$11.25 then the additional security cost of \$9, for a fully security design, becomes not only feasible but favorable. An illustration of this is shown in Figure~\ref{fig:SRvI}. + +\begin{figure} +\centering +\begin{tikzpicture}[xscale=0.5,yscale=0.2] +\draw [<->] (0,11) -- (0,0) -- (13,0); +\node [left] at (0,11) {$SR$}; +\node [below right] at (13,0) {$I$}; +\draw [dashed, gray] (0,9) -- (13,9); +\node [left] at (0,9) {\$9}; +\draw [domain=0:13] plot (\x, {0.7999999*\x}); +%\node [left] at (0,0) {0}; +\draw [dashed, lightgray] (11.25, 0) -- (11.25, 11); +\node [below] at (11.25,0) {\$11.25}; +\end{tikzpicture} +\caption{Comparison of Impact as a Function of Security Risk for Design \#1} +\label{fig:SRvI} +\end{figure} -Now that a simple example has been shown, allow this paper to now expand the considerations that are made for this simplistic example. The following section will examine further expansion of `estimation metric' considerations, showing how the calculation of comparable metrics can become more involved and complicated. +While both the values of the costs and security risk equations produce a dollar-unit metric, they are not immediately combinable as some costs are representative of life-time costs while others incorporate more immediate costs of a design. For this reason, a pairing of security risk and cost are used to determine the favorability of a given design in comparison of other design choices. Now that a simple example has been shown, allow this paper to now expand the considerations that are made for this simplistic example. The following section will examine further expansion of `estimation metric' considerations, showing how the calculation of comparable metrics can become more involved and complicated. \section{Examining Attack and Defense with Detail} \label{sec:attackDefense} %The purpose of this section is to take the framework, along with the verification and selection process, and examine the stages of encryption and authentication and how including attack and defense considerations changes the landscape. Depending on the point of view of the individual examining a system, the risk and cost analysis will yield different results to different individuals based on produced incentive and attractiveness of obtainable information in comparison to the defenses that must be circumvented and the related cost. This means that when accounting for the attacker and defender views, there will be further levels of considerations and some that can be wholly arbitrary. Certain aspects may be similar, such as the number of steps an individual must go through to interact with a system (e.g. subnets). While these do exist, the area of greater interest are the aspects that differ between the two points of view. To begin this process one needs to detail out any and all statistical information about attacks on various systems, how the hardware and software nuances affect the overall ranking of different methodologies, and most difficult, one must determine a method for applying the arbitrary qualitative sense of worth for specific data to one's equations in a meaningful way. Otherwise, the generated estimation metric becomes unintelligible. -\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} - -One can further complicate these calculations by including a difference in examining the costs from the standpoint of both the defender of some sensitive information and the attacker trying to acquire any and all `useful' data. One example of this are the `atkImpact' and `atkValue' fields in Listing~\ref{lst:AADLUserDefineHigh}. These represent potential metrics of importance for different elements, attack vectors(e.g. Figure~\ref{fig:attackTree}), or worth of data that can be obtained by attacking a given system. As a defender, one can work towards detailing a system's defenses to have a better interpretation of the attack landscape. For example: one can create a `correlation matrix' of the enacted defenses and the affect of failure of one defense on the other existing defense (0-1 scaled as well), as this would allow for greater detail of the system from the point of the defender. Additionally, this same information would be of great importance to a would-be attacker. +%\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} + +One can further complicate these calculations by including a difference in examining the costs from the standpoint of both the defender of some sensitive information and the attacker trying to acquire any and all `useful' data. +%One example of this are the `atkImpact' and `atkValue' fields in Listing~\ref{lst:AADLUserDefineHigh}. These represent potential metrics of importance for different elements, attack vectors(e.g. Figure~\ref{fig:attackTree}), or worth of data that can be obtained by attacking a given system. As a defender, one can work towards detailing a system's defenses to have a better interpretation of the attack landscape. +For example: one can create a `correlation matrix' of the enacted defenses and the affect of failure of one defense on the other existing defense (0-1 scaled as well), as this would allow for greater detail of the system from the point of the defender. Additionally, this same information would be of great importance to a would-be attacker. %\subsection{Expansion of Details} While the examinations proposed here are specific to the system under examination, considerations can extend to a far larger scope of concern. One can begin to account for the worth of data to external parties (e.g. any other individual that is not the attacker or defender; black market or customers). @@ -656,10 +680,9 @@ users that treat security with a laissez-faire attitude). This would allow for %\end{multline} % %`Initial Wealth' can be calculated from the design model generated, while the probability of events occurring will require more statistical harvesting of information relating to known attacks or event occurring within a given system. While advantageous from a business standpoint, this equation is also tailored to a specific point of view for examination of a given embedded systems security model. -Expanding on this concept of point-of-view, then next section moves to examining the generated secure embedded system models through the eyes of both the defender and the attack as well as considerations that arise. +%Expanding on this concept of point-of-view, then next section moves to examining the generated secure embedded system models through the eyes of both the defender and the attack as well as considerations that arise. While the considerations, up to this point, have mainly been focused on how to define risk, how to interpret qualitative values of security into quantitative ones, and even how the examination of a system changes when incorporating attacker and defender points of view, there are still larger problems that must be addressed. - One of the largest problems facing security verification and validation techniques is the requirement for a `security expert' to formulate `libraries' of information and other data that will be needed for greater formalization of calculated values. Unfortunately these `libraries' are almost entirely arbitrary with respect to the knowledge and experience of a given security expert. This allows a great deal of room for inconsistencies due to human input. While Ferrante et.~al.~developed a method for locating inconsistencies within their work, there is no standardized methodology for determining inconsistencies in general. this means that these values can not be calculated in a deterministic manner and require a more `relatively deterministic' touch. %An other concern is that current attempts at developing security metrics produce unit-less metrics; due to their arbitrary nature. For example: in the work by Ferrante et.~al.~they are able to produce a metric value, but the interpretation of that value requires an explanation by the researchers instead of allowing for a glance-interpretation of the data. This complicates manners of comparison and is a known problem when trying to develop new benchmarks and standards for comparison. This paper proposed a standard of maintaining a monetary-time value since most aspects of security incorporate time to some degree and it is relatively simple to associate a financial value to time spent.