요새 프로젝트를 진행하면서 고민이 많습니다.
아무래도 컨소시엄을 구성해서 작업을 수행하다보면, 수행 절차나 방법론의 차이로 문제가 생기게 마련인가 봅니다.
보안 컨설팅 분야도 SI 사업과 마찬가지로 ‘착수전 단계 작업’없이 프로젝트 시작 후 수행 범위나 수행 방법을 논의하는 것을 보니, 제가 기존에 알던 진행 방법과 차이가 커서 생경하기도 하고, SI 사업의 그 많은 문제들이 고스란히 드러나는 것을 보면서 보안 컨설팅의 미래가 SI 업계처럼 되지 않을까 하는 우려도 듭니다.
오늘은 ‘소스 분석이 다른 웹 보안 진단에 비해 가지는 장점이 무엇인가?’라는 측면에 대해 다른 회사 컨설턴트와 논의하는 와중에 느낀 바가 많았습니다. 저는 웹 애플리케이션 보안 방법론의 일부로 소스분석 업무를 추진하면서 진단 신뢰성 강화, 분석 난이도 저감, 단위 시간당 소요 시간 절감, 진단자 간의 차별없는 품질 수준 확보 등 해결해야할 기술적 난제들이 많아, 문제 해결에 많은 시간을 할애해 왔습니다. 이 와중에 나름대로 ‘소스 보안성 분석 프로세스’를 갖춘 것이 저로선 결실이었습니다.
그러나 웹 보안 분야에 대한 대외 할동이 줄면서 정보 공유를 못해서인지, 같은 분야에서 일하는 보안 컨설턴트로부터도 ‘소스분석이란게 과연 장점이 뭐냐?’는 질문을 받은게 아닌가 싶네요. 반성해야 하겠고, 책임감도 무겁습니다.
웹 보안 분야는 다양한 방법과 프로세스가 있습니다.
국내에서는 이 중 다음과 같은 진단 서비스를 제공하는 것으로 알고 있습니다.
1. ISO17799 및 COBIT 자료를 토대로한 보안 인터뷰 및 개발 라이프사이클 보안 진단
2. 보안 아키텍쳐 분석
3. 웹 취약점 스캐너(ScanDo, AppScan 등) 점검
4. 소스 보안성 분석
5. 웹 모의 해킹
이들 각각은 나름의 장단점을 가진 개별적 프로세스로 일부 요소를 조합하거나 개별적으로 적용가능한 방법입니다.
1번 프로세스는 국내에선 관리적 보안 진단에서 주로 다루던 것으로, 영미권의 주주자본주의에 입각한 감사(audit) 필요성에 따라 해외에선 꾸준한 고객 수요를 갖고 있는 것으로 알고 있으며, 대체로 보안 컨설팅의 일부로 다루어지고 있는 것으로 압니다. 개발 단계(SDLC)에 걸쳐 프로젝트 Risk 및 보안 요소 준수 여부를 검토하고, 프로세스 및 지침 차원에서 접근하는 점이 특징입니다.
2번 프로세스는 어플리케이션 아키텍쳐를 기반으로 암호화, 인증 등의 기술적 측면을 검토하는 것으로 국내에선 한국전산원에서 수여하는 정보시스템 감리사들에 의해 수행되어 온 것으로 압니다.
1, 2번은 비교적 넓은 범위에 걸쳐 체계적인 보안 진단이 이루어진다는 장점이 있으나, 고객들의 의식 수준 미비, 영미권 기업지배구조와 한국 기업지배구조 간의 차이로 무의미한 문서 작업 정도로만 인식되는 경우가 많습니다.
기술적 측면에서 가장 빈번하게 수행되고 자주 비교되는 것이 3, 4, 5번 프로세스 입니다.
3번은 웹 취약점 진단을 위해 개발된 취약점 스캐너를 이용해 사이트를 점검합니다.
자동화된 도구가 사용되기 때문에 다음과 같은 장점이 있습니다.
가) 사용 용이성 – 전문 진단 인력의 노하우에 대한 의존도가 비교적 낮습니다.
나) 일정한 품질 수준 – S/W가 정형화된 진단 항목에 대해 점검합니다.
다) 빠른 수행 속도 – 1~3일 이내에 다수의 사이트로 이루어진 고객사를 진단할 수 있습니다.
라) 자동화된 리포트 – 리포트의 분량이 많기는 하나 리포트 작성을 위한 노동력, 시간 투입이 없어 편리합니다.
반면 내부적으로 사용하는 기술로 인해 다음과 같은 단점이 있습니다.
가) 웹 Crawl 기술의 특성으로 인해 전체 사이트를 진단할 수 없습니다. – 일반적 오해와 달리 웹 취약점 스캐너는 전체 사이트를 진단할 수 없습니다. 웹 Crawl이란 검색 엔진이 내부적으로 사용하는 기술로 웹 사이트의 페이지를 다양한 알고리즘을 사용해 검색하는 것을 말합니다. 이 기술은 페이지 간의 링크에 의존(물론 기술적으로 보다 상세히 말하면 웹 취약점 스캐너는 일부 전형적인 URL과 파일명에 대한 추측 기능도 갖고 있습니다)하기 때문에, 숨겨진 페이지를 보기 어렵거나 불가능합니다. 현존하는 최고의 검색 엔진이라 일컬어지는 구글의 경우를 한번 보시죠. 구글은 기존 검색 엔진의 검색 능력을 획기적으로 개선한 독특한 기법으로 널리 알려져 있습니다. 심지어 ‘해킹도구 구글’이라고 일컬어 질 정도로 사이트 관리자마저도 모르는 민감한 정보가 담긴 페이지, 취약점이 존재하는 페이지를 찾아내는 구글이지만, 구글 소속 엔지니어들은 구글의 현황을 다음 그림과 같이 표현하고 있습니다.
구글이라는 성능 좋은 잠수함으로도 저 심해에 있는 숨어있는 웹 페이지들을 볼 수 없다는 것입니다. 구글은 전체 웹의 1/4 만을 자신들이 볼 수 있다고 이야기 합니다. 이 비율을 여러분 사이트에 그대로 적용하여 웹 취약점 스캐너가 전체 페이지의 1/4만을 볼 수 있다고 말할 수는 없습니다. 여러분 사이트 개발에 사용된 기술과 링크 구조에 따라 웹 취약점 스캐너가 검색할 수 있는 페이지와 없는 페이지가 달라지기 때문입니다. 그러나 웹 취약점 스캐너는 여전히 다른 취약점 진단 방법에 비해 가장 많은 페이지에 대해 취약점 진단을 수행할 수 있습니다.
나) 수정 소스 파악의 어려움 – 웹 취약점 스캐너는 취약한 페이지를 발견해줄 수 있습니다. 그러나 이 때부터 개발자의 고민은 시작됩니다. 페이지라는 개념과 소스라는 개념은 다릅니다. 취약점이 발견된 페이지를 토대로 취약점 발생 원인 소스를 찾는 것은 쉬운 작업이 아닙니다. 왜냐하면 어플리케이션의 특성 상 서로 간에 복잡한 의존 관계가 있기 때문입니다. 문제는 A 라는 페이지에서 발생되었습니다. 개발자는 A라는 페이지를 생성하는 소스를 찾아야 할 것이며, 이 소스와 의존 관계에 있는 다른 모듈이 원인이 되어 해당 취약점이 발생한 것은 아닌지 검증해야 할 것입니다.
다) 수정 사항 적용의 어려움 – 웹 취약점 스캐너는 웹 애플리케이션이 동작하는 내부 메커니즘을 모르기 때문에 어느 사이트에나 적용가능한 일반적 권고 사항을 제공하게 되고, 개발자 입장에선 이 권고 사항을 토대로 소스 수정 작업을 수행해야 하는 어려움이 있습니다.
그러나 웹 취약점 스캐너는 비용대비효과가 높은 제품이며, 주기적인 진단을 통해 취약점을 수정하는데 있어 효과적입니다.
4번 소스 보안성 분석은 다음과 같은 장점이 있습니다.
가) 근본 발생 원인이 된 소스를 수정 – 진단자의 기술 수준에 따라 다르겠지만 개발 경험을 갖춘 숙련된 진단자는 사이트에 실제 적용가능한 수준의 소스 수정 방안을 제공할 수 있습니다.
나) 폭넓은 수정 효과 – 한 개의 소스 수정을 통해 다수의 페이지에 존재하는 취약점을 제거할 수 있습니다. 왜냐하면 게시판 소스와 같이 한 개의 소스가 수십, 수백 페이지를 생성하는 경우도 빈번하기 때문입니다.
다) 심도 있는 진단 – 다른 진단 방법이 한의사가 진맥을 하는 것이라면, 소스 분석은 CT촬영이나 MRI촬영과 같습니다.
내부 구현 메커니즘을 파악할 수 있기 때문에 다른 진단에서는 발견할 수 없거나, 발견하기 매우 어려운 취약점을 손쉽게 발견할 수 있습니다.
그러나 다음과 같은 단점이 있습니다.
가) 진단자의 기술 수준에 대한 높은 의존도 – 개발 경험을 갖춘 숙련된 진단자와 일반 모의해킹 인력의 소스 분석은 진단 결과와 수정 권고안에서 그 수준이 달라, 자칫 소스 보안성 분석 품질에 대한 불신을 불러 일으킬 수 있습니다.
나) 비용 및 시간 소요 – 진단자의 수작업에 의해 이루어지기 때문에 전체 사이트에 대한 진단 적용이 힘들고, 많은 인력과 시간을 투여해야 할 수 있습니다. 대부분 취약빈도가 높은 대상에 대해 샘플링을 톧해 진단하기 때문에 효과가 높다고는 하지만, 여전히 다른 소스에 취약점이 존재할 가능성을 배제할 수 없습니다. 진단자의 샘플링 기술에 대한 의존도 Risk 요인입니다.
장기적으로 소스 보안성 분석을 수행하여 전체 웹 애플리케이션을 커버해나간다면 소스 보안성 분석은 가장 신뢰도가 높고 보안 수준을 현저히 높일 수 있는 좋은 방법입니다만, 그에 따른 비용 부담이 해결해야 할 과제입니다.
5번 웹 모의해킹은 다음과 같은 장점이 있습니다.
가) 실제 공격 가능한 취약점 진단 – 해커가 손쉽게 공격 가능한 취약점을 손쉽게 발견할 수 있습니다.
나) 수행 방안에 따라 다수의 웹 취약점 진단 가능 – 취약점 진단 항목을 기준으로 웹 페이지의 넓은 범위에 적용하면 비용효과적으로 웹 취약점 진단 수행이 가능합니다.
다) 웹 해킹의 파급 효과 파악 – 웹 해킹으로 인해 발생가능한 비즈니스 피해를 직관적으로 파악할 수 있습니다.
그러나 다음과 같은 단점이 있습니다.
가) 적은 취약점 항목 진단 – 모의해킹의 특성 상 일부 심각한 웹 취약점만 발견하면 다른 취약점에 대한 진단을 추가적으로 수행하지 않는 경우가 많습니다. 물론 위에서 언급한 방법을 사용해 다수의 취약점을 발견 가능하나 여전히 다른 페이지에 발견하지 못한 취약점이 존재할 수 있습니다.
나) 수정 사항 적용의 어려움 – 소스 수정에 대한 일반적 권고 사항만 제시하므로, 개발자 입장에선 이 권고 사항을 토대로 소스 수정 작업을 수행해야 하는 어려움이 있습니다.
이왕이면 표로 설명했으면 이해하기 쉽고 보기 편해 좋겠습니다만, 이글루스가 아쉽게도 표 기능을 제공하지 않네요.
이상으로 각 진단 방법의 장단점을 간략히 살펴보았습니다.
웹 보안 진단을 수행하는 인력들이나 컨설팅을 받으시는 분들은 각 진단 방법의 특징을 숙지하여 적절한 진단 방법을 적용하므로써 본래 의도한 목적을 이루시기 바랍니다.
감사합니다.