Seungyeon Jeong, Sooyoung Kang, and Seungjoo Kim, "Application of the Common Criteria to Building Trustworthy Automotive SDLC", Proc. of The 19th ICCC 2020, The 19th International Common Criteria Conference, Virtual (online) Conference, November 16-18, 2020.

1. 1/39
Application of the Common
Criteria to Building Trustworthy
Automotive SDLC
Seungyeon Jeong, Sooyoung Kang, Seungjoo Kim
sodon513@gmail.com
Department of Automotive
Convergence,
Korea University
bbang814@gmail.com
CIST (Center for Information
Security Technologies),
School of Cybersecurity,
Korea University
skim71@korea.ac.kr
*Corresponding Author
CIST (Center for Information
Security Technologies),
School of Cybersecurity,
Korea University

2. 2/39
1. Motivation
2. Related works
3. CIA-Level Driven Secure SDLC
Framework
4. Trustworthy Automotive SDLC
5. Case Study
6. Conclusion

3. 3/39
1. Motivation

4. 4/39
1. Motivation
▪ History
1970s
2022
1980s
2015
2002
• The US government recognized that it is not possible to improve
the security of products by penetrate & patch approach.
• The US government recognized that the product development
process itself must be systematically and strictly managed(a.k.a.
security-by-design) in order to improve the security of products.
※ Security-by-design: to reduce the complexity of the product by considering security from the initial phase of development process to achieve trustworthiness of the
product

5. 5/39
1. Motivation
▪ History
※ Secure SDLC(Secure Software/System Development Life Cycle): The development process containing the security-by-design philosophy
※ UNECE (United Nations Economic Commission for Europe)
• In the industry, Microsoft and IBM have been interested in secure
SDLC at first and spread it to the industry.
• The Department of Defense(DoD) demands an evaluation and
improvement of cybersecurity of weapons systems based on
operational requirements such as the Risk Management
Framework(RMF).
• UNECE requires the application of secure SDLC on vehicles by
enacting UNECE automotive cybersecurity regulation(UNECE
regulation).
1970s
2022
1980s
2015
2002

6. 6/39
1. Motivation
▪ From the early 1970s, the U.S. government has begun to recognize that it is
impossible to improve the security of products only by penetration test.
• They recognized that the development process should be systematically and strictly managed.
▪ From the 1980s, various standards related to security-by-design.
• Development methodologies and evaluation and procurement system has begun to be
published.
▪ In 2013, RMF was released aiming to manage the development and
evaluation/procurement of computer systems of military.
• According to the DoD Cyber Strategy announced in 2015, the scope of RMF has been expanded
from computer systems to advanced weapons systems.
▪ In 2020, UNECE regulation is enacted, and from 2022 vehicles that do not
comply with it cannot be exported to Europe.
We propose a specific security-by-design methodology that can be applied in
automotive development by using Common Criteria(CC) standard.
Published standards or guidelines do not provide a detailed methodology of
security-by-design, so it is very difficult to use them in the actual field.

7. 7/39
2. Related works

8. 8/39
2. Related works
▪ Research papers
• We analyzed 66 research papers related to automotive security
development.
✓ Papers published from 2010 to 2020, and only papers published in 4 major
digital library of (i) ACM (ii) IEEE (iii) Springer, and (iv) Elsevier.
✓ Papers with 'Automotive' or 'CPS' as a keyword and have the subject of the
entire process('Process’, 'Lifecycle’, 'Development'), some
phases('Requirements analysis') or some activities('Fuzz test').
Phase Description Num
Req/Des
Requirement
Analysis/
Design
56
Imp/
Veri
Implementation/
Verification
5
Rel/
Oper
Release/
Operation
1
Entire Entire process 4
Total 66
Req/Des(auto), 14
Imp/Veri(auto), 3
Rel/Oper(auto), 1
Entire(auto), 5
Req/Des
Imp/Veri
Rel/Oper
Entire
0 10 20 30 40 50 60
Phase
Number of studies
CPS security development studies
CPS
Automotive
※ CPS(Cyber Physical System)

9. 9/39
2. Related works
▪ Research papers(Examples)
• Setting Expectations for CC
in the Software Development
Lifecycle(ICCC, 2008)
✓ This research performed mapping
between SDLC and CC but does not
present specific SDLC activities.
• Verification of IVI
Over-The-Air using UML/OCL
(ICCC, 2019)
✓ This research mentioned secure
SDLC, but only covers the
requirements analysis and design
phases.

10. 10/39
2. Related works
▪ Secure SDLC standards & guidelines
• Well-known secure SDLC standards and guidelines are extended and
utilized in various fields.
Software Microsoft SDL
Secure SDLC developed by Microsoft
and applied directly to operating
systems and database products
Not include disposal phase
Lack of activity for implementation
phaseNIST SSDLC
Secure SDLC on Software and hardware
developed by NISTSystem
Best
practices
OWASP CLASP
Secure SDLC to strengthen security in
the early phases with 5 views and 24
activities
Lack of information because the project
period expired
Vehicles SAE J3061
Secure SDLC guideline suggesting ways
to ensure the security of automotive
development
Not include training and disposal phase
※ OWASP(Open Web Application Security Project), CLASP(Comprehensive, Lightweight Application Security Process), SAE(Society of Automotive Engineers)
Target Secure SDLC Description Cons
※ SDL(Software Development Lifecycle), NIST(National Institute of Standards and Technology), SSDLC(Secure System Development Life Cycle)

11. 11/39
2. Related works
▪ Automotive Cybersecurity Regulation
• UNECE is enacting automotive cybersecurity regulation to ensure security
for the entire development process.
✓ Expected to take effect for new vehicles from 2022 and for the existing vehicles
from 2024.

12. 12/39
2. Related works
▪ Automotive Cybersecurity Regulation
• UNECE regulation is expected to expand as UAM development becomes
active in the future.
• Hyundai Motor Group has started to develop an innovative Urban Air
Mobility(UAM) infrastructure.
✓ They decided to invest $1.5 billion over the next five years in infrastructure such as private
air vehicles(PAVs) and hubs for UAM.
• Global companies expect that the UAM market will experience explosive
growth over the next 20 years.
✓ The Porsche Group predicts that the UAM market will grow rapidly from 2025, and the
market demand will reach about 16,000 units worldwide by 2035.
✓ Morgan Stanley, an investment bank of the US, predicts that the autonomous mobility
market, including UAM, will reach $1.5 trillion by 2040.

13. 13/39
3. CIA-Level Driven Secure
SDLC Framework

14. 14/39
3. CIA-Level Driven Secure SDLC Framework
▪ Security-by-Design
• To reduce the complexity of a product by considering security from the
early phases of development(such as requirements analysis or design) and
consequently to achieve the product's trustworthiness.
• The trustworthiness is to achieve all aspects of the correctness, safety, and
security of the product's functions.
▪ CIA
• Trustworthiness which is the goal of security-by-design can be named
after CIA.
Functional
Correctness
Safety
Integrity
Security
Assurance
+ +
CIA-Level Driven Secure SDLC Framework

15. 15/39
3. CIA-Level Driven Secure SDLC Framework
▪ CIA-Level Driven Secure SDLC Framework(CIA-Level Framework)
• Security-by-design methodology integrating secure SDLCs and evidence-
based approaches
• It combines 10 types of secure SDLCs and 3 types of evidence-based
approaches.
• It concretizes the secure SDLC to derive related processes, security
activities, detailed security activities, and evidence templates.
※ Evidence-based approaches: A standard that provides a concrete way of
performing a process by presenting detailed requirements(such as evidences,
detailed activities, etc.) for each activities of the development process
※ CC(Common Criteria, ISO 15408)
※ PIMS(Privacy Impact Management System, ISO 27701)
※ ISMS(Information Security Management System, ISO 27001)
• Microsoft SDL
• NIST SSDLC
• CSA SDF
• SAFECode
• MgGraw
Touchpoints
• OWASP CLASP
• Cigital BSIMM
• OWASP SAMM
• NIST RMF
• SAE J3061
Secure SDLC
• CC
• PIMS
Evidence-based
approach
• ISMS
Customized secure SDLC
Process, Activities,
Evidence Templates
CIA-Level
Framework

16. 16/39
3. CIA-Level Driven Secure SDLC Framework
▪ CIA-Level Framework
• It quantitatively analyzes the difference in the level of secure SDLC
process between enterprises and their competitors.
• It can be useful when the enterprise wants to build secure SDLC in the
actual field by easily eliciting requirements(security activities, detailed
security activities, and evidence templates) to build secure SDLC at the
desired level.
CIA-Level
Extractor
Customized
Secure SDLC
Constructor
Activity-Evidence
Mapper
Standards, Laws, Rules, and Regulations
Customized Secure SDLC Process, Activities, Detailed Activities, Evidence Templates
• Standards, Laws, Rules, and Regulations: Common Criteria, ISMS, PIMS, etc.
• Activity-Evidence Mapper: Mapping Secure SDLC activities and evidences by CIA-Level
Target Market

17. 17/39
▪ Module that maps secure SDLCs and evidence-based approaches
• It considers 10 types of secure SDLC standards and guidelines that are widely used in
each field.
✓ It compares and analyzes those secure SDLCs and generalizes them into 10 phases.
✓ It derives 66 security activities by summing up all the security activities that need to be
performed in each phase and removing redundant security activities.
3. CIA-Level Driven Secure SDLC Framework
Activity-Evidence Mapper
Analyze and normalize all the activities of each phase of every standard
Integrate them into one single Secure SDLC
Map secure SDLC and the SAR components of CC to the normalized activities
Define detailed activities and build a template for each normalized activity
Supplement the unmapped activities with other standards
Standards, Laws, Rules, and Regulations
Integrated Secure SDLC Process with detailed activities and evidence templates
CC, CEM
ISMS, PIMS,
etc.
※ SAR(Security Assurance Requirements), CEM(Common Evaluation Methodology)

18. 18/39
3. CIA-Level Driven Secure SDLC Framework
▪ Integrated Secure SDLC Process – Security activities
• CIA-Level Framework consists of a total of 66 activities for 10 phases and
28 evidence templates.
1.
Security
Training
2.
Initiation
3.
Requirements
analysis
4.
Acquisition
5.
Design
6.
Implement-ation
7.
Verification
8.
Production&
Release
9.
Operation
10.
Disposal
1.1
Basic security training
3 9 9 3 12 3 8 7 7 5
1.2
Advanced security
training
1.3
Plan training
schedules
2.1
Project categorization
2.2
Role
identification
2.3
Project tools selection
2.4
Security requirements
source identification
2.5
Minimum quality level
definition
2.6
Prepare
compensation system
for handling security
issues
2.7
Plan project
schedule
2.8
Security goals
setting by field
2.9
Verifying
consistency &
completeness of goals
3.1
Estimating scope of
project security
analysis
3.2
Impact assessment for
privacy
3.3
Impact assessment for
business
3.4
Impact assessment for
safety
3.5
Existing software
assessment
3.6
Functional
requirements
elicitation
3.7
Security requirements
elicitation
3.8
Conformity & conflict
check
on requirements
by field
3.9
Verifying
requirements based
on security goals
4.1
Plan third-party
components
acquisition
4.2
Requirements
definition for third-
party components
4.3
Assessment & test for
third-party
components
10.1
Transfer & disposal
procedure planning
10.2
Important information
disposal
10.3
Media Erase
10.4
Hardware and
software disposal
10.5
System shutdown
9.1
Monitoring
planning
9.2
Continuous
monitoring
9.3
Vulnerability report
9.4
Vulnerabilities
assessment
9.5
Solution
establishment
9.4
Vulnerability
disclosure &
patch/update
9.5
Configuration
management after
release
8.1
Final
security review
8.2
Final
privacy review
8.3
Requirements
elicitation for
production
8.4
Production procedure
determination
8.5
Verification of
production
8.4
Accident response
planning
8.5
Security review for
deployment
procedure
7.1
Final
security review
7.2
Final
privacy review
7.3
Requirements
elicitation for
production
7.4
Production procedure
determination
7.5
Verification of
production
7.6
Accident response
planning
7.7
Security review for
deployment
procedure
7.8
Security review for
deployment
procedure
5.1
Functions & design
specification
5.2
Compliance with
design best practices
and principles
5.3
Structural design for
the integration
process
5.4
Asset identification
5.5
Create data flow
diagram
5.6
Threat elicitation
5.7
Attack Library
Collection
5.8
Risk analysis
by field
5.9
Mitigation elicitation
by field
5.10
Privacy analysis
5.11
Use case and misuse
case identification
5.12
Verifying design
based on
requirements
6.1
Compliance with
secure coding
guidelines
6.2
Creation for
deployment guide
document and tools
6.3
Implementation
verification according
to design

19. 19/39
3. CIA-Level Driven Secure SDLC Framework
▪ Integrated Secure SDLC Process – Evidence templates
• CIA-Level Framework consists of a total of 66 activities for 10 phases and
28 evidence templates.
Phase Evidence Num. Phase Evidence Num.
1
Security
Training
• Security training plan
• Training attendee list
2 6
Impleme-
ntation
• Source code
• Unit test plan and test scenario
• Unit test results
3
2 Initiation
• Current process analysis
• Current system analysis
• Project plan
• Software Requirements Specification
4 7 Verification
• Integrated/system/acquisition test plan and
test scenario
• Integrated/system/acquisition test results
• Vulnerability analysis
3
3
Require-
ments
Analysis
• Impact assessment
• Interface definition
2 8
Production
& Release
• Rehearsal plan and rehearsal result
• Release request
• Emergency incident response plan
• Emergency accident response result
4
4 Acquisition • Acquisition confirmation document 1 9 Operation
• Preparation result
• Operator instructions
• User guide
• Vulnerability Response Plan
• Vulnerability patch result
5
5 Design
• Software design specification
• Software architecture design and
System architecture design specification
• Integrated test plan and integrated test
scenario
3 10 Disposal
• System execution plan and system execution
result
1

20. 20/39
3. CIA-Level Driven Secure SDLC Framework
▪ Repository that stores the mapping results and related details of Activity-
Evidence Mapper
• Database consists of a 4-table scheme.
✓ Table of 10 generalized secure SDLC phases
✓ Table of 66 security activities that must be performed at each phase
✓ Table of detailed security activity lists and descriptions
✓ Table of document templates that need to be produced
Database
Database
scheme
Integrated
Secure SDLC
Phase
Activities
Detailed Activities
Evidence
Document
Templates
CC
(SAR
&
CEM)
ISMS PIMS
AAA
BBB
CCC
DDD

21. 21/39
▪ CIA-Level Extractor: Module that extracts the CIA-Level of a company's secure
SDLC
• It quantitatively analyzes the security activities of the secure SDLC and calculates
CIA-Level.
✓ CIA-Level: Indicator of trustworthiness that composed of Level 1 to Level 7
✓ It means that the secure SDLC is systematically and strictly managed as the level increases.
▪ GAP Analyzer: Module that analyzes the gap of secure SDLC level between the
company and its competitors
Integrated
Secure
SDLC
Phase
Activities
Detailed Activities
Evidence
Document
Templates
CC
(SAR &
CEM)
ISMS PIMS
AAA
BBB
CCC
DDD
3. CIA-Level Driven Secure SDLC Framework
CIA-Level Extractor & GAP Analyzer
Predict competitor’s secure SDLC process, Activities, Detailed Activities etc.
Analyze the differences of each activity between the company and competitors
Gap Analysis Report
Average CIA-level of Competitor’s Flagship Products
Company’s secure
SDLC Process,
Activities, Detailed
Activities,
Evidences, Tools, etc.

22. 22/39
3. CIA-Level Driven Secure SDLC Framework
▪ Module that provides detailed information on the level desired by the
company
• It provides secure SDLC process, security activities, detailed security activities, and
evidence templates.
✓ It quantitative analyze on only relevant security activities out of a total of 66 security
activities, considering the business sector and characteristics.
✓ It ensures traceability of the entire Secure SDLC by easily deriving documents that need to
be produced.
Customized Secure SDLC Constructor
Select the phases according to the characteristics of the products
of the company
Choose the detailed activities and the evidence templates
according to CIA level
Customized Secure SDLC Process, Activities, Detailed Activities Evidence Templates
CIA-Level Database

23. 23/39
4. Trustworthy Automotive SDLC

24. 24/39
4. Trustworthy Automotive SDLC
▪ Trustworthy Automotive SDLC(TA_SDLC)
• Specific security-by-design methodology for automotive development
• It is an application of CIA-Level Framework that is extended and utilized
for automotive development.
• It is assumed that automotive OEMs have a safety development
process(Safety SDLC) according to ISO 26262.
Security Level
Extractor
Safety &
Security
Integrator
OEM’s Safety SDLC
(ISO 26262 safety
development process)
Safety Level
Extractor
CIA-Level
Framework
Safety &
Security
Integrator
TA_SDLC
Requirements
Requirements of
UNECE regulation &
ISO/SAE 21434
Customized TA_SDLC
Process, Activities,
Evidence Templates
※ ISO(International Organization for Standardization), ISO 26262: International standard for functional safety of electrical/electronic systems in road vehicles
※ OEM(Original Equipment Manufacturer)

25. 25/39
4. Trustworthy Automotive SDLC
▪ TA_SDLC Requirements
• A total of 4 requirements of TA_SDLC were derived.
✓ They were selected based on the characteristics of automotive development.
※ Third-party component: components developed and utilized by other companies
※ Traceability: To ensure consistency in the results between phases so that we can trace back to the initial cause when a security problem occurs
※ Depth: Indicators for the degree of activities detail defined in this study
① Targets on system
② Includes the procedure of third-party components acquisition
③ Ensures traceability between phases
④ Provides detailed activities and the evidence templates for
every phase of the process(depth=2)
Depth = 0
Depth = 1
Depth = 2

26. 26/39
4. Trustworthy Automotive SDLC
ASIL level of ISO 26262
▪ Safety Level Extractor: Module that extracts the safety level of a company’s
safety SDLC
• We assume that automotive OEMs have a safety SDLC according to ISO 26262.
✓ ASIL: safety-related risk level defined by the ISO 26262
✓ ASIL required for developing major functions of vehicles is C level or higher.
▪ Security Level Extractor: Module that extracts the security level corresponding
to the safety level of the existing safety SDLC
• It should satisfy EAL 5 to sufficient security for automotive development.
✓ EAL: security assurance level defined by CC
✓ ASIL C corresponds to the EAL 5 level of CC.
Safety Level Extractor & Security Level Extractor
ASIL C or higher
※ ASIL(Automotive Safety Integrity Level):, EAL(Evaluation Assurance Level), ISO/SAE 21434: International standard for security of E/E systems in road vehicles

27. 27/39
4. Trustworthy Automotive SDLC
▪ Framework that derives detailed secure SDLC for the target company
• It derives secure SDLC suitable for automotive development by inserting TA_SDLC
requirements and security level to the CIA-Level Framework.
▪ Module that integrates TA_SDLC derived from CIA-Level Framework and
existing automotive safety SDLC
• It derives Customized TA_SDLC suitable for ISO 26262’s safety SDLC.
Safety & Security Integrator
CIA-Level Framework
EAL 5 CIA-Level Framework
Safety &
Security
Integrator
Customized TA_SDLC
Process, Activities,
Evidence Templates
ISO 26262’s
Safety SDLCTrustworthy
Automotive SDLC
Requirements
Requirements of
UNECE regulation &
ISO/SAE 21434

28. 28/39
4. Trustworthy Automotive SDLC
▪ TA_SDLC Process – Activities
• TA_SDLC consists of a total of 50 activities for 10 phases and 26 evidence
templates.
1.
Training
1.1
Perform training
1.1.1
Basic training
1.1.2
Advanced training
1.2
Plan training
schedules
1.2.1
Training schedules
planning
2.
Initiation
2.1
Configure project
environment
2.1.1
Project
categorization
2.1.2
Role identification
2.1.3
Project tools
selection
2.1.4
Requirements
source
identification
2.1.5
Minimum quality
level definition
2.2
Plan project
schedule
2.2.1
Project schedules
planning
2.2.2
Project analysis
coverage definition
2.3
Set & verify goals
2.3.1
Goals setting
2.3.2
Verifying
consistency
& completeness of
goals
3.
Requirements
analysis
3.1
Assess impact level
3.1.1
Impact assessment
3.1.2
Conformity &
conflict check on
impact assessment
results
3.1.3
Existing system
assessment
3.2
Elicit requirements
3.2.1
Requirements
elicitation
3.3
Verify
requirements
3.3.1
Verifying
requirements
based on goals
3.2.2
Conformity &
conflict check on
requirements
4.
Acquisition
4.1
Plan third-party
components
acquisition
4.1.1
Acquisition
scope setting &
planning
4.1.2
Requirements
definition for
third-party
components
4.2
Use third-party
components
4.2.1
Assessment & test
for third-party
components
5.
Design
5.1
Design
architecture
5.1.1
Functions & design
specification
5.1.2
Design integrated
structure
5.2
Analyze risk
5.2.1
Risk analysis
5.2.2
Mitigation
elicitation
5.2.3
Conformity &
conflict check on
mitigations
5.3
Verify design
5.3.1
Verifying design
based on
requirements
6.
Implementation
6.1
Build an
implementation
environment
6.1.1
Coding guidelines
compliance
6.1.2
Guideline & tools
creation
6.2
Verify
Implementation
6.2.1
Verifying
implementation
based on design
7.
Verification
7.1
Test
7.1.1
Static analysis
7.1.2
Dynamic analysis
7.2
Review before
production
7.2.1
Final review
7.2.2
Documents review
& update
7.1.3
Integration &
acceptance test
7.1.4
Penetration test
8.
Production&
Release
8.1
Produce
8.1.1
Requirements
elicitation for
production
8.1.2
Production
procedure
determination
8.2
Establish response
plans
8.2.1
Accident response
planning
8.1.3
Verification of
production
8.3
Review
deployment
procedure
8.3.1
Security review for
deployment
procedure
9.
Operation
9.1
Monitor
9.1.1
Monitoring
planning
9.1.2
Continuous
monitoring
9.2
Respond to
Incident
9.2.1
Vulnerability
report
9.3
Manage
configuration
9.3.1
Configuration
management after
release
9.2.2
Vulnerabilities
assessment
9.2.3
Solution
establishment
9.2.4
Vulnerability
disclosure
& patch/update
10.
Disposal
10.1
Plan transfer &
disposal procedure
10.1.1
Transfer & disposal
procedure
planning
10.2
Build transfer &
disposal
environment
10.2.1
Providing
guidelines for
transfer & disposal
procedures
3 9 6 3 6 3 6 5 7 2

29. 29/39
4. Trustworthy Automotive SDLC
▪ TA_SDLC Process – Evidence templates
• TA_SDLC consists of a total of 50 activities for 10 phases and 26 evidence
templates.
Phase Evidence Num. Phase Evidence Num.
1 Training
• Training plan
• List of attendance at training
2 6
Impleme-
ntation
• System implementation report
• User's manual or tool
• Project implementation verification
report
3
2 Initiation
• Project plan
• Project goal verification report
2 7 Verification
• Test plan
• Test result report
• Vulnerability Analysis report
• Final review report
4
3
Require-
ments
Analysis
• Impact assessment report
• Requirements definition report
• Project requirements verification
report
3 8
Production
& Release
· Production plan
· Production verification report
· Accident response plan
3
4 Acquisition
• Acquisition plan
• Acquisition inspection report
2 9 Operation
· System monitoring report
· Accident response report
2
5 Design
• Design specification
• Architecture specification
• System Risk Analysis report
• Project design verification report
4 10 Disposal
· Guidelines for system transfer and
disposal
1

30. 30/39
5. Case Study

31. 31/39
5. Case Study – CIA-Level Framework(Company A)
▪ To prove the effectiveness of the CIA-Level Framework, we applied it to a
representative software development company(A) in Korea.
▪ We selected competitors of company A and performed the following process.
• After selecting the competitor as Microsoft, we selected CIA-Level 4 based on the
CC certification cases.
1. Identify the characteristics of the enterprise
2. Select competitors based on the result of #1
3. Deviate average CIA-level of competitors
4. Select phase and security activities associated with the enterprise
5. Deviate CIA-level for each enterprise security activity
6. Analyze secure SDLC level gap between competitor and enterprise
7. Elicit gap analysis report and result graph
8. Share analysis results to security managers
8. Select CIA-level that enterprise wants
10. Provide suitable secure SDLC process, security activities,
detailed security activities, artifacts, etc
Product name EAL Year
DB
Microsoft SQL Server 2014 EAL2+ 2015
Microsoft SQL Server 2014 EAL4+ 2015
Microsoft SQL Server 2016 EAL4+ 2017
Microsoft SQL Server 2016
Database Engine Enterprise Edition
EAL2+ 2017
Microsoft SQL Server 2017 EAL4+ 2020
OS
Microsoft Windows 10 EAL1 2016
Windows 10 Anniversary Update
and Microsoft Windows Server
2016
EAL1 2017
Microsoft Windows 10 EAL1 2018
Windows 10 and Windows Server EAL1 2018
Windows 10 and Windows Server EAL1 2019
Windows 10 and Windows Server
2019 version 1809
EAL1 2019
Windows 10 and
Server version 1903
EAL1 2019

32. 32/39
5. Case Study – CIA-Level Framework(Company A)
▪ We selected 8 of the 10 phases: security training, initiation, requirements
analysis, design, implementation, verification, release, and operation.
• Out of 66 security activities, 58 were selected, and company A determined that only
6 out of 58 security activities had the same level as Microsoft.
▪ We suggested a secure SDLC suitable for company A by applying CIA-Level
Framework.
• Afterward, the effectiveness of the framework has been proved as company A
applied the improved process to the actual environment.
0
1
2
3
4
5
6
7
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58
Level
Activity
Company A
Microsoft
Security
Training
Initiation
Requirements
Analysis
Design
Implemen
-tation
Verification Release Operation

33. 33/39
5. Case Study – TA_SDLC(Company B)
▪ In order to prove the effectiveness of TA_SDLC, we applied it to a
representative automotive OEM(B) in Korea targeting the European market.
▪ We performed the following process based on company B's development
process.
• We estimated the satisfaction level of company B's development process for each
activity of TA_SDLC.
▪ Company B does not have a systematic security development process and
performs security activities sporadically.
• We collected information mainly based on expert interviews to understand the
security activities performed by company B.
1. Identify
company B's
development
process and activities
2. Estimate
satisfaction level of
company B's
development process
with TA_SDLC’s
phases and activities
3. Derive
improvements of
company B's
development process
for automotive
security-by-design

34. 34/39
5. Case Study – TA_SDLC(Company B)
▪ We determined that company B performs only 34 activities out of the 50
activities of TA_SLDC, and 16 additional activities should be performed to
achieve automotive security-by-design.
• Afterward, we suggested that automotive OEMs could improve the company's
development process to satisfy UNECE regulation and develop vehicles with
trustworthiness.
Phase
Number of activities
(B/TA_SDLC)
1 Training 2/3
2 Initiation 8/9
3 Requirements Analysis 3/6
4 Acquisition 3/3
5 Design 5/6
6 Implementation 2/3
7 Verification 3/6
8 Production & Release 4/5
9 Operation 4/7
10 Disposal 0/2
Total 34/50

35. 35/39
6. Conclusion

36. 36/39
6. Conclusion
▪ Since the 1980s, the US government has recognized that the
development process must be systematically and strictly managed to
improve security.
▪ Afterward, Secure SDLC which applies the security-by-design
philosophy has begun to be used.
• However, it is difficult to use them in the actual field since they are too
general.
▪ In this study, we proposed a CIA-Level Framework that derives
detailed secure SDLC by integrating existing secure SDLCs and
evidence-based approaches.
▪ We also proposed TA_SDLC, a specific automotive security-by-design
methodology derived by CIA-Level Framework.
▪ In addition, we did case studies of CIA-Level Framework and TA_SDLC.
• By applying CIA-Level Framework to a representative software
development company, the effectiveness of CIA-Level Framework was
verified.
• By applying TA_SDLC to a representative automotive OEM, the possibility
of developing vehicles with trustworthiness was presented.

37. 37/39
Reference
1. Abdo, H., et al. "A safety/security risk analysis approach of Industrial Control Systems: A cyber bowtie–combining new version of attack tree with bowtie analysis." Computers &
Security 72 (2018): 175-195.
2. Apvrille, Ludovic, and Letitia W. Li. "Harmonizing safety, security and performance requirements in embedded systems." 2019 Design, Automation & Test in Europe Conference &
Exhibition (DATE). IEEE, 2019.
3. Asplund, Fredrik, et al. "Rapid Integration of CPS Security and Safety." IEEE Embedded Systems Letters 11.4 (2018): 111-114.
4. Bhalla, Nishchal, et al. "Security risk identification in a secure software lifecycle." U.S. Patent Application No.15784072. 2019
5. Bramberger, Robert, et al. "Co-engineering of Safety and Security Life Cycles for Engineering of Automotive Systems." ACM SIGAda Ada Letters 39.2 (2020): 41-48.
6. Brunner, Michael, et al. "Towards an integrated model for safety and security requirements of cyber-physical systems." 2017 IEEE International Conference on Software Quality,
Reliability and Security Companion (QRS-C). IEEE, 2017.
7. Casola, Valentina, et al. "A novel Security-by-Design methodology: Modeling and assessing security by SLAs with a quantitative approach." Journal of Systems and Software 163
(2020): 110537.
8. Chen, Earl, et al. "Designing security into software during the development lifecycle." U.S. Patent Application No. 13619581. 2013.
9. Chowdhury, Thomas, et al. "Safe and secure automotive over-the-air updates." International Conference on Computer Safety, Reliability, and Security. Springer, Cham, 2018.
10. Cigital, "Building Security in Maturity Model 1.0."
11. CSA, “security-by-design Framework version 1.0”. 2017
12. Dobaj, Jürgen, et al. "Towards Integrated Quantitative Security and Safety Risk Assessment." International Conference on Computer Safety, Reliability, and Security. Springer,
Cham, 2019.
13. Fowler, Daniel S., et al. "A Method for Constructing Automotive Cybersecurity Tests, a CAN Fuzz Testing Example." 2019 IEEE 19th International Conference on Software Quality,
Reliability and Security Companion (QRS-C). IEEE, 2019.
14. Futcher, Lynn, and Rossouw von Solms. "SecSDM: a model for integrating security into the software development life cycle." IFIP World Conference on Information Security
Education. Springer, New York, NY, 2007.
15. Geismann, Johannes, Christopher Gerking, and Eric Bodden. "Towards ensuring security-by-design in cyber-physical systems engineering processes." Proceedings of the 2018
International Conference on Software and System Process. 2018.
16. Huang, Kaixing, et al. "Assessing the physical impact of cyberattacks on industrial cyber-physical systems." IEEE Transactions on Industrial Electronics 65.10 (2018): 8153-8162.
17. ISO/IEC 15408, "Information technology - Security techniques - Evaluation criteria for IT security(CC)."
18. ISO/IEC 27001, "Information Security Management(ISMS)."
19. ISO/IEC 27701, "Security techniques - Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management (PIMS).“
20. Koschuch, Manuel, et al. "Safety & Security in the Context of Autonomous Driving." 2019 IEEE International Conference on Connected Vehicles and Expo (ICCVE). IEEE, 2019.
21. Kriaa, Siwar, et al. "A survey of approaches combining safety and security for industrial control systems." Reliability engineering & system safety 139 (2015): 156-178.
22. Kriaa, Siwar, et al. "A survey of approaches combining safety and security for industrial control systems." Reliability engineering & system safety 139 (2015): 156-178.
23. Lee, Younghwa, Jintae Lee, and Zoonky Lee. "Integrating software lifecycle process standards with security engineering." Computers & Security 21.4 (2002): 345-355.
24. Lisova, Elena, Irfan Šljivo, and Aida Čaušević. "Safety and security co-analyses: A systematic literature review." IEEE Systems Journal 13.3 (2018): 2189-2200.
25. Mellado, Daniel, Eduardo Fernández –Medina, and Mario Piattini. " A common criteria based security requirements engineering process for the development of secure
information systems." Computer standards & interfaces 29.2 (2007): 244-253.
26. Mesquida, Antoni Lluís, and Antonia Mas. "Implementing information security best practices on software lifecycle processes: The ISO/IEC 15504 Security Extension." Computers &
Security 48 (2015): 19-34.
27. Michailidis, Alexander, et al. "Test front loading in early stages of automotive software development based on AUTOSAR." 2010 Design, Automation & Test in Europe Conference
& Exhibition (DATE 2010). IEEE, 2010.
28. Microsoft, "Security Development Lifecycle - SDL Process Guidance Version 5.2", 2012

38. 38/39
Reference
29. Mir, Talhah Munawar, et al. "Threat analysis and modeling during a software development lifecycle of a software application." U.S. Patent No.8091065. 2012.
30. Mohammed, Nabil M., et al. "Exploring software security approaches in software development lifecycle: A systematic mapping study." Computer Standards & Interfaces 50 (2017):
107-115.
31. Morrison, Patrick, et al. "Mapping the field of software life cycle security metrics." Information and Software Technology 102 (2018): 146-159.
32. Nayerifard, Tahereh, Nasser Modiri, and Sam Jabbehdari. "An Approach for Software Security Evaluation Based on ISO/IEC 15408 in the ISMS Implementation." International
Journal of Computer Science and Information Security 11.9 (2013): 7.
33. NIST, "NIST Special Publication 800-37 Revision 2 – Risk Management Framework for Information Systems and Organizations."
34. Oka, Dennis Kengo, Tommi Makila, and Rikke Kuipers. "Integrating Application Security Testing Tools into ALM Tools in the Automotive Industry." 2019 IEEE 19th International
Conference on Software Quality, Reliability and Security Companion (QRS-C). IEEE, 2019.
35. OWASP, "Comprehensive, Lightweight Application Security Process."
36. OWASP, "Software Assurance Maturity Model 2.0 – A guide to building."
37. Pricop, Emil, Sanda Florentina Mihalache, and Jaouhar Fattahi. "Innovative fuzzy approach on analyzing industrial control systems security." Recent Advances in Systems Safety
and Security. Springer, Cham, 2016. 223-239.
38. Sabaliauskaite, Giedre, Sridhar Adepu, and Aditya Mathur. "A six-step model for safety and security analysis of cyber-physical systems." International Conference on Critical
Information Infrastructures Security. Springer, Cham, 2016.
39. SAE, "Cybersecurity Guidebook for Cyber-Physical Vehicle Systems”
40. SAFECode, “Fundamental Practices for Secure Software Development 2nd Edition”
41. Sánchez-Gordón, Mary-Luz, et al. "Towards the Integration of Security Practices in the Software Implementation Process of ISO/IEC 29110: A Mapping." European Conference on
Software Process Improvement. Springer, Cham, 2017.
42. Schilder, Marius, et al. "Secure device state apparatus and method and lifecycle management." U.S. Patent No.10223531. 2018.
43. Schmittner, Christoph, Zhendong Ma, and Erwin Schoitsch. "Combined safety and security development lifecylce." 2015 IEEE 13th International Conference on Industrial
Informatics (INDIN). IEEE, 2015.
44. Sheikhpour, Razieh, and Nasser Modiri. "A best practice approach for integration of ITIL and ISO/IEC 27001 services for information security management." Indian journal of
science and technology 5.2 (2012): 2170-2176.
45. Silke Holtmanns and Rune Lindholm, "Enhanced lifecycle management of security module", Patent Application No.CN103988530A. 2018.
46. Skoglund, Martin, Fredrik Warg, and Behrooz Sangchoolie. "In Search of Synergies in a Multi-concern Development Lifecycle: Safety and Cybersecurity." International Conference
on Computer Safety, Reliability, and Security. Springer, Cham, 2018.
47. Takahira, Ricardo Y., et al. "Scrum and Embedded Software development for the automotive industry." Proceedings of PICMET'14 Conference: Portland International Center for
Management of Engineering and Technology; Infrastructure and Service Integration. IEEE, 2014.
48. Tiirik, Karl. "Comparison of SDL and Touchpoints." Last retrieved 11 (2004): 16-18.
49. United States Congress, "NIST SP 800-64 Revision 2 – Security Considerations in the System Development Life Cycle", 2019
50. Verma, Siddhartha, et al. "Combined Approach for Safety and Security." International Conference on Computer Safety, Reliability, and Security. Springer, Cham, 2019.
51. Vincent, Benjamin, and Ariel Gordon. "Security configuration lifecycle account protection for minors." U.S. Patent Application No.16022554. 2020
52. Wilcock, Lawrence, et al. "Automated lifecycle management of a computer implemented service." U.S. Patent No.8312419. 2012.
53. Wolff, Carsten, et al. "AMALTHEA—Tailoring tools to projects in automotive software development." 2015 IEEE 8th International Conference on Intelligent Data Acquisition and
Advanced Computing Systems: Technology and Applications (IDAACS). Vol. 2. IEEE, 2015.
54. Yi, Shengwei, et al. "A safety-security assessment approach for communication-based train control (cbtc) systems based on the extended fault tree." 2018 27th International
Conference on Computer Communication and Networks (ICCCN). IEEE, 2018.
55. Young, William, and Nancy G. Leveson. "An integrated approach to safety and security based on systems theory." Communications of the ACM 57.2 (2014): 31-35.
56. Zhang, Yanan, et al. "Test and Evaluation System for Automotive Cybersecurity." 2018 IEEE International Conference on Computational Science and Engineering (CSE). IEEE, 2018.

39. 39/39
Application of the Common
Criteria to Building Trustworthy
Automotive SDLC
This research was supported by the MSIT(Ministry of Science and ICT), Korea, under the
ITRC(Information Technology Research Center) support program(IITP-2020-2015-0-
00403)supervised by the IITP(Institute for Information &communications Technology
Planning &Evaluation)
Seungyeon Jeong, Sooyoung Kang, Seungjoo Kim
sodon513@gmail.com
Department of Automotive
Convergence,
Korea University
bbang814@gmail.com
CIST (Center for Information
Security Technologies),
School of Cybersecurity,
Korea University
skim71@korea.ac.kr
*Corresponding Author
CIST (Center for Information
Security Technologies),
School of Cybersecurity,
Korea University

40. 40/39
Appendix A
▪ Effectiveness of TA_SDLC
• Comparative analysis with existing researches
✓ We compared TA_SDLC with existing researches by TA_SDLC requirements.
✓ TA_SDLC considers the aspect of trustworthiness and consists of detailed
activities derived by the existing secure SDLC standards and evidence-based
approaches.
Features
Existing secure SDLC Relevant studies
TA_SDLCMicrosoft
SDL
NIST
SSDLC
OWASP
CLASP
SAE
J3061
Takahir
a et al.
Young
et al.
Schmi-
ttner et
al.
Skogl-
und et
al.
Kosch-
uch et
al
1 Targets on system X O X O O O O O O O
2
Includes the procedure
of third-party components
acquisition
X O O O X X X X X O
3
Considers aspect of
trustworthiness
X X X O O O O O O O
4
Satisfies the level of safety
and security required by
automotive development
X X X X X X X X X O
5
Ensures traceability
between phases
O O X O X X O X X O
6
Provides detailed activities for
every phase of the process
(phase num./activity num.)
8/34 9/36 9/21 9/26 6/13 0/0 7/28 2/8 0/0 10/50

41. 41/39
Appendix A
▪ Effectiveness of TA_SDLC
• Comparative analysis with UNECE regulation requirements
✓ We mapped a total of 16 requirements of UNECE regulation related to the
development process to each TA_SDLC activity.
✓ TA_SDLC can be used for certification of the UNECE regulation.
UNECE regulation requirements (7.2. Requirements for the CSMS(Cyber Security Management System)) TA_SDLC activities(activity number)
1 The vehicle manufacturer shall have a CSMS in place and shall comply with this Regulation. Total
2 The vehicle manufacturer shall demonstrate that their CSMS applies to the development phase. Total
3 CSMS shall include the processes used within the manufacturer’s organization to manage cyber security. Total
4 CSMS shall include the processes used for the identification of risks to vehicles. 3.1.1/3.1.2/5.2.1/ 5.2.3
5 CSMS shall include the processes used for the assessment, categorization and treatment of the risks identified. 5.2.2/5.2.3
6
The vehicle manufacturer shall demonstrate how their CSMS will manage dependencies that may exist with contracted suppliers, service providers
or manufacturer’s sub-organizations.
4.1.1/4.1.2/4.2.1
7 CSMS ensure security shall include the processes used for testing the cyber security of a vehicle. 7.1.1/7.1.2/7.1.3/7.1.4
8 CSMS ensure security shall include the processes in place to verify that the risks identified are appropriately managed. 7.2.1/9.1.1/9.1.2/9.3.1
9 The vehicle manufacturer shall demonstrate that their CSMS applies to the production phase. 8.1.1/8.1.2/8.1.3
10
The vehicle manufacturer shall demonstrate that the processes that include the capability to analyze and detect cyber threats, vulnerabilities and
cyber-attacks from vehicle data and vehicle logs.
9.1.1/9.1.2/9.2.1
11 CSMS shall include the processes used for ensuring that the risk assessment is kept current. 9.2.4/9.3.1
12 CSMS shall include the processes used to monitor for, detect and respond to cyber-attacks, cyber threats and vulnerabilities on vehicles. 9.1.1/9.1.2/9.2.1/9.2.2/9.2.3/9.2.4/9.3.1
13
CSMS shall include the processes used to assess whether the cyber security measures implemented are still effective in the light of new cyber
threats and vulnerabilities that have been identified.
7.2.1/9.2.3
14
The vehicle manufacturer shall demonstrate that the processes used within their CSMS will ensure that cyber threats and vulnerabilities which
require a response from the vehicle manufacturer shall be mitigated within a reasonable timeframe.
9.2.1/9.2.2/9.2.3/9.2.4
15 The vehicle manufacturer shall demonstrate that the processes that include vehicles after first registration in the monitoring. 9.1.1/9.1.2
16 The vehicle manufacturer shall demonstrate that their CSMS applies to the post-production phase.
8.1.1/8.1.2/8.1.3/8.2.1/8.3.1/9.1.1/9.1.2/9.2.1/9.2.2/9.2.
3/9.2.4/9.3.1/10.1.1/10.2.1

42. 42/39
Appendix B
▪ TA_SDLC Requirements
• A total of 4 requirements of TA_SDLC were derived.
✓ They were selected based on the characteristics of automotive development.
※ Third-party component: components developed and utilized
by other companies
Hardware Software
System
OEMs do not develop all components of a vehicle on
their own but acquire components from partners such as
1-tier and 2-tier.
① Targets on a system(Software and
Hardware)
② Includes the procedure of third-party
components acquisition
① Targets on system
② Includes the procedure of third-party components acquisition
③ Ensures traceability between phases
④ Provides detailed activities and the evidence templates for every phase of the
process(depth=2)

43. 43/39
Appendix B
▪ TA_SDLC Requirements
• A total of 4 requirements of TA_SDLC were derived.
✓ They were selected based on the characteristics of automotive development.
※ Traceability: To ensure consistency in the results between
phases so that we can trace back to the initial cause when a
security problem occurs
※ Depth: Indicators for the degree of activities detail defined
in this study
Depth = 0
Depth = 1
Depth = 2
Verification
Implemen-
tation
Design
Requirements
Analysis
Operation
Traceability
Problem
occurs
③ Ensures traceability between phases ④ Provides detailed activities and the
evidence templates for every phase of
the process(depth=2)
① Targets on system
② Includes the procedure of third-party components acquisition
③ Ensures traceability between phases
④ Provides detailed activities and the evidence templates for every phase of the
process(depth=2)

44. 44/39
Appendix C
▪ Trustworthiness
• Functional Correctness + Safety Integrity + Security Assurance
• Functional Correctness
✓ The product operates exactly as designed
• Safety Integrity
✓ Errors that occur inside the product are not exposed externally and can harm
users
• Security Assurance
✓ confidentiality: authorized users only have access to information assets of the
system
✓ integrity: the system is fully preserved without inappropriate change or
destruction of information
✓ availability: access to and use of system information at any time users want
C IFunctional
Safety =
Functional
Correctness +
Safety
Integrity
A
Security
Assurance
=
Confidentiality
+
Integrity
+
Availability
= + +