27. 고려대학교정보보호대학원
마스터 제목 스타일 편집
27
Recent suggestions that the fleet is vulnerable have
sometimes been met with complacency and claims
that the isolated 'air-gapped' systems cannot be
penetrated. Whilst we recognise that it is important
not to be alarmist, these claims are false.
28. 고려대학교정보보호대학원
마스터 제목 스타일 편집
28
Malware injection during manufacturing(a.k.a
supply chain), mid-life refurbishment or software
updates and data transmission interception allow
potential adversaries to conduct long-term cyber
operations.
32. 고려대학교정보보호대학원
마스터 제목 스타일 편집
32
사이버작전수행에 직접 운용되거나
훈련용으로 운용하는 장비, 부품,
소프트웨어 등으로서, 사이버영역의
감시·정찰, 사이버작전 지휘통제 및 능동적
대응을 위한 장비·부품·소프트웨어 또는
사이버전 훈련을 위해 운용되는
모의공격체계, 모의훈련모델, 훈련용
장비·시설 등
(출처 : 국방사이버안보훈령)
사이버무기란?
33. 고려대학교정보보호대학원
마스터 제목 스타일 편집
33
네트워크와 연결된 모든 무기체계
C4I 등의 전술지휘자동화체계, 무인기(UAV :
Unmanned Aerial Vehicle) 및 군 위성통신체계,
위성전군방공경보체계, 해상작전위성통신체계
등과 같은 통신체계, 그리고
전술용전자식교환기, 야전용전화기,
휴대용·차량용 FM/AM 무전기 등 각종 유·무선
통신장비 및 연습훈련용·분석용· 획득용 워게임
모델 및 전술훈련모의장비 등이 모두 이에
포함됨.
(출처 : 국방사이버안보훈령의 사이버무기체계 세부분류)
다른 말로, 사이버무기란?
36. 고려대학교정보보호대학원
마스터 제목 스타일 편집
36
The key strategy is to upgrade weapon systems to qualify as
High-Assurance Cyber Military Systems (HACMS),
strategically designed to better withstand a cyber attack.
40. 고려대학교정보보호대학원
마스터 제목 스타일 편집
40
Robustness
Strength
Assurance
Assurance (in a narrow sense)
41. 고려대학교정보보호대학원
마스터 제목 스타일 편집
41
Physical Security Era
Communication Security (COMSEC) Era
Computer Security (COMPUSEC) Era (Early
1960s~)
Information Security (INFOSEC) Era (1980s~)
Information Assurance (IA) Era (1998 ~)
Etc : Operational Security (OPSEC)
Assurance (in a broader sense)
42. 고려대학교정보보호대학원
마스터 제목 스타일 편집
42
The first standardized definition of IA
was published in U.S. DoD Directive 5-
3600.1 in 1996.
The 1991 Gulf War has often been
called the first information war. In many
ways, the Gulf War was the harbinger of
IA.
Assurance (in a broader sense)
46. 고려대학교정보보호대학원
마스터 제목 스타일 편집
46☞ Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, “Basic
Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Transactions on
Dependable and Secure Computing, VOL.1, NO.1, 2004.
(Trustworthiness)
Assurance (in a broader sense)
47. 고려대학교정보보호대학원
마스터 제목 스타일 편집
47
Trustworthiness (or Dependability) is
assurance that a system deserves to be
trusted - that it will perform as expected
despite environmental disruptions,
human and operator error, hostile
attacks, and design and
implementation errors. Trustworthy
systems reinforce the belief that they will
continue to produce expected behaviour
and will not be susceptible to subversion.
Assurance (in a broader sense)
☞ The "Trust in Cyberspace" report of the United States National Research Council
48. 고려대학교정보보호대학원
마스터 제목 스타일 편집
48☞ Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, “Basic
Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Transactions on
Dependable and Secure Computing, VOL.1, NO.1, 2004.
(Trustworthiness)
Independent? No, Interdependent!
Assurance (in a broader sense)
56. 고려대학교정보보호대학원
마스터 제목 스타일 편집
56
Considering security as early as the
design phase of the software
development process.
Security by Design (in a narrow sense)
☞ Michael Waidner, Michael Backes, Jörn Müller-Quade, "Development of Secure Software
with Security By Design", Fraunhofer SIT Technical Reports, July 2014
57. 고려대학교정보보호대학원
마스터 제목 스타일 편집
57
Systematically organized and
methodically equipped framework that is
applied over the lifecycle of secure
software.
(e.g.) Embedding of secure SW development
at governance level, individual security
processes for the SW's lifecycle phases, and
security analyses of SW components
integrated from other manufacturers.
Security by Design (in a broader sense)
☞ Michael Waidner, Michael Backes, Jörn Müller-Quade, "Development of Secure Software
with Security By Design", Fraunhofer SIT Technical Reports, July 2014
58. 고려대학교정보보호대학원
마스터 제목 스타일 편집
58
Security engineering is about building
dependable (or trustworthy) embedded
systems.
Security Engineering (보안공학)
☞ ‘Dependability’ is interchangeably used for ‘trustworthiness’
(Sommerville, I.: "Software Engineering", Addison-Wesley, 6. edn., 2001, ISBN 0-201-39815-X)
59. 고려대학교정보보호대학원
마스터 제목 스타일 편집
59
Financial System
High security + Medium reliability + No safety
DB of Medical Records
Medium security + Medium reliability +
Medium safety
Air Traffic Control System
Medium security + High reliability + High safety
Automobile
Low (but now medium!) security +
High reliability + High safety
Security Engineering (보안공학)
61. 고려대학교정보보호대학원
마스터 제목 스타일 편집
61
”Our company has recruited a lot
of hackers and done lots of
pentesting, but we do not know
if the quality of our product is
really improving.”
62. 고려대학교정보보호대학원
마스터 제목 스타일 편집
62
”Our company has recruited a lot
of hackers and done lots of
pentesting, but we do not know
if the quality of our product is
really improving.”
Can't Guarantee Coverage!
63. 고려대학교정보보호대학원
마스터 제목 스타일 편집
63
Cryptography v.s Cryptanalysis
Cryptology :
science of secret
communication
Cryptography :
design secret
systems
Cryptanalysis :
break secret
systems
64. 고려대학교정보보호대학원
마스터 제목 스타일 편집
64
Security Engineer : Like to fix systems.
Security engineers are more intend on
building robust security solutions
(Firewalls, IDS, etc.).
Similar Jobs : Information Assurance
Engineer, Information Security Engineer,
Information System Security Engineer
Security Analyst : Try to break them.
Security analysts are more concerned
with probing for risks and weaknesses
(Pentesting, Auditing, etc.).
Security Engineering (보안공학)
66. 고려대학교정보보호대학원
마스터 제목 스타일 편집
66
(☞ Paul Curran, “Cyber Security Today: Career Paths, Salaries and In-Demand Job Titles”, Aug 30, 2016)
Security Engineering (보안공학)
67. 고려대학교정보보호대학원
마스터 제목 스타일 편집
67
1. Define "goals" or "properties" (i.e., what
you want the program to satisfy)
2. Design algorithms/protocols
3. Make standards
4. Generate source code
5. Compile to machine code (i.e., what
actually runs)
5 Steps for Developing Dependable S/W
68. 고려대학교정보보호대학원
마스터 제목 스타일 편집
68
☞ "Cost Effective Use of Formal Methods in Verification and Validation"
Policy (= a set of requirements) Assurance
Design Assurance
Implementation/Operational Assurance
Implementation/Operational Assurance
69. 고려대학교정보보호대학원
마스터 제목 스타일 편집
69
☞ "Cost Effective Use of Formal Methods in Verification and Validation"
Policy (= a set of requirements) Assurance
Design Assurance
Implementation/Operational Assurance
Implementation/Operational Assurance
Chain of Evidence!
70. 고려대학교정보보호대학원
마스터 제목 스타일 편집
70
☞ Daniel Jackson et al., "Software for Dependable Systems: Sufficient Evidence?"
Policy (= a set of requirements) Assurance
Design Assurance
Implementation/Operational Assurance
Implementation/Operational Assurance
Then, don’t need pentesting?
71. 고려대학교정보보호대학원
마스터 제목 스타일 편집
71
Policy (= a set of requirements) Assurance
Design Assurance
Implementation/Operational Assurance
Implementation/Operational Assurance
Testing is indispensable, and no software system
can be regarded as dependable if it has not been
extensively tested, even if its correctness has been
proven mathematically.
☞ Daniel Jackson et al., "Software for Dependable Systems: Sufficient Evidence?"
72. 고려대학교정보보호대학원
마스터 제목 스타일 편집
72
Policy (= a set of requirements) Assurance
Design Assurance
Implementation/Operational Assurance
Implementation/Operational Assurance
Testing may find flaws that elude analysis because it
exercises the system in its entirety, whereas analysis
must typically make assumptions about the
execution platform, the external environment, and
operator responses, any of which may turn out to
be unwarranted.
☞ Daniel Jackson et al., "Software for Dependable Systems: Sufficient Evidence?"
73. 고려대학교정보보호대학원
마스터 제목 스타일 편집
73
Policy (= a set of requirements) Assurance
Design Assurance
Implementation/Operational Assurance
Implementation/Operational Assurance
At the same time, it is important to realize that
testing alone is rarely sufficient to establish high
levels of dependability. It is erroneous to believe
that a rigorous development process, in which
testing and code review are the only verification
techniques used, justifies claims of extraordinarily
high levels of dependability.
☞ Daniel Jackson et al., "Software for Dependable Systems: Sufficient Evidence?"
74. 고려대학교정보보호대학원
마스터 제목 스타일 편집
74
1. Define "goals" or "properties" (i.e.,
what you want the program to satisfy)
How to identify and define goals correctly?
By using “Threat Modeling” & “Security Policy
Modeling (SPM)”
Problems for STEP 1.
83. 고려대학교정보보호대학원
마스터 제목 스타일 편집
83
2. Design algorithms/protocols
How to check if your algorithm or protocol satisfy
the goals of STEP 1?
By “hand-proof” or “machine-checked proof”
Problems for STEP 2.
84. 고려대학교정보보호대학원
마스터 제목 스타일 편집
84
Needham-Schroeder public-key
authentication protocol (1978), which
was believed secure for 17 years before
Lowe discovered it was affected by a
flaw such as replay attack (1995).
[Note] Why Design Assurance?
86. 고려대학교정보보호대학원
마스터 제목 스타일 편집
86
Security proofs give the guarantee that
the assumption is enough for security :
if an adversary can break the security of
algorithm/protocol
one can break the assumption
⇒ “reductionist” proof
How to Get Design-Proof
90. 고려대학교정보보호대학원
마스터 제목 스타일 편집
90
3. Make standards
There might be specification mismatch between
STEP 2 and STEP 3.
We need equivalence proof to address the "gap"
between the abstract algorithm/protocol and
more concrete standard specification
Problems for STEP 3.
91. 고려대학교정보보호대학원
마스터 제목 스타일 편집
91
4. Generate source code and compile it
into machine code
Problems for STEP 4 ~ STEP5.
Program might incorrectly implement the standard
of STEP 3.
Also, we can’t be sure about the compiler!
By using machine-checked proof tools such as
“Verified Software Toolchain”.
95. 고려대학교정보보호대학원
마스터 제목 스타일 편집
95
How to Get Code-Proof
☞ Symposium Celebrates Ed Clarke and Model Checking, CMU, September 2014
96. 고려대학교정보보호대학원
마스터 제목 스타일 편집
96
How to Get Code-Proof
☞ 차상길, "바이너리 분석을 통한 자동 익스플로잇 생성: 과거, 현재, 그리고 미래", SECUINSIDE 2016
97. 고려대학교정보보호대학원
마스터 제목 스타일 편집
97
How to Get Code-Proof
☞ Aaron Tomb (Galois, Inc), "Assuring Crypto Code with Automated Reasoning",
QCon, London, March 2017
98. 고려대학교정보보호대학원
마스터 제목 스타일 편집
98
How to Get Code-Proof
DES standard DES binary code
- Equivalence-checking
- Safety-checking
(e.g.) SAW with ABC (which uses SAT)
Z3 (which uses SMT)
Verified Software Toolkit (VST)
(Reference Model)
(☞ Aaron Tomb, "Automated Verification of Real-World Cryptographic Implementations“)
Symbolic Execution (for
constructing mathematical
models of SW)
(e.g.) Cryptol, Z, etc.
99. 고려대학교정보보호대학원
마스터 제목 스타일 편집
99
Equivalence-Checking : Checks whether
two functions, f and g, agree on all
inputs
Safety-Checking : Checks run-time
exceptions. Given a function f, we would
like to know if f's execution can perform
operations such as division by zero or
index out of bounds.
How to Get Code-Proof
☞ David A. Ramos and Dawson R. Engler, "Practical, Low-Effort Equivalence Verification
of Real Code", CAV 2011 : This shows a technique for performing a semantic equivalence
verification of new implementations vs reference implementations using a modified version of KLEE.
100. 고려대학교정보보호대학원
마스터 제목 스타일 편집
100
[Note] How to Link Model with Prog.
☞ Matteo Avalle, Alfredo Pironti, Riccardo Sisto, "Formal Verification of Security Protocol
Implementations: a Survey", Formal Aspects of Computing, January 2014.
101. 고려대학교정보보호대학원
마스터 제목 스타일 편집
101
Several famous theorems (particularly
Gödel’s incompleteness theorem and
Rice’s theorem) imply that it’s
impossible to write a program that can
always construct a proof of some
arbitrary theorem (or some arbitrary
property of a piece of software). Because
of these theoretical limits, automated
proof is no panacea.
In practice, however, cryptographic code
contains characteristics that make many of
its properties easier to prove.
[Note] The Limits of Automated Proof
102. 고려대학교정보보호대학원
마스터 제목 스타일 편집
102
Haskell based DSL (Domain-Specific
Language) for writing crypto-algorithms
DSL : Programming language targeted at
producing solutions in a given problem
domain by enabling subject-matter experts
to design solutions in terms they are
familiar with and at a level of abstraction
that makes most sense to them
Cryptol
☞ Lewis JR, Martin B., "Cryptol: High-Assurance, Retargetable Crypto Development and
Validation", MILCOM 2003
103. 고려대학교정보보호대학원
마스터 제목 스타일 편집
103
Created by Galois Inc. with support from
NSA
Cryptol specifications can be used to
verify various implementations
C code, VHDL, etc.
Cryptol
☞ Lewis JR, Martin B., "Cryptol: High-Assurance, Retargetable Crypto Development and
Validation", MILCOM 2003
108. 고려대학교정보보호대학원
마스터 제목 스타일 편집
108
1. Define "goals" or "properties" (i.e., what
you want the program to satisfy)
2. Design algorithms/protocols
3. Make standards
4. Generate source code
5. Compile to machine code (i.e., what
actually runs)
Assurance Levels
In many cases, "provable security in cryptography" means only "design assurance"!
i.e., the proposed algorithm/protocol satisfies certain security requirements
109. 고려대학교정보보호대학원
마스터 제목 스타일 편집
109
1. Define "goals" or "properties" (i.e., what
you want the program to satisfy)
2. Design algorithms/protocols
3. Make standards
4. Generate source code
5. Compile to machine code (i.e., what
actually runs)
Assurance Levels
Common Criteria, even at EAL7, relies on testing (not mathematical proof!). There is no proof that
security properties hold for the actual implementation (i.e., code proof).
110. 고려대학교정보보호대학원
마스터 제목 스타일 편집
110
1. Define "goals" or "properties" (i.e., what
you want the program to satisfy)
2. Design algorithms/protocols
3. Make standards
4. Generate source code
5. Compile to machine code (i.e., what
actually runs)
Assurance Levels
We call this as “High-Assurance (End-to-End Provably) Dependable Systems”
(e.g.) DARPA’s HACMS(Hisg-Assurance Cyber Military Systems) Program, NICTA’s seL4 Microkernel, etc
112. 고려대학교정보보호대학원
마스터 제목 스타일 편집
112
Mathematical proofs are best! But if it is
not achievable, we should follow the
well-defined software development
processes!!
(e.g.) Microsoft’s SDL(Security Development
Lifecycle)
If It is Not Provable…
116. 고려대학교정보보호대학원
마스터 제목 스타일 편집
116
Green Books
1989
IT-Security
Criteria
1989
Blue-White-Red
Book
1989
Orange Book
(TCSEC) 1985미 국
영 국
독 일
프랑스
Canadian Criteria
(CTCPEC) 1993
U.S. Federal Criteria
Draft 1993
캐나다
European
ITSEC (1991)
※ 1999년 : ISO/IEC 15408 국제 표준으로 제정
v1.0 1996
v2.0 1998
v2.1 1999
v2.2 2004
v2.3 2005
v3.1 R1 2006.9
v3.1 R2 2007.9
Netherlands
Criteria
1989네덜란드
CC (Common Criteria) Evaluation
117. 고려대학교정보보호대학원
마스터 제목 스타일 편집
117
기능 요구사항
보안 문제
보안목적
기능명세
설계 설명
구현 표현
구현
TOE 요약명세
정책 모델
A B
A B
A가 B에 대응 (요구사항에 따라)
A가 B로 상세화
ASE_TSS
ADV_SPM
APE/ASE_OBJ
APE/ASE_REQ
ADV_FSP
ADV_TDS
ADV_IMP
ALC_CMC.5 ATE_AVA
모든 설계 분해 단계에서
수행된 상호 보완적인 분석
구현 시 수행된 기능 시험
및 침투 시험
보안문제,
보안기능요구사항(SFR)과
보안목적 간 일치성에 대한
요구사항을 정의
TOE 요약명세에 대한 요구사항을
정의
시험클래스와 취약성 평가 클래스에서
시험된 TSF가 개발 클래스의 분해 단계에서
모두 서술된 사항임을 검증
선택된 SFR을 정형화하여
모델링하고, 이 정형화된 모델과
기능명세간의 일치성 제공에 대한
요구사항 정의
기능명세, 설계, 구현에 해당하는 각
표현을 기능요구사항에 정의
CC (Common Criteria) Evaluation
118. 고려대학교정보보호대학원
마스터 제목 스타일 편집
End-to-
End Proof
High-Assurance
Cyber System
Scope, Depth,
Rigor
CC (Common Criteria) Evaluation
119. 고려대학교정보보호대학원
마스터 제목 스타일 편집
119
NSTISSP #11 Guidance IA & IA-Enabled Products
NSA Involvement in
Product Evaluation
NSA Evaluated Product List
NIAP - Certified
CCTL Evaluations
FIPS evaluated
under CMVP
(FIPS 140-1 or 140-2)
Validated Product List
http://csrc.nist.gov/cryptval
Type 1 Crypto
for Classified
Level1Level2Level3Level4
EAL
Basic
robustness
products
Medium
robustness
products
High
robustness
products
4
7
6
5
3
2
1
0
4+
CMVP Labs
• Atlan
• Cygnacom (CEAL)
• CoACT
• EWA
• Domus
• InfoGard
NIAP Labs
• Booz Allen
Hamilton
• Cable & Wireless
• CoACT
• Criterian
Levels Of
Robustness
Crypto Modules and Algorithms
• CSC
• Cygnacom
• InfoGard
• SAIC
IT Products and PP
CC (Common Criteria) Evaluation