개인정보 보호법, 정보통신망법, 전자금융 감독규정 등에 의하면 회사에서 운영하는 내•외부 서비스는 정기적인 취약점 진단을 받도록 요구하고 있습니다. 취약점 진단의 범위는 흔히 정보 시스템이라고 통칭하지만, 세부적으로 들여다보면 생각보다 넓은 범위를 가지고 있습니다.
이 많은 자산을 점검하려면 일단 머리부터 아파집니다. 끊임없이 악성코드와 제로데이 취약점은 쏟아지는데, 보안 담당자의 업무량에는 한계가 있습니다. 보안의 범위는 넓고, 담당자의 역할이 아무리 출중하다고 하더라도 AIX OS, Android 애플리케이션의 기술적인 내용을 모두 알기 어렵습니다. 어느 정도 기술을 알고 있다고 하더라도 보안 취약점을 진단한다는 것은 단순히 언어를 알거나 운영 혹은 개발 경험이 있는 것과는 다른 이야기가 될 것입니다.
보안 담당자들은 이럴 때 고민을 하게 됩니다. ‘어떻게든 취약점 진단은 해야 하겠는데, 좋은 방법이 없을까? 외부 컨설팅을 받아서 해버릴까? 아니야, 앞으로 계속 정기적으로 점검해야 하는데 당장 돈이 좀 더 들더라도 취약점 진단 솔루션을 도입할까?’ 외부 컨설팅을 받을지, 취약점 진단 솔루션을 도입할지의 갈림길에서 어떤 방법을 이용하더라도 장단점은 있습니다. 각 회사 보안 조직의 인원, 보유한 기술 역량, 자산 수 등에 따라 적절한 선택을 해야 합니다.
외부 컨설팅을 선택한다면
외부 전문가의 도움을 받는 것은 비교적 단기간에 높은 수준의 취약점 진단을 필요로 하는 회사에 효과적인 방안입니다. 하지만 일회성 서비스이기 때문에 매년 지속적으로 비용이 들어가고, 발견한 취약점의 조치 여부 확인이 필요한 경우 이행 점검은 별도의 일정과 비용 계획이 필요할 수 있다는 것을 반드시 고려해야 합니다.
외부 전문가의 모의 해킹을 선택한다면 비즈니스에 특화되거나 고도의 스킬이 필요한 취약점들을 찾을 수 있다는 장점이 있지만, 사람이 하는 작업이다 보니 빠뜨리는 게 있을 수 있습니다. 애플리케이션의 모든 페이지에 모든 파라미터를 점검하기에는 비용 효과성이 떨어질 수 있다는 것입니다.
따라서 이 한계를 미리 이해하시고, 취약점이 식별되었다면 취약점이 발견된 기능뿐만 아니라 전체 기능에 대해 내부 점검을 하고 조치가 이루어져야 합니다.
솔루션 도입을 선택한다면
취약점 진단 솔루션을 도입하는 것은 보안 담당 조직의 인원에 비해 관리해야 하는 자산의 수가 많은 회사에서는 아주 좋은 방안이 될 것입니다. 이 방안의 최대한 장점은 일단 한번 구축하면 언제든! 어디서든! 원하는 만큼 마음껏! 취약점 점검을 할 수 있다는 점입니다. 하지만 비교적 초기 투자비용이 높고, 솔루션 사용 방법과 점검 결과의 해석에 전문성이 필요하다는 것은 꼭 고려해야 할 부분입니다.
또한, 취약점 진단 솔루션은 Signature 기반의 탐지 방법을 기반으로 하기 때문에 최신 보안 취약점에 대한 대응이 신속하게 이루어지기 어렵다는 점과 비즈니스 흐름을 이해해야만 찾을 수 있는 권한 상승 및 요청•응답 패킷 조작을 통한 결제금액 변경 등 영향도가 큰 취약점을 찾기 힘는 한계가 있다는 것을 이해하고 있어야 합니다.
취약점 진단 도구는 크게 소스코드 점검과 같은 정적 분석과 실제 동작하는 애플리케이션에 다양한 패턴의 공격 패킷을 시험하는 동적 분석으로 나눌 수 있습니다. 시중에 상용 솔루션은 이 두 가지 분석 모드를 대부분 지원합니다. 정적 분석과 동적 분석은 서로 상호 보완적인 역할을 하기 때문에 두 가지 방법 모두 적용하는 것이 바람직합니다.
고민이 끝난 뒤에도
솔루션이냐 외부 컨설팅이냐, 선택이 끝난 뒤에도 우리의 취약점 점검은 끝이 아닙니다. 분명히 취약점은 식별될 것이고, 이에 대한 조치는 이루어져야 하며 조치가 제대로 되었는지 확인이 되어야 합니다. 취약점 점검은 이벤트성 업무가 아닌 정기적인 활동입니다.
이 점검 체계는 PDCA(Plan-Do-Check-Act) 의 Cycle에 따라 계획을 세우고, 실행하고, 제대로 실행되는지 점검을 하고, 잘못된 것을 개선하고 다시 계획을 세우는 순환구조를 통해 지속해서 관리되어야 합니다.
여기까지 온 우리는 이제 이런 생각이 들 수 있습니다. ‘이런 취약점은 도대체 왜 계속 생기는 거지? 미리 방지할 수는 없었을까?’ 취약점들은 물론 제조사에서 자산을 공급할 때부터 있었던 것일 수도 있습니다. 하지만 이건 예방하기 어려운 문제입니다.
도출되는 취약점들은 자세히 살펴보면 대부분은 처음 구축 시 환경설정에서, 개발 시 분석•설계 단계에서부터 보안에 대한 충분한 고려가 되지 않았기 때문인 경우가 많습니다. 취약점 점검은 자산을 구축한 후에만 수행해야 하는 활동은 아닙니다.
처음 자산을 도입하는 단계부터 보안성 향상을 위한 고려가 되어있다면 이렇게 운영 단계에서 정기적인 취약점 점검으로 고생하는 업무를 훨씬 줄여나갈 수 있습니다.
● [시큐어코딩] 해킹 당했다. 어디서부터 잘못된 거지?
지금까지 보유한 정보자산의 취약점 진단을 하려는 방안에 대해서 말씀드렸습니다. 해킹 사고는 언제든 일어날 수 있습니다. 해킹 사고가 발생한 적이 없다면 사고는 나지 않은 게 아니라 모르고 있을 수 있습니다.
지금 회사의 어떤 정보자산이 해커의 표적이 되었을지 모르기 때문에 정기적인 취약점 점검뿐만 아니라 상시 점검은 Compliance 요건 충족을 떠나서 고객 정보 보호 및 대외 신뢰도 유지를 위한 필수적인 활동입니다. 단순한 일회성 이벤트로 취약점을 점검하고 조치하는 활동만으로는 해결책이 될 수 없습니다.
자산의 도입 시점부터 보안성 검토를 수행하고, 정보보안의 전체적인 관리체계 속에서 PDCA 사이클을 통해 취약점 점검을 수행하는 게 가장 바람직한 모습이 될 수 있습니다.
글 l LG CNS 보안컨설팅팀
