Concept

1. False Positive?

• 즉각적인 반응에 대해 일으키도록 지정된 경고들
• 경고 자체가 완벽한 경고는 아니다.

Alert의 경우, True positive 와 False positive, True nagative, False negative 가 있다.

💡 true positive : 실제 잘못된 것에 대한 경고
💡False positive : 실제로는 경고할만한 사항이 아닌데 경고 발생
💡true negative : 실제 경고할만한 사항인데 경고 발생 안함
💡false negative : 경고할만한 사항이 아니라서 경고 발생 안함

출처 : https://www.linkedin.com/pulse/which-worse-false-positive-false-negative-miha-mozina-phd

2. False Positive 결정 방법

false positive는 시간과 자원을 낭비한다.

잘못된 경고를 처리하기 위해 추가적인 자원(시간, 인력)이 소모된다. 개발자는 실제 문제가 아닌 경고를 조사하고 확인하는데 시간을 낭비하게 되며, 이는 생산성 저하로 이어진다.

1. 규칙의 상태를 조사
2. 경고의 맥락을 이해
3. 위협 피드백들과 다른 외부 데이터 리소스를 활용

3. false positives의 예시

false positives는 일반적으로 발생한다.

시스템이 특정 기술이나 코드 패턴을 사용하고 있다고 잘못 감지하고 경고를 발생시키는 경우가 있다. 예를 들어, 정적 분석 도구가 특정 키워드나 코드 조각을 통해 기술을 사용하고 있다고 판단하지만 실제로는 그렇지 않은 경우입니다. 이때 발생하는 경고는 실제 문제를 반영하지 않으므로 false positive에 해당한다.

1. 코드 분석 도구

• 코드 분석 도구가 특정 라이브러리나 프레임워크의 사용을 경고하지만, 해당 라이브러리를 실제로 사용하지 않는 경우
• 예) 코드에 "import numpy"라는 구문이 있지만, 실제로 사용된 적이 없는 경우, 도구가 numpy의 사용에 대한 경고를 생성

2. 보안 시스템

• 네트워크 보안 시스템이 특정 프로토콜이나 포트를 사용하는 공격을 감지했다고 경고하지만, 실제로 해당 프로토콜이나 포트가 사용되지 않는 경우
• 예) 특정 포트에서의 트래픽을 탐지해 공격 경고를 발생시켰지만, 해당 포트가 닫혀있거나 사용되지 않는 경우

4. false positives 예방

• 기본 규칙들을 검토한다.
• 경고들의 심각한 정도나 우선순위를 보장한다.
• 지속적으로 규칙들을 모니터하고 수정한다.
• loop를 없앤다.

LAB

#1

Q. 경고가 무엇인가?
incident review 에 들어가면 다음과 같은 탐색 결과를 볼 수 있다. Title 필드를 확인하면 어떤 공격인지 알려준다.

#2

Q. 여기서 경고가 발생되게 만든 규칙이 무엇인가?

source=* | bin_time span=5m as minute |stats count(eval('action'=="failure")) as failure count(eval('action'=="success")) as success by src_ip | where success>=0 AND failure>=2 | eval minute=strftime(minute,"%H:%M")

모든 source에 대하여 5분의 시간 범위동안 “failure” 결과가 있다면 count세서 failure로 저장하고 “success” 결과가 있다면 success로 저장한다.
success 가 0보다 크거나 같고, failure가 2보다 크거나 같은 경우를 탐색한다.
이렇게 각각의 공격 유형별로 규칙을 정하여 걸러내는 것이다.

bruteforce 공격

이론적으로 가능한 모든 경우의 수를 다 검색해보는 것이다.

그래서 위의 랩에서도 review에 같은 지속적인 공격이 있는 것이다.

#3

Q. 로그인 시도를 한 Source IP는 어느것인가?
공격을 분석해준 통계를 확인하면 총 2개의 src_ip 가 있는 것을 알 수 있다.
총 2개의 ip가 공격을 시도했음을 알 수 있었다.

#4

Q. false positive는 무엇인가?
false positive 는 일종의 거짓 양성 반응이다. 공격이 되었다고 감지하나 사실은 공격이 아닌 것을 의미한다.

#5

Q. Logon Type 2 이벤트는 어떤 시나리오임을 의미하는가?

• Logon Type 필드를 확인하면 타입이 2임을 확인할 수 있다.
• 윈도우의 로그온 유형은 다음과 같다.

출처 : microsoft 공식 홈

#6

Q. 경고의 결과가 성공적인 로그인 시도임을 보여주는 경우 사용자는 성공적인 로그인을 어떻게 하게 되었는가?
DC 서버가 사용자 계정을 재설정했음을 알 수 있다.
그리고 Subject(주체) 필드를 확인하면 계정 이름이 administrator 임을 알 수 있다.
즉, administrator가 주체가 되어 DC 서버를 이용해 계정 정보를 재설정한 것이다. 재설정이후 USER055는 로그인 성공을 한다.

#7

Q. 4번의 실패 로그인 시도들이 false-positive 로 암시하는 이유가 무엇인가?
127.0.0.1 ip 주소에서 연속적인 로그온 활동으로 인해 브루트포스로 탐지가 된 경우이다. 하지만 몇가지 눈여겨볼 점이 있다.

1. 4번의 로그인 실패가 있다는 것
   → 로그인 시도 횟수가 많지않다.
2. time 필드로 필터링 해봤을 때, 로그인 시도의 시간이 각각 다르다는 점
   → 로그인을 시도하려했던 시간이 각기 다르다. 이는 프로그램으로 브루트포스를 했다고 볼 수 없다.
3. reset의 주체가 administrator 이라는 점
   → 다시 설정한 주체가 관리자였다. (외부인이 아님)
4. reset의 시간이 마지막 실패와 처음 성공 그 사이에 있다는 점
   → 시나리오가 사용자가 로그인 시도를 지속적으로 실패하자 비밀번호를 재설정하고 로그인을 성공했다는 것이 가능성 높음

#8

Q. 어느 유저가 시도를 하였는가?
root의 경우

* src_ip="199.203.100.229" root

admin의 경우

* src_ip="199.203.100.229" admin

user의 경우

* src_ip="199.203.100.229" user

간단하게 원하는 값이 들어있는지 확인하는 검색을 해보면 알 수 있다.

#9

Q. IP주소에 따르면 ip에서 알수있는 공격 지표가 아닌 것이 무엇인가?
목적지 ip는 하나로 동일하다.
여기서 공격은 여러 ip에서 하나의 공격대상이 되는 ip로 보내는 것이기 때문이다.

#10

Q. 브루트포스 공격에서 false-positive를 구별해내기 위한 방법이 무엇인가?

1. 로그인 시도들과 시간적인 차이
2. 원래의 ip 주소 위치와 그 주소에 대한 인터넷 소스를 확인
3. 사용자의 행동에서 일반적이지 않은 것을 확인 (로그인 시도와 로그온 유형)

SUMMARY

해당 실습에서는 브루트포스 공격이라고 의심되는 경고에 대해 올바른 경고인지 살펴보는 과정을 진행했다.
두개의 IP에서 온 공격이 있었고, 그중 하나는 사용자가 암호를 까먹어 계속 틀리는 행동을 반복하는 것이 공격으로 간주되어 False Positive 경고가 발생했다.
공격이라고 판별된 경고에 대해 시나리오를 자세히 따져보고 진짜 공격 상황인지 판별하는 것은 굉장히 중요하다.