2020/10/23 - 読み終える時間: 3 分

Potential Threats and Measures to Secure Your Web Applications 翻訳版です。

Web アプリケーション の潜在的な脅威と保護対策

2020年10月22日

著者: Unnati Ghosh / HCL

Web アプリケーションは無防備で誰でも手に入る。必要なのはインターネット接続だけ。これにはハッカーも含まれます。

しかし、開発者は Web アプリケーションのセキュリティを無視することが多く、チームは通常、ほとんどの時間をコードに費やし、 Web アプリケーションが信頼できるものであることを確認する時間はほとんどありません。

Forrester によると、アプリケーションの脆弱性が攻撃の成功の主な理由であることに変わりはなく、ソフトウェアの脆弱性を悪用した攻撃の42％を占め、35％はWebアプリを経由して行われています。

一般的なWebサイトアプリの脅威

Web サイトが攻撃される方法は 1 つだけではありません。

• SQL インジェクション

SQL インジェクション攻撃は、公開された SQL クエリに悪意のあるコードを注入することで行われます。攻撃者は、Web サイトからデータベースに送信されたメッセージの中にリクエストを挿入します。

• マルウェア

マルウェアは、お客様の Web サイトへの最大の脅威であり、プライベート データやサーバー リソースにアクセスするために使用されます。マルウェアは、スパイウェア、ウイルス、ランサムウェア、ワーム、トロイの木馬など、それぞれ別の目的を達成するために活動しているため、明確なバンドに分類することができます。

• フィッシング詐欺

フィッシング詐欺の攻撃は、メールマーケティングの取り組みに直接影響を与えます。これらのタイプの脅威は、有効なソースからのメールを装い、機密データを取得するために計画されています。

• ブルートフォース

また、ハッカーがパスワードを推測し、 Web アプリケーションの所有者の詳細に強制的にアクセスしようとするブルートフォース攻撃もあります。

しかし、どのようにして悪意のある意図から Web アプリケーションを保護するのでしょうか？以下にヒントをいくつか紹介します。

• ソースコードの暗号化

マルウェアは多くの場合、アプリケーションの設計やソースコード内のバグや脆弱性をタップします。この悪意のあるコードは 12M以上のアプリに感染し、攻撃者が行う最も一般的な方法は、人気のあるアプリを「不正なアプリ」にリパッケージし、同じものを公開することです。そのため、コードの脆弱性をテストするか、ソースコードのスキャンを実行する必要があります。

• バックエンドでのネットワーク接続の安全性を確保する

アプリのAPIがアクセスするサーバーやクラウドサーバーには、データを保護し、不正アクセスを防ぐための安全対策が必要です。そこで重要になるのが、データやドキュメントのセキュリティを確保することです。CI/CD パイプライン全体でコンテナの使用を強化するためには、自動で開始から終了までを実行する必要があります。

• パッチ適用の最新情報を確認する

最新版で OS を強化していますか？遅れている可能性があります。ソフトウェアのセキュリティを確保するためには、商用ベンダやプロジェクトを維持しているオープンソースコミュニティからのアップデートでソフトウェアをパッチすることが重要なステップの1つです。

• 継続的に暗号化する

暗号化は何年も前から話題になっています。安静時とトランジット中のデータを暗号化することは、どのアプリケーションのセキュリティリストにも必ず必要です。

トラフィックのロックダウンに失敗すると、侵害の形で機密データの開示につながる可能性があります。暗号化のための基本的なチェックリストには、継続的なセキュリティと、最新の証明書を使用してSSL を使用していることを確認するような項目が含まれている必要があります。

• スキャンツールと検査ツールをインストールする

アプリケーションの完全性を確認するために、すべてのステップをチェックします。アラート手順は、侵害が発生した場合の応答時間を向上させることができます。テストやスキャンがなければ、Web サイトが侵害されたことをどのようにして知ることができるでしょうか？ブルートフォース攻撃があった場合に警告するプロンプトを必ず作成してください。

• Web サイトのファイアウォールを確保する

SSL 証明書を使用するだけでは、攻撃者による機密情報へのアクセスを防ぐことはできません。Web アプリの脆弱性により、攻撃者はトラフィックをスパイしたり、偽の Web サイトに訪問者を送ったり、Web サイトを人質に取ったり（ランサムウェア）、すべてのデータを一掃したりすることができます。Web アプリケーション・ファイアウォールは、Web サイトに対するこのような攻撃を防ぎ、お客様がビジネスに集中できるようにするために設計されています。

HCL AppScan は、クラス最高のセキュリティテストツールであり、お客様のビジネスとお客様の顧客が攻撃に対して脆弱でないことを保証します。広範囲に存在するセキュリティ脆弱性を検出し、開発ライフサイクルのあらゆるフェーズでアプリケーションの脆弱性をピンポイントで修正して修復を促進し、攻撃への曝露を最小限に抑えることができます。

SDLC の初期段階で、あらゆる種類のWeb、モバイル、オープンソースの脆弱性を迅速に特定し、理解し、修正するオールインワンのスケーラブルなセキュリティテストツールである HCL AppScan を採用してみてはいかがでしょうか。

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

HCL AppScan's DAST Engine Enhancements Superpower Your Application Security Testing の翻訳版です。

HCL AppScan: DAST エンジンの機能強化により、アプリケーション・セキュリティー・テストを強力にサポート

2020年10月12日

著者: Billy Weber / Senior Product Manager, HCL AppScan

HCL AppScan は、ますます改善され良くなってきています。私たちは過去1年間、ダイナミック・アプリケーション・セキュリティ・テスト（DAST）技術に多大な投資を行い、過去 6 ヶ月間に 3 つの AppScan 製品のリリースを発表しました。このブログの目的は、HCL Software の主要な DAST エンジン機能アップデートのいくつかにスポットを当て、みなさまご自身でテストドライブできるようにすることです。

AppScan V10 アップデートのまとめ

2020年3月には、製品ラインが HCL ファミリーの一部となってから初めての AppScan のメジャーリリースを祝いました。

V10 リリースでの AppScan DAST のハイライトには、以下が含まれています。

• Test Optimization Slider - DevSecOps のさまざまなフェーズでより高速なスキャンを提供します。テスト最適化スライダ - DevSecOps のさまざまなフェーズでより高速なスキャンを提供します。テスト最適化スライダでは、4 つの最適化レベルで問題のカバレッジとスキャン速度のトレードオフを制御できます。

• インクリメンタルスキャン - アプリケーションの変更を識別してテストフェーズ中に送信されるテスト数を大幅に削減することで、より短いスキャンを提供します。

• 機械学習を使用した最適化されたアクションベースのエクスプローラ - 機械学習を利用してエクスプローラ段階の効率を向上させました。AppScan は、すでに発見されている部分につながる可能性の高いアクションを予測するため、それを回避できます。

• AppScan DNS を使用した帯域外の脆弱性 - AppScan の DNS 解決を使用して、OS Commanding、SSRF、XXE 攻撃など、テスト済みのアプリケーションでは直接検出できない脆弱性の検出が改善されました。

AppScan V10 のポートフォリオのアップデートは、Eitan Worcel 氏のブログに掲載されています。

AppScan V10 .0.1と V10 .0.2の機能強化

DAST の強化はそれだけではありません。HCL は、最新の Web アプリケーションをより良くサポートし、より包括的で正確な結果を提示するために、DAST エンジンのコア機能への大幅な投資を続けています。新しい DAST 機能のハイライトは以下の通りです。

新しいテスト機能と改善されたテスト機能

アプリケーションがより複雑になり、より頻繁なアップデートが必要になるにつれ、ユーザーからはテスト機能の拡張を求める声が上がっています。そのため、当社では一連の新しいテスト機能強化を導入し、より広い範囲をカバーし、新しいセキュリティルールを活用できるようにしました。

AppScan V10 .0.1 および V10 .0.2 のリリースにおけるテスト改善のアップデートには、以下のものが含まれています。

• アプリケーションの直接反映ではなく、アプリケーションの外部から観測可能な動作に依存する AppScan ドメインネームサーバー（A DNS）機能の拡張。A DNS についての詳細は、Shahar Sperling 氏の包括的なブログを参照してください。

• ブラインドXPATHインジェクションとブラインドLDAPインジェクションのための新しいテスト。

• マルチステップテストのための検証の強化。

• 拡張されたディレクトリ推測オプションにより、より広いテスト範囲を提供します。

• クロスサイトスクリプティング(XSS)アナライザーは、リファラーヘッダーをサポートするようになりました。

• 多くの新しいセキュリティルールが追加されました。詳細については、リリース情報を参照してください。

カバレッジの向上、精度の向上、結果の向上

ユーザーが必要としているのは、テスト機能の拡張だけではありません。実際、Ponemon Instituteの最近の報告書によると、米国企業のサイバーセキュリティ担当者は、受信したセキュリティ警告が誤っていたために、誤検知の追跡に約25%の時間を無駄にしていることがわかりました。もっと良い方法があるはずです。

私たちは、DAST スキャンエンジンが誤検出の割合が低いことを確認するために多くの努力を費やしています。また、新しいリリースを行うたびに、お客様からのフィードバックと社内でのテスト活動に基づいて、検出結果の精度を向上させています。

ユーザーに提示する結果のカバレッジと精度をさらに向上させるために、AppScan V10 .0.1と V10 .0.2には以下の改善点が盛り込まれています。

• AppScan V10 .0.1および V10 .0.2には、以下の改善点が盛り込まれています。当社ではAction-Based-Exploreの機能を継続的に強化しており、最近のリリースでは特にAngularアプリケーションのスキャンに関連した改善点に焦点を当て、自動カバレッジを向上させています。

• AppScan のエラーページの自動検出機能が大幅に改善されました。ほとんどのアプリケーションでは、アプリケーションエラーを示すためにカスタマイズされたエラーページを使用しています。エラーページが正しく識別されない場合、AppScan は脆弱性が見つかったと考え、偽陽性の結果になることがあります。エラーページの自動検出のための改良されたアルゴリズムにより、結果の精度が向上しています。

• 課題の統合機能の改善により、頻繁に発生する課題が統合され、結果として、よりコンパクトな結果セットが作成され、レビューと管理が可能になりました。例えば、単一のソース（サーバー構成など）を共有し、アプリケーションの複数の場所で発生するissueは、1つのissueに統合されますが、詳細はすべてバリアントとして表示されます。統合により、必要な重要な詳細を失うことなく、全体の課題数を減らすことができます。

統合機能

当社のお客様の多くは、複数の AppScan 製品を使用しています。例えば、大規模な組織のセキュリティ専門家は、AppScan Standardを使用してスキャン構成を作成し、それを後で開発者が AppScan Enterprise や AppScan on Cloudを使用してアプリケーションをスキャンする際に使用することがよくあります。開発者は、AppScan Enterprise または AppScan on Cloud からスキャンを AppScan Standard にダウンロードして、必要に応じて後から AppScan Standard に戻して、詳細なトリアージを行うことができます。これらのフローを簡素化するために、私たちは V10 で AppScan Connect 機能を導入し、次のリリースではさらに多くの機能を追加して改善しました。

AppScan を DevOps 環境に統合することで、組織はセキュリティテストを自動化することができます。これは通常、お客様が AppScan Enterpriseまたは AppScan on CloudのREST API を使用して実施します。当社では、お客様の自動化プロジェクトのニーズに対応できるよう、ほぼすべてのリリースでこれらの API の追加と改善を続けています。最近では、このプロセスをさらに容易にするために、Jenkinsプラグインを AppScan Enterprise に追加しました。

詳細はこちら

私たちの新機能のすべてをご自身でご覧になるには、今すぐデモをリクエストしてください。注意事項として、私のブログで紹介したすべてのアップデートを利用するには、HCL Software AppScan のライセンスが必要です。

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

作業とボトルネックの可視化を実現する HCL Accelerate は、AppScan と組み合わせることもでき、DevOps の可視化と効率化を実現できます。そのことについての解説記事 Integrating HCL AppScan on Cloud (ASoC) with HCL Accelerate の翻訳版です。

HCL AppScan on Cloud (ASoC) とHCL Accelerate の統合

2020年9月12日

著者: Daniel Trowbridge / Technical Lead

ポーカーをプレイしたことがある人なら、カードの組み合わせが重要なことを知っているはずです。ソフトウェアに関しては、適切な製品を組み合わせることで、勝利を手にすることができます。この記事では、HCL Accelerate チームは、HCL AppScan および AppScan on Cloud (ASoC) との統合に注目してみていきたいと思います。

HCL Accelerate は、複数のチームやワークフローにまたがる可視性とガバナンスを提供する、柔軟で強力なリリースおよびバリューストリーム管理ツールです。HCL Accelerate は、1日2回の監督者から現場の DevOps に欠かせないツールです。HCL AppScan は、HCL Accelerate と驚くほど相性が良いのですが、どちらも次世代のソフトウェア開発体験という HCL のビジョンによって推進されています。AppScanは、静的および動的なセキュリティ・スキャンを提供し、オンプレミスとクラウドで提供しています。これらのスキャンは、品質、セキュリティ、およびコンプライアンスにとって非常に重要です。HCL Accelerate は、チーム、製品、ツールチェーン全体で AppScan のデータをインジェストし、可視性とガバナンスを確保することで、作業を継続し、管理を安心して行えるようにします。

さあ、始めましょう。

このチュートリアルでは、AppScanのクラウド提供（AppScan on CloudまたはASoC）を使用します。ASoC アカウントとプロジェクトをまだお持ちでない場合は、無料トライアルを利用して今すぐ設定することができます。また、HCL Accelerate をまだお持ちでない場合は、こちらから Community Edition をダウンロードできます。プロジェクトとスキャンの例を以下に示します。

また、ASoCキーIDとキーシークレットを生成する必要があります。

スキャン結果を生成する準備ができたら、スキャナを実行し、scanIDをコピーして貼り付けます。これは、以下のHCL Accelerateセクションに示されているcurlコマンドに後で必要になります。

1. HCL AccelerateでASoCインテグレーションを作成します。

1.1 プラグインを探す

HCL Accelerate で、Settings（設定）＞Integrations（統合）＞Plugins（プラグイン）に移動し、"Plugin for ASoC"で"Add Integration（統合の追加）"をクリックします。

1.2 統合を構成する

統合の追加」フォームに必要事項を入力します。HCl Accelerate と ASoC への認証を設定します。

• 統合名：ASoC_Example_Name_1
• ユーザー・アクセス・キー。HCL Accelerateのユーザー・アクセス・キーをコピーして貼り付けます。(“Settings” > “My profile” で ASoC_Example_Name_1という名前を付けることができます)
• ASoC ベース URL: https://cloud.appscan.com
• ASoC API Key ID。クラウドAPIの認証に使用するIDです。
• ASoC API Key Secret: クラウドAPIの認証に使用される実際のキー。

1.3 統合の検査

統合が作成されたことを確認します。ドロップダウンの詳細を展開して、エンドポイントのURLを表示します。統合エンドポイントのURLにPOSTコマンドでASoCデータをHCL Accelerateに送信します。

2. ASoCスキャン結果をHCL Accelerateに送信する

ASoCスキャン結果をHCL Accelerateに送信するには、スキャンIDを含むJSONオブジェクトをターゲットのHCL Accelerate統合のpluginEndpoint URLにPOSTするだけです。

データ構造の例

{
"scanId": "<ASoC scan ID>",
}

Curl コマンドの例 curl -H “Content-Type: application/json” -k -X POST https://<accelerate server>/reporting-consumer/pluginEndpoint/<integration ID>/asocScan -d “{\”scanId\”:\”<scan ID>\”}”

3. データを見る

HCL Accelerateでダッシュボードを設定することで、データを見ることができます。インサイト」に移動し、「ダッシュボードの作成」をクリックします。

チャートの追加」をクリックし、適切なメトリクスを選択してチャートを作成します。ASoCデータのデフォルトのメトリックは、「Risk」の下の「Application Vulnerabilities」です（ASoCプラグインのバージョン1.0.16以前の場合、デフォルトのメトリックは「Quality」の下の「ASoC Tests」です）。

フィルタリング・オプション

複数のフィルターや時間の選択など、データの異なる選択で複数のチャートタイプを作成することができます。

各チャートは、以下のように詳細表を表示することもできます。

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" と題した先日のウェビナーのリプレイをご覧ください。