산업 내에서 직접적인 소프트웨어 활용이 많아지면서 소프트웨어의 안전성에 대한 고민이 다른 측면으로 다시 시작되었다. 소프트웨어가 오류없이 동작하는데 초점이 맞춰진 예전에는 소프트웨어 테스팅이나 보안 중심으로 안전성을 확인했지만 지금은 소프트웨어가 산업 자체에 영향을 주는 경우가 많아 이 외에도 다양한 관점으로 안전성을 살펴볼 필요가 생겼다. 2회에 걸쳐 소프트웨어 안전성 분석에 대해 알아보고자 하며 이번 회에서는 소프트웨어 안전성 분석의 개념 중심으로 살펴보도록 한다.
소프트웨어 관점의 소프트웨어 안전성 분석
소프트웨어가 사용되면서 사용자들에게 가장 큰 고민은 소프트웨어 오류였다. 소프트웨어를 개발하면서 나타나는 오류는 사용자뿐만 아니라 개발을 완료한 개발자 입장에서도 많은 시간과 노력을 들여야 하는 경우가 많았다. 또한 소프트웨어를 사용하는 범위가 산업의 기반 시설들을 다루는 경우보다는 대체로 오퍼레이션과 관련된 것들이 많아 소프트웨어의 안전성이 좋지 않아도 산업 자체가 동작하는데 큰 무리는 없었다. 그래도 소프트웨어의 안전성을 높이기 위해 글로벌 기업을 중심으로 많은 예산과 인력을 투입하였고 다양한 소프트웨어 분석 도구와 기술을 개발하여 대처하였다. 개발 과정에서부터 보안 안전성을 고려하여 개발하는 시큐어 소프트웨어 개발 방법론(Secure Software Development Methodology)도 소프트웨어 안전성이나 보안 위협을 고려한 방법이라고 할 수 있다.
과거에 많이 사용된 소프트웨어 안전성 분석 방법은 크게 화이트박스 테스팅(White box Testing)과 블랙박스 테스팅(Black box Testing)으로 볼 수 있다. 화이트박스 테스팅은 분석 대상이 되는 소프트웨어의 소스코드를 대상으로 취약성이 발생할 수 있는 패턴을 분석하거나 버퍼 오버플로우와 포맷 스트링 취약점 등을 점검하여 소프트웨어가 적절하게 데이터를 처리하는지 점검하는 방식이다. 블랙박스 테스팅은 소프트웨어에 데이터를 입력하고 소프트웨어의 동작을 모니터링하면서 안전성을 점검한다. 블랙박스 테스팅은 소스코드가 반드시 필요하지는 않고 화이트박스 테스팅이 발견하지 못하는 예외적인 상황을 유발시켜 다양한 형태의 안전성 분석을 할 수 있지만 시간과 비용이 많이 드는 것이 단점이기 때문에 효율적인 테스팅을 위해서 자동화된 안전성 분석 도구가 이용되는 경우가 많다(그림1).
<그림1> 블랙박스 테스트와 화이트박스 테스트
소프트웨어의 안전성 분석을 위해서는 분석 대상 소프트웨어의 수준에 따라 분석 방법을 결정하는데 실행 프로그램만 있는 경우에는 블랙박스 테스팅, 소스코드가 제공되는 경우에는 화이트박스 테스팅을 수행하는 경우가 많다. 블랙박스 테스팅과 리버스 엔지니어링(Reverse Engineering)을 접목한 그레이박스 테스팅(Gray box Testing)도 알려져 있다(표1).
<표1> 소프트웨어 안전성 분석 방법의 장단점
출처: 한국전자통신연구원(ETRI)
블랙박스 테스팅과 화이트박스 테스팅을 활용하는 방법도 여러가지가 있다. 먼저 소프트웨어에 다양한 입력을 하여 실행시킨 후 결과를 살펴보는 동적 분석(Dynamic Analysis)과 소프트웨어를 실행시키지 않고 소스 코드의 내용으로 판단하는 정적 분석(Static Analysis)이 있다. 블랙박스 테스트와 화이트박스 테스트를 이 두가지 방법으로 구분하여 안전성을 테스트 할 수 있다(표2).
<표2> 정적 분석과 동적 분석
출처: 데이터베이스진흥원
소프트웨어 안전성 확인을 위해서 동적 분석은 소프트웨어의 특성에 따라 다양한 방법으로 확인해야 하지만 정적 분석은 요구사항을 받아 개발을 하면서 확인하기 때문에 요구사항을 받은 후 진행되는 프로세스에 따라 안전성 확인 방법이 어느 정도 정해져 있다.
댓글 없음 :
댓글 쓰기