はじめに
RFCを読んでいると、どのRFCにも "Security Considerations" という章があることに気付きます。これは、RFC文書の体裁を規定するRFC[1]でこの章が必須とされているからです。
この "Security Considerations" の記載に関するベストプラクティスがRFC 3552です。RFC著者のセキュリティ設計方針を知るために、本記事ではRFC 3552の第5章を中心に "Security Considerations" をどう書くべきかを紹介します。
第5章はとても短く、その紹介だけだとすぐに終わってしまいますので、最後にほかの章も簡単に紹介します。
RFC 3552 - 5. Writing Security Considerations Sections
設計するプロトコルがあらゆる攻撃に耐性を持つ必要はないが、「デューデリジェンス」実行のために既知または予見可能なすべてのリスクと脅威を記述する努力が必要とされるという導入から、RFCの著者が記載しなければならない(MUST)ことが以下の箇条書き[2]にまとめられています。
- スコープ外とする攻撃およびその理由
- スコープ内とする攻撃および
- 設計するプロトコルがその攻撃でどんな影響を受けるのか
- 設計するプロトコルがその攻撃から何を守れるのか
そこでSIer的な運用視点を加味すると、以下のように整理できます。
以上……で終わってもよいのですが、5章ではさらに具体的な指針が続きます。
- 以下の攻撃形態を考慮しなければならない(MUST)（いずれも第3章で議論されています）
- 盗聴
- リプレイ攻撃
- メッセージ挿入・削除・改ざん
- Man-In-The-Middle
- 潜在的なDoS攻撃が識別されなければならない(MUST)
- プロトコルが暗号による保護を組み込んでいる場合は、データ中の保護が適用される部分と、どのような保護なのか（完全性だけなのか、機密性や端末認証など）を明確にすべき
- 秘密にしなければならないデータ（鍵の材料(keying material)、乱数シードなど）を明確にラベル付けすべき
- 認証を含む場合、認証方法のセキュリティを仕様化しなければならない(MUST)
- 下位層のプロトコルが提供するセキュリティ機能に依存する場合、どのような保護機能が提供されることを前提としているか定義されなければならない(MUST)
- ファイアウォールに守られた環境ではなく、複数の管理者にまたがるインターネットの脅威環境を想定しなければならない(MUST)
- 脅威緩和策が実施された後の残存リスクが明確にされるべき
- プロトコルや技術の誤った使用による潜在的なリスクについての議論があるべき
そのほかの主な章
RFC 3552 - 2. The Goals of Security
通信プロトコルのセキュリティのゴールを、通信セキュリティとシステムセキュリティに分類して説明しています。
RFC 3552 - 3. The Internet Threat Model
インターネット環境における脅威モデルの考え方と、代表的な脅威を示しています。基本的な考え方として、通信に参加するシステムは侵害されておらず、逆にシステム間の通信チャネルは攻撃者によって盗聴や改ざんされうるという前提を置いています。
RFC 3552 - 4. Common Issues
多くのプロトコルに共通する論点[3]と、それらに関するセキュリティ技術が列挙されています。
RFC 3552 - 6. Examples
RFC 2821 (SMTP)とRFC 2338 (VRRP)の Security Considerations を添削し、具体的にどう記述すべきか例示しています。SMTPはいまいちな例、VRRPはよい例として挙げられているのですが、SMTPの最新版であるRFC 5321でも指摘が取り込まれているようにはあまり見えませんでした💦
参考URL
RFC 3552の公式ソース
IPAによる日本語訳
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。