2017년 4월 4일 화요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

사례 전 확인 사항

클라우드(Cloud) 보안 개념

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

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

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

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

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

출처: 미래창조과학부

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

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로 전자 메일을 보내주십시오. 고맙습니다.

피드 구독하기: 글 ( Atom )