1/2ページ
カタログの表紙
カタログの表紙

このカタログをダウンロードして
すべてを見る

ダウンロード(1.2Mb)

セキュリティベンダー選定のための比較チェックシート進呈中

その他

誰でも簡単に重要な観点を押さえながら、ベンダーの比較検討ができるチェックシートをご用意しました!

脆弱性診断サービスの導入にあたり、数あるセキュリティベンダーの中から
最適なベンダーを選定するためには確認すべき観点が多くあり、
それらを正しく判断するためには本来豊富な知見が必要です。

しかし、担当者の誰しもがそのような知見を持っている訳ではありません。
そこで、SHIFTは、誰でも簡単に重要な観点を押さえながら、
ベンダーの比較検討ができるチェックシートをご用意しました。

お客様に合った最適なセキュリティベンダーを選んでいただくことに
お役立ていただければ幸いです。

このカタログについて

ドキュメント名 セキュリティベンダー選定のための比較チェックシート進呈中
ドキュメント種別 その他
ファイルサイズ 1.2Mb
登録カテゴリ
取り扱い企業 株式会社SHIFT (この企業の取り扱いカタログ一覧)

このカタログの内容

Page1

評価 チェック観点 確認事項 具体例・解説 リスク A社 B社 C社 D社 E社 (〇△×) 脆弱性診断は原則、年に1回以上など定期的に行う必要があります。同じシス □ ベンダーが観点表をもっている テムで再度診断をする際、診断基準が変わっていないにもかかわらず、前回指 同じシステムに対して2回以上診断を実施して 摘されていない脆弱性が見つかるというケースがあります。依頼前にベンダー 〇 も、診断結果に違いはでないか? □ 毎回同じ観点で診断してもらえる が観点表を整備しており、毎回同じ観点で診断してもらえるかどうかをご確認 ください。 安 大きな変更のない同一システムにおいて毎回の診断報告内容が変わる場 診断観点が診断員によって異なり、同じシステムであるにも関わらず、前回指 定 診断担当者が変わっても、診断観点・報告内 □ 個々の診断員に依存した属人的な診断がさ 合、診断漏れによって本来見つけられるはずの脆弱性を解消できていない 摘されていない観点から脆弱性が見つかるケースがあります。個々の診断員に 性 可能性があります。 〇 容に違いはでないか? れないよう、診断が仕組化されている 依存した属人的な診断がされないよう、診断が仕組化されているかどうかをご 確認ください。 お客様の業種やプロジェクトの違いにより、診断対象となるシステムの構成は 業種やシステム構成によって診断観点・報告 □ システム構成が違っても、同一の診断観点 さまざまであると考えられます。システム構成が違っても、同一の診断観点に 〇 内容に違いはでないか? に基づいて漏れなく診断ができる 基づいて漏れなく診断ができるかご確認ください。 □ サイトクローリングなどで診断対象のリク 脆弱性診断の実施単位はクライアントアプリとサーバーの間の通信(リクエス ト)です。見積時または診断の前の段階で、診断すべきシステムの各画面・機 エストを網羅的に抽出できている サイトクローリングなどを行い診断対象のリクエストの網羅的な洗い出し 能に対するクローリングを行い、診断対象となるリクエストが網羅的に抽出さ 診断対象を網羅的に洗い出せているか? やお客様側でのリクエスト一覧の確認工程がないと、診断漏れが発生する 〇 れているかどうかをご確認ください。また、診断ベンダーからリクエスト一覧 □ リクエスト一覧で漏れがないか確認できて リスクがあります。 が提示され、仕様を把握しているお客様側でそれを確認し、漏れている対象機 いる 能がないかを確認する工程も必要になります。 網 診断の内容を記したテスト仕様書がベンダーから提示されていない場合、 診断観点や診断項目がわかる資料が提示され、システムのどの範囲をどこまで 目的に沿った診断が実施されるかは診断報告書を見るまで確認する術があ 羅 診断の範囲や深さをベンダーが提示する資料 □ 診断観点や診断項目を確認できる資料(テ 診断するかを把握できることが理想的です。それらを確認できる資料(テスト りません。「確認してほしい箇所を見てもらえなかった」「もう少し深く 〇 性 (テスト仕様書など)で確認ができるか? スト仕様書など)が事前に提示されている 仕様書など)がベンダーから事前に提示されるかご確認ください。 診断して欲しかった」など、期待と見合わない結果になる恐れがありま す。 多くのベンダーが、セキュリティの国際的な研究機構であるOWASPや、国内 ASVSやOWASP TOP10などの外部基準を取り入れていない場合、診断すべ 政府機関であるIPA(情報処理推進機構)などが規定する基準に基づいて診断 き重要な観点が網羅されているかどうかが不明確になります。 診断の基準がASVSやOWASP TOP 10などの □ 国際基準に沿った診断が実施されることを 項目の整備をしています。どのような基準に沿った診断を実施するのか、また 第三者機関に診断した実績の提示を求められた際、診断した事実はあって 〇 国際基準に適応しているか ? 確認できる その基準が実際の診断に適用されるかを、ベンダーの診断観点表やテスト仕様 も、どのレベルの診断を行ったかを示す客観的な根拠を提示できなくなっ 書などの資料でご確認ください。 てしまいます。 例えば、クレジットカード情報を保有するシステムの場合、PCIDSSに準拠 システムの用途によって取り扱う機密情報(個人情報、顧客情報等)が異なり した診断項目を実施する必要があります。システムや業界によって求めら システム特性や業界特性を考慮した診断がで □ システム特性や業界特性によって満たすべ ます。金融業界であれば取り引きや決済の情報も含まれます。システム特性や れる要件をクリアしだ基準で診断できない場合、見るべき観点が漏れてし 〇 きているか? き診断基準、観点が含まれている 業界特性によって満たすべき診断基準、観点が含まれているかをご確認くださ まい、本来実施するべき診断レベルに満たない結果となるリスクがありま い。 す。 □ 偏りのない診断を可能にする仕組みを持っ ている ホワイトハッカーはそれぞれの独自の経験や知見に基づいた診断観点をもって 専 います。人によって考え方が違ったり、得意不得意があったりするため、偏り 門 複数名のホワイトハッカーの観点で偏りのな のない診断を可能にする仕組みをベンダーがもっているかご確認ください。診 特定のホワイトハッカーの知見に依存すると、属人的な診断となり、本来 □ 診断基準が公開されている 〇 性 い診断ができているか? 断基準が公開されることがベストです。 見つけられるはずの脆弱性を発見できないリスクがあります。 また、診断エンジニアが診断する場合は、ホワイトハッカーによるレビュー工 □ ホワイトハッカーによるレビュー工程が入 程が入るかどうかも確認しておくとよいでしょう。 る(診断エンジニアが診断する場合) Webアプリケーション、スマートフォン、サーバー(OS、ミドルウェア)、 診断サービスごとにベンダーがわかれていると、契約手続きや管理工数が プラットフォームに応じた豊富な診断サービ □ あらゆるプラットフォームに対応した幅広 クラウド基盤など、脆弱性診断の対象はさまざまです。あらゆるプラット 増え、ビジネススピードに影響します。診断基準や報告内容に違いが発生 〇 スが用意されているか? い診断サービスを提供している フォームに対応した幅広い診断サービスを提供しているベンダーがおすすめで し、脆弱性の対応工数にも影響する場合があります。 す。 □ ヒアリングシートなどで診断に必要な情報 診断前に情報連携などの準備を綿密に行わないと、診断開始後に確認・対 のやり取りがある 診断開始前に、ヒアリングシートなどで診断に必要な情報のやり取りがあり、 応工数がかかり、診断スケジュールに遅れがでます。その遅れがプロジェ 計画通り診断を実行し、報告書の納品ができ 診断に要する期間の提示やスケジュール通りに実施できる体制があるかどうか クト全体の遅延を引き起こす可能性もあります。 〇 るか? □ 診断に要する期間の提示やスケジュール通 を確認する必要があります。 依頼主側の都合で診断期間が延⾧となった場合、追加費用を請求される可 生 りに実施できる体制がある 能性もあるため注意が必要です。 産 性 □ 規模に応じた費用の根拠が見積明細などで 診断規模に見合った費用になっているか? 診断費用は対象システムの画面数やリクエスト数のボリュームによって決まり 限られた予算で診断をする場合、システム全体の診断がむずかしく、画面 〇 確認できる ます。規模に応じた費用の根拠があり、意図していない作業工数やフィーが加 や機能を限定しながら診断を行わなくてはならない場合があります。ベン 算されていないかを見積明細などでご確認ください。※ベンダーによっては繁 ダーから提示された診断費用の根拠が明確でない場合、実際の診断規模に □ 意図していない作業工数やフィーが加算さ 診断工程に無駄がないか? 忙期料金や特急料金を設定していることがあります。 見合った費用であるかを判断できません。 〇 れていないことが見積明細などで確認できる
Page2

□ テスト仕様書や診断実施ケース一覧などが 診断観点や診断項目が明確で、システムのどの範囲をどこまでを診断するのか 観点や項目が示されない場合、目的に沿った診断が実施されているかを確 入手できる が把握できることが理想的です。テスト仕様書や診断実施ケース一覧などが入 認することがむずかしくなります。「診断してほしい箇所が漏れてしまっ 診断する観点や項目が示されているか? 〇 手できるか、また期待する診断を行うにあたって、その内容が十分かご確認く ていた」「特定の箇所において、もう少し深く診断してほしかった」な □ 診断を行うにあたって、その内容が十分で ださい。 ど、期待する診断とのギャップが発生するリスクがあります。 あると確認できる 診断後、対象システムの開発担当者に適切なフィードバックをするために は、リスクのある個所(NG)のみでなく、診断対象全量に対して問題がな 透 □ 診断後の報告書で、OK/NG箇所をそれぞれ 基本的に、診断後に納品される報告書はNG箇所のみの記載になっています。 診断結果はOK/NG箇所が明確か? かった箇所(OK)も把握できる状態が望ましいです。こうすることで、次 〇 明 確認することができる OK箇所も確認することは可能か依頼前にご確認ください。 回の診断時にはOK項目を除外するなど、対策を効率化することもできま 性 す。 報告書にはリスクがある箇所の対策方法や再現方法(診断手順)が記載されて □ エンジニアでなくても内容がわかるよう、 いることが一般的です。エンジニアでなくても内容がわかるように具体的な説 診断結果に対する対策方法に曖昧な点があると、システムの修正に余計な 報告書内で診断結果に対する対策が提示され 具体的な説明があり、記載が工夫されている 明があることや、画面のスクリーンショットが添付されているなど、記載が工 工数がかかる可能性があります。診断結果の詳細を把握するために有償の 〇 ているか? 夫がされているとスムーズに対策を実施できます。専門用語や技術用語の解読 事後報告会を実施するケースもありますが、報告書の記載のみで完結でき □ 不明点があった場合のサポート体制がある がむずかしかったり、対策方法に不明な点があった場合のサポート体制の有無 ることが理想的です。 についてご確認ください。 クライアントのネットワーク環境によっては、診断対象となるシステムに制約 診断ベンダーがオンサイトや常駐による診断に対応していないことがあり □ オンサイトでの診断作業や常駐にも対応で があり、外部からの接続で診断ができないケースがあります。その場合、オン オンサイト対応や常駐による診断が可能か? ます。その場合、そもそも診断を受けることがむずかしい可能性があるた 〇 きる体制をもっている サイトでの診断作業や常駐が必要になるため、診断ベンダーが対応できる体制 め、スケジュールに余裕がない場合は早めの確認が必要です。 をもっているかご確認ください。 対象システムの本番環境を診断したくても、診断ベンダーによっては診断時の 柔 環境への影響を懸念し、開発環境のみの診断を対象とするケースがあります。 診断の目的は、最終的にサービスが稼働する本番環境のセキュリティリス 軟 開発・本番環境に応じたサービス提供が可能 □ 開発環境・本番環境に関わらず診断ができ 開発環境・本番環境に関わらず診断可能かどうか事前にご確認ください。※た クや脆弱性を見つけ対策することです。設定やプログラムが異なる開発環 〇 性 か? る だし、本番環境への影響の懸念がある場合、診断内容に制限が必要になること 境の診断のみでは、本番環境側にリスクが残る可能性があります。 もありますので、その場合は、本番と同等のステージング環境を用意すること が推奨されます。 限られた予算内でWebアプリケーション診断を行う際、優先度に応じてシステ □ 予算に合わせて診断範囲の柔軟な調整がで 予算枠に応じたプランがない場合、診断をあきらめなければならない場合 予算内で最適な診断を提案できるか? ム画面やリクエスト単位での診断範囲の調整が必要になります。診断ベンダー 〇 きる があります。 側で柔軟な調整が可能かご確認ください。 診断ベンダーのリソースにも限りがあるため、空きリソースがない場合、診断 希望のスケジュールに対応可能なリソースが □ 希望通りのスケジュールを実現するための をすぐに実施できない場合があります。診断ベンダーに十分なリソースがある 〇 確保されているか? 十分なリソースがある かどうか、診断実施に向けていつから依頼をすれば希望通りのスケジュールが 確保できるかご確認ください。 例年12月から翌年3月にかけては、IT業界の予算消化時期のため、診断ベン 依頼タイミングに関係なくいつでも診断を依 □ 数ヶ月後の診断となったり、特別価格が上 ダーも繁忙期になります。リソースに空きがないと数ヶ月後の診断となった 〇 頼できるか? 乗せになることがない り、診断ができたとしても特別価格が上乗せになることがあります。依頼予定 即 の診断ベンダーが繁忙期にはどのような対応をするのか予めご確認ください。 報告書が早くでてこないと、対策のためのシステム改修が進みません。特 にサービスリリース前の診断を実施する場合、対策が間に合わないとイン 時 シデントリスクを抱えた状態でリリースすることになります。改修期間を 性 □ 診断から報告書納品までのリードタイムが 十分に確保したスケジュールで報告書を受け取れることが理想です。 短い 診断完了後、報告書がでてくるまで、脆弱性があったとしても対策することが できません。報告書の納品は一般的に1~2週間程度ですが、早ければ早いほ □ 簡易的な進捗報告を日次で行うなどの対応 ど早期に対策ができます。診断から報告書納品までのリードタイムをご確認く 診断後すぐに報告書が納品されるか ? 〇 ができる ださい。また、診断の簡易的な進捗報告を日次で行ったり、重大な脆弱性が見 つかった場合に、リスクのある個所の報告を優先的に行うベンダーも存在しま □ 重大な脆弱性が見つかった場合、すぐにリ す。そのような対応を取れるかも合わせてご確認ください。 スクのある個所の報告を優先的に行ってくれる 総合点(〇3点、△1点、×0点): 63 0 0 0 0 0