Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Additional writing for framework and simple example sections. Additio…
…n on citiations for Ferrante et. al. work on security metrics.
  • Loading branch information
Duncan committed Jun 28, 2016
1 parent e31b479 commit 68bb139
Showing 1 changed file with 21 additions and 9 deletions.
30 changes: 21 additions & 9 deletions AADLSecPaper.tex
Expand Up @@ -113,7 +113,7 @@ AADL, like most modeling languages, must be able to describe not only the requir
\item What are the challenges? The challenges faced
\begin{itemize}
\item How does one begin to place units on an arbitrary thing like risk? Risk is generally treated as a probability that an event will occur. To define 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}.
\item 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 solutions from a 0.00 -{}- 1.00 scale. Work on implementing this can be seen in a paper by \textbf{MENTION AUTHORS OF SECURITY METRIC PAPER}~\cite{CITE SECURITY METRIC PAPER}.
\item 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 solutions from a 0.00 -{}- 1.00 scale. Work on implementing this can be seen in a paper by Ferrante et.~al.~\cite{Ferrante2013}.
\end{itemize}
\item Why use AADL? Why should this paper have chosen to examine embedded system security modeling through the AADL language? AADL has a large and active community that works towards development and improvement of new annexes or other extensions to the existing AADL lexicon. In addition to the ease of extensibility, AADL is an easy language to pick up and learn. This paired with the way in which AADL has been intuitively built, allows for ease of extension by other users or even the community at large.
\item What needs to be done that is not being done?
Expand All @@ -135,7 +135,7 @@ Points to make in this section of the paper:
\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'. Recent AADL extensions to the security annex describes the security aspect of `trust' as a non-binary value, which this paper sees has not an accurate reflection of security concerns and does not allow for accurate verification and validation of security requirements and behavior. While the concept of `trust' can be influenced by aspects of reliability, the metric used for measuring trust should be binary as one can not say that they trust a component, or system, 80\% of the time; whereas reliability can be easily described as a percentage.
\item With all the work towards describing and defining security modeling aspects, there is a need to develop a method for calculating `estimation metrics' that can be used to compare and contrast generated solutions. To even begin development of these metrics, one needs to be able to account for a `security metric' that can represent differing solutions, algorithms, methods for tackling security concerns and requirements. This `security metric' value should be `relatively deterministic'. What this paper means it that the values calculated should be deterministic, but that this deterministic nature will originate from a scaling, or ranking, that is `relative' to the capabilities of the security aspect being examined (e.g. ranking encryption techniques~\cite{SECURITY METRICS PAPER}). Further more, these metrics must eventually all have the same basic `unit of measure', thus allowing for an `easy' interpretation of developed metrics and calculated values for various security solution implementation designs. The 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 unit-less metric to a time metric to a monetary metric. To better describe these security models from a financial standpoint, it might be advantageous to have the final estimation metric be represented with a money over time unit of measurement.
\item With all the work towards describing and defining security modeling aspects, there is a need to develop a method for calculating `estimation metrics' that can be used to compare and contrast generated solutions. To even begin development of these metrics, one needs to be able to account for a `security metric' that can represent differing solutions, algorithms, methods for tackling security concerns and requirements. This `security metric' value should be `relatively deterministic'. What this paper means it that the values calculated should be deterministic, but that this deterministic nature will originate from a scaling, or ranking, that is `relative' to the capabilities of the security aspect being examined (e.g. ranking encryption techniques~\cite{Ferrante2013}). Further more, these metrics must eventually all have the same basic `unit of measure', thus allowing for an `easy' interpretation of developed metrics and calculated values for various security solution implementation designs. The 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 unit-less metric to a time metric to a monetary metric. To better describe these security models from a financial standpoint, it might be advantageous to have the final estimation metric be represented with a money over time unit of measurement.
\end{itemize}
\item Section~\ref{sec:framework} will propose a security framework that can be used for applying mapping process by which a set of risk-based equations can be used to assign metrics to developed embedded system security models. But before one can even begin to apply a framework to this mapping process, one needs to first be able to define `Security Risk' so that a relatively deterministic formula can be used to obtain a meaningful metric.
\end{itemize}
Expand Down Expand Up @@ -255,13 +255,17 @@ Give a detailed description of the framework at this point in time. What is the

Now that this paper has presented a meaningful manner of representing security risk as a metric, this paper moves to show that the introduced security framework is an ideal fit for continuing development and improvement of embedded system security modeling techniques and methodologies. The key points to touch upon in this section are:
\begin{itemize}
\item What does the proposed framework bring to the table that lacked in previous security framework designs?
\item How can this framework and the security risk equations developed earlier be used to produce something meaningful? (e.g. security model)
\item What does the proposed framework bring to the table that lacked in previous security framework designs? The new security framework proposed allows for generation of embedded system security models by assuming that the security requirements and architectural component capabilities can be represented in a quantitative manner. With the framework, shown in Figure~\ref{fig:AADLSecFrame}, one can take the risk equations developed in Section~\ref{sec:riskDefinition} and produce a meaningful metric estimation that can be used to compare and contrast varying security model solutions. Combination of the framework's mapping process and the risk equations developed is done in the following manner:
\begin{itemize}
\item Define the security requirements and architectural components in a numerically meaningful manner.
\item Take these unit-less metrics and apply a `conversion equation' to them in order to produce a meaningful, `monetary unit' based metric.
\item Develop a method of interpreting the metrics in terms of requirements met, not met, and additional features added to the system.
\item Combine these metrics in a unified equation that can be used to take in values from the functional and architectural space to produce a series of embedded system security model solutions.
\end{itemize}
\item What are the complication of combining these techniques?
\begin{itemize}
\item What is easy to solve but time consuming?
\item What is easy to solve but just hasn't been examined properly?
\item What is still insanely tough about doing this?
\item One complication of this technique is the requirement to create `libraries' for certain aspects of the security modeling framework; for example, the various solution implementations for `keeping data secure'. More will be touched upon this subject in Section~\ref{sec:additionalConcerns}. Another concern is how one ranks all the various security solutions, algorithms, and methodologies in such a manner that the capabilities of the architectural components play a part in determining the best solution models that can be generated from a given set of constraints.
\item Certain aspects of this mapping process are easier to tackle but just have not had the time and effort focused on them. One such aspect is defining security terms in a manner that can be standardized for use. However, although choosing the language to describe security concepts and ideas may be simple, having that language remain flexible and relevant over the course of security's evolution is not as easy. Working towards an effective, rigorous, and standardized security modeling framework is something that will not only benefit the security community, but will allow for better representation and understanding in other fields as well (e.g. business).
\end{itemize}
\item Now that aspects of this framework's mapping process have been explained, allow us to apply these techniques to a sample example.
\end{itemize}
Expand Down Expand Up @@ -303,13 +307,20 @@ How does a simple examples such as a wireless transmitter get represented in thi

This paper now moves to showing a simple implementation of the security framework's mapping process to produce a meaningful `estimation metric' that can be used to compare design decisions. This Section must be sure to cover:
\begin{itemize}
\item What is the example to be shown?
\item What is the example to be shown? The simple example that this paper will examine is that of a wireless transmitter. In this example, there are four variations that exist of said transmitter:
\begin{enumerate}
\item Non-encrypted communication with a separate input and output buses.
\item Encrypted communication with separate input and output buses.
\item Non-encrypted communication with a single IO bus.
\item Encrypted communication with a single IO bus.
\end{enumerate}
For this example, one is deal with four instances of a single possible solution being generated based on two aspects of the architectural space: (1) the number of IO buses available and (2) whether or not communication should be encrypted. For the sake of simplicity, this paper makes use of the `relativity matrix' developed by Ferrante et.~al.~\cite{Ferrante2013}
\begin{itemize}
\item Wireless transmitter example
\end{itemize}
\item How does one create the security metric based on the given example?
\begin{itemize}
\item Require the creation of `relativity matrix'~\cite{SECURITY METRIC PAPER} for developing a relatively deterministic security metric value. (Perhaps cite work and use metrics developed by SECURITY METRIC PAPER).
\item Require the creation of `relativity matrix'~\cite{Ferrante2013} for developing a relatively deterministic security metric value. (Perhaps cite work and use metrics developed by Ferrante et.~al.).
\item How to consider differences between the four implementations of the wireless transmitter?
\begin{itemize}
\item What are the differences?
Expand Down Expand Up @@ -439,6 +450,7 @@ The purpose of this section is to talk about the topics:
\end{itemize}

\section{Additional Concerns}
\label{sec:additionalConcerns}
The purpose of this section is to talk about the topics:
\begin{itemize}
\item Detail out the concerns about for needs of `libraries' of information and other data that will be required for greater formalization of calculated values.
Expand Down

0 comments on commit 68bb139

Please sign in to comment.