Fix of all citations to display correctly

AADLSecPaper.tex

@@ -59,8 +59,8 @@ The Architecture Analysis \& Design Language (AADL) is an architecture descripti
 Recent work on extending AADL's capabilities and tools has ranged from the development of error tracking, behavioral descriptions and definitions, code generation, requirement modeling, security description and definition, as well as verification of proposed system models and implementations.  With such research and effort being poured into the many facets of the language, AADL is becoming a more powerful and well rounded tool.  Due to the ease by which new extensions and user-define additions can be created for AADL, the community is greatly responsible for the development and improvement of AADL as a modeling and analysis tool.  More on these annexes and extensions will be examined in Section ~\ref{AADL Annexes and Extensions} along with their affect on the overall use and growth on the tools use and potential.
 
 \label{securityBasics}
-Secure systems design is a formidable and troublesome obstacle that is not well understood and even more poorly implemented.  From examples of Jeep Cherokee's security weaknesses~\cite{jeepHack}, airplane hacker scares~\cite{planeHack}, adware implementation weaknesses~\cite{superFish, lenovoWPBT}, government employee data breaches~\cite{govHack}, code implementation concerns~\cite{stageFright}, and other update security concerns~\cite{googleAndroid, androidMarshmallow} one can see that a lack of standardized security design and implementation can render catastrophic failure.  This issue is further exacerbated by how vast the problem space is (e.g. secure software, trusted platform modules, new authentication methods)~\cite{aaraj2008analysis, denning1996location, %mapayi2013evaluating, lin2015security, shi2013new, son2015software, 
-saito2015case, denning2015toward, nguyen2015model, ravi2004security, gokhale2008model, perez2006vtpm, yan2015novel, tehranipoor2015dram}.
+Secure systems design is a formidable and troublesome obstacle that is not well understood and even more poorly implemented.  From examples of Jeep Cherokee's security weaknesses~\cite{jeepHack}, airplane hacker scares~\cite{planeHack}, adware implementation weaknesses~\cite{superFish}\cite{lenovoWPBT}, government employee data breaches~\cite{govHack}, code implementation concerns~\cite{stageFright}, and other update security concerns~\cite{googleAndroid, androidMarshmallow} one can see that a lack of standardized security design and implementation can render catastrophic failure.  This issue is further exacerbated by how vast the problem space is (e.g. secure software, trusted platform modules, new authentication methods)~\cite{aaraj2008analysis}\cite{denning1996location} %mapayi2013evaluating, lin2015security, shi2013new, son2015software, 
+\cite{saito2015case}\cite{denning2015toward}\cite{nguyen2015model}\cite{ravi2004security}\cite{gokhale2008model}\cite{perez2006vtpm}\cite{yan2015novel}\cite{tehranipoor2015dram}.
 
 Security is always evolving as knowledge
 of encryption techniques, authentication technologies, access control methods and other security mechanisms change over
@@ -76,7 +76,7 @@ This paper is organized as follows: Section ~\ref{Motivation and Related Work} p
 \label{Motivation and Related Work}
 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 a 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{NEED TO SITE MARKOSE PAPER}.  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{I* PAPER CITE} and `SI*'~\cite{SI* PAPER CITE}.  The work by Eric Yu~\cite{I* PAPER CITE} 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.
+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.
@@ -110,7 +110,7 @@ Although security was not an initial concern in the development of the AADL lang
 More current work on the development of a security annex for AADL has been released~\cite{AADLSecAnnex}.  The concept behind this work is to extend the AADL language with a series of security annotations that will represent the security characteristics in designed architecture models.  In comparison to the earlier work by Ellison et.~al.~, there is still the existence of `Security Levels' (e.g. unclassified, secret, top secret) but there are now integer values associated with each level.  According to the information provided during the May 2016 User Days, this allows for greater compliance with other approaches such as Bell-Lapadula~\cite{AADLSecAnnex}.  Other additions to the language include the definition of domains (e.g. entertainment, command and control), a level of trust, a degree of exposure, along with enumerated definitions of encryption methods and properties as well as authentication methods and implementations.  In terms of security analysis tools, there has been work towards defining the attack surface in terms of how vulnerabilities are discovered within the architecture and a measurement of how safe a system is.  Along the same vein, there has also been work toward generating graphical representation of vulnerabilities and their impact upon the system; similar in nature to failure mode and effect analysis or fault tree analysis.  A more interesting development has been for including code generation for secure microkernel architectures such as the seL4.
 
 \subsection{AADL Tools support for Security}
-Due to the ease by which the user community can add and expand upon the existing AADL lexicon, this paper will have to narrow its examination of additional plug-in and tools to those that have more exposure in examples and other reference materials~\cite{Osate2Examples, UserDaysMay2016}.  The rest of this section will examine Resolute, RDALTE, EMV2, BLESS, and security extensions and annexes.
+Due to the ease by which the user community can add and expand upon the existing AADL lexicon, this paper will have to narrow its examination of additional plug-in and tools to those that have more exposure in examples and other reference materials~\cite{Osate2Examples}\cite{UserDaysMay2016}.  The rest of this section will examine Resolute, RDALTE, EMV2, BLESS, and security extensions and annexes.
 
 Resolute is a language and tool for developing architectural assurance cases~\cite{AADLResolute}.  Through this tool users are able to formulate claims and rules that are used to justify these user-defined claims.  Resolute then takes these claims and constructs assurance cases that are then verified and validated for a given architectural model.  Using this tool a user is able to reason about the flow of information through a system and the availability of resources under different operating modes~\cite{gacek2014resolute}.  This is advantageous because the same mechanism that allows for Resolute to model requirements of a system's architecture from an early phase, can also be tweaked to track basic security requirements of components that make up the architectural base of a design.  Coupled with Resolute's verification of these user-defined assurances, it can be easily seen as to why Resolute can be an effective tool for tracking security requirements across architectural abstractions and with some tinkering of the AADL language could even be used to track higher level requirements of the system as a whole.  Future work of this tool is aimed towards allow for exportation of the defined assurance cases to other tools as well~\cite{gacek2014resolute}.  Unfortunately there has not been much work toward this goal.  When examining the security-based extensions to AADL, this paper will touch back upon Resolute's use for security requirement definition.
 
@@ -151,7 +151,7 @@ library is two-fold.  The first issue is that in 	order for a security implement
 one must rely on the knowledge of a `security expert' or `security experts' to define all the possible 
 combinations and implementations that are currently in use.  The second problem being the need to maintain such 
 a record in a formal and standardized method.  While not an impossible task, this is an issue that has plagued 
-this sort of work~\cite{jurjens2002umlsec, jurjens2005secure}.  This reliance on the knowledge and expertise of 
+this sort of work~\cite{jurjens2002umlsec}\cite{jurjens2005secure}.  This reliance on the knowledge and expertise of 
 individuals may not be avoidable, in which case the current solution may be the best at hand, but is by no means 
 a poor answer to a long standing problem.  The one addition that this paper does not agree with is the move to 
 describe the security aspect of `trust' as a non-binary value.  While the released work~\cite{AADLSecAnnex}