관리 주체의 활용 역량을 초과하는 대량의 데이터, 2012년에 갑자기 등장한 빅데이터에 대한 간단한 정의이다. 구글 등 정말 특별한 역량을 가진 조직만이 접근할 수 있었다던 빅데이터는 왜 갑자기 이슈가 되었을까?
아마도 구글에서 출발한 ‘하둡’ 등의 빅데이터 처리기술이 성숙하면서 기술 벤더들이 제품화에 자신감을 갖게 된 결과일 것이다.
이러한 배경 속에서 보안 업계 역시 차세대 핵심기술로 빅데이터에 주목하고 있으며, 빅데이터를 앞세운 제품과 기술이 앞 다투어 발표되고 있는 상황이다. 그렇다면 과연 빅데이터는 업계의 주장 또는 희망처럼 차세대 보안을 이끌어갈 핵심기술이 될 수 있을까?
빅데이터 이전에 먼저 우리는 데이터가 가지는 의미에 대해서 생각해볼 필요가 있다. 위키백과를 보면 ‘아마존(구매 리스트를 이용한 상품 추천)’, ‘구글(검색 기록을 이용한 맞춤 광고)’, ‘대한민국 19대 총선(SNS 메시지를 이용한 여론 분석)’ 등 다양한 빅데이터 활용사례가 나온다.
그런데 이러한 활용이 가능했던 이유는 구매 리스트, 검색 기록, SNS 메시지 등의 데이터가 발생 그 자체만으로 의미를 가지고 있기 때문이다. 미래 행위를 예측하기 위해 관련된 현재 행위를 분석, 즉 데이터 분석의 목적에 맞는 정확한 데이터를 분석한 결과인 것이다.
그렇다면 보안 분야는? 과연 보안 분야에서 발생하는 모든 데이터 역시 발생 그 자체만으로 의미를 가질 수 있을까? 보안 분야에서 데이터가 발생하는 과정을 살펴보자.
1. 서버 등 일반 시스템 및 네트워크 장비에서 동작/상태 로그 및 트래픽, 즉 일반로그가 발생한다.
-> 대량 발생
-> 보안 측면에서 낮은 정확도
2. 보안솔루션별 특성 및 기준에 의해 일반 로그가 필터링되어 보안로그가 발생한다.
-> 1번 보다는 그나마 소량 발생
-> 1번 보다는 그나마 높은 정확도
보안 분야까지 빅데이터에 열광하는 이유는 그 동안 2번 과정에서 발생한, 그나마 소량이고 정확한 보안로그 분석으로도 더 이상의 수준 향상이 어렵다고 느꼈기 때문일 것이다. 과연 그럴까?
매우 아쉽게도 보안 솔루션이 만들어내는 로그는 보안에 위협이 되는 정확한 로그와 그렇지 못한 부정확한 로그로 나뉘게 된다.
왜 그럴까? 앞서 애기했듯이 일반로그를 필터링해서 보안로그를 만들어 내는데 그 과정에서 IDS, IPS, 웹방화벽 등의 보안솔루션은 일반적으로 수천 개 이상의 다양한 필터링 규칙(Rule)을 사용하게 된다.
사례를 보자. 시스템 정보를 조회하는 uname이란 명령어의 네트워크 전송행위를 탐지하는 아래와 같은 룰이 있다.
alert tcp any any -> any 80 (content:"uname";)
아래 로그는 해당 룰이 트래픽을 필터링, 즉 검사하여 발생시킨 보안로그의 원시데이터이다. 둘다 보안에 위협이 될까?
참고로 보안로그는 일반적으로 ‘공격명/IP/Port’ 등의 정보를 수록한 기본정보(심증)와 해당 기본정보를 발생시킨 원인 패킷, 즉 원시데이터(물증)로 나뉜다. 보안로그는 물증인 원시데이터 분석을 통해 공격 여부, 즉 심증이 확정됨을 알 수 있다.
1. GET /contact.php?find=1&name=[php]echo('casper'.php_uname().'kae');die();[/php]
2. GET /view.html?Code=L00200100520&tBIName=tblNews&menuname=food
1번 로그는 PHP함수(php_uname)를 이용한 공격 코드가 들어있지만, 2번 로그는 ‘menuname’이란 패턴이 룰 패턴과 우연하게 일치한, 즉 보안에 위협이 되지 않는 부정확한 로그이다(정상적으로 사용되는 패턴이지만 불행히도 룰과 우연히 일치했다).
보안솔루션, 즉 컴퓨터는 패턴의 일치 여부만을 검사할 뿐, 패턴의 의미를 이해하지 못하기 때문에 발생하는 당연한 결과인데, 이런 사례가 비일비재한 것이 보안 분야의 현실이다.
7음계의 한계로 인해 표절 시비가 끊이지 않는 음악계처럼, 공격/정상 패턴 모두 같은 범위의 기호(문자/숫자)로 표현되는 한계로 인해 ‘오탐(공격 표절)’이 끊이지 않고 있는 것이다.
오탐인 2번 로그가 많이 발생하면 해당 룰을 사용하는 조직의 보안수준은 높아질까? 낮아질까?
해당 룰은 그대로 둔 상태에서 모든 로그(보안로그 + 일반로그)를 빅데이터로 분석하는 것이 효과적일까? 아니면 해당 룰을 수정, 즉 정확도를 높인 후 발생하는 정확한 보안로그를 분석하는 것이 효과적일까?
정확한 보안로그를 분석하는 것이 효과적임은 누구도 부정할 수 없을 것이다. 2번 로그가 많이 발생한다면 아래와 같이 룰을 정교화해서 불필요한 로그의 발생을 방지해야 하는 것이다. (uname 패턴으로 1차 필터링, 알파벳으로 시작하지 않는 uname 패턴으로 2차 필터링)
alert tcp any any -> any 80 (content:"uname"; pcre:"/[^a-z]uname/";)
그러나 인공지능을 연상시키는 자동화 마케팅과 보안을 제품으로 해결하려는 문화로 인해 룰 분석 및 개발 분야는 좀처럼 발전의 계기를 찾지 못하고 있다.
정리해보자.
1. 룰이 정교해지면 위협 가능성이 낮은 로그를 높은 비율로 걸러내므로 적은 양의 정확한 보안로그를 생성한다.
2. 그렇지 못하면 부정확한 보안로그를 대량 생성한다.
-> 업계는 수년째 '인력난'을 호소하고 있다. 대량 로그를 분석하기 위해서는 많은 분석 인력이 필요하기 때문이다.
-> 부정확한 보안로그, 즉 부정확한 데이터는 다시 부정확한 빅데이터가 될 가능성이 크다.
현 보안 분야는 체계적인 룰 정확도 향상 방안을 마련하는 대신, 대량의 부정확한 로그를 대상으로 ‘표본검사’나 발생 빈도 및 중복 빈도 등의 기준에 의한 무리한 ‘통계검사’에 의존하면서 전수검사의 실패, 즉 많은 로그를 제대로 분석하지 못하는 상황이 지속되고 있다.
결과적으로 공격이 발생해도 알지 못하는 문제가 발생할 수 있고, 실제 발생하고 있다. 보안로그가 적시에 분석되지 못하면서 많은 보안 사고들이 피해가 발생한 후에야 분석이 시도되고 있는 것이다.
이 문제를 해결하기 위해서는 보안(솔루션/관제) 업계와 사용자가 함께 고민할 필요가 있으나, 현실은 아직 문제 인식이 부족하거나, 책임소재 때문에 애써 문제를 외면하고 있는 상황이다.
이런 상황에서, 즉 일반로그보다 그나마 소량이고 정확한 보안로그도 제대로 분석하지 못하는 상황에서 빅데이터 처리기술이 뛰어나니 일반로그까지 통합해서 보안 수준을 높이자?
이미 영악한 빅데이터 벤더들은 데이터를 저장은 해주겠지만 정교한 패턴 작성 등 올바른 활용은 사용자의 몫이라며 책임소재를 명확히 구분하고 있다.
빅데이터에 파묻히고 싶지 않다면 빅데이터에 열광하기 전에,
1. 데이터 분석의 목적을 정하고,
2. 그 목적에 맞는 데이터를 선택한 후,
3. 그 데이터에 접근하는 방법을 찾아가는 경험을 쌓아야 한다.
기존 데이터의 활용경험과 만날 때, 빅데이터는 우리에게 더 나은 가치를 제공해줄 것이다. 그리고 룰 정확도 향상을 위해 우리는 보안로그, 특히 원시데이터에 주목할 필요가 있으며, 빅데이터는 우리가 그동안 외면하고 있던 비정형 원시데이터에 접근할 수 있는 길을 제시해줄 것이다.
빅데이터와 업계의 인력난
‘인력난’은 정보보안 업계를 대표하는 단어가 된지 오래다. 특히, 보안관제업계는 ‘보안관제 전문업체 지정제도’의 2011년 하반기 시행이 발표되면서 너나할 것 없이 한 목소리로 인력부족 문제를 우려하기 시작했다. 왜 ‘인력난’이 발생했을까?
단순히 그 동안 소외되었다가 수요가 증가하면서 발생한 문제로 치부할 수도 있을 것이다. 그러나 그 이면을 들여다보면 노동집약화된 보안관제 분야의 현실을 발견할 수 있다. 현실을 정확하게 알기 위해서는 먼저 보안관제 업무에 대한 이해가 필요하다.
휴전선의 감시를 소홀히 하면서 국가안보를 논할 수는 없는 것처럼 감시는 가장 중요한 보안관제 업무이고 모든 보안관제 전문업체들이 이를 알기에 365일 24시간 감시를 기본으로 업무를 진행한다.
그리고 집집마다 뒤져서 간첩을 찾는 것보다 휴전선을 감시하는 것이 더 효율적인 것처럼, 모든 보호대상 정보자산을 검사해서 침해 흔적을 찾기란 현실적으로 어렵기에 보안솔루션을 사용하여 보호대상 정보자산을 감시하는 것이 일반적이다. 즉, 네트워크로 연결된 길목에서 정보자산을 향해 오고가는 데이터를 감시하는 것이다.
이때 사용되는 대표적인 보안 솔루션이 바로 IDS로 대표되는 ‘패턴 매칭’ 기반의 ‘룰 기반 보안 솔루션’이다. (참고로 ‘패턴 매칭’은 DPI, 즉 ‘Deep Packet Inspection’과 같은 말이다) 다양한 보안 솔루션이 존재하고, 실제 현장에서 사용되고 있음에도 불구하고 왜 IDS가 대표로 언급됐을까?
IDS는 데이터 표현에 사용된 문자나 숫자 등의 기호를 검사하는 ‘패턴 매치’를 기반으로 동작한다. 그런데 IDS 이후 새로운 듯 소개된 IPS, 웹방화벽, UTM(Unified Threat Management, 방화벽/IPS 등의 기능을 통합한 보안장비), 일각에서 차세대 방화벽이라고 칭하는 애플리케이션 방화벽 등등 대부분의 보안 솔루션들 역시 ‘패턴 매칭’을 기반으로 동작한다.
IDS와의 차별화를 위해 솔루션별로 약간의 특성 차이가 있을 뿐 사실상 기반 기술은 동일하다는 얘기이며, 이들 솔루션의 효과는 ‘패턴 매칭’의 활용역량에 달려있다는 뜻이다.
IDS는 구식이란 인식이 업계에 팽배하지만 ‘패턴 매칭’에 대한 활용 노하우가 없다면, IPS, 웹방화벽 등 ‘패턴 매칭’을 사용하는 모든 보안 솔루션 역시 구식임을 명심해야 할 것이다. 그렇다면 실제 현장에서 로그는 과연 얼마나 발생할까?
서비스 구조나 성격에 따라 다르겠지만 경험상 100Mbps 네트워크 환경에서 상단의 방화벽이 가장 명확한 IP/Port 기준으로 트래픽을 1차 필터링해 줄 경우, 하단에서 2천개 내외의 룰로 운영되는 IDS 또는 IPS 등 ‘패턴 매치’ 기법을 사용하는 룰 기반 보안 솔루션은 하루에 만개 이상의 로그를 토해낸다.
상단에서 1차 필터링을 해주는 방화벽이 없다면 하루에 십만 개 이상의 로그 발생을 각오해야 할 것이다.
네트워크 규모가 커지면 당연히 로그 발생량도 증가하며, 1Gbps 이상의 네트워크 환경에서는 단 하나의 보안 솔루션에서 하루에 백만 개 이상의 로그가 발생하는 경우도 쉽게 찾아볼 수 있다.
도대체 어느 정도의 인력이 있어야 하루 만에 발생한 백만 개의 로그를 놓치지 않고 분석할 수 있을까? 밥도 안 먹고, 화장실도 안가고, 잠도 안자면서 1분에 하나씩 로그를 분석하면 하루에 1,440개의 로그 분석이 가능하다.
자 계산기를 두드려보자. 대략 700명의 초인(?)적인 인력이 필요하다! 반대로 얘기하면 700명의 인력 없이는 백만 개의 로그 분석은 불가능하며, 결과적으로 감시에 실패하게 된다는 얘기이다.
바로 이것이 정보보안, 특히 보안관제 업계의 ‘인력난’의 진실이다. ‘빅데이터’가 화두가 되기도 전에 보안업계는 이미 ‘빅데이터’에 파묻혀 있었던 것이다. 물론 현실에서는 공격유형, 공격자 등의 변수에 의해 많은 중복이 발생하지만 이를 감안하더라도 매우 많은 인력이 필요하다는 결론에 도달하게 된다.
결과적으로 대부분 보안관제 현장에서는 대량의 로그를 처리하기 위해 ‘동일 공격자가 동일 공격을, 예를 들면 10회 이상 발생’시켰을 경우에만 분석하는, 일종의 표본검사 방식을 사용하고 있다. 그런데 표본검사 방식은 전수 검사에 비해 인력 및 시간 비용을 절약할 수 있다는 장점이 있는 반면, 다음과 같은 단점들이 있다.
1. 표본 검사는 동일 공격자에 의해 발생한 동일 공격의 패턴이 모두 동일하다는 전제하에 진행된다.
-> 정확한 공격 패턴 파악이 실패할 수 있다.
2. 임계치에 도달할 때까지 실시간 감시가 지연된다.
-> 공격 시도가 10회가 될 때까지 기다려야 한다.
3. 임계치에 도달하지 않을 경우 ‘1차 감시 누락’이 발생한다.
-> 공격 시도가 9회 만에 성공해 버린다면?
4. 표본검사 범위마저 인력에 의한 분석 역량을 초과할 경우 ‘2차 감시 누락’이 발생한다.
특히, 4번 단점은 치명적이다. 백만 개의 로그를 ‘동일 공격자+동일 공격’ 조건으로 분류하면 평균 만 개 정도로 축약된다. 검사 범위를 99%이상 줄였지만 여전히 7명의 초인(?)적인 인력이 필요하다.
현실적으로 전수검사가 불가능함을 알 수 있다. 전수검사의 실패는 감시 실패로 이어진다. 해킹 시도가 발생한 사실을 몰랐다가 피해가 알려지고 나서야 뒤늦게 대응하는 사례가 증가하는 이유이다.
여기서 의문을 제기해 보자. 왜 보안 솔루션에서 해킹 시도를 알리는 로그가 하루에 백만 개씩이나 발생하는 것일까? 백만 개의 로그는 과연 모두 정확할까?
만약 모두 정확하지 않다면 부정확한, 즉 불필요한 로그의 발생을 방지함으로써 적은 인력으로 더 많은 로그를 분석할 수 있지 않을까? 인력 부족을 우려하기 전에 보안업계는 먼저 이러한 의문을 가져야 하지 않을까?
분명 ‘인력 양성’은 필요하다. 그러나 동시에 로그 역시 줄여야 한다. 계속 증가하는 대량의 로그를 그대로 둔 상태에서 ‘인력 양성’에만 매달려서는 ‘밑 빠진 독에 물 붓는’ 상황을 벗어날 수 없기 때문이다.
‘인력 양성’이 가능한 사회적 여건을 마련해 나가면서 동시에 우리는 로그가 대량으로 발생하는 원인을 파악할 필요가 있다. 이번 연재기획의 마지막 회에서 그 원인과 해결책을 제시한다.
빅데이터와 보안로그
보안업계는 오래전부터 보안로그라는 빅데이터에 파묻혀 있었다. 그 이유는 크게 2가지이다.
1. 대부분 보안 솔루션의 기술 기반인 ‘패턴 매칭’ 룰은 태생적인 한계를 가지고 있다.
-> 공격/정상 패턴 모두 같은 범위의 기호(문자/숫자)로 표현되는 한계로 인해 ‘오탐(공격 표절)’의 가능성이 항상 존재한다.
2. 일반로그를 필터링하는 보안 솔루션의 룰이 정교하지 못하다.
보안업계 종사자라면 지난 2003년 미국에서 불거진 ‘IDS 무용론’을 기억할 것이다. IDS 무용론의 핵심 원인은 ‘오탐’이었으며, 오탐의 핵심 원인은 ‘패턴 매칭’의 한계였다.
그런데 그 한계는 여전히 존재함에도 IDS 이후 출현한 IPS, 웹방화벽 등 대부분 보안솔루션은 여전히 ‘패턴 매칭’을 기반으로 동작하고 있다. (IDS만 구식으로 치부됐다)
결국 ‘패턴 매칭’을 버리지 않는 한, 보안로그라는 빅데이터에서 탈출하는 방법은 보안 솔루션의 룰을 정교하게 만드는 것뿐임을 알 수 있다. 왜 보안 솔루션의 룰은 정교하지 못할까? 정교한 룰의 조건은 크게 2가지이다.
1. 공격 원리 및 특성 반영
2. 룰이 적용될 네트워크 환경의 특성 반영
-> 트래픽 등 일반로그의 발생 양상은 환경마다 달라진다. 즉, 룰 적용 대상이 달라진다. 그리고 적용 대상에 따라 적용결과 역시 달라진다. 그렇기 때문에 적용 대상에 따라 커스터마이징된 룰 적용이 필요하다.
모든 보안 벤더들은 룰 제작시 공격 원리 및 특성을 충실하게 반영하고 있다. 그러나 안타깝게도 보안 솔루션이 설치되는 네트워크 환경의 특성은 반영하지 못하고 있다.
업계의 영세성, 인력 부족의 악순환, 정확한 정보보다 화려한 정보에 대한 선호, 사람보다 제품으로 보안을 해결하려는 문화 등 복합적인 요인이 얼키고 설키며 룰 분석 및 개발 분야의 발전이 더뎌진 결과이다.
네트워크 환경의 특성을 룰에 반영하려면 어떻게 해야 할까? 룰이 입력이라면 로그는 출력이며, 출력 결과를 분석하면 입력의 문제점을 찾을 수 있다.
보안 솔루션에서 발생하는 로그는 일반적으로 ‘공격명/IP/Port’ 등의 정보를 수록한 기본정보(심증)와 해당 기본정보를 발생시킨 원인 패킷(물증), 상세정보(원시데이터)로 나뉜다. 즉, 물증인 원시데이터를 분석하면 룰의 문제점을 찾을 수 있다.
사례를 보자. 특정 SQL Injection 공격을 탐지하는 아래와 같은 룰이 있다.
alert tcp any any -> any 80(uricontent:"%20and%20";)
아래 표는 해당 룰에 의해 발생한 로그의 상세정보, 즉 원시데이터 사례이다. 참고로 원시데이터는 일정한 규칙으로 나열되지 않은 패턴의 집합, 즉 비정형 데이터이다.
해당 원시데이터의 공격 여부를 확인하기 위해서는 '%20and%20'이란 탐지패턴을 찾고, 해당 패턴이 전체 로그에서 어떤 의미로 사용되었는지를 파악해야 한다. (이런 식으로 보안로그가 발생할 때마다 원시데이터를 하나하나 분석하려면 많은 인력과 시간이 필요하다)
그런데 해당 비정형 원시데이터를 아래와 같이 탐지패턴을 기준으로 나열한 정형 데이터로 바꿔보자. ‘공백’을 의미하는 ‘%20’ 등의 특수문자(URL 인코딩 문자)도 읽기 쉽게 바꿨다.
원시데이터의 패턴 발생 분포가 한 눈에 파악되면서 탐지패턴을 찾는 별도의 노력 없이도, 탐지패턴의 의미 파악이 가능함을 알 수 있다.
이런 식으로 룰별 원시데이터를 분석하면 어떻게 될까? 더 많은 로그를 더 빨리 분석할 수 있음은 물론, 정량적인 룰 정확도 측정이 가능해진다. 그리고 결정적으로 확인된 공격과 오탐(공격 표절) 패턴의 발생분포를 룰 정교화 작업의 근거로 사용할 수 있다.
사례 결과를 근거로 패턴 필터링을 한 번만 하던 기존 룰을 아래와 같이 두 번 필터링하도록 바꿀 수도 있다. 공격 원리 및 특성이 반영된 룰에 특정 네트워크 환경의 특성 반영이 가능해지는 것이다.
alert tcp any any -> any 80(uricontent:“%20and%20”; pcre:”/%20and%20('|"|%27|%22)?\d(%|%25)?('|"|%27|%22)?(=|%3d)('|"|%27|%22)?\d('|"|%27|%22)?/”;)
분석된 원시데이터가 많으면 많을수록 룰 정교화 수준은 높아진다. 그리고 이런 과정을 통해 정교해진 룰은 ‘오탐(공격 표절)’을 줄일 것이고, 자연스럽게 검사해야할 보안로그의 양도 줄일 것이다. 전수검사의 가능성이 높아지고, 해킹 시도를 놓치지 않고 적시에 발견할 가능성이 높아지는 것이다.
보안로그 원시데이터는 공격 여부 검증은 물론 보안솔루션의 정확도를 좌우하는 핵심 데이터임에도 그동안 제대로 주목을 받지 못해왔다. 그 이유는 2가지이다.
1. ‘룰 기반 보안 솔루션’의 개발방향이 ‘룰의 정확성’보다 ‘처리 성능’에 집중되어 왔다. ‘IT 인프라 강국’의 딜레마일까? 업계는 그동안 ‘정확히’ 보다 ‘많이 그리고 빨리’ 처리하는 것에 집중해온 것이다.
2. ‘룰 개발 및 분석 전문가’를 양성하고 그들의 노하우를 축적 및 개량해서 업계의 역량으로 발전시키는데 소홀했다.
그 결과 대량의 부정확한 보안로그가 양산되면서 보안업계는 보안로그라는 빅데이터에 파묻히고 말았다. 업계를 후끈 달군 빅데이터는 사실 가까이 있었던 것이다.
기존에 없던 데이터가 빅데이터 시대라서 하늘에서 뚝 떨어졌을까? 데이터는 항상 우리 주위에 있어 왔고, 데이터웨어하우스니 데이터마이닝이니 하는 기술도 항상 있어왔다. 빅데이터는 그저 좀더 새로운 관점에서 데이터를 처리하는 기술에 대한 마케팅의 일환일 뿐이다.
보안로그는 원시데이터를 포함한 수많은 데이터를 가지고 있다. 그리고 그 데이터들은 지금 이 순간에도 우리가 주목해주길 바라고 있다. 빅데이터에 열광하기 전에 가까이 있는 데이터에 주목하는 순간, 그 데이터는 진정한 빅데이터가 될 것이다.
관련 글
댓글 없음:
댓글 쓰기