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

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

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

2020年7月16日

著者: Shahar Sperling / Chief Architect at HCL AppScan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これは良い状況です。

詳細

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

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

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

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

2020年7月13日

著者: Shahar Sperling / Chief Architect at HCL AppScan

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

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

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

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

静的ではなく動的に

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

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

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

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

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

決定、決定

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

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

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

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

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

より効果的に

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

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

詳細は

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

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

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

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

2020年7月8日

著者: Shahar Sperling / Chief Architect at HCL AppScan

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

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

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

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

ルールについて

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

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

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

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

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

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

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

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

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

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

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

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

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

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

詳細はこちら

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

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

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

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

2020年6月22日

Eitan Worcel / Product Lead, AppScan

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

XSS とは何か？

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

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

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

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

XSS の自動識別

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

XSS Analyzer の学習機能

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

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

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

AppScan Enterprise のデモ

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

2020/6/27 - 読み終える時間: 3 分

セキュリティー対策の重要性は WHF が実施されてから、さらに高まってきています。HCL AppScan の主な機能はアプリケーションの脆弱性検査ですが、脆弱性検査を大幅に効率化することで、間接的に WFH のよるさまざまな負荷を軽減する効果もあります。このことを解説した英語版ブログ 4 Key Take-Aways: Manage Application Security More Effectively in Your Enterprise の翻訳版を掲載します。

企業のアプリケーションセキュリティをより効果的に管理する 4 つの重要なポイント

2020年6月24日

著者: Neil Jones / Senior Product Marketing Manager for HCL Software’s AppScan solution

7 月 14 日、HCL AppScan チームは Managing Application Security in a Global Enterprise と題したウェビナーを開催します (イベントへの登録はこちら から) 。

このセッションでは、HCL Software の CISO である Joe Rubino と HCL AppScan の VP である Dave Munson が、以下のトピックについて議論します。

• グローバル組織におけるセキュリティの変化のペースに対応し続けること。
• 大量のセキュリティ環境における「アナリストの疲労」に対処するためのベストプラクティス。
• 今日の「在宅勤務」環境におけるセキュリティ管理の維持。
• 人工知能技術がアプリケーション・セキュリティ・テストに与える影響

私のブログの目的は、ウェビナーで発表されるそれぞれのトピックに関連した 4 つの重要な「取り除くべきこと」 (Take-Out) を提供することです。ぜひ、より多くのことを学んでいただきたいと思います。

セキュリティの変化のペースに追いつく

私が出会ったアプリケーションのセキュリティ統計の中で、これほど説得力のあるものはありません。TechBeacon が最近まとめたレポートによると、ウェブアプリケーションの 92%が、潜在的に悪用される可能性のあるセキュリティ脆弱性を含んでいることがわかりました。

また、報告書によると、脆弱性の 86%が公開から 24 時間以内にパッチが利用可能な脆弱性であったにもかかわらず、ウェブアプリケーションの脆弱性にパッチを当てるのに平均 38 日かかっていることがわかりました。これらの調査結果から、セキュリティチームが急速な変化のペースに追いつくのに困難な時間を費やしていることが推察できます。

排除すべきこと #1.

変化のペースは速くなる一方です。組織は、セキュリティの急速な変化のペースに適応するためのベストプラクティスを実施する必要があります。

アナリストの疲労に対処する

アナリストの疲労は、正式に「もの」になっています。Healthcare IT News 誌に掲載された最近の調査によると、80% 以上のセキュリティアナリストが、セキュリティ・オペレーション・センター (SOC) では、前年にアナリストの離職率が 10% から 50% の間であったと報告しています。

さらに、回答者の 70％が、1 日に 10 件以上のアラートを調査する必要があると報告しており、前年の 45％ から増加しています。また、回答者のうち、主な担当業務はセキュリティ脅威の分析と修正であると答えたのは、前年の 70% から 41% にとどまりました。

排除すべきこと2.

アナリストの疲労に対処するための戦略を採用して、アナリストを維持し、能力を高める必要があります。

在宅勤務環境への適応

MIT の Erik Brynjolfsson 教授が率いる学術チームは、2020年 4月のワーキングペーパーの中で、COVID-19 のパンデミックの結果、調査回答者の約半数が在宅勤務をしていることを明らかにした。特に、オフィスに通勤する代わりに在宅勤務に切り替えた人の割合は、当時の回答者の約 34％ を占めていた。また、COVID-19 流行前に在宅勤務をしていたと回答した人の割合は約15％で、現在も継続している。この変化は、ニューヨークタイムズ紙が 2020 年 6 月に "What if Working from Home Goes on...Forever?" と題した記事を掲載したほどで、注目すべきものなのです。

排除すべきこと #3.

ソフトウェア開発プロセスでは、当面の間、リモートワークを行う可能性が高いため、新しい環境でも生産性とセキュリティを維持できるようにする必要があります。

AI技術でアプリケーションのセキュリティを強化する

上記のセクション 1 で紹介した Healthcare IT News の調査では、回答者の半数以上が、総所見の 50% 以上を占める偽陽性所見を調べなければならなかったと報告しています。想像してみてください-真陽性のアラート数が増加しているだけでなく、偽陽性のアラート数も増加しているのです。

HCL AppScan の Intelligent Finding Analytics (IFA) 機能のような人工知能/機械学習技術は、偽陽性所見とノイズを 90% 以上削減するのに役立ちます。IFA については、YouTube の簡単なビデオをご覧ください。

排除すべきこと #4.

機械学習の分野は常に進化しており、お客様の専門的なニーズに最も適した技術を導入する必要があります。人工知能/機械学習技術は、SOC チームの生産性を向上させながら、組織が最も重要な脆弱性に焦点を当てるのに役立ちます。

7月14日に参加してみませんか？

2020年7月15日 午前零時-01:00 (日本時間) に開催されるライブ・ウェビナーに参加することで、上記の各排除すべきことについてより詳しく知ることができます。このセッションはライブイベントの後にリプレイでもご覧いただけます。皆様にお会いできることを楽しみにしています。

2020/6/19 - 読み終える時間: 3 分

AppScan V10.0.1 が 2020年6月18 日にリリースされましたが、その機能拡張についての解説 (AppScan V10.0.1: HCL’s Ongoing Commitment to Fast, Accurate, Agile Security Testing) が英語版ブログに ポストされました。その翻訳版を掲載します。

AppScan V10.0.1: 迅速、正確、アジャイルなセキュリティテストへのHCLの継続的な取り組み

Eitan Worcel / Product Manager AppScan

AppScan V10.0.1 でアプリケーションのセキュリティテストを強化する

AppScan V10が発表されたのが3ヶ月以上も前のことだとは信じられません。3月17日の私のブログでは、V10の強化点をすべてまとめていましたが、ご記憶にあるかもしれません。この3ヶ月間に多くの変化があったことには同意できますが、技術革新に対するHCL AppScanのコミットメントは極めて一貫しています。そして、AppScanチームが在宅勤務という新たな通常の仕事にもスムーズに適応したことを誇りに思っています。

このブログでは、製品ライン別にAppScan V.10.0.1の主な機能強化にスポットを当てています。また、6月30日に開催される特別イベント「AppScan Tuesdays」にもぜひご参加ください。

HCL AppScan Enterprise V10.0.1の拡張機能

AppScan Enterprise の V10.0.1 の強化点は以下の通りです。

• 自動アクションベースの探索の精度とカバレッジを向上させる新機能。
• 以下を含む一連の新しいテスト機能。一連の新しいテスト機能には、より正確なテスト結果を得るためのエラーページ検出の改善、対象範囲を拡大するためのディレクトリ推測オプションの数の増加、新しいセキュリティルールが含まれます。
• 頻繁に発生するissueを統合するissue統合機能により、よりコンパクトな結果が得られ、レビューと管理が容易になります。さらに重要なことは、統合することで、必要な重要な詳細情報を失うことなく、全体の課題数を減らすことができます。
• 最新のDISA Standard Report V4R10をサポートする新しいコンプライアンスレポート。

AppScan Enterprise の拡張機能の詳細については、「最近のアップデート」ページをご覧ください。

HCL AppScan Standard V10.0.1 の拡張機能

AppScan Standard の V10.0.1 の強化点は以下の通りです。

• AppScan Connectのアップデートにより、スキャンファイルに加えて、AppScan Enterpriseからテンプレート (SCANT) ファイルをダウンロードできるようになりました。AppScan on CloudおよびAppScan Enterpriseからのファイルダウンロードに関連したAppScan Connectの検索機能も強化されました。
• 自動アクションベースの探索機能のカバレッジが向上し、より正確になりました。
• より正確なテスト結果を得るためのエラーページ検出の改善、カバレッジを高めるためのディレクトリ推測オプションの数の増加、マルチステップテストのための検証の強化、新しいセキュリティルールなど、一連の新しいテスト機能が含まれます。
• 頻繁に発生するissueを統合するissue統合機能により、よりコンパクトな結果が得られ、レビューと管理が容易になります。さらに重要なことは、統合することで、必要な重要な詳細を失うことなく、全体の課題数を減らすことができます。
• 最新のDISA Standard Report V4R10をサポートする新しいコンプライアンスレポート。

AppScan Standardの機能強化の詳細については、「最近のアップデート」ページをご覧ください。

HCL AppScan Source V10.0.1 の機能強化

V10.0.1 AppScan Source の強化点は以下の通りです。

• 4つの新しい言語のサポート。Scala、React.JS、Kotlin、Swift。
• コマンドラインインターフェースレベルのデルタ機能により、スキャンの間に何が修正されたか、何が新しく導入されたかを簡単に確認できます。
• 最新のDISA標準レポートV4R10をサポートする新しいコンプライアンスレポート。
• クラウドライセンスサーバーで作業する際のプロキシのサポートを強化し、オンプレミスのライセンスサーバーで自己署名証明書を使用できるようにしたユーザーの生活の質の向上。

AppScan Sourceの機能強化の詳細については、「最近のアップデート」ページを参照してください。

2020年6月 HCL AppScan on Cloud の機能強化

AppScan on Cloud (ASoC) のカレンダー第 2 四半期の機能強化には以下のようなものがあります。

• 4つの新しいSAST言語のサポート。Scala、React.JS、Kotlin、Swiftの4つの新しいSAST言語のサポート。
• 上記の「AppScan Enterprise」のセクションで言及されているすべてのDASTの機能強化。
• セキュリティ、安定性、パフォーマンスを向上させる強化された IAST Java エージェント。
• Visual Studio 2017およびVisual Studio 2019 C++プロジェクトのサポート。
• AppScan on CloudのAPIにWebhooks機能が追加され、ASoCで発生したイベントに関する通知を受信できるようになりました。
• 多数のユーザー・エクスペリエンスの強化。

AppScan on Cloudの機能強化の詳細については、「最近のアップデート」ページをご覧ください。

AppScan Tuesdays」特別イベントに参加して詳細を知る

上記の機能強化の詳細については、6月30日に開催される「AppScan Tuesdays」のスペシャルイベントにご参加ください。直接参加できない場合は、同じリンクから再生が可能になります。 https://youtu.be/taNz-jqkLcA AppScanの最新の開発情報をキャッチアップするには、YouTube Liveチャンネル「This is AppScan」をチェックアウトしてブックマークしてください。

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

HCL はアプリケーションのセキュリティー確認を行うためのツールである AppScan などを開発・販売しています。アプリケーションのセキュリティーの重要性は改めて説明するまでもありませんが、だからこそ HCL Software はこの分野に (も) 重点的な投資を行っています。そのあたりを説明した英語版ブログの 5 Key Reasons to Invest in Application Security Testing の翻訳を掲載します。

アプリケーション・セキュリティー・テストに投資する5つの主な理由

著者: Neil Jones / Senior Product Marketing Manager for HCL Software’s AppScan solution

先日開催された「IT Spending Forecast, 1Q20 Update- View from the Peak」と題したウェビナーでは、アナリスト企業であるガートナー社は、2020年のIT支出全体が2019年と比較して8%減少すると予測しています。つまり、ガートナーは今年、3.4兆ドル（そう、1兆ドル！）以上が情報技術に費やされると予測しています。

マクロなIT購買動向にもかかわらず、ガートナーは今年はITセキュリティーソフトウェアの支出が約10%増加すると予測しています。私のブログの目的は、なぜアプリケーション・セキュリティーがミッション・クリティカルな投資とみなされるべきなのかを、あなたとあなたの経営陣が理解できるようにすることです。

アプリケーションセキュリティー：5つの重要な理由

今日のダイナミックなビジネス環境では、どのようにして経営陣にアプリケーションセキュリティーへの投資を促すことができるでしょうか？少なくとも 5 つの重要な理由があります。

理由 1: アプリケーションは、これまで以上に顧客のビジネスへのライフラインであること

Mobile App Daily の最近の調査によると、企業は主に顧客サービスの向上（回答者の38%）、Web体験の拡大（26%）、収益の増加（24%）のためにモバイルアプリケーションの存在を活用していることが明らかになりました。残りの12%の組織は、主に顧客ロイヤルティを促進するためにモバイルアプリケーションを利用していました。これらがすべて重要なビジネスモチベーターであることに同意するでしょう。

そして、その特定の調査は、ちょうどCOVID-19の経済的影響が世界経済に影響を与え始めた2020年3月に更新されました。顧客がモバイルやWebアプリケーションを介して顧客とのやり取りのほとんどすべてを行うようになったときに、ミッションクリティカルなアプリケーションがセキュリティーの脆弱性によってダウンしていたとしたら、あなたの組織に与える影響を想像してみてください。

理由2：2020年には、貴社のブランドこそが最も重要であること

あなたの個人的なビジネスの大半を今年行った企業を考えてみてください。その企業は、あなたが最も信頼している企業である可能性が高いでしょう。ブランドエージェンシー Underscore のニール・スタンホープ氏は、「ブランドはこれまで以上に重要に (Brand Matters…more than ever,)」と題した記事の中で、「ブランドの評判とは、既存の顧客からだけでなく、市場全体から見て、あなたの会社がどのように認識されているかということです」と説明しています。危機の時には、人々はすぐに自分が知っていることや信頼できること、あるいは市場の権威や口コミにどのように働きかけるかに目を向けます。"

さて、あなたが好んで利用している他社サービスのひとつで、このような前例のない時代ですが、重大なセキュリティー侵害を受ける事象が発生したらどうなるか想像してみてください。そのビジネスに対するあなたの印象はどのように変わるでしょうか？あなたのお気に入りのビジネスは、平均 392 万ドル（Ponemon Instituteの調査に基づく）の推定データ侵害コストに直面しただけでなく、その風評被害も甚大なものになったでしょう。これらはすべて、顧客が一般的にそのサービスと直接対話することができないタイミングに発生していたことでしょう。

理由3：脅威となる行為者は休暇を取らないということ

2020年には、世界の多くが限られた営業時間とワーク・フロム・ホーム環境に適応していますが、サイバー脅威のアクターは、これまでと同様に生産性の高い活動を行っています。TechBeacon がまとめたITセキュリティーの調査では、Web アプリケーションの最大 92% に悪用される可能性のあるセキュリティー上の欠陥や弱点が含まれており、企業が Web アプリケーションの脆弱性にパッチを当てるのには、深刻度に関わらず平均 38 日かかっていると報告しています。米国国土安全保障省 (DHS) のサイバーセキュリティー・インフラセキュリティー庁 (CISA) と英国の国立サイバーセキュリティーセンター（NCSC）の共同アラートでは、今年 4 月に相次いだ重大なサイバー攻撃が詳細に報告されています。

そして、悪意のある行為者が悪用するアプリケーションには事欠かない。Webサイト「アプリのビジネス」では、2019年第1四半期の時点で、ユーザーは260万個のAndroidアプリと220万個のiOSアプリの中から選択できるアプリを持っていると推定しています。そして、それらのアプリはすべて、悪意のあるアクターから保護される必要がありました さらに、2018年だけで1940億のアプリダウンロードが行われたと推定されています。

最初からより安全なコーディングを奨励するために、私が勤務している会社では、コーディング中にセキュリティーの脆弱性を検出する無料のコードエディタ拡張機能「HCL AppScan CodeSweep」を提供しています。上のリンクをクリックすると、対応しているCodeSweep言語のリストを見ることができます。また、CodeSweepについて詳しく知るために、YouTubeの簡単なビデオを見ることもできます。

理由4：影響力の高い脆弱性に焦点を当てるのは簡単ではないこと

アプリケーション・セキュリティー・テスト技術の最も強力な利点の一つは、最も重要な脆弱性、特に組織のインフラに影響を与える可能性が最も高い脆弱性に焦点を当てることができることです。最初のアプリケーション・セキュリティー・スキャンのセットアップがいかに容易かについては、HCL AppScan Standardのビデオをご覧ください。

理由5: データ・プライバシーに関する規制が次々と導入されること

カリフォルニア州消費者プライバシー法（CCPA)

米国では、National Conference of State Legislatures (NCSL) が州別の民間企業のデータセキュリティーに関する法律のリストを管理しています。

その中でも最も顕著なものの一つが CCPA で、「合理的なセキュリティー手順と実践を実施し維持する義務に違反した」ことが原因で発生した違反行為に対して、対象となる企業に罰則を科すことができます。同法は、どのようなセキュリティー手順と実践が「合理的」とみなされるべきかを定義するまでには至っていませんが、カリフォルニア州は以前に、合理的なセキュリティー実践を構成するとみなすセーフガードの概要を説明しています。

これらのセキュリティー対策は Center for Internet Security が公表している20のデータセキュリティー対策に基づいています。 #CISリストの第4位は、継続的な脆弱性評価と修復であり、リストの第18位は、アプリケーション・ソフトウェア・セキュリティーである。これらの対策は、どちらもアプリケーション・セキュリティーに直接関連しています。(CISのリンク先では、アクセスするためにログインが必要な場合があることに注意)。

NYDFS サイバースセキュリティー規則（23 NYCRR 500)

ニューヨークの NYDFS の Cybersecurity Regulation 500 は、特に金融機関に焦点を当てています。NYDFSは、対象となる金融機関に対し、詳細なサイバーセキュリティー計画の導入、最高情報セキュリティー責任者（CISO）の指定、包括的なサイバーセキュリティーポリシーの制定、サイバーセキュリティー事象に関する継続的な報告システムの開始と維持を求めている。この規則はまた、Section 500.08 に、内部および外部アプリケーションに関する具体的な文言を含んでいる。

NYDFS の Section 500.08 には、以下に要約される特定のアプリケーション・セキュリティー要件も含まれている。

"(a) 各対象事業体のサイバーセキュリティープログラムには、対象事業体が利用する社内開発アプリケーションの安全な 開発手法の使用を確実にするために設計された文書化された手順、ガイドライン、および基準が含まれ、また、対象事業 体の技術環境のコンテクスト内で、対象事業体が利用する外部開発アプリケーションのセキュリティーを評価、評価、 またはテストするための手順が含まれているものとする。

(b) このような手順、ガイドライン、および基準はすべて、対象事業体の CISO (または適格な指名者) が定期的に見直し、評価し、必要に応じて更新するものとします。

PIPEDA と GDPR

米国以外の国では、カナダの個人情報保護・電子文書法 (PIPEDA, The Personal Information Protection and Electronic Documents Act) や欧州の一般データ保護規則 (GDPR、General Data Protection Regulation) などの規制が増えています。カリフォルニア州のアプローチと同様に、カナダでも遵守すべき特定のセーフガードは規定されていませんが、詳細についてはこちらをご覧ください。また、GDPRがアプリケーション・セキュリティー・テストに与える影響について説明している最近のビデオもご覧ください。

アプリケーション・セキュリティーはコンプライアンスへの取り組みの一つの要素に過ぎず、組織は常に包括的な計画を策定する必要があることを常に念頭に置いておく必要があります。

アプリケーション・セキュリティー・テストを実施する準備はできていますか？

アプリケーション・セキュリティー・テストの効果をよりよく理解できましたか？HCL AppScan on Cloud の30日間の無料トライアルに今すぐ登録して、アプリケーション・セキュリティー・テクノロジーをご自身で試すことができます。また、当社のアプリケーション・セキュリティー・ソリューションの詳細なデモについては、当社までお問い合わせください。皆様とお会いできることを楽しみにしています。

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

2020年5月7日、英語版ブログに "Empower Your Developers to Manage Application Security Vulnerabilities on their Own" が掲載されました。その翻訳版を掲載します。

開発者がアプリケーションセキュリティーの脆弱性を自分で管理できるようにする

Florin Coada

HCL

過去数年間、誰もがセキュリティーをより真剣に受け止めていることは心強いことです。個人レベルと企業レベルの両方 (およびその間のすべて) で、ユーザーがセキュリティー侵害の潜在的な被害者にならないようにと、関心がさらに高まっています

私は「セキュリティー違反 (cyber-attack)」ではなく「サイバー攻撃 (security breach)」と言いたくなりましたが、実際には、多くの場合、これらは複雑な攻撃ではなく、まったく攻撃ではありません。誰かが基本的なことをカバーするのを忘れており、攻撃者や好奇心の強い個人がシステムの弱点を悪用している。デフォルトの資格情報の変更を忘れ、管理ポータルへの匿名アクセスを許可し、外部からのデータを消去しない例がいくつかあり、この手のことが多数あります。

アプリケーションセキュリティーの台頭

企業がこれらのミスを回避し、頭痛の種になる前にそれらを見つけることができるツールの大きな市場があります。最近多くの注目が集まっている分野の1つは、アプリケーションセキュリティーです。BA や Equifax などで発生した最近の高レベルの違反により、このセキュリティーセグメントが拡大し、注目が集まっています。

ただし、アプリケーションセキュリティーは興味深い課題です。私たちのゴールは、開発者がより良いコードを記述し、コードのバグのリリースを回避し、潜在的なセキュリティー違反を防ぐことを支援することです。

これにはいくつかのアプローチがあり、それらにはすべてメリットがあります。昔ながらのアプローチでは、セキュリティーチームが脆弱性を発見するために活用したツールを利用し、その後、脆弱性のリストを開発者に送信して修正してもらいました。

開発者に脆弱性を修正する力を与える

最近、状況は少し変化しました。より最近のアプローチは、自動化ツールがセキュリティーに代わってこの分析を実行し、開発者が結果を受け取って、問題を自分で修正できるようにすることです。これは簡単に聞こえますが、このプロセスをセットアップし、開発者に、ツールが生成する何百もの問題のどれを優先すべきかを教育することは、非常に困難な場合があります。

アプリケーションセキュリティープログラムを開発チームに展開した人なら誰でも、簡単に受け入れられる話ではないことに同意するでしょう。その結果として、一部の組織では対局にある別のアプローチを試すことにしました。そもそも問題がなければツールを使用する必要はありません。ツールを使用するにしても修正すべき発見事項が少なくなるはずです。

入力を無害化し、信頼できるコンポーネントを使用する

そもそもセキュリティーの問題が発生しないようにするには、ベストプラクティスについて人々を教育する必要があります。アプリケーションのセキュリティーに関して、私はこのアドバイスを次のように要約します。「入力をサニタイズする」と「信頼できるコンポーネントを使用する」です。アプリケーションのセキュリティー教育は素晴らしいように聞こえますが難しい問題です。これらのトレーニングはすべて、仮想の (場合によっては実際の) 教室で行われます。もしあなたが私のような人なら、仮想学習は魅力的な教育アプローチかもしれません。しかし、日々取得する知識を使用しない限り、次のステップに進むと簡単に忘れてしまいがちです。

どちらのアプローチにもメリットがあり、さまざまな課題が伴いますが、私の個人的なお気に入りは、物事を学ぶことです。ここで、私たちは何年にもわたって消費者ベースのテクノロジーで使用されてきたコンセプトを使用することに決めました。誰もがスペルチェッカーとその機能に精通しており、書かれたテキストを作成するときに、誰もがその赤い下線を避けたいと思っています。そのアプローチと同様に、 AppScan CodeSweepを作成しました。CodeSweepはVS Codeで動作する AppScan (完全無料) の最初のコミュニティエディションです。

「自分のコードは本当に危険か？」

CodeSweepの目的は単純です。コードを記述しているときに開発者が問題を見つけやすくし、問題を修正する方法がわかり、適切な質問を行い、最初の段階でセキュリティーの問題を回避できるようにすることです。私たちの目標は、新しいセキュリティー・スペシャリスト・ツールを作成することではありません。目標は、コードが本当に危険であるかどうかを直感的に訓練し、コードのどの要素がそうすることができるかを説明するツールを作成することでした。この質問に答えれば答えるほど、ツールに促されることなく、将来的に分析を実行できる可能性が高くなります。ここに短いデモがあります。

YouTube: HCL AppScan - Introducing HCL AppScan CodeSweep

この最終結果、優れたセキュリティープラクティスを学ぶことができます。長時間のクラスルームスタイルのレッスンを受講することや、コードで何かを見つけたときにセキュリティーによって指摘されるのを待つこともありません。

開発者としてあなたは何もこれまでと異なることを行う必要はありません。セキュリティーからの長いレポートも、仕事の流れを壊すトレーニングもありません。コードを記述して、自分の質問に答えるだけです。適切な質問をするタイミングを示すべく私たちは待機しています。

もっと詳しく知る

以上のことはしっかりしたアプローチのように聞こえましたでしょうか。実際に動かして学びたい、そして開発者としてのセキュリティーについてもっと学びたい場合は CodeSweep のページに行ってみてください。

Visual Studio Marketplace: HCL AppScan CodeSweep

私たちはユーザーやこのトピックに関心のある人と話すのが大好きです。コミュニケーションを取りたい場合はコミュニティーに参加することをお勧めします。

Slack: CodeSweep Community