NIKKEI TECHNOLOGY AND CAREER

日経電子版がRFC 9116(security.txt)に対応した話

Hack The Nikkei アドベントカレンダー2022の14日目はセキュリティチームがお届けします。セキュリティエンジニアの藤田です。 普段はクラウドセキュリティやウェブセキュリティに関するチーム横断的な企画や、プラス・セキュリティ人材に関する施策を実践しています。

本日は、2022年4月に公開された技術仕様RFC 9116 - A File Format to Aid in Security Vulnerability Disclosure(以下、RFC9116)に日経電子版が対応した話をご紹介します。

こちらの記事では日経電子版がRFC9116に対応したきっかけや、実際に公開するにあたって考慮したことを取り上げています。 まだ実際に対応された事例が少ないと感じましたので、新たに対応を検討される方の参考になれば幸いです。

対象読者

  • RFC9116(security.txt)を初めて知る人

RFC9116とは

善意のハッカーや他の誰かが偶然にも利用サービスにセキュリティ上の問題を見つけた際、連絡したいけどどこに連絡すればいいかわからない。困りますよね。 RFC9116はそういった脆弱性の発見者に対し、ウェブサイト管理者がセキュリティ担当者の窓口を開示するための手段として提案されました。

具体的には、所定のURLに連絡先等を記述したテキストファイルを配置することで実現しています。 善意のハッカーは、脆弱性を発見した際に下記のURLにアクセスすることで連絡先を把握できるようになります。

技術仕様は下記のURLで公開されています。

なぜRFC 9116に対応したのか?

この項ではRFC9116への対応を検討した背景を紹介します。

日本の取り組み

日本ではIPA(情報処理推進機構)やJPCERT/CC(JPCERTコーディネーションセンター)が早期警戒パートナーシップという枠組みを提供しており、発見された脆弱性情報を集約して各事業者や個人に連絡する仕組みを取ってきました。

情報セキュリティ早期警戒パートナーシップガイドライン - IPA

IPAのウェブサイトでガイドラインが公開されており、善意のハッカーらがネットワーク製品やウェブサイトの脆弱性を発見した際に通報窓口に連絡することで適切にディスパッチしてくれる取り組みです。

パートナーシップガイドライン図2 (本ブログ投稿時点でIPAが2022年度版を修正中のため、2019年版を参照しています。)

しかし、サイバーセキュリティの情勢が変化するにつれて少しずつその役割も変化し、現在は脆弱性報告者に以下のように案内しています。

IPAへ届出するか、発見者から直接製品開発者やウェブサイト運営者へ届出するかは、より迅速に脆弱性情報を通知できる、もしくは修正対応が望める方法を選択して欲しい。

つまり、企業側に脆弱性報告の窓口が用意されている場合は、その窓口に直接連絡した方が迅速な対応が望めるのではないかということです。企業はRFC9116に対応することで脆弱性発見者から直接連絡を受けても適切に対処する準備があることを示すことにも繋がります。

届け出してほしい脆弱性発見者へのお願い

IPA「脆弱性届出制度に関する説明会資料」より抜粋

海外の取り組み

海外では適切な通報窓口が見つけられず行き場を失った脆弱性情報を通報するためのウェブサイトが運営されています。

Open Bug Bounty

こちらのサイトには第三者が発見した脆弱性情報がドメインごとに投稿されており、一定期間経過すると投稿された攻撃コードが公開される場合があります。攻撃コードが公開されると悪意ある第三者によって攻撃されてしまうおそれがあります。ウェブサイト管理者は脆弱性が開示される前に脆弱性を認知し、適切に対応しましょうという話です。

日本のドメインで検索してみると意外にも多くの日本企業や官公庁等が出てきます。すでに対応済みのものが多いですが、海外のボランティアハッカーが偶然にも発見した日本のウェブサイトの脆弱性を適切な報告窓口がわからずこちらに投稿したものと思われます。(海外の方は早期警戒パートナーシップの仕組みを知らないのかもしれません。)

ウェブサイトがRFC9116に対応していれば、OpenBugBountyに投稿されることなく直接通報してくれるかもしれません。また、セキュリティリサーチャーがOpenBugBountyの投稿を見つけた際に連絡してきてくれるかもしれません。本当は自分たちで積極的にチェックした方がいいんですけどね。

RFC9116に対応するまでの段取り

ここまで述べてきたように早期警戒パートナーシップやOpenBugBountyといった素晴らしい取り組みがありますが、会社側から脆弱性報告フローを明示しないと、会社側で全く認知していないプラットフォーム上でいつの間にか脆弱性報告がされるといった状況となり、結果として脆弱なまま放置してしまうおそれがあります。 ウェブサイトの管理者は自分たちの意思でRFC9116に対応し、窓口を示すことでセキュリティ強化の糸口をつかむことができます。

では、実際に公開しようと思った場合にどのような段取りが必要になるか見ていきましょう。

企画段階

弊社の場合、RFC9116が公開されて間もないころ、社内Slackでは数名のメンバーから「日経電子版に置きたい」「やりたい」といったコメントが出はじめており、対応する機運はあったものの具体的にどうすすめるか考える必要がありました。

弊社は各エンジニアの裁量で案件を企画できる文化があるため、セキュリティ案件はセキュリティチームで開始したいという思いもあり事前にテックリードに相談したうえで対応を開始しました。

具体的な決め事について、RFC 9116の仕様を見てみましょう。 主に以下のような項目について検討を進めていきます。

  • Contact: 連絡先
  • Expires: 期限
  • Hiring: 採用ページ案内
  • Policy: ポリシー
  • Acknowledgements: 謝辞

ここから事例集めや社内の体制を考慮しつつ内容を決めていきます。 ちなみに、事例集めの際は以下のような条件でGoogle検索しました。

inurl:.well-known/security.txt

Contact

連絡の受け方は、連絡用のメールアドレス(mailto:)を示すか専用URLを設ける(https://)かの選択となります。 実際の連絡頻度もわからないため、弊社ではまずは専用のメールアドレスを用意して受信することにしました。

連絡はセキュリティチームで一次的に受け取り、適切な開発チームに割り当てる運用を想定しています。 また、会社としての広報窓口を介さずに連絡を受けることになるため、念の為広報チームやSIRTチームにも案件を説明し連携しました。

Expires

公開されているsecurity.txtの陳腐化を避けるために有効期限を示すことができます。 一年以内の期限が推奨されており、定期的に内容の見直しをしたいため毎年末に更新することにしました。 他のウェブサイトの事例では半年から1年程度で更新されていることが多いようです。

Hiring

善意のハッカー向けにセキュリティ関連職種用の採用ページを案内することができます。 弊社ではセキュリティエンジニアの募集要項を用意しているため、そちらのURLを案内しています。 この投稿の最後にもリンクを張っていますので、ご興味のある方はぜひご確認ください。

Policy

脆弱性開示に関するポリシーを示すことができます。 まずは連絡先情報の共有を優先し、Policyは事例が集まった上で掲載を検討することとしたため、はじめは使用しないことにしました。 今後、ポリシーが公開できるよう社内での検討を進める予定です。

Acknowledgements

過去に報告をしてくれた方への謝辞を案内することができます。 こちらもPolicyと同様、はじめは使用しないことにしました。

参考:security.txt作成フォーム

今後、security.txtの公開を検討される際、下記のウェブサイトでフォームに沿ってテキストファイルを用意する事ができます。 https://securitytxt.org/

公開するまで

security.txtへの掲載内容が確定したタイミングでWebチームや配信チームと連携し、リリースサイクルに乗っかって無事デプロイされました。

私個人としては2022年4月に入社して以来初めて自分発の案件でのリリースでしたので、とても嬉しかったですしチームの枠を超えて喜びを分かち合いました。

リリース案内

おわりに

本投稿を通じて、RFC9116を初めて知った方や導入を迷っていた方が始めの一歩を踏み出すきっかけになれば幸いです。

ところで、日経電子版でも2022年11月11日付でsecurity.txtの件が掲載されていますのでもしよろしければご一読ください。

https://www.nikkei.com/article/DGXZQOUC0590E0V00C22A9000000/

仲間募集中

テクノロジーメディアを目指す日本経済新聞社ではデジタルサービスにおけるセキュリティを重視しており、最新のセキュリティ技術に興味のあるエンジニアを随時募集しております。一緒にメディアの未来を作る仕事に興味のある方は、ぜひお気軽にご連絡ください。

日経のデジタルサービスを支える<セキュリティエンジニア>の募集ページはこちら。

https://herp.careers/v1/nikkei/vylwWfvk8ir-

明日は並木さんによる「Streamlit と Cloud Run でデータ可視化ダッシュボードを爆速デプロイする」です。 引き続きアドベントカレンダーをお楽しみください!

藤田尚宏
SECURITY ENGINEER藤田尚宏

Entry

各種エントリーはこちらから

キャリア採用
Entry
新卒採用
Entry
短期インターン
Entry
カジュアル面談
Entry