2020/9/2 - 読み終える時間: 3 分

製品から離れて、セキュリティーの一般論を今日は紹介してみたいと思います。HCL AppScan - The New Hybrid Security Employee の翻訳版です。

HCL AppScan: 新しいハイブリッドセキュリティーー担当者の姿

2020年9月1日

著者: Rob Cuddy / Global Application Security Sales Evangelist

「ゲームをしよう (Shall we play a game?)」という言葉を聞いて何を思い浮かべるでしょうか？

もしあなたが私の世代なら、1983年に戻って、若いマシュー・ブロデリック（『(フェリスはある朝突然に Ferris Bueller's Day Off)』から数年後）とアリー・シーディ（『セント・エルモス・ファイア (St. Elmo’s Fire)』や『ブレックファスト・クラブ (The Breakfast Club)』から数年後）が、人気映画『ウォー・ゲーム (War Games)』の中で地球熱核戦争のゲームを始めるのをすぐに思い出すことでしょう。多くの人にとって、これが私たちが初めてサイバーセキュリティーを知ったきっかけでした。

そして数十年後の今でも、サイバーセキュリティーといえば、多くの人が思い浮かべるのはこれです。

画像提供：Giphy のご厚意による

40年近く経った今でも、コントロールルームやセキュリティー・オペレーション・センターは非常に存在感があり、私たちを守るために必要なものですが、確かにサイバーセキュリティーに対処する必要があるのはこれらの場所だけではありません。脅威の状況がますます増加し、脆弱性の数も増加している中で、可能性のある攻撃や脅威の媒介をすべて処理するために、高度な訓練を受けた専門家の小さなグループを一室に集めて依頼するのは、非常に不公平なだけではありません。危険です。

Edgescanの 2020 Vulnerability Statistics Report では、「専門家の 64%が、組織の Web アプリケーションやエンドポイントを完全に認識していないことを認めた」とし、2019年には 80億件以上のレコードが侵害されたことにも言及しています。そして、コンテナ、マイクロサービス、モノのインターネット (IoT) の普及はそれを難しくしているだけです。

つまり、単一分野のセキュリティー専門家に頼るという古いモデルは、特にDevOpsのスピードで動いている場合には通用しないということです。今日、成功した安全なソフトウェア開発には、複数の分野にまたがるアプローチと人材が必要とされています。今日と明日のセキュリティー社員は、どのような姿をしているのでしょうか？よくぞ聞いてくれました。

セキュリティー従業員の新しい種類

先日、Application Paranoia のポッドキャストでは、HCL Software の CISO である Joe Rubino にインタビューを行い、当社が行うすべての業務において、信頼されたセキュリティーの強固な文化を構築することについての彼の考えを尋ねました。その中心にあるのは、組織とその顧客基盤をサポートするセキュリティー専門家のチームをどのように構築し、育成しているかということです。

私たち全員が非常に興味深かったのは「セキュリティーのプロとは何か」という概念を広げる議論でした。皆さんも「セキュリティーはみんなの仕事」という言葉を聞いたことがあるのではないでしょうか。確かにその通りだと思います。結局のところ、私たちは個人的なデバイスを持ち歩き、日常的に個人的な資産と職業的な資産の複雑な組み合わせを使用しています。私たちは皆、自分の役割を果たす責任があります。私たちは、これらのデバイスを更新し、適切に使用し、フィッシング詐欺のような明らかなものを避けるようにしなければなりません。

これらは素晴らしいことですが、今日の真のセキュリティーには、より全体的な対応が求められています。ジョーはこのように表現しています。"私たちは皆、セキュリティーの専門家としての責任を負わなければなりません。データプライバシーの専門家の。カスタマーサポートのプロ。そして、その新しい通常の状態、期待、それに伴う責任を受け入れるように自分自身を追い込むことができればできるほど、私たちはさらに進歩していくでしょう。

で、セキュリティーの専門家って何ですか？

明らかに、セキュリティーは常に進化し、複雑さを増している高度に技術的な領域です。この分野で成功するためには、技術的なスキルを理解し、適応し、適用し、学ぶ能力が成功の前提条件となります。

しかし、優れた技術力だけでは、もはや十分ではありません。

今日では、特にセキュリティーに関わる分野では、従業員のハイブリッドモデルをさらに導入する必要があります。 ジョーが "学際的なアプローチ "と呼ぶものが必要です。これは、人々はいくつかの重要な分野でスキルを持っていますが、ビジネスのニーズが変化し、新しいスキルが登場しなければならないため、それらのスキルセットだけに頼ることはできないという考え方です。

ポッドキャストでは、そのような従業員を見つけ、育成することについて、成功への鍵がいくつか言及されていました。その中でも特に重要なのは、次のようなことでした。好奇心旺盛で、共感力のある人を見つけること。これは、より多くの組織が DevSecOps のプラクティスを採用するように努力しているので、特に重要である。好奇心と共感は問題解決とチームワークを促進し、DevOps と DevSecOps の長期的な成功に不可欠な文化を構築します。

セキュリティー専門家のメンタリティが、単に「このチェックリストを実行してください。完了！」という考え方では、必要とされる包括的なセキュリティーを提供することはできません。また、ポリシーの施行や規制の遵守だけではいけません。その代わり、セキュリティー対策は継続的に評価、評価され、ビジネスニーズの変化に応じて調整されなければなりません。適切に実施されれば、優れたセキュリティーは消費者の信頼と信頼を促進します。これにより、「当社はお客様のデータに対して責任を持っています」と宣言することができます。

「決められていることだから」の意識から距離を置く

我々は正しい理由で正しいことを行い、多くの人がセキュリティーの専門家だと思っているようなチェックリストのような考え方を避けているのだろうか」という、重要なレトリック的な質問をジョー氏は投げかけました。

素晴らしい質問です。

今日、セキュリティーは単なるゲートキーパーではなく、ビジネスを可能にする存在である必要があります。つまり、セキュリティーの専門家は、ビジネスとの連携が必要なのです。セキュリティーはもはやサイロで運営することができないため、コラボレーションの増加を意味します。また、コラボレーションには、あらゆるレベルで効果的な感情的知性、共感性、リーダーシップが必要である。これは、潜在的なリスクを認識するだけでなく、ビジネス価値の観点からリスクを評価できることを意味します。要するに、セキュリティーに対する考え方は、「NO」の声が聞こえる場所から、「YES、そして、安全に行う方法はこうだ」というのが当たり前の場所へと変化しなければならないのです。

良いセキュリティーがあれば、より速く進むことができる。

その通りです。優れたセキュリティー対策がソフトウェア開発ライフサイクル (SDLC) 全体に十分に統合され、すべての段階で意味のある実用的なフィードバックがチームに提供されると、リスクの監視、管理、最小化、緩和がより適切に行われるようになります。 その結果、システムに構築された信頼性が高まり、全体的な展開が短縮されます。

「決められた」という考え方から離れることができれば、莫大な利益を得ることができます。特に、安全なコーディングの分野があります。安全でないコードを書こうとしている開発者にはまだ会ったことがありません。彼らは正しいことをしたいと思っています。彼らは、機能する安全なコードを書きたいと思っています。しかし、あまりにも多くの場合、私たちは開発者が成功するためにはセキュリティーの「専門家」になる必要があると考えています。しかし、それは真実ではありません。開発者が専門家になる必要はありませんが、開発者全員がより安全になる必要があります。

実際に、説明しましょう。あなたがどこかに車を運転していて、突然、車のダッシュボードがクリスマスツリーのようにライトアップされ、エンジンがストールしたとしましょう。あなたは車を停めて、車を降りてボンネットを開け、問題を解決できる可能性が低いことを知っていました。突然、あなたの後ろに車が停車する音がして、誰かがやってきて、あなたのそばに立ってしばらく見ていました。そして、エンジンのランダムな部分を指差して「そこに問題があります」と言うと、あなたが返事をする前に、彼らは自分の車に戻って、車に乗って走り去ってしまうのです。あなたがたまたま経験豊富なメカニックで、手元に正しい部品を持っていない限り、彼らが問題を指摘するだけでは、あなたを助けるためには何の役にも立たないのではないでしょうか？

欠陥追跡システムからセキュリティー問題についてのメールを受け取る開発者のようなものです。

私はしばらく前に主要なセキュリティーカンファレンスにいましたが、私が訪れたほぼすべてのブースでは、「開発者をセキュリティーに関与させる」ということについて、何かしらの趣向が凝らされていました。その根底にある考えは、開発者がスキャンをして報告を受けることで、何がどこに脆弱性があるのか、より多くの情報を開発者に提供することができれば、もちろん開発者はそれを修正する方法を知っているだろうというものでした。これを聞いたとき、私が最初に思ったのは「頑張ってください！」ということでした。現実には、開発者がそのレベルのセキュリティーの専門知識を求めているのであれば、すでにそれを達成しているはずだからです。

実際のところ、安全なコーディングは大変な作業です。そして、やりがいがあります。そして、それには複数の視点が必要です。機能が満たされていることを確認するためにコードレビューを行うという概念は理解していますよね？では、セキュリティーの専門家と開発者が、脅威のモデル化やセキュリティーレビューのようなことで一緒にパートナーを組むのは良いアイデアではないと考えるのは、本当に大げさなことでしょうか？重要なのは、セキュリティーの専門家は、もはやテストを実行して発見した脆弱性を報告するだけでは済まないということです。そうではなく、開発チームと協力して、バランスを取り、優先順位をつけ、修正するために積極的に働く必要があります。これこそが、共有学習を促進することなのです。

まとめ

つまり、今日のビジネスを成功させるためには、技術的なスキルだけでなく、リスクを軽減するためのより良いコラボレーションを推進するための根性、共感、好奇心を持ったセキュリティーとセキュリティーの専門家に対する新しいチームベースのアプローチが求められているということです。ビジネスリーダーは、このようなコラボレーションを大規模に推進するための環境、プラットフォーム、さらにはインセンティブを提供し、チーム間やパイプラインを通じて信頼を高め、最終的には、より優れた、より安全なソフトウェアをより迅速に提供することにつながるようにする必要があります。

これらやその他のアプリケーションセキュリティーに関する議論については、Application Paranoia ポッドキャストをチェックしてください。

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

継続的なセキュリティーに関する連載の最終回、HCL AppScan - Assure Continuous Security の翻訳版です。

HCL AppScan - 継続的なセキュリティーの確保

2020年9月1日

著者: Colin Bell / SALES DIRECTOR 共著: Rob Cuddy / Global Application Security Sales Evangelist, Kristofer A Duer / Architect for research projects at HCL AppScan

第 1 回目の継続的セキュリティーに関するブログでは、3 つのテーマ分野の概要を説明し、それぞれに 2 つの重要な機能が含まれていることを説明しました。シリーズ最終回となる今回のブログでは、「保証 (Assure)」のテーマと、「測定 (Measure)」と「監査 (Audit)」の能力に焦点を当てていきます。

では、なぜ「アシュア」を選んだのでしょうか？ それは、あまりにも多くの場合、セキュリティーがプロアクティブよりもリアクティブであることに気づいたからです。実際、Ponemon Institute の 2018年の調査によると、サイバーセキュリティーおよび情報セキュリティーチームの 78%が誤ったアラートに対処するために週に 250時間以上（合計で）を費やしていたという驚くべき結果が出ています。私たちはより良い方法で対処する必要があります。正しく行われている適切なセキュリティープログラムは、ビジネスに付加価値を与え、システムへの信頼感を高め、非生産的なことに費やす時間を減らすことができます。すべてのアラートが実際に問題なのかどうかを理解しようとして時間を無駄にするのではなく、セキュリティープログラムの真の保証が必要です。

継続的なセキュリティーでは、プロセスから学び、改善することを目的としています。例えば、あるチームが継続的なサニタイズの問題に悩んでいるとしたら、安全なコーディング教育を強化する必要があるかもしれません。また、ある脆弱性が多くのチームに渡って暴露されている場合は、コーディングガイドラインを修正する必要があるかもしれません。成功するためには、ガイドラインと基準を満たすための管理が確実に行われていることを確認する必要があります。成功を測定するためにはメトリクスが必要であり、目標を確実に達成するためには監査が必要です。

測定

測定能力は、継続的なセキュリティーを成功させるための重要な側面の一つです。このケイパビリティでは、セキュリティーの具体的な側面である測定値と、それらの測定値が互いに関係している関係、およびビジネスとの関係である測定値の両方を調査します。この両方に注意を払い、プロセスの成熟と進展に合わせて正しく適用する必要があります。この能力は、多くの組織でアプローチが異なる点でもあります。例えば、私は、リリース前にアプリケーションをスキャンすることが最も重要な測定値であるというケースを見てきました。残念なことに、これは、スキャンによって発見された結果を重視していません。そう、スキャンは実行されましたが、もし、その結果が何も行われなかった場合、それはビジネスにどのような価値を与えるのでしょうか？一般的に、このアプローチの根本的な理由は、プログラムが PCI DSS などのコンプライアンスのニーズから推進されていることです。

その他の企業は、ポートフォリオ内のアプリケーションの総数と比較して、テストされたアプリケーションの数をコアメトリクスとして評価しています。これらの組織では、多くの場合、「王冠の宝石」や最も重要な重要アプリケーションから開始し、それらがある程度のレベルのセキュリティーポリシーを満たしていることを確認しています。おそらく、アプリケーションが次のフェーズに進む前に、すべての高リスクの問題が緩和されているものと思われます。

より成熟した組織は、脆弱性を修正するための時間を短縮するために測定値を使用し、チームベースの測定値を使用して、脆弱性がどこに出現したか、あるいはどこで作成されたかを判断します。このことは、第５話「アプリケーションパラノイア」のポッドキャストシリーズで、HCL Software の CISO である Joe Rubino 氏とのディスカッションを通じて強調されました。ルビノ氏が重要視していた主要なメトリクスは、カバレッジエリアと範囲、ソース別の脆弱性の特定、特定された脆弱性の種類、過去の傾向と比較して時間の経過とともに新たに出てきたもの、そしてそれらの発見に対してチームがどのように対応していたか、というものでした。

Joe氏はまた、彼のチームにとって重要な指標が「開発チームから何を聞いているか」に関連していることにも言及しています。開発チームからは、脆弱性やセキュリティー全般についての懸念があり、その懸念が彼らの作業負荷にどのような影響を与えているか？セキュリティーチームは、その負担を軽減するために、どのようにプロセスを改善できるのでしょうか？彼の指摘は、これが単なる一方向的なコミュニケーションフローではないことを確認する必要があり、全員が同じチームの一員であると感じていることを確認するための指標を使用する必要があるということです。

どのようなアプローチであれ、最終的に重要なのは、メトリクスがセキュリティーガバナンスの観点から推進されることであり、その逆ではないということです。例えば、ビジネスリスクに基づいてアプリケーションのテストプロセスの概要を説明したり、スキャンにどのようなタイプのポリ シーが適用されるかを決定する安全なコーディングガイドラインを含めることができます。これは、どのようなリスクを受け入れ、どのようなリスクを修正する必要があるかについての決定に直接つながります。ガバナンスがうまくいっていれば、何を測定すべきかをよりよく知ることができ、その情報を使って、私たちが望む結果に影響を与えることができます。

監査

これは、セキュリティー監査の活動にうまく連れてきてくれます。多くの組織では、これは独立した機能であり、重要なアプリケーションのセキュリティーテストやアプリケーションのペンテストを担当しているかもしれません。過去にこのような活動をしてきた経験から、これらのチームは非常に熟練しており、脆弱性を探すことになると、岩が発見されないようにする能力に誇りを持っていることを知っています。

問題は、彼らの作業が長く、何百ものアプリケーションを持っている会社にとっては、規模が大きくならないことです。SDLC で行われたセキュリティーテストを常に活用しているとは限りません。また、実施されているテストの種類をレビューすることもありません。

継続的なセキュリティーでは、監査も重要な要素であり、企業のセキュリティーは、開発から運用に至るまでのセキュリティープログラム全体に責任を持つべきである。監査は、一連の規則や規則に対するコンプライアンスを検証するだけのものではありません。監査とは、ビジネスが健全に機能するように、ポリシー、慣行、手順が正しく実行されているかどうかを検証することです。ペンテストは一つの機能ですが、単独で行うべきではありません。むしろ、収集したメトリクスを見直し、脆弱性の知見を報告書に反映させるなど、企業の全体的なセキュリティー戦略の中に収めるべきです。

SIEM を使用している場合、その情報は、アプリケーションとその露出リスクに関する意思決定を行うためにも活用されなければなりません。すべての活動から情報が収集されると、この情報は、必要に応じてプロセスを変更するためにガバナンスにフィードバックされることがあり、また、フィードバックされるべきである。これは、チームに教育を提供して、セキュリティー意識を強化したり、脅威モデルに影響を与えたり、セキュリ ティ基準やガイドラインを変更したりすることができるかもしれません。このことが意味するのは、監査は、アプリケーションの全体的なリスクを決定する上で重要な側面であるということです。

まとめ

つまり、継続的なセキュリティーの成功を保証するための柱は、監査、測定、ガバナンスが共に働くことである。本質的には、ガバナンスは、プロセス全体でセキュリティーテストがなぜ、どのように行われているかを概説し、メジャーはテストに関する事実を示し、監査は、それが望ましいレベルで機能しているかどうかを確認することです。

今回のブログでは、Assure のテーマと Measure と Audit の機能に注目しました。これで、継続的なセキュリティー連載は終了です。

このシリーズの以前の記事を見逃してしまった方は、こちらからご覧いただけます。

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

第2回: HCL AppScan - 継続的なセキュリティーの構築

第3回: HCL AppScan - 継続的なセキュリティーの強化

2020/8/26 - 読み終える時間: ~1 分

セキュリティーテストの完全性を高める HCL AppScan on Cloud (ASoC) のインタラクティブ・アプリケーション・セキュリティ・テスト (IAST) についての記事 [Leverage IAST to Empower Your Application Security Testing Program]() の翻訳版です。

AppScan: IAST を活用してアプリケーション・セキュリティ・テスト・プログラムを強化する

2020年8月24日

著者: Lalitha Prasad / Group Technical Specialist (SME)

インタラクティブ・アプリケーション・セキュリティ・テスト (IAST) の重要な価値提案は、アプリケーション・セキュリティ・テストを初期段階でSDLCに統合し、開発プロセスの後期に発見されるセキュリティ問題の数を減らすことを可能にするシフトレフトの実践を可能にすることです。このブログでは、HCL AppScan の IAST ソリューションを調査し、それが SDLC にどのように統合されるかを学びます。

私のテストは完了していますか？

長年にわたり、基本的なアプリケーションセキュリティ保護は、動的アプリケーションセキュリティテスト (DAST) と静的アプリケーションセキュリティテスト (SAST) のアプローチで構成されていました。この 2 つのテスト手法は互いに補完し合っていましたが、テスターにとっては、常に口うるさい質問がありました。「自分の分析は本当に完了しているのか」。

ご存知のように、それぞれのテスト手法には限界があります。DAST は実行中のアプリケーションのテストに対応し、潜在的な攻撃者の視点をシミュレートします。一方、セキュリティアナリストや開発者は、総合的なASTを実施して、誤検出がほとんどないか、あるいは全くないようにしたいと考えています。それはどのようにして実現できるのでしょうか？

HCL AppScan on Cloud IAST の世界へ

HCL AppScan on Cloud (ASoC) IAST は、誤検出を最小限に抑え、シフト・レフト戦略の拡大を支援することで、ASTプログラムを強化します。AppScan IAST はスキャナの代わりに、アプリケーション・サーバ内で計測されるモニタリング・エージェントです。その名が示すように、IAST はアプリケーション内で対話的に動作し、QA/DAST プロセス中でもアプリケーションと対話しながら、「ソース」から「シンク」までのすべてを監視します。

IASTはアプリケーションサーバ内で計測されているため、トランザクションデータベースの呼び出し、データフロー、ファイルシステムへのアクセス活動などをすべて監視することができます。IASTは、脆弱性を発見した場合には、明確なトレースコールとリクエストで警告します。これにより、あなたとあなたの開発者は、セキュリティ問題をすぐに特定して修正することができるようになります。

さらに、HCL ASoC IASTは、クリックすることなくインストールすることができます。アプリケーションサーバに IAST を設置するだけで、アプリケーションを監視し、潜在的な脆弱性についてテスターに警告する準備が整います。

詳細

どのようなツールでもそうですが、IASTには利点と限界があります。IASTとその多くの機能の詳細については、私の最近のホワイトペーパーをダウンロードしてください。また、ホワイトペーパーには、クロスサイトスクリプティング (XSS) の脆弱性を特定して修正する方法の実例が掲載されています。

また、HCL AppScan on Cloud をご自身でテストドライブするには、ここをクリックしてください。

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

セキュリティーにまつわる、AppScan シリーズの 3 回目です。HCL AppScan: Intensify Continuous Security の翻訳版です。

HCL AppScan: 継続的なセキュリティの強化

2020年8月24日

著者: Rob Cuddy / HCL

第 1 回目のブログ「継続的セキュリティ」では、3 つのテーマ分野の概要を説明しましたが、それぞれに 2 つの重要な能力が含まれています。このシリーズの第 3 回目のブログでは、「Intensify」というテーマと、「Educate」と「Govern」の能力に焦点を当てています。

継続的セキュリティに関連するテーマに「強化」という言葉を使うのは変だと思われるかもしれません。結局のところ、「激化」という言葉を調べてみると、その定義は簡単に言うと、"become or make more intensify"となります。

では、どのような意味でしょうか。

多くの組織が DevOps のプラクティスを採用している、あるいは採用中であり、それらのプラクティスにセキュリティを組み込むことにも取り組んでいます。これは素晴らしいことなのですが、それだけの取り組みやプロジェクトではありません。パイプラインにセキュリティテストを追加し、結果を共有して「完了」と呼ぶようなものではありません。そうではなく、最初に行った努力を積み重ね、そこから学び、コース修正をしていかなければなりません。さらに、セキュリティチームを超えてセキュリティプログラムを拡大し、組織の開発プラクティスに組み込むことで、セキュリティプログラムを強化することも視野に入れています。

リスクを発見し、軽減する能力を継続的に向上させていく必要があります。要するに、強化するための取り組みは、アプリケーションをより健全に、そして時間をかけてより安全にするために行われているのです。

セキュリティを本当に継続的なものにするためには、セキュリティパラダイムを増幅して拡張する必要があり、その結果、より安全なコードが書かれ、より良いセキュリティプラクティスが守られるようになります。そのためには、より良い教育とより良いガバナンスが必要です。

教育

教育というと、いくつかの異なる側面があり、それぞれが重要である。教育はセキュリティプログラム全体を超越しており、セキュリティが開発、テスト、運用、セキュリティとどこで連携するかによってニーズが異なります。何よりもまず第一に、コードを書いて作業をしているチームのためのものです。

正直に言うと、開発者は通常、安全でないコードを書こうとしているわけではありませんが、何が本当に脆弱なのか、どのようにして悪用が起こるのかについての認識不足に悩まされていることが多いのです。開発者は一般的に、最初から安全なコードを作れるようになりたいと考えています。これには正式なトレーニングが必要になりますが、クラスと並行して開発者は、組織内のチームが実施した脆弱性修正のリポジトリなど、具体的で文脈に沿った例を必要とし、他の人がその恩恵を受けられるようにします。結局のところ、これだけ多くのコードが共有されているのですから、もしあなたが脆弱性に遭遇した場合、他の誰かが脆弱性を持っている可能性は十分にあります。このことは、理想的には、セキュリティプログラムのガバナンスと連携した安全なコーディングガイドラインに反映されるべきです。

組織におけるより広範なセキュリティプログラムを真に推進する明確なステップは、開発チーム内で独立したセキュリ ティチャンピオンを育成し、成長させることです。これを成功させるには、セキュリティ意識とベストプラクティスに関する教育が鍵となります。セキュリティチャンピオンを独立させ、セキュリティチームとの連携を強めることで、企業ベースのセキュリ ティポリシーと実践が確実に管理されるようになる。セキュリティチャンピオンは、より広いチームとして協力し、お互いに学び合うこともできます。

第二の側面は、ツールとプロセスに関するものである。DevOps が要求するペースを維持するためには、コーディング時に支援を提供できるツールを用意することが不可欠である。リリースサイクルの最後に重要なセキュリティ問題が特定され、修正に対応するためにピボットが必要になると、チームはイライラしてしまいます。それよりも、コードがコミットされたときにコードの健全性についての洞察を得ることの方がはるかに有益です。DevSecOps では、自動化と統合が非常に重要です。各チームは通常、微妙に異なる方法でアプローチしているため、ベストプラクティスと統合するための手順についての教育は非常に有益です。

そして、最後に取り組むべきことは予算です。より良く、より安全になるためには投資が必要です。トレーニングを受け、リスクを低減している人に報酬を与えることです。そして、それは単に良い習慣ではなく、実際にはビジネスの全体的な士気を高めることになります。Sonatype による最近の調査では、定期的にセキュアなコーディングトレーニングを受けている開発者は、仕事に満足している可能性が5倍高いという結果が出ています。

ここまで人の話をしてきましたが、次はプロセスの話をしましょう。

統治 (ガバナンス)

継続的セキュリティモデルでは、ガバメントは後回しにされていますが、実際には、セキュリティプログラムが始まるのはここからであることが多いのです。多くの組織がアプリケーションセキュリティを追求するのは、外部からのコンプライアンス要件からくるやむを得ない必要性があるためです。Payment Card Industry Data Security Standard (PCI DSS) やSarbanes-Oxley Act (SOX) は、一般的なコンプライアンスの推進要因の例であり、セキュリティガバナンスと整合性があり、最初の段階で優れた方向性を提供してくれます。課題は、継続的な改善と継続的なセキュリティという目標に到達できるように、プログラムを確実にその先に進めることです。

理想的な世界では、完全に柔軟なポリシーと実践があり、それが完璧に機能して、必要とされる卓越した運用を実現できるでしょう。方針と手順はビジネスの目標に沿ったものであり、自然と便利で安全な結果に向かって進んでいきます。

あまりにも多くの場合、私たちが持っているのは、多くのアラート、通知、監視、優先順位のジャグリングを生み出す、十分な量の自動化です。実際、CriticalStart が実施した 2019 年の調査では、セキュリティ担当者の 70%が1日に10件以上のアラートを調査しなければならないことがわかりました。受信するだけではなく、調査する 誰もが「左遷」する方法を模索している世界では、それらの調査には通常、開発チームが関与しています。そのような場合、35%がスタッフを増やそうとしているか、または大量のアラート機能をオフにしていることが同じ調査でわかりました。

これは、私たちが求めていたものとは正反対の結果です。

前述したように、適切なガバナンスはビジネスを可能にするものです。それはちょうど十分なルールを提供し、ポリシーの遵守、コンプライアンスへの対応、ビジネス目標の達成を確実にします。では、実際にどのようにしてそれを達成するのでしょうか。行動よりも結果を測定することから始めるのです。

簡単な例を挙げてみよう。休日の週末の金曜日の午後遅くです。コードはコミットされ、ビルドプロセスが実行されています。プロセスの一部には、新しいコードの変更を検証するためのセキュリティスキャンが含まれています。そして、それが起こります。クリティカルテストが失敗し、ビルドプロセスが開始され、メールが飛び交い始めます。次に何が起こるのでしょうか。

もしあなたが行動を測定しているのであれば、最初の質問は「いったい誰が悪いコードをチェックインしたのか」、「誰がコミット前にスキャンを実行しなかったのか」、「誰がそのライブラリを追加したのか」などです。この人が修正する必要がある人だという前提があるので、PERSONを見つけることに焦点が当てられています。

代わりに結果を測定しているのであれば、最初の質問はより可能性が高い"What?"です。何が悪かったのか」「何を見逃したのか」「どんなテストを行ったのか目標は、何が起こったのかを理解し、将来的にそれを防ぐことができるようにすることです。ビルドが始まる前に、より多くのスキャンを促すようにプロセスを調整する必要があるかもしれませんし、コードが消費されてレビューされる方法を変更する必要があるかもしれません。

重要なのは、ガバナンスがシステムのコントロールに影響を与える必要があるということです。ガバナンスは、アプリケーションのセキュリティに関する標準とルールの概要を説明しなければなりません。ガバナンスは、「当社の安全なコーディングガイドラインは何か」という質問に効果的に答えなければなりません。ガバナンスとは、ソフトウェアに関して意思決定を行い、期待されることを定義するための構造を形成する、ポリシー、標準、およびプロセスのフレームワークです。本質的には、ガバナンスは、セキュリティテストがなぜ、どのように全体的に行われているかを概説します。

まとめ

今回のブログでは、「Intensify」のテーマと「Educate」と「Govern」の能力に焦点を当てました。このシリーズの最終回では、「保証」のテーマと「測定と監査」の機能を見ていきます。

最後に、このシリーズの過去の記事を見逃してしまった方は、こちらからご覧いただけます。

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

パート2: 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 - 読み終える時間: 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 の無料トライアルページをご覧ください。