2021/2/9 - 読み終える時間: ~1 分

HCL AppScan はソースコードおよびアプリケーションの脆弱性検査ツールです。インテリジェントな診断エンジンを備え、小規模から大規模まで、ソフトウェア開発および運用に欠かせないソフトウェアです。HCL AppScan の概要とバージョン 10 の特長についての資料を公開しました。

• サポート技術情報: 製品資料: HCL AppScan 10 のご紹介

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

HCL AppScan の新たなリリースが出る度に、開発者による新機能や変更点についての解説 (英語) が YouTube にアップロードされています。直近では 10.0.3 のものが上がっています。

Special Event - What's new in AppScan 10.0.3 - YouTube

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

AppScan and the OWASP Top 10: Why So Sensitive? の翻訳版です。

2020年12月19日

著者: Neil Jones / Senior Product Marketing Manager for HCL Software’s AppScan solution 共著: Rob Cuddy / Global Application Security Evangelist

AppScan と OWASP トップ 10。なぜそんなに慎重に扱うべきなのか？

OWASP トップ 10 に関するブログシリーズの第２部へようこそ。パート１では、最も一般的なタイプの脆弱性である SQL インジェクションを調べ、効果的なアプリケーション・セキュリティ・プログラムがどのようにしてこの脅威に対処するかをレビューしました。この記事では、もう一つのホットな話題を取り上げます。機密データの暴露です。

機密データの暴露の定義

機密データの暴露とは、まさにそのように聞こえます。これは、保護されているはずのデータが、あるべきではない時に、あるべきではない場所で利用可能になってしまうことを言います。センシティブデータには多くの種類がありますが、最も一般的な種類は、固有の個人情報、財務記録、健康情報、法的文書に関連するものです。

機密データには、個人のアイデンティティにとって重要であり、個人を一意に識別するために使用できる情報が含まれています。これには、完全な名前、電子メールアドレス、自宅の住所、電話番号、さらにはIPアドレス情報などの識別情報が含まれます。技術の進歩に伴い、バイオメトリクス・データや遺伝情報が、人種、宗教、信条とともにセンシティブ・データとして扱われるようになってきています。

機密データの暴露があなたに与える影響

私たちが日常的に共有している自分自身についての情報の量が多い中で、どのようにして機密データを悪意を持って利用して私たちに危害を加えることができるのでしょうか？その答えは非常に簡単です。機密データの漏洩は、アプリケーションやAPIが機密データを適切に保護していない場合に発生します。例えば、入力を適切に検証しなかったり、現在利用可能な無数のトランザクションを適切に処理しなかったりする安全でないアプリケーションを考えてみましょう。

これらの脆弱性により、データが盗まれたり、様々な形で悪用されたりする可能性があります。これらの悪用には、盗まれたクレジットカード情報、口座開設、融資の申請、医療や政府からの支払いなどの給付金を得るための個人情報の不正使用などがあります。極端な例では、法の執行から逃れるために使用されることもあります。最後に、データの悪用は、盗まれた政治家や組織の所属情報にまで及ぶ可能性があります。

そして、この暴露のためのコストは、個人的に高額になる可能性があります。米国司法統計局からのこれらの改訂された統計を考慮してください。

• ID 窃盗被害者の大多数（86%）は、クレジットカードや銀行口座情報などの既存の口座情報の不正使用を経験しています。
• 既存のアカウントやその他の詐欺で複数のタイプの ID 窃盗を経験した被害者の中で、約 3 分の 1 (32%) が問題の解決に 1 ヶ月以上を費やした。
• ID 窃盗被害者の推定 36%が、事件の結果として中等度または重度の感情的苦痛を報告しています。

そして、Javelin Strategyが発表した2020年のアイデンティティ詐欺報告書から、これらの統計を考えてみてください。

• 2019年、詐欺被害は15%増え、169億ドル。
• 詐欺被害は、消費者が35億ドルの費用負担外費用に直面する結果となりました。
• 犯罪者は、クレジットカード詐欺から、口座の開設と徴用に焦点を移しました。

機密データの暴露による組織への影響

そして今、組織の視点に移ります。GDPRのようなデータプライバシー規制が導入され、組織が日常的に収集する情報量が一般的になったことで、センシティブなデータに関連した企業への潜在的な被害について疑問に思うことがあるかもしれません。答えは比較的簡単です。効果的でないアプリケーション・セキュリティ・テスト技術や安全でない DevSecOps の実践は、機能的なアプリケーションを生み出しますが、ユーザーの個人情報が潜在的な攻撃にさらされたままになる可能性があります。実際、Ponemon Instituteの最近のレポート「DevOps環境におけるアプリケーションセキュリティ」では、回答者の71%が、DevOpsセキュリティプラクティスの可視性と一貫性の欠如が、最終的に顧客と従業員のデータを危険にさらすと回答しています。

そして、顧客データを無責任に扱うことは、高い代償を伴うことになります。同じPonemon Instituteのレポートによると、組織の脆弱なアプリケーションに対する攻撃によって生じた経済的損失の平均総額は、過去12ヶ月間で1,200万ドルに達しています。

同じくPonemon Instituteの「2020 Cost of a Data Breach Report」には、次のような悲惨な統計が掲載されています。

• データ侵害の世界平均コストは386万ドル。
• 顧客の個人情報が関与していた場合のレコードあたりのコストは146ドルでした。
• 悪意のある攻撃が原因で発生した場合、そのコストは1億7500万ドルまで上昇しました。
• メガ・ブリーチの被害者（100万件以上の記録を超えるブリーチと定義）の場合、ブリーチの平均コストは5,000万ドル以上でした。
• また、5,000万件を超える記録の侵害では、3億9,200万ドルの費用が発生しました。

機密性の高いデータへの対処

これを回避するために、センシティブデータは絶対に、安静時や転送中の暗号化などの追加の保護を受けて扱われるべきであり、ブラウザとのやりとりの際には特別な予防措置が必要です。また、可能な限り、ユーザーとのやりとりが発生する前に、センシティブな情報で発生する可能性のある潜在的な問題を特定し、修正することができるようにしたいと考えています。

HCL AppScanは、機密情報への対処とテストを支援するいくつかの異なる方法を提供しています。以下の図1、図2、および図3は、利用可能なオプションのいくつかを示しています。

最初に、図1は、スキャン構成中に使用できる設定を示しており、低/中/高の設定を使用して、アプリケーション環境自体を機密として宣言することができます。AppScanは、この設定に関連して報告される脆弱性の深刻度を調整します。

図1：アプリケーション環境の機密性設定

次に、図2は、ログや結果ファイルに表示される可能性のある機密情報をどのように扱うことができるかを示しています。この種の情報をユーザーが選択したパターンに置き換えるようにスキャンを設定することができます。これにより、わかりやすさを維持しながら、実際のデータを難読化することができます。

図2: 機密情報をユーザ定義のパターンに置き換える

最後に、図 3 は、正しい権限を持つユーザが CVSS 形式の設定を使用して、特定の脆弱性の深刻度を手動で更新することができることを示しています。この例では、報告された URL リダイレクション経由のフィッシングに関連する脆弱性が表示され、手動更新ウィンドウが表示され、ユーザが機密性の影響評価を行うことができる場所が強調表示されています。これにより、脆弱性管理のためのより高度な管理と評価が可能になります。

図3: CVSS-Style設定を使用した脆弱性の手動更新

詳細はこちら

センシティブ・データ暴露の可能性のある攻撃に対抗する最善の方法は、効果的なアプリケーション・セキュリティ・テスト・プログラムを利用することです。アプリケーション・セキュリティ・テクノロジーをご自身でテストしてみたい方は、今すぐHCL AppScanの30日間の無料トライアルに登録してください。また、Ponemon Instituteの「DevOps環境におけるアプリケーション・セキュリティ」レポートはこちらからダウンロードできます。

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

HCL AppScan: Now Supporting SAP ABAP の翻訳版です。

HCL AppScan: SAP ABAP のサポートを追加

2020年11月10日

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

ビジネスでは、セキュアな SAP アプリケーションが必要とされています

ご存知のように、SAP は、ビジネスプロセスの管理のために多くのグローバル企業で使用されているビジネスクリティカルなアプリケーションです。世界中で SAP は、SAP ベースのインストールに独自のカスタマイズされた ABAP コードを追加した多数のパートナーと提携しています。このアプローチは、組織が SAP アプリケーションを特定のニーズに合わせてカスタマイズするのに役立つ一方で、SAP アプリケーションベースに脆弱性やセキュリティホールを導入するリスクを高める可能性があります。SAP は通常、ほとんどの企業の重要な機能で利用されているため、セキュリティーの必要性は非常に高くなります。企業は、本番環境に展開するコードが可能な限り安全であることを保証するために、特別な措置を講じる必要があります。

安全でないコードが組織に与える実際の財務上の影響を理解するには、Ponemon Institute の「DevOps 環境におけるアプリケーションセキュリティー」調査から得られた主な財務上の知見に焦点を当てた HCL Software の最近のブログをお読みください。

AppScan SAST で SAP ABAP コードを保護する

ここに SAP と HCL AppScan の SAST 機能の融合があります。AppScan は、ABAP 向けの SAST の導入により、カスタム ABAP コードのスキャンを支援できます。

そして、HCL が世界でも有数の強さを誇る SAP のプラクティスであることはご存じないかもしれません。HCL には独自の SAP Center of Excellence (CoE) があり、非常に優秀で経験豊富なSAP 実践者が集まっています。Digilabs とも呼ばれるこのセンターオブエクセレンスは、HCL Software が提供する製品をSAP環境に統合することに重点を置いてきました。AppScan、HCL Launch、HCL Accelerate などの HCL ソリューションは、SAP の DevSecOps スペースに付加価値を与えるために強化されています。

AppScan: SAP/ABAPのサポートを追加

HCL SAP の CoE スペシャリスト と AppScan の SAST のノウハウを活用することで、HCL AppScan が SAP/ABAP をサポートしたことを誇りに思います。

はい、これは正しいものでした。AppScan の SAST は ABAP ECC バージョン 6 以上のスキャンをサポートしています。AppScan は バックエンドのABAPコードをスキャンすることができ、ビジネスに不可欠なアプリケーションをスキャンする際の優位性を提供します。AppScan は ABAP ソースコードの静的分析を実行し、XSS、SQL インジェクション、ディレクトリやファイルへの不正アクセスの可能性（ディレクトリ・トラバーサル）、ダイナミック・コールの操作（コール・インジェクション）、不十分な権限チェック、ユーザー管理のバイパスなど、コード内の脆弱性を発見します。

AppScan が他と異なるのは、アプリケーションポートフォリオに関する知識を一枚のガラスの下に追加できることです。SAP アプリケーションを探している場合でも、Java、.Net、Node、PHP（および当社がサポートしているその他の言語）をベースにした他のエンタープライズフレームワークで開発されたアプリケーションを探している場合でも、AppScan は単一のソリューションを提供し、お客様のニーズをすべてカバーすることができるようになりました。さらに、AppScan は、ソースコードが入手できないアプリケーションをテストするために、その最先端のダイナミック・アプリケーション・セキュリティ・テスト (DAST) 機能を活用して、さらなる保証を得ることができます。

開発者との作業に関しては、AppScan の ABAP の SAST スキャン（AppScan がスキャンする他の言語と同様）の利点は、修正グループと詳細なセキュリティレポートを使用していることです。

詳細

AppScan の SAP ABAP テスト機能の詳細については、今すぐデモをリクエストするか、アプリケーションセキュリティテストソリューションの 30 日間無料トライアルを開始してください。新しい資料が入手可能になり次第、このブログを更新していきますので、ご期待ください。

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

AppScan and the OWASP Top 10: A Focus on SQL Injection の翻訳版です。

AppScan と OWASP Top 10: SQLインジェクションに焦点を当てた考察

2020年11月2日

著者: Rob Cuddy / Global Application Security Evangelist 共著: Neil Jones / Senior Product Marketing Manager for HCL Software's AppScan solution

もし、あなたがアプリケーションセキュリティに長く携わってきたならば、OWASP Top 10 のことを聞いたことがあるでしょう。OWASP Top 10 は、2010 年に開始され、2013 年と 2017 年に更新されました。今日では、アプリケーション開発者や Web アプリケーションセキュリティの専門家が注意しなければならない最も一般的な脆弱性のタイプの「デファクトスタンダードなリスト」であると広く考えられています。実際には、API や IoT に特化した OWASP Top 10 リストがあるほどの標準となっています。

この定期的なブログシリーズでは、OWASP Top 10 リストの中で最も広まっている脆弱性を見ていきます。今回の記事では、OWASP Top 10 の脆弱性の中で最も普及しているタイプである SQL インジェクションを検証します。また、効果的なアプリケーション・セキュリティ・プログラムがどのようにしてこの脅威に対処できるかを検討します。

SQL インジェクションの定義

OWASP によると、「SQL、NoSQL、OS、LDAP インジェクションなどのインジェクションの欠陥は、信頼されていないデータがコマンドやクエリの一部としてインタプリタに送られたときに発生します。攻撃者の敵対的なデータは、インタープリタを騙して意図しないコマンドを実行したり、適切な権限なしにデータにアクセスしたりすることができます。" インジェクションとは、データフローを利用して、意図しないことをするためにデータフローを利用することです。 誰もが耳にしたことのある一般的な例としては、Web ページのフィールドでシングルクォートを使用して SQL クエリを悪用しようとすることがあります。

SQL インジェクションの影響

最近の Ponemon Institute の「DevOps 環境におけるアプリケーションセキュリティ」調査では、回答した組織のビジネスクリティカルなアプリケーションの 67%が、継続的に脆弱性のテストを行っていないことがわかりました。そのため、SQL インジェクションのような脆弱性の潜在的な影響は計り知れません。そのため、著者の Pallavi Dutta 氏による最近の SecurityBoulevard.com の記事では、大規模な SQL インジェクション攻撃が、英国の通信会社、多数の大学や政府機関、さらには E コマース企業など、幅広い業界の組織に影響を与えていることを指摘しています。

しかし、なぜ SQL インジェクションはまだ存在するのでしょうか？

実際のところ、SQL インジェクションは文字通り何十年も前から公に議論されてきましたが、なぜこれほど多くの組織にとって未だに問題となっているのでしょうか？ 現実には、SQLインジェクションを防止することはそれほど難しいことではありませんが、ソフトウェアがデータベースと通信し、ユーザーが提供した入力を使用している場所の数は膨大なものです。

「アプリケーション・パラノイア」ポッドキャスト・シリーズのシーズン 1、エピソード 10 では、アプリケーション・セキュリティの専門家で影響力のある Tanya Janca 氏に、誰もが二度と書いてはいけない脆弱性について尋ねたときに、この重要性を再認識しました。 Tanya は言いました。

「OK、それで、私のお気に入りの脆弱性で、私が修正しようと思っているもの。私はこの質問をひっくり返してみたいと思います。 なぜなら、すべてのプログラマが入力の検証をあるべき場所に配置し、入力の検証をきちんと行っていれば...それは膨大で膨大で膨大な量の脆弱性を修正することになり、この世のものとは思えないほどのものになるからです」。

インジェクション攻撃への対処

インジェクション攻撃の潜在的な影響を考えると、HCL AppScan はどのようにしてインジェクションを見つけ、それに対処しているのでしょうか？アプリケーションをスキャンする際には、あらゆる種類の可能な構成を試し、インジェクション攻撃が可能であることを示すものを探して出力を検査します。例えば、どのような種類のエラーメッセージが表示されているか、また、これらのメッセージがアプリケーションがどのように動作するかについての洞察を提供しているかどうかを調べます。私たちは良性のインジェクションを試してみて、それが「うまくいく」かどうかを確認し、開発チームがその存在に気づくことができるように、それらの試みの成功を報告します。また、発見された脆弱性の種類と、なぜそれが問題なのかについての情報を提供し、理解を助けます。

図 1: AppScan スキャン設定パネル

上図1は、HCL AppScan のスキャン設定パネルを示しています。 ここでは、ユーザーはテストしたい問題の種類を正確にカスタマイズすることができます。この例では、「Developer Essentials」プロファイルを選択することから始めました。これは、開発者が潜在的な問題について迅速にフィードバックを得ることができるように、成功する確率の高い多くの一般的なテストで構成されています。次に「インジェクション」という単語を検索して、選択されていない可能性のある他の関連テストを探し出し、それらを含めることができるようにしました。このような柔軟性により、テストに磨きをかけることができます。

インジェクションの問題が見つかったら、どのように対処すればいいのでしょうか？ ポッドキャストシリーズ「アプリケーションパラノイア」のシーズン1、エピソード 9 では、「クリスに聞く」のセクションで、クリス・デュアーが素晴らしい洞察を提供してくれました。彼が与えた強力なアドバイスは以下の通りです。

"ベストプラクティス 1: 準備された文を使うこと。 実行クエリを使うのをやめろ...実行クエリや実行文を見るたびに、私の魂の一部が死んでしまう。 パラメータがなくても気にしない...パラメータを持たせて、それを持たせて、絶対にステートメントを使わない。 常に準備された文を使う。 常に準備されたクエリを使用する.... それは文字通りただの

"ベストプラクティス 1: 準備された文を使用する。 クエリを実行するのをやめてください... クエリの実行や文の実行を見るたびに、私の魂の一部が死んでしまいます。 パラメータがなくても気にしません... パラメータを持たせて、ステートメントを使わないようにします。 常に準備された文を使う。 常に準備されたクエリを使え.... 文字列を連結するクエリを書くのをやめろ。 SQL インジェクションの問題の 99.9%はそれで解決する.... 動的な SQL を使うのはやめて、動的な SQL でなければならない場合は、準備された文を使うようにしましょう。

要約すると、脆弱性が特定されたら、それに対処するには、通常、以下の2つのカテゴリーのいずれかに分類されます。

• ユーザーからの入力を利用した動的なクエリの記述を排除する

• ユーザーが提供した入力が利用される場合、"悪い" SQL がクエリの残りの部分に影響を与えるのを防ぎます。

これら 2 つのカテゴリーに対処するには、パラメータ化されたクエリ、ストアドプロシージャ、許容される入力のリストの 定義、ユーザーが入力した入力のエスケープなどを使用する必要がある。 図 2 で示されているように、HCL AppScan は、発見された脆弱性に関する具体的な情報を、潜在的な修正案の中でこれらの戦略を使用して提供しています。さらに、OWASP は、これらの様々な方法をどのように使用するかを例示する素晴らしいリソースを提供しています。

図２：脆弱性と改善策の情報

詳細

潜在的な SQL インジェクション攻撃に対抗する最善の方法は、効果的なアプリケーション・セキュリティ・テスト・プログラムを利用することです。アプリケーション・セキュリティ・テクノロジーをご自身でテストしたい場合は、HCL AppScan の 30日間の無料トライアルにご登録ください。

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

?AST - The Who, What, Why and Where of Application Security Testing の翻訳版です。

AST - アプリケーションセキュリティテストの疑問: 「誰が」「何を」「なぜ」「どこで」？

2020年10月28日

著者: Shahar Sperling / Chief Architect at HCL AppScan

アプリケーションのセキュリティテスト技術を選ぶことは、単純な作業ではありません。直感的に、あなたは自分自身に尋ねるでしょう、 "最高の技術は何ですか？" その答えを見つけたら、あとは自分が一番気に入った製品を選ぶだけの簡単な作業です。

私は直感の大ファンなのですが、この場合、検討範囲を完全に理解していないと直感が誤解を招くことになります。上の質問は基本的に "DAST vs. SAST vs. IAST" という考え方をしていますが、本来は "DAST & SAST & IAST" であるべきなのです。AppScan の世界では、DAST から SAST、そして IAST へと拡大していく中で、私たちは10年以上前にこの結論に達しました。この拡大は、単にお客様に多くのオプションを提供するだけの問題ではないということに気付いたからです。スキャン範囲を改善してリスクを低減し、DevOps ライフサイクルのより多くの場所でセキュリティテストを適用し、適切な仕事に適切な技術を使用し、適切な人に適切なツールを提供することが重要なのです。テクノロジーは互いに置き換えられるものではなく、互いに補完し合い、隣り合わせに存在します。

なぜ、みなさまは単一のテクノロジーを求めているのでしょうか

技術には長所と短所があり、対象者も違えば、さまざまな種類の結果をもたらし、さまざまな条件のもとで活躍する技術もあります。開発とリリースのライフサイクルには、多くの段階があり、様々なスキルや専門分野を持つ多くの参加者がいます。可能な限り最も効果的なセキュリティテストを実施するために、ライフサイクルの異なるポイントで技術を導入することができますし、導入すべきです。

単一の技術の探索は、通常、次の3つの理由に起因します。

• 予算の制約: 支出は常に組織の関心事であり、制約があるかもしれません。
• プロファイルと政治性: 組織で働く人々のタイプ、誰の話を聞いているか、どのブログを読んでいるかなど。組織の一部がセキュリティプログラムに参加する意思があるかどうか、また、その結果として生じる腕ひねり（いわゆる、政治）は、すべて技術の選択に影響を与える。
• 誤情報: あるいは、過剰な情報。知っていることが多すぎても、十分でなくても、同じように混乱することがある。

それぞれの技術の使用状況をフレーム化するために、さらにいくつかの質問をしてみましょう。これらの質問はプログラムを設計するのに役立ちますが、それでも一つの技術を選択することが目的であるならば、決定するのに役立つはずです。

誰がスキャンを実行するのですか

この質問は、厳密には誰がスキャンの設定や設定を行うかということではありません。誰が実行するかという質問でもあります。特別な制限があるわけではありませんが、技術には、他の技術よりもはるかに適した特定のユーザータイプが存在することがよくあります。

開発者: 開発者は SAST スキャンを実行することで最も恩恵を受けることができますが、IAST も活用することができます。

QA エンジニア: QA エンジニアは、特別な相互作用がないため、IAST スキャンの実行に最も適している可能性が高いです。スキャンは、彼らが通常のQA作業（手動または自動化されたテスト）を行っているときに起こります。QAエンジニアは、DASTスキャンを実行することはほとんどなく、通常、SASTの開発環境にアクセスすることはありません。

セキュリティの専門家とペンテスター: セキュリティの専門家とペンテスターは、SAST と DAST が相性が良いと考えていますが、ほとんどの場合、IAST を使用することはありません。

結果を誰が受け止めるのか

これは、アウトプットが可能な限り実行可能なものになるようにしたいので、重要です。最終的には、開発者がすべてのスキャン結果を受け取り、それに基づいて行動する必要があります（つまり、修正する必要があります）。しかし、追加のキャッチャー(オペレーションやITなど)や中間処理者がいるかもしれません。

SAST と IAST の結果は、開発者にとって最も直接的に消費可能なものです。これらの結果は、開発者にとって最も直接的な情報（特定のコードの位置など）を保持しています。しかし、コードロケーションよりもレクリエーションシナリオを好む開発者は、DAST の方がより多くの利益を得られるかもしれません（これは、ユーザーが何に慣れるかの問題です）。

DAST の結果は、専門家やペンテスター、あるいは運用/IT (インフラストラクチャーの問題を修正するための) にとって、より意味があります。コードは、ほとんどの場合、彼らにとってはアクセスできないか、無関係なものです。

スキャンはいつ実行すべきでしょうか

スキャンには時間がかかります。コードレビュー、ユニットテスト、自動化された機能テストなど、開発ライフサイクルに別のタスクを導入する場合は、注意して行わなければなりません。セキュリティテストはそのようなタスクの一つに過ぎませんが、通常は無視されています。何が最も重要なのかを考える必要があります。

できるだけ早期に問題を発見することが最重要であるならば、SAST を使ってセキュリティテストを開発者に導入することは素晴らしい選択です。また、開発者は、特定の DAST テストアプローチが非常に有用であることに気づくことができます。

主な目的が既存のワークフローへの混乱を最小限に抑え、その影響を気づかれないようにすることであるならば、IASTはおそらくあなたの選択するテクノロジーです。アプリケーションと一緒にデプロイするために IAST を設定することは、一度だけの操作であり、一度それが行われると、アプリケーションは常に監視されます。アプリケーションとのインタラクション（自動機能テスト、手動テスト、統合テスト）があるたびに、アプリケーションはセキュリティの問題がないか監視されます。

あなたは、既存のチームの外部にテスト専門の新しいチームを作りたいと考えているかもしれません。そのような場合、DAST のテクノロジーは、彼らが選択するツールとなるでしょう。DAST は、テスターに、基礎となるコードや実行中のアプリケーションから最大限の分離を提供します。

スキャンの期待される結果は何ですか? 何を達成しようとしているのでしょうか?

これらは愚かな質問のように聞こえます。これらの質問は愚かな質問のように聞こえますが、その答えは、「アプリケーションをより安全にしたい！」ということです。しかし、使用する技術の種類を制限することは、ある種の節約を達成することを意味します。あなたは、金銭的にも、時間的にも、あるいは他のどんな条件でも、費用対効果を得ようとしています。そのためには、これらの質問に正直に答える必要があります。

例えば、サーバサイドのコードの安全性をより重視したり、優先順位を高くしたりしているかもしれませんし、開発者に開発ライフサイクルの可能な限り早い段階で問題に対処してもらいたいのであれば、SAST は正しい判断かもしれません。

もう一つの例としては、開発者の気が散るのを避け、時間の節約を促すことを優先することが挙げられます。これらの優先順位を満たすためには、IAST が適切でしょう。この技術は、あなたが何か他のことをしている間に欠陥を特定します。問題点を特定するのに必要な労力はほとんどありません。その「他のこと」をしている間に実行されているコードに限定されますが、基準セットの中では非常に安価です。

オーバーレイと外挿

これを読むと、誰がいつ何を使うべきかという明確な線引きがあると思うかもしれません。現実はもちろんもっと複雑で、重要なのは、それぞれの技術の長所と適合性を見極め、そのラインに沿って最適化することです。

そのラインを表すパラメータには、スキャニングの強さ、限界、リスク、想定ターゲットユーザー（ベンダーが想定）の 4つがあります。

SAST SAST は、サーバサイドの脆弱性（Webアプリケーションでは、モバイルとデスクトップアプリケーションのすべての側面をカバーしています）を特定するのに適しています。クライアント側の脆弱性も、特定の状況下では検出することができますが、SAST が得意とするところではありません。SAST の結果は、かなりの量のトリアージとクリーンアップを必要とする可能性があります。このプロセスは些細なものではなく、数回のサイクルを必要とすることもありますが、コード指向の結果は開発者にとって理想的であり、迅速な修正のターンアラウンドを得るために非常に効果的です。

DAST DAST はサーバサイドの脆弱性に対しても非常に良い仕事をしますが、3つの技術の中ではクライアントサイドの脆弱性に対して最も良い仕事をします。また、その能動的な性質により、はるかに正確な検証が可能となり、誤報告を減らすことができます。コードの位置がわからない一方で、テストペイロードはデバッグに役立ち、これは実行可能な代替手段として役立つかもしれません。DAST には、ある種の盲点があります。DAST が依存している、外部から見える副作用を発生させない問題を特定することはできません。DAST は、アプリケーションの入手困難な部分を見逃してしまう可能性があるため、カバレッジも問題となります。ユーザーがコードや実行中のアプリケーションと対話する必要がないため、DAST は、ペンテスターや帯域外のテストサイクルに最も適したツールです。

IAST IAST の強みは、サーバサイドの脆弱性検出にもあります。多くの点で SAST と多くの特長を共有していますが、結果の質がアプリケーションの機能のカバレッジの質に直接依存するという重大な制限があります。SAST の利点の一つは、内部コードの表現とともにリクエストデータを提示することです。これは、そうでなければ SAST にはない再現性とデバッグ機能を可能にします。第二の利点は、提案されたサニテーションとバリデーションコードの実行時検証です。サニテーションとバリデーションコードの信頼は、（よく知られたライブラリー関数が使用されていない限り）ヒューリスティックに行われるか、設定によって行われます。これはIASTでは要求されない。意図されたユーザーは、組織内で機能テストに従事している人なら誰でもよい。これにより、テストへの投資の可能性が大幅に高まり、以前は不可能であった、ビジネス的に意味をなさなかった開発フェーズでのテストが可能になります。

では、ギャップについてどう思いますか？また、そのギャップに耐えられるものなのでしょうか？

HCL AppScan では、どのような技術もあきらめるべきではない、というのが私たちの当たり前の結論です。諦めてはいけないというのが私たちの結論です。

詳細はこちら

ご自身でアプリケーションセキュリティテスト技術をテストするには、今すぐ AppScan の 30日間の無料トライアルをお申し込みください。

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

Key Financial Findings from Ponemon Institute’s “Application Security in the DevOps Environment” の翻訳版です。

Ponemon Institute の「DevOps環境におけるアプリケーションセキュリティ」の主な財務上の知見

2020年10月23日

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

IT支出の減少

ご存知のように、2020年は誰にとっても典型的な年ではありませんでした。以前、世界的な大流行がIT支出に与える影響について書いたことがあります。ガートナー社は2020年7月のレポートで、今年の世界のIT支出は3.5兆ドル (366兆円)（2019年比7.3％減）に減少すると予測しています。

アプリケーションの脆弱性が増加している

バー、レストラン、旅行などの世界経済の一部の要素は、パンデミックの影響からの回復が遅れていますが、悪意のある行為者は休んでいません。

それを裏付ける最近の統計をご紹介しましょう。

• 今年初め、TechRepublic誌に掲載された調査では、メールによるフィッシング攻撃が2020年2月末から2020年3月末にかけて667％増加したことが明らかになりました。
• 特にアプリケーションセキュリティの分野では、Security Boulevard誌に掲載された別の分析によると、2020年5月/6月の期間に80%以上のアプリケーションが SQL インジェクション攻撃を経験していることがわかりました。
• 同レポートによると、少なくとも3分の1のアプリケーションには、少なくとも1つの深刻な脆弱性が含まれていることが判明しています。

開発者の燃え尽きが課題に

これに加えて、今年のハイパーデジタルの世界を動かすために必要な新しいアプリケーションやアプリケーションのアップデートの数が膨大な数になっています。Wall Street Journal が報告した2019年の調査では、大企業がデプロイしたアプリケーションの平均数は129個という驚異的な数になっています。そう、その数は129個です。

管理すべきアプリケーションの量が増えていることに加えて、以下の要因が開発者の燃え尽きを助長しています。

• Octoverse Spotlight のブログによると、COVID-19 の時代には、開発者の仕事の時間は、従来のビジネスウィークと週末に 1 日 1 時間拡大しています。
• 同じ調査では、アクティブユーザーあたりのプルリクエスト、プッシュ、作成された課題など、ほぼすべての開発者活動のメトリクスが上昇していることがわかりました。
• アプリケーションボリュームの増加に伴い、今年作成されたオープンソースリポジトリの数もそれに応じて増加しており、2019年3月から2020年3月までの間に 28%近く増加しています。

要約すると、あなたのような組織が直面しているのは、予算の減少、脆弱性の増加、作業負荷の増加です。あなたの組織が直面しているサイバーセキュリティの脅威に対処し続けながら、これらの問題にどのように対処することができるでしょうか？いつものように、情報、経営陣の協力、予算の確保が手始めに重要なポイントとなります。

Ponemon Institute レポートの調査結果を経営陣と共有する

Ponemon Instituteは、2020年10月に "DevOps環境におけるアプリケーションセキュリティ "と題した調査を発表しました。HCL AppScanがスポンサーとなっているこの調査には、AppSecとDevOpsに関連した財務数値の宝庫が含まれており、経営陣と一緒にアプリケーションセキュリティテストを実施する際に活用することができます。この包括的なレポートはこちらからアクセスできます。

以下に、レポートから得られる主な財務上の知見を紹介します。

脆弱性のあるアプリケーションに対する攻撃による平均的な経済的損失総額

Ponemonの調査では、過去12ヶ月間に、脆弱性のあるアプリケーションに対する攻撃の結果、平均1,200万ドル (13億円)のコストが発生しています。言い換えれば、そのコストは月に約100万ドル (約1億円)であり、効果的なアプリケーションセキュリティテストプログラムを持たない企業では、さらに高くなる可能性があります。

経済的損失の合計 - 最悪のシナリオ

調査に含まれている組織の中には、脆弱性のあるアプリケーションへの攻撃の結果、1億ドルを超える信じられないような経済的損失を被ったものもあります。この1億ドルという数字は、フロリダ州交通局がタフニッケルに提供した見積もりによると、州間高速道路を13マイル建設するのにかかる費用とされています。この数字が経営者の注意を惹かないのであれば、何の意味もありません。

IT、AppSec、DevOps の平均予算

回答者によると、組織の平均 IT 予算は 9,960 万ドルでした。平均して、組織の今年度の IT 予算の 25% はアプリケーションセキュリティ活動に費やされることになります。さらに、組織の今年の IT 予算の 20% は、DevOps 活動に費やされることになります。

セキュリティ予算と投資の原動力

回答者の51％が、投資収益率（ROI）の向上が、組織のセキュリティ予算と投資の意思決定の重要な推進要因であると回答しています。総所有コスト（TCO）の削減が重要な推進要因であると答えたのは29%にとどまりました。

成功への障壁

回答者の41%が、予算が不足しているためにアプリケーション・セキュリティ・プログラムが効果的に機能していないと答えています。

AppSec と DevOps のその他の戦略的および財務的傾向については、こちらから包括的なレポートにアクセスできます。

詳細はこちら

10月29日午前11時（米国東部標準時）／午前8時（米国太平洋標準時）に開催されるウェビナーにご参加ください。Ponemon Institute の Larry Ponemon 氏と HCL AppScan の Eitan Worcel が調査結果を分析します。ライブセッションの後には、リプレイを視聴することができます。また、アプリケーション・セキュリティ・テスト技術をご自身でテストするために、今すぐ HCL AppScan の無料トライアルをリクエストしてください。

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

Ponemon Institute and HCL AppScan Reveal State of Application Security in DevOps Environments の翻訳版です。著者の許諾を得て翻訳版を公開しています。

Ponemon Institute と HCL AppScan、DevOps 環境におけるアプリケーションセキュリティーの現状を明らかに

2020年10月20日

著者: Larry Ponemon / Chairman and Founder of the Ponemon Institute

はじめに

HCL SoftwareがスポンサーとなったPonemon Instituteの「Application Security in the DevOps Environment」調査の目的は、アプリケーションの脆弱性を迅速に検出し、優先順位をつけて修復する組織の能力をよりよく理解することでした。

そのため、Ponemon Instituteは、ITセキュリティ、品質保証、または開発業務に従事する626名の個人を対象に調査を実施しました。さらに、調査回答者の組織はすべて、アプリケーションのセキュリティテストを含むDevOpsアプローチを利用しています。

このブログの目的は、この調査で得られた主な結果を要約することです。包括的なレポートを無料で入手するには、こちらをクリックしてください。

調査結果のショーケース

このレポートには、アプリケーション・セキュリティの保護と DevOps の利用に関する説得力のある調査結果が満載されていますが、その中でも最も説得力のある調査結果は以下の通りです。

• 脆弱性のあるアプリケーションへの攻撃は、私たちが予想している以上にコストがかかります。脆弱性のあるアプリケーションへの攻撃は、予想以上にコストがかかります。過去 12ヶ月間に、調査対象となった組織は、脆弱性のあるアプリケーションへの攻撃の結果、平均で 1,200万ドルの経済的損失を被っています。
• 調査対象となった組織の中には、脆弱性のあるアプリケーションに対する攻撃の結果、1億ドルを超える驚くべき経済的損失を被った組織もあります。この 1億ドルという数字は、調査に回答した組織の平均的な IT 予算総額を表しています。
• 脆弱性のあるアプリケーションへの攻撃を特定するのに平均8ヶ月近くかかり、攻撃から回復するのに 6ヶ月かかることがあります。
• 平均して、ビジネスクリティカルなアプリケーションの 67%が、継続的に脆弱性のテストを受けていません。
• 回答者の 74%が、セキュリティ上の懸念を評価する必要があるコードのために、多くのアプリケーションの開発サイクルが遅れており、それが組織のリリース期限に影響を与えていると述べています。
• 回答者の 71%が、DevOps セキュリティプラクティスにおける可視性と一貫性の欠如が、最終的に顧客や従業員のデータを危険にさらすことになると回答しています。

肯定的な傾向

本調査はまた、アプリケーション・セキュリティと DevOps のいくつかのポジティブな傾向にも光を当てています。

• 組織は、アプリケーション・セキュリティと DevOps に多額の投資を行っています。本調査の回答者の平均1億ドルのIT予算のうち、約 2,500万ドルがアプリケーションセキュリティ活動に、さらに 2,000万ドルがDevOps活動に割り当てられています。
• 組織がセキュリティ予算と投資を決定する主な要因は以下の通りです。リスクの低減（回答者の 65％）、コンプライアンス/規制の遵守（回答者の 53％）、投資収益率（ROI）の向上（回答者の 51％） * 組織がアプリケーションセキュリティテストを実施する際には、アプリケーションセキュリティのテストを実施しています。
• 組織がアプリケーションセキュリティテストを実施する際には、DAST、SAST、IAST、SCA、ペネトレーションテストなど、様々なテスト手法を活用しています。
• 特に有望な兆候として、回答者の 49％が、コーディングプロセス内の脆弱性を特定するために開発者に権限を与えていると回答し、47％が、コーディングプロセスの安全性を確保するためのトレーニングを確実に実施していると回答しています。
• 回答者の 52%が、ソフトウェア開発ライフサイクル (SDLC) の各段階での脆弱性スキャンの自動化が組織にとって重要であると回答し、56%が自動化ツールを使用して迅速に脆弱性を修正することが重要であると回答しています。

改善点

最後に、本調査では、AppSec と DevOps の専門家がより効果的であり、さらなる進展が必要な分野がいくつか明らかになりました。

• すでに配備されている脆弱性のあるアプリケーションに対する攻撃の 50%以上を防ぐことができたと答えた組織は 1 つもなく、回答者の 45%は、そのような攻撃を防ぐことができたのは 15%未満であったと答えています。
• 脆弱性のあるアプリケーションに対する攻撃が発生した場合、組織は、平均して 40%しか攻撃を検知し、食い止めることができないと報告しました。
• 半数近くの組織が、四半期ごとに、またはそれ以上の頻度でアプリケーションをテストしていますが、回答者の 6%は、1 年ごとにアプリケーションをテストしていると回答しています。回答者の 25%が、計画されたテストサイクルがないと回答しています。
• 調査回答者にとって、脆弱性のあるアプリケーションに対する攻撃を防ぐための主な障壁は、人手不足でした（回答者の 63%）。また、アラート疲労は引き続き大きな懸念事項であり、回答者の40%が、AppSec の調査結果がノイズを発生させすぎて、効果的に管理できないと報告しています。
• 脆弱性を可能な限り早期に修正できていると報告している組織は、わずか 38% にすぎません。

詳細

上記で説明した調査結果の詳細な分析を確認するには、レポートをダウンロードしてください。また、2020年10月29日の午前11時（東部標準時）、午前8時（太平洋標準時）、(翻訳者注: 日本時間 30日、午前1時) に開催されるウェビナーにもご参加ください。Eitan Worcel と私が、この研究の結果をより詳細に分析します。ライブセッションの後、ウェビナーの録画が利用可能になります。

Larry Ponemon 氏について

Ponemon Institute 会長・創設者

Larry Ponemon 博士は、Ponemon Institute の会長兼創設者であり、プライバシー監査と責任ある情報管理（RIM）フレームワークのパイオニアです。Ponemon 博士は、米国連邦取引委員会のオンラインアクセス＆セキュリティ諮問委員会に任命され、ホワイトハウスから国土安全保障省のデータプライバシー・整合性諮問委員会に任命されました。また、プライバシーおよびデータセキュリティ法に関するカリフォルニア州の 2 つのタスクフォースにも任命され、Shared Assessments の諮問委員会のメンバーでもあります。ユニオンカレッジで博士号を取得。ハーバード大学で修士号を取得し、カーネギーメロン大学のシステム科学の博士課程に在籍しています。Ponemon 博士は、アリゾナ州ツーソンにあるアリゾナ大学で学士号を取得しました。公認会計士、公認情報プライバシープロフェッショナル。