2020/8/5 - 読み終える時間: 2 分

DEF CON で HCL 社員がルーターのセキュリティー問題に関して発表を行います。そのことについて記された英語版ブログの記事 HCL Aleph Research at DEF CON Conference Spotlights Critical Security Vulnerabilities in Router Technology の翻訳版を掲載します。

HCL Aleph の研究、DEF CONカンファレンスでルータ技術における重大なセキュリティ脆弱性にスポットを当てる

2020年8月3日

著者: Mikala Vidal / Head of Marketing for HCL AppScan

2020年8月8日に、HCL AppScan Aleph サイバーセキュリティチームの Gal Zror が "Don't Ruck Us Again ? The Exploit Returns" と題したセッションを行います。

このセッションでは、第36回 年次カオス通信会議 (Chaos Communication Congress)で発表された Ruckus Wireless の ZoneDirector と Unleashed ルーターに関連して発見された初期の脆弱性に対する Gal 氏の追跡調査を取り上げます。研究者は、33 種類の Ruckus 社のアクセスポイントのファームウェアを調査し、そのすべてに脆弱性があることが判明しました。

3つの攻撃シナリオが発見されました。

• アクセスポイントのルートシェルを取得するためのウェブインターフェースのクレデンシャル開示とCLIの脱獄。
• 認証されていない HTTP リクエストを Web インターフェースに送信することで可能になった、'zap'実行ファイルのスタックオーバーフロー。
• zap' 実行ファイルを使用した任意のファイル書き込みにより、認証を必要としない新しい 'jsp' ページが作成され、コマンドインジェクションの脆弱性。

「これらの脆弱性のいくつかは、本当に簡単なものです」と Zror 氏は SecurityWeek に語っています。「例えば最初のものは、実行するのが簡単です」。

TechCrunch が指摘しているように、攻撃者がルーターのソフトウェアの脆弱性を見つけてそれを利用すれば、デバイスを制御してより広い内部ネットワークにアクセスし、コンピュータや他のデバイスをハッキングやデータ盗難にさらすことができる。Zror 氏は、ルーターの多くはインターネットからアクセスできるため、「ボットネットにとって非常に良い候補になる」と説明しています。これは、攻撃者が脆弱なルーターを強制的に参加させ、悪意のある行為者によって制御された独自の分散型ネットワークに参加させた場合のことであり、それらをまとめて、大量のジャンク・トラフィックでウェブサイトや他のネットワークを叩きのめすように指示することができます、それらをオフラインにします。インターネット上には、脆弱な Ruckus ルーターが「数千台」存在します。

Zror 氏の追跡調査では、コマンドインジェクション、情報漏洩、資格情報の上書き、スタックオーバーフロー、クロスサイトスクリプティング (XSS) など 6 つの新たな脆弱性が含まれています。これらの脆弱性を用いて、Zror氏は、新たに2つの異なる認証前リモートコード実行攻撃 (RCE) を検出することができました。Zror 氏は、最初の調査と合わせて、合計 5 つの全く異なるRCEを発見しました。彼はまた、Ruckus が最初の研究で発見した脆弱性の一部を正しく修正しておらず、非常に端正なペイロードを使用することで悪用可能であることも発見しました。

2019年の Symantec Internet Security Threat Report (ISTR) によると、攻撃されるデバイスの 90% はルーターと接続されたカメラです。

ルーターがハッキングされると、ビジネスネットワーク全体とそれに接続されているすべてのものが危険にさらされます。メリーランド大学によると、悪意のあるハッカーは現在、39秒に1回の割合でコンピュータやネットワークを攻撃しています。

サイバー攻撃を減らすためには、無線エンドポイントの安全性を確保することが最重要ですが、特に 2020年の特殊な状況によって生み出される攻撃範囲が大きくなることを考えると、ハッカーがアクセスを獲得する可能性は高いと言えます。インジェクションやクロスサイトスクリプティング (XSS) などの OWASP トップ 10 の脆弱性の潜在的なリスクを最小化するアプリケーションのセキュリティテスト対策を含む、多層的なデバイス、DevOps、AppSec のアプローチを検討してください。

HCL AppScan on Cloud のテストドライブはこちらからご利用いただけます。

2020/8/4 - 読み終える時間: 6 分

HCL AppScan のダイナミックスキャンをより効率的に実施するための機能、「HCL AppScan アクティビティレコーダー」の解説記事 A Closer Look at HCL AppScan Activity Recorder 's Features and Usage の翻訳版です。

HCL AppScan アクティビティレコーダー の機能と使い方の詳細

2020年7月27日

著者: Vinita Sanghi / Engineering Manager at HCL AppScan

こんな経験はないでしょうか。Web アプリケーションの新バージョンをステージングにデプロイ後、ダイナミックスキャンを実行して、セキュリティの脆弱性を把握しようとして Web サイトを開いたものの、「変更点に関するものの操作を記録して、短時間でダイナミックスキャンで検査が完了できればいいのに」と思ったこと。

他の製品を見る必要はないでしょう。HCL AppScan は、それに最適なソリューションを提供します - HCL AppScan Activity Recorder Chrome ブラウザ拡張機能です。この小さなユーティリティを使用すると、ウェブサイトからのトラフィックとアクションを記録し、それらの記録を、選択した AppScan ダイナミック分析ツール（ HCL AppScan Enterprise または HCL AppScan Standard）にアップロードすることができます。記録は、ログイン・シーケンスまたはマルチステップ・データのいずれかにすることができます。また、HCL AppScan On Cloud (ASoC) ユーザーの方にもご用意ができています。ASoC では、AppScan Activity Recorder を介して記録されたログイン・シーケンスをアップロードして、ダイナミック・スキャンを行うことができます。

では、Chrome 拡張機能についての理解が深まったので、簡単なインストール方法と使いやすい機能をご紹介します。

インストール

AppScan Activity Recorder を Chrome ブラウザにインストールするには、以下の手順を実行します。

1. Chrome ウェブストアで「 AppScan 」を検索します。下のスナップショットに示すように、検索結果が表示されます。

または、AppScan ツールには、AppScan Activity Recorder をインストールするための Chrome ウェブストアへのリンクも含まれています。AppScan Enterprise と AppScan on Cloudのスナップショットは以下のように表示されます。

1. Chrome ウェブストアのリンクで、「 Chrome に追加」をクリックします。
2. 以下のようなメッセージが表示されます。パニックにならないでください。お使いのソフトウェアに害が及ぶことはありません。拡張機能の追加」をクリックします。

3. インストールが成功すると、右上のアドレスバーに小さな HCL AppScan アイコンが表示され、以下のようなメッセージが表示されます。

4.アイコンが表示されない場合は、「拡張機能」アイコンをクリックして、AppScan Activity Recorder をピン留めすると、アドレスバーに拡張機能のアイコンが表示されるようになります。

使用方法に進む前に、覚えておくべきことがいくつかあります。

• 拡張機能の管理」に移動し、「シークレットで許可」オプションを有効にすることで、シークレットモードでの動作を有効にすることができます。
• オプションといえば、AppScan Activity Recorder には、別のデバッガウィンドウでアクティビティを表示するオプションが含まれています。拡張機能を右クリックして「オプション」を選択するだけです。オプションにチェックを入れて保存をクリックします。このブログの残りの部分では、このオプションはチェックを外したままにしておきます。

使い方

AppScan Activity Recorder の使用を開始するには、以下の手順に従ってください。

• スキャンする必要のあるウェブサイトのページに移動します。
• AppScan Activity Recorder のアイコンをクリックします。記録が開始されたことを示すために点滅し始めるはずです。このブログでは、デモサイトのtestfire.netを使用しています。

3. 上のメッセージにドメインURLが表示されていることに注意してください。これは、同じブラウザウィンドウで複数のウェブサイトを開いていて、どのウェブサイトを録画しているのか忘れてしまう可能性がある場合に便利です。

4. 手動クロールを開始し、AppScan Activity Recorder に作業を任せます。

5. ブラウジングが終了したら、以下の方法で録画を停止することができます。

   • 点滅しているアイコンをクリックします。
   • ブラウザウィンドウで「キャンセル」をクリックします。

6. 録画を停止すると、録画を dast.config に保存するように促されます。この形式は、すべての AppScan ツールで認識されるため、選択されています。ファイル名には、参照用にドメインと現在のタイムスタンプが含まれています。必要に応じて自由に変更してください。例えば、ログインシーケンスファイルには、使いやすさのためにログインタグを追加することができます。

7. 好奇心旺盛な方のための追加ステップ。記録を確認したい場合は、保存されたファイルを解凍して、同封されている内容をコピーペーストしてください。私のお勧めは、Online JSON Viewer を使用することです。

AppScan Activity Recorder のデバッグオプション

以前にデバッグオプションについてお話したのを覚えていますか？このオプションは AppScan Activity Recorder に追加され、クッキーやアクション、ヒットしたリクエストを記録することでブラウジング活動を見ることができるようになりました。

デバッグオプションを有効にするとどうなるか見てみましょう。

記録を開始するとすぐに新しいウィンドウがポップアップし、アクションを記録しながら記録を終了するオプションが表示されます。

注意点としては、デバッグオプションを有効にすると、拡張機能のアイコンが点滅しなくなることです。これはバグではありませんが、設計上の制限と考えることができます。しかし、これは録音を完了して保存することを妨げるものではありません。保存時には、デバッグウィンドウを自動的に閉じないようにしています。これは設計上の制限ではなく、自分のペースでデータを見られるようにするための設計上の配慮です。グレーアウトされた情報に気づいた場合、それはフィルタリングされたレスポンスであり、シーケンスファイルには表示されません。

この時点で、AppScan Activity Recorder を使用して、選択した AppScan ツールでトラフィックとアクションを記録する準備が整いました。

HCL AppScan Enterprise での AppScan Activity Recorder の記録の使用

HCL AppScan Enterprise は、大規模、マルチユーザー、マルチアプリの動的アプリケーションセキュリティテスト（DAST）ツールで、脆弱性の特定、理解、修正を行い、規制遵守の実現を支援します。動的テストのニーズに合わせてコンテンツスキャンとADACジョブを設定することができます。

AppScan Activity Recorder を介して記録されたログインシーケンスとアプリケーションの探索データファイルは、コンテンツスキャンとADACジョブの両方に対応しています。さらに、AppScan Enterprise UIや REST API を介したインポートにも対応しています。どのようにしてですか？詳細については、ここに示されている詳細な手順に従ってください。

インポートが成功すると、コンテンツスキャンジョブの場合、以下のように手動で探索されたURLが表示されます。

HCL AppScan on Cloudでの AppScan アクティビティレコーダーの使用

HCL AppScan on Cloud (ASoC) は、動的および静的な手法を用いてWeb、モバイル、デスクトップアプリケーションをスキャンすることができる、あらゆるアプリケーションセキュリティテストのニーズに対応したSaaS型ソリューションです。ASoC は、そのすべての機能を可能にするWeb UIを備えています。このWeb UIを介して動的スキャンを作成している間に、AppScan Activity Recorder を使用してログインシーケンスを記録し、ASoC がスキャン中にアプリにログインする必要があるときにいつでも使用できるようにすることができます（下のスナップショットに示すように）。

ASoC はこの機能を REST API でも公開しています。ASoC は、統合を容易にするために、/api/v2/Scans/DynamicAnalyzer という REST API でこの機能を公開しています。

結論

要約すると、AppScan Activity Recorder は、あなたの記録ニーズに役立つ効果的なツールです。この拡張機能を使用して、Chrome ページのレビューセクションからご希望の機能や強化点をすべてお知らせください。クラウド上の HCL AppScan をテストドライブするには、HCL Software の無料トライアルページをご覧ください。

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 の技術力の詳細をお知りになりたい場合は、是非デモの要望など、お問い合わせ下さい。