セキュリティにこれから取り組む方にとっては、セキュリティは「難しそう」、「何から手をつけるべきか分からない」、「どのぐらい費用がかかるか見えない」など、不安なことが多いと思います。 本記事では、これからセキュリティ対策を始める担当者の方に向けて、セキュリティを始めるための5つのポイントをご紹介します。

ポイント1 目的とゴールを明確化する

セキュリティを始めるにあたり、最初に取り組みたいのが「目的とゴールの明確化」です。セキュリティを行う際には、何かしらのツールや外部サービスを利用することになりますが、数ある選択肢の中から適切なソリューションを選定するためには、判断基準となる目的とゴールを明確にしておくことが必要です。何に対しての品質を守っていきたいのかを整理しましょう。

各工程で利用できるソリューション

開発において、ほとんどの場合「要件定義→設計→実装→テスト→リリース→運用」の順に進んでいきますが、工程ごとに利用すべきソリューションは異なります。

image1

最初の工程である「要件定義→設計」に対しては、<支援コンサル>が有効です。
どれほど優秀なプログラマーが完璧に実装したとしても、要件定義や設計段階で脆弱性が生まれてしまうことは少なくありません。プロによる支援コンサルを受けてから設計工程へ進むと安心です。

次に、「実装→テスト→リリース→運用」の工程については、<Webアプリケーション検査ツール>が有効です。
「実装」段階では、ソースごとに不備がないか、ガイドラインに沿ったコーディングがされているかを確認する<SAST>ツール。アプリが少し動くようになった「テスト」段階では、テストとセキュリティ検査を同時に行える<IAST>ツール。 「リリース→運用」についてはアプリケーションの利用者と同じ環境に、攻撃者と同じ視点でセキュリティテストを実施できる<DAST>ツールを利用します。

さらにリリース後は、Webアプリケーションだけではなく、ネットワーク等のプラットフォーム検査も必要になるため、外部の<セキュリティ診断>を利用するという選択肢もあります。

このように、段階ごとに検査対象や検査手法、コスト、導入条件などが異なります。

現在の状況とゴールイメージの決め方

では、目的とゴールはどのように決めればよいのでしょうか?

まずは、社内体制や使用するツールの変化についてイメージしてみましょう。
例えば、今は「他業務とセキュリティ兼任の担当者が、フリーツールで対応できる範囲だけ診断している」状態なら、将来的に目指すのは「同じ体制のまま、外部の診断サービスを併用する」なのか、「数カ月かけて専任チームを組成し、商用ツールですべての診断を内製する」なのか…といった風に、どの程度の期間を経て、どのように変化させるのかを検討します。

「商用ツールを使って全自動化し、人が全く関わらない状態を目指したい」といった高い理想を掲げても、絵に描いた餅になってしまっては意味がありません。「本当に実現できるのか?」、「どのくらいのコストがかかるのか?」といった点を踏まえて、現実的なゴールを設定する必要があります。

image2

当社にご相談をいただくケースで多いのは「今は2~3割しか診断できていないが、網羅性を上げてセキュリティ品質を高めたい」や、「外部診断を利用しているが、内製化してコストダウンとスピードアップを実現したい」というご相談です。

しかし、セキュリティ品質、コスト、スピードはトレードオフの関係にあるため、すべてを完璧に行うのは実現難易度が非常に高くなります。「本当に実現したいことはどれか?」、「どこまでのリスクなら許容できるか?」、「どれくらい下がれば成功と言えるか?」など、現実的な着地点を最初に検討する必要があります。自分たちだけでは適切な判断が難しい場合には、必要に応じてコンサル支援サービス等を活用しましょう。

ポイント2 ツール本質の理解

目的にあわせて適切なツールが選択できたとしても、ツール導入後に「想定していたより自動化できない点が多く工数がかかる」、「マニュアルを見てもツールの設定方法が分からない」、「ツールが出した検査結果の見方が分からない」というギャップが発生して、せっかく導入したツールがうまく使えないケースもあります。

そうならないためには、ツールを決める時にPoCを行い、確認すべき観点を明確にしておきます。難しそうに聞こえるかもしれませんが、確認ポイントは最低限で構いません。診断すべき箇所、ツールの検査手法、ツールの動き、導入予定のツールで対応できないことなどが分かれば、ツールを導入するだけでは実現できない点や残るリスクが明らかになります。あらかじめ、そのリスクを許容するのか、外注診断で対処するのか…といった対応方針を決めておくことが重要です。

また、ツールを使いこなすためには、技術トレーニングやサポートの有無についても確認しておきましょう。

余裕があれば、主要な脆弱性に関する最低限の理解や、HTML、SQL構文 JavaScriptについての基本的な文法理解があると、さらにツールの本質を理解することにつながります。

ツールは使いこなせば非常に便利ですが、あくまで道具であり、万能ではありません。「全自動で検査してくれる」、「全ての脆弱性を見つけてくれる」、「ツールの結果は絶対に正しい」と決めつけず、利用する側が知識やスキルを身に付けることで、より正しく活用できるようになります。

ポイント3 自社システムの棚卸

ツール導入後、いよいよ検査…という段階になっても、自社のアプリケーションについて把握できていないと、検査すべきアプリの対象や優先度が分からず、スムーズに検査に入れないことがあります。
アプリの開発計画やリリース頻度、重要情報が含まれているアプリがどれか?といった点については、事前に理解・整理しておきましょう。

事前に確認したいポイント

  • 静的/動的サイトの整理ができているか
  • 個人情報等を取り扱っているアプリは認識しているか
  • どの機能が新規作成/改修されたか共有できているか
  • サイトの仕様書や機能一覧などは作成できているか
  • 検査用の検証環境は準備できているか
  • 検査に必要な充分なサンプルデータが準備可能か
  • システムパッチやアップデートは適切にできているか

さらに成功している企業では、上記に加えて次のような点もあらかじめ準備できていました。可能な範囲でこちらについても対応できると良いかもしれません。

✔︎ 動的サイトの機能一覧を用意する

外部から送信されるパラメータが利用される動的サイトは、脆弱性が埋め込まれやすい傾向にあります。
個人情報閲覧機能や決済機能など重要な機能に関しては、検査漏れ防止のため、機能一覧を作成しておきましょう。

✔︎ 検査時間や作業工数に大きく影響する要素を確認する

検査にかかる時間は様々な条件により異なります。検査をスケジュール通りに進められるよう、検査時間や作業工数に影響する要素となる、ネットワーク環境やパラメータ数、画面数や画面遷移などについてもあらかじめ確認しておきましょう。

例えば、検査時にはアクセスが集中的に発生するため、検証環境の稼働が高まります。サーバスペックが弱く、レスポンスが返ってこない状態が発生してしまうと、検査時間が長引いてしまいます。

また、サイト内の画面数や遷移、1画面あたりに含まれているパラメータ数なども、検査時間に大きく影響します。アプリを構成している画面数が10画面なのか100画面なのか、1リクエストの中に含まれるパラメータが5個なのか50個なのか、特定の画面にアクセスするために経由する画面が何ページあるのか…といった構成でも所要検査時間は異なります。

✔︎ 関係部門との関係性を構築する

セキュリティについては、情報セキュリティ部門とシステム管理部門や開発部門など各部署との協力・連携が必要不可欠ですが、部門ごとの熱量が違うと協力が得にくいケースもあります。
セキュリティは会社全体のミッションであることや、会社の目的と目指すゴールを早めにシェアして、全社一丸となって取り組めるような関係を築いておきましょう。

ポイント4 適切な運用設計

理想通りに検査が進むとは限りません。検査における優先順位や範囲について運用ルールを決めておくと、「検査が予定通り終わらずリリースが遅延してしまった」、「検査調整ができず、未検査のままリリースすることになった」、「無理なスケジュールで検査担当者の残業負荷が高くなってしまった」といった事態を回避できます。

image3

運用ルール① 検査対象アプリケーションの情報を整理する

検査対象アプリケーションの画面一覧やシステム情報については、開発者やシステム管理者が管理しています。これらの情報が確実に提供されるよう運用フローやルールを設定しましょう。

運用ルール② 検査箇所の優先順を付ける

「全画面を検査する」と決めることは理想的ですが、検査漏れ画面が多くなってしまうと、結果的に検査時間が増大してしまうため、アプリケーションに含まれる機能や情報を元に優先順位を付けて検査を行います。 

運用ルール③予定通り進まない場合の対応

もし予定通り検査が進まなかった場合、「検査期間を延長する」か、あるいは「夜間帯や休日に検査を行えるか」などの対応を事前に確認しておきましょう。

運用ルール④検査に必要なデータ

ログイン機能や決済機能がある場合は、検査時に利用可能なユーザや、入力しても良いサンプルデータをあらかじめ用意します。こういった準備が漏れていたことでスケジュール遅延になるケースは少なくありません。

運用ルール⑤脆弱性の改修、再検査

検査の結果、見つかったのが数件程度の脆弱性であれば全て改修できますが、もし数十~数百件見つかった場合には、どこまで改修するのか判断をしなければなりません。脆弱性が発見された時の対応方針についても事前に決めておきましょう。
このような運用ルールを設けても、予定通りに運用できない事象が発生することはあり得ます。予定通りに運用できないときには、発生源を確認したうえで改善に向けた対応方針を検討するなどPDCAサイクルをしっかり回しながら運用を行いましょう。

ポイント5 リスクコントロール

運用がうまく回っていても、担当者個人の知識やスキルに依存していると、人事異動や退職を機に失敗に繋がってしまうことがあります。
後任の方へ情報の引継ぎがされなかったり、学習に時間がかかったり、開発チームや関係部門とのコミュニケーションがうまくいかなかったり…といったことが続くと、ツール導入時に設定したそもそもの目的やゴールが忘れ去られ、「もっと簡単でシンプルに運用できるように」という観点からコストやツールの分かりやすさが重要視されるようになってしまいます。

担当者が変更になっても本来の目的とゴールが達成できるよう、「複数人で担当する」、「内部マニュアルや手順書の作成を行う」、「引き継ぐ際は後任の方へ導入目的や運用情報も共有する」などし、個人に依存しすぎる運用は避けましょう。困った際には、メーカーなどのサポートや技術系セミナーなども活用できます。

社内での対応が難しい場合には、無料相談会も

これら5つのポイントについて、最初は難易度が高く感じられるかもしれませんが、すべてを理解する必要はありません。セキュリティは適切なツールを活用することで一定レベルの品質担保が可能ですので、必要なツールを選択し、利用できるように勉強や準備環境を整えることが第一歩です。

それでも「社内での対応は難しい」という場合には、弊社の無料相談会などもありますので、ぜひ「支援コンサル」を入れる前にご活用ください。セキュリティは常にアップデートしなければならない情報がたくさんある領域であるため、そういった点でもプロのサポートが役に立つはずです。

Webアプリの脆弱性検査ツール「Vex」

新規CTA

セキュリティ課題の分析を無料でサポート!「無料相談会」実施中

セキュリティ課題の分析を無料でサポート!「無料相談会」実施中