EN

NRIセキュア ブログ

「シフトレフト」の始め方|設計工程で作りこまれる脆弱性にどう対処するか?

目次

    シフトレフトセキュリティのススメ

    システム開発に取り組まれている皆さま、情報セキュリティに関する事故を最小限に留めることを目的として、開発のテスト工程で事前に発見した脆弱性に対処できる、セキュリティ診断サービスの報告書を有効に活用されていますか?

     

    また、危険度の高い脆弱性がセキュリティ診断サービスで発見された際にはシステムのリリースに大きな影響を与えることになりますが、これを最小限に留めためにシフトレフトに取り組まれていますか

     

    さらに、開発の上流工程で脆弱性に対して先手を打つ、セキュリティ・バイ・デザインをご存じでしょうか?

     

    セキュリティ・バイ・デザインは、これまでのシステム開発でも取り入れられてきた概念です。しかし、皆さまにとって、“開発の上流工程で先手を打つ”ことが一般的によい施策であることをイメージできるものの、実際に得られる効果は想像しづらい(効果測定しづらい)と感じることはないでしょうか。

     

    一方、開発の後工程(開発工程の右側)で発見される脆弱性の発生原因を、前工程(左側)で根本解決することを目的とするシフトレフトは、皆さまにとって、課題解決型の施策となることから得られる効果を想像しやすく感じないでしょうか。

     

     

     

     

    セキュリティ・バイ・デザインShiftLeft重要性 
    セキュリティ・バイ・デザインとShiftLeftの重要性 

    セキュリティ・バイ・デザインシフトレフトはともに重要な概念です。

    本日はシフトレフトのメリットについて、開発者とセキュリティベンダの視点を交えて考えたいと思います。

     

    システム設計・開発における、セキュリティ・バイ・デザインについては、下記をご参照ください。

     

    MS&ADシステムズ株式会社 様

     

    セキュリティ・バイ・デザインの実践の仕方|スピード感とセキュリティを両立させるスキーム

     

    現場と寄り添いながらセキュアなサービス開発プロセスを整備してきたセブン&アイグループ

     

    また、サービス仕様に関する、セキュリティ・バイ・デザインについては、下記のブログをご参照ください。

     

    QRコード決済に迫る攻撃者 セキュリティー対策の要諦|アプリ対策だけでは不十分、サービス全体のリスク分析が重要

     

    デジタルクライムにどう立ち向かうか|サービス不正利用のリスク分析の進め方  

    【お役立ち資料ダウンロード】サイバー攻撃・内部不正による情報漏えいを効果的に防ぐ手段とは?インシデント事例から見えてくる解決のカギは「特権ID管理」

    開発の現場でよく起きる課題

    プロジェクトの終盤に受領した、外部専門家によるセキュリティ診断サービスの報告書を確認して、呆然としたことはありませんか?

     

    私は何度か経験したことがあります。特に、私自身の開発経験が浅かったころや新規システムの開発プロジェクトでは、発見された脆弱性の改修にかかる追加のアクションを即時に想像できない(想像したくないときもある)ことから、呆然としたものでした。

     

    例えば、脆弱性を作りこんだ直接原因と根本原因の分析、改修コストの増加による各種調整、リリース遅延による社内外のステークホルダーへの悪影響、そして脆弱性改修後の再テストなど、追加となるアクションは多岐にわたります。時には、脆弱性の改修方法に考慮漏れがあり、ノンデグレードテスト中にアプリケーションが正常に動作しないことが判明し、改修方法の再検討が求められることもありました。

     

    そして、これらの課題を解決している最中には、設計工程でセキュリティをもう一歩踏み込んで検討していたら、と強く後悔したこともありました。

     

    実際に、NRIセキュアで実施したセキュリティ診断の傾向を分析すると、約3割のWebアプリケーションで重要情報の窃取に繋がる危険な脆弱性が発見されています。診断で発見された脆弱性の半数以上は要件定義・設計フェーズで作りこまれています。脆弱性を修正する場合、設計時での修正コストを1とすると運用時での修正コストは約100倍に上ります。

    セキュリティ診断の統計情報から得られる気づき

    セキュリティ診断の統計情報から得られる気づき

    設計工程で作りこまれる脆弱性

    昨今、セキュリティ診断サービスに加えて、設計工程で作成される設計書のセキュリティレビューを行う設計評価サービスや、開発チームの皆さまと一緒にセキュリティ設計を行う設計支援サービスのご相談がとても増えています。その中から、設計工程でよく見かける課題を2つ取り上げます。

    例1)外部認証サービスとの連携における設計不備

    最近では、外部認証サービスと連携するWebアプリケーションやAPIも多く、そのシステム連携方式として標準プロトコルであるOpenID ConnectやOAuthを用いた認証・認可の仕組みを見かける機会が増えています。

    アーキテクチャ(外部認証連携)における設計不備

    アーキテクチャ(外部認証連携)における設計不備

    これらの標準プロトコルではセキュリティが考慮された設計が施されていますが、特定のシーケンス(上の図の赤線)で危険度の高い脆弱性(セッションを用いずに強度の低い推測可能な内部識別子でアクセス可能)が作りこまれていることをよく見かけます。このケースでは、標準プロトコルを採用したことで安心してしまい、Webアプリケーション側の認証方式のレビューが疎かになっていたことが原因でした。

    例2)設計書(開発チームをまたぐシステム間連携)のレビュー不足

    開発チームにとって、設計書を最新状態に維持することは想像以上に労力のかかるタスクではないでしょうか。特にサブシステムごとに開発チームが別れている場合には、開発チーム間でシステム連携方式を検討する必要が出てきます。

     

    例えば、モバイルアプリと連携するWebアプリケーション(API)を開発する場合には、モバイルとAPIでチームが別れることによって、それぞれのチームで設計書が作成されることがあります。そして、モバイルとAPIの設計書をつなげてレビューすることで、システム連携方式に矛盾が見つかることがあります。

    モバイルアプリとAPIのシーケンスモバイルアプリとAPI間のシーケンス

    はじめに、上記シーケンスにおけるAPI側の仕様は、機微情報A,Bを取得する際にはアクセストークンに加えて追加認証コードが必要、機微情報Bのみを取得する場合には追加認証コードが不要となります。

     

    しかし、モバイル側の仕様では、機密情報AよりもBのほうが漏洩した場合の影響が大きい情報と考えていました。また、モバイル側は機微情報A,Bをまとめて取得するので、機微情報Bのみを取得するAPIは不要と考えていました。

     

    つまり、機微情報B(Aよりも重要度が高い)に対して、追加認証が備わっていない(認証強度の低い)形で、本来開発が不要なAPIを誤った設計書に従って実装してしまう、可能性があったと言えます。このケースでは、設計書のレビュー不足から、以前検討した古いAPI仕様が設計書に残っていることに気が付けなかったことが原因でした。

     

    これらの例は、レビューの観点を備えることによって、設計工程で潰しこみが可能なセキュリティ上の課題と言えると考えています。

    シフトレフトの概念

    ここで、IPAから公開されている“セキュリティ・バイ・デザイン導入指南書”より、シフトレフトとセキュリティ・バイ・デザインの重要ポイントを引用する形でその特徴を考察したいと思います。

     

    https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2022/security-by-design.html

    シフトレフトとセキュリティ・バイ・デザインの特徴

    シフトレフト

    セキュリティ・バイ・デザイン

    • セキュリティの確保は上流だけではなく、下流工程におけるセキュリティの対策の実施も重要である
    • シフトレフトは後工程で実施するセキュリティ対策を前工程に単純にシフトするのではなく、本質は発生原因の根本解決である
    • セキュリティ・バイ・デザインとは、脆弱性に対して上流工程で先手を打つこと
    • セキュリティ・バイ・デザインにより、ソフトウェアの「信頼性の向上」「コスト削減」「保守性の良いシステムが開発できる」が得られる

     

    私はこの比較から、シフトレフトは“過去発生した脆弱性を根本解決する施策”、セキュリティ・バイ・デザインは“潜在的な脆弱性に対して先手を打つ施策”と考えました。さらに、シフトレフトの特徴を開発者視点とセキュリティベンダ視点で比較するとどうでしょうか。

    視点別のシフトレフトの特徴

    開発チーム視点のシフトレフト

    セキュリティベンダ視点のシフトレフト

    • 開発チームに過去発生した脆弱性の発生原因を根本的に解決する施策
    • セキュリティベンダが過去発見した脆弱性の発生原因を根本的に解決する施策
    • 開発チームから見ると、過去発生していない潜在的な脆弱性に対して先手を打てる可能性がある

     

    セキュリティ診断サービスによって日々脆弱性を発見しているセキュリティベンダ視点のシフトレフトは、開発チームから見ると、セキュリティ・バイ・デザインの施策にもなりうることに気がつきます。過去のサービス提供実績件数

    セキュリティ診断サービスで培ってきた経験を活かした弊社のシフトレフトセキュリティ施策には、シフトレフトとセキュリティ・バイ・デザイン両方の特徴が含まれています。

    シフトレフトセキュリティの価値検証(PoV)のススメ

    セキュリティ診断サービスで発見される脆弱性の特徴は、開発チーム、開発プロジェクトによって様々です。また、開発方式(ウォータフォールやアジャイル)によっても特徴が異なることがあります。

     

    弊社のシフトレフトセキュリティは、セキュリティ診断サービスにおけるシステムの評価観点を「要件定義・設計」と「実装」工程の観点に分割したうえ、セキュリティ設計評価サービスでは「要件定義・設計」工程の観点で、ツール診断サービス(SAST/IAST/DAST)では「実装」工程の観点で脆弱性をつぶしこむことによって、システム開発におけるコスト抑制とリリース遅延の防止に効果的です。さらに、開発チームの皆さまと一緒にセキュリティ設計を行う設計支援サービスも提供可能です。

     

    まず、セキュリティ診断サービスの報告書から脆弱性が作りこまれた原因を分析し、みなさまの開発現場に適したシフトレフト施策を価値検証する取り組みをお薦めしています。

    自社に適したシフトレフトセキュリティの価値検証(PoV)のススメ

    自社に適したシフトレフトセキュリティの価値検証(PoV)のススメ

    弊社のセキュリティ診断サービスをご採用いただいているお客様も、他社のセキュリティ診断サービスをご利用されている皆さまも、シフトレフトセキュリティについてお悩みの際にはぜひお声がけください。

    おわりに

    弊社では、お客様の開発チームをセキュリティでご支援するSec Team Servicesに力を入れています。また、外部講演資料も公開していますので、みなさまのご参考になれば幸いです。

     

    SEC Team Services

     

    【7/23-24開催】Developers Summit 2024 Summerに登壇

     

    Speaker Deck「先進事例から学ぶ DevSecOpsでセキュリティに取り組むコツ」「ライブラリとの上手な付き合い方」(https://speakerdeck.com/sekido)

     

    最後に、シフトレフトセキュリティ事業の採用活動も行っています、関心がある方のご応募もお待ちしています。

    シフトレフトに携わるコンサルタントへのインタビュー:平柳 俊一郎
    NRIセキュア セキュリティコンサルタント職種詳細