プラクティス5-4 セキュリティバイデザインを標準とする、クラウドベースの開発プロセスの励行
従業員数500名規模の金融系IT子会社であるK社は、Fintechを含む金融系のサービスやプロダクトの開発・実証を行っている。現在、開発プロジェクトの対象はクラウドベンダーの提供するIaaS上で運用するものが主流となっている。同社は従来、開発工程で諸機能を実装するタイミングでセキュリティ機能も検討していたが、対応すべき脅威が多様化する中、開発部門の責任者は担当者への負担増や、手戻りによる開発スケジュール遅延等の発生等を課題と感じていた。全社のセキュリティ開発を統括するセキュリティチームとの相談の結果、いわゆる「セキュリティバイデザイン」として企画・設計段階からセキュリティ機能を組み込むことが適切と判断し、自社の標準的な開発プロセスとして規定することとした。
K社の実践のステップ
セキュリティ機能は一般にソフトウェアの主たる目的には含まれないが、かといって後付けで実装しようとすると設計・開発段階まで手戻りが生じることにもなりかねない。近年、セキュリティバイデザインの重要性が認識されつつあるが、企画・設計段階でセキュリティ要件を明確化することは容易ではなく、同社も踏み込んだ検討には至っていなかった。K社のセキュリティチームのリーダーは、開発部門のニーズに合わせた脅威分析を支援することで、次のステップでセキュリティバイデザインの導入に取り組んだ。
- ①ソフトウェアの概念設計フェーズにおいて設計内容が固まった段階で、次ページ図の要領で開発と並行して脅威分析を行う手順を標準的な開発プロセスに追加した。なお、あくまで標準であって、プロジェクトの特徴に応じた個別対応を妨げるものとはしていない。
- ②運用段階における対策については、インフラチームの協力を得ることで実装するクラウド環境における適切なセキュリティ設定の維持、仕様変更対応やインシデント対応体制等が担保されるようにした。
- ③現状では上記①②を通じてセキュリティバイデザインを概ね実践できているが、さらなる効率化を実現するため、ソフトウェアの用途や環境に応じた脅威分析の適切な粒度を見極めるための手法について検討している。
K社の実践内容
K社が設計段階で実践しているセキュリティ対策は次の通りである。
- 脅威分析にはSTRIDE（次ページ参照）を利用。概念設計段階で作成するDFD（Data Flow Diagram）をもとに、各ポイントでどのようなセキュリティ脅威があるかの洗い出しを実施。洗い出しはセキュリティチームで行うが、ユースケースによって脅威が異なってくることもあることから、必要に応じて設計チームと脅威の想定についてのディスカッションを行っている。
- セキュリティ対策に関する要求仕様としては、公益財団法人金融情報システムセンターの『金融機関等コンピュータシステムの安全対策基準・解説書』に準拠しつつ、用途別にチェックリストを作成して対応。
- クラウド環境において実施する対策の選定にはCISベンチマーク（下欄）を使用。これは要求されている対策が具体的で顧客や開発ベンダ等とのコミュニケーションにも使いやすいとの判断による。
- クラウドが提供するアクセス制御機能やモニタリング機能等を活用。これらの可用性確保に関する保守をクラウドベンダに委ねることでセキュリティ機能の運用の効率化を実現。
- セキュリティ機能の実装には、対象のクラウドサービス用に業界で用いられているテンプレートを適用することで、利用可能なベンダーのセキュリティ機能を活用しながらセキュアな環境構築を行った。
図1 K社のソフトウェアライフサイクルにおけるセキュリティバイデザイン導入の効果比較
参考情報
CISベンチマーク
https://www.cisecurity.org/cis-benchmarks/
米国の非営利法人Center for Internet Security）が公表している、情報システムの構築・運用における構成要素別のセキュリティ対策のベストプラクティスを定めたガイドライン。
STRIDE
https://www.ipa.go.jp/files/000046476.pdf
Microsoft が提唱する脅威の分類手法。「なりすまし」「改ざん」「否認」「情報漏えい」「サービス拒否」「特権の昇格」の6種類のカテゴリから脅威を洗い出す手法。