하루가 멀다 하고 해킹 사고가 뉴스에 오르내리고 있습니다. 최근에는 숙박 앱이 해킹되어 개인 정보와 숙박 기록까지 유출된 것으로 추정되어 한바탕 소동이 일고 있습니다. 또 중국에서는 최근의 국내 군사 움직임을 문제 삼아 보복성 해킹 공격을 예고하고 또 실행하기도 했습니다.
이러한 환경에서 과연 우리의 IT 시스템은 얼마나 안전할 수 있을까요? 전문가들은 보안은 100% 안전할 수 없다고 말합니다. 그래서 기업의 보안담당자들은 치솟아만 가는 해킹의 위협 속에서 “제발 우리 회사는 공격 대상이 안됐으면 좋겠다”라든지, “설마, 우리 회사를 공격하겠어?”라는 기대와 희망이 교차하리라 생각됩니다.
물론 이미 다양한 방법으로 해킹 공격에 대응을 하는 회사도 있습니다. 또는 열심히 기도를 하고 있을 수도 있겠네요. 그래서 지금부터는 해킹 공격에 대응할 수 있는 방법 중 가장 근본적인 방법인 시큐어 코딩(Secure Coding)에 대해 이야기를 해보겠습니다.
본격적으로 이야기를 시작하기에 앞서, 이번 글에서 다루는 해킹 공격의 유형에 대해서 간단하게 짚고 넘어가겠습니다. 해킹에는 다양한 방법과 기법이 있습니다. ‘어디를 공격 대상으로 삼는가?’로 분류할 수도 있고, 공격 대상을 어떠한 경로로 해킹을 시도하는지, 즉 침투 경로로 분류할 수도 있습니다.
이렇게 분류한다면 네트워크 해킹, 시스템 해킹, 애플리케이션 해킹, 하드웨어 해킹, 심지어는 사람을 속이는 사회공학까지 너무나도 다양한 경로로 해킹 시도가 가능한 것을 알 수 있습니다. 이번 글에서는 ‘시큐어 코딩’에 대한 이야기인 만큼, 소프트웨어 해킹에 초점을 맞춰서 어떻게 하면 보다 안전한 소프트웨어를 개발하여 다양한 해킹 공격에 대비할 수 있을지 고민해 보겠습니다.
그리고 이 단계에서는 앞으로 본격적인 개발에 들어갈 개발자들에게 시큐어 코딩 가이드와 필요한 공통 모듈의 사용방법을 함께 교육을 시켜야 합니다. 보안뿐만이 아니라 일반적인 개발 과정에서 유지 보수성을 향상시키기 위해서라도 코딩 표준이나, 애플리케이션 프레임워크 사용 방법에 대해서는 교육을 시켜야 하기 때문에 이러한 과정에 보안과 관련된 내용을 포함시킵니다.
또 한가지 덧붙이자면, 아직 국내에서는 적용되는 사례가 많지는 않지만 설계서(또는 화면 설계서) 내에 보안 관련 요구 사항들을 명시하는 것입니다.
예를 들어 화면에 입력 값을 받는 곳에 SQL Injection 예방을 위한 입력 값 검증을 수행하도록 명시를 한다면 개발 시 개발자가 굳이 보안에 대해서 별도의 고민을 하지 않아도 되는 효과가 있습니다. 물론 보다 좋은 방법은 개발자가 아예 고민을 하지 않도록 애플리케이션 프레임워크 단에서 알아서 검증이 되도록 아키텍처를 설계하는 것이겠지만요.
실제 위와 같이 설계문서에 보안 요구 사항들을 반영을 하였을 경우, 그렇지 않았을 경우와 비교했을 때 모의해킹(취약점 점검)을 수행하면 발견되는 보안 취약점의 개수는 보안 요구 사항이 설계에 반영되었을 경우 현저하게 적습니다.
그리고 도구를 활용하는 방법 외에 마이크로소프트에서 활용하는 것으로 알려진 방법은 짝 프로그래밍(Pair Programming)입니다. 개발자 두 명이 나란히 앉아서 개발을 함께 진행하는 것입니다. 두 명이 함께 개발을 진행하게 되면 서로 놓치는 부분을 보완해주는 효과가 있습니다.
추가적으로, 단위 개발이 완료될 경우 공식적인 코드 리뷰 시간을 가지기도 합니다. 이때는 다른 개발자들이 모두 함께 모여 각자가 개발한 소스 코드를 화면에 띄워놓고 서로 토론을 하며 코드 품질을 높여나가게 됩니다. 하지만 이러한 방식은 국내 사정이나 정서에 맞지 않아서 널리 사용되지는 않지만 해외에서는 코드의 품질을 향상시키는 방법으로 많이 활용되고 있습니다. (물론 국내에도 짝 프로그래밍과 코드 리뷰 과정을 거치는 경우가 있습니다.)
결국 소스 코드의 ‘품질’을 높이는데 활용되는 다양한 방법들이 동일하게 보안을 높이는데도 사용되는 것을 알 수 있습니다. 보안도 결국은 품질의 한 요소이니까요.
예를 들어, 입력 값 검증을 하지 못해 발생하는 SQL Injection의 경우는 사람보다는 자동화된 점검 도구가 훨씬 더 손쉽게 취약점을 발견하지만, 일반 사용자는 특정 권한을 가진 화면을 볼 수 없다는 권한 관리 요건을 점검할 때는 아직까지는 사람이 조금 더 손쉽게 점검을 할 수 있습니다.
따라서 보통 수작업이 포함되는 모의해킹(또는 취약점 점검)을 별도로 수행합니다. 대규모 회사의 경우는 이러한 모의해킹을 전담하여 수행하는 별도의 조직을 운영하기도 합니다. 흔히 Red Team으로 부르는 이러한 조직은 기업•기관의 다양한 소프트웨어에 대해 상시적으로 취약점 점검을 수행하는 역할을 갖습니다.
l 소프트웨어 개발 단계 별 결함 수정 비용 분석
(출처: The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002.5, NIST)
이 연구 결과를 놓고 보면, 개발 초기 단계에서부터 안전한 소프트웨어를 위해 투자하는 비용은 전체적으로 봤을 때 오히려 비용을 절감하는 효과를 가져옵니다.
최근에 발생하는 각종 해킹 관련된 사고들을 돌이켜보면, 비단 비용만의 문제가 아님을 느낄 수 있습니다. 기업의 존폐가 결정될 수도 있는 이용자 대거 이탈과 더불어 법적인 처벌까지 받을 수 있는 최근의 환경에서는 보다 안전한 소프트웨어 개발은 선택이 아닌 필수가 되어가고 있습니다.
앞서 설명한 내용은 가장 일반적인 개발 절차를 따랐습니다. 세상에는 다양한 개발 방법론이 있으며 절차대로 개발이 되지 않는 소프트웨어도 많이 있습니다. 하지만 한가지 분명한 것은, 보안을 개발 과정에 녹여내지 못하고 별도로 떼어놓고 고민을 하고 있다면 그 고민은 영원히 풀리지 않는 숙제가 될 것입니다.
품질 결함이 있으면 당연히 제품 출시를 못하는 것처럼 보안도 품질의 한 부분이 되어야 합니다. 보안을 소프트웨어 품질의 한 요소로 명확히 인지하고 전반적인 품질관리 체계 안으로 녹여서 관리를 해야 합니다. 그렇게 해서, 보안 취약점(품질 결함)이 있을 경우 제품 출시를 못하게 되는 것이 당연한 것으로 인식되어야 할 것입니다.
글 | LG CNS 보안컨설팅팀
[관련 글 보기]
* 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 LG CNS 블로그에 저작권이 있습니다.
* 해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.