2020/7/24 - 読み終える時間: 3 分

DNS に関するセキュリティーテストの解説記事 Hey, DNS! (with HCL AppScan Domain Name Server) の翻訳記事です。

翻訳者注: 本記事は技術的詳細内容が含まれています。技術者による翻訳文の妥当性確認は行っていません。不明点等がある場合は、恐れ入りますが原文を参照願います。

Hey, DNS! (HCL AppScan Domain Name Server の利用)

2020年7月22日

著者: Shahar Sperling / Chief Architect at HCL AppScan

昔々、「動的解析」は「ブラックボックステスト」と呼ばれていました。昔の名前（Black-Box、White-Box、Glass-Box...）が懐かしいです。新しい名前には素敵な頭字語（DAST、SAST、IASTなど）が使われていますが、その名前は、その作業方法についての説明力としては不足しています。あるタイプのテストや別のタイプのテストを実行するときに直面する課題は、名前がテストオプションが実際にどのように動作するかを説明しているとはほど遠いことです。

Black-Box は、テスト対象を「ブラックボックス」として扱っていることを非常に明確に伝えています。中を見ることはできません。あなたは、ブラックボックスがあなたに公開することを選択したものだけに頼ることができます。私たちがテスト攻撃を実行するとき、アプリケーションが攻撃に対してどのように反応するかを「リフレクション」と呼びます。テストが成功したかどうかを示すのは、リフレクションの欠如であることがあります。

このリフレクションへの依存は、DAST が直面している大きな課題の 1 つです。これは、検出できる問題の種類を制限する要因となっています。いくつかのテストは、即時の応答(またはそれに続く一連の要求に対する応答)を作成し、それらはDASTが発見できる問題です。テストの中には、WebApp の実行フローを混乱させるように設計されているものもあります (意図的に反映の失敗を引き起こす) が、これらも DAST が検出できる問題です。

それ以外はどうでしょうか？

非同期検証メカニズムテストの影響

他のすべてではないかもしれませんが、数年前に導入された非同期検証メカニズムは役に立ちます。これらのテストの背後にある考えは、直接的なリフレクション (あるいはその欠如) に頼るのではなく、アプリケーションの他の外部から観測可能な動作に頼るということです。

これはどこで役に立つのでしょうか？例えば、コマンド実行のテストをするときです。私たちは、以下に説明されているアクションの一つを実行するコマンドを実行しようとします。これらのコマンドは、実行中のアプリケーションのコンテキストの外で実行され、多くの場合、それらに関連したレスポンス（例えば、HTMLへの直接的なリフレクション）がありません。通常の状況では、DAST スキャナはこれらの脆弱性を検出することはできません。

最初のクラスのテストでは、AppScan スキャナ自体に組み込まれた Web サーバーへの HTTP リクエストをトリガーしようとします。AppScanは、テストされたサーバーに特定のURLへのHTTPリクエストを開始させようとしますが、これは攻撃源を理解するのに役立ちます。また、外部ファイル挿入の脆弱性の検出も向上します。

ペイロード部分: http://:/AppScanMsg.html?varId=＜attack_id＞ (山括弧は意図的に全角にしています)

ここで、appscan_ip と port は、スキャナが実行されているマシンの IP と組み込み Web サーバーのポートです。attack_id の値は、送信された実際の攻撃を識別します。

これらのテストは非常に高い精度を持っていますが、失敗しやすいです。多くの場合、ネットワークのセグメンテーションにより、これらの要求がそもそも AppScan に到達しないようになっています。HTTP リクエストは実際にはサーバーによって生成されますが、その後、ネットワーク自体のファイアウォールやセグメンテーションルールによってブロックされることがあります。これはラボやステージング環境では非常に一般的です。ネットワークセグメントへのアクセスは許可されていても、セグメント内のマシンはセグメント外で HTTP トラフィックを生成することはできません。

HTTP トラフィックはエスケープできないかもしれませんが、DNS の性質上、DNS リクエストはそれがよく起こりえることです。そのため、第二のクラスのテストを含めることにしました。最初のテストと同様に、これらのテストはリクエストをトリガーしようとします。しかし、新しいテストでは、組み込みサーバーへの DNS ルックアップをトリガーしようとします。

DNS は連鎖したプロセスです。ある DNS サーバーがホスト名を IP に解決できない場合、接続されている他の DNS サーバーでそのホスト名を探そうとします。DNS リクエストは、ファイアウォールやゲートウェイ、その他のネットワークメカニズムによってブロックされることはほとんどありません。

その結果は高い精度で非常に良いのですが、キャッチがあります。多くのマシンでは、組織のポリシーにより、特定の DNS リゾルバへのルックアップを実行できません。これは、スキャナ内蔵の DNS サーバーをマシン上で設定しなければならないことを意味します。これは問題です。

解決策は、自動的に認識される DNS サーバーを作成することです。

AppScanドメインネームサーバー（ADNS）の導入

ADNS - AppScan Domain Name Server のご紹介です。オープンなインターネット上に鎮座するクラウドベースのサーバーで、インターネットベースのDNS サーバーを利用できるマシンであれば誰でもアクセス可能で、利用できるようになっています。これは、世界中のコンピュータの大多数を構成しています（物理的にインターネットに接続されていないコンピュータを除く）。HTTP トラフィックが遮断されている環境や、ファイアウォールによって遮断されている環境でも、通常は DNS トラフィックを通過させることができます。

その結果、テストの仕組みは次のようになります。

• ステップ 1: クラフトされたホストへのペイロードを持つ攻撃を作成する。

• ステップ2: テストされたサーバーはこのホスト名を調べる。

• ステップ 3: ADNSはこのルックアップの記録を受信して保持する。

• ステップ 4: AppScanは、ルックアップが行われたかどうかをADNSに問い合わせる。

シンプルさを維持し、ステップ 4 が成功することを確実にするために、DNS ルックアップを使用してクエリも行われます。そのため、インターネットへの直接アクセス（HTTPアクセス）がないAppScanインスタンスでも、DNS ルックアップが成功する確率が非常に高いため、このメカニズムを使用することができます。

前述したように、DNS の検索は細工されたホスト名に対して行われます。ホスト名は次のように構成されています。

vX-ping-＜variant_id＞-＜scan_GUID＞.securityip.appscan.com (山括弧は意図的に全角しています)

• securityip.appscan.com / securityip.appsechcl.com - これらは ADNS 自体を参照しています。この記事は「appsechcl」から「appscan」への移行期に書かれています。どちらかの名前が出てきます。この記事の目的のために、私は "appscan.com "を使用しています。
• variant_id - 特定の攻撃を識別するID
• scan_GUID - 特定のスキャンを識別するID。バリアントIDは1回のスキャンでは一意ですが、グローバルに識別可能なIDのためには、ランダムなスキャンIDも必要です。
• X - これは AppScan プロトコル(スキャナと ADNS 間の交換)の内部識別子です。

ペイロードは次のようになります。

v3-ping-11345?b697b0fb-06f5-4aab-a8d5-1867c7daa8c5.securityip.appscan.com

• 3 - 現在のプロトコルのバージョン
• 11345 - バリアント ID は送信された元のテストを識別します。
• b697b0fb-06f5-4aab-a8d5-1867c7daa8c5 - グローバルに一意なインスタンス ID。

ADNS はこれらのルックアップを待っており、それらの記録を保持しています。ADNS は解決されたホスト名 (例えば、ソースIP/ポート) 以外のものを保持しませんし、 リクエストの発信元を特定する方法もありません。ADNS はその後、次のように見える別のルックアップを待ちます。

v3-query-11345-b697b0fb-06f5-4aab-a8d5-1867c7daa8c5.securityip.appscan.com

これは、AppScan スキャナが生成するルックアップです。この名前を解決すると、ADNS IP アドレスまたは NXDOMAIN (Non-Existent Domain) が返されます。これは攻撃の検証段階です。サーバーが有効な IP アドレスを返す場合、攻撃は成功しています。そうでない場合、AppScanはテストされたアプリケーションが脆弱性がなかったことを登録します。

AppScan は様々なテストで ADNS を使用します。明らかなのはコマンド実行シナリオでの直接検索です。しかし、他のタイプのテストでも恩恵を受けることができます。例えば、リモートファイルインクルージョンです。古典的な DAST の検証は、アプリケーションを騙して、レスポンスの中に検出できる外部コンテンツを埋め込むように試みます。ADNS を使用して、外部 URL に ADNS ドメインを含めることができます。コンテンツは埋め込まれませんが、アプリケーションは少なくともホスト名を解決する必要があり、これが脆弱性の証明となります。

ADNS は、非リフレクションテストの精度の飛躍的な向上を表し、AppScan が検出するために使用できる脆弱性の種類の全体的な数を増やします。

私たちはこれを常に喜んでいます。

詳細

ADNS の詳細については、HCL Software に連絡してデモを予約してください。

2020/7/23 - 読み終える時間: 2 分

継続とは習慣であり文化であり、それがない状態から変えていくことは難しいものです。特に組織においては。アプリケーションのセキュリティー維持について「継続性」をテーマにした英語版ブログ AppScan ? It's Time For Security To Be Continuous Too の翻訳版です。

AppScan - そろそろセキュリティも継続的に行う必要があります

2020年7月22日

著者: Rob Cuddy / HCL

継続的であること (Continuous)。

DevOps に長く携わっている人なら、この言葉を聞いたことがあるでしょう。これは、私たちがやろうとしていることの本質です。継続的という言葉は、ほぼすべての能力領域を説明するために使われています。考えてみてください。Continuous Integration、Continuous Build、Continuous Deployment、Continuous Testing、Continuous Delivery、Continuous Monitoring などを考えてみてください。

しかし、まだ追いついていない分野があります。

今日では、個人情報とデータのプライバシーがこれまで以上に重要になっており、特にオンラインでのやり取りが増えています。データの収集と使用に関する規則がより厳しくなり、GDPR、NYDFS、CCPA などの規制により、アプリケーションのセキュリティの向上が求められています。そして、これらの規制は違反者に深刻な結果をもたらします。

これはすべて、継続的なセキュリティが前面に出てきていることを意味しています。しかし、継続的セキュリティとは何でしょうか？

継続的セキュリティとは何か

オンライン検索をすると、ほとんどの議論は、セキュリティテストをパイプラインに統合することと、フィードバックを提供することの 2 つの主要なアイデアに焦点を当てていることがわかります。さらに、これらの活動を開発者が利用しやすい方法で実施することについても議論されています。この 2 つの分野は、DevSecOps の主要な構成要素でもあります。しかし、デプロイを自動化することが DevOps を行うことと同じではないのと同じように、パイプラインでテストを実行してレポートすることは継続的セキュリティではありません。

継続的セキュリティとは、それ以上のものであり、対処すべきいくつかの異なる能力領域があり、それらのすべてがパイプラインでの開発と一致しているわけではありません。実際、私たちは、大きな違いをもたらす6つの能力があることを発見しました。私たちは、これらを3つのテーマ分野に整理しました。これらのテーマとカテゴリは以下の図 1 のとおりです。

図 1：継続的セキュリティのテーマ

重要な継続的セキュリティテーマ

この短いブログシリーズでは、テーマごとに順番に深く掘り下げていきます。今のところは、これらの領域とその意味を紹介します。

Construct は、想像できるかもしれませんが、私たちがどのように物を作っているかを最も直接的に扱っています。2 つの機能には、Design と Automate というラベルが貼られています。設計では、最初から、そして SDLC 全体を通して、セキュリティを含むという概念を伝えたいと考えています。これには、計画、モデリング、優先順位付けなどが含まれます。自動化機能は、ほとんどの人がDevOps や DevSecOps で始めるところですが、自動化は、単に規定の方法でテストを実行するだけのものではありません。それには、動作や意思決定も含まれます。

Intensity (強化) この分野では、自分たちが行っていることをいかにしてより良いものにするかということがすべてである。集中化は、最適化に必要なプロセス、手順、学習に対処するのに役立ちます。教育能力は、コードの品質だけでなく、見積もりやトレードオフの決定を継続的に改善するために必要です。教育は、次のような疑問に答えるのに役立ちます。「チームが成功できるようにするにはどうすればいいのか」という質問に答えるのに役立ちます。Govern 機能は、データを効果的に動かし、自信を持って意思決定を行うことを可能にします。Govern は、プロセスを検証し、ポリシーとプロジェクトのバランスをとることで、生産性を向上させることができます。

Assure この領域は、SDLC 全体に影響を与える、より良い、より情報に基づいた意思決定を行うために、持っているデータと情報を使用することがすべてです。監査と測定の機能は、ビジネスを推進するためにデータを活用することを目的としています。例えば、監査では、ペンテストチームからの情報が開発者のバックログに入っていませんか？ 測定を行う際に、リスク管理に最大の利益をもたらす主要な測定基準と測定方法は何かを知っているだろうか？ これらの能力は、リスクとスピードのバランスが取れているかどうかを判断するのに役立ちます。

これらの各分野については、別のブログでさらに深く掘り下げていきますので、ぜひシリーズをお読みいただき、ご意見をお聞かせください。また、Brighttalkでの最近のウェビナーをご覧いただくか、Buzzsprout、Apple Podcasts、Spotify、Google Podcasts でご覧いただけるApplication Paranoia PodcastのEpisode #7をお聴きいただくことで、Continuous Security に関するコメントについてより多くの考えをお聞きいただくことができます。

2020/7/22 - 読み終える時間: 2 分

非公開のプライベートサイトのセキュリティーサイトをチェックしたいが、クラウドのセキュリティーサービスを使いたい。そんな場合でも、AppScan on Cloud が使えます。Achieve Private Site Scanning with AppScan on Cloud の翻訳記事です。

AppScan on Cloud でプライベートサイトのスキャンを実現

2020年7月17日

著者: Shahar Sperling / Chief Architect at HCL AppScan

その名の通り、HCL AppScan on Cloud (ASoC) はクラウドベースのサービスです。ASoC は、組織のネットワークの外に存在する Web アプリケーション・ダイナミック分析セキュリティ・スキャナを特長としています。

ASoC は、一般に公開されているWebアプリケーションを簡単にスキャンすることができます。しかし、開発アプリケーションやテストアプリケーションは、通常、組織内に配置され、ファイアウォールの後ろやラボ内に配置されています。これらのアプリケーションをスキャンするには、プライベートサイトスキャン (PSS) を使用する必要があります。

クラウドからプライベートサイトスキャンを実現する方法

VPN やプロキシなどのネットワーク・コンポーネントを追加したり、ネットワークを変更してスキャナが組織のネットワークにアクセスできるようにすることは明白ですが、手間がかかり、コストがかかる解決策です。このアプローチは理想的ではなく、CIO や IT セキュリティチームからは敬遠されています。

ASoC PSS ソリューションは、特別なハードウェアを必要とせず、ネットワークに変更を加える必要もありません。ASoC PSS クライアントはネットワークにセットアップされ、必要なのはインターネットへの発信アクセス（直接またはプロキシ経由）とスキャン対象のサイトへのアクセスのみです。このクライアントは、組織内のどのマシンにもインストールでき、比較的少ないリソースで済みます。

PSS は、録画プロキシなどの機能を提供する AppScan Presence パッケージの一部で、ASoC サービスからの指示を受信するためにこのサービスを使用します。

ASoC PSS は、安全な（TLSで暗号化された）TCP/IPトンネルを作成する2つのエンドポイントで構成されています。

• トンネル・サーバ・エンドポイントは、スキャナと並んでクラウド・ネットワークに存在します。このエンドポイントは、スキャナが生成したリクエストを受信し、トンネルを通ってクライアントに転送します。
• トンネルクライアントエンドポイントは、トンネル接続を開始します。これは、組織内でインターネットへの発信接続が簡単に許可されてしまうため、ネットワークの制限を回避するための鍵となります。クライアントは、サーバーからトンネルを下って送られてきたトラフィックを受信し、テストしたアプリケーションに転送します。レスポンスは、逆に同じ旅をします。

ASoCで、テスト済みアプリケーションをPSSとしてマークし、使用する AppScan Presence の場所を選択します。その後はすべて自動で行われます。

ASoC PSS でのセキュリティに関する考察

ASoC はセキュリティスキャンを可能にするため、ASoC PSS ソリューションの開発と実装では、セキュリティへの配慮が鍵となりました。ASoC の開発者は、お客様のネットワークのセキュリティとトンネル接続のセキュリティに焦点を当てました。

前述の通り、PSS はお客様のネットワークに変更を加える必要はなく、PSSトンネルクライアントが特別な譲歩を要求することもありません。これにより、PSS トンネルクライアントを実行しているホストマシンに組織的なセキュリティポリシーを適用することができます。さらに、特定のポートや IP アドレスでの着信接続を許可するなど、組織的なファイアウォールに変更を加える必要はありません。

各 Presence インスタンスには、その ID となる一意のキーがあります。このキーは Presence インスタンスを識別するために使用され、正しいスキャン タスクを提供します。キーはいつでも更新できるため、定期的な更新が必要な組織のセキュリティポリシーにも対応できます。サーバー上でキーが更新されると、プレゼンス インスタンスは、キーが物理的にプレゼンス マシンに置かれるまで、タスクの受信を停止します。

PSS レベルで接続を安全にするためには、トンネル サーバーとトンネル クライアントがお互いを信頼して、検証されていない場所からプライベート ネットワークへの外部からのアクセスを防ぐことが重要です。スキャンの実行準備が整い、トンネル サーバーが起動すると、PSS は 2 つの証明書を生成します。

サーバー証明書は、クライアント側の証明書と秘密鍵とともに、スキャン・タスクの詳細とともにトンネル・クライアントに渡されます（プレゼンス・サービスと SaaS サービス間のセキュアな通信を介して）。これにより、トンネル・クライアントとトンネル・サーバは、リモート接続のアイデンティティを検証することができます。証明書はスキャンが完了すると無効になり、再スキャンのためにも再利用されることはありません。

以上のことをまとめましょう。クラウド・プライベート・サイト・スキャンのアプリケーション・セキュリティは、クラウドベースのセキュリティ・スキャナを活用して、組織内に配備されたアプリケーションをシンプルかつ安全な方法でスキャンするメカニズムを提供しています。

詳細

HCL AppScan on Cloud をご自身でテストドライブするには、今すぐ30日間の無料トライアルに登録してください。

2020/7/21 - 読み終える時間: 2 分

Understanding the AppScan on Cloud Compliance Network の翻訳版です。

クラウド・コンプライアンス・ネットワークにおける AppScan の理解

2020年7月15日

著者: Shahar Sperling / Chief Architect at HCL AppScan

組織的なセキュリティを管理する際には、どうしても圧倒されてしまいがちです。アプリケーションのセキュリティは、使用する技術、サードパーティ製のコンポーネント、アプリケーションの配布、ユーザーのアクセスなどの特性によって影響を受けます。セキュリティスキャンの結果を見ただけでは、組織の優先順位を導き出すことは難しいでしょう。

組織のセキュリティを管理するためのアプローチの1つとして、リスク計算のメトリクスを利用することがあります。組織内のアプリケーションごとにリスク特性を定義します。結果として得られるリスクプロファイルは、アプリケーションが脆弱性を発見された場合に組織が被るリスクを示しています。セキュリティ上の問題が識別されると、全体的な結果は、リスクプロファイルのコンテキストにおいて考慮され、結果的に、重要、高、中、または低リスクの評価として、リスクスコアに変換されます。

これで、組織の優先順位を設定して、最も重要なシステムから最も重要度の低いシステムまで、これらの問題に対処することができるようになりました。このアプローチは、組織内で展開され、使用されるアプリケーションによってもたらされるリスクを理解しようとする組織に効果的です。情報セキュリティチームは、組織のリスク評価を行い、ベンダーや内部の開発チームに連絡して改善を求めることができます。

開発チームは、開発中のアプリケーションのセキュリティ状態をどのように判断することができるか

しかし、開発チームはどうでしょうか？開発チームは、特にアプリケーションが商業的に販売されることを意図している場合、開発中のアプリケーションの最終的なデプロイ環境について、ほとんど、あるいは全く考えていないかもしれません。チームは、どのようにしてリスクとセキュリティ関連の作業を管理し、優先順位をつけることができるでしょうか？開発管理者は、開発中のアプリケーションのセキュリティ状態をどのように理解できるでしょうか？この情報は、開発ライフサイクルの管理の一環として、約束をしたり、リリース日をスケジューリングしたりする際に重要です。

アプリケーションの潜在的なセキュリティリスクを計算する

開発中のアプリケーションのリスク計算には情報が必要です。しかし、開発チームが持っているかもしれないし、持っていないかもしれません。リスクを完全に理解するためには、開発チームは追加の基準を必要とします。

完全なアプリケーション・プロファイルを持たないと、開発チームには課題そのものの特性が残ってしまいます。課題には、タイプ、分類、原因、深刻度、場所、最初に発見された日付など、多くの属性があります。チームは、任意の基準に基づいて課題の断面を特定することができ、基準に一致する課題は、解決が必要なものとして、優先順位が付けられた課題となります。

チームがアプリケーションのセキュリティ作業を開始する際には、かなり緩やかな基準を使用することができます。作業が進むにつれて、業界や規制機関が要求する基準に一致することを最終的な目標として、徐々に厳しい基準を設定する必要があります。

例えば、あるアプリケーションを所有しているチームが、そのアプリケーションのセキュリティテストを開始したばかりで、問題の数に圧倒されているとします。チームは、問題を管理し、クリーンで安全なアプリケーションという究極の目標に向かって前進するために、以下の アプローチを取ることができます。

• 指定された日付を超えて新しい問題が発生しないことを指定するベースライン基準を設定する。チームは、ベースライン基準が設定された後は、新しいセキュリティ問題を追加しないことを約束する。チームは、その時点から、セキュリティ関連のタスクのために、良い開発手法を採用する。これにより、新しい問題が日常的に検出され、修正され、 開発サイクルの間に導入される問題が全体的に少なくなるようになる。
• すべての開発がベースライン基準を満たしたら、新たな重要度基準を設定し、 重大度の高い問題は許可しないことを指定する。ここで、チームが解決すべき、新たな課題セットが基準を形成される (古い、重大度の高い課題)。
• これらの問題がクリアされると、チームは OWASP トップ 10 や SANS トップ 25 のような業界標準に準拠することを選択でき（または義務づけられる） 、それらの標準に登場するすべての問題を解決することを約束する。
• 将来の基準の約束は、FedRAMP や HIPAA、あるいは「問題ゼロ」であってもよい。

逐次的な基準を設定することは、近づきやすい目標を設定するだけでなく、アプリケーションの集合体に対 して偏りのないステータスビューを作成することにもなります。各アプリケーションが同じ基準で測定されるリスク計算とは異なり、コンプライアンスステータスでは、各アプリケーションは、その特定の特性や特性に適した異なる基準を持っています。重要なのは、アプリケーション（とチーム）がコミットされた基準を満たしているかどうかであり、各チームは異なる成熟度レベルにある可能性があり、すべてのアプリケーションが異なる基準を遵守することが要求される可能性があることを理解しています。

詳細

HCL AppScan on Cloudをご自身でテストドライブするには、今すぐ30日間の無料トライアルに登録してください。

2020/7/20 - 読み終える時間: 2 分

サードパーティーのコンポーネントが入っていないソフトウェアが今どきあるでしょうか。開発する側として、サードパーティーの安全性をどうやって担保すればよいのでしょうか。「サードパーティー製だったので気づきませんでした」は言い訳にならないでしょう。開発の利便性が高まる一方で、セキュリティー対策、特にサードパーティーコンポーネントに関することがますます重要になってきています。今回は Third-Party Component Security: The Good, The Not So Good and the Downright Ugly の翻訳版を掲載します。

サードパーティ・コンポーネント・セキュリティ。良いこともあれば、そうでないこともあるし、ひどいこともある。

2020年7月16日

著者: Shahar Sperling / Chief Architect at HCL AppScan

サードパーティのコンポーネント、特にオープンソースは、現代の開発努力として欠かせないものです。これらのコンポーネントは開発を加速させ、チームがコア技術のコード開発に集中できるようにしてくれます。

それはそれで良いことでしょう。

サードパーティ製コンポーネントを採用する際の課題は、コンポーネントの動作やセキュリティの問題も取り込まれることです。

挙動上の問題は通常、すぐに発見されます：コンポーネントの機能が使用されるにつれて、障害や予期せぬ結果が発見されます。挙動上の問題は、OO コミュニティによって回避したり、報告したり修正したりすることができます。

セキュリティの問題は発見しにくい

しかし、セキュリティ問題の場合はもう少し複雑です。なぜなら、セキュリティ問題を発見するのは予想外の使用方法であり、ほとんどの開発チームはセキュリティ上の欠陥を発見するために必要な固有のスキルを持っていないからです。脆弱性は、アプリケーションによって使用される機能に発生する可能性があります。しかし、多くの脆弱性は、コンポーネントによって公開されているが、アプリケーションによって使用されていない機能に悪用される可能性があります。このため、リモートの攻撃者によって悪用される可能性のあるコンポーネントが Web アプリケーションやモバイルアプリケーションで使用されている場合、脆弱性は特に危険なものとなります。

これはあまり良くないですね。マズいことです。

サードパーティ製のコンポーネントに脆弱性が確認されると、アップデートがリリースされます。これは完全に標準化されており、期待されていることです。しかし、あるコンポーネントがアップデートを提供したからといって、そのコンポーネントを使用するすべてのアプリケーションでアップデートが行われたとは限りません。

これは、物事が悪いだけではなく、醜いものになってしまうところです。サードパーティのコンポーネントのパッチが適用されていないことが原因で、ヘッドラインに載りたい人はいないでしょう。

チームは喜んでサードパーティ製の、ほとんどがオープンソースのコンポーネントを採用しますが、コンポーネントの迅速なアップデートには備えていません。私たちは自分のコードにコンポーネントを入れても、それを忘れてしまう傾向があります。結局のところ、自分のところで書いたコードには注意は払われるけれど、サードパーティ製のコンポーネントを採用している、ということで、サードパーティ製のコンポーネントについて関心が払われていないのが実際ではないでしょうか。

サードパーティ製のコンポーネントに対処しなかった場合の現実的な結果

数年前、世界は Equifax の大規模な侵害とその後の余波にさらされました。2017年5月から7月にかけてサードパーティ製のコンポーネントに悪用された脆弱性は、早くも2017年3月に報告されていますが、Equifax 内ではすぐに対処されていませんでした。

迅速なアップデートに備えることは重要ですが、迅速なアップデートは本質的に緊急性が高く未知の要素であるため、通常のプロトコルの一部として無視されがちです。ほとんどのチームにとって、深刻な脆弱性が原因で初めて更新を余儀なくされた場合、それはパニック状態の緊急事態になりますが、本来は日常的な準備訓練の一環であるはずです。

訓練の実行を恐れる必要はありません。訓練を実施する理由は準備を整えるためです。訓練を実施することで、緊急アップグレードが発生したときに、より良い対応をするためのスキルや考え方を身につけることができます。開発者が、自前のコードとサードパーティコードの間のすべてのインターフェイスと依存関係を理解していることを確認してください。これらの依存関係をチェックするためのテスト環境を準備しておけば、変更が必要になったときに、迅速かつ自信を持って変更を行うことができます。

アプリケーションが危険にさらされているかどうかは、どのようにして見分けることができるのでしょうか？

これで、サードパーティ製コンポーネントのセキュリティに関する一つの課題が解決されました。しかし、そもそもセキュリティ問題を特定することについてはどうでしょうか？アプリケーションが危険にさらされていることを知っていますか？そして、それらの兆候を可能な限り迅速に得るにはどうすればよいでしょうか？

動的解析には、長い間、公表されているサードパーティの脆弱性を特定するテストがありました。これらのテストは、ベンダによって公開された CVE を識別するテストエクスプロイトを実行するために、動的解析 (DAST) 技術を使用しています。しかし、脆弱性のためのエクスプロイトを作成するには長い時間がかかるかもしれません。しかし、ハッカーが先にエクスプロイトを作成するまで待ちたくはないでしょう。

HCL AppScan on Cloud (ASoC) では、ASoC Open Source Analyzer (OSA) を作成しました。OSAは、ASoCの静的解析ツールを活用して、プロジェクトが依存しているすべてのサードパーティ製コンポーネントのシグネチャを生成します。これらのシグネチャは ASoC サービスにアップロードされます。OSAはアプリケーション内の特定の暴露を示すのではなく、コンポーネントが脆弱性を持っており、何に対して脆弱であるかを示します。

それがどのように役立つのでしょうか。サードパーティのオープンソース・コンポーネントの新バージョンがリリースされると、ライブラリのシグネチャが作成され、保存されます。コンポーネントに対する脆弱性が報告されると、OSAは即座に認識し、その脆弱性はコンポーネントのシグネチャに関連付けられます。静的解析またはオープンソース解析がビルドパイプラインに統合され、スキャンが継続的に実行されている場合、コンポーネントとその特定のバージョンが脆弱であることを示すゼロデイ表示が表示されます。これは、エクスプロイトがまだ利用できない場合でも発生します。これにより、ハッカーを先回りしてアプリケーションが安全であることを確認することができます。

最近まで、OSA は静的解析スキャンの一部としてしか利用できませんでした。AppScan on Cloud では、OSA のみのスキャンを作成できるようになりました。これにより、オープンソースのスキャンを実行する際の応答時間がさらに向上します。アプリケーションが安全であることを確認しながら、開発を加速することができます。また、誤った理由でヘッドラインに載ることもありません。

これは良い状況です。

詳細

HCL AppScan on Cloudをご自身でテストドライブするには、今すぐ30日間の無料トライアルに登録してください。

2020/7/14 - 読み終える時間: ~1 分

AppScan の動的分析 (DAST) においてはポリシーが大きな役割を果たしています。ポリシーの調整が効果を高める結果となります。どのようにそれを実現すべきかについて英語版ブログに How to Maximize the Effectiveness of Your Dynamic Testing Policies がポストされました。この翻訳版を掲載します。

ダイナミック・テスト・ポリシーの活用を最大化する方法

2020年7月13日

著者: Shahar Sperling / Chief Architect at HCL AppScan

さまざまな種類のポリシーが企業のセキュリティ管理とセキュリティ評価を統制しています。これらのポリシーは、スキャンの結果をどう処理するか、またはどのように処理するかを定義しています。

しかし、何をスキャンするか、いつスキャンするか、どのようにスキャンするかを定義する他のポリシーもあります。What がすべてであるべきです。When はリリース要件によって管理されており、スケジュールを立てることができます。How はもっと複雑です。

How は通常、速度、完了、最適化などの異なる目標を達成するための設定や設定のセットです。静的分析 (SAST) を実行するとき、設定は、スキャナがアプリケーションコードをよりよく「理解」するのを助けることができます。例えば、カスタムサニタイザーや特定の関数の汚れの伝播状態を定義することで、ノイズが少なく、より正確な結果が得られます。動的解析 (DAST) では、ナビゲーション パラメータや冗長性チューニングを定義することで、スキャナがアプリケーションでの役割を「理解」し、それらを正しく処理できるようにします。

スキャンの設定は継続的に改善され、手動でポリシーを設定する必要性が減ります。SAST では、インテリジェントコードアナリティクス (ICA) を導入し、特定の関数や API の役割をほとんど自動的に識別できるようにしました。動的解析 (DAST) では、DOM 比較メカニズムを使用して、ハードリミットや複雑な冗長性チューニングなしでスキャンを最適化します。

静的ではなく動的に

もう一つのポリシーがありますが、それは How の一部ですが、少し違います。それは、アプリケーションをテストするときにどのルールを使うかを定義するものです。ここでは特に DAST ルールについて説明します。

HCL AppScan では、これらをテスト・ポリシーと呼んでいます。テストポリシーは、アプリケーションをテストするときに使用するルールのセットです。

カテゴリのリストを選択して、そのカテゴリ内の問題をスキャンすることもできますし、深刻度の高い問題のみを選択して、重大な欠陥をテストすることもできます。

動的テストルールには、アプリケーション、サードパーティ、またはインフラストラクチャのタイプがあります。

• アプリケーションルールは、アプリケーションコード自体に見られる論理的な問題をテストします。これらは、開発プロセスの一部として導入された脆弱性であり、組織の開発グループのコードベースの中で発見されます。解決策は、通常、コードの修正や変更です。
• サードパーティのルールは、サードパーティのコンポーネントを使用して導入された問題をテストします。サードパーティのルールは、サードパーティのコンポーネントに CVE を割り当てることで指定され、解決策は通常、関連するコンポーネントをアップグレードすることです。
• インフラストラクチャのルールは、Web アプリケーションやサービスを実行するプラットフォームの脆弱性をテストします。これらのルールは、Web やアプリケーションサーバ、通信中に使用される証明書などに関連しています。これらは、設定の問題や、サーバの一部であるサービスアプリケーションの問題である可能性もあります。解決策は、通常、構成の変更であり、多くの場合、DevOps または Ops の IT チームによって実行されます。

決定、決定

開発ライフサイクルのさまざまな段階でスキャンを実行する場合、異なるテストのセットを実行することは意味があるかもしれませんし、意味がないかもしれません。

例えば、サーバが開発サーバの場合、インフラストラクチャのテストを実行することは意味がありません。サーバーが正しく設定されている可能性が低くなり、それを修正したいと思う可能性が低くなります。しかし、ステージングサーバや本番サーバをスキャンしている場合は、これらのテストを実行することが重要です。インフラストラクチャのテストのみを含むテストポリシーでスキャンを実行することもできます。

アプリケーションテストは、確かに継続的な統合スキャンに使用されるでしょう。このようなテストでは、アプリケーションにコード化されている脆弱性を識別するように設計されています。前述したように、インフラストラクチャのテストは、ほとんどがノイズを発生させるので、この段階では除外されるべきです。

サードパーティのコンポーネントは、それほど頻繁には変更されませんし、これらのコンポーネントの導入は、通常、明確に定義されたプロセスの一部として行われます。すべてのテストを常に実行する必要は本当にありません。開発段階ではオープンソース解析 (OSA) を使用した方が良いのですが、AppScan Source では、何か抜け落ちた場合に備えて動的にキャッチすることができます。

サードパーティのルールテストは、新しい脆弱性が公開される可能性があるため、定期的に実行する必要があります。さらに、サードパーティの問題は、必要のない特定の機能をオフにすることで緩和できる場合もあります。その場合は、ダイナミックスキャンを実行することで、その機能が正常に無効化されているかどうかを確認することができます。

より効果的に

セキュリティテストの重要な目標の 1 つは（アプリケーションの安全性を確保し、顧客とデータを保護することは別として）効率性と明快さです。可能な限り徹底したいと考えていますが、間違ったタイミングで間違ったテストを実行してしまうと、得られるのはノイズだけになってしまいます。ほとんどの無関係な情報に圧倒されていると、集中力を失い、場合によっては興味を失ってしまいがちです。

関連する状況に必要な結果を適切なタイミングで得ることに集中することで、スキャン時間と課題のトリアージの両方の効率が向上します。これらの目標を達成するためには、スキャンの目的とする結果に対して正しいテストポリシーを設計することが重要です。時間をかけて、ポリシーを定義するためのオプションを調査し、スキャンの意図とその結果について考えてみてください。

詳細は

AppScan の技術力の詳細をお知りになりたい場合は、是非デモの要望など、お問い合わせ下さい。

2020/7/14 - 読み終える時間: 2 分

AppScan の動的解析では、テストされた要素に関連してユーザーから質問が出てくることがよくあります。その疑問に答えるブログ記事 The Elements of Application Security Testing (With Apologies to Strunk and White) が英語版ブログにポストされました。その翻訳版を掲載します。

アプリケーション・セキュリティ・テストの要素（Strunk & White への謝罪を込めて)

2020年7月8日

著者: Shahar Sperling / Chief Architect at HCL AppScan

翻訳者注: "Strunk & White" は、適切な記述方法を記した書物 (The Elements of Style) の著者名。

動的解析では、テストされた要素に関連してユーザーから質問が出てくることがよくあります。 質問の内容は様々ですが、ユーザーは一般的に以下のことを知りたいと考えています。

• テストされた要素とは何か。
• それらは本当に進捗を表しているのか。
• いつ生成されるのか。
• テストフェーズを開始すると、数字が突然ジャンプすることがあるのはなぜか。

最後のは、エラーか何かを示しているのではないかと、とても奇妙なことのように思うことでしょう。 しかし、最初の3つの質問に答えれば、それは明らかになります。論理的にも。それについては、このブログで可能な限り説明します。

ルールについて

HCL AppScan の動的テストは、ルールによって定義されています。厳密に言えば、AppScan のルールは作業を定義する変種で構成されています。しかし、この記事では、より一般的な用語を使用します。

• ルールとは、問題を検出するための具体的なテスト命令です。
• 各ルールは、特定の課題タイプを識別するために使用されます。複数のルールが同じ課題タイプを識別することができます。
• ルールは特定の HTTP コンポーネントをテストします。たとえば、アクティブ・テストは HTTP クエリ・パラメータを変更したり、パッシブ・テストはレスポンス・ヘッダーを検査したりします。
• スキャナは各 HTTP コンポーネントタイプのルールのリストを保持します。ここで使用する用語は、エンティティタイプです。
• 各ルールのリストは、ルール範囲と呼ばれる 1 つまたは 2 つのサブリストで構成されています。最初の範囲は、互いに並行して実行できるルールのリストです。2 番目の範囲は、連続して実行する必要があるルールのリストです。リストの中には、並列実行可能なルールだけで構成されているものもあるので、1 つの範囲を含んでいます。他のリストは、並列範囲とシリアル範囲の両方を持っています。

スキャナは 1 つのテスト段階で 2 つのパスを実行します。最初に、複数のスレッド (構成で定義されている) で並列実行可能なすべてのルールを実行し、次にシリアルに実行する必要があるすべてのルールを実行するために、シングルスレッドモードに切り替えます。

HTTP コンポーネントのエンティティの危機

エンティティタイプがあるならば、型付け(タイプ)するエンティティがあるはずだと、あなたは推測して - そしてそれは正しい - いるかもしれません。では、エンティティとは何でしょうか。HTTP コンポーネント、またはエンティティタイプは、テストできる HTTP セッションの個々の部分 (リクエストとレスポンスのペア) のいずれかになります。ホスト、パス、ディレクトリー、パラメータ、クッキー、リクエスト、レスポンスなどはすべてエンティティタイプです。

スキャナがリクエストとレスポンスのセッションを収集すると、関連するエンティティを抽出します。したがって、エンティティとは特定のセッションにおけるエンティティタイプの特定のインスタンスです。また、脆弱性をテストするコンポーネントであるため、セキュリティエンティティとも呼ばれています。HTTP トラフィックを収集して分析する際に、探索フェーズでエンティティを生成します。

「エンティティがたくさんあるじゃないか！」と思うかもしれません。そして、実行するテストの数も多く、それぞれが独自のルールのリストを持っています。その通りです。最適化がなければ、何千万ものテストを実行することになり、その多くは何度も同じ問題を見つけることになります。なぜでしょうか。 それは、AppScan が識別するリクエスト・レスポンス・セッションは多数ありますが、同じサーバー側のコードに起因する大きなグループが存在するからです。

では、最適化にはどのようなものがあるのでしょうか。いくつかのタイプがあり、その多くは何らかの方法で設定や影響を与えることができます。私たちは DOM の類似性と DOM の冗長性を利用して、リクエストとレスポンスのセッションのセット、あるいはページ全体が同じサーバーサイドのコードに由来するかどうかを判断します。そして、代表的なものを選んでテストし、残りのものは無視します。冗長性のチューニング設定は、エンティティの数にも影響を与えます。テストで使用する HTTP コンポーネントの最適なセットを選ぶために行うヒューリスティックや比較は他にもあります。それは、セキュリティエンティティを作成することです。

これは理解しておくべき最初の重要なことです: アプリケーションデータで見ることができるすべての HTTP コンポーネントが、実際のセキュリティエンティティになるわけではありません。繰り返しになりますが、これは最適化のためです。

もう 1 つ理解しておくべき重要なことは、最適化は、設定されたものとは別に、AppScan が十分なデータを収集した場合にのみ実行されるということです。どのくらいの量が十分なのでしょうか。最小限のセッション数で済むこともあれば、最後まで待って可能な限りのセッション数を確保することもあります。「いくつかの最適化は、探索の最後の最後に行われる」ということを覚えていてください。これは、上記の質問のいくつかに答えてくれるので重要なことです。

エレメント単位の視点 (Elementwise)

これで、セキュリティエンティティ、ルールの範囲、テストフェーズの 2 回のパスができました。最初のパスではエンティティを選択し、1 つの範囲にあるすべてのルールを実行し、その後、必要に応じて再度選択し、2 つ目の範囲にあるすべてのルールを実行します。このエンティティとルールの範囲のペアリングをテスト済み要素 (a tested element) と呼びます。エンティティは、ルール範囲が 1 つしかない場合は 1 つのテスト済み要素を、そうでない場合は 2 つのテスト済み要素を提供することができます。最適化、エンティティの種類、そしてアプリケーション内においてそれらが分散しているため、AppScan が探索データ（HTTP コンポーネント）から取得するテスト済み要素の数を事前に計算することはほぼ不可能です。

これで、テストされた要素が DAST スキャンで何を表し、何を意味するのかを理解したので、進捗状況の問題に入ることができます。スキャナは、完了したルール範囲をカウントオフします。これが進捗の表現です。

AppScan がテスト済み要素を生成する方法（探索中）について少し説明しましたが、他にもオプションがあります。エンティティは、手動での探索をインポートする際にも生成されます。スキャナがシーケンスを処理すると、エンティティが 2 ステップで生成されます。AppScan は一部のエンティティを最適化せずにインポート時に生成します。AppScan は残りの部分を最適化しようとしてインポートの最後に生成されます。

詳細はこちら

AppScan の技術力の詳細をお知りになりたい場合は、是非デモの要望など、お問い合わせ下さい。

2020/6/28 - 読み終える時間: ~1 分

クロスサイトスクリプティング (XSS) の脆弱性は今もなお Web アプリケーションにおけて多発しています。AppScan は XSS 検出機能を古くから備え、最新版の 10.0.1 でも精度と検出能力向上を図っています。英語版ブログ [Identify and Remediate Cross-Site Scripting Vulnerabilities with HCL AppScan V10.0.1]() の翻訳版を掲載します。

HCL AppScan V10.0.1 でクロスサイトスクリプティングの脆弱性を特定し、修正する

2020年6月22日

Eitan Worcel / Product Lead, AppScan

古いことわざにもあるように、「古いものはすべてまた新しい」という言葉があります。残念ながら、広まっているクロスサイトスクリプティング (XSS) 脆弱性は、最も一般的なアプリケーション脆弱性の種類のひとつであり続けています。10年以上もこの脆弱性と戦ってきたとは信じがたいことですが、それでもクロスサイトスクリプティングは OWASP のトップ 10 の中で最も一般的な脆弱性タイプのひとつです。2018年の報告書によると、XSS の脆弱性は、最新のアプリケーションの最大 82% に見られる可能性があります。

XSS とは何か？

OWASP は、クロスサイトスクリプティングを次のように定義しています。「XSS 攻撃は、攻撃者が Web アプリケーションを利用して、悪意のあるコード (一般的にはブラウザー側のスクリプトの形で) を別のエンドユーザーに送信することで発生する」。

これだけの年月を経ても、XSS が現在も広く普及している脆弱性であり続けているという事実を反省しながら、2012 年に当社が XSS Analyzer と名付けた画期的な AppScan 技術を導入したことを思い出しました。2020 年の現在も AppScan V10.0.1 で利用可能であり、ほとんどのアプリケーションセキュリティテストソリューションが提供できるものよりも技術的に先を行っています。本質的には、クロスサイトスクリプティングの自動検出のための速度と精度が向上します。

XSS Analyzer でクロスサイトスクリプティング脆弱性の特定

XSS Analyzer を使ったクロスサイトスクリプティングの脆弱性の特定は簡単です。エンティティ (パラメータなど) の値に JavaScript コード (例: <ｓｃｒｉｐｔ>alert ('XSS') </ｓｃｒｉｐｔ>) (意図的に全角にしています) を入力し、レスポンスがレンダリングされたときに JavaScript コードが実行されたかどうかをチェックするだけです (例: アラートが表示される) 。XSS の脆弱性を悪用する方法はたくさんあります。ひとつが失敗した場合、Analyzer は次の方法を試します。このような潜在的なペイロードの以前のリスト (通常は「チートシート」と呼ばれています) には、数十から数百の潜在的なペイロードが含まれていました。当社の継続的な調査により、7 億以上のペイロードが XSS Analyzer で使用されていることが明らかになりました!

XSS の自動識別

クロスサイトスクリプティングの自動識別は、成功したペイロードが見つかるまで潜在的なペイロードを送信することによって実行されます。従来のダイナミック アプリケーション スキャナは、時間が限られているため、各エンティティに対して数十回以上のリクエストを送信することができません。そのため、DAST スキャナは膨大なペイロード空間の中から小さなサブセットを選択し、そのサブセットに対してのみテストを行います。サブセットの選択は、成功確率、反射コンテクスト、その他の特性に基づいた賢い選択ですが、テスト空間全体をカバーすることは決してありません。サブセットはテスト空間の2分の1もカバーしません。

XSS Analyzer の学習機能

これが XSS Analyzer の特長です。これは、スキャンのタイムパフォーマンスに影響を与えることなく、より多くのXSS脆弱性をより高い精度で、より少ない時間で発見します。

さらに、XSS Analyzer は人間の攻撃者になりすますように訓練されています。単にランダムなリクエストを送信するのではなく、サーバー側のロジックを学習し、テストに適したペイロードを選択します。 これが XSS Analyzer のパフォーマンスと精度の鍵となります。 この「学習システム」により、XSS Analyzer は各テストペイロードから学習することができます。

テスト結果に基づいて、XSS Analyzer は「チートシート」にある7億個のペイロードの中から潜在的なペイロードを排除し、他のペイロードに集中することができます。 テストごとに、XSS Analyzer は機能する範囲を絞り込み、通常は 20 回以下のテストで問題を発見し、平均 20 回のテストで 7 億項目のチートシートのリストから脅威が存在しないかどうかを判断することができます。これは、スピードと正確さの点で、XSS の識別において本当に大きな成果です。

AppScan Enterprise のデモ

今すぐ登録して、HCL AppScan Enterprise の包括的なデモをご覧になり、当社の XSS Analyzer 機能の詳細をご確認ください (日本のお問い合わせ窓口はこちらです)。