MSSP 및 MDR 제공업체를 위한 다중 테넌트 탐지 운영

멀티 테넌트 탐지 작업은 공급업체에 구애받지 않는 탐지 논리를 중앙에서 관리하고 각 테넌트에 맞게 번역 및 조정하는 것으로 서로 다른 SIEM 플랫폼을 사용하는 고객들이 일관성 있게 조정 가능하며 보고 가능한 상태를 유지하는 실천입니다.

수십 개의 테넌트를 위한 탐지를 운영하는 MSSP는 하나의 구조적 질문에 직면합니다: 각 고객이 모든 탐지 규칙의 자체 포크를 받는가, 아니면 단일로 관리되는 소스가 테넌트별로 번역 및 조정되는가? 이 대답은 운영 비용, 보장 보고서 정확성, 공유된 논리에 대한 변경 사항이 일시에 전파되는지 아니면 수동 패치 백로그에 쌓이는지를 결정합니다.

이 페이지는 그 모델의 탐지 콘텐츠 계층을 포함합니다: 중앙에서 관리되고 각 테넌트에 맞게 번역 및 조정되는 공급업체에 구애받지 않는 탐지 논리의 소스입니다. 헌터즈는 MSSPs 및 MDR 제공업체를 위한 SOC 및 SIEM 대체 플랫폼인 분석 및 운영 계층에서 운영됩니다. 콘트라포스는 마이크로소프트 보안 스택(Microsoft Sentinel 및 Defender XDR)에 맞춰 사례 관리 및 전달 워크플로우 계층에서 운영됩니다. 여기서 설명하는 탐지 콘텐츠 소스는 공급업체에 구애받지 않는 탐지 논리를 실행, 조사 및 보고 계층에 제공하는 상류에 위치합니다.

범위: SIEM 플랫폼 (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike). EDR을 배포 대상으로 하는 것은 각 플랫폼에 대한 지원이 검증될 때까지 범위에서 제외됩니다.

MSSP는 그 자체로 규제 대상이기도 합니다. 2024년 11월 7일부터 발효된 위임 시행 규정 (EU) 2024/2690호는 NIS2에 따라 관리 보안 서비스 제공업체에 대한 모니터링 및 로깅 요구 사항(부속서 섹션 3.2)을 설정합니다. MSSP 자체의 증거 의무는 테넌트의 것만이 아니라 탐지 콘텐츠가 어떻게 관리되고 보고되는지를 결정합니다.

멀티 테넌트 SOC는 어떻게 서로 다른 SIEM 플랫폼을 사용하는 고객 환경에 걸쳐 탐지 논리를 일관되게 유지할 수 있을까요?

공급업체에 구애받지 않는 형식으로 탐지 논리를 한 번 작성하세요 (Sigma). 각 테넌트의 SIEM에 맞게 번역하세요. 소스를 중앙에서 관리하세요.

공유된 기본 아티팩트

기본은 단일 탐지 논리 아티팩트입니다. 그 논리 조건은 어느 테넌트의 원시 로그 필드가 아닌 공통 된 표준화된 스키마에 대해 평가됩니다. 이는 동일한 규칙이 탐지 논리 자체를 재 작성하지 않고도 Splunk, Microsoft Sentinel, Google SecOps, Elastic 및 CrowdStrike를 아우르는 포터블한 것임을 의미합니다.

정규화는 원천 별 필드를 의미를 보존하면서 그 공유된 스키마에 매핑합니다. 정규화된 필드 auth.result에 대해 작성된 규칙은 어떤 신원 제공자가 이벤트를 생성하든 동일한 의미를 갖습니다: auth.result는 지정된 의미론적 계약에 따라 {성공, 실패, 도전}으로 해석되며, 고객의 IdP가 필드를 어떻게 부르는지에 따라 결정되지 않습니다.

테넌트 별 오버레이

각 테넌트는 오버레이를 받습니다. 오버레이는 해당 테넌트의 원시 소스 필드를 공유된 정규화된 스키마로 변환하는 필드 매핑과 그 테넌트 환경에 맞춘 튜닝 파라메터(임계 값, 시간 창, 소음 제외)를 포함합니다. 기본 및 오버레이는 별도로 버전 관리됩니다.

기초 논리의 업데이트는 필요한 필드를 매핑하는 모든 테넌트의 오버레이에 전파됩니다. 한 테넌트의 오버레이에 대한 튜닝 변경은 그 테넌트에만 영향을 미칩니다.

공유 대 테넌트별

공유되는 것: 탐지 논리 조건, 논리가 의존하는 의미론적 계약 정의, MITRE ATT&CK 기술 태그, 버전 및 변경 이력입니다.

테넌트별: 원시-정규화 필드 매핑, 런타임에서의 계약 검증 상태(테넌트의 실제 이벤트 스트림에 따라 평가 된 통과 혹은 실패, 규칙의 정적 속성이 아님), 플랫폼 타겟 번역, 그리고 튜닝 파라메터입니다.

어떻게 고객 환경 수십 개를 포크 없이 탐지 콘텐츠를 관리할 수 있을까요?

각 고객별 포크가 아니라 탐지 하나당 하나의 관리되는 아티팩트.

고객 별 포크로 규칙 파일을 유지하려면, 하나의 관리된 아티팩트가 되어야 할 것의 독립적인 사본을 유지보수해야 합니다. 논리 수정이나 새로운 회피 기술 업데이트는 수작업으로 모든 포크에다 다시 적용해야 합니다. 포크는 분산되고 단일 버전 관리 변경 이력은 사라집니다.

감사자나 고객이 해당 규칙이 언제, 왜 변경되었는지를 물으면, 그 질문은 하나의 타임라인으로 추적되어야 합니다. 동일한 수정을 반영할 수도 있고 반영하지 않을 수도 있는 여러 사본은 그 질문을 답하기 어렵게 만듭니다. 이것은 거버넌스 및 변경 관리 실패를 의미하며, 감사자가 의존하는 증거 추적을 직접적으로 약화시킵니다.

기본과 오버레이 모델은 하나의 아티팩트를 관리 상태로 유지합니다:

계층	포함 사항	범위
기본 (공유)	탐지 논리 조건, 의미론적/시간적/상관 계약 정의, MITRE ATT&CK 기술 태그, 버전 및 변경 이력	모든 테넌트
오버레이 (테넌트별)	원시-정규화 필드 매핑, 플랫폼 타겟 번역, 임계 값, 시간 창, 소음 제외	하나의 테넌트

기초 논리의 변화는 구조상 전파됩니다. 매핑과 튜닝만 현지화로 남습니다. 이것은 코드로 탐지 경험을 멀티 테넌트 운영에 적용합니다: 규칙 변경은 버전 관리, 검토, 코드 아티팩트로 추적됩니다. 배포 자동화가 업데이트 된 기본을 오버레이를 지원하는 모든 테넌트에 전달합니다.

계약 버전 관리는 기본을 지배합니다. 변경 사항은 버전 관리되어야 하며, 파괴적인 변경은 새로운 계약 ID가 필요하며 모든 테넌트가 조화로운 업그레이드 경로를 얻고 조용한 깨짐이 없도록 합니다.

SOC Prime은 SiEM 탐지에서 Prime Detect로 SIEM 볼륨을 줄이는 탐지 엔지니어링 작업을 설계하기 위해 MDRs와 협력합니다.

영업 문의

기본 규칙을 깨지 않고 고객별로 어떻게 튜닝할 수 있을까요?

오버레이에서 튜닝하세요. 기본 규칙은 고정된 상태로 유지됩니다.

오버레이는 두 부분으로 나뉘어 테넌트 특화 구성을 포함합니다.

필드 매핑. 각 테넌트의 소스 제품은 원시 로그에서 동일한 사실을 다르게 명명하기 때문에, 오버레이는 이러한 원시 필드를 공유된 정규화된 스키마로 번역합니다. 매핑은 다른 모든 테넌트가 공유하는 동일한 의미론적 계약을 독자적으로 충족해야 합니다.

이것이 중요한 이유를 보여주는 구체적인 실패가 있습니다. 한 테넌트의 오버레이가 ID 제공자의 “MFA 대기” 결과를 “도전” 대신 “실패”로 정규화된 값에 매핑합니다. 공유 MFA-우회 탐지 논리가, 도전 이벤트가 없는 성공적인 로그인을 찾으려고 할 때, 그 테넌트는 “도전” 값을 전혀 보지 못합니다. 매번 성공적인 로그인이 우회로 플래그 됩니다: 동일한 규칙이 올바른 매핑을 갖춘 다른 모든 테넌트를 위해서는 올바르지만, 그 한 테넌트를 위한 대량의 거짓 긍정입니다.

규칙은 한 번도 변경된 적이 없습니다. 실패는 전적으로 오버레이에 있으며, 오버레이 오류가 규칙 버그인 것처럼 가장하고 있습니다.

튜닝 매개 변수. 연관된 이벤트를 연결하기 위한 상관 시간 허용 오차, 인증 시퀀스를 위한 세션 타임아웃 및 유예 기간 창, 그리고 소음 제외. 허용 오차를 너무 엄격하게 설정하면 실제 상관을 놓치게 됩니다. 너무 느슨하게 설정하면 관련이 없는 이벤트를 연결하게 됩니다. 이러한 창은 테넌트의 시계 동기화 및 대기 특성을 고려하여 테넌트별로 조정되어야 합니다.

기본 규칙의 탐지 논리 조건은 정규화된 필드에 대해 평가되며 단일 테넌트에 대해서는 변경되지 않습니다. 계약 검증 상태는 런타임에 테넌트 별로 평가되어야 하며 규칙이나 소스 유형에서 추정되어서는 안 됩니다.

다양한 로그 소스를 우리가 받는 상황에서 각 고객에 MITRE ATT&CK 탐지 범위를 어떻게 보고할 수 있을까요?

해당 테넌트의 우선 기술 세트에 대해 각 테넌트에 대해 범위를 계산하세요. 절대 동일한 라이브러리 숫자로 테넌트를 가로지르지 마십시오. 전체 측정 방법은 MITRE ATT&CK 탐지 범위 측정의 동반 페이지에 설명되어 있습니다.

커버리지 템플릿:

커버리지 (테넌트) = [원격 측정 유효 AND 규칙 배치 AND 규칙 발사 증명된] 기술들 나누기 그 테넌트의 우선 기술 수.

기술이 커버된다고 계산될 때

기술은 다음이 모두 함께 이루어질 때에만 커버된다고 계산됩니다:

1. 이 테넌트에 대해 원격 측정이 유효합니다. 필요한 데이터 소스가 수집, 적극적으로 수집되고 있으며, 의미, 시간적 및 상관 계약을 통과하고 품질 SLO(공백 율, 신선도)를 충족하고 있습니다. 이러한 모든 것은 소스 유형 기본값이 아닌 실제 이벤트 스트림에 대해 이 테넌트에 대해 평가됩니다.

2. 규칙이 배포되고 기술에 매핑되었습니다. Detection-as-Code 인벤토리 사실: 어떤 규칙이 존재하고, 어떤 MITRE ATT&CK 태그를 가지고 있으며, 그 버전.

3. 규칙이 발사 증거를 가지고 있습니다. 화재율 기준 설정, 잠재 이벤트, 또는 실제 또는 에뮬레이트된 활동에 대한 경고를 생성하고 있는 규칙을 보여주는 원자 테스트 검증. 발사 기록이 없는 기술 태그는 레이블일 뿐 증거가 아닙니다.

분모는 그 테넌트의 명명되고 우선 기술 세트의 하위 집합입니다 ATT&CK 기술. 절대 전체 ATT&CK 매트릭스. 절대 공급업체의 규칙 라이브러리 크기.

보고 간격 상태

하나의 수치로 압축하지 않고 간격 상태를 구별하여 보고:

상태	의미	수정
유효한	모든 게이트 통과, 규칙 배포, 파일에 검증된 발사 증거	보고서일 기준으로 커버됨
무효한	필요한 소스가 수집되거나 수집되지 않음	소스 활성화 또는 수집 복원
저하된	소스가 수집되나 계약 또는 품질 SLO 실패	매핑, 파서, 또는 스키마 수정
콘텐츠 간격	원격 측정 유효, 기술에 매핑된 규칙 없음	콘텐츠 개발

무효함과 저하됨을 하나의 “간격” 숫자로 합치지 마십시오. 다른 실패 모드는 서로 다른 수리를 요구하며 서로 다른 고객 대화를 생성합니다.

날짜와 함께 보고하세요. 커버리지는 특정 시간의 정보입니다.

콘텐츠 재사용이 마진과 분석가 훈련 부하에 미치는 영향은 무엇인가요?

테넌트 전반의 콘텐츠 재사용은 고객별 탐지 엔지니어링 비용을 공유되고 감가 상각된 비용으로 전환합니다. 기반 탐지 논리가 한 번 작성되고 테넌트별로 번역될 때 엔지니어링 비용은 고객 서적 전체에 퍼집니다.

마진. 공유된 기본을 운영하는 모든 테넌트는 점진적인 탐지 엔지니어링 시간을 피합니다. 마진 개선은 구조적입니다. SOC Prime의 MDR 파트너 프로그램 은 연간 4K 시간의 위협 연구 및 탐지 콘텐츠 코딩 절감을 제시합니다.

훈련 부하. 하나의 Detection-as-Code 방법론. 하나의 정규화된 스키마. 하나의 계약 의미론 세트. 분석가는 이름, 구조 및 의도가 다른 고객별 규칙 라이브러리 대신 공유 모델에 대해 온보딩 됩니다. 분석가가 한 테넌트의 큐에서 다른 테넌트로 이동할 때 탐지 논리, 스키마, 계약은 이미 익숙합니다.

정직한 반대. 공유된 탐지 콘텐츠는 MSSP의 차별화를 지우지 않습니다. 차별화는 튜닝, 대응, 보고로 이동합니다. 테넌트별 오버레이, 대응 런북 및 고객 대면 보고에서 MSSP의 가치가 드러납니다. “공유 콘텐츠”를 듣고 “일용품”을 생각하는 고객은 사용자 정의 작업이 어디에 있는지를 정확히 볼 필요가 있습니다.

규제 동인. NIS2를 통한 위임 시행 규정 (EU) 2024/2690에 따라 MSSP 자체의 증거 의무는 테넌트의 것만이 아니라 MSSP 자체 모니터링 및 로깅 증거를 요구합니다. 공유 모델은 그 증거 생성 비용을 분담합니다.

이것이 통하지 않는 곳

기본 및 오버레이 모델은 기본 규칙이 모든 테넌트의 소스 제품이 충족할 수 있는 정규화된 스키마에 대해 작성되었다고 가정합니다. 모델은 다음 조건에서 깨집니다.

1. 필요한 데이터를 방출하지 않는 소스 제품. 다른 소스 제품 또는 동일한 제품의 다른 버전은 필요 데이터 요소를 전혀 방출하지 않을 수 있습니다. 오버레이는 구조적으로 없는 필드를 수정할 수 없습니다. 이것은 소스 활성화 또는 업그레이드를 통해 수정되는 무효 간격입니다.

2. 소스 가용성. 테넌트가 필요한 로그 소스를 온보딩 하지 않았거나, 수집이 중단되었습니다. 규칙, 매핑, 튜닝이 모두 올바로 되어 있어도 소스가 다시 흐를 때까지 영향받는 기술은 여전히 덮이지 않습니다.

3. 상관 허용 오차 불일치. 공유 기본 시간 허용 오차는 예외적으로 동기화 되지 않은 시계나 지연 시간을 가진 테넌트를 위해 실제 상관성을 놓칠 수 있습니다. 테넌트별 상관 창 조정은 선택 사항이 아닌 필수입니다.

4. 고유 위협 모델이나 데이터 거주 제한. 진정한 고유 위협 프로파일이 있는 테넌트는 공유 기반에 포함되지 않는 사용자 정의 탐지 논리가 필요할 수 있습니다. 조직 경계를 넘어 탐지 논리 아티팩트를 공유하지 못하게 하는 제약은 동일한 효과를 가집니다.

5. 테넌트 격리는 협상 불가. 모델은 테넌트 간의 탐지 논리(규칙 텍스트, 계약 정의)를 공유합니다. 테넌트 데이터를, 보강 캐시를, 경고 상태나 검증 결과를 테넌트 경계를 넘어 공유하지 않습니다. 한 테넌트의 보강 조회 또는 경고 큐가 다른 테넌트로 유출되는 모든 아키텍처는 설계상 우선순위 1의 사고입니다. 논리 공유와 데이터 공유는 서로 다른 주장입니다.

 

멀티 테넌트 운영 모델 체크리스트

기본 규칙 작성 및 관리

• 정규화 된, 계약으로 정의 된 스키마에 대해 공급업체에 구애받지 않는 형식(Sigma)으로 작성된 탐지 논리
• 기본 규칙이 테넌트 오버레이와 분리 되어 있습니다: 탐지 논리, 계약 정의, MITRE ATT&CK 태그 및 버전 이력이 공유된 상태로 유지됩니다
• 각 테넌트의 오버레이는 필드 매핑, 플랫폼 번역 및 튜닝 매개변수만을 포함하며, 기본과는 별개로 버전 관리됩니다
• 기본 규칙 변경은 모든 테넌트에 구조상 전파됩니다
• 변경 이력은 기본 규칙당 하나의 관리된 타임라인으로 추적되며, 테넌트별로 오버레이 변경 사항이 추적됩니다
• 계약 버전이 적용됩니다: 파괴적인 변경은 새로운 계약 ID를 가집니다

매핑 및 플랫폼 번역을 검증

• 필드 매핑은 테넌트 당 동일한 의미론적 계약을 충족하며, 각 테넌트의 실제 이벤트 스트림에 대해 런타임에 계약 검증이 실행됩니다
• 대상 SIEM(Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike)당 플랫폼 번역이 검증됩니다

테넌트당 범위 계산

• 해당 테넌트의 우선 ATT&CK 기술 세트에 대해 테넌트당 범위를 계산합니다
• 원격 측정이 유효하고 규칙이 배포되며 규칙이 발사된 증거를 가지고 있어야만 커버리지 분모 요구 사항을 충족합니다
• 간격 상태 구별: 유효, 무효(소스 누락), 저하됨(소스 존재, 검증 실패) 및 콘텐츠 간격(원격 측정 유효, 매핑된 규칙 없음)

튜닝, 격리, 및 보고

• 테넌트 별 클럭 동기화 및 지연 특성에 맞춰 상관 시간 허용 오차 검토
• 기본 규칙을 포크하지 않고 오버레이에서 조정된 튜닝
• 테넌트 격리 적용: 데이터, 보강 캐시, 경고 상태 또는 검증 결과가 테넌트 경계를 넘어 공유되지 않음
• 커버리지는 날짜와 함께, 테넌트 별로 보고됩니다, 책 전체에 대한 하나의 라이브러리 번호로 절대 표시되지 않습니다
• MSSP의 규제 증거 의무 (NIS2 시행 규정 2024/2690)는 테넌트 의무와 함께 다루어집니다
• 분석가 교육은 공유된 Detection-as-Code 방법론, 정규화된 스키마 및 계약 의미론에 맞춰 조정

영업 문의

관련 읽을거리

• 파이프라인 계층에서의 탐지를 통한 SOC Prime ROI: 검증된 절감 효과 (2026년 9월)
• MSSPs와 MDRs가 Uncoder AI를 통해 위협 탐지 효율을 극대화하는 방법 (2024년 10월)
• SOC Prime으로 MDR 탁월성을 가속화하세요 (2023년 11월)