사이버보안 위험 분석 예시-공격 트리 기반 침투 시험

※ Attack Tree

• 시스템에 대한 공격에 대하여 목표에 도달하기 위한 행위들을 트리 형태로 가시화 한 형태
• 하나의 루트 노드와 자식 노드로 구성
• 최하위 노드로부터 루트 노드까지의 하나의 경로의 조건을 만족할 경우 공격이 성사됨 
• 각 노드의 하위 간선(edge)은 노드의 조건을 만족하기 위한 행위를 명시
• AND-decomposition : 하위 간선의 명시된 동작이 모두 행해져야 상위 노드 의 조건을 만족
• OR-decomposition : 하위 간선의 명시된 동작 중 하나가 행해지면 상위 노드의 조건을 만족

출처:  Formal Works Inc.

원전 사이버보안 위험 분석 절차 및 운용

원전 사이버보안 위험 분석

1. 자산 분석

• 대상의 개요, 주요기능 및 구성, 영향도, 의존성 등을 분석 
• 대상의 네트워크 인터페이스 및 영향도, 의존성 등을 분석 
• 대상 계통에 대한 특성, 연계 정보 등을 분석

2. 취약점 분석

• 대상과 관련된 취약점 정보를 수집 
• 대상 별 취약점 점검 항목을 도출 
• 도출된 점검항목 및 침투 시험 기반의 취약점 평가

3. 위협 분석

• 대상에 대해 알려진 사이버보안 위협을 식별 
• 식별된 위협을 기반으로 공격 트리(Attack Tree) 작성 
• 작성된 공격 트리를 기반으로 공격 시나리오를 식별 
• 작성된 시나리오를 기반으로 모의 침투를 수행

4. 위험 평가

• 발견 취약점 및 성공 공격 시나리오에 대하여 원전에 대한 실 제 위협 가능성 평가 
• 각 위협에 대한 영향도 및 심각도 평가

사이버보안 위험 분석 체계 운용

출처:  Formal Works Inc.

포멀웍스-안랩의 원자력 제어 시스템 사이버보안 평가 방법론(NUSAF) 수행 개요

※ NUSAF™(Nuclear Security Assessment Framework) : 포멀웍스 - 안랩 제어 시스템 사이버 보안성 평가 방법론 (FASAF™ : Formalworks Ahnlab Security Assessment Framework) 를 원자력 제어 시스템 분야에 적합하게 수정한 평가 방법론

사이버보안 위험 분석 

• 원전 사이버보안 활동에서는 보안 위험을 체계적으로 관리하기 위하여 NUSAF 방법론 기반 보안 위험 분석(Security Risk Analysis)을 수행
• 각 단위 장비 및 계통에 대하여 1)자산 분석, 2)취약점 분석, 3)위협 분석을 수행 

출처:  Formal Works Inc.

원전 사이버보안 위험 관리 단계

출처:  Formal Works Inc.

Avoiding Top Mistakes in Safety Critical Software Development

Mistake #1: Forgetting to Conduct Requirements Reviews Often
"Review Requirements Early and Often – Make use of Lean and Agile"

• Conduct more frequent iterative reviews
• Review requirements in smaller batches
• Increase quality by having more thorough reviews & defined criteria
• Use collaborative techniques during review

Mistake #2:  Forgetting to Use Safety-Critical Requirements Checklists
"Make use of checklists when performing requirements reviews"


Mistake #3 Not Reviewing Software Requirements in Context
"Review Requirements with their traces in context."


Mistake #4– Neglecting Traceability
"When creating new requirements, tests cases, or code:"

• Establish the required traces immediately, not later when you need to demonstrate those traces to the auditor
• Make traceability updates mandatory for review of Requirements, Code, & Tests 
• Two-way traceability for:
• Requirements to Code Functions
• Code Functions to Tests
• Requirements to Tests 

Mistake #5: Neglecting Transition Criteria 

Mistake #6– Forgetting the Safety-Critical Software Lifecycle

Mistake #7 – Safety “Before & During”: Neglecting to Apply Safety  Standards BEFORE Software Development then During!

Mistake #8 – Neglecting Independence

• Independence refers to the Correctness process (reviews and verification) 
• Required Independence increases as criticality  increases
• Not providing required Independence necessitates development rework
• If future criticality level changes and Independence lacking:  rework.
• Recommendation:  even when Independence is not required, do it:  better review and insurance against future critical level increase

Mistake #9 – Inadequate Plans or not Following!

• Plans that are not compliant to standards
• Lack of checklists
• E.g. Code reviews without requirements traceability to code
• Plans are not complete prior to starting associated developments
• Plans not QA approved
• Plans too detailed, requiring extreme customization for each project

Mistake #10 - Lack of Automated Testing = Expen$ive Regression Test 

• Testing is a “life-of-product” continual activity
• Testing costs exceed development costs, over product lifetime
• Guilty-until-proven innocent regression: retest everything unless you can ensure no side effects
• Best regression test strategy?  Retest everything (only practical via automated testing)

Mistake #11: When to “Verify”?

Traditional Software Engineering Sequence:

Recommended “Best Practice” Software Engineering Sequence:

출처: www.afuzion.com

Safety-Critical Requirements

Safety Critical Definitions

• Software Requirement: “Measurable software processing that is necessary.”
• Safety-Critical Software Requirement: “A necessary aspect within a system whose anomalous behavior could negatively impact safety.” 

Safety-Critical Systems - Basic Facts

• “Safety-critical” encompasses many domains: Industrial, Automotive, Aerospace, Nuclear, Medical, etc. 
• Software size and complexity are rapidly increasing
• Yesterday’s non-safety-critical is becoming tomorrow’s safety-critical due to IoT, integration/connectivity, etc. 
• Requirements are  needed to guide development, identify hazard detection/mitigation, and assess implementation.

Safety-Critical Requirements –Background

• Experts say majority of safety-critical failures stem from requirements. 
• Safety-critical requirements include Safety aspects, but not exclusively: also address Functional, Performance, etc. 
• Most safety-critical requirements specifications are incomplete: lack complete hazard prevention/mitigation. 
• Need requirement identification, specification, verification, and management.

출처: www.afuzion.com

Attack Tree on Safety Function

출처: Goal-Oriented Co-engineering of Security and Safety Requirements in Cyber-Physical Systems by Philippe Massonet