이상 감지를위한 기능 준비 / 구성 방법 (네트워크 보안 데이터)

저의 목표는 침입 탐지 목적으로 클러스터링 / 변칙 탐지를 사용하여 네트워크 로그 (예 : Apache, syslog, Active Directory 보안 감사 등)를 분석하는 것입니다.

로그에는 IP 주소, 사용자 이름, 호스트 이름, 대상 포트, 소스 포트 등과 같은 많은 텍스트 필드가 있습니다 (총 15-20 필드). 로그에 몇 가지 공격이 있는지 알지 못하고 가장 의심스러운 이벤트 (이상치)를 강조하고 싶습니다.

일반적으로 이상 감지는 확률 / 빈도가 낮은 포인트를 이상으로 표시합니다. 그러나 로그 레코드의 절반에는 고유 한 필드 조합이 포함됩니다. 따라서 데이터 세트의 레코드 중 절반이 가장 낮은 빈도를 갖습니다.

클러스터링을 기반으로 이상 감지를 사용하는 경우 (예 : 클러스터를 찾은 다음 모든 클러스터 중심에서 멀리 떨어진 점을 선택) 서로 다른 점 사이의 거리를 찾아야합니다. 필자는 15-20 개의 필드를 가지고 있기 때문에 차원이 사용자 이름, 포트, IP 주소 등인 다차원 공간이됩니다. 그러나 Mahalanobis 거리는 정규 분포 피쳐에만 적용 할 수 있습니다. 이것은 데이터 포인트 사이의 거리를 찾고 클러스터를 구성 할 방법이 없다는 것을 의미합니다 ...

예를 들어 20 개의 레코드 데이터 세트에 사용자 Alice, Bob, Carol, Dave, Eve 및 Frank가 있다고 가정 해 봅시다. 데이터베이스에서 2,5,2,5,1,5가 발생할 수 있습니다. 단순히 사용자 이름을 숫자로 매핑하면

Alice --> 1
Bob --> 2
Carol --> 3
Dave --> 4
Eve --> 5
Frank --> 6

그런 다음 사용자 이름에 대한 확률 분포는 다음과 같습니다.

p (1) = 0.1, p (2) = 0.25, p (3) = 0.1, p (4) = 0.25, p (5) = 0.05, p (6) = 0.25

물론 이것은 일반적인 배포가 아니며, 다른 방법으로 사용자 이름을 매핑 할 수 있기 때문에 의미가 없습니다 ...

따라서 사용자 이름, 작업, 포트 번호, IP 주소 등과 같은 필드를 숫자로 간단히 매핑해도 아무런 효과가 없습니다.

따라서 감독되지 않은 이상 / 이탈 감지가 가능하도록 일반적으로 텍스트 필드를 처리 / 기능을 구성하는 방법을 묻고 싶습니다.

편집 : 데이터 구조.

데이터베이스 테이블에 약 100 개의 열이 있으며 Active Directory Events의 정보가 들어 있습니다. 이 100 개의 열에서 가장 중요한 항목을 선택합니다 : SubjectUser, TargetUser, SourceIPaddress, SourceHostName, SourcePort, Computer, DestinationIPaddress, DestinationHostName, DestinationPort, Action, Status, FilePath, EventID, WeekDay, DayTime.

이벤트는 Active Directory 이벤트이며, 여기서 EventID는 기록 된 내용 (예 : Kerberos 티켓 생성, 사용자 로그온, 사용자 로그 오프 등)을 정의합니다.

데이터 샘플은 다음과 같습니다.

+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| ID | SubjectUser | TargetUser | SourceIPaddress | SourceHostName | SourcePort | 컴퓨터 | DestinationIPaddress | DestinationHostName | DestinationPort | Action | 상태 | FilePath | EventID | WeekDay | DayTime |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| 171390673 |? |? |? |? |? | domaincontroller1.domain.com | 1.1.1.1 | domaincontroller1.domain.com |? | / 인증 / 확인 | / 성공 |? | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| 173348232 |? |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / 인증 / 확인 | / 성공 |? | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| 180176916 |? |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / 인증 / 확인 | / 성공 |? | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| 144144725 |? | John.Doe | 3.3.3.3 | domaincontroller3.domain.com | 2407 | domaincontroller3.domain.com | 3.3.3.4 | domaincontroller3.domain.com |? | / 인증 / 확인 | / 성공 |? | 4624 | 3 | 12345 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+

모두 함께 약 1 억 5 천만 개의 이벤트가 있습니다. 각기 다른 이벤트에는 다른 필드가 채워져 있으며 모든 이벤트가 사용자 로그온 / 로그 오프와 관련된 것은 아닙니다.

나는 이상 탐지 에 대한 전문가가 아닙니다 . 그러나, 그것은 흥미로운 영역이고 여기에 내 두 센트가 있습니다. 먼저, "마할 라 노비스 거리는 정규 분포 된 피처에만 적용 할 수 있습니다." 비정규 데이터의 경우에도 해당 메트릭을 계속 사용할 수 있다고 주장하는 일부 연구를 진행했습니다 . 에서 자신을 위해 좀 받아 본 논문 과 이 기술 보고서를 .

또한 유용한 다음 찾을 수 있기를 바랍니다 자원 에 대한 자율 이상 탐지 (AD) 의 IT 네트워크 보안 컨텍스트를 다양한 방법과 방법 사용 : 본 연구 하는 제시 기하학적 인 프레임 워크 자율 AD를 들어; 밀도 기반 및 그리드 기반 클러스터링 방식 을 사용하는 이 백서 ; 이 프리젠 테이션 슬라이드 에서는 AD에 대한 자체 구성 맵 사용에 대해 설명합니다.

마지막으로, 주제와 관련이 있다고 생각되는 다음과 같은 답변을 살펴볼 것을 제안합니다 . 클러스터링 접근 방식 에 대한 답변, 비거리 기반 클러스터링 에 대한 답변 및 소프트웨어 옵션에 대한 답변 광고 .

우선, 사임해야 할 것이 몇 가지 있다고 생각합니다.

이 문제에서 볼 수있는 어려운 제약 중 하나는 아마도 높은 오 탐지율을 갖도록 준비해야한다는 것입니다. 내가 아는 한, 네트워크 이상의 일부인 기본 레코드 비율은 상당히 낮습니다 (인용 필요). 논쟁을 위해 1000 : 1 확률이라고합시다. 그런 다음 레코드가 침입이면 합법적 일 경우 발생할 가능성이 100 배 더 높은 패턴을 관찰하더라도 Bayes 'Rule에 따르면 사후 확률은 10 : 1이며 트래픽은 여전히 ​​합법적입니다.

다른 문제는 원칙적으로 일부 침입은 탐지하기 어렵다는 것 입니다. 예를 들어 누군가 누군가가 저에게 컴퓨터를 제공하도록 사회 공학적으로 설계 한 다음이 서비스에 로그인하여 내가 작업했던 최고 비밀 파일 하나를 다운로드 한 경우 찾기가 매우 어려울 것입니다. 기본적으로 충분히 결정된 공격자는 침입 행동을 시스템의 정상적인 동작에 거의 임의로 가깝게 만들 수 있습니다.

또한 적들은 통계적 프로세스가 아니라 지능적이므로 일부 패턴을 감지하고 종료하기 시작하면 해당 패턴을 더 이상 따르지 않음으로써 단순히 응답 할 수 있습니다. 예를 들어, 모든 문자 사이에 공백이있는 스팸 메시지가 많이 나타나는 이유는 무엇입니까 ( " V I A G R A"또는 기타 항목을 제공함 ). 스팸 필터는 "viagra"라는 문자열이 스팸이라는 것을 알아 냈으므로 공격자들은 다른 작업을 시작했습니다.

이로 인해 어떤 유형의 신뢰를 감지 할 수 있는지 알아볼 가치가 있다고 생각할 가치가 있다고 생각합니다. 여기에 매달려있는 과일이 확실히 있기 때문에 완벽한 것을 선의 적으로 삼지 말고 모든 침입을 감지 할 수있는 알고리즘을 생각해보십시오.

저것은, 거꾸로 과일에 대해 이야기합시다. 여기서는 분석 단위를 개별 레코드에서 레코드 그룹 으로 전환하는 것이 생산적이라고 생각합니다 .

예를 들어, 모든 레코드의 절반에 고유 한 필드 조합이 있다고합니다. 그러나 아마도 예를 들어 대부분의 소스 IP는 하나 이상의 레코드에 나타납니다. 요청의 다른 필드가 변경되어 조합을 고유하게 만듭니다. IP로 요청을 그룹화하면 다음과 같은 질문을 할 수 있습니다.

• 일부 IP가 비정상적으로 많은 사용자 (또는 비정상적으로 소수)로 인증되는 것 같습니까?
• 일부 IP에 비정상적으로 많은 수의 인증 실패가 있습니까?
• 일부 IP의 경우 비정상적인 액세스 타이밍 패턴이 있습니까 (예 : 시간대에서 오전 3 시쯤에 많은 활동이 있거나 하루 종일 1 초마다 요청)?

사용자 이름과 같은 다른 그룹에 대해 비슷한 작업을 수행 할 수 있습니다.

• 이 사용자가 이전에 모든 요청에 ​​동일한 컴퓨터를 사용했을 때 다른 컴퓨터에서 인증하고 있습니까?
• 이 사용자가 이전에 한 번도 본 적이없는 파일 시스템의 일부를 갑자기 만지고 있습니까?

사용자의 잠재적 행동이 매우 다양 하고 시간이 지남에 따라 행동 변화 에 관심이 있기 때문에 이것에 특히 적합한 상용 분류기를 알지 못합니다 . 즉, 향후 각 사용자 / IP / 무엇이 수행 될 것인지에 대한 일종의 모델을 구축하고이 모델과의 편차를 표시하려고합니다. 그러나 사용자의 행동 패턴이 다른 경우에는 매우 집중적 인 프로세스입니다!

이러한 어려움 때문에, 지금까지 위에서 설명한 일종의 탐색 모드 분석을 수행하는 것이 더 생산적이라고 생각합니다. 즉 패턴의 종류가 가장 흥미로운 사람이 무엇인지에 대해 알려 가능성, 그리고 다음 당신은 그 패턴을 감지하는 멋진 통계 알고리즘을 사용하여 시작할 수 있습니다.

처음 에는 공격 이 없는 기간 동안 데이터를 기록하는 데이터 집합이 필요하다고 생각합니다 . 이 데이터 세트는 정상적으로 작동하는 시스템 고유의 변형을 캡처해야합니다. 주석이 달린 데이터 세트가 아니라는 점을 강조하고 싶습니다.

다음으로 모든 (또는 하위 집합) 메트릭을 하나로 결합하려고합니다. 이 새로운 측정 항목은 "놀람"의 양을 반영해야합니다. 예를 들어, 낮은 값은 시스템이 정상적으로 작동한다는 의미이고 높은 값의 피크 / 고원은 빠른 변화가 있음을 의미합니다. 여기서는 CUSUM 또는 Shewhart 차트 스타일 차트에 대해 생각하고 있습니다.

사용 가능한 데이터의 예를 제공 할 수 있습니까? 주로 문자열, 숫자, 1/0 표시기입니까?

공격없이 백그라운드 데이터가 제공되는 기능간에 베이지안 네트워크를 학습 할 수 있습니다. 베이지안 네트워크를 학습하면 기능간에 조건부 독립성을 제공하므로 유용합니다. 따라서 가능한 모든 기능 조합을 다루지는 않습니다. 예를 들어, 특징 A가 B와 C에 영향을 미치고 특징 B와 C가 함께 D에 영향을 미치는 경우, A가 B에 미치는 영향, C에 미치는 영향 및 B와 C가 D에 어떻게 영향을 미치는지에 대한 모델 만 배웁니다. 전체 확률 분포보다 매개 변수이며 전체 결합 확률 분포를 저장하는 대신 베이지안 네트워크를 사용하는 주요 이유입니다. 베이지안 네트워크에 이상이 있는지 테스트하려면 학습 된 베이지안 네트워크 모델을 사용하여 들어오는 데이터 포인트의 확률을 계산하십시오. 확률이 매우 낮 으면

Ben Kuhn의 답변은 실용적이고 통찰력이 있다고 생각했습니다.

이제 내 자신의 배경은 텍스트 분류, 전문가 시스템, 클러스터링 및 보안에 포함됩니다. 이러한 배경을 감안할 때, 나는 것 처럼 나는 대화에 추가 할 것이 있다고 생각 할 수 있습니다. 그러나 벤 쿤 (Ben Kuhn)의 이전 진술은 간단한 접근 방식이 많은 오탐 (false positive)을 생성 할 수 있음을 강조합니다. IT 직원은 많은 오탐 (false positive)에 직면했을 때 일반적으로 항상 오탐 (false positive)을 추적 할 시간이 없기 때문에 일반적으로 "조정"합니다.

그래서 뭘 할건데?

확실히 공격이있는 로그는 도움이 될 수 있지만 회사가 공격 데이터를 공유하지 않는 한 catch-22가 있습니다. 일부 실리콘 밸리 스타트 업이 그러한 위협 공유를 추구하고있을 수 있지만, 우리는 무엇을 할 수 있습니까?

가능한 방법 중 하나는 네트워크 시뮬레이션을 만든 다음 시뮬레이션에 대한 공격을 생성하는 방법을 찾는 것입니다. 즉, 검은 색 모자 (또는 시뮬레이션 된)가 흰색 모자에 미리 알려지지 않은 시뮬레이션을 만든다고 가정합니다. 이러한 공격이 주어지면 이러한 공격을 발견해야하는 알고리즘을 만들 수 있습니다. 검은 모자가 흰색 모자와 독립적으로 작동하면 실제 전투가 벌어집니다. 공격자가 시스템에 침입하거나 탐지되지 않으면 흰색 모자가 어느 정도 실패한 것입니다.

블랙 햇 팀의 보안 분석가가 성공 (브리치 또는 알려지지 않은 공격)에 대해 보상을받을 때 인센티브 구조를 가질 수도 있습니다. 유사하게, 흰 모자를 포함하는 그룹은 브리치 중단 및 / 또는 공격 탐지에 대해 보상을 받는다.

이 배열에 대해 완벽한 것은 없습니다. 분명히 실제 검은 모자는 "친절한"검은 모자 팀의 재능을 능가 할 수 있습니다. 그럼에도 불구하고, 상당한 양의 데이터 분석을 가진 사람으로서, 검은 모자를 더 잘 이해하지 않고 흰 모자의 성공을 정량화하는 것은 매우 어려운 것 같습니다. 결론은 이것입니다. 우리가 진짜 검은 모자가 무엇을하고 있는지 알 수 없다면, 다음으로 가장 좋은 것은 친근한 검은 모자입니다.

나는 또한 다소 특이한 생각을 가지고 있습니다. 친근한 검은 모자와 흰색 모자 외에 회색 모자 팀이 있다고 가정하십시오. 회색 모자라는 것은 무엇을 의미합니까? 아이디어는 간단하다. 회색 모자는 친절한 검은 모자와 흰 모자가 무엇을하는지 볼 수 있습니다. 그런데 왜?

친근한 검은 모자가 A, B, C 접근법을 사용하여 공격을 시작하고 흰색 모자 가이 세 가지 접근법 중 어느 것도 발견하지 못한다고 가정 하십시오. 글쎄, 회색 모자는 친절한 검은 모자와 흰 모자가하는 일을 모두 볼 수있는 능력이 있으며, 감지되지 않은 공격을 발견하는 데 어떤 원칙이 사용되는지 고려하려고합니다. 회색 모자가 그러한 원칙을 찾으면, 회색 모자 팀은 정확한 공격을 자세히 설명 하지 않고 흰색 모자 팀과 이러한 원칙을 공유 할 수 있습니다 .

희망은 회색 모자 팀이 제공 한 이러한 "힌트"가 흰 모자 팀에게 너무 많은 것을 밝히지 않고 올바른 방향으로 나아가도록하는 것입니다.

돌이켜 보면 응답이 특정 기술에 관한 것이 아니라면 사과드립니다. 분명히 내 대답은 특정 기술에 관한 것이 아닙니다 . 그러나 제 경험상 보안 문제를 포함하여 기계 학습의 많은 문제는 종종 데이터가 부적절하기 때문에 실패합니다. 흰 모자, 회색 모자 및 검은 모자를 사용하는이 접근 방식은 보안 회사 (또는 IT 직원)가 방어의 효과를 정량화 할뿐만 아니라 화이트 햇 팀을 추진하는 조직 구조를 제공 할 수있는 데이터를 생성하는 데 도움이 될 수 있습니다. 방어 및 모니터링을 점진적으로 개선했습니다.

내가 제안하는 접근법이 독창적인지 전혀 모른다. 나는 회색 모자에 대해 들어 본 적이 없지만 실제로 회색 모자의 역할이 너무 많이 드러내지 않고 백인 팀을 앞으로 나아가는 데 중요 할 수 있다고 생각합니다.

참고 : 여기서 "회색 모자"라는 용어는 표준이 아닙니다. http://www.howtogeek.com/157460/hacker-hat-colors-explained-black-hats-white-hats-and-gray-hats/를 참조 하십시오 . 따라서 다른 용어 인 "스트라이프 모자"를 대신 사용해야합니다.

그러나 여전히 아이디어는 동일합니다. 줄무늬 모자는 친절한 검은 모자와 수비수 (흰 모자)의 작업을 중재하는 데 도움이되므로 특정 아이디어와 힌트를 흰색 모자와 신중하게 공유 할 수 있습니다.

원래 질문을 게시 한 이후이 주제에 대해 많은 연구를 수행했으며 결과를 답변으로 제공 할 수 있습니다.

우선 실험실에서 이상 탐지 알고리즘을 사용하는 SIEM 시스템을 개발합니다. 시스템 및 알고리즘에 대한 설명은 본 백서에서 확인할 수 있습니다. 대규모 네트워크에서 보안 이벤트를 복잡한 분석하기위한 시스템으로

그 외에도 Cross Validated에 대한 비슷한 질문에 대한 답변 에서 이러한 데이터를 처리하는 방법에 대한 간단한 요약을 작성했습니다.