HCL AppScan - 継続的なセキュリティの構築

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

AppScan を道具として継続的に使いこなす方法について書かれた英語版ブログの記事 HCL AppScan - Constructing Continuous Security の翻訳版です。


HCL AppScan - 継続的なセキュリティの構築

2020年8月12日

著者: Rob Cuddy / HCL

画像の説明

継続的セキュリティに関する最初のブログでは、2 つの主要な能力を含む 3 つのテーマ領域の概要を説明しました。 今回のブログでは、Construct のテーマと Design and Automate の機能に焦点を当ててみたいと思います。

Construct は、既存のソフトウェア開発プロセスにセキュリティを追加しようとする場合、ほとんどの組織が最初に着手する場所です。チームは API を使用したり、CLI を活用したりして、コードのコミットやビルド時に行われるスキャン機能を提供します。そして、それらのスキャンの結果とフィードバックを実行可能なものにする方法を探します。

これは素晴らしいスタートです。

しかし、本当にうまく構築したいのであれば、考慮すべきことはもっとある。例えば、山の中に旅行に行き、夢のキャビンを建てるのに最適な土地を見つけたとします。あなただけの木を切り倒して建物を建てることから始めますか。もちろんそうではありません。あなたは計画を立てることから始めます。そこには、許可を得るために、発生する必要があり、最初に構築され、設定する必要がある基礎を地面に水平にする必要があります。 その小屋を成功させるためには、方法と順序があります。

ソフトウェアにも同じことが言えます。

多くの組織は、何年もかけて技術的な負債を回収してきましたが、今ではその負債を返済するか、新しい機能を作るかの日々の戦いになっています。多くの場合、技術的な負債を処理しなければならない時は、そうせざるを得ない時であるように思われます。技術的な負債を処理しないことの痛みや壊れ方があまりにも大きくなり、物事を変えなければならなくなる。対照的に、成功しているビジネスは、これらの考え方の間で適切なバランスをとることができるものです。。何が彼らにこれを可能にするのでしょうか。それは、デザインに注意を払うことです。


デザイン

建築の世界 では「形は機能に従う」とよく言われます。つまり、建物や構造物をどのように作るかは、それが何に使われるかによって大きく決まるということです。意図によって発明が決まるのです。

ソフトウェアでは、私たちは直感的に同じものが欲しいと分かっていても、狭く限られた範囲で運用することが多い。新しい機能や能力を構築し、それを使って何を達成したいかは分かっていますが、それがシステムの他の部分とどのように相互作用するかを実際に確認する手段や可視性が不足していることがよくあります。そして、セキュリティにとっては、これが大きな問題となります。

そのため、継続的なセキュリティに関しては、プロジェクトの開始時から、SDLC のすべての段階で継続的なセキュリティを導入する必要があります。これは、ユースケース、ヒルステートメント、ユーザーストーリー、カンバンボードなどのすべてに、セキュリティの特定の側面が含まれていることを意味します。与えられた機能がどのように動作するかの概要を示す何十ものステップを含む叙事詩を作成し、最後に「そしてそれは安全でなければならない」というステップを追加するような時代は終わりました。

優れたデザインをすることはチームスポーツであり、複数のプレイヤーが必要です。あなたが開発者であれば、最後に脅威のモデリング演習に参加したのはいつですか。自分のコードが危険にさらされる可能性のあるさまざまな方法を考えたことがありますか。あなたがセキュリティの専門家であれば、開発チームを評価に参加させたのはいつですか。ビジネスへの影響に関連して、脅威とリスクを検討していますか。

ここでは、設計に関するいくつかの "Robservations" を紹介します。


  • 脅威のモデリングにゲーミフィケーションを使用する。 脅威のモデリングにゲーミフィケーションを使用することで、コミュニケーションを容易にし、非難ゲームを避けることができます。 使うことができる素晴らしいゲームがあります。 特権の昇格 (Elevation of Privilege) (githubでも利用可能)


  • 制約として機能するセキュリティ要求事項がある。 セキュリティ要件を満たさないソフトウェアのデプロイは、それらが解決されるまでプロセスを停止させるべきです。
    • これはまた、セキュリティ上の欠陥を発見した人が誰 (Anyone) でも、配送や出荷を停止することを許可すべきであることを意味しています。これは、問題が修正されるまで自動車作業員が生産を一時停止することを許可する、有名なトヨタの工場のアンドンの仕組み (Andon cords) と同じ考えです。
    • セキュリティ上の欠陥を修正するためにリリースを遅らせた方が、後になってデータ漏洩によってその代償を支払うよりもずっと良いことです。


  • プロジェクトに敵対的ユースケースを追加して、失敗しないようにする。 例えば、侵害につながる可能性のある様々なステップやイベントを検討し、それらを1つ以上のユースケースで定義する。
    • 例として。例えば、あるユースケースでは、次のような簡単なステップがあるかもしれません。 "リモートハッカーとして、不正なURLを挿入し、それによってこのウェブサイトへの不正アクセスを得ることができます。
    • このようにすることで、チームは「ハッカーのように考える」ようになり、より強固なセキュリティを日常的に構築することができるようになります。


設計段階でプロジェクトのセキュリティ面について考える時間を増やすことで、後になってから脆弱性の発見、優先順位付け、修正に費やす時間が減り、全体的なサイクルタイムがほぼ確実に短縮されます。


自動化

DevOpsとDevSecOpsに関して言えば、多くの場合、多くの場合、Automate機能はほとんどの場合、そこから始めることになります。それは理にかなっています。DevOpsとDevSecOpsは、最終的には、信頼性と信頼性の高い機能をより早く提供することで、価値をより早く実現することを目的としています。しかし、自動化はスピードだけではありません。

その核心は、「なぜ自動化するのか」が「何を自動化するのか」と同じくらい重要です。おそらく、それ以上に重要です。

例えば、品質保証(QA)テスト環境に展開する前に、統合ビルドの初期検証の一部としてセキュリティテストを行いたいとします。そのためには、統合ビルドを進める前にコードストリームの静的解析テストを自動化することにします。

ビルド前に静的解析を実行することは素晴らしいことですが、重要な問題は、いつ、どこで実行するのかということです。ビルドを開始する前にビルド環境で実行しますか。もしそうだとしたら、それはビルド時間にどのような影響を与えますか。ビルドに通常30分かかる場合、その時点でスタティックスキャンを実行すると、認識されているビルド時間が2倍になる可能性があります。重要な脆弱性が見つかった場合はどうしますか。ビルドを実行しないようにしますか、それとも深刻な問題があることを十分に理解した上で、ビルドを続行させますか。それとも、個々の開発者に、コミットする前にスキャンを実行して重要な問題を解決することを義務付けるのでしょうか。その場合、開発者が問題を解決する方法を知らない場合、どのようにして解決できるようにするのでしょうか。開発者をセキュリティチームとペアにしていますか。

すべての有効な質問は、実装の前に考えなければなりません。

自動化のポイントは、単に決められた方法でテストを実行して結果を報告するだけのものではないということです。 もちろん、テストは実行されるべきであり、結果は報告されるべきである。 しかし、間違った方法で自動化を追加することは、助けるよりも傷つけることになる。 それは、情報過多やアラート疲労を引き起こす可能性があります。 優れた自動化は、行動と決定を見て、プロセスの摩擦と無駄を排除しようとする。

ここでは、助けるべきである設計上のいくつかの "Robservations" は、次のとおりです。


  • 最初にボトルネックを特定する。 Eliyahu M. GoldrattのThe Theory of Constraints (または Phoenix Project を読んだことがある人)に精通している人は、ボトルネック以外のどこかのプロセスに行われた改善は幻想であることを知っているでしょう。
    • ボトルネックの後の改善は、待っているだけなので、役に立たない。
    • ボトルネックになる前の改善は、ボトルネックでさらに山積みになる。


  • 小さなことから始めよう。一度にすべてを自動化しようとしないこと。 そうすることで、プロセスの一箇所での自動化の影響を測定することがはるかに困難になる。これは、後の最適化の評価をより困難にする。
    • 平凡な手動プロセスが発生している場所や、ステージ間のハンドオフがある場所を特定し、そこに自動化を追加する。
    • 自動化がその時点で追加する利益を定量化する。


  • 二度測定して、一度追加すること。 熟練した大工や芸術家のように、我々が正しいことをしていることを確認するために測定値を検証することが重要である。
    • プロセスの別のポイントに自動化を追加する前に、現在のプロセスのスループットと決定要因が何であるかを自信を持って知ることができる。これにより、システムを十分に理解することができます。


詳細

今回のブログでは、Construct テーマと Design と Automate の機能に焦点を当てました。 第3部では、「強化」テーマと「教育と統治」の機能を見ていきます。このトピックについてさらに詳しく知りたい方は、"Go Beyond Application Testing to Continuous Security" と題した先日のウェビナーのリプレイをご覧ください。


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

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 と統合する方法をご紹介しました。


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

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

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


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氏とのインタビュー動画もご覧いただけます。 デイブと私は、本当に最先端のアプリケーションセキュリティテストソリューションの要素にスポットライトを当てています。


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

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 のテストドライブはこちらからご利用いただけます。


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

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. 以下のようなメッセージが表示されます。パニックにならないでください。お使いのソフトウェアに害が及ぶことはありません。拡張機能の追加」をクリックします。

画像の説明

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

画像の説明

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

画像の説明

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

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

画像の説明

使い方

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

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

画像の説明

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

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

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

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

画像の説明

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

  2. 好奇心旺盛な方のための追加ステップ。記録を確認したい場合は、保存されたファイルを解凍して、同封されている内容をコピーペーストしてください。私のお勧めは、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 の無料トライアルページをご覧ください。


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

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_ipport は、スキャナが実行されているマシンの 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 に連絡してデモを予約してください。


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

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での最近のウェビナーをご覧いただくか、BuzzsproutApple PodcastsSpotifyGoogle Podcasts でご覧いただけるApplication Paranoia PodcastのEpisode #7をお聴きいただくことで、Continuous Security に関するコメントについてより多くの考えをお聞きいただくことができます。


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

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


About

HCL Japan の Software 部門の複数担当者で HCL Software 全般について記しています。