메시지가 주장하는 내용을 식별하세요.
메시지는 여러 가지 방법으로 비즈니스를 모방할 수 있습니다. 표시되는 보낸 사람 주소에 업체의 정확한 도메인을 입력하거나, 관련 없는 주소와 함께 아는 사람의 표시 이름을 사용하거나, 업체와 유사하도록 선택한 다른 도메인에서 보낼 수 있습니다. 이는 상호 교환 가능한 메커니즘이 아닙니다. 그들은 서로 다른 증거를 요구하고 서로 다른 통제 경계를 노출합니다. 세 가지 경우를 모두 호출 DMARC 실패는 잘못된 수리를 조장하고 DNS 편집이 아닌 비즈니스 확인이 필요한 사고를 숨길 수 있습니다.
RFC 9989 DMARC 범위를 RFC5322 도메인 및 정렬 인증. 도메인 이외의 엔터티에 대한 표시 이름 공격, 콘텐츠 분석 및 인증을 명시적으로 제외합니다. 수신자는 여전히 추가 보호를 적용할 수 있지만 이러한 보호를 DMARC 자체에 적용해서는 안 됩니다. 이 문서에서는 실제 메시지 검사나 명명된 발신자에 대한 주장 없이 방어 분류를 위한 분류 방법을 제공합니다.
정확한 도메인 사용에는 정확한 비교가 필요합니다
메일 애플리케이션에 표시되는 표시 텍스트가 아니라 구문 분석된 보낸 사람 주소의 실제 도메인으로 시작합니다. 요청과 관련된 비즈니스 도메인과 비교하세요. 제한된 조사 기록에 정확한 철자와 증거 출처를 보존합니다. 도메인이 동일한 경우 다음 질문은 신뢰할 수 있는 수신자 증거가 정렬된 인증, 실패, 정책 부재 또는 불확실한 결과를 표시하는지 여부입니다. 정확한 도메인 모양만으로는 어떤 일이 발생했는지 알 수 없습니다.
정확한 도메인을 사용하는 무단 발신자는 실패할 수 있습니다 조정, 그러나 손상된 인증 계정이나 서비스는 정렬된 메일을 생성할 수 있습니다. 따라서 동일한 가시적 도메인이 매우 다른 사건에서 발생할 수 있습니다. DMARC 패스는 메시지가 사람에 의해 승인되었음을 증명하지 않으며, 실패 자체가 악의적인 의도를 증명하지 않습니다. 전달, 구성 실수 및 불완전한 증거로 인해 해석이 복잡해질 수 있습니다. 원인을 밝히기 전에 관찰된 좁은 사실을 기술하십시오.
표시 이름은 별도의 ID 표면입니다.
RFC 5322, 섹션 3.4에서는 사서함의 선택적 표시 이름을 해당 주소와 구별합니다. 표시 이름은 DMARC 에서 평가하는 도메인이 아니더라도 독자에게 사람이나 역할을 식별할 수 있습니다. 예를 들어 주소가 관련 없는 예시 도메인에 속해 있는 가상 메시지에 'Accounts Team'이 표시될 수 있습니다. 친숙한 라벨은 조직 소유권의 증거가 아닙니다.
작은 화면이나 축소된 보기에서는 첫눈에 모든 ID 필드가 표시되지 않을 수 있습니다. 방어 조치는 수신 애플리케이션의 신뢰할 수 있는 인터페이스를 사용하여 전체 주소를 검사한 다음 비즈니스 요청을 독립적으로 평가하는 것입니다. 보편적인 UI 규칙을 만들거나 모든 클라이언트가 불일치를 강조한다고 약속하지 마세요. 라벨과 주소 사이의 표준 구별은 안정적입니다. 표시 및 보호 경고는 클라이언트와 수신자에 따라 다릅니다.
유사 도메인이 성공적으로 인증될 수 있음
다른 도메인은 철자, 구두점 또는 문자 선택으로 인해 신뢰할 수 있는 도메인과 시각적으로 유사할 수 있습니다. 운영자가 전송 설정을 합법적으로 제어하는 경우 해당 도메인의 메일은 통과할 수 있습니다. SPF, DKIM 해당 도메인에 대한 DMARC . 인증이 반드시 오작동하는 것은 아닙니다. 의도한 조직에 대한 수신자의 인식이 실패했거나 다른 계층에서 조작되었습니다.
실제 도메인을 의심스러운 메시지 외부에서 얻은 신뢰할 수 있는 비즈니스 기록과 비교하십시오. 단지 소유권을 확립하기 위해 제공된 웹사이트를 방문하거나 의심스러운 주소에 응답하지 마십시오. 긴 이름에 익숙한 브랜드 단어가 포함되어 있는 것만으로는 충분하지 않습니다. 국제화 이름 해석을 신중하게 유지하고 표시된 형식과 기본 형식이 다른 경우 적격 분석을 구하십시오. 이 초안은 완전한 유니코드 또는 공개 접미사 분류 알고리즘을 제공하지 않습니다.
신뢰할 수 있는 인증 증거 사용
안 Authentication-Results 필드는 수신자의 신뢰 경계 내에서만 유용합니다. RFC 8601 소비자가 신뢰할 수 있는 인증 어설션과 메시지에 포함된 임의 필드를 구별해야 하는 이유를 설명합니다. 전달된 메시지나 스크린샷에서 전달되었다는 줄을 복사해도 관련 수신자가 이를 생성했다는 의미는 아닙니다. 어떤 수신자가 메시지를 평가했는지, 조사자가 결과를 어떻게 얻었는지 기록합니다.
표시되는 보낸 사람 도메인을 유지하고, 봉투 보낸 사람 도메인, DKIM 서명 도메인 및 회신 ID는 별개입니다. 이들의 차이점은 타당한 설명이 있을 수 있으며 사기 발견으로 자동 축소되어서는 안 됩니다. DMARC 의 경우 모든 SPF 또는 DKIM 패스를 충분하게 처리하는 대신 정렬된 인증 경로를 식별하세요. 비즈니스 요청의 경우 요청된 작업과 해당 작업을 수행하는 사람의 권한을 검토하세요.
신원 비교 워크시트
신뢰할 수 있는 비즈니스 도메인, 표시되는 표시 레이블, 구문 분석된 보낸 사람 주소, 회신 주소(있는 경우), 인증된 도메인, 수신자 결과, 증거 출처 및 제안된 분류가 포함된 행을 준비합니다. 아직 알려지지 않은 항목과 요청을 확인할 수 있는 독립 채널에 대한 열을 추가하세요. 두 도메인이 동일한지 다른지 여부를 유지하면서 모든 공유 버전에서 개인 식별자를 최소화합니다. 모든 값을 하나의 자리 표시자로 변경하면 워크시트에 표시하려는 관계가 파괴됩니다.
정확한 도메인 사용, 표시 이름 모방, 다른 도메인 유사성의 세 가지 임시 범주를 사용합니다. 조합 및 미해결 카테고리를 허용합니다. 메시지에는 오해의 소지가 있는 표시 이름과 유사 도메인. 또한 워크시트에서는 정렬된 메일이 실제 조직에서 오는 것으로 나타날 경우 승인된 계정 손상을 가설로 허용해야 합니다. 분류는 의도나 책임에 대한 최종 결정이 아니라 조사 경로를 지정하는 방법입니다.
세 가지 메시지를 통한 허구적 비교
가상의 재무팀이 Northbridge 예시와 관련된 세 가지 특이한 요청을 받았다고 상상해 보세요. 첫 번째는 Northbridge의 정확한 도메인을 가지고 있지만 신뢰할 수 있는 수신자 증거는 정렬된 패스가 없음을 나타냅니다. 두 번째는 자체 도메인을 인증하는 관련 없는 주소와 함께 재무 책임자의 표시 이름을 사용합니다. 세 번째는 비슷해 보이지만 다른 도메인을 사용하고 해당 도메인에 대해서도 인증합니다. 이는 이 작업 중에 수집된 메시지가 아니라 관찰한 내용입니다.
첫 번째 경우는 인증 및 전송 경로 조사로 이어집니다. 두 번째는 표시 이름 및 비즈니스 권한 확인으로 이어집니다. 세 번째는 도메인 비교 및 가장 처리로 이어집니다. 친숙한 이름이 나타난다는 이유만으로 지불을 보증하는 것은 없으며 Northbridge의 발신인에 관련 없는 발신자를 추가하여 "수정"해서는 안 됩니다. SPF 레코드. 네 번째 메시지가 Northbridge의 실제 도메인을 사용하여 정렬을 통과하면 계정 또는 서비스 손상이 여전히 가능하며 자체 증거가 필요합니다.
메시지 이상의 요청을 확인하세요.
그만큼 IC3 클라우드 이메일 BEC 권고2020년에 게시된 에서는 의심스러운 비즈니스 요청에 대해 알려진 연락 방법을 통해 확인할 것을 권장합니다. 해당 연령은 명시적입니다. 현재 사건이나 특정 수신자의 현재 인터페이스에 대한 주장이 아닌 일반적인 제어를 지원합니다. 이미 독립적으로 기록된 번호나 작업 흐름을 사용하고 단순히 누군가가 이메일을 보냈는지 묻는 것이 아니라 요청된 특정 변경 사항을 확인하세요.
신원 증거, 제어 경계 및 독립적인 비즈니스 검증을 포함하여 필수 수정된 남용 시나리오는 아직 충족되지 않았습니다. 이 원고의 허구적 비교는 이를 만족시키지 않습니다. 어떤 계정도 쿼리되지 않았고, 의심스러운 도메인도 방문되지 않았으며, 어떤 당사자에게도 연락되지 않았습니다. 출시 전에 승인된 실제 증거를 보관하고, 자격을 갖춘 검토자가 분류를 검증하도록 하고, 소스 적용 가능성 및 생산 경로를 확인하고, 접근성 검토를 완료하고, 소유자 승인을 얻습니다. 결과는 어떤 ID가 주장되었고 통제가 실제로 무엇을 확립했는지에 대한 방어 가능한 설명이어야 합니다.