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

継続とは習慣であり文化であり、それがない状態から変えていくことは難しいものです。特に組織においては。アプリケーションのセキュリティー維持について「継続性」をテーマにした英語版ブログ AppScan ? It's Time For Security To Be Continuous Too の翻訳版です。

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

2020年7月22日

著者: Rob Cuddy / HCL

継続的であること (Continuous)。

DevOps に長く携わっている人なら、この言葉を聞いたことがあるでしょう。これは、私たちがやろうとしていることの本質です。継続的という言葉は、ほぼすべての能力領域を説明するために使われています。考えてみてください。Continuous Integration、Continuous Build、Continuous Deployment、Continuous Testing、Continuous Delivery、Continuous Monitoring などを考えてみてください。

しかし、まだ追いついていない分野があります。

今日では、個人情報とデータのプライバシーがこれまで以上に重要になっており、特にオンラインでのやり取りが増えています。データの収集と使用に関する規則がより厳しくなり、GDPR、NYDFS、CCPA などの規制により、アプリケーションのセキュリティの向上が求められています。そして、これらの規制は違反者に深刻な結果をもたらします。

これはすべて、継続的なセキュリティが前面に出てきていることを意味しています。しかし、継続的セキュリティとは何でしょうか？

継続的セキュリティとは何か

オンライン検索をすると、ほとんどの議論は、セキュリティテストをパイプラインに統合することと、フィードバックを提供することの 2 つの主要なアイデアに焦点を当てていることがわかります。さらに、これらの活動を開発者が利用しやすい方法で実施することについても議論されています。この 2 つの分野は、DevSecOps の主要な構成要素でもあります。しかし、デプロイを自動化することが DevOps を行うことと同じではないのと同じように、パイプラインでテストを実行してレポートすることは継続的セキュリティではありません。

継続的セキュリティとは、それ以上のものであり、対処すべきいくつかの異なる能力領域があり、それらのすべてがパイプラインでの開発と一致しているわけではありません。実際、私たちは、大きな違いをもたらす6つの能力があることを発見しました。私たちは、これらを3つのテーマ分野に整理しました。これらのテーマとカテゴリは以下の図 1 のとおりです。

図 1：継続的セキュリティのテーマ

重要な継続的セキュリティテーマ

この短いブログシリーズでは、テーマごとに順番に深く掘り下げていきます。今のところは、これらの領域とその意味を紹介します。

Construct は、想像できるかもしれませんが、私たちがどのように物を作っているかを最も直接的に扱っています。2 つの機能には、Design と Automate というラベルが貼られています。設計では、最初から、そして SDLC 全体を通して、セキュリティを含むという概念を伝えたいと考えています。これには、計画、モデリング、優先順位付けなどが含まれます。自動化機能は、ほとんどの人がDevOps や DevSecOps で始めるところですが、自動化は、単に規定の方法でテストを実行するだけのものではありません。それには、動作や意思決定も含まれます。

Intensity (強化) この分野では、自分たちが行っていることをいかにしてより良いものにするかということがすべてである。集中化は、最適化に必要なプロセス、手順、学習に対処するのに役立ちます。教育能力は、コードの品質だけでなく、見積もりやトレードオフの決定を継続的に改善するために必要です。教育は、次のような疑問に答えるのに役立ちます。「チームが成功できるようにするにはどうすればいいのか」という質問に答えるのに役立ちます。Govern 機能は、データを効果的に動かし、自信を持って意思決定を行うことを可能にします。Govern は、プロセスを検証し、ポリシーとプロジェクトのバランスをとることで、生産性を向上させることができます。

Assure この領域は、SDLC 全体に影響を与える、より良い、より情報に基づいた意思決定を行うために、持っているデータと情報を使用することがすべてです。監査と測定の機能は、ビジネスを推進するためにデータを活用することを目的としています。例えば、監査では、ペンテストチームからの情報が開発者のバックログに入っていませんか？ 測定を行う際に、リスク管理に最大の利益をもたらす主要な測定基準と測定方法は何かを知っているだろうか？ これらの能力は、リスクとスピードのバランスが取れているかどうかを判断するのに役立ちます。

これらの各分野については、別のブログでさらに深く掘り下げていきますので、ぜひシリーズをお読みいただき、ご意見をお聞かせください。また、Brighttalkでの最近のウェビナーをご覧いただくか、Buzzsprout、Apple Podcasts、Spotify、Google Podcasts でご覧いただけるApplication Paranoia PodcastのEpisode #7をお聴きいただくことで、Continuous Security に関するコメントについてより多くの考えをお聞きいただくことができます。

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

Jira や ServiceNow など複数の仕組みを利用している環境では、そのプロセス処理が煩雑になりがちで、ルールの遵守やミス誘発の観点からしっかりした運用管理の仕組みが必要です。HCL Launch は統合された運用指示を実現できます。今回は、その機能のひとつである外部承認機能についての解説です。英語版ブログ External Approvals in HCL Launch の翻訳版です。

HCL Launch の外部承認機能

2020年7月22日

著者: Diego Villafuerte / Solutions Specialist

私たちは、継続的デリバリプラットフォームである HCL Launch を使用している人たちの傾向に気づきました。多くのお客様は、デプロイ前に変更要求がいくつかの定義された基準を満たしているかどうかを検証するために、Jira や ServiceNow などのサードパーティのツールを使用しています。これはガバナンスのギャップにつながり、CR のステータスをチェックしてプロセスをグリーンライト化するために手動で承認する必要があります。この方法は機能しますが、理想的な方法ではありません。だからこそ、自動化するために HCL Launch を開発しました。

7.1.0.0 では、プロセスを自動的に検証するために使用するツールの汎用テンプレートである外部承認機能 (External Approvals) を追加しました。外部承認プロセスは、既存の承認プロセスよりも一般的なプロセスのようなもので、エージェント上で実行され、プラグインのステップにアクセスすることができます。現在のセキュリティスキームに沿って、これらのプロセスを制御するために、新しい権限をいくつか追加しました。ガバナンスの観点からは、これはチームが外部承認のアクセス権を持つ人を完全に制御し、外部承認の設定を要求できることを意味します。

外部承認 (External Approvals) は、Process タブで作成および変更されます。

外部承認は、現在の承認プロセスの概念を置き換えるものではありません。代わりに、承認プロセスは、特定の担当者からの手動承認が必要な配置の任意の部分で利用できますが、外部承認プロセスは、配置の前に自動的に実行され、配置が記録システムに従って実行されるべきであることを検証するのに適しています。承認プロセスは、プロセス要求が送信されたりスケジュールされたりするとすぐにキックオフされますが、外部承認は、手動承認に応答した後、デプロイメントが開始される直前に実行されます。

外部承認は、環境の基本設定で設定します。

ここでの "Validate JIRA Record" (JIRA レコードを検証する) から外部承認プロセスを変更する権限は、他の基本設定とは区別されています。これは、開発者が外部承認を管理することを制限できる一方で、環境レベルのプロパティを変更できることを意味します。

実行ログ (Execution Log) では、外部承認プロセスを展開してステップを詳しく見ることができます。

皆様の期待通り、アプリケーションは外部承認でエクスポートされ、上記で説明した内容を制御するための新しい粒度での細かいセキュリティ権限設定があります。

外部承認機能があなたの DevOps の変革に役立ったかどうかを教えてください。

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

非公開のプライベートサイトのセキュリティーサイトをチェックしたいが、クラウドのセキュリティーサービスを使いたい。そんな場合でも、AppScan on Cloud が使えます。Achieve Private Site Scanning with AppScan on Cloud の翻訳記事です。

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

2020年7月17日

著者: Shahar Sperling / Chief Architect at HCL AppScan

その名の通り、HCL AppScan on Cloud (ASoC) はクラウドベースのサービスです。ASoC は、組織のネットワークの外に存在する Web アプリケーション・ダイナミック分析セキュリティ・スキャナを特長としています。

ASoC は、一般に公開されているWebアプリケーションを簡単にスキャンすることができます。しかし、開発アプリケーションやテストアプリケーションは、通常、組織内に配置され、ファイアウォールの後ろやラボ内に配置されています。これらのアプリケーションをスキャンするには、プライベートサイトスキャン (PSS) を使用する必要があります。

クラウドからプライベートサイトスキャンを実現する方法

VPN やプロキシなどのネットワーク・コンポーネントを追加したり、ネットワークを変更してスキャナが組織のネットワークにアクセスできるようにすることは明白ですが、手間がかかり、コストがかかる解決策です。このアプローチは理想的ではなく、CIO や IT セキュリティチームからは敬遠されています。

ASoC PSS ソリューションは、特別なハードウェアを必要とせず、ネットワークに変更を加える必要もありません。ASoC PSS クライアントはネットワークにセットアップされ、必要なのはインターネットへの発信アクセス（直接またはプロキシ経由）とスキャン対象のサイトへのアクセスのみです。このクライアントは、組織内のどのマシンにもインストールでき、比較的少ないリソースで済みます。

PSS は、録画プロキシなどの機能を提供する AppScan Presence パッケージの一部で、ASoC サービスからの指示を受信するためにこのサービスを使用します。

ASoC PSS は、安全な（TLSで暗号化された）TCP/IPトンネルを作成する2つのエンドポイントで構成されています。

• トンネル・サーバ・エンドポイントは、スキャナと並んでクラウド・ネットワークに存在します。このエンドポイントは、スキャナが生成したリクエストを受信し、トンネルを通ってクライアントに転送します。
• トンネルクライアントエンドポイントは、トンネル接続を開始します。これは、組織内でインターネットへの発信接続が簡単に許可されてしまうため、ネットワークの制限を回避するための鍵となります。クライアントは、サーバーからトンネルを下って送られてきたトラフィックを受信し、テストしたアプリケーションに転送します。レスポンスは、逆に同じ旅をします。

ASoCで、テスト済みアプリケーションをPSSとしてマークし、使用する AppScan Presence の場所を選択します。その後はすべて自動で行われます。

ASoC PSS でのセキュリティに関する考察

ASoC はセキュリティスキャンを可能にするため、ASoC PSS ソリューションの開発と実装では、セキュリティへの配慮が鍵となりました。ASoC の開発者は、お客様のネットワークのセキュリティとトンネル接続のセキュリティに焦点を当てました。

前述の通り、PSS はお客様のネットワークに変更を加える必要はなく、PSSトンネルクライアントが特別な譲歩を要求することもありません。これにより、PSS トンネルクライアントを実行しているホストマシンに組織的なセキュリティポリシーを適用することができます。さらに、特定のポートや IP アドレスでの着信接続を許可するなど、組織的なファイアウォールに変更を加える必要はありません。

各 Presence インスタンスには、その ID となる一意のキーがあります。このキーは Presence インスタンスを識別するために使用され、正しいスキャン タスクを提供します。キーはいつでも更新できるため、定期的な更新が必要な組織のセキュリティポリシーにも対応できます。サーバー上でキーが更新されると、プレゼンス インスタンスは、キーが物理的にプレゼンス マシンに置かれるまで、タスクの受信を停止します。

PSS レベルで接続を安全にするためには、トンネル サーバーとトンネル クライアントがお互いを信頼して、検証されていない場所からプライベート ネットワークへの外部からのアクセスを防ぐことが重要です。スキャンの実行準備が整い、トンネル サーバーが起動すると、PSS は 2 つの証明書を生成します。

サーバー証明書は、クライアント側の証明書と秘密鍵とともに、スキャン・タスクの詳細とともにトンネル・クライアントに渡されます（プレゼンス・サービスと SaaS サービス間のセキュアな通信を介して）。これにより、トンネル・クライアントとトンネル・サーバは、リモート接続のアイデンティティを検証することができます。証明書はスキャンが完了すると無効になり、再スキャンのためにも再利用されることはありません。

以上のことをまとめましょう。クラウド・プライベート・サイト・スキャンのアプリケーション・セキュリティは、クラウドベースのセキュリティ・スキャナを活用して、組織内に配備されたアプリケーションをシンプルかつ安全な方法でスキャンするメカニズムを提供しています。

詳細

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

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

Deliver Your Projects on Time with Kudos Activities Plus and HCL Connections の翻訳版です。HCL Connections 6.5 には、パートナー製品であった Kudos Activity Plus というタスク管理機能を製品に取り込み、機能および使い勝手を向上させています。

Kudos Activity Plus と HCL Connections を利用して、プロジェクトを期限内に完了させる

2020年7月21日

著者: Adam Gartenberg / HCL

HCL Connections の最新バージョンへのアップグレードをお勧めする理由は数多くあります。Connections 6.5 の主な新機能の 1 つは、Kudos Activities Plus を無料で統合したことです。これは、迅速でアジャイルなプロジェクト管理機能であり、チームが目標をより早く達成するための方法を提供します。

Connections 6.5 の Activities 機能は、直感的で使いやすいインターフェイスと、リソース、ツール、知識を連携させて仕事を進めることができる軽量なプロジェクト管理ツールとして再設計されました。タスクの割り当てと期限の設定は、プロジェクトを期限内に、予算内に完了させるための重要な要素です。Kudos Activities Plus を使用すると、Connections のお客様は、モバイルとデスクトップの両方のデバイスでタスクやプロジェクトを管理することができます。

HCL Connections のユーザーは、Connections 環境から直接、タスク、チームワーク、プロジェクト、スケジュールを簡単かつ迅速に整理することができます。この新しい機能は、Connections 6.5 Component Packをインストールすることで無料でご利用いただけます。

また、Connections と Microsoft 365 の両方の利点を組み合わせたいユーザーのために、Activities Plus は Microsoft 365 (Teams、OneDrive、SharePoint、Outlook) と完全に統合されています - Kudos Activities Plusは、両方の環境からアクセスできます。この高度な統合により、Microsoft Teams へのアクティビティの追加、メールでの共有、OneDrive へのファイルの追加、SharePoint ワークスペースの一部としてのサイトページとしての SharePoint への直接の追加が可能になります。

詳細はこちらをご覧ください。

2020/7/21 - 読み終える時間: 5 分

Understand the Test Run tables in Unica Interact Flowchart の翻訳版です。

Unica Interactフローチャートのテスト実行テーブルを理解する

2020年6月3日

著者: Nitin Dhabale / Product Support Lead, Unica

最近、Interact フローチャートのテスト実行に関する問い合わせが多く寄せられました。そのようなケースでは、バックグラウンド・テーブルに挿入されるデータがテーブルのカラム・サイズを超えていたため、フローチャートのテスト実行が停止したことが確認されました。別のシナリオでは、Interact のユーザーは、どの視聴者IDがどのセグメントに該当するかを理解したいと考えていました。この情報を得るために、ユーザーはフローチャート自体に結果を表示するために、テストランでフローチャートを繰り返し実行していました。入力データは膨大で、顧客はそれを減らしたくありませんでした。そのため、フローチャートの実行完了までにかなりの時間がかかっていました。

Unica Interact でフローチャートを設計する際、開発者は一般的にフローチャートをテスト実行して、設定が正しいことを確認します。しかし、フローチャートがエラーで失敗した場合はどうなるのでしょうか？データはどうなるのでしょうか？データはどこに格納されるのでしょうか？これらは、ユーザーが常に答えを求めている共通の問題となっています。そこで、私は、フローチャートが実行されるときにバックグラウンドで作成されるテーブルについてさらに話しているこのブログを書きました。それは、どのようなデータがどこに保存されるかについて話しています。

Interact セッションでフローチャートのテストを実行している間、開発者はどのようにして様々なエラーメッセージを観察するのかについて話しました。これらの情報はすべて、4つの異なるタイプのテーブルに格納されています。Interact ・セッションのフローチャートが実行されると、バックグラウンドで、プロファイル・データベースの TESTATTR_n、TESTCOUNT_n、TESTSEG_n、TESTERROR_n の 4 種類のテーブルが作成されます。この番号（_n）は、同じインタラクティブ・フローチャートの上記のすべてのテーブルで同じである。この場合、Unicaは、TESTATTR_142、TESTCOUNT_142、TESTSEG_142、および TESTERROR_142を生成します。

「フローチャートがテスト実行で失敗したのはなぜか」という質問に対する正しい答えを見つけるためには、「フローチャートがテスト実行で失敗したのはなぜか」という質問に答える必要があります。より良い分析のためには、各テーブルの重要性を理解することが重要です。

フローチャートを実行する前のテストラン

テーブルに格納される情報は、異なる環境、セグメント、オーディエンス、および他の多くの要因によって異なります。例えば、ターゲットオーディエンスのタイプに応じて、オーディエンスIDは変化します。それは、世帯のオーディエンス ID のままでありながら、個人のための顧客 ID にすることができます。最初の表は、オーディエンスに焦点を当てています。

• TESTATTR_nテーブルの使い方は？

TESTATTR_n テーブルは、対話型フローチャートに従ってプロファイルデータベースの下に作成されます。このテーブルには、画像2に表示されているように、対話型フローチャートのテスト実行の結果が記録されています。このテーブルには、オーディエンス ID のみが記録される。つのオーディエンス ID を持つ複合オーディエンスＩＤが存在する場合、このテーブルは、その後、２つの列を持つことになる。出力されるオーディエンスIDの最大数は、インタラクション・プロセスで作成された構成に依存します。

テスト実行中に、ユーザーが 1000 件のレコードをすべて表示しようとしないことがあります。そのような場合は、出力を15レコードに制限することができます（下の画像のように）。

• TESTCOUNT_nテーブルの使用方法は？

フローチャートの構成には、いくつのプロセス・ボックスが関与していましたか？どのプロセス・システムが失敗し、どのセル・コードの下で失敗したか？このような情報はすべてTESTCOUNT_nの下に保存されます。これは、対話型フローチャートごとにプロファイル・データベースの下に作成されます。テーブルには5つの列があります。PROCESSID、CELLID、CELLCOUNT、CELLNAME、CELLCODE。

PROCESSID：列には、インタラクティブ・フローチャートに取り込まれた各プロセス・ボックスのID（数値データ）が含まれています。

CELLID : Decision、Sampleプロセスのような異なるプロセスボックスから複数のセルを作成することができる。この列には、インタラクティブ・フローチャートから作成された各セルのIDが含まれています。Interaction Process (対話プロセス)、Select Process (選択プロセス) は、最大1つの出力セルを作成することができます。サンプルプロセス (Sample Process)、決定プロセス (Decision Process) は、1つ以上の出力セルを作成することができます。スナップショットプロセス (Snapshot Process)、ポピュレートセグプロセス (Populate Seg Process) には、出力セルは含まれません。

CELLCOUNT : この列には、インタラクティブ・フローチャートのテスト実行が行われたときにポップレートされた各セルのカウントが含まれています。

CELLNAME : この列には、インタラクティブ・フローチャートのテスト実行後に作成された各出力セルの名前が含まれます。アウトプット・セル名は、プロセス・ボックスに作成されます。

• TESTSEG_n テーブルの使用方法は？

フローチャートではセグメントを作成します。今回のケースでは、セグメントは男性セグメントと女性セグメントの2つのグループに分かれています。では、どのオーディエンスIDがどのセグメントに属しているか？その情報は TESTSEG_n に保存されます。テーブルには以下の列があります。AUDIENCEID、ASSIGNED_SEGMENTID、ASSIGNED_SEGMENTNAME。

AUDIENCEID : データがオーディエンスIDとしてCustomerIDを含む場合、列の名前はCUSTOMERIDになります。そのデータ型は、HCL Campaignで作成されたオーディエンスIDのデータ型に依存します。

ASSIGNED_SEGMENTID : この列には、オーディエンスIDが該当するスマート戦略セグメントのIDが含まれています。

ASSIGNED_SEGMENTNAME : 列には、オーディエンスIDが該当するスマート戦略セグメントのIDが含まれます。列には、オーディエンスIDが該当するスマート戦略セグメントのNAMEが格納されます。場合には、以下のように

ASSIGNED_SEGMENTID : 列には、オーディエンスIDが該当するスマート戦略セグメントのIDが含まれています。

ASSIGNED_SEGMENTNAME : 列には、オーディエンスIDが該当するスマート戦略セグメントのNAMEが格納されています。視聴者IDがスマート戦略セグメントのいずれにも該当しない場合は、視聴者IDの隣の値はNULLのままです。

潜在的な構成問題を特定するためのエラーの理解

では、フローチャートが失敗したエラーメッセージは何でしょうか？すべてのエラーメッセージの情報は TESTERROR_n テーブルに保存されます。

• TESTERROR_n テーブルの使用方法は？

対話型フローチャートのテスト実行が何らかのエラーメッセージで失敗した場合、それぞれの ERRORMESSAGE、ERRORORCODE、失敗したプロセスボックスの ID がこのテーブルに挿入されます。

PROCESSESID : このカラムは数値データ型を持つ。インタラクティブフローチャートで実行に失敗したプロセスボックスの ID が格納される。

ERRORCODE：この列には、インタラクティブ・フローチャートで実行に失敗したプロセス・ボックスのIDが含まれている。この列には、インタラクティブ・フローチャートのプロセス・ボックスが実行に失敗したエラー・コードが含まれる。

ERRORMESSAGE : この列には、インタラクティブ・フローチャートのプロセス・ボックスの実行に失敗した理由を説明するエラーメッセージの説明が含まれる。

SEQID : これは、テーブルに挿入された各レコードに対してシステムが生成した一意のフィールドです。

問題とトラブルシューティング

しかし、どのようにトラブルシューティングして問題を解決するのでしょうか？私は例からいくつかの助けを得てみましょう。インタラクティブ・フローチャートのテスト実行が、列 "TESTERROR_<>."""ERRORESSAGE" の値が大きすぎるデータベース・エラー (value too large for the column) で失敗した場合。

原因 : インタラクティブ フローチャートは、テーブル TESTERROR_n テーブルのテーブル カラム "ERRORMESSAGE" のサイズよりも大きいエラーメッセージをスローします。デフォルトでは、対話型フローチャートごとに、1つのTESTERROR_n テーブルがプロファイルデータベースに作成されます。このテーブルのカラム ERRORMESSAGE のサイズは 512 バイトであり、エラーメッセージが 512 より大きい場合は、以下のようにデータベースエラーで失敗します。

行[1]でのテスト実行エラー[run id=6u2keu1n90]。

com.unicacorp.interactual.exceptions.DataAccessException. 以下のデータベースクエリを実行する際にエラーが発生しました(ORA-12899: column "UNICAINTERACTTR"... "TESTERROR_3900774″... "ERRORESSAGE" (actual: 1059,maximum: 512) )。INSERT INTO UNICAINTERACTTR.TestError_3900774 (SeqID,ErrorMessage,ErrorCode,ProcessID) VALUES (?,?,?,?)

解決方法

このエラーを解決する最も簡単な方法は、対話型フローチャート用に作成された TESTERROR_n テーブルを ERRORESSAGE のサイズを大きくして変更することです。Interact でフローチャートを設計する際には、最終的な実行前にテストを行うことが不可欠です。これは、設定の早い段階で問題を分析し、修正するのに役立ちます。そのため、次回のテスト実行が失敗した場合は、これらの 4 つのテーブルを参照して、特定の情報を確認してください。

Unica に関するご質問は、いつでもサポートコミュニティに質問してください。

また、HCL のアイデアポータルに登録して、製品のロードマップに影響を与えるチャンスです。

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

How does HCL Accelerate make open source better? の翻訳版です。

HCL Accelerate はどのようにしてオープンソースツールをより良いものにするのか

2020年7月20日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

皆様が、使い慣れたソフトウェアが好きであることや、オープンソースツールを使用してきた長い歴史を持つ企業の方であることを、HCL Software は理解しています。しかし、HCL Software は、お客様の仕事をより簡単にし、チームをより協調的にすることができるのではないかと考えています。HCL Software DevOps ソリューションは、現在お使いの開発ソフトウェアのエコシステムとして補完することができます。オープンソースのツールをより良くするにはどうすればいいのでしょうか？ガバナンス、可視性、エンタープライズ・スケールなど、より速く実行し、より大きく成長するために必要な要素を追加します。

HCL Software の究極の追跡・確認ツールである HCL Accelerate を、お客様の DevOps エコシステムの上に配置することで、これまでにないほどの洞察力とガバナンスが得られます。ツールチェーンに何があるか、オープンソースであるかどうかに関係なく、HCL Accelerate は、これまでにないほどの洞察力とガバナンスを提供します。HCL Accelerate は、ボトルネックを発見し、チームを改善し、ビジネス価値を高めるために必要なメトリクスを提供します。

カスタム・プラグインを加速する HCL Accelerate の主な利点は、すべての DevOps ツールからのデータを集約するため、使用しているツールにあまり詳しくない関係者でもパイプラインを簡単に解釈できることです。例えば、Jenkins を使用している開発者であれば、そのツールの使い方を熟知しています。しかし、Jenkins はオープンソースであるため、あまり洗練された UI を持っておらず、管理者が必要な情報を掘り下げて見つけるのは容易ではありません。HCL Accelerate は、オープンソースのツールに慣れていない人のために、単一のビューでデータを分析するためのユーザーフレンドリーなレイヤーを提供します。

オープンソースは非常にニッチなアプリケーションであり、コスト節約の面ではとても素晴らしいものです。しかし、オープンソースは、セキュリティやサポートなどの重要な要素を見逃しがちです。HCL Accelerate は、オープンソースツール全体にガバナンス、コンプライアンス、およびレポートを追加することで、このギャップを埋めることができます。リリースオーケストレーションやインテリジェントゲーティングなどの機能を備えた HCL Accelerateは、オープンソースツールの操り人形的な役割を果たします。たとえば、HCL Accelerate を使用して、Jenkins で安全にゲーティングされたリリースを設定することができるので、誤って何かを早期にリリースしたり、間違ったビルドをリリースしたりすることがなくなります。セキュリティ機能を追加し、パイプラインデータを1つのビューにまとめることで、HCL Accelerate はチームに最適なツールを自由に使用できるようにします。

HCL Software は、ソフトウェアデリバリツールへの「リッピング＆リプレース (全面的な取り替え)」アプローチが必ずしも理想的ではないことを知っています。しかし、組織の成長にはアップグレードが必要です。そのため、HCL Accelerate は既存のツールセットと統合できるように構築されているため、チームに最適なツールを自由に使用できるようになり、同時に主要な利害関係者に可視性とセキュリティを提供することができます。無料のコミュニティ版で HCL Accelerate をお試しください。

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

Understanding the AppScan on Cloud Compliance Network の翻訳版です。

クラウド・コンプライアンス・ネットワークにおける AppScan の理解

2020年7月15日

著者: Shahar Sperling / Chief Architect at HCL AppScan

組織的なセキュリティを管理する際には、どうしても圧倒されてしまいがちです。アプリケーションのセキュリティは、使用する技術、サードパーティ製のコンポーネント、アプリケーションの配布、ユーザーのアクセスなどの特性によって影響を受けます。セキュリティスキャンの結果を見ただけでは、組織の優先順位を導き出すことは難しいでしょう。

組織のセキュリティを管理するためのアプローチの1つとして、リスク計算のメトリクスを利用することがあります。組織内のアプリケーションごとにリスク特性を定義します。結果として得られるリスクプロファイルは、アプリケーションが脆弱性を発見された場合に組織が被るリスクを示しています。セキュリティ上の問題が識別されると、全体的な結果は、リスクプロファイルのコンテキストにおいて考慮され、結果的に、重要、高、中、または低リスクの評価として、リスクスコアに変換されます。

これで、組織の優先順位を設定して、最も重要なシステムから最も重要度の低いシステムまで、これらの問題に対処することができるようになりました。このアプローチは、組織内で展開され、使用されるアプリケーションによってもたらされるリスクを理解しようとする組織に効果的です。情報セキュリティチームは、組織のリスク評価を行い、ベンダーや内部の開発チームに連絡して改善を求めることができます。

開発チームは、開発中のアプリケーションのセキュリティ状態をどのように判断することができるか

しかし、開発チームはどうでしょうか？開発チームは、特にアプリケーションが商業的に販売されることを意図している場合、開発中のアプリケーションの最終的なデプロイ環境について、ほとんど、あるいは全く考えていないかもしれません。チームは、どのようにしてリスクとセキュリティ関連の作業を管理し、優先順位をつけることができるでしょうか？開発管理者は、開発中のアプリケーションのセキュリティ状態をどのように理解できるでしょうか？この情報は、開発ライフサイクルの管理の一環として、約束をしたり、リリース日をスケジューリングしたりする際に重要です。

アプリケーションの潜在的なセキュリティリスクを計算する

開発中のアプリケーションのリスク計算には情報が必要です。しかし、開発チームが持っているかもしれないし、持っていないかもしれません。リスクを完全に理解するためには、開発チームは追加の基準を必要とします。

完全なアプリケーション・プロファイルを持たないと、開発チームには課題そのものの特性が残ってしまいます。課題には、タイプ、分類、原因、深刻度、場所、最初に発見された日付など、多くの属性があります。チームは、任意の基準に基づいて課題の断面を特定することができ、基準に一致する課題は、解決が必要なものとして、優先順位が付けられた課題となります。

チームがアプリケーションのセキュリティ作業を開始する際には、かなり緩やかな基準を使用することができます。作業が進むにつれて、業界や規制機関が要求する基準に一致することを最終的な目標として、徐々に厳しい基準を設定する必要があります。

例えば、あるアプリケーションを所有しているチームが、そのアプリケーションのセキュリティテストを開始したばかりで、問題の数に圧倒されているとします。チームは、問題を管理し、クリーンで安全なアプリケーションという究極の目標に向かって前進するために、以下の アプローチを取ることができます。

• 指定された日付を超えて新しい問題が発生しないことを指定するベースライン基準を設定する。チームは、ベースライン基準が設定された後は、新しいセキュリティ問題を追加しないことを約束する。チームは、その時点から、セキュリティ関連のタスクのために、良い開発手法を採用する。これにより、新しい問題が日常的に検出され、修正され、 開発サイクルの間に導入される問題が全体的に少なくなるようになる。
• すべての開発がベースライン基準を満たしたら、新たな重要度基準を設定し、 重大度の高い問題は許可しないことを指定する。ここで、チームが解決すべき、新たな課題セットが基準を形成される (古い、重大度の高い課題)。
• これらの問題がクリアされると、チームは OWASP トップ 10 や SANS トップ 25 のような業界標準に準拠することを選択でき（または義務づけられる） 、それらの標準に登場するすべての問題を解決することを約束する。
• 将来の基準の約束は、FedRAMP や HIPAA、あるいは「問題ゼロ」であってもよい。

逐次的な基準を設定することは、近づきやすい目標を設定するだけでなく、アプリケーションの集合体に対 して偏りのないステータスビューを作成することにもなります。各アプリケーションが同じ基準で測定されるリスク計算とは異なり、コンプライアンスステータスでは、各アプリケーションは、その特定の特性や特性に適した異なる基準を持っています。重要なのは、アプリケーション（とチーム）がコミットされた基準を満たしているかどうかであり、各チームは異なる成熟度レベルにある可能性があり、すべてのアプリケーションが異なる基準を遵守することが要求される可能性があることを理解しています。

詳細

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

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

SaaS の MarTech サービスが花盛りですが、本当にそこだけに依存してもよいのでしょうか。英語版ブログの記事 What the SaaS?! Why your MarTech SaaS Symphony Needs a Maestro More than Ever の翻訳版です。

MarTech SaaS とは？なぜ MarTech SaaS シンフォニーにこれまで以上にマエストロが必要なのか？

2002年7月16日

著者: Maddie Highsmith / HCL Unica Specialist & Martech Advisor

今日の一般的な企業では、日々のメッセージング、プロモーション、広告キャンペーンをチャネル横断的に管理するために、91～189 のマーケティング＆CRM SaaS ツール（ツール）を導入しています。誰に聞くかによって、これらの数は多少異なるかもしれませんが、業界関係者の間で最もよく参照されているのは、Netskope社の調査です。同社の調査によると、企業では CRM 関連の SaaS ツールが69種類、マーケティング関連の SaaS ツールが 120 種類使用されているとのことです。

これは管理しやすいと思われるかもしれませんが、これらのツールはすべてのユーザーが年間サブスクリプションと企業とのセキュアな接続を必要としていることを考えてみてください。これに加えて、SaaS アプリケーションの寿命はわずか2年であり、マーケティング・チームの人員配置、トレーニング、管理を非常に困難にする、多くの離職率とスキルの課題が発生します。

今日、CMO の要求はこれまで以上に厳しくなっています。CMO は企業のブランド戦略やメッセージングを管理するだけでなく、マーケティングタスクを実行するために利用可能な様々なテクノロジーの中から選択しなければなりません。

毎年、有名な Chiefmartec のインフォグラフィックが公開され、世界の SaaS の選択肢やイノベーションを紹介している。今年は 8,000 件を超えました。

世界中のマーケティング・チームが日々の業務に100以上のツールを使用しており、SaaS への支出は年々増加し続けていることを考えると、これらの投資の ROI を証明したり、可視化することが難しくなるのは当然のことである。何がうまくいっているのか、何がうまくいっていないのかという真のパフォーマンス・メトリクスは、まだつかみどころがないか、あるいは文字にするのが難しいだけなのです。

MarTech や AdTech の技術革新に加えて、SaaS のおかげでこれらのツールが簡単に導入できるようになった今、疑問に思うことがあります。

• 現代のデジタル・タッチポイントと伝統的なチャネルを横断したブランド・コミュニケーションを管理する努力は、より良い管理になっているのか、それともより混沌としたものになっているのか？
• 最終的には、これら多くのツールのパフォーマンスの橋渡しとオーケストレーションを行う時期に来ているのか？

答えは次の通りです。

• 両方とも真実です。
• そう、その時が来たのです。

ブランドマーケティングが改善されたと言ってもいいが、マーケティング実務者と CMO の両方の生活にプラスの影響を与えるという点では、テクノロジーの約束事はまだ完全には実現されていません。私の同僚の一人は、異なる SaaS ツールを分析して接続する際にマーケターが直面する課題を「オリンピック形式の体操」と丁寧に表現しています。ほとんどのマーケターが「気が狂いそう」と言っていることを考えると、適切な表現だと思います。多くのマーケターが「気が狂いそう」と言っていることを適切に表現していると思います。

私はあなたに、今こそすべてをつなぐ時だと提案します。マーケターとして、またブランド戦略アドバイザーとして、私は SaaS を愛しています。手軽にサインアップできて、基本的なことにも使えます。また、自分の運命をコントロールできるのも気に入っています。しかし、SaaS ツールが次々と登場しては消えていくため、特定の顧客の行動や行動に関連するデータを抽出して管理することが重要になってきます。とあるツールがサービス終了になったからといって、重要なデータを失っても問題ないと考えるマーケティング組織はないでしょう。

IDC の予測によると、パブリッククラウドサービスとインフラストラクチャへの世界的な支出は、今後5年間で2倍になると予測されています。5年間の複合年間成長率 (CAGR) に牽引されている。企業の TCO と日々の運用コストを削減し、複雑さを解消するという SaaS の約束は、必ずしもうまくいっていないようだ。

オンプレミスのソフトウェアとハードウェアのエンド・オブ・ライフの煩わしさを交換することで、セキュリティや統合の課題が全く新しいものになり、重大な監視と注意が必要になります。プライベート・クラウドも、いくつかのソリューション (Unica) では選択肢の一つとなっています。すべての組織の CMO は、これまで以上に CIO との関係を強化し、団結することを必要としている。

SaaS は、新しいマーケティングやアドテクのイノベーションをより早く市場に投入する上で明確な役割を果たしているが、その一方で、ある程度の組織性とセキュリティが必要です。大規模なマーケティング部門のオペレーションには、目標に対するパフォーマンスを管理・追跡するための可視性が必要です。Unica は、世界で最も統合されたマーケティングプラットフォームです。クラウドネイティブのプライベートオプションで、マルチテナント型 SaaS に縛り付けるようなことはせずに、すべての顧客データと情報を一元化することができます...ゴールベースのマーケティングのために特別に構築されています。

Unica は、お客様の SaaS ツールやエンタープライズオペレーションとの間の橋渡し役であり、多くのチャネルや SaaS システムを介して、最も重要な顧客に向けて、(大規模から小規模まで) 規模に応じたプレシジョンマーケティングが可能です。

ゴールベースのマーケティングは、成功するブランドにとって常に重要です。

人間の注意を引くための断片化と競争は、ぼんやりとしたものになってきています。メッセージやオファーが発信されたり、利用可能な様々な方法で顧客に提示されたりすると、これらのメッセージの乱雑さが人間の上に積み重なっていきます。最終顧客は多くのことを吸収することができません。

同様に、マーケターのマインドシェアを競うSaaS競争は、マーテックやアドテックのツール空間を前進させ続けている。マーケティングには、より専門的なことを可能にする新しいツールが次々と登場し、マーケターの日々の業務はさらに細分化されています。マーケティングチームが「新しいことをする」ための方法は、年々登場し続けています。

CMO やマーケティング担当者にとって、これら多くの SaaS ツールを使いこなすためには、ペースを維持し、スキルを身につけるのは大変な作業です。これらの SaaS ツールを採用することは、自社にとって革新的であることを意味します。それは彼らにとって市場での勝敗を意味します。そしてこれはまた管理するために絶えず増加する支出/予算を意味する。SaaS は当初、低コストとシンプルさを約束して採用されました。SaaS のマルチテナント・モデルと Web ベースのツールの簡単なインターフェースは、あらゆる規模のマーケティング担当者にとって魅力的な約束でした。

マーケティング・チームの最大の課題は、会社の広告キャンペーン、ブランド・プロモーション、スーパーボウルの CM などで次のキラー・クリエイティブを思いつくことでしたが、悲しいことに今はもうなくなってしまいました。キラー & クリエイティブなキャンペーンも必要ですが、それをシンフォニックな形で顧客に届けるためには、メディアミックスの各チャンネルで 100 以上の「楽器 (Instruments: 道具)」が必要です。優れたブランド体験を提供することは、それほど複雑なことではありませんでした。

適切なチャネル（オン/オフライン）で、必要な時に必要な場所で適切な人にパーソナライズされたオファーを提供することこそが、Unica がブランドのために行うことなのです。銀行、小売店、通信、保険、救急隊などの企業は、ブランドに特化したメッセージだけでなく、重要なメッセージや時間的な制約のあるメッセージを顧客に配信するためにUNICAを利用しています。Unica は単なるマーケティングではなく、必要不可欠なものなのです。

Unica はビジネスコミュニケーション (Communications) の中心であり、不可欠なものなのです。

MIT の数学者から生まれた Unica は、未来のために設計されています。15年以上に及ぶ献身的な経験と開発により、Unica は、世界で最も優れた企業や最も信頼されるブランドから選ばれるコミュニケーションテクノロジーとなってきましたし、現在もその地位を維持しています。

20 年以上にわたり、Unica は世界最大のブランドのマエストロとして、伝統的なチャネルとデジタルチャネルでのキャンペーンの指揮を執ってきました。これらはすべて、最高レベルのセキュリティと大規模なスケールで自信を持って実施されています。HCL Software のクライアントは、業界の巨人や革新的な企業であり、適切なメッセージを適切な顧客に、適切なタイミングで、適切な媒体で、いつでも確実に届けるために、Unica を常に頼りにしています。

Unica は、機器（SaaSツール）、システム、データウェアハウス、メディアチャネルなど、規模に応じたプレシジョンマーケティングで知られています。

今すぐお問い合わせいただき (日本は Web のお問い合わせフォームから)、Unica がお客様の SaaS 楽器のオーケストラの管理にどのように貢献できるかをご確認ください。