セキュリティガイドライン策定支援サービス

概要

セキュリティ基準となるガイドラインで、よりセキュアな開発を実現!脆弱性改修の手戻りや運用開始後のセキュリティインシデントを未然に防止する

セキュアなWebサイトを構築するためには、ある一定の基準(ガイドライン)に基づいたアプリケーション開発を行うことが有効です。これにより、開発者のスキルによらず、セキュリティ対策の統一化が可能となるため、脆弱性改修による手戻りの削減やセキュリティインシデントの未然防止に繋がります。自社内で開発する場合の脆弱性対策やセキュリティ機能を定めた開発ガイドラインに加え、外部の開発ベンダに開発を委託する際のセキュリティ要求仕様書など、お客様のご要望に合わせてさまざまなガイドラインを提供します。

開発工程における本サービスの位置づけ

作業工程:要件定義 実施すべきセキュリティ対策:(PDCA) 1. セキュリティ要件定義 具体的施策:セキュア開発ガイドライン策定支援 作業工程:基本設計・詳細設計 実施すべきセキュリティ対策(PDCA):2. セキュリティ機能設計 具体的施策:セキュア開発ガイドライン策定支援 作業工程:開発・構築 実施すべきセキュリティ対策(PDCA):3. セキュリティ開発・構築 (セキュアコーディング) 具体的施策:セキュア開発ガイドライン策定支援 作業工程:テスト 実施すべきセキュリティ対策(PDCA):4. セキュリティテスト 具体的施策 :Webアプリケーション診断トレーニング

サービスフェーズ

Webアプリケーションの開発工程において、「要件定義」または「開発」フェーズにおいてセキュア開発ガイドラインを用いた設計・開発が効果的です。特に設計に起因する脆弱性が開発(コーディング)後に見つかった場合、大幅な手戻りが発生し余分な工数がかかるとともに、サイトのリリーススケジュールに影響することも考えられます。「要件定義」および「設計」の段階でガイドラインにのっとった運用を導入することをお勧めします。

導入前 診断→修正→診断→修正を繰り返す 独自に策定したガイドラインに則り、セキュリティライフサイクルに沿ったWebアプリケーションの開発を行うことが求められます。導入後 Plan:セキュリティ対策ガイドラインの策定 Do:ガイドラインに基づいた開発 Check:Webアプリケーション脆弱性診断の実施、セキュリティレベルの把握・リスク分析 Action:脆弱性の改修、セキュリティ対策ガイドラインの見直し

サービス内容

セキュリティガイドライン策定

セキュアなWebアプリケーションを開発するには、開発工程ごとにセキュリティ対策を実施する必要があります。これを実現するためにセキュア開発ガイドラインとチェックシートを策定します。

フェーズ1 分析 実施項目:1-1. 現状分析(脆弱性診断)、1-2. ガイドライン骨子作成、1-3. 中間報告会 成果物:脆弱性診断報告書、ガイドライン骨子、議事録 フェーズ2 策定 実施項目:2-1. ドキュメント作成、2-2. ドキュメント修正、2-3. 最終報告会 成果物:ガイドライン、チェックシート、議事録 フェーズ3 導入 実施項目:3-1. 導入準備(お客様作業)、3-2. トレーニング、3-3. 本番運用(お客様作業) 成果物:議事録

利用シーン

Webセキュリティ成熟度モデル

KCCSではWebアプリケーションのセキュリティレベルを確認する指標として、独自の「成熟度モデル」を作成しています。セキュア開発ガイドライン策定支援サービスは、この成熟度モデルにおいて、「診断」 ⇒ 「対策」の繰り返しという受動的対策のレベル1の段階から、「セキュア開発ガイドラインに従って改善できる」というレベル2を目指すお客様向けのサービスとなります。

セキュリティレベル:セキュリティレベル0~セキュリティレベル3の昇順となります。

セキュリティレベル 説明
レベル0:何もしていない 脆弱性の対策をしていない状態である。ガイドラインなどによるセキュリティ対策や、サービス開始前のセキュリティテストなどの対策が行われておらず、結果として脆弱性が大量に存在するWebサイトとなっている。
レベル1:診断して修正する 診断後、都度脆弱性を修正する状態である。この場合、開発工程での対策が十分考慮されていない可能性が高く、手戻り(診断後の修正作業)が多くなり、結果として時間とコストが多くかかることが予想される。
レベル2:ガイドラインに従って改善できる あらかじめ定めたガイドラインに従って設計・実装・構築時に対策を行い、併せてサービス開始前に診断を実施する状態である。このレベルは、レベル1と比べ手戻り(診断後の修正作業)が少なくなることが予想される。レベル1と同様にサービス開始前の診断については専門家に委託する必要があるが、診断項目・対象の絞り込みが可能であり、レベル1よりもコストが削減できる。
レベル3:自ら改善できる 自社内にセキュリティ専任部門を設置し、自らガイドライン改定などの運用も含めた継続的なセキュリティ対策を推進できる状態である。

導入効果

ガイドライン導入前と導入後の効果例

開発者の疑問 ガイドライン導入前 ガイドライン導入後
例1 データベースを使用したいが、どのようにデータベースを呼び出せば良いか? 個々の開発担当者のスキルに依存し、データベースの呼び出し方を誤って実装する可能性がある。
⇒SQLインジェクション脆弱性が発生。
「データベースセキュリティ」の開発規約を参照。
⇒脅威を理解し、サンプルコードを参照しながら、人に依存しない脆弱性対策を事前に取ることが可能。
例2 一般/管理者権限に応じて機能を分けたいが、どのようなことに注意すれば良いか? 設計の際、権限管理に関して知識が不足しており、権限に応じた考慮が欠けてしまう可能性がある。
⇒アクセス制御の不備が発生。
コーディング後に脆弱性が見つかった場合、大幅な手戻りが発生し、余分な工数がかかってしまう。
権限に関する設計を行う際、「認証 - アクセスコントロール」の開発規約を参照。
⇒セキュリティを意識した設計が可能。
例3 画面に入力データを表示させる場合、具体的にどのように実装すれば良いか? 対策方法は知っているものの、対策レベルに差があり、あるパターンにおいては漏れが発生する可能性がある。
⇒クロスサイト・スクリプティング脆弱性が発生。
「表示関連処理」の開発規約を参照。
⇒開発者や外注ベンダのレベルに依存することなく、一定のレベルで対策が可能。

価格

基本雛形をベースに、お客様のご要望に応じてより現場に即したセキュリティガイドラインを作成します。カスタマイズ内容に応じて価格が異なるため、当社営業までお問い合わせください。

お問い合わせ・資料請求別ウィンドウで開きます

カタログダウンロード

京セラコミュニケーションシステム(KCCS)は、セキュリティブランド「SecureOWL」を展開しています。
鋭い眼光と広い視野で暗闇でも見通すフクロウ(OWL)をブランドのキャラクターとしました。お客様の環境を監視し、大切な情報を守るためのセキュリティソリューションを提供します。