Security Evaluation Framework for Military IoT Devices

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


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


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


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


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


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


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


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


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


[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


Active and Passive Electronic Components

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



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



Journal ofEngineeringVolume 2018

SensorsJournal of



RotatingMachinery


Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation


Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom


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





key features




evaluation platform




CC

Product

System CampA

Environment











SystemCategorize①

②③

④

⑥⑤



AuthorizeSystem


DTampE




Surface







Risk Reduction



Operationamp

Support


SDLC

DefenseAcquisition

System

RMF

SSE

TampECybersecurity


RFP Release

Proposal Assessment

Test amp Evaluation

Decision

requirements


Decision

Requirements









Requirement

Requirements

SystemCategorize

Design


for acquirer

RFP Document


Security Controls

Development

Provider


SDLC

PurchaseProcess

RMF

ProposeFramework

SC based Criteria

CybersecurityTampE





Test andEvaluation

purchase

RFPReview

RFP

Risk Assessment

RiskUnacceptable

Release

① ② ②

③

④⑤

④

④







IdentifyKnown

vulnerabilities

PenetrationTest








ImpactAnalysis

RiskDetermination













































































Authentication













CVE-2017-9945












5 Conclusion



Data Availability




Acknowledgments


References


































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia






key features




evaluation platform




CC

Product

System CampA

Environment











SystemCategorize①

②③

④

⑥⑤



AuthorizeSystem


DTampE




Surface







Risk Reduction



Operationamp

Support


SDLC

DefenseAcquisition

System

RMF

SSE

TampECybersecurity


RFP Release

Proposal Assessment

Test amp Evaluation

Decision

requirements


Decision

Requirements









Requirement

Requirements

SystemCategorize

Design


for acquirer

RFP Document


Security Controls

Development

Provider


SDLC

PurchaseProcess

RMF

ProposeFramework

SC based Criteria

CybersecurityTampE





Test andEvaluation

purchase

RFPReview

RFP

Risk Assessment

RiskUnacceptable

Release

① ② ②

③

④⑤

④

④







IdentifyKnown

vulnerabilities

PenetrationTest








ImpactAnalysis

RiskDetermination













































































Authentication













CVE-2017-9945












5 Conclusion



Data Availability




Acknowledgments


References


































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




SystemCategorize①

②③

④

⑥⑤



AuthorizeSystem


DTampE




Surface







Risk Reduction



Operationamp

Support


SDLC

DefenseAcquisition

System

RMF

SSE

TampECybersecurity


RFP Release

Proposal Assessment

Test amp Evaluation

Decision

requirements


Decision

Requirements









Requirement

Requirements

SystemCategorize

Design


for acquirer

RFP Document


Security Controls

Development

Provider


SDLC

PurchaseProcess

RMF

ProposeFramework

SC based Criteria

CybersecurityTampE





Test andEvaluation

purchase

RFPReview

RFP

Risk Assessment

RiskUnacceptable

Release

① ② ②

③

④⑤

④

④







IdentifyKnown

vulnerabilities

PenetrationTest








ImpactAnalysis

RiskDetermination













































































Authentication













CVE-2017-9945












5 Conclusion



Data Availability




Acknowledgments


References


































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Requirement

Requirements

SystemCategorize

Design


for acquirer

RFP Document


Security Controls

Development

Provider


SDLC

PurchaseProcess

RMF

ProposeFramework

SC based Criteria

CybersecurityTampE





Test andEvaluation

purchase

RFPReview

RFP

Risk Assessment

RiskUnacceptable

Release

① ② ②

③

④⑤

④

④







IdentifyKnown

vulnerabilities

PenetrationTest








ImpactAnalysis

RiskDetermination













































































Authentication













CVE-2017-9945












5 Conclusion



Data Availability




Acknowledgments


References


































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia






ImpactAnalysis

RiskDetermination













































































Authentication













CVE-2017-9945












5 Conclusion



Data Availability




Acknowledgments


References


































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




































































Authentication













CVE-2017-9945












5 Conclusion



Data Availability




Acknowledgments


References


































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia









5 Conclusion



Data Availability




Acknowledgments


References


































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


Security Evaluation Framework for Military IoT Devices

Documents

Transcript of Security Evaluation Framework for Military IoT Devices