• 본 문서는 2025년 12월 26일 기준으로 작성되었습니다.

• Elasticsearch 9.2.0, Kibana 9.2.0 버전을 기준으로 기술하였습니다.

Attack Discovery

Attack Discovery란

 당신은 보안관제팀의 담당자입니다. 산더미처럼 쌓이는 수많은 경고 알람들은 항상 당신에게 고민거리입니다. 어떤 것이 공격의 징후인지 파악해보려 하던 열정이 점점 식으며, 이제 이 보안알람들이 귀찮게 느껴집니다. 그러나 당신은 알람들을 일일이 확인해야만 합니다. 혹시라도 침해사고가 발생하면 당신이 책임을 져야하기 때문이죠. 당신은 조금 더 나은 방법이 없을까 생각해봅니다. 이 모든 과정을 알아서 해주는 것으 없나 하고요. 그런 당신의 눈 앞에 한 줄기 빛이 내려오더니, 하늘에서 목소리가 들립니다. "엘라스틱서치 Attack Dicovery를 쓰거라"

 Attack Discovery는 Elastic Security에서 생성되는 다수의 보안 위협 알림들을 LLM이 일종의 시나리오 단위로 묶어서 요약해주는 기능입니다. 사람이 일일이 위협 알람을 하나씩 열어보면서 연결고리를 찾는 대신, Attack Discovery가 알람들 사이의 관계를 분석하여 공격 흐름을 만들어 보여주는 방식입니다.

 기존에는 1. 수백 개의 알람이 쌓이고, 2. 그 알람들의 우선순위를 매긴 뒤에, 3. 비슷한 것끼리 묶고, 4. 타임라인을 만들어 5. 공격 시나리오인지 파악해야 했습니다. Attack Discovery는 이 과정에서 2~4 단계를 자동화해준다고 보면 됩니다. LLM이 잘하는 정리, 분석, 요약을 제공받고, 실제 공격 시나리오인지만 파악하면 되어 굉장히 편리합니다. 당신은 드디어 해결책을 찾았고, 얼른 사용해보려 합니다.

LLM 커넥터 연동

 Attack Discovery를 사용하려면 먼저 LLM이 필요합니다. OpenAI ChatGPT, Google Gemini, Amazone Bedrock 등 Public LLM은 물론이고 Private LLM도 연동 가능합니다. 물론, 더 발전된 모델일 수록 결과값도 높습니다. 마침 GPT와 Bedrock을 사용중이던 당신은 GPT API 키와 Bedrock Access Key, Secret Key를 발급 받습니다.

이름과 URL, Model을 선택하고, Access Key와 Secret Key를 입력한 뒤 저장합니다.

마찬가지로 커넥터 화면에서 OpenAI를 클릭한 뒤, 이름과 URL, Model을 선택하고, API Key를 입력한 뒤 저장합니다.

테스트 화면에서 답변이 돌아온다면 정상적으로 연동된 것입니다.

지식베이스 설정

 LLM 연동이 끝났다면 이제 LLM에게 기본적인 엘라스틱서치의 Security 지식을 알려줘야합니다. LLM은 이 지식베이스를 기반해 답변에 참고하여 응답을 돌려줍니다. 키바나 Stack Management -> AI Assistants -> Security -> Knowlede Base 탭으로 이동합니다. 여기에서 Security Labs라는 지식베이스를 추가해줍니다. 

지식베이스가 설치되면 위와 같이 Author Elastic, Entries 190으로 지식베이스가 생성됩니다. (Entries는 엘라스틱서치 버전에 따라 다를 수 있으며, 9.2버전은 190개, 8.18버전은 168입니다.)

분석 범위 설정

 지식베이스가 설치되고 나면 이제 Security 기반 알람에 대한 Attack Discovery 분석이 가능해집니다. Attack Discovery 화면으로 돌아와, 우측 상단 설정 버튼을 클릭합니다.

 설정에서, 알람을 분석할 범위를 지정할 수 있습니다. 분석할 범위 시간을 지정할 수 있으며, 커스텀 쿼리를 통해 필터링을 할 수 있고, 커넥터 지정을 할 수 있습니다. 그리고 최대 분석 알람 개수를 지정할 수 있습니다. 현재는 500개까지 가능합니다.

 설정을 마쳤다면 Save and run을 실행합니다.

토큰 줄이기

 당신은 일부러 최대 알람으로 설정 후 분석하게 하였습니다. 그랬더니, 토큰이 너무 많다면서 오류가 리턴됩니다. 오류 문구를 보면 'Input is too long for requested model' 이라고 나옵니다. 당신은 고민에 빠집니다. 어떻게 하면 토큰을 줄일 수 있을까?

 다행히도 방법이 있었습니다. 당신은 LLM에 전달되는 필드를 줄여 토큰을 최적화 해보려 합니다.. 키바나 Stack Management -> AI Assistants -> Security -> Anonymization으로 이동합니다. 여기에서, LLM에 전달될 필드를 지정할 수 있습니다. 기본값으로 모든 필드가 LLM에 전달되며, 여기에서 Allowed 항목을 체크 해제 하면 전달되지 않습니다.

 임의로 하나의 필드를 체크 해제하니, 전체 Avaliable 필드가 102개인데 Allowed 필드가 101개로 나온 모습입니다. 필요 없는 필드들을 체크해제하면 그만큼 _source가 줄어 토큰 수를 굉장히 많이 줄일 수 있습니다.

익명 처리

 Public LLM은 성능이 좋은 반면, 사내 데이터가 외부로 전송된다는 리스크가 있습니다. 당신은 외부 유출을 바라지 않는 민감한 정보는 익명 처리를 하고 싶습니다. 또 한번 다행히도, 방법이 있습니다. 바로 Anonymization입니다. 같은 화면에서, Anonymized 항목을 클릭해 기본값인 익명처리 No에서 Yes로 바꾸면, 필드를 익명처리 할 수 있습니다.

 user.name 항목을 익명처리하여 Anonymized 개수가 1개로 증가한 사진입니다. 이를 통해 민감한 정보는 익명화하여 LLM에 전달이 가능하며, 보다 안전하게 Attack Discovery 사용이 가능해집니다.

마치며

 이번 포스팅에서는 Attack Discovery가 무엇인지, 어떻게 구성하는지, 어떻게 최적화 하는지를 알아보았습니다. 마치 나의 일인것처럼 하나의 엔지니어가 되어 고민하고 방법을 찾는 과정처럼 약간의 억지를 더해 포스팅해보았습니다. Attack Discovery 항목은 여전히 꾸준한 개발이 있기에, 추후 버전에는 커스텀 쿼리를 ESQL로 확장해 Lookup Join과 같은 기능을 활용할 수 있다면 더 좋을 것 같습니다. 많은 엔지니어들에게 도움이 됬길 바라며 포스팅을 마칩니다.