[ BIMI & 브랜드 ]

인증된 로고 남용: 신원 및 평판 관리에 대한 교훈

로고만을 비난하거나 신뢰하지 않고 ID, 계정 제어, 전송 승인 및 비즈니스 확인을 통해 악의적인 요청을 조사합니다.

EmailAuth 연구팀 제공 · 8분 읽기

[ 핵심사항 ]

  • 다른 제어 경계가 실패하는 동안 인증이 작동할 수 있습니다.
  • 평판과 발표는 사건 평결이 아닙니다.
  • 격리 및 사업 검증에는 별도의 책임 있는 소유자가 필요합니다.
이 페이지에서

실패한 경계 조사

인증된 도메인과 관련된 악성 메시지는 증거 조사 없이 '인증 실패'로 요약되어서는 안 됩니다. 계정, 승인된 전송 서비스 또는 비즈니스 프로세스가 오용되는 동안 메시지가 도메인 검사를 통과했을 수 있습니다. 표시된 로고는 메시지가 전송된 방법이나 수신자가 이를 신뢰한 이유에 대한 완전한 설명이 아니라 프레젠테이션 관찰을 추가합니다. 신원, 계정 제어, 전송 승인, 콘텐츠 및 비즈니스 승인을 분리하는 것부터 시작하세요.

이 문서에서는 방어 조사 및 통제 검토 워크플로를 제안합니다. 검증된 내용을 설명하지 않습니다. BIMI 사건을 남용하거나 실제 조직을 비난합니다. 2026년 11월 8일에 보관된 소스에는 프로토콜 및 수신자 문서와 2020년 4월 6일자로 명시적으로 날짜가 지정된 IC3의 클라우드 이메일 권고가 포함됩니다. 가상의 예는 운영 증명이 아니며 자격 증명, 테넌트 로그, 인증서 기록 또는 영향을 받는 메시지가 수집되지 않았습니다.

신원 증거를 정확하게 정의하십시오.

DMARC 눈에 보이는 시작 도메인과 전달 정렬을 연결합니다. SPF 또는 DKIM 입증. 해당 도메인의 모든 메시지가 승인된 비즈니스 지침으로 바뀌지는 않습니다. DKIM 서명 책임을 식별하고 해당 콘텐츠를 보호합니다. 인간 저자에게 요청 권한이 있다는 것은 보편적인 진술이 아닙니다. 어떤 통제가 효과가 있었는지 결론을 내리기 전에 실제 신원과 검증된 결과를 기록하십시오. RFC 9989 RFC 6376

또한 신뢰할 수 있는 결과 소스를 식별합니다. Authentication-Results 신뢰 경계가 있으며 그 외부에 삽입된 어설션은 오해의 소지가 있을 수 있습니다. 패스 레이블의 스크린샷에 의존하기보다는 수신된 메시지와 검증자 컨텍스트를 보존하세요. 신뢰할 수 있는 결과가 없으면 인증을 확인되지 않음으로 표시하세요. 친숙한 로고나 DNS 에 언급된 인증서의 존재만으로 이를 유추하지 마십시오. RFC 8601

프레젠테이션과 평판을 구별하라

Google의 BIMI 문서와 Yahoo 의 자격 페이지에는 다양한 인증서 및 표시 조건이 설명되어 있습니다. Yahoo 평판과 참여가 명시적으로 포함되어 있는 반면 Google은 인증서 지원 경로와 VMC 연결 체크 표시를 문서화합니다. 따라서 로고 관찰은 보편적인 평판 점수 또는 보낸 사람의 모든 메시지가 안전하다는 보장으로 일반화될 수 없습니다. 관찰과 함께 수신기와 클라이언트 표면을 기록합니다. 구글 BIMI Yahoo BIMI

또한 평판 시스템은 사고 평결로 취급되어서는 안 됩니다. 로고가 없다는 것은 좋은 설명일 수 있으며, 로고가 있다고 해서 새로 손상된 계정을 배제할 수는 없습니다. 하나의 인터페이스가 예기치 않게 작동했기 때문에 브랜드를 비난하지 마십시오. 조사에는 책임을 할당하거나 결과적 주장을 전달하기 전에 메시지, 계정 및 비즈니스 증거가 필요합니다.

승인된 채널의 손상을 고려하세요.

IC3의 2020년 권고에서는 합법적인 클라우드 이메일 계정을 침해하고 서신을 검사하고 결제를 리디렉션하는 범죄자에 대해 설명합니다. 또한 해당 사건의 가능한 부분으로 사서함 규칙 및 외부 전달을 설명합니다. 이는 승인된 증거로 인해 손상이 의심되는 경우 계정 및 사서함 활동을 조사하는 데 도움이 됩니다. 이 프로젝트의 특정 메시지가 이러한 기술을 사용했다는 사실은 입증되지 않았습니다. IC3 클라우드 이메일 권고

보유된 기록에 대해 테스트할 수 있는 가설을 구축합니다. 일반 서비스를 통해 메시지를 보냈나요? 승인된 애플리케이션이나 사용자 계정이 생성했습니까? 예상치 못한 계정, 전달 또는 구성 변경이 있었나요? 실제로 어떤 신분이 통과됐는지 조정? 뒷받침되지 않는 가능성을 가설로 표시하십시오. 이론을 증명하기 위해 비밀을 수집하거나 다른 조직의 환경에 접근하려고 시도하지 마십시오.

적절한 소유자를 통해 보존 및 억제

제안된 응답에는 보안 소유자, 메일 관리자, 비즈니스 승인자 및 증거 관리자의 이름이 명시되어야 합니다. 컨텍스트를 파괴할 수 있는 변경을 하기 전에 메시지와 관련 인증 로그를 보존하십시오. 실제 사건으로 인해 계정 정지, 자격 증명 순환 또는 권한 변경이 필요한 경우 이는 조직의 대응 프로세스에 따른 별도의 결과적 조치이지 이 문서에서 실행하거나 승인한 단계가 아닙니다.

IC3 권고에서는 다단계 인증, 로깅, 의심스러운 활동 경고 및 피싱 방지 보호 기능을 권장합니다. 권고 사항은 오래되었고 해당 플랫폼 예제는 일반적이므로 이전 구성 지침을 그대로 복사하는 대신 각 권장 사항을 조직의 현재 지원되는 컨트롤에 매핑하십시오. 통제 검토에서는 무엇이 활성화되어 있는지, 적용 범위가 어떻게 확인되는지, 예외를 소유한 사람이 누구인지 물어봐야 합니다. IC3 방어 권장 사항

손상된 채널 외부에서 비즈니스 확인을 유지하세요.

메시지에서 지불 또는 중대한 변경을 요청하는 경우 독립적으로 알려진 연락처와 확립된 승인 프로세스를 통해 요청을 확인하십시오. IC3는 결제 변경 및 거래에 대해 직접 확인하거나 알려진 번호를 확인할 것을 권장합니다. 잠재적으로 손상되었을 가능성이 있는 동일한 스레드에 응답하는 것은 단지 응답이 동일한 인증된 도메인에서 도착한다는 이유만으로 독립적인 확인이 아닙니다. IC3 검증 지침

확인된 사실과 확인자의 권한을 기록합니다. 보안은 기술적 타협을 확립할 수 있으며, 재무는 자체 프로세스를 통해 거래를 보류하거나 취소하는 방법을 결정합니다. 반대로, 사업주는 기술적인 원인이 알려지기 전에도 승인되지 않은 요청을 거부할 수 있습니다. 두 팀 모두 기존 보호 조치를 적용하기 위해 로고나 인증서 진단을 기다리면 안 됩니다.

원본 신원 및 제어 검토 워크시트

제안된 워크시트를 사용하여 관찰, 가설 및 조치를 분리하세요. 완전한 사건 보고서가 아니며 실제 피해자 정보가 포함되어 있지 않습니다.

  • 관찰된 메시지: 원본 보존, 수신 시간, 가시적 신원 및 요청된 작업.
  • 신뢰할 수 있는 인증: 검증자, SPF 또는 DKIM ID, 정렬 및 서명된 콘텐츠 범위.
  • 디스플레이 관찰: 수신자, 클라이언트, 로고 또는 배지 및 이미지 소스에 대한 불확실성.
  • 승인된 채널: 설정된 경우 전송을 담당하는 계정, 애플리케이션 또는 서비스입니다.
  • 가설: 손상, 오용, 구성 문제 또는 기타 원인(증거 필요)
  • 비즈니스 검증: 독립적인 연락처, 권한 및 정확한 요청이 확인되거나 거부됩니다.
  • 통제 대응: 책임 있는 소유자, 승인된 격리, 증거 보존 및 복구 기준.
  • 의사소통: 입증된 사실, 수정, 청중의 승인 및 해결되지 않은 결론.

유용한 발견은 다른 제어 경계가 조사 중인 동안 인증이 설계된 대로 작동했다는 것을 의미할 수 있습니다. 이는 BIMI 손상되었다고 선언하거나 보낸 사람이 안전하다고 선언하는 것보다 더 정확합니다. 증거가 더 강력한 결론을 뒷받침할 때까지 귀인에 대한 불확실성을 유지합니다. 실제 조직에 대한 평판 주장에는 특별한 주의와 명시적인 검토가 필요합니다.

가상의 시나리오: 친숙한 계정이 무단 변경을 보냅니다.

가상의 Alder Harbor는 일반적으로 구매를 처리하는 공급업체 계정으로부터 송장 변경 요청을 받습니다. 제안된 조사는 친숙하게 표시된 로고와 가상으로 정렬된 인증 결과를 기록하지만 둘 다 관찰된 사실이 아닌 시나리오 가정으로 취급합니다. 사업주는 기존 공급업체 기록을 통해 독립적으로 공급업체에 연락하고 상상한 실습에서 변경 사항이 승인되지 않았다는 사실을 알게 됩니다.

그런 다음 보안 팀에 승인된 전송 채널을 식별하고 적절한 소유자를 통해 관련 증거를 보존하도록 요청합니다. 인증서가 부정하게 발급되었거나 특정 공급자가 실패했다고 가정하지 않습니다. 이 작업에는 Alder Harbor 메시지, 계정 또는 확인 전화가 없습니다. 시나리오는 수정된 사건이 ​​아니라 교육적 통제 활동입니다.

유용한 인증을 삭제하지 않고 복구

실제 사고 발생 후 메일 인증 구성과 함께 계정 액세스, 애플리케이션 승인, 모니터링 및 비즈니스 확인을 검토하세요. 인증을 제거해도 계정 제어 오류는 복구되지 않으며 다른 가장 경로에 대한 유용한 보호 기능이 제거될 수 있습니다. 증거가 해당 구성요소와 관련되어 있는 경우 인증서 및 자산 검토는 여전히 적절할 수 있지만 로고의 시각적 중요성보다는 실제 사실을 따라야 합니다.

카탈로그에는 신원 증거, 제어 경계 및 독립적인 비즈니스 검증을 통해 수정된 남용 시나리오가 필요합니다. 이러한 운영 아티팩트가 없습니다. 원본 증거, 인간 SME, 소스 적용 가능성, 생산 경로, 시각적 접근성 및 소유자 공개는 계속 열려 있습니다. 이 원고는 사건 발견, 통제 구현 또는 안전 보장이 아닌 계층화된 조사 방법을 제공합니다.

[ 테이크아웃 ]

신뢰할 수 있는 증거를 보존하고, 실제 승인된 채널을 조사하고, 유용한 인증을 폐기하지 않고 실패한 경계를 복구합니다.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

실제 전송 경로 식별

통과 도메인 결과는 누가 계정을 관리했는지 설명하지 않습니다.

다음 단계

  1. 서명된 ID와 검증자 컨텍스트를 유지합니다.
  2. 승인된 서비스 증거를 검토합니다.
  3. 구성 가설을 사실과 분리하여 유지하십시오.

CISO/SecOps

계층화된 응답 조정

사고 원인 분석에는 시각적 지표 이상의 것이 필요합니다.

다음 단계

  1. 승인된 로그와 메시지를 보존합니다.
  2. 격리 및 복구 소유자를 할당합니다.
  3. 날짜가 적힌 지침을 사용하여 현재 계정 통제를 주의 깊게 검토하십시오.

창립자 / 비기술자

비즈니스 및 평판 결정 보호

확인되지 않은 주장은 사건을 더욱 악화시킬 수 있습니다.

다음 단계

  1. 확인을 기다리는 동안 결과적인 변경 사항을 보류합니다.
  2. 확립된 공급업체 연락처를 사용하십시오.
  3. 뒷받침되는 사실에 대해서만 외부 사건 진술을 승인하십시오.

[ 자주 묻는 질문 ]

자주 묻는 질문

악의적인 요청에 대해 인증이 통과될 수 있나요?

도메인 인증 자체로는 비즈니스 명령이 승인되었음을 입증하지 않습니다.

RFC 9989: DMARC

DKIM 보편적으로 신뢰할 수 있는 인간 작성자를 식별합니까?

아니요. 서명 책임을 식별하고 정의된 범위 내에서 해당 콘텐츠를 보호합니다.

RFC 6376: DKIM

로고는 계정이 손상되지 않았음을 증명합니까?

그러한 보장은 없습니다. IC3은 합법적으로 손상된 계정과 관련된 남용을 설명합니다.

IC3: 클라우드 기반 이메일 서비스 BEC 권고, 2020년 4월 6일

Yahoo 평판 자격은 모든 메시지가 안전하다는 것을 증명합니까?

아니요. 표시 조건은 기업 승인이나 사건 판결 메커니즘이 아닙니다.

Yahoo 발신자 허브: BIMI

어떤 증거를 보존해야 합니까?

원본 메시지, 신뢰할 수 있는 결과, 관련 인증 로그, 표시 컨텍스트 및 독립적인 비즈니스 확인입니다.

이전 권고 설정을 맹목적으로 복사해야 합니까?

아니요. 현재 지원되는 통제 및 승인된 프로세스에 대한 지침과 지도 권장사항을 날짜별로 지정하세요.

계정 남용 후 도메인 인증을 제거해야 합니까?

그것만으로는 계정 통제 실패를 복구할 수 없습니다. 실제 영향을 받는 경계를 검토하고 유용한 인증 보호를 유지하세요.

이 기사는 확인된 BIMI 남용 사건을 보고합니까?

아니요. 해당 시나리오는 허구이며 필요한 수정된 운영 증거는 여전히 공개되어 있습니다.

[ 출처 ]

출처

  1. Google: BIMI 설정

    섹션 시작하기 전에 · 1단계: 로고의 SVG 파일 만들기 · 2단계: VMC 또는 CMC 및 관련 파일 가져오기

  2. Yahoo 발신자 허브: BIMI

    섹션 다음과 같은 경우 로고를 표시합니다. · VMC 요구 사항

  3. RFC 9989: DMARC

    섹션 식별자 정렬 · A.6 pct 태그 제거

  4. RFC 6376: DKIM

    섹션 §3.5 DKIM-Signature 헤더 필드

  5. RFC 8601: Authentication-Results

    섹션 §1.2 신뢰 경계 · §7. 보안 고려 사항

  6. IC3: 클라우드 기반 이메일 서비스 BEC 권고, 2020년 4월 6일

    섹션 정의 · 위협 · 최종 사용자를 위한 권장 사항 · IT 관리자를 위한 권장 사항 · 피해자인 경우 해야 할 일

[ 어휘 ]

어휘

서명 책임
메시지 작성자에 대한 보편적 신뢰와는 다른 DKIM 서명과 관련된 도메인 책임입니다.

RFC 6376: DKIM

승인된 채널
실제 사용에는 조사가 필요할 수 있지만 전송이 허용된 계정, 애플리케이션 또는 서비스입니다.
격리 소유자
사고 제한을 조정하고 증거를 보존할 권한이 있는 책임자.
귀속 한도
이용 가능한 증거를 넘어서는 경계는 원인이나 책임 지정을 지원하지 않습니다.

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료