連絡先が必要なのはWebサイトだけではない

　今回のRFCはあくまでWebサイトに向けたものです。しかし、同じ考え方はその他のエリアでも必要なはずです。例えば皆さんの会社で作った製品に対するセキュリティ問題を発見した人が、どこに連絡すればよいのか分からない事態はなるべく避けるべきでしょう。親切なホワイトハッカーがあまたいるとまでは思わないものの、例えば海外に住む善意のハッカーがあなたの製品に脆弱性を発見したとき、その連絡先が日本語ネイティブではない人でも分かるようになっている必要があるでしょう。Webサイト向けには上記RFCを適用するとして、窓口をどう設定すべきでしょうか。

　実はこれも、RFCが用意されています。「RFC 2142」（https://www.ietf.org/rfc/rfc2142.txt）では一般的なサービス、役割、機能に対するメールボックス名が定義されており、メールサーバを運用している組織は、特定の名称のメールアドレスを用意すべしとあります。例えばネットワークセキュリティであれば「security@example.com」といったメールアドレスが存在する前提で、ここに送ることでコミュニケーションが取れるように準備しておく必要があります。

　ただ、個人的にはやはり、英文を含む「セキュリティ報告窓口」を、企業のトップページから分かりやすい動線で用意しておく必要があると思っています。それがあることで、企業として製品のセキュリティをどう考えているかが分かります。同じようにsecurity.txtを用意しておけば、エンジニア視点でも「この企業は最新の仕組みをちゃんとキャッチアップしている」という印象を与えるかもしれません。

　もちろん、連絡先のメールアドレスや窓口を明らかにすることだけではなく、その宛先にセキュリティの問題が送られて来たときに、ちゃんと社内でそれを受ける仕組みが存在するかという点こそが重要です。多くのセキュリティエンジニアは善意で脆弱性を報告するでしょう。しかし、その報告がなしのつぶてとなった場合、人によっては「脆弱性が残る状態では利用者に影響があるため、広く公開する」しかないと考えます。それはゼロデイ脆弱性の公開であるだけでなく、SNSなどで注目を集めてしまうことも多く、誰も幸せにならない善意に化けてしまうでしょう。

　昨今では、自社が開発した製品のセキュリティ的な品質を保つ意味での「PSIRT」（Product Security Incident Response Team）の運用が必須ともいえるようになりました。似たような言葉である「CSIRT」（Computer Security Incident Response Team）の第一歩はやはり「連絡窓口を決め、対外的に発表する」ことです。その意味でも、最初に紹介した「security.txt」は興味深い取り組みであるとともに、画期的な仕組みだと私は思っています。

　余談ですが、そのsecurity.txtの仕様の一つに「Hiring」があるのも興味深いと思っています。おそらくそんなテキストファイルをのぞきに来る人は、それなりに腕のあるセキュリティエンジニアのはず。それを見越してしっかり仕様に入っているのは本当に面白いと思います。ぜひ、皆さんの組織でもsecurity.txtを設置し、それをきっかけにPSIRT運営までに手を出してほしいと思います。

⇒ 新着ホワイトペーパーをチェックする

著者紹介：

宮田健（みやた たけし）

元＠ITの編集者としてセキュリティ分野を担当。現在はフリーライターとして、ITやエンターテインメント情報を追いかけている。自分の生活を変える新しいデジタルガジェットを求め、趣味と仕事を公私混同しつつ日々試行錯誤中。

2019年2月1日に2冊目の本『Q＆Aで考えるセキュリティ入門「木曜日のフルット」と学ぼう！＜漫画キャラで学ぶ大人のビジネス教養シリーズ＞』（エムディエヌコーポレーション）が発売。スマートフォンやPCにある大切なデータや個人情報を、インターネット上の「悪意ある攻撃」などから守るための基本知識をQ＆Aのクイズ形式で楽しく学べる本です。

筆者より：TechFactoryでの本連載では、ITセキュリティの「あるべき論」「正論」だけでなく、モノづくりに携わる方たちに「気楽に」「楽しく」セキュリティを考えていただけるように、さまざまな話題を取り上げたいと思います。「セキュリティっていわれてもねえ……」と思わず考えてしまった皆さんに覚えていただけるようなコラムにしたいと思います。お楽しみに！