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 分

2020年6月18日、OpenNTF 主催のイベントにおいて、HCL から数名の社員が参加して講演を行いました。その際に、今後に向けた取り組みの一つとして、Notes リッチテキストの互換性に関することが紹介されました。便利であり、Notes を特徴付ける項目のひとつであるリッチテキストについて、データの互換性をいかに確保していくかについて、研究がされています。

これについて書かれた英語版ブログ Sharing Domino Data: How Do You Solve a Problem Like Formatted Text? の翻訳版を掲載します。

本記事は、実現された製品に関するものではありません。今後に向けた、研究開発活動の一つであることにご注意ください。

翻訳者注: 概念的な内容について適切な翻訳が難しい部分がありました。理解が難しい場合は原文の参照をお願いします。途中に YouTube への参照があり、本内容の理解の補助となります。

Domino のデータを共有する。フォーマットされたテキストのような問題を解決するには？

2020年6月24日

著者: Paul Withers / Technical Architect, HCL Labs

Domino データを Notes/Domino プラットフォームの外で共有する際に、 Notes リッチテキストの再現忠実性は長い間問題となっていました。この問題について考える場合、一般的な出発点は、Notes リッチテキストのフィールドレンダラ/エディタと Notes リッチテキストアイテムの保存形式となるでしょう。しかし、これらはあまりに厳しい制約事項であり、その中でうまく収まるようなソリューションを見つけることは困難であり、私たちが考えられる範囲を越えています。

HCL Labs では、より根本的なアプローチをとっています。最近、新しいメンバーが入社してきたときには、箱の外で考えるのではなく、箱に火をつけるように指示されました。その結果、誰にでも合うとは限らないアプローチになってしまうかもしれません。しかし、私たちが Project Rosetta (社内の内部的なコンセプト実証プロジェクト) に与えられた使命は、Domino の外で使用するためのフォーマット化されたコンテンツの忠実性を保つための革新的なソリューションを見つけることであり、それにはひとつの必須条件がありました。デジタルソリューションのCTOであるジェイソン・ロイ・ゲイリーは、DNUG のローンチイベントと最近の OpenNTF のウェビナーでその成果を説明しました。40:27-50:44の10分間のプレゼンテーションはこちらからご覧いただけます。

用語について

初期のアクションのひとつは用語について非常に具体的にすることでした。Domino の読者にとって「リッチテキスト」という言葉は、Notes エディタや特定のストレージフォーマットと表裏一体の関係にあります。その結果、私たちは意識的に「フォーマットされたテキスト (formatted text) 」の扱いに言及する努力をしてきました。この件について議論している人には、間違った思い込みを避けるためにも、同じことをすることを強くお勧めします。

この間、2つのラジカルな選択肢がテーブルに残されていました。それは、Notes ではこのコンテンツのために別のエディタ/レンダラが必要になる可能性があるということと、既存のコンテンツがその利点を活用したい場合には、一度だけの変換が必要になる可能性があるということです。また、2つの重要な期待も認識していました。それは Notes リッチテキストを置き換えることを意図したものではないことと、既存の Notes リッチテキストをすべて変換する必要がないことです。なせなら、コンテンツが Notes クライアントでのみ使用されている場合や、サードパーティのソリューションがすでに問題を管理できている場合は、現状を受け入れられるからです。

出発点

Domino 以外の標準的なエディタには何があり、それらはどのようなフォーマットを使用しているのでしょうか？これは単純な質問のように思えますが、明らかになったのは、Notes リッチテキストエディタは 3 つの特定の目的のために使用されており、それぞれが特定のパラダイムと相互運用可能なフォーマットを持っているということです。

"1. 文書処理" (Document processing)

Domino では、ポリシーや手順書のような複雑で厳密にフォーマットされたコンテンツを管理するために、リッチテキストエディタやアイテムが使用されているのを時々見かけることがあります。そのようなコンテンツを扱うアプリケーションでは、変更追跡のような複雑な、文書処理機能を似せた設計がされています。Domino 以外では、このようなコンテンツは通常、Microsoft Word や HCL Connections Docs、Google Docs、Collabora などの共同編集ツールなど、特定の文書処理ツールで管理されています。

長年の抵抗の末、各ベンダーは相互運用性のための標準フォーマットである OOXML に移行しました。このストレージ・フォーマットには、文書処理エディタではオープンに編集できない、著者やタグなどのメタデータが含まれています。しかし、これらのメタデータは固定されており、範囲も限定されています。エディタはカスタムメタデータの操作を許可していません。また、エディタは一度に1つのファイルを編集することしかできません。

「一度保存すれば、どこでも共有できる」という試みにもかかわらず、セキュリティやアクセスの複雑さから、コンテンツがコピーされてしまうことがよくあります。ドキュメントは、すべての画像や埋め込みファイルなどが含まれた、1つの目立たないパッケージとして送信されます。これは一般的に、HTTPや電子メールの送信には大きすぎるファイルの結果となります。そのため、ユーザーはファイルを圧縮するか、Connections のような製品や SFTP のような一時的な転送プロトコルなど、安全なファイル共有ソリューションにコピーする必要があります。

これは非常に特殊なパラダイムであり、事実上メタデータを追加せずにリッチテキスト項目だけでフォームをマッチングさせるというものです。私たちはこれが有効なユースケースであることを認めていますが、狭義のユースケースです。その場でレンダリングしながら、Microsoft Word のような外部エディタで編集できるような形式でコンテンツを保存できないかどうかを調査するのは興味深いことです。しかし、それは現在のスコープとしては適切ではありませんでした。

2. メール

メールは常に Notes/Domino の中核をなすものでした。Domino が発売された当時、メールはまだ広く使われていませんでした。実際、MIME が定義されたのは 1992 年になってからです。しかし、MIME は Domino 以外での相互運用性のためのデファクトスタンダードとなっています。Domino の外からメールを受信した場合、それは MIME として保存されます。Domino ドメインからのメールのみが Notes Rich Text として保存されます。

繰り返しになりますが、特定のメタデータがありますが限定されています。MIME メールの場合、アドレスが保存されるアイテムタイプは Text ではなく、RFC822 Text です。これは Domino 内部では別のデータ型ですが、Notes クライアントは (おそらく) 特定の方法で解釈するようにプログラムされています。それは興味深く、有益な情報です。

ストレージ構造もこのユースケースでは非常に特殊です。メールは送信者のみがソースから参照されます。他の誰もが自分のメールのコピーを受け取ります。すべての受信者が参照する「単一バージョンの真実」を保存しようとしたことはありません。その結果、流通するのは、文書処理と同様に、テキスト、画像、ファイルを含む単一のパッケージとなります。そのため、最近の多くのメールは外部画像を参照したり、Connections Files や Box のような中央サービス上のファイルにリンクしたりしています。

これもまた、非常に特殊なパラダイムであり、アプリケーションの典型的な使用法とは一致しません。Domino がこのコンテンツを Notes リッチテキストではなく MIME として保存し、Notes クライアントに Notes リッチテキストではなく MIME を使用する代替のエディタ/レンダラがあれば、メールの相互運用性はより簡単になるでしょうか？それは現在の調査の範囲を超えています。しかし、繰り返しになりますが、このタイプのコンテンツは対象外となりました。

3. フォームのフィールドでフォーマットされたコンテンツ

第三のシナリオは、フォーム内の任意のフィールドでフォーマットされた内容です。エディタは文書処理ツールでもメールクライアントでもありません。様々なエディタが使用されていましたが、出力は 2 つのカテゴリに分類されます。HTML とマークダウンです。

マークダウンの編集には、2 種類のエディタがあります。最初のタイプは IDE (VS Code) またはスタンドアロン (Joplin) のエディタで、これらはマークダウンファイルのみを編集するように設計されています。文書処理ツールと同様に、これらは対象外です。2 番目のタイプは、OpenNTF の Web サイトやブログの Stephan Wissel のコメントエリアのエディタのように、アプリケーションに埋め込むことができるマークダウンエディタです。これらは Domino アプリケーションのためのエディタの種類とより密接に関連しています。また、TinyMCE のような HTML としてコンテンツを提供するエディタや、Vaadin リッチテキストエディタのようなフレームワーク固有のエディタとも密接に対応しています。

ドキュメントプロセッサやメールエディタとは、他にもいくつかの重要な違いがあります。第一に、コンテンツはコピーされることを意図したものではなく、参照されることを意図したものです。第二に、画像とファイルの添付ファイルは通常別々に保存されているため、コンテンツを表示しているクライアントが何であれ、それらをキャッシュすることができます。実際、WordPress のようなブログプラットフォームでは、これらのリソースを別々に保存することが義務付けられており、エディタはこれを強制しています。Domino でも、Declan Lynch 氏の Blogsphere テンプレートは、アセットを別々に保存するというアプローチをとっています。第三に、1 つのフォームに複数のフォーマットされたテキストエディタがあるかもしれません。第四に、フォーマットされたコンテンツに隣接するメタデータ、つまり他のフィールドはランダムであり、2つのフォームに同じメタデータが含まれることはほとんどありません。

以上の三つが Project Rosetta がターゲットとしたシナリオです。この分析からわかるように、Notes リッチテキストエディタとアイテムの機能には重要な違いがあります。しかし、私たちが対象としたユースケースは、Domino 以外で共有することを意図したコンテンツのみを対象としています。

アーキテクチャーの選択

私たちの概念実証には単純な目標がありました。コンテンツを HTML またはマークダウンとして管理し、理想的には両者を変換して Domino に保存できるようにすることの実現可能性を探ることです。

通常、コンテンツはどちらか一方で入力されます。マークダウンは、意味づけされた基本的なフォーマットで素早く編集するための、素晴らしい柔軟性のあるアプローチであり、利用する場面でも興味深いものになるでしょう。また、ノートブロックのような HTML では容易に利用できない、マークダウンで利用可能な選択肢もあります。しかし、例えばマーケティングや HR のユーザーがコンテンツをマークダウンとして入力することを期待することは現実的ではないことも理解しています。マークダウンと HTML とその逆の間で変換することはこの問題を解決し、Domino のローコードビジョンのために議論されてきたローコード/プロコードの往復アプローチに類似しています。

私たちは、Project Keep の上に API レイヤーを構築しました。私たちが抱えていた課題は、他のフィールドと共にこのコンテンツを送信する場合、どのようにして保存すべきデータ型を決定するかということでした。Keep や Domino HTTP では、添付ファイルはすでにアップロードされ、フィールドデータへのアクセスについては、別個の REST 呼び出しで取得されていした。そこで、ここでも同様のアプローチをとりました。この時点でのフローは、1回の呼び出しでドキュメントを作成し、別の呼び出しで添付ファイルや画像をアップロードし、Content-Typeを "text/ HTML "または "text/マークダウン"としてフォーマットされたコンテンツをアップロードまたは取得するというものです。これは変更できますか？もちろんです。

技術的には、Keep は Java であり、Java では HTML 操作のための標準ライブラリーは JSoupであり、マークダウン変換のための標準ライブラリーはflexmarkです。

サーバー上の2つの出力タイプの間でこの操作を維持する利点は、クライアントが HTML またはマークダウンを話す必要があればよいことです。マークダウンの異なるフレーバー (方言) は将来的に課題となるかもしれませんが、それは先の話です。アプリ開発者にしてみれば、かれらは独自のエディタを持っていて、私たちは一貫した変換を提供するわけです。サーバー上で処理することで、HTML をクリーニングするフェーズも可能になります。これは、現時点ではお話しできませんが、多くの潜在的な革新的な機会を開くことになるので、私はこの方法を維持することを特に強く望んでいます。

確かに、誰も解決できないような問題を解決しようとしているのかもしれません。しかし、研究開発とは、問題を別の方法で考え、これまでに提案されなかった解決策を考え出すことです。イカルスのように、より高く飛ぶ勇気があっても、落ちても構わないということです。

モバイルから Web へ、そして生の HTML /マークダウンの上に適切なエディタで Nomad が何を扱えるかを考え、Webへ、そしてモバイルへと戻っていくデモで、私たちがやろうとしていたことは達成できたと思っています。確かに完全なものではなく、Notes クライアント/Nomad 上での作業が必要になります。そして、私が言ったように、これはすべてのシナリオをカバーしているわけではありません。しかし、より普遍的なものを使って、Notes リッチテキストの特殊性なしに Domino にフォーマットされたコンテンツを出し入れできることを実証しています。これは、非 Domino データベースから NSF にフォーマットされたコンテンツを移行するための新しい方法を開き、非伝統的 (non-traditional) な聴衆にアピールしています。また、セッションの最後に Jason が示したように、フォーマットされたコンテンツのために Notes Rich Text を超えて考えることは、EWS (Exchange Web Services) のような非伝統的 (non-traditional) なクライアントや転送フォーマットのための要件です。

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/27 - 読み終える時間: ~1 分

HCL でも COVID-19 への対応として WFH を実施しています。COVID-19 以前から WFH は日常的に行われていましたが、全社的に実施されてはいませんでした。全員がモバイル PC を保有しているわけでもなく、BYOD で対応せざるを得ない場合も多数発生しました。しかし、HCL では BigFix を導入していたために、BYOD を含めて、スムーズに WHF に移行することができました。これについての英語ブログ HCL's IT Organization Consolidates Six Tools and Slashes Costs with BigFix の翻訳版を掲載します。

HCLのIT組織はBigFixで6つのツールを統合し、コストを削減

2020年6月26日

著者: BigFix Team

HCL グローバル・インフォメーション・テクノロジー (HCL GIT) は、世界 40 の異なる拠点で 9 万以上のエンドポイントを管理しています。24 時間 365 日の運用という大規模なIT組織の典型的な要求に対応するにはリソースを集中的に使用することになります。多くの組織と同様に、複数の管理サイロが作られており、それぞれがエンドポイント上で動作する独自のエージェント、独自のエンジニアリングと運用スタッフ、特定のハードウェアとソフトウェアを持っていたために、それらすべてがITコストを押し上る結果となっていました。

GIT エンジニアリングの Deputy General Manager である Umesh Kad 氏は、この課題について次のように述べています。「6 種類以上の異なるツールを使用していたため、ベンダーが多すぎてエージェントが多すぎ、パッチ適用完了までのサイクルが長引いていたこと、多くの地理的な場所にまたがるさまざまな程度のスケーラビリティ、複数のポートに依存していたこと、広範なスタッフのスキルセット、複数のタイムゾーンのサポート要件、さらには複数のソースからデータを統合する必要があるレポート作成の課題などがありました」。もう一つの大きな課題は、インターネット経由でアクセスする (ローミングしている) コンピュータを可視化できないことで、パッチ適用の遅れや、しばしば手動での介入が発生していたことです。HCL GIT は、Windows、HP-UX、macOS、Red Hat Linuxを実行しているワークステーションやサーバーを効果的に管理・制御できるソリューションを使用して、より自動化された、よりスピーディーなパッチ適用と、インターネット経由でアクセスするラップトップの可視性と制御を必要としていました。

2019 年 7 月に HCL が IBM から BigFix を買収した後、GIT は機能および要件分析に着手し、BigFix が 6 つの異なるエンドポイント管理ツール (SCCM、Flexera Secunia、RedHat Satellite、Flexera Admin Studio、Symantec Wise、JAMF) の代替として使用できることを確認しました。管理ツールが BigFix ひとつになることで、エンドポイント管理プロセスを合理化し、すべてのエンドポイントについて、正しい単一データソースとなりました。

6 つのツールを BigFix に統合することで、GIT は、OS、場所、接続、ステータスに関係なく、すべてのサーバーとワークステーションを管理・制御できる単一のツールを手に入れました。具体的には以下のとおりです。

• 6 つのツールを 1 つに統合し、6 つの異なるツールに関連する年間のソフトウェアとハードウェアのコストを削減しました。
• パッチサイクルを 5 日間短縮し、年間 2700 時間のスタッフ時間を削減しました。
• 15,000 台のインターネット経由でアクセスするワークステーションの可視性と制御を確保し、ファーストパスでのパッチの成功率を劇的に向上させました。
• スキル要件を簡素化し、エンジニアリングの労力とトレーニングコストを削減すると同時に、オペレーションスタッフのスケジューリングを簡素化できました。
• インベントリとパッチステータスの単一の真実のデータソースを作成でき、複数のツールからの面倒なデータ統合を排除できました。
• パッチ適用、コンプライアンス、インベントリに関連する人件費を 25 ％削減し、5 人のスタッフを新しい IT イニシアチブやプロジェクトに再配置できました。

さらに、2020 年初頭に HCL の従業員の大部分がリモートワーカーになったとき、GIT は答えを持っていました。BigFix です。GIT は容易にサポートを拡大することができ、従業員の自宅にあるワークステーションを可視化して制御し、企業ネットワーク上にあるかのようにパッチを当てることができました。BigFix によって、HCL は費用対効果が高く拡張性の高いエンドポイント管理ソリューションを導入し、効果的で安全なワーク・フロム・ホーム戦略をサポートしています。

2020年7月1日 午前1時 (日本時間) からのウェビナー (リプレイあり) では、GIT の BigFix 導入を支援した BigFix ラボサービスコンサルタントの Jason Walker 氏が、導入について説明します。詳細については、以下のリンクをクリックしてください。

Webinar: 6つのツールを1つに：IT管理ツールを統合するケーススタディ (From Six Tools to One: A Case Study in Consolidating IT Management Tools)

BigFix の詳細については、www.bigfix.com をご覧ください。

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

2020年6月23日、「クラウドネイティブな HCL Digital Experience の新リリースでビジネスクリティカルな状況に対応」のニュースを発表しました。

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

2020年6月22日、「HCL Software、ビジネスの機動性を加速させるバリューストリーム管理機能を備えた DevOps を発表」のニュースをリリースしました。

先日、ブログで紹介した「HCL Secure DevOps 製品の名称一部変更」と同件です。

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

2020年6月18日、HCL Unica 12.1 に関するニュースを発表しました。

• 2020年6月18日: HCL TECHNOLOGIESは、新しい UNICA プラットフォームで、大規模プレシジョンマーケティングを次のレベルに引き上げます

これにあわせて、12.1 の資料を公開しました。

ダウンロードはこちら: 製品情報: HCL Unica v12.x 製品紹介資料

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」をチェックアウトしてブックマークしてください。