보안 포탈 설계 (1) 업무 티켓으로 보안 이벤트를 받아봤습니다

티켓과 보안 이벤트가 어떻게 다른지를 다룹니다. 시리즈의 다른 글 보기

안녕하세요. 오픈소프트랩에서 보안 운영 포탈을 만드는 개발팀입니다.

저희는 티켓 시스템을 여러 번 만들어봤습니다. 프로젝트 관리로 시작해서 IT 서비스 관리, 개발 운영 관리까지 왔습니다. 요청이 들어오면 담당자를 정하고, 결재를 거치고, 처리하고, 이력을 남기는 구조를 10년 가까이 다듬어 왔습니다. 그 과정은 업무 시스템 다시 만들기 시리즈에 적었습니다. 마지막 편에서 그 뼈대가 보안 업무에서 처음 어긋났다고 썼는데, 이번 시리즈가 그 이야기입니다.

그래서 보안 운영을 맡게 됐을 때 이렇게 생각했습니다.

보안 업무도 결국 티켓이다. 탐지된 이벤트를 티켓으로 만들고, 담당자를 정하고, 처리하고 닫으면 된다. 우리가 제일 잘하는 일이었습니다.

틀린 생각은 아니었습니다. 지금도 그 구조 위에 서 있습니다. 다만 탐지 데이터를 실제로 받아보고 나서 몇 가지를 다시 짜야 했습니다.

티켓 324장이 만들어졌습니다

처음 연동해서 데이터를 받아봤을 때 나온 숫자입니다.

내부 계정 로그인 비정상 이벤트

  연관 Alert  324건

화면과 수치는 시연용 예시입니다.

업무 요청이라면 324건은 324개의 일입니다. 그런데 이건 하나의 사안이었습니다. 같은 계정, 같은 시간대, 같은 유형. 담당자가 확인해야 할 것은 "이 계정에 무슨 일이 있었나" 하나인데, 티켓은 324장이 생깁니다.

여기서 첫 번째 차이가 드러났습니다.

업무 티켓은 사람이 만듭니다. 누군가 "이것 좀 해주세요"라고 요청할 때 하나가 생깁니다. 사람이 만드니까 하나하나가 이미 하나의 일입니다.

보안 이벤트는 장비가 만듭니다. 탐지 규칙에 걸릴 때마다 생기고, 사람이 보기 전에 이미 쌓여 있습니다. 그리고 장비는 "이게 한 사건이다"를 모릅니다.

그래서 받는 쪽에서 묶어야 했습니다. 탐지 데이터를 그대로 티켓으로 바꾸는 게 아니라, 묶어서 하나의 처리 대상으로 만든 다음 티켓을 발행하는 단계를 넣었습니다.

처리했는데 끝나지 않았습니다

두 번째 차이는 더 늦게 나왔습니다.

업무 티켓은 담당자가 처리하면 끝납니다. 요청한 사람이 만족했는지는 별개고, 시스템 입장에서 완료 조건은 담당자의 행위입니다.

보안 이벤트는 달랐습니다. 담당자가 확인을 마쳐도 끝낼 수가 없는 건이 있었습니다.

탐지 시스템이 넘겨주는 데이터를 보면 이유가 보입니다.

시나리오 ID
대상자 ID · 이메일
위반 일시
상세 로그    (파일 반출, 특정 단어 포함 등)

누가 무엇을 했는지까지는 장비가 알려줍니다. 그런데 그게 위반인지 아닌지는 장비가 판단하지 못합니다. 업무상 정당한 반출일 수도 있고, 승인받은 작업일 수도 있습니다.

판단하려면 그 사람에게 물어봐야 합니다.

담당자가 아무리 자세히 봐도 당사자만 아는 맥락이 있습니다. 그래서 완료 조건이 담당자에서 대상자로 넘어갑니다. 티켓 시스템에는 없던 구조였습니다.

기다림이 절차에 들어왔습니다

사람에게 물어보고 답을 기다린다는 건, 절차 안에 시간이 들어온다는 뜻입니다.

업무 티켓에서 처리 시간은 성능 지표입니다. 빠르면 좋고 느리면 문제지만, 시스템이 특별히 할 일은 없습니다.

답을 기다리는 건 다릅니다. 안 올 수도 있습니다. 답이 없는 상태로 얼마나 둘 것인지, 그동안 이 건은 무슨 상태인지, 끝내 안 오면 어떻게 할 것인지를 전부 정해야 했습니다.

그래서 이 단계에만 상태를 일곱 개 뒀습니다.

요청 · 취소 · 진행 · 검토 · 기간 만료 · 회수 · 종료

처음 설계에는 요청과 종료밖에 없었습니다. 나머지 다섯은 운영하면서 하나씩 늘어난 것들입니다.

기간 만료가 필요했던 이유는 앞서 말한 대로입니다. 요청할 때 기한을 같이 정하고, 지나면 만료로 떨어집니다.

회수는 조금 다른 경우입니다. 담당자가 사안을 중간에 종료해야 할 때가 있는데, 그때 답을 기다리는 요청이 남아 있으면 대상자는 이미 끝난 일에 답을 씁니다. 그래서 중간 종료 시 미응답 요청은 회수하도록 했습니다.

검토는 답이 온 뒤의 상태입니다. 받았다고 바로 끝나는 게 아니라 담당자가 내용을 보고 판단해야 합니다.

다음 단계를 고르게 했습니다

여기까지 오니 원래 구조로는 부족했습니다.

업무 티켓은 대체로 정해진 흐름을 탑니다. 접수하고, 처리하고, 결재받고, 닫습니다. 순서가 미리 정해져 있습니다.

보안 이벤트는 건마다 다음에 할 일이 달랐습니다. 어떤 건은 바로 닫아도 되고, 어떤 건은 물어봐야 하고, 어떤 건은 조치 작업이 필요하고, 어떤 건은 결재를 받아야 합니다. 그리고 처음부터 알 수 없습니다. 들여다봐야 압니다.

그래서 흐름을 고정하지 않고, 처리하는 사람이 다음 단계를 고르게 했습니다.

현재: 소명
다음 단계 결정 →  소명 / 작업 / 결재 / 최종 완료

단계마다 담당자를 따로 지정할 수 있게 했습니다. 물어보는 사람과 조치하는 사람이 다를 수 있기 때문입니다.

이 구조를 넣으면서 결재 모듈을 크게 손봤습니다. 원래는 결재가 흐름의 정해진 위치에 있었는데, 어느 단계에서든 결재로 넘어갈 수 있게 되면서 결재를 따로 떼어내야 했습니다. 떼어내고 보니 흐름 곳곳에 박혀 있던 분기가 함께 사라졌습니다.

얻은 것과 포기한 것

얻은 것 — 탐지 데이터를 그대로 받아도 처리 가능한 단위로 정리됩니다. Alert 수백 건이 하나의 사안이 되고, 그 사안에 대해 누가 무엇을 판단했는지가 한 흐름에 남습니다. 감사 때 이력을 다시 짜맞출 필요가 없어졌습니다.

포기한 것 — 흐름이 고정되지 않으니 운영자가 매번 판단해야 합니다. 업무 티켓처럼 정해진 대로 흘러가지 않습니다. 담당자마다 다르게 처리할 여지도 생겼습니다.

이건 감수하기로 한 쪽입니다. 보안 이벤트는 건마다 성격이 달라서, 흐름을 고정하면 맞지 않는 건이 반드시 나옵니다. 그때 담당자는 시스템을 우회합니다. 메일로 처리하고 결과만 입력하는 식으로요. 그러면 이력이 끊깁니다.

정해진 대로 흘러가는 시스템과 이력이 남는 시스템 중에 후자를 골랐습니다.

무엇을 하나로 묶을 것인가

지금 가장 애매한 부분입니다.

Alert 324건을 하나로 묶는 건 쉬웠습니다. 같은 계정, 같은 시간대, 같은 시나리오였으니까요. 그런데 경계가 흐린 경우가 많습니다.

같은 사람이 비슷한 행위를 사흘에 걸쳐 했다면 한 사안인지 세 사안인지, 같은 시간대에 여러 사람이 같은 유형으로 걸렸다면 사람별로 나눌지 유형별로 묶을지 — 묶는 기준이 달라지면 담당자가 봐야 할 건수가 크게 달라집니다.

지금은 탐지 시스템이 보내주는 시나리오 단위를 그대로 씁니다. 사전에 정의한 시나리오 ID로 넘어오기 때문에 그 경계를 신뢰하는 방식입니다. 저희가 임의로 다시 묶는 것보다 탐지 쪽에서 정한 경계를 존중하는 편이 안전하다고 봤습니다.

다만 이렇게 하면 시나리오 설계에 따라 포탈의 업무량이 정해집니다. 탐지 규칙을 손볼 때 포탈에 얼마나 쌓일지를 같이 봐야 하는데, 지금은 그걸 미리 보여주는 방법이 없습니다. 시나리오별로 최근 발생량을 보여주는 화면을 먼저 붙였고, 다음에는 규칙을 바꾸기 전에 예상 건수를 가늠할 수 있는 쪽을 보려고 합니다.

다음 편에서는 물어보고 답을 받는 절차를 어떻게 만들었는지 다룹니다.

오픈소프트랩 개발팀이 작성합니다. 보안 운영 포탈과 생성형 AI 사용 통제를 만들고 있습니다.