EN

NRIセキュア ブログ

セキュリティ診断の実施基準|脆弱性へ効果的・効率的に対応するための考え方

目次

    blogtop 

     サイバー攻撃による情報漏えいやアカウントの不正利用など、企業の社会的信用の失墜や経済的なダメージに繋がりうる様々な脅威が増加しています。こうした背景からビジネスリスクを低減するために、インターネット上でサービス展開している事業者は、Webアプリケーション診断、プラットフォーム診断、クラウド診断などのセキュリティ診断(以下「診断」と記載、図1)を実施して、システム公開前に脆弱性を発見することが重要です。

     

    新規CTA

     

    図1 様々なセキュリティ診断1

     また、診断は開発工程と並行して準備され、開発の規模が詳細に決まってくる詳細設計中盤あたりから本格化し、連結テスト(システムテスト)と並行して診断するプロジェクトが多いかと思います。なお、この際準備期間に、診断対象の整理やどのようなセキュリティ診断を実施するかなどの診断要否判断が必要になります (図2)。

     

    図2 システム開発プロジェクトにおける診断タイミング(例)2

     

     診断要否判断については、システムの利用端末(利用者)(以下「利用端末」と記載)、利用ネットワーク(以下「NW」と記載)、提供サービスなどを考慮して行います(図3)。図3ではシステムA、Bを判断例として挙げています。システムAは一般的に利用されるWebコンテンツ(ECサイトなど)で静的画面を対象外にしており、システムBは社内システムで重要情報を持っていないシステムであるため、診断を実施しない(対象外)という判断となっています。

     

    図3 診断要否判断 (例)3

     この診断要否判断を実施する際、筆者としては体系的なセキュリティ診断基準(以下「診断基準」と記載)を事前に用意することが必要であると考えています。理由としては、診断基準のような診断要否の条件をまとめた資料がない場合、開発担当者の経験や知見に依存したり、経験や知見が少ない開発担当者による診断対象の過不足や、検討時間が長期化したりする可能性あり、診断を効果的・効率的に行うことが難しくなるためです。

     

     このブログでは診断を進めるにあたり、現場が抱える問題点、診断基準の基本的な考え方、診断基準を作成する際に、どのようなポイントを考慮すべきかについて例示を基に解説します。

    多くの企業が抱える問題点

     システムの開発が完了し、利用者に公開する(リリース前)までに、診断を行い脆弱性を発見することは、サイバー攻撃によるセキュリティ事故を最小限に留めることにつながります。リリース対象となる全ての機能に対し診断を行うことが理想ですが、一般的に診断の対象が増加すると、診断に要する費用や時間も増えます。

     

     そのため、企業の多くは、診断の対象を最小限にするための診断基準を作成しています。ただし、その診断基準は、診断対象を特定するには曖昧な基準(条件)となっていること場合もあります。

     

     診断対象を決める条件が曖昧であると、診断要否判断に想定以上の時間を要すことになり、予定していた日程までにリリースができないおそれがあります。また、開発担当者の解釈に依存すると、診断の対象に不足が発生し、結果として脆弱性が存在した状態でリリースされ、サイバー攻撃によるセキュリティ事故に繋がります。

     

     診断基準に関して、曖昧さをすべて無くすことは難しいものの、どのような考え方で診断基準を作成すると、曖昧さの排除が可能かという筆者の考え方について、次章に記載します。

    セキュリティ診断の要否判断における基本的な考え方

     診断要否を考える上で基本となる観点は下記3つであると考えます(図4)。

     

     <基本観点>

      ①システムに接続するための利用端末(PC、スマートフォン等)

      ②システムに接続するために利用するNW(インターネット、社内NW等)

      ③システムが提供するサービス(ECサイト、ネットバンキング、問い合わせ等)

     

    図4 診断要否判断に必要な3つの観点4

     診断要否判断は提供サービスへの利用端末からのアクセス方式やサービスが利用する情報などを考慮する必要があります。なお、クラウドに関しても利用状況に応じて診断基準に記載する必要はありますが、本稿では取り扱わずに、一般的なシステム構成を3つ挙げ、それらに対して考慮すべき基本的なポイントを解説します。

    パターン1(一般公開システム~不特定多数利用~)

     不特定多数の利用端末(PCやスマートフォンなど)からアクセスされる一般公開システムは公衆回線などのインターネットを経由します。また、システム側で接続元IPアドレスを制限するといったことも通常困難であるため、悪意を持った利用者からもアクセスされるおそれがあり、脆弱性を無くすことが重要になります。

     

     このパターンでは、提供サービスに関わらず、悪意を持った外部の第三者のアクセスが可能となるため、セキュリティ的な問題がないかを確認するために診断対象とすべきです(図5)。一方で、企業概要などの静的コンテンツで構成される画面などはWebアプリケーション診断の対象外とします。

     

    図5 一般公開システム~不特定多数利用~5

    パターン2(一般公開システム~特定企業利用~)

     取引がある特定の企業(他社)向けに公開しているシステムや自社従業員向けに公開しているシステムはインターネットを経由するものの、接続拠点ごとのIPアドレスで接続元を制限していることが多いです。

     

     その場合、NWレイヤーで制限がかけられているため、悪意を持った外部の第三者からのアクセスは無くなりますが、利用端末がマルウェア感染して踏み台になった場合は公開しているシステムが攻撃を受けるおそれがあります。

     

     そのため、このパターンも診断対象となりますが、提供サービスにて重要情報を保有していない場合は診断を実施しないなど、情報の重要度に応じた診断要否を診断基準作成時に作り込む必要があります。(図6)。

     

    図6 一般公開システム~特定企業利用~6

    パターン3(社内システム/管理システム)

     パターン2と同様に社内NWや専用線などクローズドなNWからアクセスされるシステムについても悪意を持った外部の第三者からのアクセスはありません。加えて、利用端末は自社のセキュリティ統制の範囲内であることからマルウェア感染のリスクも低減されていると考えられるため、診断を実施しないことが多いかと考えられます。

     

     しかしながら、社内システムにおいても重要な情報を取り扱う場合や、ActiveDirectoryのような全社のIDを扱うシステムなどにおいては、パターン2と同様、診断を行うべきであるため、診断基準を作成する際に条件として明記する必要があります (図7)。

     

    図7 社内システム/管理システム7

     基本的な考え方を代表的なパターン1から3を用いて説明しました。冒頭で述べたようにアクセス方式(利用端末やNW)や提供サービス(保有情報)に鑑みてパターンを増やして可視化していくことで曖昧さを排除していくことが重要です。

     

     特に、パターン2、3については接続元を制限している場合や内部のNWに閉じている場合であっても保有する情報によっては診断実施を選択する旨を上述しましたが、これはシステムを公開している企業の監督官庁から出されている各種ガイドラインや業界団体が発行する指針、および法令対応の観点から内部システムであっても診断が必要となる場合があるからです。

     

     また、診断基準は文章のみの構成だとミスリードが起きやすいため、下記のようにマトリクスなどを用いて情報を整理し、判断をしやすいものにすることも重要になります(図8)。

     

    図8 診断要否判断マトリクス(基本系)8

    考慮すべきポイント

     基本的な考え方については、前述した内容となりますが、その他にもシステムの構成なども考慮する必要があり、ここでは1つの例示(非レスポンシブデザインで作られたシステム)を取り上げ解説します。

    非レスポンシブデザイン画面の診断対象漏れ

     レスポンシブデザインとはエンドユーザがWebコンテンツにアクセスする際の利用端末がPCとスマホ等に関係なく同じソースコードで画面描写する仕組みです。一方で非レスポンシブデザインはPC、スマートフォン(タブレット)で別々のソースコードで画面描写する仕組みです。

     

     ECサイトに対し診断を実施する場合、Webアプリケーション診断を実施することになると思いますが、Webコンテンツの作りを意識することが必要です。これは非レスポンシブデザイン場合、PCでアクセスした際に画面描写されるソースコードのみ診断対象とすると、スマートフォン(タブレット)でアクセスした際に使用されるソースコードが診断対象から漏れるためです。

     

     これがログイン画面やクレジットカード決済に関連する画面で発生し、当該画面に致命的な脆弱性が検出された場合、是正されるまでサービス停止などの措置を取らざるを得ない状況となるおそれがあります。

     

     昨今ではこのように非レスポンシブデザインを用いたWebコンテンツは減少傾向にあるものの、注意したい1つのポイントです。また、スマートフォン向けのページが用意されていないシステムに対し、スマートフォンサイトを新たに作成する場合、リリース後の定期的な診断のタイミングで片方のコンテンツが診断対象から漏れることが想定されるためこちらも注意が必要です。

    さいごに

     本稿では、診断要否判断で必要な基本的な考え方や例示を踏まえて考慮すべきポイントなどを解説いたしました。診断基準については基本的な考えをもとに、診断要否判断の条件を明記することで、開発担当者の経験や知見に依存することなく、診断範囲の見極めが容易になることをお伝えできたかと思います。

     

     一方で、診断基準の作り込みの部分に関しては、自社の業務特性や専門的な知見をもとに作成していく必要があり、それにはセキュリティの知見を保有した人員によるサポートが必要となります。NRIセキュアでは、診断基準作成に関する豊富な支援実績、ノウハウをもとにしたご支援を行っています。自社のセキュリティ診断に関わるリソースの選択と集中を行い、効果的・効率的な診断をご要望の際には、是非お問い合わせください。

     

    新規CTA