다음은 스플렁크의 머신러닝. 모두 이상징후 분석에 촛점이 잡혀있다. 아무래도 이상징후 분석 시장이 제일 크기 때문일 것이다. 보안을 포함한 모든 산업 분야에 적용할 수 있으니까.
미국애들이 안 하는 건지, 못하는 건지 모르겠지만 개인적으로 IDS, IPS 등 패턴매칭 분야에 대한 인공지능 도입 시도에 대해서는 부정적이다. 이유는
일단 룰이 많다
바둑 룰은 하나다. 이어지는 돌(로 만들어진 집)이 많으면 이긴다. 알파고가 이세돌보다 바둑을 잘 두는 이유는 그 단순한 룰이 담겨진 16만 개의 기보(3천만 개의 포석) 데이터를 들이부었기 때문.
바둑 포석이 우주의 원자 개수보다 많네 어쩌네 하지만, 그건 말 그대로 경우의 수일 뿐이고, 사람 생각하는 게 다르면 얼마나 다를까. 결국 3천만 개의 포석에는 사람 머리에서 나올만한 포석이 모조리 담겨 있다고 봐도 무방하다. 결과는 천하무적 알파고.
패턴매칭은 룰이 수천 개다. 개점휴업 상태인 룰을 빼도 수백 개 이상. 왜 이렇게 많을까 싶지만, 알려진 공격 패턴(15년쯤 7만 개였던 CVE가 어느새 10만 개)에 비하면 많은 것도 아니다.
왜 많을까?
(취약점이 많아서이기도 하지만) 룰 제작은 실적 포장이 쉽다. '새로운 위협에 대응하기 위해 새로운 룰을 만들었습니다'란 보고는 칭찬받기 쉽다. 잘했으니까. 그런데 새로 만든 룰이 정확도가 형편 없는 오탐 공장이라는 보고는 하기 어렵다. 혼날테니까(..)
그래서 사후분석을 통해 정확도를 높이거나, 유사도 측정 등을 통해 중복도를 낮추는 작업은 잘 실행되지 않으며, 실행된다 한들 별로 주목받지도 못한다. 번거로움에 비해 실적이 될 가능성이 낮다는 얘기. 왜 그럴까?
혼나는 건 둘째치고 일단 설명이 어렵다. (아래 웹쉘 탐지 예시를 사장님께 설명해보자) 하지만 빅데이터나 인공지능같은 걸 끼얹으면 설명이 쉬워지는 수준을 넘어, 설명이 필요 없어지는 마법을 경험하게 됨.
결국
단순하지도 않다
다음은
<%@ page import=”java.util.*,java.io.*”%>
<HTML><BODY>
<H3>JSP SHELL</H3>
<FORM METHOD=”GET” NAME=”myform” ACTION=”">
<INPUT TYPE=”text” NAME=”cmd”>
<INPUT TYPE=”submit” VALUE=”Execute”>
</FORM><PRE><%
if (request.getParameter(“cmd”) != null) {
out.println(“Command: ” +
request.getParameter(“cmd”) + “<BR>”);자바 패키지를 사용할 수 있게 해주는 코드의 일부인 'import="java'란 패턴으로 JSP 웹쉘 공격을 탐지하는 룰을 만들어 보자. 어떤 일이 벌어질까? 다음은 회원정보를 뿌려주는 JSP 코드 일부.
<%@ page import="java.util.*"%>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<% request.setCharacterEncoding("UTF-8"); %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>회원 파라미터 출력</title> </head>
<body> <h2>request.getParameter() 메서드</h2>
name 파라미터 : <%=request.getParameter("name") %><br>
age 파라미터 : <%=request.getParameter("age") %><br>
gender 파라미터 : <%=request.getParameter("gender") %><br>'import="java'란 문자열은 JSP 개발 과정에서 흔하게 나타나는 패턴임을 알 수 있다. 그리고 해당 문자열 패턴을 검사하는 룰은 JSP 파일을 송수신하는 정상 트래픽(주로 파일 업로드)을 죄다 웹쉘 공격이라며 탐지할 것이다.
처음부터 완벽한 룰을 만들기는 어렵다
그런 로그 정오탐 잘 구분해서 인공지능에 들이부으면 제법 잘 동작할 것이다. 구분이 까다롭다 한들, 학습 데이터 죽어라 만들다 보면 언젠가는 인공지능이 다 해주는 날도 오겠지. 룰은 계속 만들어질테니, 스스로 학습하는 인공지능이 나오기 전까지 학습 데이터는 계속 만들어줘야겠군.
그런데 이왕 만든 학습 데이터로 룰도 개선해보면 어떨까? 룰이 정확해지면 오탐이 줄테고, 덩달아 로그양도 줄테고, 그러면 수백, 수천 만 개의 로그에서 공격을 찾아 헤매는 일도 줄텐데. 가만, 그러면 인공지능 할 일이 없어지겠네!?
우린 이미 알고 있다. 로그를 발생시키는 원천의 문제를 해결하지 않고 있다는 사실을, 오염된 상류를 방치한 채 하류에서만 정수를 하려 한다는 사실을
수단 VS 목적
생각이 이쯤에 이르니 인공지능과 보안 정확도 중 뭐가 수단이고, 뭐가 목적인지 헷갈리기 시작한다. 현재로선 인공지능 도입의 정당성을 부여하기 위해 금기어였던 정확도를 들춰내고, 학습 데이터 만들기 위해 관심 밖이던 정오탐 구분을 독려하는 상황이니(..)
어쩌면 오탐은 보안 업계의 영원한 성장동력으로 그 존재가치를 갖는지도 모르겠다. 영원히 해결 불가능한 문제로 남아 새로운 컨셉의 제품을 계속 팔 수 있게 해주는 무한 성장동력
어쩌다 인공지능 가르칠 학습 데이터 알바(?)를 하게 되면서 이런저런 생각이 들어 끄적여봤다. 딱 봐도 비관적인데 왜 하냐고? 인공지능이 얼마나 일 잘하는지 구경 좀 해보고 싶더라. 물론 돈도 준대고.
그나저나 IDS, IPS를 10년 이상 운영해 온 조직에 인공지능 학습에 쓸만한 데이터가 없다고 한다. 그럴 리가 없는데, 기계에게 일자리 뺏길까봐 협조하지 않는 걸까?
관련 글
- 보안 알파고?
- 미국의 오탐 대응
- 인공지능 이상징후 탐지 시스템?
- 데이터 분석에 필요한 자질은 뭘까?
- 기계학습가 침입탐지: 문법 추론 결과
- 엘라스틱 지도학습으로 IDS 정오탐 구분해보기
댓글 없음:
댓글 쓰기