天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

セキュリティ対策 今知っておくべき脆弱性とは!?に参加してきた

findy.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

ここ最近仮想通貨の流出や、マルウェアによるサイバー攻撃といった、大規模なセキュリティインシデントが目立っています。また、ニュースで大きく取り上げられることはなくとも、日本国内では毎日のように、不正アクセスやウィルス感染等による情報漏洩やサービス停止などのトラブルが発生しております。

本イベントでは、ご登壇者のお二人に、エンジニアとして今知っておくべき脆弱性やその対策について、技術的な知見をお話しいただく予定です。

会の様子

開発者目線の脆弱性診断入門

最初に松本さんから講演がありました。

アイスブレイク

OWASPは、元々Open Web Application Security Projectの略称だったものの、2023年2月からは活動の実態に合わせて、Open Worldwide Application Security Projectに変更があったということでした。
また、ZAPはOWASPからSSPにプロジェクトが移籍したことで、OWASP ZAPではなくZAPになったということです。

サイバー攻撃の現状

サイバー攻撃の現状として、

  • フィッシング被害が爆増している
  • インターネットバンキングにおける不正送金の被害は令和5年度に過去最多を記録し、個人が多く被害にあっている
  • クレジットカードの不正利用も過去最多を記録している。
脆弱性診断の目的と手法

開発者目線で脆弱性診断に関して話がありました。

脆弱性診断は、脆弱性を特定し、発見された脆弱性のリスクを評価し、脆弱性を修正するための具体的な対策を提案することが目的だということです。

また、診断の分類として、診断対象のアプリケーションに対して外部から診断を行うことで攻撃者の視点に立って脆弱性を探索するのがブラックボックス診断であり、診断対象のソースコードやドキュメントをもとに内部構造を理解したうえで脆弱性を検出するのがホワイトボックス診断だという話がありました。

脆弱性診断に必要なスキル

プロトコルや名前解決、文字コードや暗号、認証、URL、Webぶブラウザ、HTML/CSS、JS、XML/JSONに関しては最低限知識として持っていてほしいという話がありました。

脆弱性診断で使用するツール

診断ツールに関して、Burp SuiteとZed Attack Proxyの話がありました。
これらは単純操作に関してはそこまで難しくないものの、マクロなどを作ろうとすると学習コストがそれなりに高くなってくるということです。

脆弱性診断フロー

フローは大きく分けると

  1. クローリングなどを活用して診断対象を選定
  2. 診断作業を準備&実施
  3. 診断結果をレビューなどで精査し、再現手順や結果をまとめて報告

の3つに分かれるという話がありました。

脆弱性診断の学習方法

今日話したことがすべてではないものの、

  • OWASPやWeb Security Academyなどをもとにしたオンライン学習
  • 認定Webアプリケーション脆弱性診断士の公式トレーニン
  • Webアプリケーション脆弱性診断ハンズオンコース
  • JNSAやOWASP Japanといったコミュニティ

が学習方法として考えられるということでした。

脆弱性対応をこの先生きのこるには

続いて鈴木さんから話がありました。

脆弱性の定義

JISの定義である、「一つ以上の脅威によって付け込まれる可能性のある、資産または管理策の弱点」の紹介や脅威と組み合わさったときにリスクが顕在化するという説明がまずありました。

昨今の脆弱性

昨今は、VPN機器を経由したランサムウェア攻撃や、ESXi経由で不正侵入を行ったりする事例の紹介がありました。

脆弱性対応が大変な理由

高い品質の一覧表を作るコストが高かったり、脆弱性のChainが大変だったりするのが、脆弱性対応を大変にしている理由だと考えているという話がありました。

コンテキスト合わせ

具体的な事例に入る前に、どういう環境での話なのかの紹介がありました。

  • 創業5年目
  • フルクラウド
  • 明日のキャッシュが怖い
  • セキュリティスペシャリストはいない
  • 採用は全社の3%位を目指す
守るべき情報資産の可視化

守るべき情報資産を可視化するために、システムをグラフとして捉えているという話がありました。

グラフでいうとすべてのノードに脆弱性は存在するということです。(設定不備やフィッシング、GitHub Actionsの脆弱性サプライチェーンリスクなど)

どういう対策をしているのか?

クラシックな脆弱性対応としては、

  • エンドポイントにおいてEDRなどを通して脆弱性情報を集め、通知を飛ばす
  • Dependabotや年次脆弱性診断の実施
  • 統一的なCSPMは採用せず(コストに見合わない)、ソリューションに存在するCSPMを活用するような状態

を行っているということです。

判断軸

どの対応を優先的にするのかという判断軸は、脆弱性種別や資産状況、脅威種別、業界動向、管理元...多数あるため、しっかり判断軸を選んでいくのが重要だと考えているそうです。

アプローチに関しては、大まかに分ければ、リスクベースとコンプラベースの2通りが考えられ、To BeとAs Is両方からせ攻めていくことが重要だということでした。

鈴木さんの会社では、脆弱性を表現するDBを用意し、前述したノードや経路をもとに守るべき資産を判断しているということです。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

グレーボックス診断は、ブラックボックス診断とホワイトボックス診断を両方行う診断ということか?支払う予算に応じてどのボックスによる診断を判断するのか?

質問の通り。診断ツールを回してSQLインジェクションが出たら、部分的にソースコードをもらい本当に脆弱性があるかを確認したりする。ソースコードを他社に公開するのは難しい会社が多いので、原則はブラックボックス診断になることが多い。

ホワイトボックス診断はどれくらい自動化できるのか?

過検知だらけになってしまうが、これは仕方ない。対応が大変すぎて諦めるというパターンもよくある。

クラウドサービスをはじめとしてリスク範囲が広大な中、どこまでの影響を考慮すればいいか?
  • 経営陣にヒアリングし、ユーザー側の権利などは現場でカバーする
  • 他社事例を見る

会全体を通した感想

脆弱性対応のエントリーポイントとしての話を聞いて、その後に実際に具体的な現場での対策の話があったので、構成として非常にきれいで聞きやすかったです。

トリアージのあたりはもう少しQ&Aなどでも聞けるとありがたかったですが、グラフを活用したアプローチなどは取り組みやすいですし、ユーザーや経営陣とのヒアリングの中でも共通言語的な形で使うことができそうなものだったので、非常に良いなあと思いました。