2017년 4월 6일 목요일

소프트웨어의 안전성

소프트웨어의 안전성은 과거 소프트웨어 중심의 프로세스 안전성 관점에서 시스템과 소프트웨어를 동시에 바라보는 개념으로 변화하고 있다. 이같은 변화는 소프트웨어를 전체 시스템의 일부로 인식하여 전체 시스템 레벨에서 위험성 분석을 선행하고, 시스템 위험분석 결과로 도출된 시스템 안전요구사항을 바탕으로 소프트웨어 안전요구사항을 도출해야 한다는 것을 의미한다.

소프트웨어 안전성을 보증한다는 의미는 소프트웨어가 가지고 있는 여러 가지 속성 중에서 특히 안전기능(Safety Function)이 올바르게 선정되었는지를 확인할 수 있어야 하고, 최종 개발 결과물이 수행하는 안전기능이 정상적으로 작동하는가를 확인하는 것이다.

예를 들어 “원자로를 안전하게 보호할 수 있고, 위험성을 알릴 수 있는 SW 를 개발하자” 라는 안전 요구사항을 기반으로 프로젝트를 시작한다고 하면 먼저 사업계획서를 만들고, 요구사항 명세서를 정리하고, 상세기술 명세서를 만들고, 소스코드를 만드는 등 여러 엔지니어들의 손과 머리를 거치게 된다. 하지만 작업이 끝난 후엔 처음에 의도했던 바와 전혀 다른 결과물이 나올 수 있게 된다. 그렇기 때문에 처음에 의도한 안전 요구사항과 최종 결과물의 일치성을 확보하고, 특히 안전기능(Safety Function)이 원래 의도한대로 개발되었는가를 반드시 검사해야 한다.

안전 소프트웨어 개발이라는 목표 달성이라는 측면에서 볼 때 가장 중요한 요소는 세가지로 구분된다.

첫째, SW 개발 안전 수명주기에 대한 이해이다. SW 개발 안전 수명주기는 개발 조직 내의 모든 개발자가 숙지하고 각 단계 별 결과물들을 사전에 계획된 바에 따라 생성해 나가야 하는 것인데 수명주기는 경우에 따라 국제표준에서 제시하는 가이드를 일부 테일러링하여 개발 프로젝트에 최적화시킬 수 있다.

둘째, 시스템 및 소프트웨어 위험분석 기법에 대한 이해가 필요하다. 안전한 소프트웨어 개발은 시스템 위험분석을 통하여 도출된 시스템 안전기능 요구사항을 근간으로 개발이 이루어 지기 때문이다. 시스템 레벨에서 도출된 안전기능 요구사항 중에서 소프트웨어가 수행하여야 하는 요구사항들이 소프트웨어 관점에서 명세화되고 이를 바탕으로 소프트웨어가 구현되어야 한다.

셋째, 소프트웨어 안전기능이 의도한 바와 같이 구현이 되었는지를 확인하는 올바른 검증 시험 방법을 적용하는 것이 중요하다. 소프트웨어의 안전성을 검증하는 시험은 디바이스 레벨에서 이루어지며, 검증의 목표는 시스템 안전 요구사항 및 소프트웨어 안전 요구사항이 원래 의도와 같이 구현되었는지를 검증하는 것이기 때문이다.


안전 기능으로 다뤄지는 항목들은 대개 표의 범주를 벗어나지 않으며, 아래 항목에 있는 부분들은 최상위 안전등급으로 다뤄져야 한다.

표. Safety Critical 소프트웨어 유형 

2017년 4월 5일 수요일

안전기능 요구사항과 안전무결성 요구사항

안전기능 요구사항은 위험원 분석을 통해 도출되고, 안전무결성 요구사항은 위험성 평가를 통해 도출된다. 안전 무결성(Safety Integrity)은 주어진 모든 조건하에 있는 안전관련 시스템이 주어진 시간 내에 요구되는 안전기능을 만족스럽게 수행할 수 있는 확률로 정의된다. 안전무결성수준이 높을수록 해당 장비 또는 시스템의 고장 발생 가능성은 낮아진다.

이와 같이 어떠한 기술로 구현된 시스템이 안전기능을 수행하면 안전관련시스템(SRS, Safety Related System)이라고 한다. 안전관련시스템은 장치 또는 시스템을 제어하는 기존 시스템과 분리하여 작동하거나, 그 안에 포함되어 일부로서 작동하거나, 기존 제어시스템 그 자체가 안전관련시스템의 역할을 하기도 한다. 안전무결성 요구사항 수준이 높을수록 안전관련 시스템이 더욱 엄격하게 적용해야 한다. 표는 기능안전성 관련 시스템의 사례를 보여준다.

표. 기능 안전에 의존하는 안전관련시스템 예시 

이러한 시스템은 보통 복잡하고, 모든 고장 모드를 완전하게 사전에 예측하거나 발생 가능한 모든 경우를 사전에 테스트하는 것은 현실적으로 불가능하다. 테스트는 항상 필수적으로 수행해야 하지만, 안전을 위한 충분한 성능을 예측 및 시험하는 것은 매우 어려운 일이다. 기능 안전성을 달성하기 위해서는 위험한 고장을 방지하거나, 고장이 발생할 때 그것을 제어하는 방식으로 시스템을 설계해야 한다. 

기능안전성과 안전한 시스템

기능안전성은 시스템이나 장비에 의해 좌우되는 전체적인 안전성의 일부분으로 안전 기능을 수행하는 시스템이나 장치는 조건 입력에 대해 사전에 정의한 대로 의도된 반응이 올바르게 수행되어야 한다.

전기 모터의 권선에 열 센서를 달아 과열되기 전에 동력을 차단하기 위한 고온 방지 장치는 기능안전성의 한 예로 볼 수 있다. 그러나 고온을 견디기 위해 특수화된 절연체를 입히는 것은 기능 안전성에 포함되지 않는다. 안전의 예시이고 동일한 위험원에 대해 방어 또는 보호할 수 있는 위험 방지 대책에는 해당하지만 기능안전성이라고 말하지는 않는다.

기능안전성은 시스템 전체적인 측면과 상호 작용하는 환경을 고려하지 않고서는 결정될 수 없다. 안전 기능은 그 입력에 응답하여 시스템 또는 올바르게 작동하는 장치로 구성되며 유해 사건을 방지하거나 유해 사건의 결과를 감소, 방지하기 위하여 제어 기기 및 장치를 활성화하여 잠재적으로 발생 가능한 위험한 상황을 사전에 검출하는 활성화된 기능이다.

그림. 기능안전성과 안전관련 시스템(SRS)의 관계 


그림은 기능안전성과 안전관련 시스템의 관계를 보여준다. Non-Safety System 에서는 별도의 Functional Safety 를 요구하지 않지만 안전관련시스템(SRS, Safety Related System)에서는 안전기능이 반드시 필요하다.

일반적으로 안전 설비 및 사전 정의된 환경에서 작동하도록 만들어진 안전 기능인 제어 시스템의 주요 위험원은 분석자 또는 개발자에 의한 위험원 분석을 통해 사전에 식별되어야 한다. 이 분석을 통해서 주요 위험원에 대한 적절한 보호를 위해 기능안전성이 꼭 필요한 것인지 결정하여 설계 시에 적절한 방법을 고려하여 구현할 수 있도록 해야 한다. 기능안전성은 위험원을 다루는 하나의 방법일 뿐이고 설계를 통해 고유의 안전성을 확보하는 것과 같이 위험원을 제거하거나 감소시키는 방법이 가장 중요한 것이다.

안전관련(Safety Related)이라는 용어는 특정한 기능을 수행하거나 위험성을 허용 가능한 수준으로 유지되도록 보증하는 안전 기능들을 수행하는 시스템을 설명하는데 사용한다.

수용 또는 허용 가능한 위험(Risk)

안전하다고 해도 반드시 약간의 위험성이 남아 있기 마련이기 때문에 절대적으로 안전하다는 의미의 절대 안전을 주장할 수는 없다. 반드시 어떤 크기의 위험성이 남아 있고 항상 사고는 일어날 수 있다는 것을 의미를 포함한다. 남아 있는 위험성, 즉 수용할 수 있거나 허용할 수 있는 위험성은 일반적으로 잔류 위험성(residual risk)이라고 일컬어진다.

여기에서 무엇을 가지고 안전하다고 할 것인가 할 때에 두 개의 다른 단어가 나온다. 하나는 「수용 가능한 위험성」(Acceptable Risk)이고, 다른 하나는 「허용 가능한 위험성」(Tolerable Risk)이다.

그림. 수용 또는 허용 가능한 위험성과 안전 

제품 또는 시스템을 설계하는 초기 단계에서는 여러 가지 큰 위험성(risk)이 존재하고 안전상 불안한 상황이다. 그래서 각각의 위험성에 대하여 설계, 제작 및 운영 단계에서 각종 안전 기능 또는 안전 대책을 마련하여 위험성의 크기를 줄여야 한다. 

누가 생각하더라도 이 정도 크기의 위험성만 존재한다면 문제가 되지 않는 상태를 수용 가능한 위험성이라고 할 수 있다. 한 마디로 위험성이 매우 적거나 낮아졌기 때문에 문제가 되지 않은 위험성 영역이 바로 진정으로 안전한 상태(Safety State)라고 말할 수 있다. 

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)에 따라 보안이 구성되기 때문에 서비스 특성에 따른 맞춤형 보안도 장점 중 하나다. 또 다양한 시스템을 효율적인 구성으로 서비스하는 클라우드는 자원을 빌려 쓰는 개념이다 보니 비용적 측면이나 운영적 측면에서도 매우 효과적이고 보안 사고가 날 경우에도 클라우드 업체와 이용 업체가 책임을 나눌 수 있다는 점에서도 보안 부담이 줄어드는 것도 사실이다.