사이버 공격은 오늘날 이미 잘 보호되고 있는 IT 네트워크 인프라스트럭처에서 벗어나 일상적인 소프트웨어로 옮겨가고 있으며, 동시에 기업이나 조직, 또한 일반 개인들의 취약점을 증가시키고 있다. 그러나 여전히 소프트웨어는 생산성 향상을 위해 도입되어 수많은 민감한 데이터를 저장하고 있다. 또한, 소프트웨어 개발 과정에 있어 보안은 오랫동안 ‘나중 문제’로 여겨져 왔기 때문에 사이버 범죄자들이 그러한 데이터를 탈취하는 것은 어렵지 않은 일이다.
소프트웨어 보안 관리의 불명예스러운 방법인 릴리스앤패치(release-and-patch)는 더 이상 ‘일 처리 방식(modus operandi)’이 될 수 없다. 전문가 커뮤니티는 이러한 불합리한 사이클에서 탈출하기 위해서는 시스템적인 접근이 필요하다고 보고 있다. 이와 관련해 본 필자는 소프트웨어 개발 라이프사이클(software development lifecycle ; SDLC)의 이해관계자들의 경험과 전문 지식을 반영하는 안전한 소프트웨어 개발을 위한 10가지 베스트 프랙티스(best practice)를 간추려봤다. 아울러 SDLC 이해관계자들이란 분석가, 설계자, 코드 작성자, 테스트 담당자, 감사원, 운영 담당자 및 관리자들 등을 의미한다.
고객의 신뢰, 브랜드를 보호하라
사이버 범죄자들이 진화하고 있는 만큼 이에 대응하는 이들도 진화해야만 한다. 대응자들과 그들의 조직은 궁극적으로 그들은 보안 침해에 책임이 있기 때문에 사이버범죄자들 보다 한발 앞서있어야만 한다. 고객 정보 노출, 서비스 거부, 비즈니스 영속성에 대한 위협 등으로 이어지는 이러한 침해 사건들은 참혹한 재정 손실을 가져올 수 있다. 그러나 조직(또는 기업)의 가장 심각한 손실은 브랜드에 대한 고객의 믿음과 신뢰 상실이 될 것이다. 이러한 상실은 돌이킬 수 없는 것이며 실질적인 금전적인 손해를 산정하는 것도 불가능하다. 기본적으로 진정으로 안전한 소프트웨어 생산을 위해서는 조직이 고객들을 보호할 의무가 있다는 인식이 강력한 동기가 되어야만 한다.
비즈니스를 이해하고 안전한 솔루션으로 지원하라
“왜 브레이크가 개발되었는가”라는 질문에 대한 답은 두 가지가 될 수 있다. 하나는 “자동차 사고를 방지하기 위해서”일 것이고 다른 하나는 “자동차를 더욱 빠르게 하기 위해서”일 것이다. 이와 마찬가지로 보안은 비즈니스가 무너지지 않게 할 수 있으며 비즈니스가 더욱 빨라지게 할 수도 있다. 이를 위해서는 규제 및 컴플라이언스 요건, 해당 리스크, 사용된 아키텍처, 회사의 기술적인 통제, 사용자들의 훈련 및 교육을 통한 비즈니스에 대한 완전한 이해가 필요하다.
기술과 소프트웨어를 이해하라
네트워크 분리, 호스트 강화, 공개 키 인프라스트럭처 등 기존 인프라스트럭처의 구성 요소에 대한 완전한 이해가 필요하다. 소프트웨어의 도입 및 배치가 운영적인 측면에서 기능적인지, 또는 기존의 컴퓨팅 환경의 보안을 약화시키지는 않는지를 분명히 해야 하기 때문이다. 소프트웨어와 함께 기술 구성부분의 상호작용에 대한 이해는 보안 전반에 대한 영향을 판단하는 데 있어 필수적이며 소프트웨어의 보안을 개선하기 위한 결정을 뒷받침할 수 있다. 아울러 소프트웨어 구매 시, ‘보안’ 기능에 관한 업체의 주장과 자신의 조직 내 구현 가능성을 확인하는 것이 필수다.
가버넌스, 규제, 프라이버시를 준수하라.
오늘날 많은 업계들이 규제를 받고 있다. GRC, 즉 가버넌스·리스크·컴플라이언스(Governance, Risk and Compliance)는 소프트웨어 보안 내의 규제와 프라이버시 요건사항을 충족시키는 수단이다. 비즈니스, 필요한 보안 통제에 대한 매핑, 소프트웨어의 보안 통제 구현 후 남게 되는 리스크, 규제 및 프라이버시 요건 사항 측면에서의 컴플라이언스 등을 좌우하는 내외부적인 정책을 반드시 이해해야만 한다.
소프트웨어 보안의 기본 방침을 알아야만 한다.
안전한 소프트웨어에는 모든 이들이 친숙하게 이해해야만 하는 몇 가지 방침이 있다. 노출 방지(기밀성, confidentiality), 변경 방지(무결성, integrity), 요청자 확인(인증, authentication), 요청자의 권한 및 특권(인가, authorization), 기록 증거 구축 능력(감사, auditing), 설정/세션/예외 관리가 그것이다. 이러한 기본 방침에 대한 지식을 갖추고 이러한 방침들이 어떻게 소프트웨어에 구현될 수 있는지 알아야만 한다. 이를 통해 이러한 기본 방침을 뒷받침하는 메커니즘의 전후 관계에 관해 이해할 수 있기 때문이다. 또한 이와 같은 기본 방침을 뒷받침하는 메커니즘은 암호화, 해싱, 로드밸런싱, 모니터링, 패스워드, 토큰, 생체인식 기능, 로깅, 설정 및 감사 통제 등이다.
민감한 정보의 보호를 확인하라.
조직이 막대한 가치를 두고 있어 상실, 손해, 또는 사업 붕괴와 같은 결과를 가져올 수 있는 모든 정보는 손상될 수 있는 만큼 민감하게 다뤄져야만 한다. 그러나 건강 기록이나 신용카드 정보와 같은 특정한 데이터 요소들의 민감성은 쉽게 알 수 있는 반면, 다른 것들은 그렇게 뚜렷하지 않은 경우가 있다. 데이터 노출, 변경, 파괴에 대비해 데이터 분류와 보호 메커니즘을 반드시 고려해야만 한다.
특히 데이터 분류는 데이터가 생성, 수정, 저장, 전송, 또는 보강될 때 이 데이터의 민감성 수준을 정하는 의도적인 결정이다. 따라서 민감한 정보를 전송하고 처리하며 또는 저장하는 소프트웨어 역시 빌트인 보안 컨트롤을 탑재하고 있어야만 한다.
안전한 기능으로 소프트웨어를 ‘설계’하라.
어떤 사람은 코드에서 보안 이슈를 찾는데 지나치게 치중하는 반면 어떤 사람은 전체 취약성의 종류에서 누락된 리스크를 쫓는다. 그러나 소프트웨어 개발 라이프사이클의 설계 단계에서 설계나 비즈니스 로직 취약점과 같은 다른 문제에서의 보안 이슈들을 위협 수행과 남용 케이스 모델(abuse case model)을 통해 면밀히 살펴볼 필요가 있다. 반복구조 기술인 위협 모델링(Threat modeling)은 소프트웨어의 보안 대상을 확인하고 또 그것을 프로파일링함으로써 위협을 확인하기 위해 이용된다.
위협 모델링의 일부인 공격 표면 분석(Attack surface analysis)은 소프트웨어를 의심스러운 사용자에게 노출함으로써 수행된다. 이 외에 권장할만한 안전한 설계 공식의 예를 앞서 표 1과 같이 정리했다.
안전한 기능의 소프트웨어를 ‘개발’하라.
컴플라이어(compiler)나 인터프리터(interpreter)가 이해할 수 있는 신택스 구조(syntax construct)로 설계 구조가 전환될 때 보안 기능이 필수적으로 처리되어야만 한다. 개발되고 나면 소프트웨어 보안의 기본 방침을 처리하는 컨트롤은 배치와 유효성을 위해 보안 코드 리뷰어와 보안 테스팅에 의해 인증되어야만 한다. 또한 이것은 기능성 테스트와 함께 보완되어야만 한다. 보안 코드 리뷰의 유효성을 확보하기 위해서는 리뷰 대상의 범위 정의, 리뷰 범위, 코딩 표준, 보안 코딩 요건, 역할과 책임에 따른 코드 리뷰 프로세스, 사전 정의되어야만 하는 메커니즘 시행 등이 충족되어야만 한다. 아울러 테스트는 소프트웨어의 보안을 약화시키는 설정 문제를 완화하기위해 프로덕션 환경의 설정을 모방(에뮬레이트, emulate)한 테스팅 환경에서 수행되어야만 한다.
보안 기능의 소프트웨어를 도입하라.
안전한 도입은 소프트웨어가 기능적으로나 운영적으로 모두 안전하다는 것을 보장한다. 즉, 소프트웨어가 심층방어(defense-in-depth)로 도입된다는 것으로, 공격 범위가 부적절한 배포, 변경, 또는 설정관리에 의해 증가하지 않는다는 것을 의미한다. 또한 공격자 관점에서의 평가가 도입 전에, 혹은 도입 증시 수행된다는 것을 의미하는 것이기도 하다.
개발 및 테스트 환경에서 어떠한 보안 문제도 없이 기능하던 소프트웨어가 보다 까다로운 프로덕션 환경에 도입될 때 종종 문제를 겪는다. 이러한 상당수의 경우에 관한 사후 분석들은 개발과 테스트 환경이 프로덕션 환경을 시뮬레이트하지 않는다는 것을 보여주고 있다. 따라서 프로덕션 환경에 행해진 변경은 적절한 변경관리 절차를 통해 개발과 테스트 환경에도 갱신되어야만 한다.
릴리스 관리 또한 “재생 버그(regenerative bugs)”라고 불리는 현상, 즉 다음 릴리스에 다시 나타나는 소프트웨어 결함을 피하기 위해 적절한 소스 코드 통제와 버전관리(versioning)가 포함되어야만 한다. 코딩 결함, 즉 버그는 테스트 환경에서 탐지되어 수정된다. 그리고 나면 소프트웨어는 개발 환경에서 갱신되지 않은 채 프로덕션으로 진행된다. 게다가 취약점 평가와 모의해킹 테스트는 다단계 사전 프로덕션 환경에서, 또는 필요할 경우 프로덕션 환경에서 엄격한 통제로 수행된다.
안전한 소프트웨어 구축 방법을 학습하고 교육하라.
찰스 디킨스는 “변화가 변화를 낳는다(Change begets change)”고 했다. 교육받은 사람이 차례로 다른 이들을 교육한다면 시급한 보안 문화 변화를 가져오는데 복합적인 효과를 가져와 자동적으로 교육을 통한 소프트웨어 보안이 기본 요소가 되는 문화를 가져올 것이다. 정보보호는 우리 모두의 일이기 때문이다.
<글 : 마노 폴(Mano Paul) CSSLP, CISSP, AMBCI, MCAD, MCSD, Network+, ECSA, (ISC)2 소프트웨어 어슈어런스 고문(kchung@isc2.org)>
[월간 정보보호21c 통권 제105호 (info@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
[2024-05-12] 
.jpg)
