ダイニーの urahiroshi です。
ダイニーはプロダクト・組織ともに拡大中です。プロダクトの利用が広がれば広がるほどセキュリティの重要度も増してきますが、ダイニーにはセキュリティの専門家がおらず、体系立ててセキュリティ対策を実施できていなかったという課題がありました。
この記事では、ダイニーのセキュリティ改善の取り組みを紹介していくことで、ダイニーのようにセキュリティの専門家がいないスタートアップでもセキュリティを改善していく動きができるように後押ししたいと考えています。
ステップ0. 方針の策定
スタートアップの日々の開発業務において、プロダクトの改善やインシデント対策などについてはやりたいことが無数にあります。しかし、そういった目に見えて優先度が高いものを実施しているだけだと永遠にセキュリティ対策ができません。
そこで、まずセキュリティのリスクや優先度を見える化する動きを作り、継続的にセキュリティ対策を実施できないかと考えました。そこで思い当たったのがセキュリティアセスメントという手法でした。
セキュリティアセスメントとは、ダイニーが保持しているデータなどに対するセキュリティリスクのインパクトや発生可能性などを計測し、リスクをスコア付けしたうえで対応の優先順位付けを行うためのものです。しかし、社内にはこれまでセキュリティアセスメントを実施したメンバーもおらず、そもそもうまく進められるのかが疑問でした。
そんな中、自分が参加していた Cyber-sec+ Slack チャンネル内で 情報資産リスクアセスメントの実務 というセキュリティアセスメントの実務について記載された書籍が紹介されていました。さっそく書籍を読むと、この本が 中小企業の情報セキュリティガイドライン というIPAのドキュメントを参照しており、ガイドラインの内容も非常にわかりやすく記載されていました。IPAのガイドラインは誰でも自由に閲覧できるということもあり、こちらを教科書としてセキュリティアセスメントを実施していく方針としました。
以降に記載するステップは、中小企業の情報セキュリティガイドライン第3.1版の p54 - p63 に記載のある「詳細リスク分析の実施方法」をベースに、どのようにダイニーの中でセキュリティアセスメントを実行していったかについて記載します。なお、本記事に記載しているプロセスはガイドラインを参照しながらもダイニー内で独自に内容を解釈・変更して実施しているものです。原則としてのプロセスはガイドラインを参照いただき、こちらの文章は一つの実践例として参考にしていただければと思っています。
ステップ1. 情報資産の洗い出し
まず、ダイニーが保持している情報資産の洗い出しからスタートします。情報資産は「機密性」「完全性」「可用性」の3つの観点で洗い出すことができます。
- 機密性: 漏洩すると問題になる情報 (個人情報や秘匿性の高い情報)
- 完全性: 改ざんされると問題になる情報 (webサービス上で実行されるJavaScriptコードなど)
- 可用性: アクセスできなくなると問題になるもの (webサービスを構成するインフラなど)
可用性として挙げられた情報資産はサービスを構成するインフラそのものが対象となるため、当初は “情報資産” という単語のイメージとギャップを感じましたが、可用性の観点で DDoS のようなセキュリティリスクをカバーすることができることに気づき、なるほどと感じられました。
情報資産は「重要度」の定義によりスコア付けすることができます。最大の重要度スコアは3であり、法律違反や金銭的な損害を生じうるようなもので、会社が傾くらいのリスクになるものと解釈しました (意訳しているので、詳細はぜひIPAのドキュメントを参照してください！)
本来の流れであればまずあらゆる情報資産をリストアップして重要度のスコアを付けて… となるのですが、極力スモールスタートで運用のサイクルを回していくようにしたかったため、ダイニーではまず重要度スコアが3となりうるものに限ってリストアップしていきました。
リストアップした情報資産をお見せすることはできないのですが、ダイニーでは「機密性」「完全性」「可用性」それぞれの観点で重要度の高い情報資産を以下のようにグルーピングすることができました。
- 機密性
- 個人情報
- 営業秘密となる情報 (店舗の売上情報など)
- 機密データにアクセスできる情報 (パスワードなど)
- インフラのアクセス情報 (GCPのサービスアカウントキーなど)
- 連携サービスのアクセス情報 (APIキーなど)
- 完全性
- 通信の傍受・改ざんに用いられるもの (ネットワークの接続情報など)
- 書き換えによって金銭的な損害があるもの (口座情報など)
- コンテンツの改ざんに用いられるもの (アプリケーションのバイナリなど)
- 可用性
- 止まると大規模な金銭的影響を生じるもの (ダイニーの場合、飲食店が営業できなくなるくらいインパクトがあるもの)
ステップ2. 脅威のリストアップ
次に、情報資産ごとにどういう脅威 (セキュリティリスク) があるかをリストアップしていきます。
脅威をリストアップし始めたところで、「あれ、DBに格納されている情報資産のリスクって、ほとんど同じでは？」と思い、情報資産を格納先ごとにグループ化し、格納先ごとに脅威をリストアップする手法にしました。例えば以下のような流れです。
- 情報資産として「店舗の売上情報」がある
- 「店舗の売上情報」はデータベース (AlloyDB) に格納されている
- データベースから情報が参照される脅威をリストアップする
- 認可ロジックのバグにより他社のデータが閲覧できる
- データベースにアクセスできるGoogleアカウントが不正にログインされる
- サービスとデータベース間の通信が不正に傍受される
- …
脅威のリストアップは最もセキュリティの知識・観点が求められるポイントで、漏れている観点がないか複数人で確認したり、ChatGPTに問い合わせてみるのも良いでしょう。セキュリティの専門家に相談できるならそれがベストです。
もちろん、格納先によってはより粒度が細かく権限管理できるものもあり、その場合は情報資産ごとに脅威を考慮する必要も生じます。ダイニーでは、上記のように格納先ベースで脅威を書きつつ、必要に応じて情報資産ごとの脅威を追加していきました。
ステップ3. リスクの算出
脅威をリストアップできれば、次は個々の脅威のリスク値を算出します。
リスク値の算出は計算式があり、 重要度 * 被害発生可能性 となります。 被害発生可能性 は 脅威の起こりやすさ と 脆弱性 によって数値化できます。
中小企業の情報セキュリティ対策ガイドライン p60より
そのため、個々の脅威に対して 脅威の起こりやすさ と 脆弱性 をスコア付けする必要がありますが、スコア付けの基準は以下のようになっており、客観的にスコア付けするのはかなり難しいと感じました。
| 脅威の起こりやすさ | |
|---|---|
| 3 | 通常の状況で脅威が発生する (いつ発生してもおかしくない) |
| 2 | 特定の状況で脅威が発生する (年に数回程度) |
| 1 | 通常の状況で脅威が発生することはない |
| 脆弱性 (つけ込みやすさ) | |
|---|---|
| 3 | 対策を実施していない (ほぼ無防備) |
| 2 | 部分的に対策を実施している |
| 1 | 必要な対策をすべて実施している |
なるべく評価者によってブレが生じることを防ぐため、脅威をグルーピングし、脅威のグループごとに 脅威の起こりやすさ と 脆弱性 の定義をより詳細に定められるように努めました。以下の表がその例となります。まだ一定の主観性は残っていますが、これを叩き台として改善の議論が起これば、その議論自体が属人性の排除につながるものと期待しています。
| 脅威の種別 | 起こりやすさ | 脆弱性 |
|---|---|---|
| 権限管理 | 3: 共有アカウント等で多数のメンバーがアクセス可能なリソースである 2: Googleアカウントと連携していないID, パスワードなど情報によりアクセス可能なリソースである 1: Googleアカウントのみでアクセス可能なリソース、もしくはアカウント権限だけではアクセスが容易ではないリソースである |
3: 特に対策を行っておらず、不必要なユーザーにも権限が付与されたままになっている 2: 定期的に権限が見直されている 1: 異動時・退職時などにアカウント情報を更新するワークフローを持っている |
| サプライチェーン | 3: 不正なパッケージの混入により容易に発生するリスクであり、更新頻度も高い 2: 更新頻度が低いパッケージである、もしくは不正なパッケージの混入により発生するリスクが低い |
3: 特に対策を行っていない 2: 不正なパッケージの確認は定期的に行っているが、体系立てた更新はできていない 1: 不正なパッケージの検知および対策を体系立てて実施できている |
| secret管理 | 3: 有効期限のない、もしくは１週間より長い有効期限のsecretであり、正社員の開発メンバー以外も含め多数がアクセス可能なsecretである 2: 有効期限のない、もしくは1週間より長い有効期限のsecretであり、正社員の開発メンバーのみアクセス可能なsecretである 1: 1週間以内の有効期限のあるsecretである |
3: 特に対策を行っておらず、不必要なユーザーでも閲覧可能なsecretとなっている 2: 定期的にsecretへのアクセス権限が見直されている 1: 異動時・退職時などにsecretへのアクセス権限が見直されているとともに、secretが定期的にローテーションされている |
| ブラウザ拡張機能 | 3: エンジニア以外のメンバーも含む多数のメンバーがアクセスできるWebサイト上で、不正な拡張機能のインストールにより容易に発生するリスクである 2: 不正な拡張機能のインストールにより発生するリスクがある |
3: 特に対策を行っていない 2: セキュリティ教育等により、拡張機能インストール時のリスクについて周知されている 1: 拡張機能をインストールする前に安全性をチェックするためのプロセスが組み込まれている |
| ヒューマンエラー | 3: 過去に起こったことがあるリスクである / 高頻度で複雑なマニュアル操作が必要とされる箇所である 2: 高頻度もしくは複雑なマニュアル操作が必要とされる箇所である |
3: 特に対策を行っておらず、個人個人の作業に委ねられている 2: 作業内容のレビューやミスがないか確認するプロセスが組み込まれている 1: 作業が自動化されている |
| 不正ログイン | 3: ログイン画面が不特定多数にアクセス可能である 2: 一般公開されていないURLによりログインが実行できる |
3: 特に対策を行っておらず、総当たり攻撃などによってログインが可能である 2: 一定のパスワード長を求める・一定回数のパスワード誤入力を検知する・CAPTCHAを入れているなど、総当たり攻撃に対する対策を実施している 1: 二要素認証などにより、IP/パスワードのみでログインできないようになっている |
| 端末管理 | 3: 不特定多数に利用される端末上のリスクである / 端末に不正なソフトウェアがインストールされることで容易に発生するリスクである 2: 端末に不正なソフトウェアがインストールされることで発生する可能性がある |
3: 特に対策を行っていない 2: 端末(PC, モバイル含む) にインストールするソフトウェアのリスク周知やポリシーの策定が行われている 1: MDMなど端末を管理するためのセキュリティツールが導入・運用されている |
| アプリケーション脆弱性 | 3: エンドユーザーに露出しているHTTPエンドポイントへのリクエストのみで攻撃可能なリスクである 2: XSSなど、アプリケーション固有の条件を満たした場合に攻撃可能なリスクである |
3: 特に対策を行っていない 2: 定期的にペネトレーションテストを行っている or 原理上脆弱性が発生しにくいフレームワークを使っている 1: 原理上脆弱性が発生しにくいフレームワークを使っているとともに、高頻度でペネトレーションテストを行っている or 原理上脆弱性が発生しないアーキテクチャとなっている |
| DoS | 3: 一般ユーザーに露出しているHTTPエンドポイントへの単体のリクエストのみで攻撃可能なリスクがある 2: 一般ユーザーに露出していないHTTPエンドポイントへの単体のリクエストのみで攻撃可能なリスクがある or 一般ユーザーに露出しているHTTPエンドポイントへの高頻度のリクエストで攻撃可能なリスクがある 1: 上記以外 (DDoSのリスクがある) |
3: 特に対策を行っていない 2: 運用マニュアルによって特定のIPアドレス、User-Agentなどのリクエストを除外できる 1: 2に加え、CloudArmorなどによりDDoS対策を即座に実施できる状態となている |
| 外部サービス障害 | 3: SLAが設定されていないサービスである / 低SLA (99.9%より低い) のサービスである 2: 中程度のSLA (99.9%以上, 99.99%未満) のサービスである 1: 高SLA (99.99%以上) のサービスである |
3: 特に対策を行っていない 2: 外部サービス障害を検知・対応するためのワークフローがある 1: 外部サービス障害が発生しても縮退運用できる体制になっている |
ステップ4. 対策の実施と運用
ステップ3まで実行できれば、脅威とそのリスク値がすべて可視化された状態になっており、リスク値に基づいて優先順位をつけて対策を実施することができます。
ダイニーでは開発タスクをチケットとして管理しているため、個々の脅威についてチケットを作成しました。次にリスク値に基づいて対策を優先付けし、期ごとの目標 (OKR) と紐づけて計画的に対策を実施する動きを作ることができました。具体的には「リスク値が xxx 以上の脅威を xxx % 減らす」のように目標を数値化して実施していきました。
また、日々の開発業務の中でどんどん新しい情報資産が作られていくため、継続的に新しい情報資産を認知し、脅威を識別するためのプロセスも必要です。ダイニーでは、プロダクトの開発チームがある一方で、Platform Team というプロダクト全体にまたがって品質や開発生産性を向上するための取り組みを行っているチームがあるのですが、
- 情報資産の追加: プロダクト開発チームが責務を持つ
- 情報資産全体の運用、対策の管理: Platform Team が責務を持つ
といったように責務分担を行う形で対応しました。
最後に
より本格的にセキュリティアセスメントを実施している企業と比べるとまだまだ未熟なプロセスかもしれませんが、継続的にプロセスを実施・改善していくための第一歩を踏み出すことが最も大事だと考えています。
ダイニーではセキュリティに関心があり、このような取り組みをさらに発展させていけるエンジニアを募集しています。情報セキュリティの専門家でなくても、セキュリティに興味があり、一緒にプロセスを改善していける方をお待ちしています。ぜひカジュアルにお話しましょう！
Discussion