2021 アプリケーションセキュリティに関する 2021年の自分なりの展望

2021/1/13 - 読み終える時間: 3 分

2021 Robservations for Application Security の翻訳版です。

2021 アプリケーションセキュリティに関する 2021年の自分なりの展望

2021年1月7日

著者: Rob Cuddy / Global Application Security Evangelist

画像の説明

1 年前、アプリケーションセキュリティのホットな話題のほとんどは DevSecOps に関連していました。継続的なデリバリパイプラインでのセキュリティテストの自動化、開発者をセキュリティテストにもっと参加させるための最良の方法を見つけ出すこと、またはセキュリティ運用センター (SOC) のセキュリティ専門家が開発チームとより良いパートナーになるための方法を見つけることなど、DevSecOps を現実のものにすることが話題になっていました。

そして、パンデミックが発生しました。

パンデミックの流行に伴い、特にランサムウェアを介したサイバー攻撃が驚くほど増加しました。これにより、DevSecOps は「必要なものを持っているイニシアチブ」から「必要不可欠なプログラム」へと移行する必要性が強調されました。さて、予想以上に困難な一年に「さようなら」と言ったところで、アプリケーション・セキュリティに関連して 2021 年に注目すべき重要なことは何でしょうか?という質問をいただきました。

QAがセキュリティパーティに参加する(ありがとう、IAST!)

多くの組織では、DevOps パイプラインに何らかの形で自動化されたセキュリティテストを組み込み、通常は継続的な統合ビルドの一部として実施しています。これにより、SDLC の早い段階で開発チームにより良いフィードバックが得られます。しかし、DevSecOps が DevOps のスピードで高品質のセキュアなソフトウェアをリリースするレベルに到達するためには、セキュリティは全体的な品質を構成する不可欠な要素と見なされなければなりません。機能性とパフォーマンスが品質とユーザーエクスペリエンスを牽引するのと同じように、今ではセキュリティも同様に重要な要素となっています。

2020年には、QA の専門家が他の種類のテストと並行して何らかの形のセキュリティテストを実施することを求められるようになっています。DevOps 環境におけるアプリケーションセキュリティ」と題した Ponemon Institute の調査では、620人以上の回答者のうち11%が、自分の役割に品質保証が含まれていると報告しています。

また、セキュリティテストに QA をより良く関与させる方法を探している組織には、インタラクティブ・アプリケーション・セキュリティ・テスト(IAST)を利用することをお勧めします。インタラクティブなテストでは、アプリケーションの動作に合わせてセキュリティ脆弱性を発見することができます。これは、QA チームが機能テストを実施している間に、同時にセキュリティ問題を発見することができることを意味します。そして、これらの脆弱性がアプリケーションの使用中に発見されるという事実は、誤検出率がゼロに近いことを意味します。

開発者に優しい脅威のモデリング

脅威のモデリングは、2020年の DevOps 関連イベントで頻繁に登場したトピックでした。 DevOps Enterprise SummitSAYA 10x イベントでのセッションは、ほんの一例でした。そして、これは私の同僚である Colin Bell 氏と私が個人的に All Day DevOpsAgile Techwell DevSecOps Summit で議論したトピックである。これらはすべて、セキュリティの可視性を高め、開発者とセキュリティ専門家の連携をより良くするための方法として、脅威モデルの演習に開発者をより多く関与させるという考え方を肯定しています。

そして2020年後半には、脅威モデリングをより効果的なものにするための中核的な価値観と原則を提供する、協調的な脅威モデリングのマニフェストが発表されました。その中で言及されているコア・プリンシプルの1つを紹介しよう。

"脅威のモデリングは、組織の開発プラクティスと整合性をとり、システムの管理可能な部分を対象とした反復的な設計変更に従わなければならない。

ここで強調されているのは、開発プラクティスとの整合性です。これを実現する最善の方法は、開発者を脅威モデルの演習に参加させることです。これにより、少なくとも 2 つの明確な利点が得られる。

  • 開発者は、コードが侵害される可能性のある無数の方法についての洞察を得ることができ、これが直接、より良いコーディングの実践につながるはずである。
  • セキュリティの専門家は、開発者にかかる圧力と実務についての洞察を得ることができ、脆弱性の優先順位付けと管理の改善、特にバックログの管理につながるはずです。

開発者を脅威モデルに組み込む方法を探している場合は、カードゲームElevation of Privilege(Githubにもあります)や Backdoors & Breaches のようなリソースは、楽しくて罪のない環境で議論や教育を促進するのに最適な方法です。

新たなベストプラクティス - 特にオープンソースのために

セキュリティは常に重要視されてきましたが、多くのビジネス専門家がリモートワークに移行し、サイバー犯罪の増加がすでに指摘されていることもあり、セキュリティは CISO だけが中心となって取り組むべきテーマから、すべての人が最優先で取り組むべきテーマへと変化しています。組織がリスクを低減するためには、費用対効果の高い効率的な方法でリスクを低減することが最重要課題となっています。

そのため、より多くのベストプラクティスが必要とされています。

公平に見ても、今日では、機械学習を活用して開発チームに結果を提示する前に誤検出を識別するなど、優れたアプリケーション・セキュリティのベストプラクティスが数多く存在しますが、これまでのところ、そのほとんどは社内コードに焦点を当てています。

オープンソースの利用が急増しているこの時代には、定義されたベストプラクティス、テクニック、リファレンスアーキテクチャ、オープンフレームワークやコード共有に関する教育やトレーニングが必要とされています。私は 2021年にはこのニーズが大きく高まると予想していますが、実際、現在、OSSF(Open Source Security Foundation)と呼ばれるグループがまさにその取り組みを行っています。議論に貢献することに興味があるなら、Github のワークグループをチェックしてみてください。

アプリケーションセキュリティのベストプラクティスのためのもう一つの素晴らしいリソースをお探しなら、友人のTanya Janca (@shehackspurple)さんの新刊 Alice & Bob Learn Application Security をぜひチェックしてください。

実際のエントリーレベルと明確なキャリアパス

2021年にもっと多くの議論が行われると予想されるもう一つの分野は、セキュリティ関連のキャリア、特にエントリーレベルのポジションに関連したものです。

サイバーセキュリティのスキルギャップが深刻化しているという統計を聞いたことがあります。問題の真の部分は、スキルを学び成長させることができる現実的なエントリーレベルの職務を持つことであり、それに加えて、セキュリティの専門知識のキャリアパスが明確に定義されていないという追加の課題があります。私の友人の CISO の一人が、David Spark 氏のポッドキャストにゲストとして出演した際に、次のように語っていました。

「私たちのような立場の人間にとって、エントリーレベルの役割とは何かを定義するのは非常に難しいことです。私たちは誰一人としてセキュリティの初級職に就いたことがありませんでした。私たちは最初のセキュリティ担当者で、自分たちで作り上げていったのです」

今日では、学んだスキルを証明するためのさまざまな資格が存在しますが、その多くは取得するのに相当な時間とエネルギー、労力を必要とします。中には現場での経験を必要とするものもあり、「鶏と卵」の問題が発生します。

簡単に言えば、私たちはもっと良い方法を採る必要があるということです。学界と協力して、正しい基礎スキルを教え、卒業生がサイバー活動に参加して意味のあるエントリーレベルの役割を果たすために必要な能力を身につけられるようにしなければなりません。そして、成功に向けてのプロセスの一部として、リスク、失敗、学習、成長といった個々のニーズを、組織が許容するリスク許容度とのバランスをとることができるようにしなければなりません。メンターシップや見習いは、それを可能にするための長い道のりを歩むことができます。

詳細はこちら

アプリケーションセキュリティは重要であり、2021年には、継続的なメトリクスに基づいた改善が、アプリケーションセキュリティテストプログラムに与える影響を最大化するための努力を続けていきます。これが何を意味するのかについて詳しく知りたい方は、Application Paranoia ポッドキャストを聴いて、IAST のエピソードをご覧ください。 このポッドキャストは、Apple Podcasts、Spotify、Google Podcasts、Buzzsprout で視聴できます。 また、ポッドキャストの同僚である Colin Bell 氏とKris Duer 氏との Continuous Security ウェビナーもご覧いただけます。


HCL AppScan: 開発者による新機能解説

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

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

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


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

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 に関するブログシリーズの第2部へようこそ。パート1では、最も一般的なタイプの脆弱性である 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環境におけるアプリケーション・セキュリティ」レポートはこちらからダウンロードできます。



AppScan: データセンターを EU に開設

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

HCL AppScan on Cloud est arrivé en Europe! の翻訳版です。


AppScan: データセンターを EU に開設

2020年11月21日

著者: Julie Reed / Senior Product Manager

画像の説明

正直に言うと、私は今年何度もヨーロッパに行こうとしてきましたが、他の多くの人と同じように、国境閉鎖や旅行制限によって計画が中断されてきました。一度ではなく、二度ではなく、三度も。今日、ヨーロッパで AppScan on Cloud サービスが開始されたことで、やっとの思いでヨーロッパに行くことができました。

AppScan チームは、市場をリードする当社のアプリケーション・セキュリティ・スイートを、欧州地域にデータを常駐させたクラウド・サービスの利用を希望する欧州の組織に提供できることに興奮しています。

AppScan on Cloudは完全に管理されたソリューションで、迅速に立ち上げて運用することができるため、ソフトウェアの導入に集中するのではなく、セキュリティリスクと脆弱性に集中することができます。このスイートには、静的解析 (SAST)、動的解析 (DAST)、インタラクティブ解析 (IAST)、ソフトウェア構成解析 (SCA) が含まれており、脆弱性を検出し、アプリケーションの安全性を確保するために、指先ですべてのツールを使用することができます。

すべてのスキャンの結果は、アプリケーションの下に集約され、アプリケーションの状態を一目で評価することができます。 ダッシュボードでは、ビジネスユニットまたは関連するアプリケーションのグループのレベルで、リスクと AppSec プログラムを表示できます。

主要な開発者 IDE や CI/CD ツールとの統合により、AppScan を使用したアプリケーションセキュリティテストを開発プロセスやパイプラインに簡単に追加することができます。

AppScan on Cloud は ISO 27001 認証を取得しており、SOC 2 認証を取得したドイツの Microsoft Azure でホストされています。

当社の新しい EU データセンター http://cloud.appscan.com/eu をご覧ください。ページの左上隅にある AppScan のロゴに続く EU の略語を探してください。

画像の説明

AppScan on Cloud の詳細や Proof of Concept の開始にご興味のある方は、こちらからお問い合わせください。

悲しいことに、私はスウェーデンの家族を訪問するために来年まで待たなければならないかもしれませんが、素晴らしいニュースは、HCL AppScan on Cloud を開始するために全く待つ必要がないということです。


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

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 ソースコードの静的分析を実行し、XSSSQL インジェクション、ディレクトリやファイルへの不正アクセスの可能性(ディレクトリ・トラバーサル)、ダイナミック・コールの操作(コール・インジェクション)、不十分な権限チェック、ユーザー管理のバイパスなど、コード内の脆弱性を発見します。

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

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

詳細

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


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

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 は、これらの様々な方法をどのように使用するかを例示する素晴らしいリソースを提供しています。

図2:脆弱性と改善策の情報 画像の説明

詳細

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


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

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日間の無料トライアルをお申し込みください。


このブログについて

HCL Japan の Software 部門の複数担当者で HCL Software 全般について記しています。