2020/8/12 - 読み終える時間: 3 分

HCL AppScan on Cloud と HCL Launch を組み合わせることで、安全ビルドの管理・デプロイを制御しながら運用することについて、英語版ブログの記事 Adding Security to Continuous Delivery を掲載します。

継続的なデリバリーにセキュリティーを追加する

2020年8月7日

著者: Brian Stump / Product Specialist, HCL

物事がうまくいっているときは素晴らしいことだと思いませんか？これは、当社の継続的なデリバリとソフトウェア・セキュリティー・ツールを使用して得られる感覚です。HCL Launch は、AppScan on Cloud (ASoC) と一緒に、自動化、レポート作成、リリース管理を含む DevOps ライフサイクル全体の中で、アプリケーションのセキュリティを自動制御する機能を提供してくれます。

HCL Launch は、ASoC プラグインの出力を処理し、それに応じてビルドを処理できます。ビルドが低レベルの環境に正常にデプロイされたが、深刻度の高い問題で Dynamic ASoC スキャンに失敗した場合、HCL Launch は自動的に最後にデプロイされたバージョンにロールバックし、問題があることを示すステータスでビルドをマークします。ASoC があなたのビルドの中でそれほど深刻ではない問題を識別した場合、HCL Launch は「デプロイメント警告」を表示しますが、ターゲットマシンにインストールされたままにしておきます。そして、もし ASoC が重大な問題を発見しなかった場合、HCL Launch はそのバージョンに AppScan のすべてのスキャンに合格したことを示すアプリのステータスを与えます。言い換えれば、HCL Launch は、AppScan の承認に合格しない場合、Prod やその他の高レベルの環境へのデプロイを防げる環境ゲートを作成します。

ソフトウェアのデプロイメントにおけるセキュリティを簡単にする準備はできていますか？HCL Launch を使用してデプロイメントを実行し、ASoC セキュリティースキャンを開始するパイプラインをセットアップする方法について説明します。

HCL Launch の構成

HCL Launch には、AppScan on Cloud 用の無料でインストール可能なプラグインがあります。このプラグインには、AppScan サーバー上で以下の各作業を行うための手順が含まれています。

• ASoC プレゼンスの作成
• ASoC プレゼンスの削除
• ASoC のプレゼンスを開始
• Start Android Mobile Analyzer ASoC Scan
• Dynamic Analyzer ASoC Scan の起動
• Static Analyzer ASoC Scan の開始
• iOS Analyzer ASoC Scan の起動
• ASoC の存在の停止

このシナリオでは、ASoC で静的スキャンと動的スキャンを同時にキックオフするワークフローを設定します。以下の手順とスクリーンショットでは、HCL Launch プロセスを構成する方法を説明します。

各HCL Launch プラグインのステップは、ASoC アプリケーションID、キーID、およびキーシークレットを設定する必要があります。

スタティック アナライザー ステップでは、スキャンのためにアップロードされる IRX ファイル、またはスキャンするファイルやその他の場所を含むディレクトリーのいずれかを指す IRX ファイルも必要です。このフィールドには、スキャン設定ファイル、eclipseワークスペース、.jar、.war、および.earファイルタイプを指定できます。アプリケーションID、キーID、およびキーシークレットに加えて、ダイナミックアナライザーのステップでは、スキャンする場所のURLが必要になります。ページにログインが必要な場合は、アプリケーションのログイン認証情報も提供する必要があります。

各ステップには、「失敗条件のしきい値」のフィールドがあり、H、M、L、I の文字が含まれていることに注意してください。これらは、そのステップが失敗する前に、そのステップが何個の高、中、低、および情報レベルのセキュリティ脅威を受け入れるかを示しています。たとえば、次の例では、スキャンの結果、5 つ以上の中程度の警告が発生した場合、ステップは失敗します。

また、各 ASoC ステップの後の HCL 起動プロセスエディタ内のグレーの円にも注意してください。これは、ステップが失敗しても、失敗した場合を処理するために、プロセスが先に進めるようにするために重要です。必要に応じて、条件付きロジックを追加して、HCL Launch プロセス・エディタを使用してプロセス全体を失敗させることもできます。

ステップが設定されたら、アプリケーションの展開とセキュリティ・スキャンを実行する時間です。これを実行するための HCL Launch アプリケーションのプロセスは、以下のようになります。

同時に実行されている2つのスキャンを示すステップを丸で囲んでみました。 ASoC サーバーにジャンプすると、これらのスキャンがそこでも実行されていることがわかります。

ここでは、AppScan on Cloud を HCL Software のバリュー・ストリーム管理プラットフォームである HCL Accelerate と統合する方法をご紹介しました。

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

アナリスト企業である Enterprise Security Group (ESG) が HCL AppScan の実効性について検証した結果を発表しました。そのことについての英語版ブログ ESG Report Validates How HCL AppScan Helps Developers to Continuously Secure Applications の翻訳版です。

レポートの日本語版: 「HCL AppScanを使用した継続的アプリケーションセキュリティ」

ESG レポートが HCL AppScan によるアプリケーションの継続的な安全性の確保を検証

2020年8月5日

著者: Eitan Worcel / Product Lead, AppScan, HCL

はじめに

このほど、アナリスト企業である Enterprise Security Group (ESG) は HCL AppScan のクニカルレビューを発表し、AppScan が開発者がアプリケーションの継続的なセキュリティをどのように支援するのかについて評価・分析しました。ESG は、AppScan が CI/CD パイプラインに簡単に統合し、DevSecOps の取り組みをサポートすることで、組織に継続的なアプリケーション・セキュリティを大規模な形で提供する方法についても評価しています。

ESG の手法

AppScan のアプリケーションのセキュリティテスト機能を徹底的に評価するために、ESG は、以下に概説する一般的な手順に従いました。

• HCL AppScan on Cloud のユーザーインターフェースを使用して、アプリケーションにセキュリティポリシーを定義し、関連付けました。
• 次に、アプリケーションにセキュリティポリシーを関連付けました。
• 次に、AppScan を DevSecOps ツールチェーンに統合することで、AppScan の「スキャンと分析」機能を評価しました。
• 次に、AppScan を DevSecOps ツールチェーンに統合することで、AppScan の「スキャンと分析」機能を評価しました。
• 最後に、AppScan のレポート機能を評価しました。

AppScan の DevSecOps への影響

ESG は、AppScan が DevSecOps の4つの主要な側面に統合されていることを発見しました。

• ポリシーの定義: セキュリティと規制の専門家がポリシーを定義し、アプリケーションに関連付ける。
• スキャンと分析: 開発者が静的分析を使用してセキュリティを「左にシフト」し、CI/CD パイプラインの初期段階でコードの脆弱性を特定できるようにします。動的でインタラクティブなテストは、同様に、開発者が実行中のアプリケーションの脆弱性を特定するのに役立ちます。
• 脆弱性の修正: 開発者が脆弱性をレビューして修正することを許可するプロセス。ESG は、AppScan の機械学習が、関連する脆弱性をグループ化して優先順位を付け、ソースコード内の潜在的な修正と修正箇所を特定することで、修復を加速させることを発見しました。
• レポート機能: DevSecOps プロセスの重要なコンポーネントであり、セキュリティや規制の専門家や組織管理者がセキュリティやコンプライアンスの進捗状況を継続的に監視できます。

AppScan を DevSecOps モデルに組み込むことで得られるメリットなど、ESG の主要な調査結果をすべて確認するには、無料レポートを今すぐダウンロードしてみてください。

アプリケーションセキュリティが重要な理由

レポートの最後の「Why This Matters (なぜこれが重要なのか)」のセクションで、ESG は効果的なアプリケーション・セキュリティ・テスト・プログラムの利点を要約しています。

「アプリケーションセキュリティテストを DevSecOps の手法に統合して自動化することで、アプリケーション開発ライフサイクルの早い段階でサイバーセキュリティの脆弱性を特定して修正することが可能になり、セキュリティを強化して効率性を向上させられます。また、熟練したサイバーセキュリティチームが直面している課題を緩和するのにも役立ちます。

ESG は、HCL AppScan がアプリケーションのセキュリティテストを簡素化し、高速化することを検証しました。数回クリックするだけで、ESG はセキュリティポリシーを定義し、AppScan を設定して、一連のセキュリティ脆弱性とベンチマークや規制へのコンプライアンスをテストするようにアプリケーションを設定しました。ESG は、オンデマンドのスキャンの設定と実行も同様に迅速かつ簡単で、静的分析と動的分析の結果が簡潔で一貫性のあるインターフェイスで迅速に表示されることに気付きました」。

さらに詳しく

ESG の完全なレポートをダウンロードするだけでなく、ESGのアナリストであるDave Gruber氏とのインタビュー動画もご覧いただけます。 デイブと私は、本当に最先端のアプリケーションセキュリティテストソリューションの要素にスポットライトを当てています。

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日間の無料トライアルに登録してください。