セキュリティ コミュニティは、サイバー脅威に対して世界をより適切に配置するために、継続的に変化し、成長し、互いに学び合っています。最新の Voice of the Community ブログ シリーズの投稿では、マイクロソフト プロダクト マーケティング マネージャーのNatalia Godylaが、Banco Santander のセキュリティ リサーチのグローバル ヘッドであるDaniel Cuthbertと対談しています。 Daniel は、アプリケーション セキュリティ テストとテスト標準を使用してセキュリティを向上させる方法について説明します。
ナタリア: アプリケーション セキュリティ テストとは何ですか? また、その内容は何ですか?
Daniel : たとえば、従来のレガシー バンキング アプリケーションがあるとします。ユーザーは Web ブラウザーを使用してサインインし、財務の詳細や資金にアクセスしたり、お金を移動したり、お金を受け取ったりできます。通常、そのタイプのアプリケーションに対してアプリケーション評価を行う場合は、認証と承認のプロセス、アプリケーション アーキテクチャの仕組み、データの処理方法、およびユーザーがそれを操作する方法を調べます。アプリケーションが、バックエンド データベースと対話する単一のアプリケーションからマイクロサービスへと成長するにつれて、データを移動およびインストールするすべての方法 (およびプロセス) がより重要になります。
一般に、アプリケーション テストでは、誰かがデータや他人のお金に不正にアクセスできないことを確認します。また、許可されたユーザーが別のユーザーになりすましたり、他人の資金にアクセスしたり、アーキテクチャ内のシステムに開発者やエンジニアが予想もしなかったようなことをさせたりできないようにしたいと考えています。
Natalia: Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS) とは何ですか? また、組織はこの標準をどのように使用する必要がありますか?
Daniel : ASVS は Application Security Verification Standard 1の略です。そのアイデアは、人々がアプリケーション セキュリティテストを実施し、受け取る方法を標準化することでした。それ以前は、方法論はありませんでした。業界には多くの曖昧さがありました。 「アプリのテストが必要です」と言うと、選択した会社には方法論があり、評価を行う人は方法論に従うことができます。
実際には、そうではありませんでした。それは、さまざまな侵入テスト機関によって異なりました。侵入テストとアプリケーション テストのコンサルティングを受けた人は、何をテストする必要があるか、または安全で堅牢なアプリケーションを構成するものについて構造化された考えを持っていませんでした。そこで ASVS の出番です。これで、「アプリケーション テストが必要です。このアプリケーションのレベル 2 評価が必要です。」テストを受ける人は自分が何を期待しているかを正確に知っており、テストを行う人はクライアントが何を期待しているかを正確に知っています。全員が同じ認識を持つことができ、それが以前は欠けていたものです。
ナタリア:企業は、ASVS のレベルとコントロールにどのように優先順位を付け、ナビゲートする必要がありますか?
ダニエル: 初めて ASVS を見たとき、多くの人が怖くて圧倒されてしまいます。まず、落ち着いてください。ガイドラインとして 3 つのレベルがあります。レベル 1 は、最低限の絶対値である必要があります。アプリケーションをインターネット上に置く場合、それが遊びの入り口であり、レベル 1 を自動化できるように設計しようとしています。レベル 1 を自動化するためのツールに関しては、OWASP Zed Attack Proxy (ZAP) がそこに到達しています。 2021 年には、特にプライバシーを考慮した場合、アプリケーションはレベル 2 になるはずです。レベル 3 はユニークです。ほとんどの人はレベル 3 を必要としません。レベル 3 は、クリティカルでセキュリティの必要性が高いアプリケーション向けに設計されたものです。レベル 3 がダウンすると、人命の損失や多大な影響が発生します。レベル 3 は費用と時間がかかりますが、たとえば発電所の場合はそれが予想されます。数時間ですぐに一緒に投げられたくありません。
すべてのレベルで、すべてのコントロールを通過する必要はありません。ここで、 脅威モデリングの出番です。アプリケーションでバックエンド データベースを使用し、マイクロサービスを使用している場合は、レベル 2 から必要な部分を取得して、テスト プログラムを構築します。多くの人は、すべてのコントロールをテストする必要があると考えていますが、そうではありません。必要なだけカスタマイズする必要があります。
ナタリア:アプリケーションのセキュリティ テストを実施するための適切な頻度は?
Daniel : アプリケーションの構築方法は劇的に変わりました。 10年前は「靴を売るウィジェットを作りたい」など機能仕様を使ったウォーターフォール型のアプローチをしている人が多かったです。偉大な。誰かが彼らにお金と時間を与えます。開発者は開発を進め、最後に機能的なユーザー受け入れテスト (UAT) を開始し、誰かに侵入テストを実施してもらいます。史上最悪のミス。私の経験では、月曜日に稼働し、侵入テストはその前の週に行われました。
アジャイルの採用で私たちが目にしたのは、ソフトウェア開発ライフサイクル(SDLC) の左側へのシフトです。セキュリティを最終的なアドオンとしてではなく、機能の一部として考える人が増えています。アプリが安全で、使いやすく、堅牢であることを期待しています。私たちはセキュリティ基準を採用しています。継続的インテグレーションと継続的デリバリー パイプラインにガードレールを採用しています。つまり、開発者は関数を作成し、コードを Git などのリポジトリにチェックインし、コードが堅牢で、正しくフォーマットされ、安全であることがチェックされます。業界では、アプリケーションの最終テストに依存することから、ライフサイクル全体を通してバグ、構成ミス、または暗号化やエンコーディングの不適切な使用を常に確認するようになりつつあります。
Natalia :アプリケーションのセキュリティ評価の結果に影響を与える、企業がよく犯す間違いとは?
Daniel : 1 つ目は、企業が脅威モデリングのすばらしい世界を受け入れていないことです。脅威モデルは時間を節約し、方向性を示します。人々が脅威モデリングの基本的な段階を回避すると、サイクルが燃えています。脅威モデルを採用し、「これは悪意のある人物が私たちのお気に入りのウィジェット ツールを破壊するすべての方法です」と言うなら、それに基づいて構築することができます。
2 つ目の間違いは、すべてのコンポーネントの機能を理解していないことです。単一の Web サーバー、インターネット インフォメーション サービス (IIS)、またはデータベースに格納される NGINX であるアプリケーションを構築することはなくなりました。今日はめったに見られません。今日のアプリケーションは複雑です。複数のチームがそのプロセスの個々の部分を担当しているため、データ フローなどの単純なことを理解するために全員が協力しているわけではありません。データはどこに保管されていますか？このアプリケーションはそのデータをどのように処理しますか?多くの場合、誰もが他のチームがそれを行っていると想定しています。これは問題です。特に大規模なプロジェクトの場合は、スクラム マスターまたはプロダクト オーナーのいずれかがアプリケーションの完全な可視性を所有する必要があります。ただし、組織によって異なります。私たちは、それが定義された役割になるにはまだ十分に成熟した段階ではありません.
また、セキュリティと開発の間のギャップは依然として広すぎます。セキュリティは多くの友達を作りませんでした。私たちは常に開発者を軽視していました。私はその一部であり、私たちは間違っていました。現在、私たちは 2 つのチームの橋渡しを試みています。セキュリティが開発者を助けようとしていることを開発者に理解してもらいたいのです。
コード パイプラインによくある間違いが発生しないようにガードレールを設定しながら、開発者が期待どおりにクリエイティブでクールになる方法を構築する必要があります。 安全なコードを書くのは非常に難しいですが、第 4 世代の継続的インテグレーションと継続的デリバリー (CI/CD) を受け入れることができます。コードをチェックインしてください。その後、一連のテストを行います。その時点で、そのコミットで、コードが堅牢で、安全で、適切であることを確認してください。
Natalia :脆弱性から保護するために、セキュリティ チームは開発者とどのように連携する必要がありますか?
Daniel : 開発者が最新の脆弱性をすべて理解しているとは思いません。それがセキュリティまたはセキュリティ エンジニアリング チームの役割です。チームが成熟するにつれて、セキュリティ エンジニアリングまたはセキュリティ チームが橋渡し役として機能します。彼らは脆弱性とそれがどのように悪用されるかを理解し、それを人々が組織のコードを構築する方法に変換します。また、これらの脆弱性が問題になるのを防ぐために活用できるさまざまなツールやプロセスも検討しています。
私が GitHub で見始めている本当に素晴らしいことの 1 つは、 GitHub インサイトです。何千ものリポジトリを持つ大規模な組織があるとします。これらすべてのリポジトリを見れば、脆弱性の一般的なパターンが見られるでしょう。セキュリティに「マイノリティ・リポート」風の機能を持たせる段階に来ています。
毎月、「バグをチェックインしているチームを見せてください。デシリアライゼーションとしましょう。」と言うことができます。大きな問題になる前に問題を理解し、それらのチームと協力して、「最後の 10 個の引数のうち 4 個は、デシリアライゼーションのバグに対して脆弱であるとフラグが付けられました。座って、どのように構築しているか、何を目指して構築しているか、どのフレームワークを採用しようとしているのかを理解しましょう。脆弱性から保護するためのより良いツールを作成できますか?脆弱性自体を理解する必要がありますか?」ツール、パイプライン、および教育はそこにあります。私たちはその架け橋になり始めることができます。
もっと詳しく知る
Microsoft セキュリティ ソリューションの詳細については、 当社の Web サイト を参照してください。セキュリティ ブログをブックマークして、セキュリティに関する専門家の記事を入手してください。また、 @MSFTSecurityをフォローして、サイバーセキュリティに関する最新ニュースと更新情報を入手してください。
1OWASP アプリケーション セキュリティ検証標準、OWSAP。
Comments