정보 보안 실무 04-2 취약점 분석

정보 보안 실무 04-2 취약점 분석

취약점 진단

1. 취약점의 정의

취약점 진단

취약점이  무엇인지 그 정의부터 알아보겠습니다. 취약점이란 위협이 발생하는 전제 조건으로, 자산이 가지고 있는 보안상의 결점 또는 취약한 속성을 말합니다. 취약점은 자산이 부당하게 이용될 수 있는 안전장치의 부재 혹은 결점으로 간주되기도 합니다.

예를 통해 이해해 봅시다. 취약점은 서버에 실행되는 오래된 버전의 서비스, 제한 없는 네트워크 접근, 침입 차단 시스템의 열린 포트, 느슨한 통제구역의 물적 보안, 서버와 PC에 취약한 패스워드 설정 등이 있습니다.

취약점을 발생 유형별로 살펴보죠. 다음의 세 가지로 나누어 볼 수 있겠는데요. 먼저 환경 및 시설과 관련된 취약점에는 문과 창문  등의 물리적 보호 결여가 있겠으며, 이러한 취약점은 도난이라는 위협에 의해 자산이 손실될 위험이 발생할 수 있습니다. 또한 불안정한 전원 설비로 인해 정전과 오작동으로 자산이 피해를 볼 수 있습니다. 홍수, 지진 피해 등 재해를 입기 쉬운 입지 조건 역시 환경 및 시설 측면에서의 취약점이라고 할 수 있겠습니다.

하드웨어적인 취약점으로는 온도와 습도 변화로 인한 전산 기기의 고장이나 오작동이 있고 기억 매체의 유지보수 부족으로 인해 장애 발생 시 중요 데이터가 유실되는 것을 들 수 있습니다.

그럼, 소프트웨어에서 발생할 수 있는 취약점으로는 무엇이 있을까요? 소프트웨어의 전반적인 성능과 기능 요구 사항 등이 기록된 명세서가 존재하지 않아 원하는 성능과 기능을 충족하지 못하는 경우가 발생할 수 있습니다. 또한 부적절한 패스워드 설정 취약점으로 인해 부정접속이나 2차적으로 정보유출이라는 피해를 야기할 수도 있으며, 백업을 실시하지 않음으로 인해 장애 및 침해사고 발생 시 그에 대한 적절한 대처를 하기 어려운 취약점들도 생각해볼 수 있습니다.

그 외에 접근제어 기능이 미비하여 중요 데이터에 누구나 접근이 가능한 취약점이 생길 수도 있습니다. 그리고 감사를 실시하지 않음으로써 부정 행위 단속의 부재를 야기하기도 합니다.

2. 취약점의 분류

이번에는 취약점의 발생 유형을 점검하기 위한 취약점 점검 분류에 대해 알아보겠습니다. 취약점 점검은 크게 관리적 관점, 기술적 관점, 물리적 관점으로 나누어 볼 수 있습니다. 관리적 관점은 정보보호관리체계 보안 통제에 근거하여 취약점을 점검하는 것을 말하며 기술적 관점은 서버, 네트워크, PC 보안 점검 등을 통해 취약점을 점검하는 것을 말합니다. 물리적 관점은 문서 검토, 체크리스트, 면담 등을 통해 취약점을 점검하는 것입니다.

취약점 점검의 세 가지 분류에 대해 구체적으로 알아보겠습니다. 먼저 관리적 관점입니다. 이 관점에서는 조직과 조직에서의 정보자산 운영을 위해 어떠한 취약점이 존재하는지를 바라봐야 합니다. 상세 분류에서는 업무 프로세스가 적합한지, 보안에 적절한 예산이

분배되고 있는지, 시설물에 대한 유지보수가 잘 이루어지고 있는지 등의 정보보호 운영에 대한 취약점을 점검합니다. 정보보호 관리의 취약성은 주로 조직 내 정책과 지침의 준수가 잘 이루어 지는지, 조직 내 전담 인력이 존재하여 보안 활동을 잘 수행하는지, 정보보호 교육을 통한 임직원들의 정보보호에 대한 의식을 제고하고 있는지 등을 점검합니다. 인적 관리에서는 임직원도 하나의 자원이라는 관점으로 바라보아 인적 자원으로 발생할 수 있는 보안 취약점을 점검합니다. 예를 들어 적합하지 않은 직무 부여, 외부인에 대한

감독 소홀, 정보보호 인식 부재 등이 있습니다.

기술적 관점에서는 주로 IT인프라 시설에 대해 관리가 잘 이루어 지고 있는지 점검하게 됩니다. 컴퓨터/통신관련 취약성은 컴퓨터와 통신이 안전하게 이루어지는지에 대한 내용을 점검하게 되며 인증 매커니즘, 접근통제, 감사 증적, 시스템 패치 등의 취약점을 점검합니다. 정보보호 시스템 관련 취약성은 침입 차단 시스템인 방화벽이나 침입 방지 시스템 IPS, 침입 탐지 시스템 IDS와 같은 보안 솔루션이 올바르게 운영되어 컴퓨터/통신에 대한 보안성 향상을 지원하고 있는지를 점검하게 됩니다. 시스템의 개발과 관련된

취약성이 있으며, 이것은 조직이 사용하는 애플리케이션 개발이 안전하게 이루어지는지를 점검하게 됩니다. 개발 단계에서 보안 측면이 전혀 고려되지 않은 채 최종 애플리케이션이 나오게 된다면 무수히 많은 잠재적인 보안 취약점을 가지게 됩니다. 더구나 개발 완료 후 기능을 수정하는 것에는 막대한 예산을 소모됩니다. 따라서 개발 단계부터 안전하게 개발이 이루어지는지 그 취약점을 점검할 필요가 있습니다.

물리적 관점에서 시설물들에 대해 관리 및 설치가 잘 이루어 지고 있는지 점검하게 됩니다. 물리적 취약성은 물리적 보안을 위해 출입 통제 시스템을 잘 활용하고 있는지, 올바른 위치에 설치되어 있는지 등 물리 보안에 대한 취약점을 점검하게 됩니다.

환경적 취약점은 환경의 변화에 따른 보안 취약점을 점검하기 위해 화재 및 수재 장치 등이 올바른 위치에 설치되어 있는지, 정상적인 동작을 하는지에 대해 주기적인 점검을 실시하게 됩니다.

3. 취약점의 진단

취약점을 진단하기 위한 절차에 대해 살펴보겠습니다. 취약점 진단은 침입자가 관리자가 운영하는 네트워크와 서버 등에 침입할 수 있는 보안상의 허점이 있는지 기술적으로 분석하는 과정입니다. 그 절차는 화면과 같이 자산 조사 및 분석을 하고 진단 대상을 선정하는 등의 절차를 통해 진단을 완료합니다.

각 절차에 대해 자세히 알아볼까요?

취약점 진단은 어떤 자산에 대해서 수행할 것인지를 선정하기 위해 자산의 조사 및 분석을 가장 먼저 실시해야 합니다. 그런 다음 취약점 진단을 수행할 대상을 선정하게 됩니다. 대상의 선정 방법은 전수 조사와 샘플링이 있습니다. 전수조사는 모든 자산을 대상으로 선정하는 것이고 샘플링은 자산의 규모가 매우 클 경우 비슷한 성격을 가진 자산을 한 개의 그룹으로 묶어서 그룹 내 몇 개의 대상만 선정하여 취약점 진단을 수행합니다.

일반적으로 공통의 성격을 가진 자산은 공통의 취약점을 가지는 경우가 많습니다. 따라서 샘플링 방법을 선택하게 되면 취약점의 진단의 업무가 간편화 될 뿐만 아니라 추후 위험 평가를 진행하면서도 중복되는 평가를 실시하지 않을 수 있습니다. 전수 조사는 전체 자산에 대해 취약점 점검을 수행하게 됩니다. 이 방법은 주로 자산의 규모가 적을 경우 샘플링에 비해 꼼꼼히 점검할 수가 있습니다. 그러므로 조직은 전체 자산에 대해 누락되는 성격의 자산이 발생하지 않는 범위 내에서 두 가지  방법 중 효율적인 것을

선택하면 됩니다.

제약 사항 및 일정 확인 단계입니다. 모든 정보 자산이 동일한 방식으로 취약점 진단을 수행하긴 어렵습니다. 예를 들어 우리 조직이 쇼핑몰 서비스를 제공하는데 웹 취약점 점검을 수행하는 중 원인을 알 수 없는 장애사고가 발생했다면 쇼핑몰 서비스가 중단되어 매출에 악영향을 받을 수 있습니다. 이런 경우 진단을 수행하는 시간대가 제약사항이 될 수 있습니다. 바로 이런 제약사항을 확인해야 합니다. 또한 진단을 수행하는 인력에 비해 진단을 해야 할 업무가 과도한 경우도 발생할 수 있습니다. 이런 경우 일정을 분배하여 진행할 수 있습니다.

취약점 진단 수행을 살펴볼까요? 제시된 그림은 정보자산 유형별 취약점 진단 수행 방식의 예시입니다. 네트워크 시스템은 주로환경설정 파일을 수집하여 이를 수동으로 분석하고, 윈도우 계열 서버는 자동화 도구 기반 점검을 수행합니다. 그리고 유닉스 계열의 OS, DBMS, WEB 등의 서버들은 스크립트나 자동화 도구를 기반으로 점검이 가능합니다.

취약점 진단 수행에는 여러 방법이 있습니다. 기술적 취약점 진단에서는 크게 수동 진단과 자동 진단 방법이 존재합니다. 그러나 수십 수백 대의 서버가 존재하는 조직의 경우 이를 정해진 시간 내에 수동 점검하기란 거의 불가능합니다. 이런 경우 프로그램을 통해 보다 효과적으로 자동 진단을 수행할 수 있습니다. 또한 관리적인 취약점 진단은 담당자와의 인터뷰를 통해 진행을 하게 되며, 물리적인 취약점 진단은 실사 등을 통해 진행을 하게 됩니다. 이처럼 정보자산의 유형과 취약점 점검 분류에 따라 그 진단 방식은

다양하게 존재합니다.

취약점 진단이 끝나게 되면 그 결과를 분석하고 보고서를 작성합니다. 이후 보고를 하게 되면 취약점 진단의 절차는 완료됩니다.

기술적 취약점 진단에서 구체적으로 어떠한 항목들을 점검하는지 윈도우 서버, 유닉스/리눅스 서버, 네트워크 장비, 보안 솔루션, PC, 웹 애플리케이션 등 각 정보자산의 유형별로 살펴보겠습니다.

첫 번째로 윈도우 서버의 진단 항목들입니다. 서버에 등록된 계정을 보호하기 위한 설정을 점검하는 계정관리설정 항목이 있습니다.

여기서는 계정의 취약한 패스워드 설정이나 패스워드의 길이, 기간 설정 등이 포함되며 세부적인 계정에 대한 설정 즉 잠금 설정이나Default 계정에 대한 설정을 점검하게 됩니다.

파일 및 디렉터리의 소유 권한 등을 점검하는 파일 및 디렉터리 보안 설정 항목, 서버에서 제공되는 서비스가 안전하게 설정되어 있는지를 점검하는 네트워크 서비스 보안 설정 항목, 그리고 IIS나 MS-SQL 서버 등의 응용애플리케이션에 대한 취약점 부분을

점검하는 응용프로그램 보안 설정 항목이 있습니다.

또한 시스템 장애 및 침해사고의 대응과 복구를 위해 참조해야 하는 로그를 안전하게 보호 조치 하는지 그 취약점을 점검하는 로그 관리 및 보안 감사 설정 점검 항목, OS 시스템 내 보안에 취약한 설정이 존재하는지 점검하는 시스템 보안 설정 항목과, 최신 보안패치를 통해 악성코드 및 Zero-day 공격을 방지하는지 점검하는 보안 패치 설정 항목이 있습니다.

유닉스 및 리눅스 서버 진단 항목에는 어떤 것들이 있을까요? 윈도우 서버와  동일한 서버의 역할을 하기 때문에 그와 크게 다르지 않습니다. 계정 관리 설정, 시스템 환경 설정, 파일 및 디렉터리 보안 설정이  상당히 유사합니다.

다만 OS의 종류가 다르기 때문에 세부적인 점검 방법과 항목이 조금 다릅니다. 예를 들어 윈도우는 RDP라는 애플리케이션을 통해 시스템에 원격으로 접근하여 관리할 수 있습니다. 그러나 유닉스 및 리눅스 서버의 경우는 SSH나 텔넷을 통해 시스템에 접근하여 관리를 하게 됩니다. 따라서 이 서버에서는 RDP 애플리케이션 점검을 수행해야 할 것이 아니라 SSH 및 Telnet 애플리케이션에

대한 보안성 점검을 수행해야 합니다. 그밖에 네트워크 서비스 설정, 로그 설정, 패치 관리 등의 진단 항목은 윈도우 서버와 유사합니다.

네트워크 장비의 진단 항목들에는 어떤 것들이 있을까요? 네트워크 장비는 서버와는 역할이 다릅니다. 크게 네트워크 장비 관리와 계정 보안을 위해 이를 점검하는 계정관리설정 항목과, 네트워크 장비 관리를 위한 SNMP 설정이 취약하지 않은지를 점검하는SNMP 설정 항목, 장비의 운영 시 필요한 보안 설정이 되어 있는지를 점검하는 장비 운영 환경 설정 항목이 있습니다.

그리고 장애 및 침해사고의 복구 및 대응을 위한 로그에 대한 설정이 올바른지를 점검하는 로그 설정 항목, 네트워크 장비가 제공하는 서비스 들의 보안 상태를 점검하는 네트워크 서비스 설정 항목, 네트워크 장비의 운영을 위한 애플리케이션 및 OS에 대한 패치를 점검하는 패치관리 항목도 있습니다.

보안 솔루션의 진단 항목들에 대해 알아봅시다. 보안 솔루션의 핵심은 정책의 관리입니다. 얼마나 오탐을 줄이고, 많은 공격을방어하는지는 정책을 어떻게 설정하느냐에 따라 달려 있다고 봐도 과언이 아닙니다. 구체적으로 보안 솔루션의 정책이 유효하게 설정되어 있는지를 점검하는 정책관리 항목과, 보안 솔루션의 구성 및 운영이 취약한지를 점검하는 운영 관리 항목, 보안 솔루션에

누구나 접근하여 설정을 변경할 수 없도록 적절한 접근제어를 수행하는지를 점검하는 보안장비 접근 및 권한 설정 관리 항목이있습니다.

보안 솔루션 역시 공격을 받을 수 있습니다. 보안 솔루션을 공격하여 장애가 발생할 경우 앞에서 보안 솔루션이 정지되기 때문에 뒤의 네트워크로 데이터 전송이 불가능 합니다. 이런 경우 조직에서 사용하는 네트워크 전체가 마비가 되는 상황이 발생하기도 합니다.

따라서 보안 솔루션이 지나치게 높은 사용률을 가지고 있지 않는지 그 성능에 대한 부분을 점검해야 합니다. 또한 장애 및 침해사고의 복구 및 대응을 위한 로그에 대한 설정이 올바른지를 점검하는 로그 관리 항목이 있으며, 주요 로그들과, 환경설정 들이 장애나 침해 사고로 손실될 경우 이를 복원하기 위한 백업이 이루어 지는지를 점검하는 백업 관리 항목, 보안 솔루션의 자체적인 애플리케이션 및 OS에 대한 패치를 점검하는 패치 관리 항목이 있습니다.

조직 내 임직원들이 업무 처리를 위해 사용하는 PC에 대해서도 점검이 이루어져야 합니다. 최근의 보안 사고들은 각종 보안 설정이 잘 이루어지는 서버보다 상대적으로 덜 보안을 지키는 사용자 PC를 대상으로 발생하고 있으므로 취약점 점검이 꼭 필요합니다.

PC는 사용 대상이 일반 임직원이기 때문에 각 사용자가 지켜야 할 보안 수칙들을 위주로 점검할 수 있습니다. 대표적으로 사용자가 사용하는 계정에 대한 보안 설정이 올바른지 점검하는 사용자 계정 보안 항목과, PC내 업무상 불필요한 서비스가 구동 중인지를 점검하는 네트워크 보안 항목, 중요 문서가 적절한 권한 없이 공유되어 인가 받지 않은 사용자가 이를 열람 및 변조 삭제 할 수 있는지를 점검하는 공유폴더 보안 항목이 있습니다.

그리고 PC의 보안 설정이 적절히 이루어 져 있는지를 점검하는 시스템 보안 항목,  바이러스와 웜, 악성코드 등으로부터 PC를 보호하기 위한 안티 바이러스 점검 항목, PC에 설치된 OS의 취약점을 제거하기 위해 보안 업데이트 및 패치를 수행하는지를 점검하는 항목들이 있습니다.

웹 애플리케이션에 대한 진단에 대해 알아봅시다. 흔히 모의 해킹으로 부르고 있으며 웹 애플리케이션에 대한 취약점 점검을 수행하게 됩니다. 우선 모의해킹을 수행 할 대상을 선정으로 부터 시작하여 수행 대상, 수행 일정, 수행 방법 등에 대해 담당자와 협의 후 진행 수행 계획서를 작성합니다. 다음으로 모의해커가 공격을 위해 필요한 정보를  수집하는 정보수집 단계를 거쳐 실제 모의해킹을 수행하여 웹 애플리케이션에 존재하는 취약점을 찾게 됩니다. 모의해킹을 수행한 결과는 찾아낸 취약점의 종류와 내용, 그리고 대응

방법을 포함하는 결과 보고서를 작성하고 결과를 발표하는 순서로 웹 애플리케이션 진단 절차가 진행되게 됩니다.

웹 애플리케이션 취약점 진단은 대표적으로 OWASP Top 10이라는 기준이 있습니다. OWASP Top 10은 OWASP라는 국제 보안 단체에서 3년 정도를 주기로 발행이 되며, 그간 가장 위험도가 높거나 발생 빈도가 높은 공격들을 순위화한 것입니다. 어떤 것이 있는지 살펴볼까요? 먼저, 인젝션은 웹 애플리케이션에서 사용되어지는 명령어를 사용자가 입력하여 의도치 않은 명령이 일어나는지 그 취약점을 점검하게 됩니다. 취약한 인증 및 세션 관리는 인증 프로세스와 세션의 관리 취약점으로 인해 발생할 수 있는 ID 위조 및

탈취 등의 취약점을 점검하며, 크로스 사이트 스크립팅은 스크립트 명령을 사용자가 실행해서 악성코드 설치 등의 악의적인 행동이 가능토록 하는 취약점이 존재 하는지를 점검합니다. 안전하지 않은 직접 객체 참조에서는 개발자가 파일, 디렉토리, 데이터베이스와 같은 내부에서만 참조해야 할 것들이 외부로 노출되어 이에 접근이 가능한지를 점검합니다. 보안상 잘못된 구성은 웹 애플리케이션의 환경 설정이 취약하여 발생하는 취약점이 없는지를 점검합니다.

6위부터 10위까지입니다. 민감한 데이터 노출은 개인정보와 같이 외부에 노출되어선 안 되는 정보들이 노출되는 취약점이 존재하는지를 점검합니다. 접근 통제 누락은 어떠한 기능을 웹 애플리케이션에서 수행하기 이전에 적절한 사용자가 요청 하였는지를 검토하는지

점검하게 됩니다. 접근통제가 누락되는 취약점이 존재할 경우, 관리자만 접근이 가능한 관리자 페이지에 일반 사용자가 접근하여 회원 개인 정보를 유출하거나 데이터를 삭제하는 등의 악의적인 행동이 가능하게 됩니다. 크로스 사이트 요청 위조는 스크립트 명령을 사용자가 실행해서 특정 행동이 가능토록 하는 취약점이 존재 하는지를 점검합니다. 알려진 취약점이 존재하는 컴포넌트 사용은 웹 애플리케이션이 서비스 하기 위해 부가적인 기능을 별도로 모은 컴포넌트가 가지는 취약점이 존재하는지를 점검합니다.

끝으로 검증되지 않은 Redirect/Forward는 정상적으로 이루어져야 할 페이지 이동에 대해 검증하지 않아 위/변조된 페이지로의 이동이 가능한 취약점이 존재하는지를 점검하는 항목입니다.

4. 취약점의 평가

취약점 또한 위협과 마찬가지로 평가를 실시해야 합니다. 평가 기준에 대해 살펴볼까요? 실질적인 정보자산에 악영향을 끼치는 위험을 평가하기 위해 취약점의 정도 즉 등급이 필요하기 때문입니다. 취약점에 대한 평가는 위협과는 달리 취약점으로 인해 정보자산이 어떠한 손실을 받는지에 대한 등급으로 분류할 수 있습니다. 4단계의 등급으로 분류하여 취약점의 등급을 매기는 평가 기준을 보이고 있습니다. 매우 취약은 자산의 복구가 불가능하거나 피해 규모가 아주 큰 경우입니다. 비교적 취약은 최고 경영자나

상습 관리자의 정밀한 검색 및 승인을 필요로 하는 위험을 발생시킬 수 있는 경우와 자산의 복구는 가능하나 그 피해 규모가 비교적 큰 경우입니다.

보통은 취약점이 상급 관리자의 검토 및 승인을 필요로 하는 정도의 위험을 발생시킬 수 있는 경우를 말하며 취약하지 않음은 취약점이 자산에 별다른 영향을 끼치지 않는 경우이거나 취약점이 자산에 약간의 영향을 끼치지만 그 영향이 미미해서 해당 자산이 하위 관리자의 조치만으로 해결이 가능한 경우를 말합니다.

다음은 취약점 평가 시 우려사항에 대해 알아보겠습니다. 취약점은 때로 직원의 부재, 인력의 부족, 접근제어 미흡과 같이 취약점 자체가 위협이나 위험을 표현하기 위해 사용되는 경우 위협과 위험과의 구분이 모호하게 됩니다. 조직의 성격에 따라 위협과 취약성을 구분하지 않고 하나로 나타내어 위험도를 도출 할 수 있는데 이를 우려사항이라고 정의하고 우려되는 정도를 나타내는 값을 우려도라고 합니다. 일반적으로 사람들은 취약성의 정도를 평가할 때 자산의 가치를 고려하여 답을 하는 경향이 있습니다. 예를 들면 정보 자산이

1등급으로 매우 중요한 경우, 취약성에 대한 대책이 존재함에도 불구하고 취약성이 높다라고 평가하는 경우가 있으며, 정보 자산 등급이 5등급으로 매우 낮은 경우에는 취약성에 대한 대책이 없더라도 취약성이 낮다라는 평가를 합니다. 그래서 최근 위험 분석 방법론에서는 취약성과 위협을 결합하여 의미의 모호함을 줄이고 중복성을 제거한 우려사항으로 표현하기도 합니다.

취약점과 위협을 하나로 합쳤기 때문에 마찬가지로 이에 대한 평가를 실시하게 됩니다. 평가 기준은 화면에  보이듯이 세 등급으로 구분할 수 있습니다. 우려사항은 취약성이 어떤 위협에 의해 발생될 수 있는지의 가능성으로 표현되기 때문에 평가 기준은 발생 가능성이 됩니다. 한 가상의 건설 업체를 예로 들어 보겠습니다. 이 업체에서는 사무용 데이터와 설계 데이터, 기밀 문서에 대한

우려사항을 평가하였습니다. 사무용 데이터와 기밀 문서에 대해 적절한 보안 규정이 부족하여 자산이 제대로 보호되지 않을 수 있다라는 우려사항에 대해서 접근이 가능한 인원에 제한되어 있기 때문에, 우려사항의 평가 기준을 ‘낮음’으로 책정할 수 있습니다.

이는 규정이 없어도 보안에 대한 사고 발생의 가능성이 낮다라는 의미가 됩니다. 그러나 설계 데이터에 대해서는 외부 업체로 빈번히 노출되기 때문에 보안 사고의 발생 가능성이 높아지게 됩니다. 따라서 설계 데이터의 우려사항은 가능성이 ‘높음’으로 책정됩니다.