Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Draft of paper for AsiaCCS 2017 conference
  • Loading branch information
Duncan committed Nov 24, 2016
1 parent 78ed728 commit a69c293
Showing 1 changed file with 94 additions and 18 deletions.
112 changes: 94 additions & 18 deletions sig-alternate-sample.tex
Expand Up @@ -263,24 +263,91 @@ What are the security concerns of embedded systems? How do the constraints of a

\section{Related Work}
Related work in the field:
\subsection{Modeling}
\begin{itemize}
\item System Modeling
\begin{itemize}
\item AADL
\end{itemize}
\item Security Modeling
\item Metrics of Security
\end{itemize}
\subsection{Defining Risk}
\begin{itemize}
\item Traditional View of Risk
\item How to Define Risk in Security
\begin{itemize}
\item Need to Define Risk
\end{itemize}
\item Show Math of How to Calculate Risk for a Given System
\end{itemize}

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}
Expand Down Expand Up @@ -427,6 +494,15 @@ Talk about modeling an attacker:
\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}

Expand Down

0 comments on commit a69c293

Please sign in to comment.