56
IEC- 62645 반영
IEC- 62645 반영
2
목차
• 1. 개요
– Cyber Security Scenario
– Target
• 2. 적용
– 할일 & 해결방안
• 1. Security Requirement 작성
• 2. Design에 반영
• 3. Safety와 간섭 여부 확인
• 4. 최종 시스템의 Security Requirement 확인
• 3. 결론
3
Target • KNICS (Korea Nuclear Instrumentation & Control System)
– 원자력 계측제어 시스템
• ESF-CCS
– 공학적안전설비-기기제어계통
4
Target • KNICS (원자력 계측제어 시스템)
– 원자력 발전소의 두뇌와 신경망에 해당
– 원자력 발전소의 안전 운전을 보장하고 사고예방에 필수적인 시스템
– 발전소에 중대한 결함이 발생할 경우 신속하게 제어봉의 작동을 중지시켜 원자로를 안전하게 정지
5
KNICS
6
Target • ESF-CCS
– 공학적안전설비-기기제어계통
• 입력 – 발전소 보호계통(PPS) – 방사선 감시계통(RMS) – 운전원의 수동작동 신호
• 기능
– 공학적안전설비 작동 • 1. 안전주입작동 (SIAS) • 2. 격납용기격리작동 (CIAS) • 3. 주증기격리작동 (MSIS) • 4. 격납용기살수작동 (CSAS) • 5. 보조급수작동 (AFAS) • 6. 주제어실비상환기작동 (CREVAS) • 7. 핵연료취급지역 비상환기작동 (FHEVAS) • 8. 격납용기퍼지격리작동 (CPIAS)
– 정보제공 • MCR, RSR, COM에 정보 Display
7
ESF-CCS 특징 • 작동논리계통 기능을 그룹제어기(GC, Group Controller)로, • 기기제어계통 기능을 루프제어기(LC, Loop Controller)로 구성하고 이를
통합한 구조
• 그룹제어기를 삼중화하여 오작동 개선
• 루프제어기에 다중루프(Multi-Loop) 제어기를 적용
• 채널 내부 및 채널간 모든 연계에 데이터 통신방식을 적용
• 온-라인 자가진단과 자동시험 기능을 강화
• 설계 및 제작 전 과정에 걸쳐 확인 및 검증 절차 수행
• 안전성 및 가동성을 고려한 루프제어기 기기할당
• 디지털 기기의 공통유형고장에 대비한 공학적안전설비 수동작동 기능 보유
8
KNICS
Target
ESF-CCS
9
Division - 4
10
ESF-CCS (Division A)
GC 2
N-to-N Data Network
LC 1
CIM
LC 2
CIM
LC 12
GC 1
COM
Diverse Manual
Minimum Inventory
Manual Actuation
Manual Actuation
CPM
MCR RSR
CCG
SOFT- CNTR1
SOFT- CNTR18
SOFT- CNTR1
SOFT- CNTR4
PPS (IC)
CS
SOFT-CNTR CS (HR-SDL)
RMS
Hard-Wired
P-to-P Data Link
IPS NET QIAS-N NET B,C,D Division
ETIP
CPM
PPS IC
CS CS CS
LOOP CONTROL NET (HR-SDN)
INTRA-DIVISION NET (FMS)
From DPS
PPS (ATIP)
HR-SDL
FMS
GC 3
PPS IC
CIM
11
ESF-CCS (PLC)
GC1
COM GC2
GC3
CCG
ETIP LC3
LC4
LC1
LC2
CIM
12
공극 전략 (Air Gap)
13
공극 전략 (Air Gap)
14
Cyber Security - NPP
• Cyber Security
– 아날로그 -> 디지털 (안전계통)
– 발전소 상태의 실시간 데이터 획득을 위한 통신 접속이 늘어남에 따라 (비안전계통)
• 2003년 9월 미국 데이비드 베쎄 원전 통신망 – 비 안전계통 지속적으로 이상 신호 발생시킴으로써 발전소 가동 중단
침해 사례
적용
16
적용
• 할일
– 1. Security Requirement 작성
• 적절한 방법론을 이용
– Zone, Degree 할당
– 2. Design 에 반영 여부
• Trace
• V&V
– 3. Security와 Safe와의 간섭 여부
• V&V
– 4. 최종 시스템에 Security Requirement의 V&V
17
적용
• 할일
– 1. Security Requirement 작성
• 적절한 방법론을 이용
– Zone, Degree 할당
– 2. Design 에 반영 여부
• Trace
• V&V
– 3. Security와 Safe와의 간섭 여부
• V&V
– 4. 최종 시스템에 Security Requirement의 V&V
1
2
3
4
해결 방법
Zone, Degree를 주관적인 기준을 가지고 분류
분석가의 Inspection - 요구사항 추적 매트릭스 작성을 통한
Inspection - Requirement 중심의 system modeling을 통
한 분석
- Equivalence Checking
- 전문가에 의한 Inspection
Test - Security test case generation Simulation - Use case, Misuse case 작성을 후 simulation
1. SECURITY REQUIREMENT 작성
19
Security Requirement
• IEC-62645
– Graded Approach
– Zone -> Security Degree -> Security Requirement
– 설정
• Zone
• Security Degree
• Security Requirement
20
Zone
• Zone
– Zone에 대해서는 물리적 논리적 비슷한 역할 또는 등급을 가질 수 있는 부분을 하나의 zone으로 설정하기를 제시
– 비슷한 수준의 protective measures가 요구되는 경우 하나의 zone으로 설정
21
ESF-CCS
22
Zone Monitoring Control
Room
Remote Shutdown
Room
시험
Display
Core Process
23
Degree
• Degree
– IEC-6264 는 IEC-60880에서 분류한 degree(category A, B, C Function)를 이용하여 Security Degree를 할당하는 것을 제시
– 현재 I&C에 대한 자산 분석 프로세스(RG 5.71, 기타 논문)는 존재하지만 Device 속의 Module or Component에 대한 degree 할당 방법은 존재하지 않음
– 그래서! 찾거나 만들어야 겠다
• I&C의 Cyber 공격의 결과가 계통의 safety에 영향을 미치는 정도
– 계통의 핵심 기능과 관련된 Core Module – S1
– 계통의 정보 표현 관련된 Display Module – S2
– 계통의 시험 및 보조와 관련된 Testing Module – S3
26
Zone Monitoring Control
Room
Remote Shutdown
Room
시험
Display
Core Process
27
Degree 기준 계통의 핵심 기능과 관련된 Core Module – S1 계통의 정보 표현 관련된 Display Module – S2 계통의 시험 및 보조와 관련된 Testing Module – S3
28
Requirement 작성
1. Business Requirement
2. Technical Requirement
3. Security Requirement
29
Z1(Core Process) - GC (S1)
1. Business Requirement 1. PPS와 RMS에서 신호를 받아 2/4, 1/2 voting process를 수행 후 LC에 결과
값은 전달한다. 2. 주기적인, 운전자에 의한 수동 시험을 통해 계통의 건전성을 유지한다.
2. Technical Requirement 1. S1 등급에 요구되는 requirement
3. Security Requirement 1. 해당 device의 특징, 상황 등을 이용
1. PLC 1. Upgrade 시 지정된 장비를 사용 2. 지정된 장비에 pSet 이외에 다른 프로그램 설치 X 3. 자동 업데이트 X
2. Network 1. MCR -> GC (Profibus-FMS): Manual signal 의 경우 인가된 운전원에 의한 신호인지
개인키를 이용하여 확인 한다. 2. PPS -> GC (HR-SDN): DDos 공격 를 막기 위해 통신시 일정한 주기를 가지고 통신을
유지한다. 3. ATIT -> GC (Profibus-FMS) : 한 Division이 test 중인 경우 타 Division의 test를 수행하
지 않도록 한다.
3. Real Time System
a. S1 system의 경우 networked links 는 다른 S1이나 S2 만 연결이 되어야 한다.
b. Communications 은 S1에서 S2로만 되어야 한다. c. S2에서 S1으로의 Data translation 은 최대 한도를 제한
해야 한다. 어쩔 수 없는 전송 (e.g. permissive) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
d. S2에서 S1으로 전송되는 모든 data 는 static provisions 적용에 의해 보호되어야 한다.
e. Software Upgrade는 반드시 local로 이루어져야 한다.(한번에 한 channel 만 이용해야 한다.)
f. 시스템 소프트웨어의 숨겨진 기능에 대한 규정이 있어야 한다. (e.g., software code verification)
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
30
Z1(Core Process) - LC (S1)
1. Business Requirement
1. GC에서 신호를 받아 2/3 voting process를 수행 후 결과값은 CIM에 전달한다.
2. 주기적인, 운전자에 의한 수동 시험을 통해 계통의 건전성을 유지한다.
3. Division 간의 박동신호를 검사한다.
2. Technical Requirement
1. S1 등급에 요구되는 requirement
3. Security Requirement
1. 해당 device의 특징, 상황 등을 이용
1. PLC
1. Upgrade 시 지정된 장비를 사용
2. 지정된 장비에 pSet 이외에 다른 프로그램 설치 X
3. 자동 업데이트 X
2. Network
1. GC-> LC : DDos 공격 를 막기 위해 통신시 일정한 주기를 가지고 통신을 유지한다.
2. ATIT -> LC : 한 Division이 test 중인 경우 타 Division의 test를 수행하지 않도록 한다.
a. S1 system의 경우 networked links 는 다른 S1이나 S2 만 연결이 되어야 한다.
b. Communications 은 S1에서 S2로만 되어야 한다. c. S2에서 S1으로의 Data translation 은 최대 한도를 제한
해야 한다. 어쩔 수 없는 전송 (e.g. permissive) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
d. S2에서 S1으로 전송되는 모든 data 는 static provisions 적용에 의해 보호되어야 한다.
e. Software Upgrade는 반드시 local로 이루어져야 한다.(한번에 한 channel 만 이용해야 한다.)
f. 시스템 소프트웨어의 숨겨진 기능에 대한 규정이 있어야 한다. (e.g., software code verification)
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
31
Z1(Core Process) - CIM
1. Hardware 기반이므로 제외
1. 각 디비젼의 현장기기 출력단에는 루프제어기 출력, 다양성 ESF 수동작동 신호 및 다양성보호계통으로부터의 보조급수 작동신호를 OR 할 수 있는 현장기기 연계모듈이 제공되어야 한다. 현장기기 연계모듈은 소프트웨어적인 기능을 배제한 하드웨어 근간의 게이트들로 구성되어야 한다.
2. 현장기기 연계모듈은 디지털 공통모드고장에 대비한 제어실의 다양성 ESF 수동작동신호 및 다양성보호계통으로부터 실배선으로 전송되는 보조급수작동 신호의 접속 기능을 수행해야 하므로, 소프트웨어적인 기능을 배제한 하드웨어근간의 게이트들로 구성되어야 한다.
32
Z2(MCR), Z3(RSR) - CPM (S2)
1. Business Requirement
1. 최소재고량 관련 기기에 대한 제어신호를 받아 디지털화 및 다중화 하여 LC에 전송
2. MCR, RSR의 채널 선택 신호를 받아 CCG로 전송
2. Technical Requirement
1. S2 등급에 요구되는 requirement
3. Security Requirement
1. 해당 device의 특징, 상황 등을 이용
a. Communications 은 S2에서 S3로만 되어야 한다. b. S3에서 S2으로의 Data translation 은 최대 한도를 제한
해야 한다. 어쩔 수 없는 전송 (e.g. permissives) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
c. Software Upgrade는 반드시 S3에서 가능하게 하면 안 된다.
d. S2의 Upgrade는 반드시 한번에 한 채널만 가능하게 해야 한다.
e. S2의 access는 권한이 없는 사람의 접근을 가능하게 하면 안된다.
f. I&C 이외의 IT System과의 communication은 case by case로 제약을 두어야 한다. 모든 원격 communication은 제한되어야 한다.
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
33
Z2(MCR) – SOFT CONTROL(S2)
1. Business Requirement
1. 소프트제어기는 제어실의 정보 표시화면과 연동하여 공학적안전설비-기기제어계통의 모든 개별기기에 대한 제어 수단을 제공할 수 있어야 한다.
2. 소프트제어기의 개별기기 제어신호는 소프트제어망을 통해 제어채널 게이트웨이로 입력되고 운전원의 채널선택 신호를 확인한 후 루프제어망을 통하여 해당 루프제어기에 입력되어야 한다.
2. Technical Requirement
1. S2 등급에 요구되는 requirement
3. Security Requirement
1. 해당 device의 특징, 상황 등을 이용
1. Network
1. SOFT CONTROL -> CCG :
a. Communications 은 S2에서 S3로만 되어야 한다. b. S3에서 S2으로의 Data translation 은 최대 한도를 제한
해야 한다. 어쩔 수 없는 전송 (e.g. permissives) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
c. Software Upgrade는 반드시 S3에서 가능하게 하면 안 된다.
d. S2의 Upgrade는 반드시 한번에 한 채널만 가능하게 해야 한다.
e. S2의 access는 권한이 없는 사람의 접근을 가능하게 하면 안된다.
f. I&C 이외의 IT System과의 communication은 case by case로 제약을 두어야 한다. 모든 원격 communication은 제한되어야 한다.
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
34
Z4(시험관련) - ETIP(S3)
1. Business Requirement 1. 일정 시간마다 GC와 LC의 논리를 자동으로, 운전원의 요구에 의해 수동으
로 시험을 수행할 수 있는 기능을 제공해야 한다. 결과의 피드백을 통해 계통의 건전선을 평가 가능하게 해야 한다.
2. 다음과 같은 상황에서는 시험을 개시하지 않아야 한다. 1. 공학적안전설비 개시신호 발생 2. 공학적안전설비 작동신호 발생 3. 그룹제어기 및 루프제어기의 하드웨어 오류 발생 4. 자체 하드웨어 오류 발생 5. 타 디비젼이 시험 중이거나 타 디비젼의 시험 및 연계 프로세서 오류 발생
2. Technical Requirement 1. S3 등급에 요구되는 requirement
3. Security Requirement 1. 해당 device의 특징, 상황 등을 이용
1. PLC 1. Upgrade 시 지정된 장비를 사용 2. 지정된 장비에 pSet 이외에 다른 프로그램 설치 X 3. 자동 업데이트 X
2. Network 1. ATIP > ETIP : DDos 공격 를 막기 위해 통신시 일정한 주기를 가지고 통신을 유지한다. 2. ETIP -> GC : 한 Division이 test 중인 경우 타 Division의 test를 수행하지 않도록 한다. 3. ETIP -> LC : ‘’
a. Plant 외부에서 원격 접근은 case-by-case로 제한해야 한다.
b. 권한이 없는 사람으로부터의 S3의 물리적 접근은 막아야한다.
c. 보안 log를 정기적으로 확인해야 한다.
35
Z5(Display관련) - COM(S2)
1. Business Requirement 1. 디비젼 내 모든 제어기의 상태정보, 현장 기기에 대한 상태 정보 및 시험에
대한 결과를 입력받아 운전원에게 제공해야한다.
2. 운전원에 의한 시험 지원 기능을 제공해야 한다.
3. 운전화면은 안전기준 및 인간공학적 기준에 따라 운전원이 쉽게 인지하고 정보의 접근이 용이하도록 설계되어야 한다.
2. Technical Requirement 1. S2 등급에 요구되는 requirement
3. Security Requirement 1. 해당 device의 특징, 상황 등을 이용
1. PLC 1. Upgrade 시 지정된 장비를 사용
2. 지정된 장비에 pSet 이외에 다른 프로그램 설치 X
3. 자동 업데이트 X
2. Network 1. ETIP, GC, LC -> COM (Profibus-FMS): 각각의 data를 암호화해 외부로의 유출이 불가
능 하게 해야 한다.
a. Communications 은 S2에서 S3로만 되어야 한다. b. S3에서 S2으로의 Data translation 은 최대 한도를 제한
해야 한다. 어쩔 수 없는 전송 (e.g. permissives) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
c. Software Upgrade는 반드시 S3에서 가능하게 하면 안 된다.
d. S2의 Upgrade는 반드시 한번에 한 채널만 가능하게 해야 한다.
e. S2의 access는 권한이 없는 사람의 접근을 가능하게 하면 안된다.
f. I&C 이외의 IT System과의 communication은 case by case로 제약을 두어야 한다. 모든 원격 communication은 제한되어야 한다.
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
36
Z5(Display 관련) - CCG(S2)
1. Business Requirement 1. MCR, RSR 개별기기에 대한 제어 명령을 수신하고, CPM의 채널선택신호
를 확인하여 해당 채널 및 기기의 루프제어기에 전송.
2. 타 디비젼의 제어신호 및 운전원에 의하여 확인되지 않은 제어 명령 입력되는 것을 방지할 수 있어야 한다.
2. Technical Requirement 1. S2 등급에 요구되는 requirement
3. Security Requirement 1. 해당 device의 특징, 상황 등을 이용
1. PLC 1. Upgrade 시 지정된 장비를 사용
2. 지정된 장비에 pSet 이외에 다른 프로그램 설치 X
3. 자동 업데이트 X
2. Network 1. CPM, COM -> CCG : ETIP, GC와의 communication 은 못하게 한다.
2. SOFT CONTROL -> CCG : Manual signal 의 경우 인가된 운전원에 의한 신호인지 개인키를 이용하여 확인 한다.
a. Communications 은 S2에서 S3로만 되어야 한다. b. S3에서 S2으로의 Data translation 은 최대 한도를 제한
해야 한다. 어쩔 수 없는 전송 (e.g. permissives) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
c. Software Upgrade는 반드시 S3에서 가능하게 하면 안 된다.
d. S2의 Upgrade는 반드시 한번에 한 채널만 가능하게 해야 한다.
e. S2의 access는 권한이 없는 사람의 접근을 가능하게 하면 안된다.
f. I&C 이외의 IT System과의 communication은 case by case로 제약을 두어야 한다. 모든 원격 communication은 제한되어야 한다.
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
37
지금까지.. Zone, Degree, Requirement 할당
2. DESIGN에 반영
40
Design에 반영
• 분석가의 Inspection
– 요구사항 추적 매트릭스를 통한 Inspection
• 구조적 분석
– System Modeling 을 통한 Model Checking
41
분석가의 Inspection • 요구사항 추적 매트릭스란?
– Development life Cycle에 걸쳐 Requirement의 변경 및 반영 사항을 문서로 기록
42
Requirement 관리 Tools 를 이용
V
43
Inspection (Requirement(S1) – Deign)
S1 Technical Requirement
a. S1 system의 경우 networked links 는 다른 S1이나 S2 만 연결이 되어야 한다.
b. Communications 은 S1에서 S2로만 되어야 한다. c. S2에서 S1으로의 Data translation 은 최대 한도를 제한 해야 한다. 어쩔 수 없
는 전송 (e.g. permissive) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
d. S2에서 S1으로 전송되는 모든 data 는 static provisions 적용에 의해 보호되어야 한다.
e. Software Upgrade는 반드시 local로 이루어져야 한다.(한번에 한 channel 만 이용해야 한다.)
f. 시스템 소프트웨어의 숨겨진 기능에 대한 규정이 있어야 한다. (e.g., software code verification)
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
44
Inspection (Requirement(S1) – Deign)
S1 Technical Requirement a. S1 system의 경우 networked links 는 다른 S1이나 S2 만 연결이 되어야 한다.
b. Communications 은 S1에서 S2로만 되어야 한다. c. S2에서 S1으로의 Data translation 은 최대 한도를 제한 해야
한다. 어쩔 수 없는 전송 (e.g. permissive) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
d. S2에서 S1으로 전송되는 모든 data 는 static provisions 적용에 의해 보호되어야 한다.
e. Software Upgrade는 반드시 local로 이루어져야 한다.(한번에 한 channel 만 이용해야 한다.)
f. 시스템 소프트웨어의 숨겨진 기능에 대한 규정이 있어야 한다. (e.g., software code verification)
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
Profibus-FMS
FMS를 사용하면 다양한 서비스를 이용하여 고 수준의 분산제어 애플리케이션을 구현할 수 있으며 제어프로그램의 수시 다운로드 및 변경도 가능하다. 특별한 제약 X, 인증 X
HR-SDN
45
Inspection (Requirement(S1) – Deign)
GC와 CCG, CPM은 서로 Communication 하지 않음에도 하나의 네트워트로 연결되어 있음
HR-SDN
46
Design에 반영
• Requirement 중심의 system modeling을 통한 분석 (Safety와 마찬 기지 접근 방법)
– System Modeling
Ex)
• Data Flow Diagram
• State Chart
– Inspection, Model Checking
3. SAFETY와 간섭 여부 확인
48
Safety & Security S1 Technical Requirement a. S1 system의 경우 networked links 는 다른 S1이나 S2 만 연결이 되어야 한다.
b. Communications 은 S1에서 S2로만 되어야 한다. c. S2에서 S1으로의 Data translation 은 최대 한도를 제한 해야
한다. 어쩔 수 없는 전송 (e.g. permissive) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
d. S2에서 S1으로 전송되는 모든 data 는 static provisions 적용에 의해 보호되어야 한다.
e. Software Upgrade는 반드시 local로 이루어져야 한다.(한번에 한 channel 만 이용해야 한다.)
f. 시스템 소프트웨어의 숨겨진 기능에 대한 규정이 있어야 한다. (e.g., software code verification)
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
Profibus-FMS
FMS는 특별한 제약 X, 인증 X network 여기에 인증과정, 보안키 확인과정 등을 추가 -> 빠른 응답시간을 보장 X or 권한 때문에 원하는 기능을 수행하지 못하는 상황
HR-SDN
49
Safety & Security S1 Technical Requirement a. S1 system의 경우 networked links 는 다른 S1이나 S2 만 연결이 되어야 한다.
b. Communications 은 S1에서 S2로만 되어야 한다. c. S2에서 S1으로의 Data translation 은 최대 한도를 제한 해야
한다. 어쩔 수 없는 전송 (e.g. permissive) 은 security risk-analysis 를 통해 case-by-case 로 처리해야 한다.
d. S2에서 S1으로 전송되는 모든 data 는 static provisions 적용에 의해 보호되어야 한다.
e. Software Upgrade는 반드시 local로 이루어져야 한다.(한번에 한 channel 만 이용해야 한다.)
f. 시스템 소프트웨어의 숨겨진 기능에 대한 규정이 있어야 한다. (e.g., software code verification)
g. 비 정상 Alarms는 즉시 주의 깊게 분석되어야 한다.
Profibus-FMS
FMS는 특별한 제약 X, 인증 X 여기에 인증과정, 보안키 확인과정 등을 추가 -> 빠른 응답시간을 보장 X or 권한 때문에 원하는 기능을 수행하지 못하는 상황
HR-SDN
1. Security가 반영이 안 되었다. 2. Degree를 잘못 주었다. 3. Degree를 나눈 기준이 Module level이 아니다.
4. Safety와 Security는 간섭이 일어날 수 있다.
1. 해결할 수 있는 방법론이 필요
50
방법
• Equivalence checking
– 현 시스템의 Modeling
– Security Requirement 를 추가한 시스템 Modeling
– 두 Model 사이의 행위 일치성을 확인
• 전문가에 의한 Inspection
– 기존 시스템에 Security Issue를 추가해서 기존의 기능을 수행하지 못하는 경우가 있는지 확인
기존 시스템 Security Requirement
를 추가한 기존 시스템
Equivalence checking
4. 최종 시스템에 SECURITY REQUIREMENT 반영 여부 확인
52
최종 시스템에 Security requirement 반영 여부 확인 • 결국
– Test
• Security test case generation
– Simulation
• Use case, Misuse case 작성을 후 simulation
53
최종 시스템에 Security requirement 반영 여부 확인 • Test
– Security test case generation
– 기존 IT 산업의 Security 관련 이슈들을 이용하여 test case를 작성
– 전문가와 협업..
54
최종 시스템에 Security requirement 반영 여부 확인 • Simulation
– Misuse case Model, Anti-Goal Model 을 작성을 후 가상 위협 시나리오에 대해 시스템을 Simulation
55
결론
• 할일
– 1. Security Requirement 작성
• 적절한 방법론을 이용
– Zone, Degree 할당
– 2. Design 에 반영 여부
• Trace
• V&V
– 3. Security와 Safe와의 간섭 여부
• V&V
– 4. 최종 시스템에 Security Requirement의 V&V
1 Zone, Degree를 주관적인 기준을 가지고 분류
2
분석가의 Inspection - 요구사항 추적 매트릭스 작성을 통한
Inspection - Requirement 중심의 system modeling을 통
한 분석
3 - Equivalence Checking
- 전문가에 의한 Inspection
4 Test - Security test case generation Simulation - Use case, Misuse case 작성을 후 simulation
해결 방법
56
결론
• Cyber Security Scenario
설계상 취약점
정상 작동 중 침임
정상 프로그램 변경
Safety 침해
중요 정보 획득 & 파기
재산침해 2차 공격
57
결론
• Cyber Security Scenario
설계상 취약점
정상 작동 중 침임
정상 프로그램 변경
Safety 침해
Secure Coding
Security Requirement
Security 강화
내, 외부인에 의한 침입
실시간 감시
운전원 교육
Monitoring
program
백신 프로그램
중요 정보 획득 & 파기
재산침해 2차 공격
예방 가능할 활동
Policy
58
결론
• 접근 방법: Security Requirement를 작성하여 견고한 시스템을 만들어 사이버 공격을 원천 방어 하자
설계상 취약점
정상작동중 침임
정상 프로그램 변경
Safety 침해
Secure Coding
Security Requirement
Security 강화
내, 외부인에 의한 침입
실시간 감시
운전원 교육
Monitoring
program
백신 프로그램
중요 정보 획득 & 파기
재산침해 2차 공격
예방 가능할 활동
Policy
IEC-62645를 적용 - 취약점 제거를 통한
Cyber Security Attack 방어
Security Requirement 작성
시스템에 Security Requirement 반영
운행중에 이를 유지
59
• 감사합니다.
