[ 欺騙和身份濫用 ]

為什麼合法的 SaaS 平台可以傳遞惡意訊息

評估經過身份驗證的 SaaS 訊息內的請求,而不是將平台視為合法性證明。

由EmailAuth研究團隊提供 · 3 分鐘閱讀

[ 重點 ]

  • 評估經過身份驗證的 SaaS 訊息內的請求,而不是將平台視為合法性證明。
  • 保留正確的身份驗證證據,同時獨立調查帳戶、內容和業務風險。
在此頁面上

合法的服務可以傳送非法的請求。使用者可能會濫用平台的正常共享或通知功能,帳戶可能會被盜用,或者授權的發送者可能會提出未經授權的業務請求。網域身份驗證可以正確識別服務或配置的寄件者,同時使這些風險無法解決。調查應該解釋這兩個事實,而不是將每條傳遞的惡意訊息稱為身份驗證失敗。

區分服務和請求

記錄訊息中的實際寄件者網域、簽章網域、信封身分和連結。決定哪些身分屬於服務,哪些身分屬於客戶控制的網域。不要假設熟悉的標誌或可見的顯示名稱表示該訊息源自於被冒充的組織。 DKIM 將簽名域與訊息關聯起來;它不證明訊息陳述的真實性。 RFC 6376.

詢問平台實際驗證了什麼。它可能已經驗證了帳戶會話、配置的網域或通知工作流程。沒有必要證明帳戶所有者有意更改付款或共享文件是安全的。在服務所有者和業務接受者提供證據之前,請保留這些問題。

建構需求和證據矩陣

使用單獨的行進行網域身份驗證、帳戶控制、內容審核和業務審核。每行都需要一個要求、證據、信心、所有者和下一步。通過的對齊簽章可以滿足窄域認證行而不滿足其他行。 RFC 9989 描述 DMARC基於領域的範圍,而不是關於內容的一般保證。 DMARC規範.

對於財務請求,獨立驗證尤其重要。使用已知的聯絡方式,而不是訊息中新提供的電話號碼或回覆地址。聯邦調查局建議獨立檢查付款請求和帳戶詳細資訊的變更。 聯邦調查局指導.

閱讀透明工作負載範例

書面範例假設支付變更訊息具有一致的身份驗證、沒有業務批准且已知供應商聯絡人拒絕更改。因此,它的矩陣會保留身份驗證通行證,同時保留付款變更。它無法推斷帳戶是否被盜用、服務功能是否被濫用或被指控的寄件者是否參與其中。

同樣的假設模型使用每月 10,000 則訊息的說明性工作負載、1% 的評論選擇率以及每個所選訊息四分鐘的時間。計算得出 100 條評論和大約 6.67 小時的分析師時間。這些是計劃假設,而不是衡量的平台濫用率、人員配置基準或供應商價格。它們不包括調查升級、週末、誤報處理和事件協調,因此它們並不是完整的營運成本估算。

進行調查而不過度阻塞

保留訊息識別碼和特定於提供者的物件參考(如果可用),但避免不必要地傳播敏感文件內容。要求授權服務所有者調查帳戶活動、共用設定和審核日誌。任何遏制行動的範圍都應限於已驗證的威脅,並得到組織回應流程的允許。

阻止整個流行服務可能會中斷合法的工作流程,而無法解決其他地方的帳戶洩露問題。考慮是否支援更窄的寄件者、物件、URL 或帳戶操作並且是否合適。這些是決策標準,而不是未經授權執行刪除或更改他人帳戶的指示。

關閉已證明的身份事實、未經驗證的因果解釋、業務成果和回應所有者。如果服務仍然可用,請保留其驗證配置,同時解決濫用路徑。刪除DKIM以避免信任的出現會削弱有用的訊號,而不會保證內容的安全。目標是正確解釋該訊號並添加請求所需的獨立檢查。

保持四個證據行不同

對於本發明的情況,規定域認證通過;郵件管理員擁有檢查真實接收證據的權力。帳戶控制未知;授權服務擁有者必須檢查實際帳戶活動。內容安全未解決;安全性負責範圍內的內容審查。未獲得商業批准且規定的已知供應商拒絕該請求;財務保留付款保留。沒有聯繫真正的供應商,沒有調查帳戶,也沒有改變付款方式。此範例提供了決策結構,而不是識別犯罪者的證據。

源和執行邊界

RFC 9989第 4.4、5.3.5 和 5.4 節 區分認證, 結盟 和處理;通行證並不認可訊息內容。這裡的營運決策是範圍內的建議和明確的假設範例,而不是對客戶、提供者或歷史固定裝置的新測試。任何真正的改變都需要有自己的授權範圍、保留的證據和負責任的決定。

[ 外帶 ]

保留正確的身份驗證證據,同時獨立調查帳戶、內容和業務風險。

[ 按角色 ]

這對您意味著什麼

選擇您的角色以執行後續實際步驟。

IT/郵件管理員

保留準確的身份證據

惡意請求可以正確驗證。

後續步驟

  1. 捕獲評估的域。
  2. 保留服務對象引用。
  3. 避免一攬子身份驗證變更。

CISO / SecOps

調查濫用路徑

不要從品牌推斷原因。

後續步驟

  1. 經授權查看帳戶活動。
  2. 範圍遏制。
  3. 將證據與歸屬分開。

創辦人/非技術人員

實際審核工作預算

身份驗證不能取代業務控制。

後續步驟

  1. 驗證工作負載假設。
  2. 資金升級能力。
  3. 保持付款驗證的獨立性。

[ 常見問題解答 ]

常見問題

惡意郵件可以有有效的DKIM嗎?

是的。有效的簽名並不證明內容是良性的或業務授權。

服務品牌是否能證明誰要求採取行動?

否。獨立驗證實際訊息身份和請求。

是否應該在事件記錄中將通過更改為失敗?

否。保留觀察到的身份驗證結果並記錄單獨的濫用問題。

該範例是否證明帳戶被盜?

不。它發明的證據支持企業持有,而不是特定原因。

工作量數字是基準嗎?

不。它們是審查工作算術的明確說明性假設。

為什麼不立即阻止整個服務?

廣泛的封鎖可能會擾亂合法的工作;對證據和權威的範圍回應。

濫用後是否應該禁用DKIM ?

不僅僅是消除信任訊號;解決實際的濫用和帳戶控制問題。

最終的矩陣應該顯示什麼?

將身分、帳戶、內容和業務需求與證據、所有者和未解決的差距分開。

[ 來源 ]

來源

  1. RFC 6376 DKIM

    部分 §3.4 · §3.5 · §3.7 · §6.1 · §6.3

  2. RFC 9989 DMARC

    部分 §4.4 · §5.3.5 · §5.4 · §7.4 · §8

  3. FBI IC3 基於雲端的電子郵件 BEC 指南

    部分 給最終用戶的建議

[ 詞彙表 ]

詞彙表

需求矩陣
將每個所需的控制結果與證據和所有者連接起來的記錄。
服務濫用
使用合法服務執行不需要的或未經授權的活動。

企業出處

為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。

傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中,手動監督意味著延遲執行、配置漂移和不受監控的影子域。

EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject,保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準,以及人機互動審核能力。

政府 大型企業 一級金融機構

SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密

知識庫