2017년 4월 3일 월요일

안전성과 위험성의 관계

안전성(Safety)은 확률적인 개념으로 절대적 안전이란 존재하지 않고 상대적인 안전이 존재한다. 위험성(Risk)의 반대 개념으로 생각하여 보면 이해가 쉬운데, 매우 안전하다는 것은 위험하지 않다는 것이다.

안전성 평가는 확률 또는 정도의 개념으로 위험성에 대한 정량화하여 위험성을 제거 또는 감소하기 위한 기능이나 대책을 마련하는 위험성 평가 과정을 포함하며 여기서 나온 기능 및 대책이 안전 기능 및 안전 대책이 된다. 그림 2 는 두 개념의 관계를 보여준다.

이와 같이 안전성은 위험성을 이용하여 정의하고 정량화하여 평가할 수 있고, 안전성이란 위험성의 크기가 모두 수용 가능한 또는 허용 가능한 것만으로 되어 있는 상태라고 할 수 있다. 확률적 개념인 안전성의 수준을 안전무결성(Safety Integrity level)으로 표현할 수 있다.

안전성과 위험성에 대한 이해

1. 안전성(Safety)의 이해

안전성의 정의는 국제안전규격을 위한 가이드인 ISO/IEC GUIDE51 에 기술되어 있다. 이것에 의하면, 안전성은 ‘수용할 수 없는 위험성이 없는 것(freedom from unacceptable risk)’이라고 표현되어 있다. 직역하면, ‘수용할 수 없는 위험으로부터의 해방’이라는 정의이다. 달리 말하면, 사람 또는 재산에 대한 재해의 위험성이 허용 가능한 수준으로 억제되어 있는 상태라 할 수 있다.

이에 따라 시스템에서는 안전에 대한 개념을 1 차적 안전(Primary safety), 기능 안전성(Functional safety), 간접 안전성(Indirect safety)으로 분리할 수 있다. 1 차적 안전성은 화재, 감전과 같은 하드웨어에 의한 직접적 사고로부터의 안전성으로 정의한 것이고, 기능 안전성은 리스크 평가 측정결과에 따라서 설계과정을 통해 위험이 제거되는 장비의 안전성을 말하며, 간접 안전성은 데이터베이스 정보 에러와 같이 잘못된 정보 제공으로 일어날 수 있는 위험원으로부터의 안전성을 정의한다.

2. 위험성(Risk)에 대한 이해

일상에서 “Risk 가 있다”라고 할 때, Risk 는 ‘위험성, 일이 잘 안 풀릴 우려, 손실의 가능성’ 등을 의미할 수 있다. 산업분야에서도 적용 형태에 따라 다양하게 쓰이는데 공학, 교육, 식품(농업/어업) 관련 분야에서 Risk 는 위험, 사망, 부상, 질병 등의 의미로 사용되고 금융에서는 비용손실, 신뢰 상실, 모험, 도박 등을 의미하며, 정보통신기술에서는 정보유출, 가동중단 등의 의미를 나타내는 등 다양하게 쓰이고 있다. 산업안전보건 또는 환경분야의 경우 개념을 별도로 정의하여 ‘Risk’를 ‘위험성’, ‘위해성’으로 사용하고, 위험성은 ‘Risk’, 유해(Harm, Accident)를 일으키는 위험원은 ‘Hazard’로 구분하여 사용한다. Hazard 는 확률 개념을 포함하지 않고, 확률 개념인 Risk 의 근본 원인을 Hazard 로 표현한다. 위험을 위험성 평가는 ‘Risk Assessment’를 각각 의미한다.

그림 1 은 유해(Harm), 위험원(Hazard), 위험성(Risk)의 관계를 표현한 것으로 예를 들어, 뜨거운 물이 엎질러져 화상을 입는 경우에 뜨거운 물은 위험원이 되고, 물이 엎질러지는 상황은 위험한 상황, 그로 인해 화상을 입는 것을 유해로 예시하면 이러한 일련의 과정이 일어날 수 있는 가능성 및 결과의 심각성을 위험이라 표현하였다. 타이어 펑크로 인해 교통사고가 나거나 연료부족으로 인한 엔진 고장으로 비행기가 추락하는 경우를 생각해 보면 개념에 대한 이해를 좀더 명확히 할 수 있다.

정리하면 위험성(Risk)은 ‘유해 위험원(Hazard)이 유해(Harm)인 부상 또는 질병으로 이어질 수 있는 가능성(빈도, Probablity)과 심각성(강도, Severity)을 조합한 것’으로 정의할 수 있다. 위험성 평가는 ‘위험원(Hazard)를 찾아내어 사고 발생 확률과 사고 크기를 분석하여 그때 발생하는 영향을 정량화하여 대책을 세우는 과정’ 이라 할 수 있다. 이때 위험원(Hazard)은 정성적 기법으로 찾아내고, 위험성(Risk)의 대상인 사고발생확률과 사고 크기는 정량적 기법으로 찾아낸다.

IEC61508 기능 안전성 관련 전문 용어

Harm(피해) 사람들의 건강에 대한 물리적 부상 또는 환경/자산에 대한 물리적 피해
Hazard(위험) 피해의 잠재적 요인
Hazardous situation(위험한 상황) 하나 이상의 위험에 노출된 사람, 자산, 환경의 상황
Hazardous event(위험한 사건) 피해를 발생시키는 사건
Harmful event(유해한 사건) 피해를 발생시키는 위험한 상황 또는 위험한 사건의 발생
Risk(위험성) 피해발생의 확률과 피해의 심각도의 합
Tolerable risk(허용 가능한 위험성) 사회의 현재 가치에 기반한 주어진 상황을 반영하는 위험
Residual risk(잔여 위험성) 보호 조치를 취하고 남은 위험성
EUC risk(EUC 위험성) EUC 또는 EUC 제어 시스템의 상호작용으로부터 발생하는 위험성
Target risk(목표 위험성) 전기/전자/프로그램 가능한 전자 안전 관련 시스템과 기타 위험성 감소 조치와 함께 EUC 위험을 고려한 특정 위험에 도달하는 것을 의도하는 위험성
Safety(안전) 수용 불가능한 위험으로부터 벗어난 상태
Functional safety(기능 안전) E/E/PE 안전 관련 시스템과 기타 위험성 감소 조치의 올바른 기능에 의한 EUC 와 EUC 제어 시스템과 관련된 전체 안전의 일부
Safe state(안전 상태) EUC 가 안전에 도달한 상태
Reasonably foreseeable misuse(타당한 예비 오용) 제품, 절차 또는 서비스의 사용이 공급자에 의도대로 사용되지 않는 경우, 이는 쉽게 예측 가능한 사람의 행동으로부터 생길 수 있음.
Equipment under control, EUC(제어 되는 장비) 생산, 프로세스, 운송, 의료 또는 기타 활동에 사용되는 장비, 기계, 기관, 플랜트를 말함(EUC 제어시스템과 EUC 는 별개임)
Environment(환경) 특정 조건하에 있는 응용이나 모든 안전성 생명주기 단계에서 기능 안전에 도달할 수 있도록 하는 모든 관련 요소. 예를 들어, 물리적 환경, 사용 환경, 법적 환경, 유지 보수 환경 포함가능
Functional unit(기능 유닛) 특정 목적을 이룰 수 있게 하는 하드웨어 또는 소프트웨어(혹은 둘 모두를 포함). IEV 191-01-01 에서는 기능 유닛 대신 item(아이템)을 사용, item 에는 사람이 포함될 수 있음
Application(응용) E/E/PE 시스템보다 EUC 와 관련된 작업
Software(소프트웨어) 데이터 처리 시스템 운용과 관련된 프로그램, 프로시저, 데이터, 규칙, 그리고 관련 문서로 구성되는 지적 생산물
System software(시스템 소프트웨어) PE 시스템의 소프트웨어, 이것은 프로그램 가능한 장치 스스로 서비스를 생산하고 기능함, 응용 소프트웨어와 대비되는 개념
Configuration data(응용소프트웨어, 응용데이터, 설정데이터) 기능을 구체화 하는 PE 소프트웨어, 프로그램 가능한 장치 스스로 제공하는 서비스나 장치 스스로의 기능보다는 EUC 와 관련된 작업을 수행함
Pre-existing software(이미 존재하는 소프트웨어) 이미 존재하고 있으며, 현재 프로젝트나 안전 관련 시스템과 특별히 관계가 있지 않은 소프트웨어 요소
Data(데이터) 컴퓨터의 통신, 해석, 프로세싱을 위한 의미로 표현된 정보
Software on-line support tool(소프트웨어 온라인 지원 도구) 소프트에어 실행 시간 동안 안전 관련 시스템에 직접 영향을 줄 수 있는 소프트웨어 도구
Software off-line support tool(소프트웨어 오프라인 지원 도구) 소프트웨어 개발 생명주기의 한 단계를 지원하는 소프트웨어 도구, 실행시간에 직접 영향을 주지 못함. 소프트웨어 오프라인 지원도구는 T1, T2, T3 로 구분

T1:(데이터를 포함한)실행 코드에 직/간접적으로 기여하는 산출물을 생산하지 않음
T2:설계 또는 실행 코드에 대해 테스트 및 검증을 지원
T3:(데이터를 포함한)실행 코드에 직/간접적으로 기여하는 산출물을 생산함

Programmable electronic, PE(프로그램 가능한 전자의 (어떤 것)) 하드웨어, 소프트웨어, 입력 또는 출력 유닛으로 구성될 수 있는 컴퓨터 기술에 기반한 (어떤 것)
Electrical/electronical/programmable electronic, E/E/PE(전기/전자/프로그램 가능한 전자의 (어떤 것) 전기, 전자 또는 프로그램 가능한 전자 기술에 기반한 (어떤 것)
Limited variability language(제한된 다양성 언어) 상업적 및 산업적으로 프로그래밍 가능한 전자 제어장비를 위한 소프트웨어 프로그래밍 언어, 응용에 제한적임
Application specific integrated circuit, ASIC(주문형 반도체) 특정 기능을 목적으로 생산되고 고안된 집적 회로, 제품 생산자에 의해 기능이 정의됨(wikipedia)
PE system(PE 시스템) 하나 이상의 PE 장치로 이루어진 제어, 보호, 모니터링을 위한 시스템, 여기서 PE 장치에는 전원 장치, 센서, 입력 장치, 데이터 고속도로, 통신 패스, 액츄에이터, 기타 출력 장치 등을 포함함
E/E/PE system(E/E/PE 시스템) 하나 이상의 E/E/PE 장치로 이루어진 제어, 보호, 모니터링을 위한 시스템. 여기서 PE 장치에는 전원 장치, 센서, 입력 장치, 데이터 고속도로, 통신 패스, 액츄에이터, 기타 출력 장치 등을 포함함
EUC control system(EUC 제어 시스템) 프로세스 또는 오퍼레이터로부터 입력 받은 신호에 대한 응답을 하는 시스템. 또한, 원하는 방식으로 EUC 가 출력신호를 생성하는 시스템
Architecture(구조) 시스템에서 하드웨어 및 소프트웨어의 특정한 설정
Software module(소프트웨어 모듈) 프로시저 및 자료선언의 구성을 구조화 함. 또한, 다른 구성과 상호작용 할 수 있도록 구조화 함
Channel(채널) 기초 안전 기능을 독립적으로 구현하는 요소 혹은 요소들의 그룹
Diversity(다양성) 요구되는 기능을 수행하는 다른 방법 다양성은 물리적 방법 또는 디자인 접근방법을 다르게 함으로써 달성될 수 있음
Safety-related system(안전 관련 시스템) 아래의 특성을 갖는 시스템 - EUC 의 안전한 상태를 달성 또는 유지하는데 필요한 안전 기능을 구현함 - 시스템 자체 또는 E/E/PE 안전 관련 시스템이나 다른 위험성 감소 조치를 포함하여 요구되는 안전 기능에 대해 필요한 안전 무결성을 달성하려는 것
Other risk reduction measure(기타 위험성 감소 조치) 위험성을 감소시키거나 완화시키기 위한 조치. 이것은 E/E/PE 안전 관련 시스템과 분리되고 구분됨
Low complexity E/E/PE safety-related system(낮은 복잡도의 E/E/PE 안전 관련 시스템) 아래와 같은 특성을 갖는 E/E/PE 시스템 각 개별적인 컴포넌트의 실패 모드가 잘 정의됨 - 결함 조건에 맞는 시스템의 응답행동이 완전히 결정될 수 있음
Subsystem(서브시스템) 안전 관련 시스템의 최상위 구조 설계 결과물
Element(요소) 하나 이상의 기초 안전 기능을 수행하는 단일 컴포넌트 또는 컴포넌트의 그룹으로 구성된 서브시스템
Redundancy(여분) 요구되는 기능을 수행하기 위해 또는 정보를 표현하기 위해 하나 이상의 방법을 갖는 존재
Safety function(안전 기능) 특정 위험한 사건에 대하여 E/E/PE 시스템 또는 기타 위험성 감소 조치에 의해 구현된 기능
Overall safety function(전체 안전 기능) 특정 위험한 사건에 대하여 EUC 를 위한 안전한 상태를 달성 또는 유지하기 위한 방법
Element safety function(기초 안전 기능) 요소에 의해 구현되는 안전 기능의 일부
Safety integrity(안전 무결성) E/E/PE 안전 관련 시스템이 정해진 시간 안에 정해진 모든 조건에 맞는 특정 안전 기능을 만족스럽게 수행할 확률
Software safety integrity(소프트웨어 안전 무결성) (소프트웨어 속성에 맞는)장애의 위험한 모드에서 시스템적 장애와 관련한 안전 관련 시스템의 안전 무결성
Systematic safety integrity(시스템적 안전 무결성) 장애의 위험한 모드에서 시스템적 장애와 관련한 안전 관련 시스템의 안전 무결성
Hardware safety integrity(하드웨어 안전 무결성) 장애의 위험한 모드에서 임의의 하드웨어 장애와 관련한 안전 관련 시스템의 안전 무결성
Safety integrity level, SIL(안전 무결성 등급) 안전 무결성 값의 범위에 따라 구분된 등급. 예를 들어, 4 단계로 나누었을 때 4 단계가 가장 높고 1 단계가 가장 낮음
Systematic capability(시스템적 능력) 요소의 시스템적 안전 무결성이 특정 SIL 의 요구사항을 만족함을 보여줄 수 있는 기준
Software safety integrity level(소프트웨어 안전 무결성 등급) 안전 관련 시스템의 서브시스템으로 구성된 소프트웨어 요소의 시스템적 능력
E/E/PE system safety requirements specification(E/E/PE 시스템 안전 요구사항 명세) 안전 기능 및 그와 관련된 안전 무결성 등급을 위한 요구사항을 담고 있는 명세
E/E/PE system safety functions specification(E/E/PE 시스템 안전 기능 명세) 안전 관련 시스템에 의해 수행되어야 하는 안전 기능에 대한 요구사항을 담고 있는 명세
E/E/PE system safety integrity requirements specification(E/E/PE 시스템 안전 무결성 요구사항 명세) 안전 관련 시스템에 의해 수행되어야 하는 안전 기능의 안전 무결성 요구사항을 담고 있는 명세
E/E/PE system design requirements specification(E/E/PE 시스템 설계 요구사항 명세) 서브시스템과 요소의 관점에서 E/E/PE 안전 관련 시스템을 위한 설계 요구사항을 담고 있는 명세
Safety-related software(안전 관련 소프트웨어) 안전 관련 시스템에서 안전 기능을 구현하는데 사용되는 소프트웨어
Mode of operation(동작 모드) 안전 기능을 동작하는 방법 - Low demand mode(낮은 요청 모드): EUC 가 특정 안전 상태에 들어가기 위해서 안전 기능이 즉시 수행되어야만 하는 경우 중 연간 요청 주기가 1 개 미만인 경우 - High demand mode(높은 요청 모드): EUC 가 특정 안전 상태에 들어가기 위해서 안전 기능이 즉시 수행되어야만 하는 경우 중 연간 요청 주기가 1 개 이상인 경우 - Continuous mode(계속적 모드): 보통의 동작에서 안전 기능이 EUC 가 안전한 상태를 유지할 수 있게 하는 경우
Target failure measure(목표 장애 기준) 안전 무결성 요구사항에 대해 위험한 모드의 장애의 목표 확률 - 요청이 왔을 때 안전 기능에 대한 위험 장애의 평균 비율(낮은 요청 모드) - 위험 장애 [h-1]의 평균 주기(높은 요청 모드 또는 계속적 모드)
Necessary risk reduction(필요 위험성 감소) 위험성의 허용 가능한 범위를 초과하지 않도록 하기 위하여 E/E/PE 안전 관련 시스템 및 기타 위험성 감소 조치에 의해 달성되는 위험성 감소
Fault(결함) 요청된 기능을 수행할 때 기능 유닛의 능력이 감소하거나, 손실이 발생하는 비정상적 조건
Fault avoidance(결함 회피) 안전성 생명주기의 어떤 단계 중에도 결함을 피할 수 있도록 하는 기술 및 프로시저의 사용
Fault tolerance(결함 허용) 결함 또는 오류가 존재할 때 기능 유닛이 요청된 기능을 계속 수행할 수 있는 능력
Failure(장애) 요청된 방법 이외의 방법으로 기능 유닛 기능 또는 동작을 정상적인 제공이 멈추는 경우
Random hardware failure(임의의 하드웨어 장애) 임의의 시간에 발생하는 하나 또는 그 이상의 하드웨어 오염 메커니즘을 발생시키는 장애
Systematic failure(시스템적 장애) 설계 또는 생산 프로세스의 수정이나 동작 프로시저, 문서 또는 기타 관련 요인에 의해 제거될 수 있는 장애
Dangerous failure(위험한 장애) A) EUC 가 위험한 상태 또는 잠재적으로 위험한 상태로 들어가도록 요청 모드일 때 안전 기능이 실행되는 것을 막거나 계속적 모드에서 안전 기능이 실패하게 함 B) 필요 시 안전 기능이 제대로 동작하는 확률을 감소시킴
Safe failure(안전한 장애) A) EUC 가 안전한 상태에 들어가거나 안전한 상태를 유지하기 위해 안전 기능의 거짓 동작이 발생함 B)거짓 동작의 발생 확률이 증가함
Dependent failure(의존적 장애) 의존적 장애의 확률은 개별 사건에 대한 확률의 곱으로 나타낼 수 없음 ※ 두 사건 A 와 B 가 의존적일 때,P(A and B) > P(A)×P(B).
Common cause failure(일반적으로 발생하는 장애) 멀티 채널 시스템에서 둘 또는 그 이상의 분리된 채널의 장애가 동시발생 하는 경우, 시스템 장애 발생
Error(오류) 이론적으로 올바른 값이나 조건과 계산, 관찰 또는 측정된 값이나 조건과의 차이. 이론 값과 실측 값의 차이
Soft-error(소프트 오류) (물리 회로 자체에는 영향을 주지 않는) 데이터 컨텐츠의 잘못된 변화
No part failure(무 역할 장애) 안전 기능을 구현하는데 아무런 역할을 하지 않는 컴포넌트의 장애 ※안전 장애 비율 산정방식을 사용하지 않음
No effect failure(무 영향 장애) 안전 기능을 구현하는데 역할을 하지만 안전 기능에 직접적으로 영향을 미치지 않는 요소의 장애 ※ 안전 장애 비율 산정방식을 사용하지 않음
Safe failure fraction(안전 장애 비율) (Σλ_(Savg)+Σλ_(Ddavg))/(Σλ_(Savg)+Σλ_(Davg)) Σλ_(Savg):average of the rate of safe failure Σλ_(Dd avg): average of the rate of detected dangerous failure Σλ_(D avg): average of the rate of dangerous failure
Failure rate(장애율)
Probability of dangerous failure on demand, PFD(즉발적 위험한 장애에 대한 확률) EUC 또는 EUC 제어 시스템에서 요청 발생 시 E/E/PE 안전 관련 시스템이 특정 안전 기능을 실행할 때의 안전 비가용성
Average probability of dangerous failure on demand, PFDavg(즉발적 위험한 장애에 대한 확률의 평균) EUC 또는 EUC 제어 시스템에서 요청 발생 시 E/E/PE 안전 관련 시스템이 특정 안전 기능을 실행할 때의 평균 비가용성
Average frequency of a dangerous failure per hour, PFH(시간당 위험한 장애의 평균 발생 주기) 주어진 시간 동안 E/E/PE 안전 관련 시스템이 특정 안전 기능을 수행할 때 발생하는 위험한 장애의 평균 발생 주기
Process safety time(안전 처리 시간) EUC 또는 EUC 제어 시스템에서 장애가 발생한 시점부터 발생한 장애가 완전히 해결된 시점 사이의 시간 여기서 장애는 위험한 사건을 일으킬 수 있는 잠재적 장애이며, 장애를 해결하는 것은 위험한 사건이 발생하지 않도록 방지하는 것
Mean time to restoration, MTTR(복원 평균 시간) 복원 상태에 도달하기까지 예상 시간
Mean repair time, MRT(평균 복구 시간) 전체 복구 예상 시간
Safety lifecycle(안전 생명 주기) 안전 관련 시스템을 구현하기 위하여 프로젝트의 컨셉을 잡는 것부터 시스템이 더 이상 사용되지 않을 때 까지 포함되는 모든 필요한 활동들을 말함
Software lifecycle(소프트웨어 생명주기) 소프트웨어의 개발이 시작될 때부터 영구적으로 폐기될 때까지 발생하는 모든 활동
Configuration management(형상 관리) 포넌트에 대한 변화를 제어하고 지속성 및 추적성을 유지하는 것에 대한 규칙

2017년 3월 31일 금요일

[218호 웹진: SW공학 동영상] Cyber Security Engineering for Software and Systems Assurance

Cyber Security Engineering for Software and Systems Assurance

참석자

Nancy R. Mead - SEI fellow and principal researcher in the CERT Division of the Software Engineering Institute

Carol Woody - Senior member of the technical staff and the technical manager of the Cybersecurity Engineering Team

요약

소프트웨어 및 시스템 보증을 위한 사이버 보안 공학

시스템을 계속 구축되어야 하고 우리가 원하는 모든 기능을 필요로 합니다. 그것은 싸야 하고 빠르게 바뀌지 않아야 합니다. 사람들을 대체할 수 있어야 하고 일을 빨리 끝낼 수 있어야 합니다. 여분의 노력과 추가 비용이 들기 때문에 보안 장비에 대한 여유가 없습니다.

우리가 쓰는 훌륭한 보안 주체는 인수 관리자입니다. 계약이나 상업용 소프트웨어 구매 등을 통해 제품을 개발할뿐만 아니라 사이버 보안에 대해서 고민합니다. 또 다른 보안 주체는 실제로 시스템에 사이버 보안을 구축할 책임이 있는 개발 관리자와 기술자입니다. 그들은 의사 결정권자입니다.

사이버 보안에 종사하는 사람들도 시스템을 개발하고 습득할 때 사이버 보안이 왜 그렇게 중요한지의 연관성을 이해하지 못합니다. 블로그 포스트에서 사이버 보안 공학을 지원하기 위해 7가지 원칙에 대해 이야기했지만 7가지 원칙은 일종의 체계를 구성하는 것입니다.

리스크 관리를 추진력으로 삼았기 때문에 책에 대한 요점이 매우 중요하다고 생각합니다. 아무도 보안을 위한 구입하지 않기 때문입니다. 리스크 유형의 제어나 구조가 필요하고 기술에 대한 설명이 있어야 합니다. 이 기술로 무엇을 하고 있는지, 데이터는 어디에 있는지, 얼마나 광범위하게 정보를 배포하고 있는지, 어떤 종류의 사람들이 그것으로 작업할 것인지 말입니다. 이 모든 것은 의사 결정의 일부가 됩니다. 웹에 게시 될 수도 있고 모든 인터페이스를 제어하지 않고 액세스 될 수도 있습니다.

몇 가지 중요한 점을 제기합니다. 체크리스트를 위한 컨트롤 목록을 제공한다는 것과 소프트웨어를 어디에서 공급하는지에 대한 공급망 문제입니다. 공급망이 어떻게 생겼는지에 대해 알 수가 없습니다.

소프트웨어를 만드는 방법을 살펴 보는 것은 계획된 주요 프로세스입니다. 그러나 이 과정에서 보안을 계획하는 곳은 없습니다. 라이프 사이클 전반에 걸쳐 통합되어 있지 않으면 따로 계획하기 어렵습니다. 누군가 서비스 거부를 만들었고 특정인이 조작할 수 없기 때문에 문제가 생깁니다. 처음에 이러한 것이 만들어질 때 고려해야 합니다.

보안을 처음에 고려하지 않은 경우 나중에 잘 통합되지 않을 가능성이 있습니다. 왜냐하면 보안에 대한 결정이 미리 없었기 때문입니다. 전체 시스템을 안전하게 할 수 없기 때문에 전체 시스템이 문제가 생길 수 있습니다. 보안을 위한 패치의 지속 비용이 엄청난데 그나마 패치 주기에 지칠 수 있고 패치가 다른 문제를 일으킬 수도 있습니다.

집중적으로 고민해야 하는 방법 중 하나는 직원과 조직이 사이버 보안 역량을 향상시키는 방법입니다. 그렇지 않으면 보안 담당은 할 일이 너무 많은데 직원과 조직이 무엇을 해야할지 몰라 아무 것도 하지 않게 됩니다. 역량을 향상시켜 작은 증분 단계를 시작할 수 있으면 개선이 쉬워집니다. 사람들이 할 수 있는 가장 효과적인 방법입니다. 그런데 직원과 조직의 압박은 많습니다. 할 일이 너무 많다라고 생각할 텐데 성장이 필요합니다.

이 팟 캐스트는 SEI 웹 사이트 sei.cmu.edu/podcasts 및 Carnegie Mellon University의 iTunes U 사이트에서 제공됩니다. 항상 그렇듯이 질문이 있으시면 info@sei.cmu.edu로 전자 메일을 보내주십시오. 고맙습니다.

[218호 웹진: 인사이드이슈] 소프트웨어공학의 오해와 필요성

소프트웨어공학의 오해와 필요성

불과 얼마 전까지만 해도 소프트웨어 개발 프로세스나 개발 방법론 등은 개발자들에게 환영 받지 못할 정도로 소프트웨어를 개발할 때 필요한 요소들이 정리된 소프트웨어공학의 관심은 일부 전공자들에게 한정되어 있었다. 하지만 최근에 소프트웨어공학을 다시 살펴보자는 주장들이 많이 나오고 있어 호윤시스템 김기향 팀장과 소프트웨어공학을 전공한 윤광렬 박사를 만나 이야기를 나눠본다.

Q: 안녕하세요. 2000년 전후로 집중적인 관심을 받다가 그 이후 지속적으로 관심이 줄어들고 있던 소프트웨어공학이 요새 다시 회자되고 있습니다.

이 얘기를 들으시는 분 중에 요새 소프트웨어공학이 다시 얘기되는 것을 모르겠다는 분들도 많을 겁니다. 그런데 최근에 이슈가 많이 되고 있는 애자일(Agile)이나 마이크로 서비스(Micro Service), 클라우드 서비스(Cloud Service) 등 많은 부분이 소프트웨어공학 없이는 구현되기가 어려운 것들입니다. 녹아 들어있는 소프트웨어공학을 인지 못하시는 것뿐입니다.

<그림1> 소프트웨어공학 활용의 예

$D:\49376f6d9f5acBD.jpg$

출처: http://blog.creation.net/306

최근까지도 소프트웨어공학을 소프트웨어를 개발하고 유지보수하는 생명주기 전반을 나타낸다고 이해하시는 분들이 많습니다. 특히 위키백과와 같은 사전적 정의도 이렇게 정의된 경우가 대부분이죠. 위키백과에서는 “소프트웨어의 개발, 운용, 유지보수 등의 생명 주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문이다; 즉, 공학을 소프트웨어에 적용하는 것이다”라고 정의되어 있습니다. 물론 틀린 말은 아니지만 소프트웨어공학이 적용되는 범위는 훨씬 광범위하다는 것이죠.

“소프트웨어를 만들 때”라는 말을 하나의 시스템을 개발하는 것에만 국한하지 말고 어떠한 제품을 만들 때 소프트웨어를 어떻게 하면 잘 적용할 수 있는가 하는 것도 포함시켜야 합니다.

Q: “제품을 만들 때”라는 말이 이해가 어려운데 조금 자세히 말씀해주시겠습니까?

일반적으로 소프트웨어를 만든다고 하면 시스템을 설계해서 코딩을 하고 운영을 하게 됩니다. 말 그대로 소프트웨어가 단독으로 만들어지는 것이지요. SI가 이러한 형태로 개발이 되고 솔루션 개발에서도 이러한 방식을 취하는 경우가 많습니다. 그런데 소프트웨어가 다른 제품에 들어가는 경우도 많지 않습니까? 최근에는 자동차나 비행기, 공장 등지에서도 사용되고 있는 것이 현실이지요. 반도체는 컴퓨터에만 쓰이는 것으로 잘 알려져 있지만 사람이 사용하는 거의 모든 전자 제품에 들어가는 것처럼 소프트웨어도 비슷합니다.

<그림2> 임베디드 소프트웨어 활용의 예

$D:\embedded.png$

출처: http://j.mp/ZYZ4KF

그림2에서처럼 임베디드 소프트웨어만 그런 것은 아닙니다. 이제 소프트웨어가 거의 모든 기계나 제품에 대부분 들어간다는 것을 인식해야 하고 이에 대비한 소프트웨어 만드는 방식을 준비해야 하는 것이죠.

Q: 요새 나오는 전자 제품에는 소프트웨어가 꼭 들어가니 소프트웨어를 적용하기 위해 소프트웨어공학이 필요하다는 말로 이해가 되네요. 맞나요?

맞는 말이긴 하지만 전자 제품이 아니더라도 소프트웨어공학은 소프트웨어를 만드는 방법적인 것을 말하는 것이기 때문에 개발 프로세스나 개발 방법론에 너무 한정해서는 안된다는 것을 말씀드리는 것입니다.

SI에서 소프트웨어를 만드는 것과 자동차에 들어가는 소프트웨어를 개발하는 것은 매우 다른 방법으로 소프트웨어가 이해되어야 하지만 소프트웨어를 만들기 위해 고민해야 하는 근본적인 문제는 똑같다는 것이죠. 예를 들면 소프트웨어가 어떤 운영체제에서 구동되는지, 보안상 필요한 부분은 무엇인지, 데이터는 어떻게 주고 받아야 하는지 등을 말합니다.

<그림3> 자동차에 탑재되는 소프트웨어의 예

출처: IT조선

그림3에서 차간거리제어를 보죠. 차간 거리를 제어하기 위해서는 거리를 측정하는 센서도 필요하지만 센서에서 거리를 읽어 판단하고 제어하는 소프트웨어도 필요할 겁니다. 이 때 만들어지는 소프트웨어를 SI 개발하듯이 개발할 수 있을까요? 아닐 겁니다. 이러한 소프트웨어를 만들 때는 또다른 방법이 필요하고 이러한 방법은 소프트웨어공학을 기반으로 정의되어야 한다는 것이 오늘 이야기의 핵심입니다.

Q: 그러한 소프트웨어 개발은 임베디드 소프트웨어에만 한정되어 있는 것 아닌가요? 그리고 임베디드 소프트웨어는 SI 개발과는 비교도 안될 만큼 개발 규모가 작지 않나요?

이 부분이 혼동하기 쉬운 부분입니다. 임베디드 소프트웨어는 이미 구분되어 있는 소프트웨어의 한 분야는 맞습니다. 하지만 어디서부터 어디까지 임베디드 소프트웨어라고 할 것인가라는 정의는 따로 없습니다. 어떤 제품이 원활하게 동작할 수 있도록 도와주는 것 정도로만 알고있는 것이 현실인데 최근에는 제품에 들어가는 소프트웨어가 임베디드 소프트웨어인지 시스템이라고 불릴 수 있는 소프트웨어인지 구분하기가 매우 애매해 졌다는 것입니다.

<그림4> 스마트 공장의 소프트웨어 활용

$D:\158a26f9a939493afcee397b0ad82d4b_20150403111024_zihmcknj.jpg$

출처: http://www.iuchem.com

Q: 이전의 인터뷰에서 소프트웨어 산업이라는 말이 없어지고 모든 산업에서 소프트웨어가 부자재로 사용될 것이다라는 말이 기억납니다.

네 맞습니다. 소프트웨어 시스템이라고 불리던 SI 형태 위주였던 대규모 소프트웨어 산업에서 모든 산업에서 필요로 하는 소규모지만 반드시 필요한 맞춤형 소프트웨어로 바뀌고 있는 것이지요.

Q: 4차 산업혁명과 맥을 같이 하는 것으로 봐도 되겠네요. 그렇다면 소프트웨어공학과 연관해서 정리를 해주시죠.

4차 산업혁명은 인공지능 중심으로 산업이 변화되는 경우가 많은 것으로 알려져 있지요. 하지만 그 전에 모든 산업에서 필요한 소프트웨어를 탑재하게 됩니다. 초연결 사회를 지향하는 4차 산업혁명의 경우 소프트웨어를 더 효율적이고 체계적으로 적용하기 위해서는 반드시 소프트웨어공학이 필요합니다. 그림5는 고건 교수가 말하는 초연결 사회에서는 소프트웨어공학이 해답이라고 말한 것을 나타내고 있습니다. 물론 시각의 차이는 있겠지만 시대가 지날수록 소프트웨어를 만들 때 소프트웨어공학의 필요성은 점점 증가한다는 것이지요.

<그림5> 초연결 사회와 소프트웨어공학의 연관성

출처: 고건 - 22nd SW Quality Insight Conference

Q: 각 산업 군에서 소프트웨어가 필요하고 소프트웨어 개발을 위해 소프트웨어공학이 필요하다는 것은 이해가 갑니다. 그런데 소프트웨어공학을 어떻게 적용해야 하는 걸까요?

앞에서 소프트웨어공학은 개발 프로세스나 개발 방법론에 국한해서는 안된다는 말을 했습니다. 말하자면 소프트웨어를 만들 때 표준화된 프로세스와 방법론에 따라 만드는 것에서 벗어나야 한다는 것이죠. 각 산업 군에서 사용되는 소프트웨어는 각자 만들어지는 방식도 매우 다를 겁니다. 아니 다르게 만들어져야 합니다. 왜냐하면 각 산업 환경은 매우 다르기 때문에 거기에 맞는 소프트웨어가 있고 개발 방법도 정해진다는 말입니다.

기존에는 임베디드 소프트웨어라는 범위로 획일화된 개발 방식이 있었습니다. 하지만 지금은 자동차에서 사용되는 소프트웨어에서 고민해야 하는 것과 공장 자동화에서 사용되는 소프트웨어에서 고민해야 하는 것이 다를 수 있다는 것이죠. 여기서 말하는 다르다고 하는 것은 소프트웨어를 만드는 방법뿐만 아니라 운영체제, 보안, 데이터 전달, 더 나아가서는 인공지능으로 확대되는 것까지 다양한 형태가 존재합니다.

Q: 운영체제나 보안 같은 분야는 소프트웨어 개발에서 기본적으로 고민되는 부분 아닌가요? 각 산업에서 다르게 적용될 것이라는 이유는 무엇인가요?

예를 들면 자동차에서 고민해야 하는 보안 문제는 무엇일까요? 자율 주행을 적용했는데 해킹을 당해 도로 위에서 사고를 유발할 수 있다는 것을 고려해야 하고 스마트 공장에서 보안을 생각해야 한다면 IoT 장비에 장애가 일어나서 기계들을 멈추게 할 수 있죠. 이와 같이 보안 문제도 산업마다 다르게 나타나고 그에 대비한 소프트웨어 관점의 고민도 달라진다는 것입니다. 바로 산업 안전성 문제가 대두되는 것이죠.

<그림6> 소프트웨어 안정성 분석

산업에 적용해야 할 제품을 체계적으로 분석하고 특성에 맞게 설계하고 효율적인 개발을 통해 산업 발전에 도움을 줄 수 있는 소프트웨어를 만들기 위해서 소프트웨어공학은 이전보다 더 필요한 시대가 왔다고 봐야 합니다. 소프트웨어공학은 소프트웨어를 만드는 순서를 나타낸 것이 아니라 효율적인 소프트웨어를 체계적으로 개발하기 위한 것이 목적이기 때문입니다. 특히 4차 산업혁명이 나타난 지금 시점에 소프트웨어공학의 필요성은 계속 증가할 것으로 예상됩니다.

Q: 최근에 각 산업에서는 안전성에 대한 이슈가 계속 부각되고 있는데 점점 복잡해지는 산업 구조에 소프트웨어가 차지하는 비중도 커지기 때문일 것도 같습니다. 소프트웨어 안전성에 대한 이슈도 더 커지는 것 같고요. 오늘 이야기를 정리해 주시죠.

소프트웨어는 이제 소프트웨어를 만드는 회사나 개발자만 고민해서는 안됩니다. 거의 모든 산업에서 소프트웨어를 사용하고 있고 소프트웨어로 인해 문제가 발생하고 발전도 이룹니다. 소프트웨어의 역할이 그만큼 커졌다는 말이겠죠. 소프트웨어로 인한 안전 사고도 계속 발생할 것으로 보이기 때문에 소프트웨어에 대한 안전성 이슈도 대두될 것이고요. 소프트웨어공학은 이러한 이슈나 문제를 해결하기 위해 반드시 필요한 것이라고 인식해야 합니다. 소프트웨어가 원하는 대로 잘 개발되게 하고 문제가 발생하지 않게 하기 위해서는 소프트웨어공학을 얼마나 잘 적용했느냐 하는 것이 중요하기 때문입니다. 소프트웨어공학에 대한 각 산업의 이해가 더 필요한 시점인 것 같습니다.

Keyword: software engineering, software safety, fourth industrial revolution, software development

[218호 웹진: 공학 트렌드] 클라우드 SW 사례 연구 - 보안

클라우드 SW 사례 연구 - 보안

클라우드 서비스가 전통적인 소프트웨어 시스템을 대체하면서 가장 크게 이슈화된 것이 보안이다. 전통적인 소프트웨어 시스템은 구현 초기부터 보안에 대한 분석과 설계를 함께 하게 되는데 클라우드는 네트워크 자체가 외부에 오픈되어 있는 경우도 많고 가상화나 공유되는 부분도 많아 보안 문제가 항상 노출되어 있다. 하지만 클라우드 서비스도 소프트웨어 시스템의 일종이기 때문에 기존 보안 기술을 적절히 사용한다면 큰 보안 문제는 나타나지 않을 것으로 보인다. 이번 회에서는 클라우드 서비스의 보안에 대해 살펴보기로 한다.

사례 전 확인 사항

클라우드(Cloud) 보안 개념

클라우드 서비스는 시스템 내부의 자원을 사용하지 않고 외부의 자원을 일부나 전부를 사용하는 경우가 많아 보안에 대한 대비가 반드시 필요하다. 클라우드 보안 문제도 전통적인 소프트웨어 시스템의 보안 문제와 유사한 데이터 유출이나 안정성, 네트워크 문제, 그리고 가용성에 따른 서비스 문제 등이 있다(표1).

<표1> 클라우드 서비스의 보안 위협

출처: 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

클라우드 서비스에서 보안 문제가 더 크게 대두되는 문제는 그림1에서 보는 것처럼 전통적인 소프트웨어 시스템에서는 각 시스템 단위로 보안 문제를 준비하면 되기 때문에 자체적인 보안 가이드에 따라 보안 준비가 가능했지만 클라우드는 외부 네트워크로 연결되어 서비스가 되기 때문에 보안이 외부에 직접적으로 노출되어 있기 때문이다.

<그림1> 전통적인 소프트웨어 시스템과 클라우드 서비스의 비교

출처: 미래창조과학부

클라우드 서비스의 보안은 두가지 관점이 공존한다. 다양한 기업의 정보나 네트워크가 몰려 있기 때문에 보안 사고가 나타나면 여파가 굉장히 크다는 것과 기업이 자체적인 보안보다 체계적인 관리를 하기 때문에 더 안전하다는 관점도 있다. 특히 인프라(IaaS), 플랫폼(PaaS), 그리고 소프트웨어(SaaS)에 따라 보안이 구성되기 때문에 서비스 특성에 따른 맞춤형 보안도 장점 중 하나다. 또 다양한 시스템을 효율적인 구성으로 서비스하는 클라우드는 자원을 빌려 쓰는 개념이다 보니 비용적 측면이나 운영적 측면에서도 매우 효과적이고 보안 사고가 날 경우에도 클라우드 업체와 이용 업체가 책임을 나눌 수 있다는 점에서도 보안 부담이 줄어드는 것도 사실이다.

클라우드 보안 요소

클라우드 보안은 보안 위협 종류와 서비스 방식에 따라 다양한 보안 대처 방법이 필요하기 때문에 이미 몇 년 전부터 보안 위협에 대비하기 위해 클라우드 발전법이 시행되었고 보안 가이드라인이 제정된 상태다. 해외에는 미국의 페드램프(FedRAMP), 싱가포르의 MTCS, 일본의 ASP.SaaS와 같은 클라우드 보안 인증 제도를 운영하고 있다. 우리나라의 경우 한국인터넷진흥원(KISA; Korea Internet & Security Agency)에서 클라우드 서비스를 위한 보안 가이드를 제시하고 있다(표2).

<표2> KISA의 클라우드를 위한 보안 가이드

출처: 한국인터넷진흥원, 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

표2를 살펴보면 전통적인 소프트웨어 시스템은 시스템과 네트워크, 데이터베이스와 같은 스토리지, 그리고 애플리케이션으로 구성되는데 클라우드 서비스는 전통적인 소프트웨어 시스템을 일부 또는 전체를 대체하는 서비스이기 때문에 전통적인 소프트웨어 시스템의 보안 기준과 크게 차이가 나지 않는 것이 특징이다(표3).

<표3> 클라우드 서비스의 보안 기술

출처: 보안공학연구논문지 - 클라우드 보안 위협요소와 기술 동향 분석

클라우드가 보안에 취약한 가장 큰 이유는 방화벽이나 네트워크 연결 등으로 제한할 수 있는 전통적인 소프트웨어 시스템에 비해 원격 접속을 허용해야 하는 속성과 클라우드 사용에 필요한 소프트웨어를 설치해야 하기 때문이다. 그리고 클라우드 서비스 업체는 보안 문제가 발생해도 외부에 공개하지 않고 처리하는 경우도 많기 때문에 보안 이슈에 대한 정보 공유도 아쉬운 것이 사실이다.

이러한 문제를 해결하기 위해서는 기존 소프트웨어 시스템의 보안 가이드나 보안 기술들을 적용해 보안 위협을 확인해야 하고 클라우드 서비스에서 독특하게 사용되는 가상화 기반 환경에 대해 집중적인 보안 위협 확인이 필요하다(그림2).

<그림2> 클라우드 가상화 기반의 보안 취약점

$D:\1981902326_1464250065.43202.png$

출처: Tech M

사례 연구

AWS(Amazon Web Services)

출처: https://www.slideshare.net/awskorea/intro-of-aws-cloud-usecase-and-strategy-61567540

AWS는 한 대의 독립된 컴퓨터를 제공하는 EC2, 파일 서버를 제공하는 S3, 데이터베이스를 제공하는 RDS 등의 서비스를 제공한다. 이러한 서비스를 조합해서 웹서비스(Web Service)를 만들게 된다(그림3). 빌딩 블록을 조립하듯이 비즈니스 요구사항에 따라 40여 개 이상의 서비스를 조립하여 유연하게 활용이 가능하다.

<그림3> AWS에서 제공하는 서비스

출처: Amazon

AWS는 세가지 방법으로 사용이 가능한데 웹서비스를 이용하는 AMC(AWS Management Console), 명령어 입력 방식인 CLI(Command Line Interface), 프로그래밍 언어 단위로 개발 API를 제공하는 SDK(Software Development Kit)가 있다. 명령어에 익숙하지 않다면 AMC를 우선적으로 사용하면 된다.

탄력적인 웹 트래픽 관리를 위한 AWS 사용은 그림4와 같이 구성할 수 있는데 로드밸런싱이나 오토스케일링을 통해 서버 부하 문제를 줄일 수 있고 확장성이 용이하다. 이러한 구성을 통해 웹사이트 리뉴얼이 용이하고 트래픽에 따라 최적의 성능이 발휘될 수 있어 AWS 구성에 따른 비용 절감 효과가 뛰어나다고 소개하고 있다.

<그림4> 웹 프래픽 관리를 위한 AWS 구성 예

출처: Amazon

그림5는 최근에 많이 적용되고 있는 빅데이터 관련 구성이다. 빅데이터 분석을 위해 수집과 저장, 분석 모듈에 필요한 AWS 컴포넌트를 사용하고 있다. 빅데이터 분석을 위해 자체적인 모듈이 사용된 경우 그림5에서 해당 모듈을 추가 적용해서 사용하면 된다.

<그림5> 빅데이터 분석을 위한 AWS 구성 예

출처: Amazon

그림6은 그림5의 빅데이터 분석을 위한 AWS 구성을 게임 빅데이터 분석에 적용한 예다. 게임 로그 데이터를 EC2와 S3를 거쳐 하둡(Hadoop)으로 구성된 EMR에서 분석하고 수분 내에 데이터 분석이 완료되도록 구성되어 있다.

<그림6> AWS의 빅데이터 분석을 게임 빅데이터 분석에 적용한 예

출처: Amazon

아마존에서는 기존 소프트웨어 시스템에서 클라우드로 전환하여 서비스하는 형태가 아닌 클라우드에서 신규 서비스를 직접 개발하는 전략을 수립하도록 권장하고 있는데 빠르고 저렴한 비용으로 개발과 배포가 가능하도록 서비스를 구성하고 있다. 이러한 서비스 제공은 다른 클라우드 서비스 업체에서도 제공하는 형태지만 특정 서비스 형태 뿐만 아니라 전체적인 클라우드 서비스를 한 곳에서 모두 제공한다는 점에서 장점이 있다.

또 아마존에서는 기존 소프트웨어 시스템에서 전환하거나 신규 서비스를 제공하더라도 유용한 기능만 우선 적용하도록 권장하고 있는데 자체적으로 구성해도 큰 무리가 없는 시스템까지 모두 클라우드로 전환할 필요는 없다는 이유 때문이다. 클라우드 서비스는 서비스 단위의 모듈 형태로 제공되기 때문에 전체 서비스를 도입할 필요는 없어 기존 인프라나 자체적으로 구성이 가능한 서비스는 그대로 두고 클라우드와 역할을 분리하여 구성하는 것이 좋다(그림7).

<그림7> 하이브리드 클라우드 서비스의 예

출처: Amazon

기대 효과와 결론

클라우드 보안의 경우 기존 서비스와 크게 차이를 보이지 않기 때문에 가급적 기존 보안 가이드나 보안 기술을 이용해 보안 구성을 하는 것이 일차적인 목표다. 이렇게 구성된 보안 기준에 클라우드를 적용해서 나타나는 보안 요소에 대해서는 적용하는 클라우드 서비스 업체가 자세히 상의하는 것이 가장 현명한 방법이다. 클라우드는 기존에 만들어진 형태에 새롭게 만드는 것이 아니고 내가 가진 서비스와 조립을 하는 형태이기 때문이다. 조립에서 나타날 수 있는 보안 요소에 대해 철저히 확인한다면 클라우드 적용으로 인해 발생할 수 있는 보안 문제를 줄일 수 있을 것이다.

Keyword: software engineering, cloud service, paas, saas, iaas, amazon web service, cloud software architecture, cloud security

2017년 3월 30일 목요일

FRACAS

FRACAS는 고장 데이터를 수집하고, 고장 원인을 결정하기 위한 절차와 수행된 개선 조치에 대한 문서를 제공하는데 목적을 갖는다.

또한, 고장 보고 및 분석은 제품의 신뢰성 및 유지보수성이 요구사항에 부합되고 유지된다는 것을 보장하기 위하여 필요로 한다. FRACAS의 적용은 신규 시스템 개발 및 생산에 대하여 고장 반복 및 재발을 제어하기 위한 핵심 요소이다. FRACAS 절차는 고장이 정확하게 보고되고 철저히 분석되었다는 것과 개선 조치가 고장 재발을 감소하고 예방하기 위하여 적정한 시기에 수행되었음을 보장하기 위한 규정 또는 조항을 포함해야 한다.

무엇이 고장을 발행하였는가?
언제 고장이 발생하였는가?
어떻게 고장이 발생하였는가?
왜 고장이 발생하였는가?
이후에 발생할 고장을 어떻게 방지 또는 제거 할 것인가?

FRACAS 흐름

FRACAS 기법의 수행에 대한 절차가 완료 되었다면, 실제로 해당 기법에 대한 입력물은 충분하였는지, 해당 절차는 준수하였는지에 평가를 수행해야 한다. 또한, 수행 결과에 대한 산출물 리스트는 적절한지에 대한 평가를 최종적으로 점검하기 위해서 본 가이드에서는 제시하는 위험원 분석 기법에 대한 검증 표를 제공 한다. 따라서 FRACAS 기법의 수행에 대한 검증은 [표 1]을 통해서 수행된다.

표 1. FRACAS 주요 항목 및 산출물 체크 리스트

피드 구독하기: 글 ( Atom )