Research ArticleSecurity Evaluation Framework for Military IoT Devices
Sungyong Cha Seungsoo Baek Sooyoung Kang and Seungjoo Kim
Center for Information Security Technologies (CIST) Korea University Seoul 02841 Republic of Korea
Correspondence should be addressed to Seungjoo Kim skim71koreaackr
Received 6 March 2018 Revised 6 May 2018 Accepted 29 May 2018 Published 3 July 2018
Academic Editor Ilsun You
Copyright copy 2018 Sungyong Cha et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited
IoT is gaining importance in our lives and in the military too With the application of IoT paradigm in the military and theweapon systemrsquos connectivity to the network this facilitates the commanders to make real-time decisions However cybersecuritythreats to weapon systems intensify along with the growing of IoTrsquos benefits Coping with these cybersecurity threats nowadays werequire the implementation of ldquosecurity by designrdquo concept during weapon system development throughout the system lifecyclebut not traditional security solutions Since only developed countries are capable of developing systems on their own they adoptldquosecurity by designrdquo when developing new weapon systems another approach to acquire weapon systems is through import if acountry cannot develop the whole weapon system However few studies have been done on the security evaluation frameworkthat could be used upon purchase and integration of the developed weapon system In this paper we proposed a novel securityevaluation framework that could be used to integrate IoT devices and components into the weapon system and amethod to addresscybersecurity requirements using international standard security control
1 Introduction
With the advent of the IoT paradigm all devices connectedto the network began exchanging data among each otherThemilitary is aware of the benefits of IoT and has continuouslyapplied it to the weapon system which ultimately becomesan essential to achieve military goals [1] IoT technologyconnects and integrates into a myriad of devices and systemsbut this will also increase attack surface Until recently cyber-attacks have been spreading beyond PCs to devices which ofthose have been connected to the Internet and smartphones[2] But the security threats of the network-centric weaponsystems including the IoT devices are growing together withthe advantages of IoT too [3] What is more the militarydomain is targeted by hackers There is a recent experimentconducted in 2015 purported to hack into a Jeep Cherokeethe symbol of military mobility in the US and it turnedout to be a successful hacking later [4] In fact even if thenetwork is far from another network physically such asthe Internet and Intranet hacker attacks are still inexorableAccording to [5] there is a possibility that the Trident sys-tem in partitioned network will be hacked through the air-gap from an external network which will seriously affect
operation and reliability Therefore some argue that theprotection against cyber-attacks should be placed as the toppriority Simply the usual way to enhance cybersecurity ofthe existing systems by introducing security solutions egfirewall and cryptographic devices is no longer effective Ifa security vulnerability is found in a system denoting thatthe cybersecurity factor has not been embedded in the systemdesign at first it would be difficult and costly to fix it in someextreme cases it would be impossible to handle the problemIn order to overcome these defects researches are conductedby implementing security by design concept as displayedin [6ndash8] Representative examples are HACMS (High-Assur-ance Cyber Military Systems) project in DARPA (DefenseAdvanced Research Projects Agency) and theDefense Acqui-sition System in Department of Defense (DoD) which coor-dinately takes cybersecurity into account during weapon sys-tem acquisition [9 10]
However [9 10] only confine the consideration forcybersecurity to weapon systems which are developed by theUS in this manner when one country imports part or all of aweapon system from another country its cybersecurity couldnot be checked To remedy these drawbacks a compositesecurity evaluation method for assessing the cybersecurity
HindawiSecurity and Communication NetworksVolume 2018 Article ID 6135845 12 pageshttpsdoiorg10115520186135845
2 Security and Communication Networks
of the whole system in system integration has been studied[11 12 15] Such composite security evaluation method isyet difficult to be applied to weapon systems because of thedifferences in the evaluation target and assurance levels forthese composite security assessments Therefore accordingto [13] if the composite security evaluation cannot be im-plemented and the security of the system cannot be provedmathematically the system should be developed along a well-structured process hence we require a framework to evaluatecybersecurity when we buy parts from other countries andintegrate them To settle cybersecurity requirements acquirermakes and utilizes security controls For example there are253 security controls composed of 18 families being usedin the United States and 5 families and 76 security controlsutilized in Republic of Korea respectively [16] Neverthelesssecurity controls differ from country to country in termsof the criteria and description on top of that there aredifferences in interpretation between acquirer and providerwhich may result in missing some security functions of theweapon system hence a universal security control is impera-tive
In this paper we propose a novel evaluation frameworkthat could be used to evaluate cybersecurity requirementsnot uponweapon system development but the import of partor all of a weapon system from other countries By using theinternational cybersecurity standards security controls aswell as the understanding between acquirer and provider arethen unified in order to achieve mutual trust and strengthencybersecurity along the arms import process
The contents of this paper are as constructed as followswe discuss the research about the background of this studyin Section 2 in Section 3 we introduce the framework toimprove the cybersecurity when purchasing weapon systemsin which our proposal also maps out domestic security con-trols with international cybersecurity standards Followingthat we examine how the proposed process can be appliedin Section 4 we finalize the paper in Section 5
2 Related Work
21 Cybersecurity Evaluation in Domestic and InternationalReliability and security are verified through systemsrsquo cyber-security evaluation That is system users can make use ofevaluation certificationmethods to upgrade information pro-tection level of an organization and their asset and contributeto credibility Countries establish their standards to undergocybersecurity evaluation and requirements based on theirown circumstances To name a few BS 7799 part 2 [17] oper-ated byUnited Kingdom andTCSEC (Trusted Computer Sys-tem Evaluation Criteria) in the US [18] are the representa-tives of domestic evaluation standards NIST (National Insti-tute of Standards and Technology) documents are also refer-ences to many countries besides the US government [19]
ISO IEC 15408 [20] as known as the Common Criteria(CC) is an international standard established to coordinatedifferent information protection system evaluation standardsby country and to mutually certify the evaluation resultsCC consists of 11 Security Functional Requirements (SFRs)which defines the required structure and content of security
functional components and 10 Security Assurance Require-ments (SARs) define a scale for measuring assurance forcomponent target of evaluations However the limited abilityto evaluate a single product but not the whole system anddisability to provide an evaluation of environments elements(physical human and operational security) discern thedisadvantage of CC to this end the composite evaluationwas introduced Yet composite ToE (Target of Evaluation)of CC-CAP (Composite Assurance Packages) is subjected toproducts only with CC certification The highest evaluationlevel of CC-CAP CAP-C manifests a similar evaluation levelof EAL (Evaluation Assurance Level) 4 in CC to whichweapon systems requesting a level higher than EAL 5 arenot applicable CCDB-CPE (Common Criteria DevelopmentBoard-Composite Product Evaluation) approach could bedeployed to weapon systems demanding a level higher thanEAL 5 still this approach is yet to be claimed ideal designdocuments and other sensitive information are required tobe disclosed added to this disadvantage it is not suitablefor implementation in weapon systems as it was originallydesigned for smartcard evaluation EURO-MILS (multipleindependent levels of security) another evaluation approachappropriate for those security levels equivalent to EAL 5 isalso limited to the use of designated platforms only Table 1concludes the characteristics of these composite securityevaluation methods
ISOIEC 27001 [21] as known as the Information SecurityManagement System (ISMS) consists of 114 controls in a totalof 14 clauses It also carries out verification for informationsecurity policymanagement human resources security phys-ical environment security communication and operationmanagement information system construction and mainte-nance The security controls of ISOIEC 27001 could be indi-cators of whether the product (or information) is managedproperly based on the established procedureThere is a short-coming that the product security itself still could not beensubstantiatedTherefore it is necessary to verify that the secu-rity of a product in general Since the SFRs of ISOIEC 15408is initiated to confirm only the implemented security func-tions of the product but not the environment related to thedevelopment the evaluation of functional and nonfunctionalparts of the weapon system could be done by complementingISOIEC27001 mentioned previously
22 Cybersecurity Evaluation in Defense The evaluation ofsecurity functions and assurance of a to-be-imported sys-tem is of considerable importance Despite that to achievehigh level of security and assurance of weapon systems aswell as security functional evaluation introducing formalverification is necessary Nevertheless a formal verificationentails the combination of all the functions in the system tobe proved mathematically to validate the logic A frameworkshould be followed by awell-defined development process if itcannot be proved on a mathematical basis [13] Products aredeveloped according to the System Development Life Cycle(SDLC) similarly weapon systems are developed based onSDLC considering whether they are suitable to the acquisi-tion system of the respective country However these acqui-sition systems have traditionally focused on performance
Security and Communication Networks 3
Table 1 Composite security evaluation approach
CC-CAP [11] CCDB-CPE [12] EURO-MILS [13]
Operation area CCRAMembers CCRAMembers European countries(28 countries) (28 countries)
key features
a composite Target of Evaluation(TOE) is composed of
components that have alreadypassed CC evaluation
enable installing applicationsonto an already passed CC
evaluation platform
reuse componentcertificates
Evaluation subject information product smartcard avionic andautomotive
Assurance Level CAP-(A B C) EAL1 sim EAL7 comparable to EAL 5lowast CAP-C is comparable to EAL4
CC
Product
System CampA
Environment
Figure 1 Scope of security evaluation by CC and CampA
and operability rather than cybersecurity aspects of weaponsystems Instead of changing the acquisition system to rein-force cybersecurity processes such as CampA (Certificationand Accreditation) are blended into the existing systems toenhance cybersecurity level of which this practice is shownin Figure 1
The CampA process was introduced in the Trusted Com-puter System Evaluation Criteria (TCSEC) [18] known as theOrange Book and was then recognized as an internationalstandard under the name of Common Criteria (CC) [20]However as described in Section 21 there are drawbacks thatmake it difficult to apply these evaluation methods directlyto weapon systems Thus the US Department of Defense(DoD) created the Department of Defense InformationTechnology Security Certification and Accreditation Process(DITSCAP) in 1997 for environmental and system securityevaluation as well as product security [23] Later on theDoD released Information Assurance Accreditation Process(DIACAP) [24] to overcome the drawbacks of DITSCAPand is currently operating Risk Management Framework(RMF) [25 26] At present cybersecurity-enhanced defenseacquisition system with RMF employed in the US is shownin Figure 2 [22] However [22] focuses only on weaponssystems development and hence is difficult to use whenpurchasing and integrating parts of weapons systems It is noteasy to apply the above-mentioned system in other countries
because most countries would not develop weapons systemsby themselves but import weapons systems from other coun-tries For example some countries purchase critical partseg stealth functions in developed countries in essence it isproblematic to verify security by using different cyber secu-rity processes and standards for acquirers and providers Be-sides the provider developed the system of which its riskmanagementwas based on the assumption of an environmenttotally different from that of the acquirer Therefore it is notappropriate for the acquirer to assess risk based on the sameenvironment in this respect Therefore we need a frameworkto design verify and test cyber security in the weapon systemimport process Figure 3 is a general weapon system importprocess where we must combine some of the frameworks toenhance cybersecurity
An analysis of the defense acquisition system shows thatthe Risk Management Framework and Cybersecurity Test ampEvaluation are carried out throughout the lifecycle of weaponsystem development In addition it applies not only to riskmanagement in functional part of the weapon system butalso to the nonfunctional aspects such as the developmentenvironment and human resources Therefore it is essentialto apply risk management in both functional and nonfunc-tional parts of the weapon system during the purchasingprocess shown in Figure 3
23 Weaknesses in Current Evaluation Framework To sum-marize the issues discussed earlier first of all among the exist-ing import process for weapons systems there is no frame-work to enhance cybersecurity Secondly there is a possibilityof misinterpretation of weapon security requirements thatarises fromdifferences in security controls adopted in variouscountries For that reason the requirements for the weaponsystem import process are summarized as follows
(i) To comprehensively evaluate both security and non-security functions processes for enhancing cyberse-curity such as RMF and Cybersecurity TampE shouldbe integrated into existing import processes
(ii) Security controls of the provider and the acquirershould be matched so that they can be used in allinstances not limited to specific countries
4 Security and Communication Networks
AssessSecurity Controls
SystemCategorize①
②③
④
⑥⑤
ImplementSecurity Controls
CooperativeVulnerabilityIdentification
AuthorizeSystem
AdversarialCybersecurity
DTampE
MonitorSecurity Controls
UnderstandCybersecurityRequirements
CharacterizeCyber Attack
Surface
CooperativeVulnerabilityPenetrationAssessment
AdversarialAssessment
Security ControlsSelect
Requirement Design Implementation Test amp Evaluation Operation
MaterialSolutionAnalysis
TechnologyMaturation amp
Risk Reduction
Engineering ampManufacturingDevelopment
Production andDeployment
Operationamp
Support
System Security Engineering
SDLC
DefenseAcquisition
System
RMF
SSE
TampECybersecurity
Figure 2 Defense Acquisition System in the US for enhancing cybersecurity [22]
RFP Release
Proposal Assessment
Test amp Evaluation
Decision
requirements
Assessment ofrequirementssatisfaction
Decision
Requirements
Figure 3 General weapon system purchasing process
3 Proposed Security Evaluation Framework
31 Security Evaluation Framework In this chapter we pro-pose a new security evaluation framework that combinesRMF and Cybersecurity Test amp Evaluation in the existingweapons import process with cybersecurity internationalstandards The framework for improving cybersecurity isshown in Figure 4A sim F relate to eachRMF step in Figure 2and the blue boxes indicate the purchase process in Figure 3the red and green boxes represent RMF and CybersecurityTampE in Figure 2 respectively Also the indicators of italicizedalphabets for flow of steps are illustrated in detail below
(A) Defining Requirements with Risk Identification (SystemCategorization) At this stage the same method as the firststep in RMF [25 26] is used to identify the risks for theproduct (or system) to be acquired And the provisionalimpact value for each risk is calculated Provisional impactvalues are classified into three levels high moderate lowfor confidentiality integrity and availability By defining thecybersecurity requirements for the product to be acquiredwith reference to the impact value of the identified riskthe unnecessary cost can be reduced and accurate securityfunctions can be implemented These cybersecurity require-ments are then integrated with other functions operatingrequirements and then passed on to the next step
(B) Selecting Appropriate Security Controls from the Require-ments In this step we choose security controls as a counter-measure to achieve the cybersecurity requirements definedin step (A) To select security controls for the product to beimported we should review the security controls in the parentsystems first and determine if there are any security controlsthat could be inherit from the system Those are inherent inthe system should be tailored out from the product list ofsecurity controls and the remaining list would be the securitycontrolswe should implement At this point the security con-trol set made by the acquirer comes into effect The reason isto reduce time to select security controls and to remove miss-ing parts by using new sets of security controls that are notfamiliar with If there is no set of security controls availablefrom the acquirer they may skip this step and the providermay bring up a set of security controls or a set of internationalstandard security controls Once the security controls havebeen selected one can proceed to the next step following byreview
(C) Converting the Security Controls into the InternationalStandards The selected security controls are converted intointernational standard (ISOIEC 15408 ISOIEC27001) secu-rity controls at this stage The reason for this standardizationis that it is difficult for the provider to clearly understandthe security controls of the acquirer so the misunderstandingensued from such environmental differences can be reducedHowever the problem is to what extent the set of securitycontrols of the acquirer and the provider can be convertedand expressed under the set of international standard securitycontrols This will be covered in detail in Section 32 andbriefly the mapping table and definition of addition subjectsare provided in Appendix H [16]
Concurrently the part corresponding to the function ofproduct security is converted into the Security FunctionalRequirements (SFR) of ISOIEC 15408 and that of operationand environment is converted into ISO IEC 27001 Nonethe-less there are real cases where ISOIEC 15408 does not cover
Security and Communication Networks 5
Requirement
Requirements
SystemCategorize
Design
SelectSecurity Controls
for acquirer
RFP Document
InternationalStandards
Security Controls
Development
Provider
Test ampEvaluation Operation(SI)
SDLC
PurchaseProcess
RMF
ProposeFramework
SC based Criteria
CybersecurityTampE
Non-Functional Non-Functional
FunctionalFunctional
ExamineDocumentation
System Integration Riskacceptable
Test andEvaluation
purchase
RFPReview
RFP
Risk Assessment
RiskUnacceptable
Release
① ② ②
③
④⑤
④
④
Figure 4 Proposed security evaluation framework
all the conversions for product security function then ISO IEC 27001 is used for the conversion in such cases Usinginternational standard security controls in this construct wecan generate a set of security requirements similar to theProfile Protection used in the Common Criteria
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation It is a step for a comprehensiveassessment of those security controls functions and operat-ing requirements that has been converted into internationalstandards which reflect cyber security requirements Themain objective at this stage is to gather all stakeholders andcoordinate any conflicting interests in between in particularto adjust requirements that may be confined to fundingIf resource constraints and other issues do not reflect allrequirements they should be broken down into mandatoryrequirements and optional requirements on the foundation ofdistinguished risk and impact values identified in the first step[27] In other words risk-based decisions are made so thatrisks can be handled according to priorities Once everythingis done consistently it is followed by the announcement ofRFP (Request for Proposal)
While the provider is in the middle of RFP release andproposal preparation the acquirer constructs the evaluationlist by dividing the nonsecurity functional part and thesecurity functional part based on the cybersecurity require-ments in Figure 4 The rationale behind this is to insure theevaluation of security-related means and environments forrequired security functions and product development
(E) Evaluation of Submitted Proposals and PreverificationThe provider submits the proposal of the announced RFP
CharacterizeAttackSurface
IdentifyKnown
vulnerabilities
PenetrationTest
Figure 5 Security functional test flow
to the acquirer based on the international standard securitycontrols Since the security nonfunctional parts are difficult toverify directly it is advised to submit proposal results whichhas been verified by an authorized third party Despite thefact that the nonfunctional parts could be compromised bycertifications such as ISOIEC 27001 it is only possible whenthe scope of evaluation is identical The security functionalparts are the main components to be verified in the nextstep ldquoReal verificationrdquo nevertheless it should also engagein assessing whether the document evaluation comprisesthe functionality to confirm the satisfactory level of securityfunctions When examining the satisfactory level of securityfunctions (for the security functional parts of the documentevaluation) it is necessary to deploy advance preparation toshorten the evaluation time for ldquoReal verificationrdquo Advancepreparation refers to the identification of the attack surfaceand the identification of known vulnerabilities [28] whichembody the penetration test and Figure 5 is a detaileddescription of E1015840 in Figure 4
(F) Functional RequirementVerification Products that passeddocumentation undergo another test to gauge whether theycan function exactly as what have been stated in the proposalThe focus of the verification is not only to validate the
6 Security and Communication Networks
Table 2 Number of security controls that do not provide mapping table in NIST 800-53
Security Controls Total Not ProvidesAC Access Control 25 8AT Awareness and Training 5 1AU Audit and Accountability 12 4CA Security Assessment and Authorization 9 5CM Configuration Management 11 2CP Contingency Planning 13 1IA Identification and Authentication 11 4IR Incident Response 10 5MA Maintenance 6 3MP Media Protection 8 1PE Physical and Environmental Protection 20 2PL Planning 9 1PS Personnel Security 8 1RA Risk Assessment 6 1SA System and services Acquisition 22 8SC System and Communications Protection 44 31SI System and Information Integrity 16 11PM Program Management 9 5
LikelihoodDetermination
ImpactAnalysis
RiskDetermination
Figure 6 Risk assessment flow
described requirements but also to confirm if cybersecurityis implemented properly by carrying out known vulnerabili-ties check and penetration testThe actual evaluation is basedon a block-box test However if the acquirer is in agreementwith the provider on white-box testing the acquirer couldverify the product in detail In case of lack of time and costthis might be an optional step for acquirers to follow
(G) Risk Assessment The product is cleared if it has passedthrough all the evaluations at ldquoverificationrdquo stage productsthat fail to meet the requirements criterion are directed toundergo risk assessment The first risk assessment was a pro-visional impact value done under a proposed situationwhereas the risk assessment at this step will be revealed usingreal data inputThe risk assessment flow is shown in Figure 6and this procedure is applied in accordance with the proce-dure in [29]
At this stage an actual and reliable risk assessment isfeasible as outcome is collected from real data If the risk levelresult is acceptable acquirer can advance to the next step ifnot the parts would be taken as inappropriate and acquirermay consult with provider
(H) Secure System Integration and Operational Test andEvaluation Products that survived ldquoverificationrdquo ((F) (G)Step) are incorporated into the whole system and are finally
reevaluated After integrating into the system similar evalua-tion on functionality of a single product goes through exceptthat the reevaluation for the time being concentrates on theproduct operability The ldquoAssurancerdquo part that is designedto guarantee the function performance of the product isexcluded from this paper
32 Mapping Security Controls to ISOIEC 15408 and 27001The security controls of acquirer have to be revised toadapt to international standardized security requirementswith a purpose to guarantee a successful flow of Stage (C) inSection 31This section illustrates the amended internationalsecurity controls with the most concrete and detailed NIST800-53 According to the analyzing result from the conversiontable provided in Appendix H 73 out of 252 security controlsin 18 categories are not provided with mapping as securitycontrols of ISOIEC 15408 and 27001 [Table 2]
Those security controls without mapping are analyzedand converted into international standard security controlsof which the results are shown in Table 3
The conversion of security controls demands consider-able of technical controls in view of this it is recommendedto proceed conversion using ISOIEC 15408The definition ofthe class regarding ISOIEC 15408 Security FunctionalRequirements is listed in Table 4 Also security controlsthat are not related to weapons purchasing IR (IncidentResponse) AT (Awareness and Training) and PM (ProgramManagement) are removed from conversion of security con-trols
For example the IA-3 (Device Identification and Authen-tication) relates to the identification and authentication ofdevices connected to the information systemThis control canbe converted into the UAU (User Authentication) and UID
Security and Communication Networks 7
Table 3 Security controls that are converted on component and family level
NIST Security Controls ISOIEC15408 Common Criteria Componentor Family
AC-21 Information Sharing FPT TDC1AC-22 Publicly Accessible Content FPT TDC1AC-23 Data Mining Protection FTA LSA1AU-13 Monitoring for Information Disclosure FAU SAR1 FDP ETC1AU-16 Cross-Organizational Auditing FAU SAR1CM-2 Baseline Configuration EAL packageIA-3 Device Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-9 Service Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-10 Adaptive Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2MP-8 Media Downgrading ALC CMC ALC CMSPE-6 Monitoring Physical Access FPT PHP1 FPT PHP2 FPT PHP3PE-8 Visitor Access Records ALC DVSPS-2 Position Risk Designation FPT PHP1 FPT PHP2 FPT PHP3RA-6 Technical Surveillance Countermeasures Survey AVA VANSA-2 Allocation of Resources FRU RSASA-13 Trustworthiness EAL packageSA-16 Developer-Provided Training ALC DVSSA-20 Customized Development of Critical Components ALC CMC ALC CMSSC-2 Application Partitioning FIA ATD1SC-18 Mobile Code FMT MSA1 FMT MSA2SC-19 Voice Over Internet Protocol FMT MSA1 FMT MSA2SC-20 Secure NameAddress Resolution Service (Authoritative Source) FMT MSA1 FMT MSA2SC-21 Secure NameAddress Resolution Service (Recursive or Caching Resolver) FMT MSA1 FMT MSA2SC-22 Architecture and Provisioning for NameAddress Resolution Service FMT MSA1 FMT MSA2SC-29 Heterogeneity FDP IFFSC-32 Information System Partitioning ADV ARCSC-37 Out-of-Band Channels FPT PHP1 FPT PHP2 FPT PHP3SC-39 Process Isolation ADV ARCSC-42 Sensor Capability and Data FDP ETC1 FDP ETC2SC-43 Usage Restrictions FDP IFF3
SI-8 Spam Protection FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-11 Error Handling FDP ACC1 FDP ACC2 FIA AFL1
SI-15 Information Output Filtering FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-16 Memory Protection ADV ARCSI-17 Fail-Safe Procedures FPT RCV ADV ARC
(User Identification) families in Functional Identification andAuthentication (FIA) class The selected components areshown in Table 5
The reason is that the FIA UID and FIA UAU familiesare related to user authentication and identification but canalso be described equivalently under the condition that theuser of the CC is conceived as the same subject as the devicein the NIST security controls However as shown in Table 6security controls of some specific technologies that are not
directly converted to the component or family unit can bemapped at the class level and organizational security policypursued by illustration
33 Comparison Analysis Different from other evaluationframeworks our proposed framework is intended for theintegration of imported systems It is set up based onRMF and Cybersecurity TampE of which their properties areinherited However as shown in Table 2 RMF does not carry
8 Security and Communication Networks
Table 4 Families of security functional requirements in ISOIEC15408
Family DescriptionFAU Security AuditFCO CommunicationFCS Cryptographic SupportFDP User Data ProtectionFIA Identification and AuthenticationFMT Security ManagementFPR PrivacyFPT Protection of the TSFFRU Resource utilizationFTA TOE accessFTP Trusted pathchannels
Table 5 Example of security control conversion into CC component
Components Description
FIA UAU1 Timing of authentication allows a user to perform certain actionsprior to the authentication of the userrsquos identity
FIA UAU2 User authentication before any action requires that users authenticatethemselves before any action will be allowed by the TSF
FIA UID1 Timing of identification allows users to perform certain actionsbefore being identified by the TSF
FIA UID1 User identification before any action require that users identifythemselves before any action will be allowed by the TSF
Table 6 Security controls that are converted on class level
NIST Security Controls ISOIEC15408Family
SA-22 Unsupported SystemComponents FMT
SC-25 Thin Nodes FRUSC-26 Honeypots FDP
SC-27 Platform-IndependentApplications FDP FIA
SC-30 Concealment andMisdirection FDP
SC-34 Non-ModifiableExecutable Programs FMT
SC-35 Honey clients FDP
SC-36 Distributed Processingand Storage FMT
SC-40 Wireless Link Protection FIA FPT FTAFTP
SC-44 Detonation Chambers FDPSI-14 Non-Persistence FDP
all the mapping tables required for international standardtherefore we propose an addition conversion method inSection 32 Table 7 is the comparison table of our frameworkwith RMF Cybersecurity TampE and CC-based approaches
4 Use-Case Adoption ofthe Inertial Navigation System Import forUnmanned Aerial Vehicle
A formal evaluation upon our framework would be an idealproof of frameworkrsquos novelty The framework we proposedhowever would be difficult to be proved formally as suchevaluation is out of scope of this proposal In lieu of a formalproof we demonstrate use-case to explain how our proposedframework in Section 3 is applied to the weapon systempurchasing process an example of an inertial navigationsystem(INS) built in an unmanned aerial vehicle (UAV) It isnoted that owing to confidentiality issue the components ofmilitary UAV are not disclosed hence we use a general UAVinstead for illustration in the use-case An inertial navigationsystem is a navigation aid that uses a computer motionsensors (accelerometers) rotation sensors (gyroscopes) andoccasionally magnetic sensors (magnetometers) to continu-ously calculate by dead reckoning the position the orienta-tion and the velocity (direction and speed of movement) of amoving object without the need for external references TheINS is a critical part of computing data from sensors in UAVthus security is assured
(A) Defining Requirements with Risk Identification (SystemCategorization) As presented in [30] the risk of INS in UAVshould be evaluated by the parameter ie velocity attitude
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
2 Security and Communication Networks
of the whole system in system integration has been studied[11 12 15] Such composite security evaluation method isyet difficult to be applied to weapon systems because of thedifferences in the evaluation target and assurance levels forthese composite security assessments Therefore accordingto [13] if the composite security evaluation cannot be im-plemented and the security of the system cannot be provedmathematically the system should be developed along a well-structured process hence we require a framework to evaluatecybersecurity when we buy parts from other countries andintegrate them To settle cybersecurity requirements acquirermakes and utilizes security controls For example there are253 security controls composed of 18 families being usedin the United States and 5 families and 76 security controlsutilized in Republic of Korea respectively [16] Neverthelesssecurity controls differ from country to country in termsof the criteria and description on top of that there aredifferences in interpretation between acquirer and providerwhich may result in missing some security functions of theweapon system hence a universal security control is impera-tive
In this paper we propose a novel evaluation frameworkthat could be used to evaluate cybersecurity requirementsnot uponweapon system development but the import of partor all of a weapon system from other countries By using theinternational cybersecurity standards security controls aswell as the understanding between acquirer and provider arethen unified in order to achieve mutual trust and strengthencybersecurity along the arms import process
The contents of this paper are as constructed as followswe discuss the research about the background of this studyin Section 2 in Section 3 we introduce the framework toimprove the cybersecurity when purchasing weapon systemsin which our proposal also maps out domestic security con-trols with international cybersecurity standards Followingthat we examine how the proposed process can be appliedin Section 4 we finalize the paper in Section 5
2 Related Work
21 Cybersecurity Evaluation in Domestic and InternationalReliability and security are verified through systemsrsquo cyber-security evaluation That is system users can make use ofevaluation certificationmethods to upgrade information pro-tection level of an organization and their asset and contributeto credibility Countries establish their standards to undergocybersecurity evaluation and requirements based on theirown circumstances To name a few BS 7799 part 2 [17] oper-ated byUnited Kingdom andTCSEC (Trusted Computer Sys-tem Evaluation Criteria) in the US [18] are the representa-tives of domestic evaluation standards NIST (National Insti-tute of Standards and Technology) documents are also refer-ences to many countries besides the US government [19]
ISO IEC 15408 [20] as known as the Common Criteria(CC) is an international standard established to coordinatedifferent information protection system evaluation standardsby country and to mutually certify the evaluation resultsCC consists of 11 Security Functional Requirements (SFRs)which defines the required structure and content of security
functional components and 10 Security Assurance Require-ments (SARs) define a scale for measuring assurance forcomponent target of evaluations However the limited abilityto evaluate a single product but not the whole system anddisability to provide an evaluation of environments elements(physical human and operational security) discern thedisadvantage of CC to this end the composite evaluationwas introduced Yet composite ToE (Target of Evaluation)of CC-CAP (Composite Assurance Packages) is subjected toproducts only with CC certification The highest evaluationlevel of CC-CAP CAP-C manifests a similar evaluation levelof EAL (Evaluation Assurance Level) 4 in CC to whichweapon systems requesting a level higher than EAL 5 arenot applicable CCDB-CPE (Common Criteria DevelopmentBoard-Composite Product Evaluation) approach could bedeployed to weapon systems demanding a level higher thanEAL 5 still this approach is yet to be claimed ideal designdocuments and other sensitive information are required tobe disclosed added to this disadvantage it is not suitablefor implementation in weapon systems as it was originallydesigned for smartcard evaluation EURO-MILS (multipleindependent levels of security) another evaluation approachappropriate for those security levels equivalent to EAL 5 isalso limited to the use of designated platforms only Table 1concludes the characteristics of these composite securityevaluation methods
ISOIEC 27001 [21] as known as the Information SecurityManagement System (ISMS) consists of 114 controls in a totalof 14 clauses It also carries out verification for informationsecurity policymanagement human resources security phys-ical environment security communication and operationmanagement information system construction and mainte-nance The security controls of ISOIEC 27001 could be indi-cators of whether the product (or information) is managedproperly based on the established procedureThere is a short-coming that the product security itself still could not beensubstantiatedTherefore it is necessary to verify that the secu-rity of a product in general Since the SFRs of ISOIEC 15408is initiated to confirm only the implemented security func-tions of the product but not the environment related to thedevelopment the evaluation of functional and nonfunctionalparts of the weapon system could be done by complementingISOIEC27001 mentioned previously
22 Cybersecurity Evaluation in Defense The evaluation ofsecurity functions and assurance of a to-be-imported sys-tem is of considerable importance Despite that to achievehigh level of security and assurance of weapon systems aswell as security functional evaluation introducing formalverification is necessary Nevertheless a formal verificationentails the combination of all the functions in the system tobe proved mathematically to validate the logic A frameworkshould be followed by awell-defined development process if itcannot be proved on a mathematical basis [13] Products aredeveloped according to the System Development Life Cycle(SDLC) similarly weapon systems are developed based onSDLC considering whether they are suitable to the acquisi-tion system of the respective country However these acqui-sition systems have traditionally focused on performance
Security and Communication Networks 3
Table 1 Composite security evaluation approach
CC-CAP [11] CCDB-CPE [12] EURO-MILS [13]
Operation area CCRAMembers CCRAMembers European countries(28 countries) (28 countries)
key features
a composite Target of Evaluation(TOE) is composed of
components that have alreadypassed CC evaluation
enable installing applicationsonto an already passed CC
evaluation platform
reuse componentcertificates
Evaluation subject information product smartcard avionic andautomotive
Assurance Level CAP-(A B C) EAL1 sim EAL7 comparable to EAL 5lowast CAP-C is comparable to EAL4
CC
Product
System CampA
Environment
Figure 1 Scope of security evaluation by CC and CampA
and operability rather than cybersecurity aspects of weaponsystems Instead of changing the acquisition system to rein-force cybersecurity processes such as CampA (Certificationand Accreditation) are blended into the existing systems toenhance cybersecurity level of which this practice is shownin Figure 1
The CampA process was introduced in the Trusted Com-puter System Evaluation Criteria (TCSEC) [18] known as theOrange Book and was then recognized as an internationalstandard under the name of Common Criteria (CC) [20]However as described in Section 21 there are drawbacks thatmake it difficult to apply these evaluation methods directlyto weapon systems Thus the US Department of Defense(DoD) created the Department of Defense InformationTechnology Security Certification and Accreditation Process(DITSCAP) in 1997 for environmental and system securityevaluation as well as product security [23] Later on theDoD released Information Assurance Accreditation Process(DIACAP) [24] to overcome the drawbacks of DITSCAPand is currently operating Risk Management Framework(RMF) [25 26] At present cybersecurity-enhanced defenseacquisition system with RMF employed in the US is shownin Figure 2 [22] However [22] focuses only on weaponssystems development and hence is difficult to use whenpurchasing and integrating parts of weapons systems It is noteasy to apply the above-mentioned system in other countries
because most countries would not develop weapons systemsby themselves but import weapons systems from other coun-tries For example some countries purchase critical partseg stealth functions in developed countries in essence it isproblematic to verify security by using different cyber secu-rity processes and standards for acquirers and providers Be-sides the provider developed the system of which its riskmanagementwas based on the assumption of an environmenttotally different from that of the acquirer Therefore it is notappropriate for the acquirer to assess risk based on the sameenvironment in this respect Therefore we need a frameworkto design verify and test cyber security in the weapon systemimport process Figure 3 is a general weapon system importprocess where we must combine some of the frameworks toenhance cybersecurity
An analysis of the defense acquisition system shows thatthe Risk Management Framework and Cybersecurity Test ampEvaluation are carried out throughout the lifecycle of weaponsystem development In addition it applies not only to riskmanagement in functional part of the weapon system butalso to the nonfunctional aspects such as the developmentenvironment and human resources Therefore it is essentialto apply risk management in both functional and nonfunc-tional parts of the weapon system during the purchasingprocess shown in Figure 3
23 Weaknesses in Current Evaluation Framework To sum-marize the issues discussed earlier first of all among the exist-ing import process for weapons systems there is no frame-work to enhance cybersecurity Secondly there is a possibilityof misinterpretation of weapon security requirements thatarises fromdifferences in security controls adopted in variouscountries For that reason the requirements for the weaponsystem import process are summarized as follows
(i) To comprehensively evaluate both security and non-security functions processes for enhancing cyberse-curity such as RMF and Cybersecurity TampE shouldbe integrated into existing import processes
(ii) Security controls of the provider and the acquirershould be matched so that they can be used in allinstances not limited to specific countries
4 Security and Communication Networks
AssessSecurity Controls
SystemCategorize①
②③
④
⑥⑤
ImplementSecurity Controls
CooperativeVulnerabilityIdentification
AuthorizeSystem
AdversarialCybersecurity
DTampE
MonitorSecurity Controls
UnderstandCybersecurityRequirements
CharacterizeCyber Attack
Surface
CooperativeVulnerabilityPenetrationAssessment
AdversarialAssessment
Security ControlsSelect
Requirement Design Implementation Test amp Evaluation Operation
MaterialSolutionAnalysis
TechnologyMaturation amp
Risk Reduction
Engineering ampManufacturingDevelopment
Production andDeployment
Operationamp
Support
System Security Engineering
SDLC
DefenseAcquisition
System
RMF
SSE
TampECybersecurity
Figure 2 Defense Acquisition System in the US for enhancing cybersecurity [22]
RFP Release
Proposal Assessment
Test amp Evaluation
Decision
requirements
Assessment ofrequirementssatisfaction
Decision
Requirements
Figure 3 General weapon system purchasing process
3 Proposed Security Evaluation Framework
31 Security Evaluation Framework In this chapter we pro-pose a new security evaluation framework that combinesRMF and Cybersecurity Test amp Evaluation in the existingweapons import process with cybersecurity internationalstandards The framework for improving cybersecurity isshown in Figure 4A sim F relate to eachRMF step in Figure 2and the blue boxes indicate the purchase process in Figure 3the red and green boxes represent RMF and CybersecurityTampE in Figure 2 respectively Also the indicators of italicizedalphabets for flow of steps are illustrated in detail below
(A) Defining Requirements with Risk Identification (SystemCategorization) At this stage the same method as the firststep in RMF [25 26] is used to identify the risks for theproduct (or system) to be acquired And the provisionalimpact value for each risk is calculated Provisional impactvalues are classified into three levels high moderate lowfor confidentiality integrity and availability By defining thecybersecurity requirements for the product to be acquiredwith reference to the impact value of the identified riskthe unnecessary cost can be reduced and accurate securityfunctions can be implemented These cybersecurity require-ments are then integrated with other functions operatingrequirements and then passed on to the next step
(B) Selecting Appropriate Security Controls from the Require-ments In this step we choose security controls as a counter-measure to achieve the cybersecurity requirements definedin step (A) To select security controls for the product to beimported we should review the security controls in the parentsystems first and determine if there are any security controlsthat could be inherit from the system Those are inherent inthe system should be tailored out from the product list ofsecurity controls and the remaining list would be the securitycontrolswe should implement At this point the security con-trol set made by the acquirer comes into effect The reason isto reduce time to select security controls and to remove miss-ing parts by using new sets of security controls that are notfamiliar with If there is no set of security controls availablefrom the acquirer they may skip this step and the providermay bring up a set of security controls or a set of internationalstandard security controls Once the security controls havebeen selected one can proceed to the next step following byreview
(C) Converting the Security Controls into the InternationalStandards The selected security controls are converted intointernational standard (ISOIEC 15408 ISOIEC27001) secu-rity controls at this stage The reason for this standardizationis that it is difficult for the provider to clearly understandthe security controls of the acquirer so the misunderstandingensued from such environmental differences can be reducedHowever the problem is to what extent the set of securitycontrols of the acquirer and the provider can be convertedand expressed under the set of international standard securitycontrols This will be covered in detail in Section 32 andbriefly the mapping table and definition of addition subjectsare provided in Appendix H [16]
Concurrently the part corresponding to the function ofproduct security is converted into the Security FunctionalRequirements (SFR) of ISOIEC 15408 and that of operationand environment is converted into ISO IEC 27001 Nonethe-less there are real cases where ISOIEC 15408 does not cover
Security and Communication Networks 5
Requirement
Requirements
SystemCategorize
Design
SelectSecurity Controls
for acquirer
RFP Document
InternationalStandards
Security Controls
Development
Provider
Test ampEvaluation Operation(SI)
SDLC
PurchaseProcess
RMF
ProposeFramework
SC based Criteria
CybersecurityTampE
Non-Functional Non-Functional
FunctionalFunctional
ExamineDocumentation
System Integration Riskacceptable
Test andEvaluation
purchase
RFPReview
RFP
Risk Assessment
RiskUnacceptable
Release
① ② ②
③
④⑤
④
④
Figure 4 Proposed security evaluation framework
all the conversions for product security function then ISO IEC 27001 is used for the conversion in such cases Usinginternational standard security controls in this construct wecan generate a set of security requirements similar to theProfile Protection used in the Common Criteria
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation It is a step for a comprehensiveassessment of those security controls functions and operat-ing requirements that has been converted into internationalstandards which reflect cyber security requirements Themain objective at this stage is to gather all stakeholders andcoordinate any conflicting interests in between in particularto adjust requirements that may be confined to fundingIf resource constraints and other issues do not reflect allrequirements they should be broken down into mandatoryrequirements and optional requirements on the foundation ofdistinguished risk and impact values identified in the first step[27] In other words risk-based decisions are made so thatrisks can be handled according to priorities Once everythingis done consistently it is followed by the announcement ofRFP (Request for Proposal)
While the provider is in the middle of RFP release andproposal preparation the acquirer constructs the evaluationlist by dividing the nonsecurity functional part and thesecurity functional part based on the cybersecurity require-ments in Figure 4 The rationale behind this is to insure theevaluation of security-related means and environments forrequired security functions and product development
(E) Evaluation of Submitted Proposals and PreverificationThe provider submits the proposal of the announced RFP
CharacterizeAttackSurface
IdentifyKnown
vulnerabilities
PenetrationTest
Figure 5 Security functional test flow
to the acquirer based on the international standard securitycontrols Since the security nonfunctional parts are difficult toverify directly it is advised to submit proposal results whichhas been verified by an authorized third party Despite thefact that the nonfunctional parts could be compromised bycertifications such as ISOIEC 27001 it is only possible whenthe scope of evaluation is identical The security functionalparts are the main components to be verified in the nextstep ldquoReal verificationrdquo nevertheless it should also engagein assessing whether the document evaluation comprisesthe functionality to confirm the satisfactory level of securityfunctions When examining the satisfactory level of securityfunctions (for the security functional parts of the documentevaluation) it is necessary to deploy advance preparation toshorten the evaluation time for ldquoReal verificationrdquo Advancepreparation refers to the identification of the attack surfaceand the identification of known vulnerabilities [28] whichembody the penetration test and Figure 5 is a detaileddescription of E1015840 in Figure 4
(F) Functional RequirementVerification Products that passeddocumentation undergo another test to gauge whether theycan function exactly as what have been stated in the proposalThe focus of the verification is not only to validate the
6 Security and Communication Networks
Table 2 Number of security controls that do not provide mapping table in NIST 800-53
Security Controls Total Not ProvidesAC Access Control 25 8AT Awareness and Training 5 1AU Audit and Accountability 12 4CA Security Assessment and Authorization 9 5CM Configuration Management 11 2CP Contingency Planning 13 1IA Identification and Authentication 11 4IR Incident Response 10 5MA Maintenance 6 3MP Media Protection 8 1PE Physical and Environmental Protection 20 2PL Planning 9 1PS Personnel Security 8 1RA Risk Assessment 6 1SA System and services Acquisition 22 8SC System and Communications Protection 44 31SI System and Information Integrity 16 11PM Program Management 9 5
LikelihoodDetermination
ImpactAnalysis
RiskDetermination
Figure 6 Risk assessment flow
described requirements but also to confirm if cybersecurityis implemented properly by carrying out known vulnerabili-ties check and penetration testThe actual evaluation is basedon a block-box test However if the acquirer is in agreementwith the provider on white-box testing the acquirer couldverify the product in detail In case of lack of time and costthis might be an optional step for acquirers to follow
(G) Risk Assessment The product is cleared if it has passedthrough all the evaluations at ldquoverificationrdquo stage productsthat fail to meet the requirements criterion are directed toundergo risk assessment The first risk assessment was a pro-visional impact value done under a proposed situationwhereas the risk assessment at this step will be revealed usingreal data inputThe risk assessment flow is shown in Figure 6and this procedure is applied in accordance with the proce-dure in [29]
At this stage an actual and reliable risk assessment isfeasible as outcome is collected from real data If the risk levelresult is acceptable acquirer can advance to the next step ifnot the parts would be taken as inappropriate and acquirermay consult with provider
(H) Secure System Integration and Operational Test andEvaluation Products that survived ldquoverificationrdquo ((F) (G)Step) are incorporated into the whole system and are finally
reevaluated After integrating into the system similar evalua-tion on functionality of a single product goes through exceptthat the reevaluation for the time being concentrates on theproduct operability The ldquoAssurancerdquo part that is designedto guarantee the function performance of the product isexcluded from this paper
32 Mapping Security Controls to ISOIEC 15408 and 27001The security controls of acquirer have to be revised toadapt to international standardized security requirementswith a purpose to guarantee a successful flow of Stage (C) inSection 31This section illustrates the amended internationalsecurity controls with the most concrete and detailed NIST800-53 According to the analyzing result from the conversiontable provided in Appendix H 73 out of 252 security controlsin 18 categories are not provided with mapping as securitycontrols of ISOIEC 15408 and 27001 [Table 2]
Those security controls without mapping are analyzedand converted into international standard security controlsof which the results are shown in Table 3
The conversion of security controls demands consider-able of technical controls in view of this it is recommendedto proceed conversion using ISOIEC 15408The definition ofthe class regarding ISOIEC 15408 Security FunctionalRequirements is listed in Table 4 Also security controlsthat are not related to weapons purchasing IR (IncidentResponse) AT (Awareness and Training) and PM (ProgramManagement) are removed from conversion of security con-trols
For example the IA-3 (Device Identification and Authen-tication) relates to the identification and authentication ofdevices connected to the information systemThis control canbe converted into the UAU (User Authentication) and UID
Security and Communication Networks 7
Table 3 Security controls that are converted on component and family level
NIST Security Controls ISOIEC15408 Common Criteria Componentor Family
AC-21 Information Sharing FPT TDC1AC-22 Publicly Accessible Content FPT TDC1AC-23 Data Mining Protection FTA LSA1AU-13 Monitoring for Information Disclosure FAU SAR1 FDP ETC1AU-16 Cross-Organizational Auditing FAU SAR1CM-2 Baseline Configuration EAL packageIA-3 Device Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-9 Service Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-10 Adaptive Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2MP-8 Media Downgrading ALC CMC ALC CMSPE-6 Monitoring Physical Access FPT PHP1 FPT PHP2 FPT PHP3PE-8 Visitor Access Records ALC DVSPS-2 Position Risk Designation FPT PHP1 FPT PHP2 FPT PHP3RA-6 Technical Surveillance Countermeasures Survey AVA VANSA-2 Allocation of Resources FRU RSASA-13 Trustworthiness EAL packageSA-16 Developer-Provided Training ALC DVSSA-20 Customized Development of Critical Components ALC CMC ALC CMSSC-2 Application Partitioning FIA ATD1SC-18 Mobile Code FMT MSA1 FMT MSA2SC-19 Voice Over Internet Protocol FMT MSA1 FMT MSA2SC-20 Secure NameAddress Resolution Service (Authoritative Source) FMT MSA1 FMT MSA2SC-21 Secure NameAddress Resolution Service (Recursive or Caching Resolver) FMT MSA1 FMT MSA2SC-22 Architecture and Provisioning for NameAddress Resolution Service FMT MSA1 FMT MSA2SC-29 Heterogeneity FDP IFFSC-32 Information System Partitioning ADV ARCSC-37 Out-of-Band Channels FPT PHP1 FPT PHP2 FPT PHP3SC-39 Process Isolation ADV ARCSC-42 Sensor Capability and Data FDP ETC1 FDP ETC2SC-43 Usage Restrictions FDP IFF3
SI-8 Spam Protection FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-11 Error Handling FDP ACC1 FDP ACC2 FIA AFL1
SI-15 Information Output Filtering FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-16 Memory Protection ADV ARCSI-17 Fail-Safe Procedures FPT RCV ADV ARC
(User Identification) families in Functional Identification andAuthentication (FIA) class The selected components areshown in Table 5
The reason is that the FIA UID and FIA UAU familiesare related to user authentication and identification but canalso be described equivalently under the condition that theuser of the CC is conceived as the same subject as the devicein the NIST security controls However as shown in Table 6security controls of some specific technologies that are not
directly converted to the component or family unit can bemapped at the class level and organizational security policypursued by illustration
33 Comparison Analysis Different from other evaluationframeworks our proposed framework is intended for theintegration of imported systems It is set up based onRMF and Cybersecurity TampE of which their properties areinherited However as shown in Table 2 RMF does not carry
8 Security and Communication Networks
Table 4 Families of security functional requirements in ISOIEC15408
Family DescriptionFAU Security AuditFCO CommunicationFCS Cryptographic SupportFDP User Data ProtectionFIA Identification and AuthenticationFMT Security ManagementFPR PrivacyFPT Protection of the TSFFRU Resource utilizationFTA TOE accessFTP Trusted pathchannels
Table 5 Example of security control conversion into CC component
Components Description
FIA UAU1 Timing of authentication allows a user to perform certain actionsprior to the authentication of the userrsquos identity
FIA UAU2 User authentication before any action requires that users authenticatethemselves before any action will be allowed by the TSF
FIA UID1 Timing of identification allows users to perform certain actionsbefore being identified by the TSF
FIA UID1 User identification before any action require that users identifythemselves before any action will be allowed by the TSF
Table 6 Security controls that are converted on class level
NIST Security Controls ISOIEC15408Family
SA-22 Unsupported SystemComponents FMT
SC-25 Thin Nodes FRUSC-26 Honeypots FDP
SC-27 Platform-IndependentApplications FDP FIA
SC-30 Concealment andMisdirection FDP
SC-34 Non-ModifiableExecutable Programs FMT
SC-35 Honey clients FDP
SC-36 Distributed Processingand Storage FMT
SC-40 Wireless Link Protection FIA FPT FTAFTP
SC-44 Detonation Chambers FDPSI-14 Non-Persistence FDP
all the mapping tables required for international standardtherefore we propose an addition conversion method inSection 32 Table 7 is the comparison table of our frameworkwith RMF Cybersecurity TampE and CC-based approaches
4 Use-Case Adoption ofthe Inertial Navigation System Import forUnmanned Aerial Vehicle
A formal evaluation upon our framework would be an idealproof of frameworkrsquos novelty The framework we proposedhowever would be difficult to be proved formally as suchevaluation is out of scope of this proposal In lieu of a formalproof we demonstrate use-case to explain how our proposedframework in Section 3 is applied to the weapon systempurchasing process an example of an inertial navigationsystem(INS) built in an unmanned aerial vehicle (UAV) It isnoted that owing to confidentiality issue the components ofmilitary UAV are not disclosed hence we use a general UAVinstead for illustration in the use-case An inertial navigationsystem is a navigation aid that uses a computer motionsensors (accelerometers) rotation sensors (gyroscopes) andoccasionally magnetic sensors (magnetometers) to continu-ously calculate by dead reckoning the position the orienta-tion and the velocity (direction and speed of movement) of amoving object without the need for external references TheINS is a critical part of computing data from sensors in UAVthus security is assured
(A) Defining Requirements with Risk Identification (SystemCategorization) As presented in [30] the risk of INS in UAVshould be evaluated by the parameter ie velocity attitude
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
Security and Communication Networks 3
Table 1 Composite security evaluation approach
CC-CAP [11] CCDB-CPE [12] EURO-MILS [13]
Operation area CCRAMembers CCRAMembers European countries(28 countries) (28 countries)
key features
a composite Target of Evaluation(TOE) is composed of
components that have alreadypassed CC evaluation
enable installing applicationsonto an already passed CC
evaluation platform
reuse componentcertificates
Evaluation subject information product smartcard avionic andautomotive
Assurance Level CAP-(A B C) EAL1 sim EAL7 comparable to EAL 5lowast CAP-C is comparable to EAL4
CC
Product
System CampA
Environment
Figure 1 Scope of security evaluation by CC and CampA
and operability rather than cybersecurity aspects of weaponsystems Instead of changing the acquisition system to rein-force cybersecurity processes such as CampA (Certificationand Accreditation) are blended into the existing systems toenhance cybersecurity level of which this practice is shownin Figure 1
The CampA process was introduced in the Trusted Com-puter System Evaluation Criteria (TCSEC) [18] known as theOrange Book and was then recognized as an internationalstandard under the name of Common Criteria (CC) [20]However as described in Section 21 there are drawbacks thatmake it difficult to apply these evaluation methods directlyto weapon systems Thus the US Department of Defense(DoD) created the Department of Defense InformationTechnology Security Certification and Accreditation Process(DITSCAP) in 1997 for environmental and system securityevaluation as well as product security [23] Later on theDoD released Information Assurance Accreditation Process(DIACAP) [24] to overcome the drawbacks of DITSCAPand is currently operating Risk Management Framework(RMF) [25 26] At present cybersecurity-enhanced defenseacquisition system with RMF employed in the US is shownin Figure 2 [22] However [22] focuses only on weaponssystems development and hence is difficult to use whenpurchasing and integrating parts of weapons systems It is noteasy to apply the above-mentioned system in other countries
because most countries would not develop weapons systemsby themselves but import weapons systems from other coun-tries For example some countries purchase critical partseg stealth functions in developed countries in essence it isproblematic to verify security by using different cyber secu-rity processes and standards for acquirers and providers Be-sides the provider developed the system of which its riskmanagementwas based on the assumption of an environmenttotally different from that of the acquirer Therefore it is notappropriate for the acquirer to assess risk based on the sameenvironment in this respect Therefore we need a frameworkto design verify and test cyber security in the weapon systemimport process Figure 3 is a general weapon system importprocess where we must combine some of the frameworks toenhance cybersecurity
An analysis of the defense acquisition system shows thatthe Risk Management Framework and Cybersecurity Test ampEvaluation are carried out throughout the lifecycle of weaponsystem development In addition it applies not only to riskmanagement in functional part of the weapon system butalso to the nonfunctional aspects such as the developmentenvironment and human resources Therefore it is essentialto apply risk management in both functional and nonfunc-tional parts of the weapon system during the purchasingprocess shown in Figure 3
23 Weaknesses in Current Evaluation Framework To sum-marize the issues discussed earlier first of all among the exist-ing import process for weapons systems there is no frame-work to enhance cybersecurity Secondly there is a possibilityof misinterpretation of weapon security requirements thatarises fromdifferences in security controls adopted in variouscountries For that reason the requirements for the weaponsystem import process are summarized as follows
(i) To comprehensively evaluate both security and non-security functions processes for enhancing cyberse-curity such as RMF and Cybersecurity TampE shouldbe integrated into existing import processes
(ii) Security controls of the provider and the acquirershould be matched so that they can be used in allinstances not limited to specific countries
4 Security and Communication Networks
AssessSecurity Controls
SystemCategorize①
②③
④
⑥⑤
ImplementSecurity Controls
CooperativeVulnerabilityIdentification
AuthorizeSystem
AdversarialCybersecurity
DTampE
MonitorSecurity Controls
UnderstandCybersecurityRequirements
CharacterizeCyber Attack
Surface
CooperativeVulnerabilityPenetrationAssessment
AdversarialAssessment
Security ControlsSelect
Requirement Design Implementation Test amp Evaluation Operation
MaterialSolutionAnalysis
TechnologyMaturation amp
Risk Reduction
Engineering ampManufacturingDevelopment
Production andDeployment
Operationamp
Support
System Security Engineering
SDLC
DefenseAcquisition
System
RMF
SSE
TampECybersecurity
Figure 2 Defense Acquisition System in the US for enhancing cybersecurity [22]
RFP Release
Proposal Assessment
Test amp Evaluation
Decision
requirements
Assessment ofrequirementssatisfaction
Decision
Requirements
Figure 3 General weapon system purchasing process
3 Proposed Security Evaluation Framework
31 Security Evaluation Framework In this chapter we pro-pose a new security evaluation framework that combinesRMF and Cybersecurity Test amp Evaluation in the existingweapons import process with cybersecurity internationalstandards The framework for improving cybersecurity isshown in Figure 4A sim F relate to eachRMF step in Figure 2and the blue boxes indicate the purchase process in Figure 3the red and green boxes represent RMF and CybersecurityTampE in Figure 2 respectively Also the indicators of italicizedalphabets for flow of steps are illustrated in detail below
(A) Defining Requirements with Risk Identification (SystemCategorization) At this stage the same method as the firststep in RMF [25 26] is used to identify the risks for theproduct (or system) to be acquired And the provisionalimpact value for each risk is calculated Provisional impactvalues are classified into three levels high moderate lowfor confidentiality integrity and availability By defining thecybersecurity requirements for the product to be acquiredwith reference to the impact value of the identified riskthe unnecessary cost can be reduced and accurate securityfunctions can be implemented These cybersecurity require-ments are then integrated with other functions operatingrequirements and then passed on to the next step
(B) Selecting Appropriate Security Controls from the Require-ments In this step we choose security controls as a counter-measure to achieve the cybersecurity requirements definedin step (A) To select security controls for the product to beimported we should review the security controls in the parentsystems first and determine if there are any security controlsthat could be inherit from the system Those are inherent inthe system should be tailored out from the product list ofsecurity controls and the remaining list would be the securitycontrolswe should implement At this point the security con-trol set made by the acquirer comes into effect The reason isto reduce time to select security controls and to remove miss-ing parts by using new sets of security controls that are notfamiliar with If there is no set of security controls availablefrom the acquirer they may skip this step and the providermay bring up a set of security controls or a set of internationalstandard security controls Once the security controls havebeen selected one can proceed to the next step following byreview
(C) Converting the Security Controls into the InternationalStandards The selected security controls are converted intointernational standard (ISOIEC 15408 ISOIEC27001) secu-rity controls at this stage The reason for this standardizationis that it is difficult for the provider to clearly understandthe security controls of the acquirer so the misunderstandingensued from such environmental differences can be reducedHowever the problem is to what extent the set of securitycontrols of the acquirer and the provider can be convertedand expressed under the set of international standard securitycontrols This will be covered in detail in Section 32 andbriefly the mapping table and definition of addition subjectsare provided in Appendix H [16]
Concurrently the part corresponding to the function ofproduct security is converted into the Security FunctionalRequirements (SFR) of ISOIEC 15408 and that of operationand environment is converted into ISO IEC 27001 Nonethe-less there are real cases where ISOIEC 15408 does not cover
Security and Communication Networks 5
Requirement
Requirements
SystemCategorize
Design
SelectSecurity Controls
for acquirer
RFP Document
InternationalStandards
Security Controls
Development
Provider
Test ampEvaluation Operation(SI)
SDLC
PurchaseProcess
RMF
ProposeFramework
SC based Criteria
CybersecurityTampE
Non-Functional Non-Functional
FunctionalFunctional
ExamineDocumentation
System Integration Riskacceptable
Test andEvaluation
purchase
RFPReview
RFP
Risk Assessment
RiskUnacceptable
Release
① ② ②
③
④⑤
④
④
Figure 4 Proposed security evaluation framework
all the conversions for product security function then ISO IEC 27001 is used for the conversion in such cases Usinginternational standard security controls in this construct wecan generate a set of security requirements similar to theProfile Protection used in the Common Criteria
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation It is a step for a comprehensiveassessment of those security controls functions and operat-ing requirements that has been converted into internationalstandards which reflect cyber security requirements Themain objective at this stage is to gather all stakeholders andcoordinate any conflicting interests in between in particularto adjust requirements that may be confined to fundingIf resource constraints and other issues do not reflect allrequirements they should be broken down into mandatoryrequirements and optional requirements on the foundation ofdistinguished risk and impact values identified in the first step[27] In other words risk-based decisions are made so thatrisks can be handled according to priorities Once everythingis done consistently it is followed by the announcement ofRFP (Request for Proposal)
While the provider is in the middle of RFP release andproposal preparation the acquirer constructs the evaluationlist by dividing the nonsecurity functional part and thesecurity functional part based on the cybersecurity require-ments in Figure 4 The rationale behind this is to insure theevaluation of security-related means and environments forrequired security functions and product development
(E) Evaluation of Submitted Proposals and PreverificationThe provider submits the proposal of the announced RFP
CharacterizeAttackSurface
IdentifyKnown
vulnerabilities
PenetrationTest
Figure 5 Security functional test flow
to the acquirer based on the international standard securitycontrols Since the security nonfunctional parts are difficult toverify directly it is advised to submit proposal results whichhas been verified by an authorized third party Despite thefact that the nonfunctional parts could be compromised bycertifications such as ISOIEC 27001 it is only possible whenthe scope of evaluation is identical The security functionalparts are the main components to be verified in the nextstep ldquoReal verificationrdquo nevertheless it should also engagein assessing whether the document evaluation comprisesthe functionality to confirm the satisfactory level of securityfunctions When examining the satisfactory level of securityfunctions (for the security functional parts of the documentevaluation) it is necessary to deploy advance preparation toshorten the evaluation time for ldquoReal verificationrdquo Advancepreparation refers to the identification of the attack surfaceand the identification of known vulnerabilities [28] whichembody the penetration test and Figure 5 is a detaileddescription of E1015840 in Figure 4
(F) Functional RequirementVerification Products that passeddocumentation undergo another test to gauge whether theycan function exactly as what have been stated in the proposalThe focus of the verification is not only to validate the
6 Security and Communication Networks
Table 2 Number of security controls that do not provide mapping table in NIST 800-53
Security Controls Total Not ProvidesAC Access Control 25 8AT Awareness and Training 5 1AU Audit and Accountability 12 4CA Security Assessment and Authorization 9 5CM Configuration Management 11 2CP Contingency Planning 13 1IA Identification and Authentication 11 4IR Incident Response 10 5MA Maintenance 6 3MP Media Protection 8 1PE Physical and Environmental Protection 20 2PL Planning 9 1PS Personnel Security 8 1RA Risk Assessment 6 1SA System and services Acquisition 22 8SC System and Communications Protection 44 31SI System and Information Integrity 16 11PM Program Management 9 5
LikelihoodDetermination
ImpactAnalysis
RiskDetermination
Figure 6 Risk assessment flow
described requirements but also to confirm if cybersecurityis implemented properly by carrying out known vulnerabili-ties check and penetration testThe actual evaluation is basedon a block-box test However if the acquirer is in agreementwith the provider on white-box testing the acquirer couldverify the product in detail In case of lack of time and costthis might be an optional step for acquirers to follow
(G) Risk Assessment The product is cleared if it has passedthrough all the evaluations at ldquoverificationrdquo stage productsthat fail to meet the requirements criterion are directed toundergo risk assessment The first risk assessment was a pro-visional impact value done under a proposed situationwhereas the risk assessment at this step will be revealed usingreal data inputThe risk assessment flow is shown in Figure 6and this procedure is applied in accordance with the proce-dure in [29]
At this stage an actual and reliable risk assessment isfeasible as outcome is collected from real data If the risk levelresult is acceptable acquirer can advance to the next step ifnot the parts would be taken as inappropriate and acquirermay consult with provider
(H) Secure System Integration and Operational Test andEvaluation Products that survived ldquoverificationrdquo ((F) (G)Step) are incorporated into the whole system and are finally
reevaluated After integrating into the system similar evalua-tion on functionality of a single product goes through exceptthat the reevaluation for the time being concentrates on theproduct operability The ldquoAssurancerdquo part that is designedto guarantee the function performance of the product isexcluded from this paper
32 Mapping Security Controls to ISOIEC 15408 and 27001The security controls of acquirer have to be revised toadapt to international standardized security requirementswith a purpose to guarantee a successful flow of Stage (C) inSection 31This section illustrates the amended internationalsecurity controls with the most concrete and detailed NIST800-53 According to the analyzing result from the conversiontable provided in Appendix H 73 out of 252 security controlsin 18 categories are not provided with mapping as securitycontrols of ISOIEC 15408 and 27001 [Table 2]
Those security controls without mapping are analyzedand converted into international standard security controlsof which the results are shown in Table 3
The conversion of security controls demands consider-able of technical controls in view of this it is recommendedto proceed conversion using ISOIEC 15408The definition ofthe class regarding ISOIEC 15408 Security FunctionalRequirements is listed in Table 4 Also security controlsthat are not related to weapons purchasing IR (IncidentResponse) AT (Awareness and Training) and PM (ProgramManagement) are removed from conversion of security con-trols
For example the IA-3 (Device Identification and Authen-tication) relates to the identification and authentication ofdevices connected to the information systemThis control canbe converted into the UAU (User Authentication) and UID
Security and Communication Networks 7
Table 3 Security controls that are converted on component and family level
NIST Security Controls ISOIEC15408 Common Criteria Componentor Family
AC-21 Information Sharing FPT TDC1AC-22 Publicly Accessible Content FPT TDC1AC-23 Data Mining Protection FTA LSA1AU-13 Monitoring for Information Disclosure FAU SAR1 FDP ETC1AU-16 Cross-Organizational Auditing FAU SAR1CM-2 Baseline Configuration EAL packageIA-3 Device Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-9 Service Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-10 Adaptive Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2MP-8 Media Downgrading ALC CMC ALC CMSPE-6 Monitoring Physical Access FPT PHP1 FPT PHP2 FPT PHP3PE-8 Visitor Access Records ALC DVSPS-2 Position Risk Designation FPT PHP1 FPT PHP2 FPT PHP3RA-6 Technical Surveillance Countermeasures Survey AVA VANSA-2 Allocation of Resources FRU RSASA-13 Trustworthiness EAL packageSA-16 Developer-Provided Training ALC DVSSA-20 Customized Development of Critical Components ALC CMC ALC CMSSC-2 Application Partitioning FIA ATD1SC-18 Mobile Code FMT MSA1 FMT MSA2SC-19 Voice Over Internet Protocol FMT MSA1 FMT MSA2SC-20 Secure NameAddress Resolution Service (Authoritative Source) FMT MSA1 FMT MSA2SC-21 Secure NameAddress Resolution Service (Recursive or Caching Resolver) FMT MSA1 FMT MSA2SC-22 Architecture and Provisioning for NameAddress Resolution Service FMT MSA1 FMT MSA2SC-29 Heterogeneity FDP IFFSC-32 Information System Partitioning ADV ARCSC-37 Out-of-Band Channels FPT PHP1 FPT PHP2 FPT PHP3SC-39 Process Isolation ADV ARCSC-42 Sensor Capability and Data FDP ETC1 FDP ETC2SC-43 Usage Restrictions FDP IFF3
SI-8 Spam Protection FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-11 Error Handling FDP ACC1 FDP ACC2 FIA AFL1
SI-15 Information Output Filtering FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-16 Memory Protection ADV ARCSI-17 Fail-Safe Procedures FPT RCV ADV ARC
(User Identification) families in Functional Identification andAuthentication (FIA) class The selected components areshown in Table 5
The reason is that the FIA UID and FIA UAU familiesare related to user authentication and identification but canalso be described equivalently under the condition that theuser of the CC is conceived as the same subject as the devicein the NIST security controls However as shown in Table 6security controls of some specific technologies that are not
directly converted to the component or family unit can bemapped at the class level and organizational security policypursued by illustration
33 Comparison Analysis Different from other evaluationframeworks our proposed framework is intended for theintegration of imported systems It is set up based onRMF and Cybersecurity TampE of which their properties areinherited However as shown in Table 2 RMF does not carry
8 Security and Communication Networks
Table 4 Families of security functional requirements in ISOIEC15408
Family DescriptionFAU Security AuditFCO CommunicationFCS Cryptographic SupportFDP User Data ProtectionFIA Identification and AuthenticationFMT Security ManagementFPR PrivacyFPT Protection of the TSFFRU Resource utilizationFTA TOE accessFTP Trusted pathchannels
Table 5 Example of security control conversion into CC component
Components Description
FIA UAU1 Timing of authentication allows a user to perform certain actionsprior to the authentication of the userrsquos identity
FIA UAU2 User authentication before any action requires that users authenticatethemselves before any action will be allowed by the TSF
FIA UID1 Timing of identification allows users to perform certain actionsbefore being identified by the TSF
FIA UID1 User identification before any action require that users identifythemselves before any action will be allowed by the TSF
Table 6 Security controls that are converted on class level
NIST Security Controls ISOIEC15408Family
SA-22 Unsupported SystemComponents FMT
SC-25 Thin Nodes FRUSC-26 Honeypots FDP
SC-27 Platform-IndependentApplications FDP FIA
SC-30 Concealment andMisdirection FDP
SC-34 Non-ModifiableExecutable Programs FMT
SC-35 Honey clients FDP
SC-36 Distributed Processingand Storage FMT
SC-40 Wireless Link Protection FIA FPT FTAFTP
SC-44 Detonation Chambers FDPSI-14 Non-Persistence FDP
all the mapping tables required for international standardtherefore we propose an addition conversion method inSection 32 Table 7 is the comparison table of our frameworkwith RMF Cybersecurity TampE and CC-based approaches
4 Use-Case Adoption ofthe Inertial Navigation System Import forUnmanned Aerial Vehicle
A formal evaluation upon our framework would be an idealproof of frameworkrsquos novelty The framework we proposedhowever would be difficult to be proved formally as suchevaluation is out of scope of this proposal In lieu of a formalproof we demonstrate use-case to explain how our proposedframework in Section 3 is applied to the weapon systempurchasing process an example of an inertial navigationsystem(INS) built in an unmanned aerial vehicle (UAV) It isnoted that owing to confidentiality issue the components ofmilitary UAV are not disclosed hence we use a general UAVinstead for illustration in the use-case An inertial navigationsystem is a navigation aid that uses a computer motionsensors (accelerometers) rotation sensors (gyroscopes) andoccasionally magnetic sensors (magnetometers) to continu-ously calculate by dead reckoning the position the orienta-tion and the velocity (direction and speed of movement) of amoving object without the need for external references TheINS is a critical part of computing data from sensors in UAVthus security is assured
(A) Defining Requirements with Risk Identification (SystemCategorization) As presented in [30] the risk of INS in UAVshould be evaluated by the parameter ie velocity attitude
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
4 Security and Communication Networks
AssessSecurity Controls
SystemCategorize①
②③
④
⑥⑤
ImplementSecurity Controls
CooperativeVulnerabilityIdentification
AuthorizeSystem
AdversarialCybersecurity
DTampE
MonitorSecurity Controls
UnderstandCybersecurityRequirements
CharacterizeCyber Attack
Surface
CooperativeVulnerabilityPenetrationAssessment
AdversarialAssessment
Security ControlsSelect
Requirement Design Implementation Test amp Evaluation Operation
MaterialSolutionAnalysis
TechnologyMaturation amp
Risk Reduction
Engineering ampManufacturingDevelopment
Production andDeployment
Operationamp
Support
System Security Engineering
SDLC
DefenseAcquisition
System
RMF
SSE
TampECybersecurity
Figure 2 Defense Acquisition System in the US for enhancing cybersecurity [22]
RFP Release
Proposal Assessment
Test amp Evaluation
Decision
requirements
Assessment ofrequirementssatisfaction
Decision
Requirements
Figure 3 General weapon system purchasing process
3 Proposed Security Evaluation Framework
31 Security Evaluation Framework In this chapter we pro-pose a new security evaluation framework that combinesRMF and Cybersecurity Test amp Evaluation in the existingweapons import process with cybersecurity internationalstandards The framework for improving cybersecurity isshown in Figure 4A sim F relate to eachRMF step in Figure 2and the blue boxes indicate the purchase process in Figure 3the red and green boxes represent RMF and CybersecurityTampE in Figure 2 respectively Also the indicators of italicizedalphabets for flow of steps are illustrated in detail below
(A) Defining Requirements with Risk Identification (SystemCategorization) At this stage the same method as the firststep in RMF [25 26] is used to identify the risks for theproduct (or system) to be acquired And the provisionalimpact value for each risk is calculated Provisional impactvalues are classified into three levels high moderate lowfor confidentiality integrity and availability By defining thecybersecurity requirements for the product to be acquiredwith reference to the impact value of the identified riskthe unnecessary cost can be reduced and accurate securityfunctions can be implemented These cybersecurity require-ments are then integrated with other functions operatingrequirements and then passed on to the next step
(B) Selecting Appropriate Security Controls from the Require-ments In this step we choose security controls as a counter-measure to achieve the cybersecurity requirements definedin step (A) To select security controls for the product to beimported we should review the security controls in the parentsystems first and determine if there are any security controlsthat could be inherit from the system Those are inherent inthe system should be tailored out from the product list ofsecurity controls and the remaining list would be the securitycontrolswe should implement At this point the security con-trol set made by the acquirer comes into effect The reason isto reduce time to select security controls and to remove miss-ing parts by using new sets of security controls that are notfamiliar with If there is no set of security controls availablefrom the acquirer they may skip this step and the providermay bring up a set of security controls or a set of internationalstandard security controls Once the security controls havebeen selected one can proceed to the next step following byreview
(C) Converting the Security Controls into the InternationalStandards The selected security controls are converted intointernational standard (ISOIEC 15408 ISOIEC27001) secu-rity controls at this stage The reason for this standardizationis that it is difficult for the provider to clearly understandthe security controls of the acquirer so the misunderstandingensued from such environmental differences can be reducedHowever the problem is to what extent the set of securitycontrols of the acquirer and the provider can be convertedand expressed under the set of international standard securitycontrols This will be covered in detail in Section 32 andbriefly the mapping table and definition of addition subjectsare provided in Appendix H [16]
Concurrently the part corresponding to the function ofproduct security is converted into the Security FunctionalRequirements (SFR) of ISOIEC 15408 and that of operationand environment is converted into ISO IEC 27001 Nonethe-less there are real cases where ISOIEC 15408 does not cover
Security and Communication Networks 5
Requirement
Requirements
SystemCategorize
Design
SelectSecurity Controls
for acquirer
RFP Document
InternationalStandards
Security Controls
Development
Provider
Test ampEvaluation Operation(SI)
SDLC
PurchaseProcess
RMF
ProposeFramework
SC based Criteria
CybersecurityTampE
Non-Functional Non-Functional
FunctionalFunctional
ExamineDocumentation
System Integration Riskacceptable
Test andEvaluation
purchase
RFPReview
RFP
Risk Assessment
RiskUnacceptable
Release
① ② ②
③
④⑤
④
④
Figure 4 Proposed security evaluation framework
all the conversions for product security function then ISO IEC 27001 is used for the conversion in such cases Usinginternational standard security controls in this construct wecan generate a set of security requirements similar to theProfile Protection used in the Common Criteria
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation It is a step for a comprehensiveassessment of those security controls functions and operat-ing requirements that has been converted into internationalstandards which reflect cyber security requirements Themain objective at this stage is to gather all stakeholders andcoordinate any conflicting interests in between in particularto adjust requirements that may be confined to fundingIf resource constraints and other issues do not reflect allrequirements they should be broken down into mandatoryrequirements and optional requirements on the foundation ofdistinguished risk and impact values identified in the first step[27] In other words risk-based decisions are made so thatrisks can be handled according to priorities Once everythingis done consistently it is followed by the announcement ofRFP (Request for Proposal)
While the provider is in the middle of RFP release andproposal preparation the acquirer constructs the evaluationlist by dividing the nonsecurity functional part and thesecurity functional part based on the cybersecurity require-ments in Figure 4 The rationale behind this is to insure theevaluation of security-related means and environments forrequired security functions and product development
(E) Evaluation of Submitted Proposals and PreverificationThe provider submits the proposal of the announced RFP
CharacterizeAttackSurface
IdentifyKnown
vulnerabilities
PenetrationTest
Figure 5 Security functional test flow
to the acquirer based on the international standard securitycontrols Since the security nonfunctional parts are difficult toverify directly it is advised to submit proposal results whichhas been verified by an authorized third party Despite thefact that the nonfunctional parts could be compromised bycertifications such as ISOIEC 27001 it is only possible whenthe scope of evaluation is identical The security functionalparts are the main components to be verified in the nextstep ldquoReal verificationrdquo nevertheless it should also engagein assessing whether the document evaluation comprisesthe functionality to confirm the satisfactory level of securityfunctions When examining the satisfactory level of securityfunctions (for the security functional parts of the documentevaluation) it is necessary to deploy advance preparation toshorten the evaluation time for ldquoReal verificationrdquo Advancepreparation refers to the identification of the attack surfaceand the identification of known vulnerabilities [28] whichembody the penetration test and Figure 5 is a detaileddescription of E1015840 in Figure 4
(F) Functional RequirementVerification Products that passeddocumentation undergo another test to gauge whether theycan function exactly as what have been stated in the proposalThe focus of the verification is not only to validate the
6 Security and Communication Networks
Table 2 Number of security controls that do not provide mapping table in NIST 800-53
Security Controls Total Not ProvidesAC Access Control 25 8AT Awareness and Training 5 1AU Audit and Accountability 12 4CA Security Assessment and Authorization 9 5CM Configuration Management 11 2CP Contingency Planning 13 1IA Identification and Authentication 11 4IR Incident Response 10 5MA Maintenance 6 3MP Media Protection 8 1PE Physical and Environmental Protection 20 2PL Planning 9 1PS Personnel Security 8 1RA Risk Assessment 6 1SA System and services Acquisition 22 8SC System and Communications Protection 44 31SI System and Information Integrity 16 11PM Program Management 9 5
LikelihoodDetermination
ImpactAnalysis
RiskDetermination
Figure 6 Risk assessment flow
described requirements but also to confirm if cybersecurityis implemented properly by carrying out known vulnerabili-ties check and penetration testThe actual evaluation is basedon a block-box test However if the acquirer is in agreementwith the provider on white-box testing the acquirer couldverify the product in detail In case of lack of time and costthis might be an optional step for acquirers to follow
(G) Risk Assessment The product is cleared if it has passedthrough all the evaluations at ldquoverificationrdquo stage productsthat fail to meet the requirements criterion are directed toundergo risk assessment The first risk assessment was a pro-visional impact value done under a proposed situationwhereas the risk assessment at this step will be revealed usingreal data inputThe risk assessment flow is shown in Figure 6and this procedure is applied in accordance with the proce-dure in [29]
At this stage an actual and reliable risk assessment isfeasible as outcome is collected from real data If the risk levelresult is acceptable acquirer can advance to the next step ifnot the parts would be taken as inappropriate and acquirermay consult with provider
(H) Secure System Integration and Operational Test andEvaluation Products that survived ldquoverificationrdquo ((F) (G)Step) are incorporated into the whole system and are finally
reevaluated After integrating into the system similar evalua-tion on functionality of a single product goes through exceptthat the reevaluation for the time being concentrates on theproduct operability The ldquoAssurancerdquo part that is designedto guarantee the function performance of the product isexcluded from this paper
32 Mapping Security Controls to ISOIEC 15408 and 27001The security controls of acquirer have to be revised toadapt to international standardized security requirementswith a purpose to guarantee a successful flow of Stage (C) inSection 31This section illustrates the amended internationalsecurity controls with the most concrete and detailed NIST800-53 According to the analyzing result from the conversiontable provided in Appendix H 73 out of 252 security controlsin 18 categories are not provided with mapping as securitycontrols of ISOIEC 15408 and 27001 [Table 2]
Those security controls without mapping are analyzedand converted into international standard security controlsof which the results are shown in Table 3
The conversion of security controls demands consider-able of technical controls in view of this it is recommendedto proceed conversion using ISOIEC 15408The definition ofthe class regarding ISOIEC 15408 Security FunctionalRequirements is listed in Table 4 Also security controlsthat are not related to weapons purchasing IR (IncidentResponse) AT (Awareness and Training) and PM (ProgramManagement) are removed from conversion of security con-trols
For example the IA-3 (Device Identification and Authen-tication) relates to the identification and authentication ofdevices connected to the information systemThis control canbe converted into the UAU (User Authentication) and UID
Security and Communication Networks 7
Table 3 Security controls that are converted on component and family level
NIST Security Controls ISOIEC15408 Common Criteria Componentor Family
AC-21 Information Sharing FPT TDC1AC-22 Publicly Accessible Content FPT TDC1AC-23 Data Mining Protection FTA LSA1AU-13 Monitoring for Information Disclosure FAU SAR1 FDP ETC1AU-16 Cross-Organizational Auditing FAU SAR1CM-2 Baseline Configuration EAL packageIA-3 Device Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-9 Service Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-10 Adaptive Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2MP-8 Media Downgrading ALC CMC ALC CMSPE-6 Monitoring Physical Access FPT PHP1 FPT PHP2 FPT PHP3PE-8 Visitor Access Records ALC DVSPS-2 Position Risk Designation FPT PHP1 FPT PHP2 FPT PHP3RA-6 Technical Surveillance Countermeasures Survey AVA VANSA-2 Allocation of Resources FRU RSASA-13 Trustworthiness EAL packageSA-16 Developer-Provided Training ALC DVSSA-20 Customized Development of Critical Components ALC CMC ALC CMSSC-2 Application Partitioning FIA ATD1SC-18 Mobile Code FMT MSA1 FMT MSA2SC-19 Voice Over Internet Protocol FMT MSA1 FMT MSA2SC-20 Secure NameAddress Resolution Service (Authoritative Source) FMT MSA1 FMT MSA2SC-21 Secure NameAddress Resolution Service (Recursive or Caching Resolver) FMT MSA1 FMT MSA2SC-22 Architecture and Provisioning for NameAddress Resolution Service FMT MSA1 FMT MSA2SC-29 Heterogeneity FDP IFFSC-32 Information System Partitioning ADV ARCSC-37 Out-of-Band Channels FPT PHP1 FPT PHP2 FPT PHP3SC-39 Process Isolation ADV ARCSC-42 Sensor Capability and Data FDP ETC1 FDP ETC2SC-43 Usage Restrictions FDP IFF3
SI-8 Spam Protection FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-11 Error Handling FDP ACC1 FDP ACC2 FIA AFL1
SI-15 Information Output Filtering FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-16 Memory Protection ADV ARCSI-17 Fail-Safe Procedures FPT RCV ADV ARC
(User Identification) families in Functional Identification andAuthentication (FIA) class The selected components areshown in Table 5
The reason is that the FIA UID and FIA UAU familiesare related to user authentication and identification but canalso be described equivalently under the condition that theuser of the CC is conceived as the same subject as the devicein the NIST security controls However as shown in Table 6security controls of some specific technologies that are not
directly converted to the component or family unit can bemapped at the class level and organizational security policypursued by illustration
33 Comparison Analysis Different from other evaluationframeworks our proposed framework is intended for theintegration of imported systems It is set up based onRMF and Cybersecurity TampE of which their properties areinherited However as shown in Table 2 RMF does not carry
8 Security and Communication Networks
Table 4 Families of security functional requirements in ISOIEC15408
Family DescriptionFAU Security AuditFCO CommunicationFCS Cryptographic SupportFDP User Data ProtectionFIA Identification and AuthenticationFMT Security ManagementFPR PrivacyFPT Protection of the TSFFRU Resource utilizationFTA TOE accessFTP Trusted pathchannels
Table 5 Example of security control conversion into CC component
Components Description
FIA UAU1 Timing of authentication allows a user to perform certain actionsprior to the authentication of the userrsquos identity
FIA UAU2 User authentication before any action requires that users authenticatethemselves before any action will be allowed by the TSF
FIA UID1 Timing of identification allows users to perform certain actionsbefore being identified by the TSF
FIA UID1 User identification before any action require that users identifythemselves before any action will be allowed by the TSF
Table 6 Security controls that are converted on class level
NIST Security Controls ISOIEC15408Family
SA-22 Unsupported SystemComponents FMT
SC-25 Thin Nodes FRUSC-26 Honeypots FDP
SC-27 Platform-IndependentApplications FDP FIA
SC-30 Concealment andMisdirection FDP
SC-34 Non-ModifiableExecutable Programs FMT
SC-35 Honey clients FDP
SC-36 Distributed Processingand Storage FMT
SC-40 Wireless Link Protection FIA FPT FTAFTP
SC-44 Detonation Chambers FDPSI-14 Non-Persistence FDP
all the mapping tables required for international standardtherefore we propose an addition conversion method inSection 32 Table 7 is the comparison table of our frameworkwith RMF Cybersecurity TampE and CC-based approaches
4 Use-Case Adoption ofthe Inertial Navigation System Import forUnmanned Aerial Vehicle
A formal evaluation upon our framework would be an idealproof of frameworkrsquos novelty The framework we proposedhowever would be difficult to be proved formally as suchevaluation is out of scope of this proposal In lieu of a formalproof we demonstrate use-case to explain how our proposedframework in Section 3 is applied to the weapon systempurchasing process an example of an inertial navigationsystem(INS) built in an unmanned aerial vehicle (UAV) It isnoted that owing to confidentiality issue the components ofmilitary UAV are not disclosed hence we use a general UAVinstead for illustration in the use-case An inertial navigationsystem is a navigation aid that uses a computer motionsensors (accelerometers) rotation sensors (gyroscopes) andoccasionally magnetic sensors (magnetometers) to continu-ously calculate by dead reckoning the position the orienta-tion and the velocity (direction and speed of movement) of amoving object without the need for external references TheINS is a critical part of computing data from sensors in UAVthus security is assured
(A) Defining Requirements with Risk Identification (SystemCategorization) As presented in [30] the risk of INS in UAVshould be evaluated by the parameter ie velocity attitude
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
Security and Communication Networks 5
Requirement
Requirements
SystemCategorize
Design
SelectSecurity Controls
for acquirer
RFP Document
InternationalStandards
Security Controls
Development
Provider
Test ampEvaluation Operation(SI)
SDLC
PurchaseProcess
RMF
ProposeFramework
SC based Criteria
CybersecurityTampE
Non-Functional Non-Functional
FunctionalFunctional
ExamineDocumentation
System Integration Riskacceptable
Test andEvaluation
purchase
RFPReview
RFP
Risk Assessment
RiskUnacceptable
Release
① ② ②
③
④⑤
④
④
Figure 4 Proposed security evaluation framework
all the conversions for product security function then ISO IEC 27001 is used for the conversion in such cases Usinginternational standard security controls in this construct wecan generate a set of security requirements similar to theProfile Protection used in the Common Criteria
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation It is a step for a comprehensiveassessment of those security controls functions and operat-ing requirements that has been converted into internationalstandards which reflect cyber security requirements Themain objective at this stage is to gather all stakeholders andcoordinate any conflicting interests in between in particularto adjust requirements that may be confined to fundingIf resource constraints and other issues do not reflect allrequirements they should be broken down into mandatoryrequirements and optional requirements on the foundation ofdistinguished risk and impact values identified in the first step[27] In other words risk-based decisions are made so thatrisks can be handled according to priorities Once everythingis done consistently it is followed by the announcement ofRFP (Request for Proposal)
While the provider is in the middle of RFP release andproposal preparation the acquirer constructs the evaluationlist by dividing the nonsecurity functional part and thesecurity functional part based on the cybersecurity require-ments in Figure 4 The rationale behind this is to insure theevaluation of security-related means and environments forrequired security functions and product development
(E) Evaluation of Submitted Proposals and PreverificationThe provider submits the proposal of the announced RFP
CharacterizeAttackSurface
IdentifyKnown
vulnerabilities
PenetrationTest
Figure 5 Security functional test flow
to the acquirer based on the international standard securitycontrols Since the security nonfunctional parts are difficult toverify directly it is advised to submit proposal results whichhas been verified by an authorized third party Despite thefact that the nonfunctional parts could be compromised bycertifications such as ISOIEC 27001 it is only possible whenthe scope of evaluation is identical The security functionalparts are the main components to be verified in the nextstep ldquoReal verificationrdquo nevertheless it should also engagein assessing whether the document evaluation comprisesthe functionality to confirm the satisfactory level of securityfunctions When examining the satisfactory level of securityfunctions (for the security functional parts of the documentevaluation) it is necessary to deploy advance preparation toshorten the evaluation time for ldquoReal verificationrdquo Advancepreparation refers to the identification of the attack surfaceand the identification of known vulnerabilities [28] whichembody the penetration test and Figure 5 is a detaileddescription of E1015840 in Figure 4
(F) Functional RequirementVerification Products that passeddocumentation undergo another test to gauge whether theycan function exactly as what have been stated in the proposalThe focus of the verification is not only to validate the
6 Security and Communication Networks
Table 2 Number of security controls that do not provide mapping table in NIST 800-53
Security Controls Total Not ProvidesAC Access Control 25 8AT Awareness and Training 5 1AU Audit and Accountability 12 4CA Security Assessment and Authorization 9 5CM Configuration Management 11 2CP Contingency Planning 13 1IA Identification and Authentication 11 4IR Incident Response 10 5MA Maintenance 6 3MP Media Protection 8 1PE Physical and Environmental Protection 20 2PL Planning 9 1PS Personnel Security 8 1RA Risk Assessment 6 1SA System and services Acquisition 22 8SC System and Communications Protection 44 31SI System and Information Integrity 16 11PM Program Management 9 5
LikelihoodDetermination
ImpactAnalysis
RiskDetermination
Figure 6 Risk assessment flow
described requirements but also to confirm if cybersecurityis implemented properly by carrying out known vulnerabili-ties check and penetration testThe actual evaluation is basedon a block-box test However if the acquirer is in agreementwith the provider on white-box testing the acquirer couldverify the product in detail In case of lack of time and costthis might be an optional step for acquirers to follow
(G) Risk Assessment The product is cleared if it has passedthrough all the evaluations at ldquoverificationrdquo stage productsthat fail to meet the requirements criterion are directed toundergo risk assessment The first risk assessment was a pro-visional impact value done under a proposed situationwhereas the risk assessment at this step will be revealed usingreal data inputThe risk assessment flow is shown in Figure 6and this procedure is applied in accordance with the proce-dure in [29]
At this stage an actual and reliable risk assessment isfeasible as outcome is collected from real data If the risk levelresult is acceptable acquirer can advance to the next step ifnot the parts would be taken as inappropriate and acquirermay consult with provider
(H) Secure System Integration and Operational Test andEvaluation Products that survived ldquoverificationrdquo ((F) (G)Step) are incorporated into the whole system and are finally
reevaluated After integrating into the system similar evalua-tion on functionality of a single product goes through exceptthat the reevaluation for the time being concentrates on theproduct operability The ldquoAssurancerdquo part that is designedto guarantee the function performance of the product isexcluded from this paper
32 Mapping Security Controls to ISOIEC 15408 and 27001The security controls of acquirer have to be revised toadapt to international standardized security requirementswith a purpose to guarantee a successful flow of Stage (C) inSection 31This section illustrates the amended internationalsecurity controls with the most concrete and detailed NIST800-53 According to the analyzing result from the conversiontable provided in Appendix H 73 out of 252 security controlsin 18 categories are not provided with mapping as securitycontrols of ISOIEC 15408 and 27001 [Table 2]
Those security controls without mapping are analyzedand converted into international standard security controlsof which the results are shown in Table 3
The conversion of security controls demands consider-able of technical controls in view of this it is recommendedto proceed conversion using ISOIEC 15408The definition ofthe class regarding ISOIEC 15408 Security FunctionalRequirements is listed in Table 4 Also security controlsthat are not related to weapons purchasing IR (IncidentResponse) AT (Awareness and Training) and PM (ProgramManagement) are removed from conversion of security con-trols
For example the IA-3 (Device Identification and Authen-tication) relates to the identification and authentication ofdevices connected to the information systemThis control canbe converted into the UAU (User Authentication) and UID
Security and Communication Networks 7
Table 3 Security controls that are converted on component and family level
NIST Security Controls ISOIEC15408 Common Criteria Componentor Family
AC-21 Information Sharing FPT TDC1AC-22 Publicly Accessible Content FPT TDC1AC-23 Data Mining Protection FTA LSA1AU-13 Monitoring for Information Disclosure FAU SAR1 FDP ETC1AU-16 Cross-Organizational Auditing FAU SAR1CM-2 Baseline Configuration EAL packageIA-3 Device Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-9 Service Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-10 Adaptive Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2MP-8 Media Downgrading ALC CMC ALC CMSPE-6 Monitoring Physical Access FPT PHP1 FPT PHP2 FPT PHP3PE-8 Visitor Access Records ALC DVSPS-2 Position Risk Designation FPT PHP1 FPT PHP2 FPT PHP3RA-6 Technical Surveillance Countermeasures Survey AVA VANSA-2 Allocation of Resources FRU RSASA-13 Trustworthiness EAL packageSA-16 Developer-Provided Training ALC DVSSA-20 Customized Development of Critical Components ALC CMC ALC CMSSC-2 Application Partitioning FIA ATD1SC-18 Mobile Code FMT MSA1 FMT MSA2SC-19 Voice Over Internet Protocol FMT MSA1 FMT MSA2SC-20 Secure NameAddress Resolution Service (Authoritative Source) FMT MSA1 FMT MSA2SC-21 Secure NameAddress Resolution Service (Recursive or Caching Resolver) FMT MSA1 FMT MSA2SC-22 Architecture and Provisioning for NameAddress Resolution Service FMT MSA1 FMT MSA2SC-29 Heterogeneity FDP IFFSC-32 Information System Partitioning ADV ARCSC-37 Out-of-Band Channels FPT PHP1 FPT PHP2 FPT PHP3SC-39 Process Isolation ADV ARCSC-42 Sensor Capability and Data FDP ETC1 FDP ETC2SC-43 Usage Restrictions FDP IFF3
SI-8 Spam Protection FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-11 Error Handling FDP ACC1 FDP ACC2 FIA AFL1
SI-15 Information Output Filtering FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-16 Memory Protection ADV ARCSI-17 Fail-Safe Procedures FPT RCV ADV ARC
(User Identification) families in Functional Identification andAuthentication (FIA) class The selected components areshown in Table 5
The reason is that the FIA UID and FIA UAU familiesare related to user authentication and identification but canalso be described equivalently under the condition that theuser of the CC is conceived as the same subject as the devicein the NIST security controls However as shown in Table 6security controls of some specific technologies that are not
directly converted to the component or family unit can bemapped at the class level and organizational security policypursued by illustration
33 Comparison Analysis Different from other evaluationframeworks our proposed framework is intended for theintegration of imported systems It is set up based onRMF and Cybersecurity TampE of which their properties areinherited However as shown in Table 2 RMF does not carry
8 Security and Communication Networks
Table 4 Families of security functional requirements in ISOIEC15408
Family DescriptionFAU Security AuditFCO CommunicationFCS Cryptographic SupportFDP User Data ProtectionFIA Identification and AuthenticationFMT Security ManagementFPR PrivacyFPT Protection of the TSFFRU Resource utilizationFTA TOE accessFTP Trusted pathchannels
Table 5 Example of security control conversion into CC component
Components Description
FIA UAU1 Timing of authentication allows a user to perform certain actionsprior to the authentication of the userrsquos identity
FIA UAU2 User authentication before any action requires that users authenticatethemselves before any action will be allowed by the TSF
FIA UID1 Timing of identification allows users to perform certain actionsbefore being identified by the TSF
FIA UID1 User identification before any action require that users identifythemselves before any action will be allowed by the TSF
Table 6 Security controls that are converted on class level
NIST Security Controls ISOIEC15408Family
SA-22 Unsupported SystemComponents FMT
SC-25 Thin Nodes FRUSC-26 Honeypots FDP
SC-27 Platform-IndependentApplications FDP FIA
SC-30 Concealment andMisdirection FDP
SC-34 Non-ModifiableExecutable Programs FMT
SC-35 Honey clients FDP
SC-36 Distributed Processingand Storage FMT
SC-40 Wireless Link Protection FIA FPT FTAFTP
SC-44 Detonation Chambers FDPSI-14 Non-Persistence FDP
all the mapping tables required for international standardtherefore we propose an addition conversion method inSection 32 Table 7 is the comparison table of our frameworkwith RMF Cybersecurity TampE and CC-based approaches
4 Use-Case Adoption ofthe Inertial Navigation System Import forUnmanned Aerial Vehicle
A formal evaluation upon our framework would be an idealproof of frameworkrsquos novelty The framework we proposedhowever would be difficult to be proved formally as suchevaluation is out of scope of this proposal In lieu of a formalproof we demonstrate use-case to explain how our proposedframework in Section 3 is applied to the weapon systempurchasing process an example of an inertial navigationsystem(INS) built in an unmanned aerial vehicle (UAV) It isnoted that owing to confidentiality issue the components ofmilitary UAV are not disclosed hence we use a general UAVinstead for illustration in the use-case An inertial navigationsystem is a navigation aid that uses a computer motionsensors (accelerometers) rotation sensors (gyroscopes) andoccasionally magnetic sensors (magnetometers) to continu-ously calculate by dead reckoning the position the orienta-tion and the velocity (direction and speed of movement) of amoving object without the need for external references TheINS is a critical part of computing data from sensors in UAVthus security is assured
(A) Defining Requirements with Risk Identification (SystemCategorization) As presented in [30] the risk of INS in UAVshould be evaluated by the parameter ie velocity attitude
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
6 Security and Communication Networks
Table 2 Number of security controls that do not provide mapping table in NIST 800-53
Security Controls Total Not ProvidesAC Access Control 25 8AT Awareness and Training 5 1AU Audit and Accountability 12 4CA Security Assessment and Authorization 9 5CM Configuration Management 11 2CP Contingency Planning 13 1IA Identification and Authentication 11 4IR Incident Response 10 5MA Maintenance 6 3MP Media Protection 8 1PE Physical and Environmental Protection 20 2PL Planning 9 1PS Personnel Security 8 1RA Risk Assessment 6 1SA System and services Acquisition 22 8SC System and Communications Protection 44 31SI System and Information Integrity 16 11PM Program Management 9 5
LikelihoodDetermination
ImpactAnalysis
RiskDetermination
Figure 6 Risk assessment flow
described requirements but also to confirm if cybersecurityis implemented properly by carrying out known vulnerabili-ties check and penetration testThe actual evaluation is basedon a block-box test However if the acquirer is in agreementwith the provider on white-box testing the acquirer couldverify the product in detail In case of lack of time and costthis might be an optional step for acquirers to follow
(G) Risk Assessment The product is cleared if it has passedthrough all the evaluations at ldquoverificationrdquo stage productsthat fail to meet the requirements criterion are directed toundergo risk assessment The first risk assessment was a pro-visional impact value done under a proposed situationwhereas the risk assessment at this step will be revealed usingreal data inputThe risk assessment flow is shown in Figure 6and this procedure is applied in accordance with the proce-dure in [29]
At this stage an actual and reliable risk assessment isfeasible as outcome is collected from real data If the risk levelresult is acceptable acquirer can advance to the next step ifnot the parts would be taken as inappropriate and acquirermay consult with provider
(H) Secure System Integration and Operational Test andEvaluation Products that survived ldquoverificationrdquo ((F) (G)Step) are incorporated into the whole system and are finally
reevaluated After integrating into the system similar evalua-tion on functionality of a single product goes through exceptthat the reevaluation for the time being concentrates on theproduct operability The ldquoAssurancerdquo part that is designedto guarantee the function performance of the product isexcluded from this paper
32 Mapping Security Controls to ISOIEC 15408 and 27001The security controls of acquirer have to be revised toadapt to international standardized security requirementswith a purpose to guarantee a successful flow of Stage (C) inSection 31This section illustrates the amended internationalsecurity controls with the most concrete and detailed NIST800-53 According to the analyzing result from the conversiontable provided in Appendix H 73 out of 252 security controlsin 18 categories are not provided with mapping as securitycontrols of ISOIEC 15408 and 27001 [Table 2]
Those security controls without mapping are analyzedand converted into international standard security controlsof which the results are shown in Table 3
The conversion of security controls demands consider-able of technical controls in view of this it is recommendedto proceed conversion using ISOIEC 15408The definition ofthe class regarding ISOIEC 15408 Security FunctionalRequirements is listed in Table 4 Also security controlsthat are not related to weapons purchasing IR (IncidentResponse) AT (Awareness and Training) and PM (ProgramManagement) are removed from conversion of security con-trols
For example the IA-3 (Device Identification and Authen-tication) relates to the identification and authentication ofdevices connected to the information systemThis control canbe converted into the UAU (User Authentication) and UID
Security and Communication Networks 7
Table 3 Security controls that are converted on component and family level
NIST Security Controls ISOIEC15408 Common Criteria Componentor Family
AC-21 Information Sharing FPT TDC1AC-22 Publicly Accessible Content FPT TDC1AC-23 Data Mining Protection FTA LSA1AU-13 Monitoring for Information Disclosure FAU SAR1 FDP ETC1AU-16 Cross-Organizational Auditing FAU SAR1CM-2 Baseline Configuration EAL packageIA-3 Device Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-9 Service Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-10 Adaptive Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2MP-8 Media Downgrading ALC CMC ALC CMSPE-6 Monitoring Physical Access FPT PHP1 FPT PHP2 FPT PHP3PE-8 Visitor Access Records ALC DVSPS-2 Position Risk Designation FPT PHP1 FPT PHP2 FPT PHP3RA-6 Technical Surveillance Countermeasures Survey AVA VANSA-2 Allocation of Resources FRU RSASA-13 Trustworthiness EAL packageSA-16 Developer-Provided Training ALC DVSSA-20 Customized Development of Critical Components ALC CMC ALC CMSSC-2 Application Partitioning FIA ATD1SC-18 Mobile Code FMT MSA1 FMT MSA2SC-19 Voice Over Internet Protocol FMT MSA1 FMT MSA2SC-20 Secure NameAddress Resolution Service (Authoritative Source) FMT MSA1 FMT MSA2SC-21 Secure NameAddress Resolution Service (Recursive or Caching Resolver) FMT MSA1 FMT MSA2SC-22 Architecture and Provisioning for NameAddress Resolution Service FMT MSA1 FMT MSA2SC-29 Heterogeneity FDP IFFSC-32 Information System Partitioning ADV ARCSC-37 Out-of-Band Channels FPT PHP1 FPT PHP2 FPT PHP3SC-39 Process Isolation ADV ARCSC-42 Sensor Capability and Data FDP ETC1 FDP ETC2SC-43 Usage Restrictions FDP IFF3
SI-8 Spam Protection FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-11 Error Handling FDP ACC1 FDP ACC2 FIA AFL1
SI-15 Information Output Filtering FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-16 Memory Protection ADV ARCSI-17 Fail-Safe Procedures FPT RCV ADV ARC
(User Identification) families in Functional Identification andAuthentication (FIA) class The selected components areshown in Table 5
The reason is that the FIA UID and FIA UAU familiesare related to user authentication and identification but canalso be described equivalently under the condition that theuser of the CC is conceived as the same subject as the devicein the NIST security controls However as shown in Table 6security controls of some specific technologies that are not
directly converted to the component or family unit can bemapped at the class level and organizational security policypursued by illustration
33 Comparison Analysis Different from other evaluationframeworks our proposed framework is intended for theintegration of imported systems It is set up based onRMF and Cybersecurity TampE of which their properties areinherited However as shown in Table 2 RMF does not carry
8 Security and Communication Networks
Table 4 Families of security functional requirements in ISOIEC15408
Family DescriptionFAU Security AuditFCO CommunicationFCS Cryptographic SupportFDP User Data ProtectionFIA Identification and AuthenticationFMT Security ManagementFPR PrivacyFPT Protection of the TSFFRU Resource utilizationFTA TOE accessFTP Trusted pathchannels
Table 5 Example of security control conversion into CC component
Components Description
FIA UAU1 Timing of authentication allows a user to perform certain actionsprior to the authentication of the userrsquos identity
FIA UAU2 User authentication before any action requires that users authenticatethemselves before any action will be allowed by the TSF
FIA UID1 Timing of identification allows users to perform certain actionsbefore being identified by the TSF
FIA UID1 User identification before any action require that users identifythemselves before any action will be allowed by the TSF
Table 6 Security controls that are converted on class level
NIST Security Controls ISOIEC15408Family
SA-22 Unsupported SystemComponents FMT
SC-25 Thin Nodes FRUSC-26 Honeypots FDP
SC-27 Platform-IndependentApplications FDP FIA
SC-30 Concealment andMisdirection FDP
SC-34 Non-ModifiableExecutable Programs FMT
SC-35 Honey clients FDP
SC-36 Distributed Processingand Storage FMT
SC-40 Wireless Link Protection FIA FPT FTAFTP
SC-44 Detonation Chambers FDPSI-14 Non-Persistence FDP
all the mapping tables required for international standardtherefore we propose an addition conversion method inSection 32 Table 7 is the comparison table of our frameworkwith RMF Cybersecurity TampE and CC-based approaches
4 Use-Case Adoption ofthe Inertial Navigation System Import forUnmanned Aerial Vehicle
A formal evaluation upon our framework would be an idealproof of frameworkrsquos novelty The framework we proposedhowever would be difficult to be proved formally as suchevaluation is out of scope of this proposal In lieu of a formalproof we demonstrate use-case to explain how our proposedframework in Section 3 is applied to the weapon systempurchasing process an example of an inertial navigationsystem(INS) built in an unmanned aerial vehicle (UAV) It isnoted that owing to confidentiality issue the components ofmilitary UAV are not disclosed hence we use a general UAVinstead for illustration in the use-case An inertial navigationsystem is a navigation aid that uses a computer motionsensors (accelerometers) rotation sensors (gyroscopes) andoccasionally magnetic sensors (magnetometers) to continu-ously calculate by dead reckoning the position the orienta-tion and the velocity (direction and speed of movement) of amoving object without the need for external references TheINS is a critical part of computing data from sensors in UAVthus security is assured
(A) Defining Requirements with Risk Identification (SystemCategorization) As presented in [30] the risk of INS in UAVshould be evaluated by the parameter ie velocity attitude
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
Security and Communication Networks 7
Table 3 Security controls that are converted on component and family level
NIST Security Controls ISOIEC15408 Common Criteria Componentor Family
AC-21 Information Sharing FPT TDC1AC-22 Publicly Accessible Content FPT TDC1AC-23 Data Mining Protection FTA LSA1AU-13 Monitoring for Information Disclosure FAU SAR1 FDP ETC1AU-16 Cross-Organizational Auditing FAU SAR1CM-2 Baseline Configuration EAL packageIA-3 Device Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-9 Service Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2IA-10 Adaptive Identification and Authentication FIA UAU1 FIA UAU2 FIA UAU1 FIA UAU2MP-8 Media Downgrading ALC CMC ALC CMSPE-6 Monitoring Physical Access FPT PHP1 FPT PHP2 FPT PHP3PE-8 Visitor Access Records ALC DVSPS-2 Position Risk Designation FPT PHP1 FPT PHP2 FPT PHP3RA-6 Technical Surveillance Countermeasures Survey AVA VANSA-2 Allocation of Resources FRU RSASA-13 Trustworthiness EAL packageSA-16 Developer-Provided Training ALC DVSSA-20 Customized Development of Critical Components ALC CMC ALC CMSSC-2 Application Partitioning FIA ATD1SC-18 Mobile Code FMT MSA1 FMT MSA2SC-19 Voice Over Internet Protocol FMT MSA1 FMT MSA2SC-20 Secure NameAddress Resolution Service (Authoritative Source) FMT MSA1 FMT MSA2SC-21 Secure NameAddress Resolution Service (Recursive or Caching Resolver) FMT MSA1 FMT MSA2SC-22 Architecture and Provisioning for NameAddress Resolution Service FMT MSA1 FMT MSA2SC-29 Heterogeneity FDP IFFSC-32 Information System Partitioning ADV ARCSC-37 Out-of-Band Channels FPT PHP1 FPT PHP2 FPT PHP3SC-39 Process Isolation ADV ARCSC-42 Sensor Capability and Data FDP ETC1 FDP ETC2SC-43 Usage Restrictions FDP IFF3
SI-8 Spam Protection FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-11 Error Handling FDP ACC1 FDP ACC2 FIA AFL1
SI-15 Information Output Filtering FDP ACC1 FDP ACC2FDP IFC1FDP IFC2
SI-16 Memory Protection ADV ARCSI-17 Fail-Safe Procedures FPT RCV ADV ARC
(User Identification) families in Functional Identification andAuthentication (FIA) class The selected components areshown in Table 5
The reason is that the FIA UID and FIA UAU familiesare related to user authentication and identification but canalso be described equivalently under the condition that theuser of the CC is conceived as the same subject as the devicein the NIST security controls However as shown in Table 6security controls of some specific technologies that are not
directly converted to the component or family unit can bemapped at the class level and organizational security policypursued by illustration
33 Comparison Analysis Different from other evaluationframeworks our proposed framework is intended for theintegration of imported systems It is set up based onRMF and Cybersecurity TampE of which their properties areinherited However as shown in Table 2 RMF does not carry
8 Security and Communication Networks
Table 4 Families of security functional requirements in ISOIEC15408
Family DescriptionFAU Security AuditFCO CommunicationFCS Cryptographic SupportFDP User Data ProtectionFIA Identification and AuthenticationFMT Security ManagementFPR PrivacyFPT Protection of the TSFFRU Resource utilizationFTA TOE accessFTP Trusted pathchannels
Table 5 Example of security control conversion into CC component
Components Description
FIA UAU1 Timing of authentication allows a user to perform certain actionsprior to the authentication of the userrsquos identity
FIA UAU2 User authentication before any action requires that users authenticatethemselves before any action will be allowed by the TSF
FIA UID1 Timing of identification allows users to perform certain actionsbefore being identified by the TSF
FIA UID1 User identification before any action require that users identifythemselves before any action will be allowed by the TSF
Table 6 Security controls that are converted on class level
NIST Security Controls ISOIEC15408Family
SA-22 Unsupported SystemComponents FMT
SC-25 Thin Nodes FRUSC-26 Honeypots FDP
SC-27 Platform-IndependentApplications FDP FIA
SC-30 Concealment andMisdirection FDP
SC-34 Non-ModifiableExecutable Programs FMT
SC-35 Honey clients FDP
SC-36 Distributed Processingand Storage FMT
SC-40 Wireless Link Protection FIA FPT FTAFTP
SC-44 Detonation Chambers FDPSI-14 Non-Persistence FDP
all the mapping tables required for international standardtherefore we propose an addition conversion method inSection 32 Table 7 is the comparison table of our frameworkwith RMF Cybersecurity TampE and CC-based approaches
4 Use-Case Adoption ofthe Inertial Navigation System Import forUnmanned Aerial Vehicle
A formal evaluation upon our framework would be an idealproof of frameworkrsquos novelty The framework we proposedhowever would be difficult to be proved formally as suchevaluation is out of scope of this proposal In lieu of a formalproof we demonstrate use-case to explain how our proposedframework in Section 3 is applied to the weapon systempurchasing process an example of an inertial navigationsystem(INS) built in an unmanned aerial vehicle (UAV) It isnoted that owing to confidentiality issue the components ofmilitary UAV are not disclosed hence we use a general UAVinstead for illustration in the use-case An inertial navigationsystem is a navigation aid that uses a computer motionsensors (accelerometers) rotation sensors (gyroscopes) andoccasionally magnetic sensors (magnetometers) to continu-ously calculate by dead reckoning the position the orienta-tion and the velocity (direction and speed of movement) of amoving object without the need for external references TheINS is a critical part of computing data from sensors in UAVthus security is assured
(A) Defining Requirements with Risk Identification (SystemCategorization) As presented in [30] the risk of INS in UAVshould be evaluated by the parameter ie velocity attitude
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
8 Security and Communication Networks
Table 4 Families of security functional requirements in ISOIEC15408
Family DescriptionFAU Security AuditFCO CommunicationFCS Cryptographic SupportFDP User Data ProtectionFIA Identification and AuthenticationFMT Security ManagementFPR PrivacyFPT Protection of the TSFFRU Resource utilizationFTA TOE accessFTP Trusted pathchannels
Table 5 Example of security control conversion into CC component
Components Description
FIA UAU1 Timing of authentication allows a user to perform certain actionsprior to the authentication of the userrsquos identity
FIA UAU2 User authentication before any action requires that users authenticatethemselves before any action will be allowed by the TSF
FIA UID1 Timing of identification allows users to perform certain actionsbefore being identified by the TSF
FIA UID1 User identification before any action require that users identifythemselves before any action will be allowed by the TSF
Table 6 Security controls that are converted on class level
NIST Security Controls ISOIEC15408Family
SA-22 Unsupported SystemComponents FMT
SC-25 Thin Nodes FRUSC-26 Honeypots FDP
SC-27 Platform-IndependentApplications FDP FIA
SC-30 Concealment andMisdirection FDP
SC-34 Non-ModifiableExecutable Programs FMT
SC-35 Honey clients FDP
SC-36 Distributed Processingand Storage FMT
SC-40 Wireless Link Protection FIA FPT FTAFTP
SC-44 Detonation Chambers FDPSI-14 Non-Persistence FDP
all the mapping tables required for international standardtherefore we propose an addition conversion method inSection 32 Table 7 is the comparison table of our frameworkwith RMF Cybersecurity TampE and CC-based approaches
4 Use-Case Adoption ofthe Inertial Navigation System Import forUnmanned Aerial Vehicle
A formal evaluation upon our framework would be an idealproof of frameworkrsquos novelty The framework we proposedhowever would be difficult to be proved formally as suchevaluation is out of scope of this proposal In lieu of a formalproof we demonstrate use-case to explain how our proposedframework in Section 3 is applied to the weapon systempurchasing process an example of an inertial navigationsystem(INS) built in an unmanned aerial vehicle (UAV) It isnoted that owing to confidentiality issue the components ofmilitary UAV are not disclosed hence we use a general UAVinstead for illustration in the use-case An inertial navigationsystem is a navigation aid that uses a computer motionsensors (accelerometers) rotation sensors (gyroscopes) andoccasionally magnetic sensors (magnetometers) to continu-ously calculate by dead reckoning the position the orienta-tion and the velocity (direction and speed of movement) of amoving object without the need for external references TheINS is a critical part of computing data from sensors in UAVthus security is assured
(A) Defining Requirements with Risk Identification (SystemCategorization) As presented in [30] the risk of INS in UAVshould be evaluated by the parameter ie velocity attitude
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
Security and Communication Networks 9
Table 7 Comparison with other approaches
Our framework RMF Cybersecurity TampE CC based approaches
Purpose Integrated into armsimport process
Integrated intoacquisition system
Eliminatevulnerabilities
Security evaluation ofinformation products
For internationaluse I X I
Functional test I I I IOperational test I I I XRisk management I I X X
Table 8 Example of system categorization of INS
Elements Confidentiality Integrity AvailabilityProvisional Impact Value
Velocity M H HAttitude M H HHorizontal position M H HDepth M H HTotal M H H
horizontal position and depth which factor out the systemcategorization When the confidentiality of the parametersdoes not impact much on duty the system is graded as lowwhen the values of parameters are vague and calculation ofposition becomes infeasible availability is classified as highand integrity is marked as high too where inaccurate valuesdeter an anticipation of position Table 8 shows the risk eva-luation result of INS
(B) Selecting Appropriate Security Controls from the Require-ments Based on the result from Stage (A) the securitycontrol of INS brings the focus on the assurance of integrityand availability The security controls of INS are comparedwith that of UAV for analysis to derive the necessary securitycontrols of INS for later integration The security controlsinherent in UAV should then be excluded from the INS secu-rity control list Since INS is a part of UAV physical and envi-ronmental security controls against direct approach and acci-dent could be inherited from UAV together with the securitycontrols of management and operation security Table 9 listsout the potentially inheritable security controls from UAV
After tailoring out these inheritable security controls theremaining INS security controls are concluded in Table 10
AC-17 18 are chosen because they carry Ethernet port IA-2 is used for the identification of user and authentication ofdevice to notify UAV of the identity of INS IA-3 is to verifythe authenticity of signal if it comes from INS After selectingthe proper security controls acquirer should proceed to thenext step
(C) Converting the Security Controls into the InternationalStandards We convert selected elements in the securitycontrol into the international standards with Table 2 and [25]Table 11 shows that result of converting security controls tointernational standards
(D) Completion of RFP Evaluation Criteria and Preparationfor Proposal Evaluation We review the result of conversionwhether it is reasonable If due to certain reason the chosensecurity control is found inapplicable amid the evaluationprocess its property should be further distinguished fromcompulsory to optional For example in the manner whereIA-3 cannot be enacted unless it executes along with GPS(Global Positioning System) it is considered as an optionalsecurity control whereas IA-3 becomes compulsory when itis to be implemented in the absence of assistive device Thenwe prepare security evaluation in cases of function elementsand nonfunction elements
(E) Evaluation of Submitted Proposals and Preverification Ifthe security evaluation is ready acquirer verifies documentsfrom provider whether the documents meet the criteria ofthe security evaluation on the international standards Thenwe prepare the functional test by using open vulnerabilitieson Common Vulnerabilities Exposures (CVE) and CommonWeakness Enumeration (CWE) in order to save evaluationtime For instance because Ethernet is adhered to INS poten-tial attacks arising from Ethernet are predictable and henceEthernet contributes to one part of the attack surface in thisregard Table 12 shows some of the common vulnerabilitiesfound on Ethernet and given the fact that time is limitedin most cases acquirer should opt for the most likely andinfluential ones In situations where provider has alreadyattained the approved ISOIEC 15408 or ISOIEC 27001 it isat acquirerrsquos discretion to adopt the system as embedded ornot
(F) Functional Requirement Verification This part is highlyreliant on external factors such as the test time and budgetgiven Because of the adequate availability of papers in therespect of test method we will not discuss in detail here
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
10 Security and Communication Networks
Table 9 Example of potentially inheritable security controls from UAV and above
SC Description SC DescriptionAC-1 Access Control Policy and Procedures PE-9 Power Equipment and Cabling
AC-2 Account Management SC-1 System and Communications Protection Policy andProcedures
AU-1 Audit and Accountability Policy and Procedures SC-7 Boundary ProtectionAU-2 Audit Events SC-8 Transmission Confidentiality and Integrity
PE-1 Physical and Environmental Protection Policy andProcedures SC-12 Cryptographic Key Establishment and Management
PE-2 Physical Access Authorizations SC-13 Cryptographic ProtectionPE-3 Physical Access Control SC-20 Secure Name Address Resolution ServicePE-6 Monitoring Physical Access SC-38 Operations Security
Table 10 Example of selected INS security controls
SC Description SC Description
AC-17 RemoteAccess IA-2 Identification and
Authentication
AC-18 WirelessAccess IA-3
DeviceIdentification andAuthentication
Table 11 Example of converting the security controls to ISOIEC 15408 and 27001
NIST Security Controls ISOIEC15408 or ISOIEC 27001 Requirements
AC-17 Remote AccessA621 Mobile device policyA622 TeleworkingA1321 Information transfer policies and procedures
AC-18 Wireless AccessA621 Mobile device policyA1311 Network controlsA1321 Information transfer policies and procedures
IA-2 Identification and Authentication
FIA ATD1 User Attribute DefinitionFIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
IA-3 Device Identification andAuthentication
FIA UAU1 User Authentication (Timing of Authentication)FIA UAU2 User Authentication before any action)FIA UID1 Timing of identificationFIA UID2 User Identification before any action
Table 12 Example of selected CVE on Ethernet vulnerabilities
Name DescriptionCVE-2017-9628 An Information Exposure issue
CVE-2017-9945
a Denial-of-Service condition could beinduced by a specially crafted PROFINET
DCP packet sent as a local Ethernet(Layer 2) broadcast
CVE-2017-3726 a privilege escalation vulnerability
CVE-2016-8106 vulnerable to a denial of service in certainlayer 2 network configurations
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
Security and Communication Networks 11
Table 13 Example of assessment scale-level of risk [14]
Overall Likelihood Impact Level of RiskVery Low Low Moderate High Very High
Very High Very Low Low Moderate High Very HighHigh Very Low Low Moderate High Very HighModerate Very Low Low Moderate Moderate HighLow Very Low Low Low Low ModerateVery Low Very Low Very Low Very Low Low Low
The requirement verification lies in the test method which isdecided by acquirer or settled between acquirer and provider
(G) Risk Assessment If the IA-3 security control failed inthe functional test we should reevaluate the impact levelof the risk about IA-3 failure by referring to Table 13 [14]As demonstrated in Table 12 the possibility of direct attacksto communication between INS and the rotation sensor islow but the resulting damage can result in catastrophic con-sequences of UAV failing to fly properly (high) As a resultowing to the fact that the overall risk is low acquirer stillmanages to continue the process even if IA-3 declines)
(H) Secure System Integration and Operational Test amp Evalua-tion If thewhole evaluation ends successfully acquirer couldcommence the integration of INS into UAV after which thedevelopment and evaluation of UAV are to be deployed Thepostintegration process follows the existing procedures of theacquirer
5 Conclusion
Provided that the evaluation framework is system-specificvariations emerge in the midst of negotiations betweencountries it is therefore difficult to employ the same approachto every scenario in reality Notwithstanding an existenceof a well-established framework to guide in part is ben-eficial upon the trading of systems We proposed thesecurity-enhanced framework based on the Risk Manage-ment Framework and Cybersecurity Test amp Evaluation andthis framework has been designed to be integrated intoimport process of weapon systems but not developmentalprocess Also we have raised the assurance level of theweapon system via a well-structured framework instead ofmathematical (formal) verification Within this frameworkthe cybersecurity of weapon systems is ensured throughoutthe lifecycle of weapon systems from the developmentstage of the provider to the operation stage of the acquirerIn addition by employing international standards ratherthan using domestic security controls under the proposedframework it facilitates the weapon system acquisition com-munication between the acquirer and providerWe reinforcedthe construction of this framework with reference to NISTdocuments however we did not recommend an evaluationmethodology relevant to this framework Some nationsmight encounter difficulties in applying our frameworkinto their weapon system acquire process Therefore future
studies would require a more detailed evaluation methodfor this framework and for compositing security evaluationin order to address the assurance level of weapon systems
Data Availability
The datasets generated during andor analyzed during thecurrent study are available from the corresponding authorupon reasonable request
Conflicts of Interest
The authors declare that there are no conflicts of interest re-garding the publication of this paper
Acknowledgments
This research was supported by the MSIT (Ministry ofScience ICT) Korea under the ITRC (Information Technol-ogy Research Center) support program (IITP-2018-2015-0-00403) supervised by the IITP (Institute for Information ampCommunications Technology Promotion)
References
[1] L Yushi J Fei and Y Hui ldquoStudy on applicationmodes of mili-tary internet of things (miot)rdquo in Proceedings of the IEEEInternational Conference vol 3 pp 630ndash634 Computer Scienceand Automation Engineering (CSAE) 2012
[2] J P Farwell and R Rohozinski ldquoStuxnet and the future of cyberwarrdquo Survival vol 53 no 1 pp 23ndash40 2011
[3] A Kim B Wampler J Goppert I Hwang and H AldridgeldquoCyber attack vulnerabilities analysis for unmanned aerialvehiclesrdquo in Proceedings of the AIAA Infotech at AerospaceConference and Exhibit 2012 USA June 2012
[4] C Miller and C Valasek ldquoRemote exploitation of an unalteredpassenger vehiclerdquo in Proceedings of the Black Hat BriefingsUSA 2015
[5] A Futter The Politics of Nuclear Weapons SAGE PublicationsLtd 1 Oliverrsquos Yard 55 City Road London EC1Y 1SP 2015
[6] C Dougherty K Sayre R C Seacord D Svoboda and KTogashi ldquoSecure design patternsrdquo Tech Rep Carnegie MellonUniversity Pittsburgh Pa USA Software Engineering Institute2009
[7] N Davis ldquoSecure software development life cycle processes Atechnology scouting reportrdquo Tech Rep Carnegie-Mellon UnivPittsburgh Pa Software Engineering Inst A technology scoutingreport 2005
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
12 Security and Communication Networks
[8] C Mundie P de Vries P Haynes and M Corwine ldquoTrustwor-thy computingrdquo Technical Report 2002
[9] K Fisher ldquoUsing formal methods to enable more securevehiclesrdquo ACM SIGPLAN Notices vol 49 no 9 pp 1-1 2014
[10] M Schwartz Defense Acquisitions How Dod Acquires WeaponSystems And Recent Efforts to Reform The Process Libraryof Congress Washington Dc Congressional Research Service2010
[11] H-G Albertsen and F Forge ldquoThe modular approach A com-posite product evaluation for smart cardsrdquo in Proceedings ofthe 3rd International Common Criteria Conference-CommonCriteria Delivering Information Assurance Solutions 2002
[12] K Muller M Paulitsch S Tverdyshev and H Blasum ldquoMILS-related information flow control in the avionic domain A viewon security-enhancing software architecturesrdquo in Proceedings ofthe 2012 IEEEIFIP 42nd International Conference on Depend-able Systems and Networks Workshops (DSN-W) pp 1ndash6Boston Mass USA June 2012
[13] B S Blanchard and W J Fabrycky ldquoSystem engineering andanalysisrdquo 5th ed Upper Saddle River N J Pearson Prentice-Hall international series in industrial and systems engineering2011
[14] S Ross Ronald ldquoGuide for conducting risk assessmentsrdquo NoSpecial Publication (NIST SP)-800-30r1 September 2012
[15] A B Jeng and Y-M Yu ldquoAnalysis of the composition problemsin cc v3 1 rev 1 with some suggested solutions ICCC 2006rdquo
[16] R S Ross ldquoSecurity and privacy controls for federal informa-tion systems and organizationsrdquo Tech Rep 2013
[17] R Von Solms ldquoInformation security management (3) TheCode of Practice for Information Security Management (BS7799)rdquo Information Management amp Computer Security vol 6no 5 pp 224-225 1998
[18] S L Brand Dod 520028-std Department of Defense TrustedComputer System Evaluation Criteria (orange book) NationalComputer Security Center 1985
[19] C E Landwehr ldquoComputer securityrdquo International Journal ofInformation Security vol 1 no 1 pp 3ndash13 2001
[20] I ISO and I Std ldquoIso 15408-2 2009 Information technology-Security techniques-Evaluation criteria for IT security-Part 2rdquo
[21] G Disterer ldquoISOIEC 27000 27001 and 27002 for InformationSecurity Managementrdquo Journal of Information Security vol 04no 02 pp 92ndash100 2013
[22] R Sandoval ldquoInformation systems development (isd) and thenational institute of standards and technology (nist) risk man-agement frameworkrdquo 2017
[23] D Instruction ldquo520040 dod information technology securitycertification and accreditation process (ditscap)rdquo December1997
[24] D Instruction ldquo851001 dod information assurance certifica-tion and accreditation process (diacap) november 28 2007rdquo
[25] NIST Guide for Applying the Risk Management Framework toFederal Information Systems A Security Life Cycle ApproachFebruary 2010
[26] D Instruction 851001 Risk Management Framework (RMF)for DoD Information Technology (IT) 2014
[27] K F Joiner S R Atkinson and E Sitnikova AUSTRALIArsquoSFUTURE SUBMARINE Cybersecurity Challenges and Processes2017
[28] D Instruction DoD Cybersecurity Test and Evaluation Guide-book June 26 2015
[29] Y Y Haimes RiskModeling Assessment andManagement JohnWiley amp Sons 2015
[30] M Kevin R L Kissel W C Barker et al Guide for MappingTypes of Information and Information Systems to Security Cate-gories (2 Volume) NIST 2008
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
International Journal of
AerospaceEngineeringHindawiwwwhindawicom Volume 2018
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Active and Passive Electronic Components
VLSI Design
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Shock and Vibration
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawiwwwhindawicom
Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Control Scienceand Engineering
Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
SensorsJournal of
Hindawiwwwhindawicom Volume 2018
International Journal of
RotatingMachinery
Hindawiwwwhindawicom Volume 2018
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Navigation and Observation
International Journal of
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
Submit your manuscripts atwwwhindawicom
Top Related