暗号資産取引所「bitbank」を運営するビットバンクは2021年2月、セキュリティ強化を目的に「バグバウンティ(バグ報奨金)」プログラムを導入した。同社は現在も、バグバウンティプラットフォーム「Bugbounty.jp」上で自社の暗号資産取引所を対象にしたバグの調査・報告を募集している。
バグバウンティとは、企業のウェブサービスやアプリケーションなどの脆弱性の調査を外部のホワイトハッカー(ハッカー)に依頼し、脆弱性が見つかった場合、対価としてハッカーに報奨金を支払う取り組みのことを指す。あらかじめ、企業側で調査対象や脆弱性レベルに応じた報奨金額などを決めておき、技術的な裏付けがあったか、また報奨金に相当する脆弱性の報告であったかを精査したうえで、報奨金が支払われるのが一般的だ。
バグバウンティプログラム導入から1年が経つビットバンクのセキュリティチームに、同プログラム導入の苦労や開発チームとの連携にあたってのポイントなど、バグバウンティ活用の実際を聞いた。
定期的な脆弱性診断では得られない“気付き”や“発見”
バグバウンティプログラムを導入する以前、ビットバンクではセキュリティベンダーによる脆弱性診断を年に1度、実施していた。だが、そうした脆弱性診断は網羅的なチェックを実施することができる反面、ある時点でのスナップショット的なセキュリティ評価にならざるを得ないため、脆弱性の継続的な発見・改修に課題があった。
また、ユーザー向けの「お問い合わせ」ページで有志によるバグ報告も募っていたが、周知されていなかったために、セキュリティ対策としては機能していなかったという。
ビットバンクの情報セキュリティ部を統括する橋本健治氏は、「例えば、毎年1月に脆弱性チェックをしていたとしても、それは1月時点の状態に過ぎず、2月に新たな脆弱性が発見されても、その後1年間放置されてしまうリスクがある。他方で、日ごろからシステムログをチェックしていても、なかなか脆弱性に気付けるものでもない。脆弱性診断とバグバウンティをセットで行う運用ができれば、バグの見落としを少しでも減らせるのではないかと考え、バグバウンティプログラムの本格運用を開始した」と説明した。
当初は、「暗号資産取引所のバグを探す」という物珍しさからか、大量にバグの指摘が届き、報告をさばくのが大変だったそうだ。運営から1年が経つ中で、サービスの致命的な脆弱性は発見されず、現状、バグの報告件数も月に1件程度だという。
だが、中にはセキュリティヘッダの付け忘れや、パスワード変更時のセッション更新ができていないなど、従来は気付けなかった「セキュリティの穴」も発見できたという。
橋本氏は、「バグの種類によっては、プログラムの改修などで対応するケースもあれば、いったん受容しているケースもある。もう一歩踏み込んでセキュリティを考えないといけないな、と思える発見や気付きも得られたので、セキュリティエンジニアとして学ぶことは多い」と振り返った。
スキル・言語が異なるハッカーの視点に立つ
企業がバグバウンティを運用するうえでは、ハッカーから報告されたバグの報告内容を正確に把握し、どの程度の問題なのかを判断する必要がある。そのため、セキュリティの専門性が高い人材が一定数いないと運用するのが難しい。ビットバンクも人材を確保ができたことで、本格的に運用をスタートできたという。現在は橋本氏を含めた3名が、同社のバグバウンティの運用に携わっている。
運用メンバーの1人、情報セキュリティ部 セキュリティチームの畑上英穀氏は、バグバウンティ運用で苦労していることにハンドリングを挙げる。ハンドリングとは、ハッカーからの報告内容を読み解き、重要度別に仕分けることだ。サービスに大きな影響が出るバグなら開発チームに連携し、すぐに対処するよう働きかける。
畑上氏は、「ハッカーによってスキルレベルはまちまちで、報告内容も英語で書かれていることが多い。さまざまな指摘がある中で、『要領を得ないから後回しにしよう』『うちは対策ができているから問題ないはずだ』という受け止め方をすると、バグ改修につながる重大なヒントを取りこぼしかねない。何を伝えてくれようとしているのか、それぞれのハッカーの視点に立って読み解いている」と明かした。
ハッカーからの報告の中には、セキュリティツールでスキャンをかけた結果をコピー&ペーストして送ってくるだけの場合もあるという。
また、言語の壁もある。日本語での報告は3割ぐらいで、多くのバグ報告は英語で書かれている。英語での報告の中にはネイティブスピーカーでないハッカーからのものもあり、一読して何を伝えようとしているのかわからないものもあるそうだ。
開発チームと連携、「緊急性」や「タイミング」を明確に
セキュリティ部門の報告を基に、バグの修正やシステム改修を実際に行うのは開発エンジニアだ。そのため、わかりやすい報告や提案ができていれば、「こういうインパクトがあるのか」という開発チームの気付きや、「そんなに急がなくていいなら、根本的な改修でアプリの構成から変えよう」と開発計画のブラッシュアップにもつながる。
情報セキュリティ部 セキュリティチームの太田健介氏は、開発チームに連携する際に、自社のサービスへの影響度合いを意識してセキュリティ改修の提案を行っている。
「ハッカーからのバグ報告には、『●●な操作をしたら、こんな結果になるから危ないです』といった大雑把な内容のものあり、サービスやシステム上のリスクに結び付けづらい。そうした報告を開発チームに丸投げしたら疑問が生まれるし、余計な作業が発生しかねない。そのため、バグの緊急性や対処のタイミングなどを明確化している」と太田氏。
畑上氏もセキュリティチームと開発チームの連携を重視する。機械的にセキュリティチェックの内容を伝えるだけだと、開発とセキュリティの間で不和が生まれかねないからだ。
「セキュリティ対策では、他部署も巻き込める体制の整備が重要だと考える。開発とセキュリティがお互いの声を聞こうとしなければ、最悪の場合、『セキュリティがまた何か言っている』と話を聞いてもらえなかったり、開発現場で気付いたセキュリティの穴が報告されなかったりすることもある。また、サービス拡充や利益が優先されるフェーズでは、セキュリティ対策の優先順位は低くなりがちだが、経営陣がセキュリティの重要さに理解があるとセキュリティの報告や提案がしやすい」(畑上氏)
プライベートバグバウンティやOSINTなど、新たなセキュリティ対策に着手
ビットバンクでは、今後、ステージング環境の脆弱性チェックを実施する「プライベートバグバウンティ」にも取り組む予定だという。橋本氏は、「厳選した一部のハッカーに脆弱性チェック専用の口座を開いて、ログイン後のさまざまなページについても調査してもらう」と構想する。
最新のセキュリティ動向のキャッチアップも重要になる。2021年は年末近くになって、「Log4Shell」が注目された。ビットバンクのシステムではJavaを使用していなかったため影響はなかったそうだ。だが、導入したパッケージソフトで「Apache Log4j」が利用されている可能性もあるため、橋本氏は今後の課題として、「ライブラリとアプリケーションの依存性を加味したセキュリティ対策」を挙げた。
加えて、一般的に公開されている情報から、自社に役立つ情報を読み解き、セキュリティ対策などに活用するOSINT(Open Source Intelligence)の活用も検討していくという。
「攻撃プログラムの計画をより早期に検知したり、知らないところで自社の情報が漏えいしていないか検知したりと、広義でのセキュリティ対策に活用できるのではないかと考える」(橋本氏)