최근 인공지능, 빅데이터, VR에 대한 소식이 많이 들리고 있는데요. 이런 것들이 점차 하드웨어보다 소프트웨어에 대한 중요성이 더욱 커지고 있는 현상을 보여주고 있는 것이 아닐까 합니다.

이러한 현상과 함께 이곳 저곳에서 해킹을 당했다는 소식도 많이 들려와 보안을 업으로 하는 입장에서 안타까움이 큽니다.

2010년도 들어오면서 정부에서 안전한 개발에 대한 지원을 하고 있어 보다 안전한 소프트웨어가 확산될 수 있기를 기대하고 있습니다. 이러한 상황에서 시큐어 코딩이(Secure Coding)라는 용어가 확대되고 있는데요. 이를 계기로 보안에 대해서 좀 더 깊이있게 생각해 보고자 합니다.

시큐어 코딩이란?

행정자치부 시큐어 코딩 가이드를 참조하면 시큐어 코딩이란 해킹 등 사이버 공격의 원인이 되는 보안 약점을 소프트웨어 개발단계에서 사전에 제거해 안전한 소프트웨어를 개발하는 소프트웨어 개발기법을 의미한다고 되어 있습니다.

소프트웨어에 대한 보안 강화의 필요성이 확산되면서 전자정부에서는 시큐어 코딩의 의무화가 요구사항으로 제시되고 있는데요. 이러한 활동을 점검하고 지원하기 위한 다양한 소스코드 점검 툴들이 있습니다.

예전에는 정적 소스코드 분석 도구 등을 이용하여 보안 취약점을 점검하였으나, 최근에는 국정원의 CC 인증 제품에 “소스코드 보안약점 분석 도구”라는 구분으로 인증을 수행하고 있는데요. 이를 활용하여 제품 선정 시 참고하면 도움이 될 수 있습니다. 아래의 제품은 국내에서 인증 받은 제품을 검색하여 조회한 내용이므로 참고하시기 바랍니다.

또한 상용 제품이 아닌 툴을 이용하여 시큐어 코딩을 하기 위해 행정자치부에서 다양한 가이드를 제공하고, 공개 소프트웨어를 활용한 소프트웨어 개발보안 진단 가이드 등의 무료 배포가 진행되고 있습니다.

가이드를 통해 별도로 진단비용을 확보하기 어려운 소규모 사업이나 제도 도입 전에 구축된 정보 시스템도 유지보수 등을 통해 개선 가능할 것으로 기대됩니다. 다만, 현실적 입장에서는 상용제품을 통해 기술지원을 받지 못하는 부분에 대해서는 염려가 되는 점도 있습니다.

시큐어 코딩 현실은?

안전한 소프트웨어 개발을 위해 가장 이상적인 방법은 개발자가 그 취약성에 대해 먼저 인지하고, 취약성을 막을 수 있는 개발을 하는 것입니다. 그러나 해커는 막는 사람의 생각을 뛰어 넘는 새로운 것을 계속 찾아 내어 공격을 시도하고 있습니다.

최근 보이스 피싱이 진행되는 내용을 보면 그 창의성에 놀라울 따름인데요. 많은 해커와 개발자 사이의 관계를 살펴보면 개발자의 위치, 특히나 보호를 해야 하는 담당자의 입장이 많이 어렵습니다. 해커는 하나의 취약점을 공격해도 성공하는 반면 개발자는 모든 취약점을 막아야 성공할 수 있기 때문이죠.

또한 해커들의 공격 방법은 그들간에 공유가 활성화 되는 반면, 이를 막는 방법에 대한 공유는 보안상 이유 또는 개발자의 자산으로 인식되어 상대적으로 늦게 또는 제한적으로 이루어지고 있습니다. 이러한 상황에서 취약성 항목이 지속적으로 추가되고, 변하고 있는데요. 그에 따른 조치를 개발자 스스로 다하는 것은 더욱 한계가 있을 수 밖에 없습니다.

행정자치부의 시큐어 코딩 가이드를 보면 입력 데이터 검증 및 표현, 보안기능, 시간 및 상태, 에러처리, 코드오류, 캡슐화, API 오용 등의 항목이 있습니다. 그리고, 모바일 전자정부서비스 앱 소스 코드 가이드에 보면 모바일 보안약점 검증기준 등의 항목이 있습니다.

또한 웹 개발의 취약성 관점에서는 OWASP TOP 10 등의 취약점 항목도 있는데요. 기술적인 취약성 목록을 관리하는 Global 사이트를 참고해 보면 엄청난 수에 놀라실 수도 있을 것입니다.

앞서도 언급했었지만 이러한 개발 요건이 요구사항으로 구체화 되어 있는 경우라면 개발자가 필수로 이해하여 적용을 하겠지만, 요구사항 자체가 시큐어 코딩 준수라는 형태로 되어 있는 상황이므로 그에 따른 개발 공수가 얼마나 되는지 조차 산정하지 않고 진행되는 것이 현재의 일반적인 프로젝트의 모습이 아닐까 싶습니다.

시큐어 코딩 점검 방법?

이런 악조건 속에서 점검을 잘 할 수 있는 효율적인 방법이 있을까요? 더구나 기간과 비용이 정해져 있는 프로젝트에서 말입니다. 세상의 모든 일이 그렇듯 이것 역시 쉽지 않은 일입니다. 그렇지만 확 와 닿는 해결책이 아니어도 점진적으로 나아갈 수 있는 방향을 찾아보아야 할 것입니다.

먼저 소규모 프로젝트 또는 유지보수를 하는 업무 환경에서 살펴보면, 점검할 수 있는 환경을 구성하는 것이 우선이라고 생각됩니다. 이러한 환경을 구성한 후 개발자로 하여금 툴을 사용할 수 있도록 교육을 하는 것이죠.

환경을 구성하는데 필요한 부분이 부담이 되겠지만, 전담 인원이 없는 환경에서는 점검의 업무를 서로 나누어 가져갈 수 밖에 없습니다. 이렇게 되면 개발자가 각 항목을 이해하고, 그에 따라 점검 툴을 활용하여 해결방법을 체득하게 되어 점차 부담이 완화되어 가는 상황을 만들 수 있게 될 것입니다.

전담은 아니어도 이를 추진하고 모니터링하고 지원하는 역할을 가진 사람이 필요하다는 것은 당연한 전제임을 고려해야 합니다. 이런 체계는 SM을 통해 유지보수를 하는 환경이라면 더욱 적합한 모습이지 않을까 생각됩니다.

최근 규모가 큰 회사에서는 이를 위해 툴을 통해 점검할 수 있도록 제반 환경을 제공하며, 형상관리 적용 시 소스 코드 점검에 대한 절차 준수가 안 되어있는 경우, 운영으로 이관을 통제하는 환경을 만들어 가고 있습니다.

하지만 대규모 프로젝트라면 위의 방식은 한계가 있을 수 밖에 없어 다른 접근이 필요한데요. 분석•설계•개발•테스트에 모두 일정이 할당되어 진행되며, 이러한 과정에서 시큐어 코딩에 대한 요구사항이 불명확할 때 개발자에게 아무리 툴을 준다고 해도 사전에 모든 점검을 기대하는 것은 어려울 수 있습니다.

테스트 단계에서도 소스의 수정이 발생할 수 밖에 없으므로, 개발자는 테스트가 완료된 후에 소스 코드 점검을 하여 그 공수를 최소화하는 것이 효과적입니다. 하지만 관리 관점에서는 형상 관리에서 통제를 한다고 하더라도 그 시점에 일대 혼란을 야기하는 상황을 경험하게 될 수도 있습니다.

따라서 일괄로 점검하는 방안을 마련해야 합니다. 즉, 개발 공수와는 별도로 점검하는 인원의 공수를 고려해야 하는데요. 그 공수는 실제 많이 소요되지는 않으며 1~3회 정도 점검을 한다고 계획하면 될 것으로 보입니다. 일괄점검을 위한 환경이 필요할 수 있으니 이 역시 미리 고려해 놓는 것이 필요합니다.

이러한 것이 마련되어 있다면 대규모 프로젝트에서는 개발 초기에 1차로 일괄 점검을 수행하고, 개발자에게 관련 내용을 공유하여 소스의 안정성 강화에 실질적인 가이드를 제공할 수 있습니다. 또한 관리 측면에서도 소스 코드의 점검 결과를 추정할 수 있어 통제 시점에 시큐어 코딩 준수를 위해 소스를 변경해야 하는 혼란을 최소화 할 수 있을 것입니다.

시큐어 코딩 합리적인 점검 룰 설정

이러한 환경이 모두 구성이 된다고 하더라도 적용되는 룰에 대한 검토가 필수적이라고 할 수 있는데요. 이 룰은 보통 5개 등급으로 레벨을 나누어 접근하도록 되어 있습니다. 1레벨의 룰은 Critical 한 문제를 야기할 수 있는 수준으로 설정하고, 2레벨은 Major 항목으로, 3레벨 이하의 경우는 일반적으로 코딩 규칙 준수 등의 항목으로 살펴볼 수 있습니다.

품질 관점에서는 3레벨 정도의 항목까지 준수하고자 하는 경우가 많지만, 현실적으로 개발자의 입장에서는 “뭐 이런 걸~” 이란 생각이 들 수도 있는 항목도 많이 포함되어 있습니다. 그래서 보통 상호 적용 기준을 만들 때 협의가 잘 안 되기도 합니다.

이처럼 협의를 통해 원활한 진행이 어려운 경우에는 기존에 적용했던 룰이라면 적용을 고려해 보되 그렇지 않고 처음으로 적용하는 기준이라면 일부 적용한 후에 그 결과를 가지고 판단해 보는 것이 좋습니다. 결과를 가지고 이야기를 하다 보면 오탐 여부 및 수정이 필수인지를 충분히 판단하여 상호 협의가 잘 진행될 수 있기 때문입니다.

이렇게 룰이 확정이 되면 개발자에게 충분히 공지 또는 교육을 수행하고, 적용이 될 수 있도록 계획을 수립하여 관리하면 되는 것이죠. 효과적인 점검을 하고 나면 안전한 소프트웨어의 방향으로 한걸음 더 나아가게 되며, 점차 보안 관점에서 개선되는 효과가 나타나게 될 것입니다.

프로젝트 계획을 담당하는 분이라면 시큐어 코딩을 위한 공수 산정을 고려해야 하고, 개발자는 관련 트렌드 및 점검 룰, 점검 도구에 대한 이해를 해야 합니다. 그리고, 점검 담당자는 점검 설정에 대한 정보가 필요한데요. 이 글이 관련 담당자분들에게 도움이 되셨기를 바랍니다. 그리고 개선되는 시간이 악의적인 사용자들이 발전해 나가는 속도에 뒤쳐지지 않기를 바래 봅니다.

글 | LG CNS 보안컨설팅팀

[‘보안, 이렇게 하면 된다’ 연재 현황]

• [1편] ISMS 의무인증 대상 확대! 어떻게 대응해야 할까?
• [2편] ISMS 인증을 위한 보안솔루션 구성 방안
• [3편] ISMS 인증 주요 결함사항 및 대응방안
• [4편] 정보보호 관련 인증 및 평가 제도
• [5편] 스마트폰의 보안 위협과 대응 방안
• [6편] IoT 보안 취약점 사례 소재 및 취약점 진단
• [7편] 스마트폰 앱 서비스 보안의 현재와 미래
• [8편] 중국 개인정보 보호법 제도 동향 및 대응방향
• [9편] 출입 보안을 위한 보안 설계
• [10편] 소프트웨어 개발 보안 – 시큐어 코딩
• [11편] 당신의 출입카드는 안녕하십니까?
• [12편] 통합 보안 관리 동향 및 활용 방안
• [13편] 비대면 실명인증이란 무엇인가?
• [14편] 프로젝트에서 소스 코드 보안 점검하기
• [15편] 차세대 행위 기반 위협 탐지 방식에 관하여
• [16편] 핀테크 보안 위협과 대응 방안
• [17편] 인공지능과 보안
• [18편] ‘보안은 제품이 아니라 절차다!’라는 말의 의미
• [19-1편] 인증의 완성판 생체인증에서 다중 생체인증까지 ①
• [19-2편] 인증의 완성판 생체인증에서 다중 생체인증까지 ②
• [20-1편] 중국 네트워크 안전법 분석 및 대응 방안 ①
• [20-2편] 중국 네트워크 안전법 분석 및 대응 방안 ②
• [21편] 유전자 정보 보안 안전한가?