DevSecOps がボット管理に取り組むべき 6 つの理由

ジム・ダウニー

2022年7月21日公開

デジタル競争の時代において、すべての企業はテクノロジー企業であり、現代のイノベーションは金融から食料品、輸送に至るまでの業界に混乱をもたらしています。現代のテクノロジー企業として勝つには、競合他社よりも速く革新する必要があり、迅速な革新には DevOps が必要です。 DevOps は、開発者と IT 運用部門のコラボレーションであり、ソフトウェア配信に Lean 原則を適用することで、製品リリースのペースを大幅に向上させました。 DevOps には期待が寄せられていますが、ボット攻撃やその他のセキュリティ上の懸念が適切に対処されなければ、組織がそのメリットを享受できなくなる可能性があります。幸いなことに、DevOps によって DevSecOps が誕生しました。これは、DevOps のペースの速い世界において、セキュリティ上の懸念、特にボット管理に対処するのに適した役割です。

DevOps 文化では、DevSecOps が継続的インテグレーション/継続的開発 (CI/CD) パイプラインにセキュリティを組み込み、セキュリティバグに関する迅速なフィードバックを開発者に提供し、テクノロジバリューストリームへのセキュリティの統合を継続的に改善する責任を負います。

リーン製造プラクティスを基盤とする DevOps では、品質に関する考慮事項をバリューストリームの早い段階に移すことを重視し、やり直しのコストが大きくなる下流での障害を削減します。つまり、検査によって欠陥を発見するよりも、製品に品質を組み込む設計の方が効果的です。セキュリティは品質の重要な要素であるため、DevSecOps も同様にセキュリティを左に移動して、ギャップがワークストリームの早い段階で計画されるようにします。静的分析セキュリティテスト、動的分析セキュリティテスト、脆弱性スキャンなどのツールを早期に実行し、早期の開発者にフィードバックを提供し、早期にバグを修正できます。

要件収集、設計、コーディングでセキュリティに重点を置くほど、セキュリティ制御の効果が高まります。これらはセキュアコーディングとソフトウェア開発ライフサイクル (SDLC) の基本的な概念ですが、後からセキュリティに対処すると迅速な展開が妨げられたり、セキュリティリスクが発生したりするため、これらのプラクティスは DevOps 環境ではさらに重要になります。

現代の企業のセキュリティ保護における DevSecOps の重要な役割を考えると、ボット管理もその特定の分野の責任に含まれるべきであると言えます。ボット管理はセキュリティに不可欠であり、DevSecOps のミッションの中核をなすものであるだけでなく、DevSecOps は組織が悪意のあるボットから十分に保護されるようにするのにも理想的な位置にあります。そこで、約束どおり、DevSecOps がボット管理に取り組むべき 6 つの理由を以下に示します。

1) ボット対策はセキュリティとデータプライバシーに不可欠

ボットは、applicationsや API への HTTP リクエストの送信を自動化するスクリプトです。犯罪者は、ボットを使用して、さまざまな種類の攻撃で Web アプリやモバイルアプリを攻撃します。

クレデンシャルスタッフィング: 攻撃者は盗んだ資格情報をログイン情報と照合してアカウントを乗っ取ります。
偽のアカウントの作成: 犯罪者は、ソーシャルメディアでの影響力行使やマネーロンダリングなどの詐欺を実行するために偽のアカウントを作成します。（ Twitterの偽のアカウント問題に関するF5の分析を参照。）
カード処理: 犯罪者は盗まれたクレジットカードのデータを検証します。
カードクラッキング: 犯罪者はさまざまな値を試して、盗まれた支払いカードデータのセキュリティコードと欠落している開始日および有効期限を特定します。
ギフトカードの残高とポイントの盗難: 犯罪者は、ユーザーがギフトカードの残高やポイントを頻繁に確認しないという事実を利用して、これらの残高やポイントを盗みます。
購入/再販: 違法ブローカーは、期間限定のセールで商品を購入し、高値で転売します。
在庫の買いだめ: ボットは商品やサービスを予約しますが、購入を完了しないため、在庫がないように見え、正当な購入を妨げます。
スクレイピング: スクレイピングボットはアプリからデータを抽出し、競争上の不利を招き、サイトのパフォーマンスを低下させます。

ボット攻撃の包括的な分類については、 OWASP Automated Threat Handbookまたは Kyle Roberts によるこの概要を参照してください。

すべてのボット攻撃の中でも、クレデンシャルスタッフィングは特に悪質です。グローバルプライバシーアセンブリ (GPA)は、クレデンシャルスタッフィングと宣言しました。 130 を超えるデータ保護およびプライバシー規制当局と執行機関を代表する GPA は、ボット管理はデータプライバシーにとって今や必要な対策であり、したがってオンラインでビジネスを行うすべての B2C 企業にとって必須であると主張しています。

DevSecOps が組織とその顧客を保護するという使命を果たすには、悪意のあるボットの問題を解決することが重要です。

2) ボットはDevOpsが依存するテレメトリを破壊します

DevOps ハンドブックによると、テレメトリは複雑なシステムにおける問題を予測、診断、解決するために不可欠です。複雑なシステムとは、大きすぎて相互に絡み合っているため、1 人の人間がすべての部分のつながりを理解することができないシステムのことです。 DevOps を成功させるには、テレメトリがビジネスメトリック、機能の使用状況、ネットワークパフォーマンス、インフラストラクチャの負荷などの複数のレイヤーをカバーし、1 つのレイヤーの問題をスタック全体で追跡して根本原因を迅速に特定できるようにする必要があります。

ボットはテレメトリを大きく歪めます。 F5 Distributed Cloud Bot Defenseの多くの顧客は、ユーザーアカウントのほとんどが偽物であり、ログイントラフィックの 95% 以上がボットによるものであることを発見しました。場合によっては、組織のインフラストラクチャの大部分がスクレイピングボットにサービスを提供しているだけでした。

人間とボットを区別する能力がなければ、テレメトリは無意味になります。機能が失敗する原因は実際のユーザーによるものでしょうか、それともボットによるものでしょうか? ログイン成功率がこれほど変動するのはなぜですか? 特定のapplicationパスへのトラフィックが急増した原因は何ですか? ボットはノイズで信号をかき消します。

DevOps を成功させるには、意味のあるテレメトリが必要であり、テレメトリを意味のあるものにするには、ボットを検出する機能が必要です。 DevSecOps はボット管理に携わり、DevOps に不可欠なデータの整合性を確保することで、DevOps の成功に大きく貢献できます。

3) ボット対策はコードセキュリティではなく、開発タスクだけの問題でもない

開発者がコーディングのベストプラクティスと脆弱性テストを通じて対処できる従来の脆弱性とは異なり、ボット攻撃は主に、ログイン、パスワードを忘れた場合、製品のチェックアウト、製品の価格情報など、アプリが公開する必要がある正当な機能をターゲットにします。 (F5 の Dan Woods は、Pirate Radio のインタビューで、これらを固有の脆弱性と呼んでいます。) ボット保護はアプリのセキュリティに不可欠ですが、安全なコーディングに関するものではなく、開発者だけでは解決できません。ボット保護は、開発者と InfoSec の間の領域、つまり DevSecOps が占める領域に該当します。

犯罪組織は検出を回避するボットを開発する動機が強いため、悪意のあるボットから保護することは驚くほど困難です。 CAPTCHAは機能しなくなりました。 ML と人間のクリックファームを使用した CAPTCHA 解決サービスにより、CAPTCHA の解決が高速かつ安価になります。 (Dan Wood のTales of a Human CAPTCHA Solver を参照してください。) ボットは、JavaScript を実行して作業証明を満たし、実際の人間の行動を模倣し、微妙なランダム性を導入し、プロキシネットワークを悪用して、何百万もの有効な住宅用 IP アドレスを通じてその起源を偽装します。そして犯罪者は、検出後数時間以内にボットを改造します。ボットのこの高度化と急速な進化により、WAF ルールを手動で更新してボットを阻止する時代はとうに過ぎ去りました。

このレベルの労力を開発担当者に強制すると、機能のリリースが妨げられます。 WAF ルールの更新を運用チームに押し付けると、すべてのリソースが消費されてしまいます。組織は、ボット管理ソリューションをテクノロジーバリューストリームに統合するために、DevSecOps を関与させる必要があります。

4) DevSecOpsはアプリのロジックを理解しており、これは効果的なボット保護に不可欠です。

ボットからの保護は純粋に開発タスクではありませんが、従来の意味での純粋に運用タスクでもありません。ボット保護を構成するには、application、その要件、設計、実装に関する詳細な知識が必要です。

上記のボット攻撃の種類を見ると、どれがあなたのapplicationに当てはまりますか? これらの攻撃タイプごとに、ボットはどのパスまたは API を狙うのでしょうか? これらのパスのそれぞれについて、ボットと人間を区別するために必要なデータを収集するための信号収集をどこで実行できるでしょうか?

F5 では、Web のボット保護を構成する際に、保護されたパスをエンドポイント、インストルメンテーションを必要とするページをエントリポイントと呼びます。ログインを想像してください。 1 つの Web ページにログインフォームをホストする場合があり、これをエントリポイントと呼びます。そして、そのフォームは特定のパスに投稿される可能性があり、これをエンドポイントと呼びます。もちろん、いつもそう単純なわけではありません。ログインフォームは多くのページに存在する可能性があり、これらのフォームは異なるパスに投稿される可能性があります。

モバイルでも同様です。モバイルアプリをボットから保護するには、通常、テレメトリ計測用の SDK を統合する必要があります。どのネットワーク要求にこのテレメトリを含める必要があるかを判断するには、アプリに関する知識が必要です。

構成に必要なこのアプリの知識を考えると、ボット管理は DevSecOps に適しています。特に、要件と設計のフェーズでボット管理を検討する際には、このステップを左に移動するのが理にかなっています。

5) DevOpsはインフラストラクチャを理解している

ボットから保護するには、同様にネットワークインフラストラクチャを理解する必要があります。一般的に、ボット保護は、CDN、ロードバランサー、API ゲートウェイ、イングレスコントローラー、applicationプラットフォームなどのネットワーク内のレイヤーから呼び出される API を介して提供されます。これらのレイヤーの 1 つは、リクエストが人間からのものかボットからのものかを判断するために、関連するトラフィックをボット管理 API に送信するように構成されます。

DevSecOps チームは、開発および運用と連携して、これらの API 呼び出しを完全に自動化 (CI/CD パイプラインの一部として) し、最適なパフォーマンスを提供する方法で実装する場所を決定する方法について、最も幅広い視点を持ちます。

6) DevSecOpsはボット管理をCI/CDパイプラインのどこに組み込むべきかを知っている

組織がテクノロジーバリューストリームを通じて新しい機能をリリースすると、WAF などの他のセキュリティコンポーネントと同様に、ボット防御にも構成の更新が必要になります。 DevSecOps チームは、CI/CD パイプラインのどこでこの自動構成更新を行うべきかを判断するのに適した立場にあります。

これは、ボット保護がボットとして検出される自動 QA テストに干渉する可能性があるため、最初に見えるよりも複雑です。この問題を解決するには、ヘッダーまたは IP アドレスを介してテストツールを許可リストに追加したり、自動 QA テストが完了した後にのみボット保護を導入したりするなど、複数の方法があります。

最も重要なのは、DevSecOps が開発および情報セキュリティと連携して、ボット保護が必要な場所を特定し、関連する機能がリリースされたときにボット保護が確実に実施されるようにする方法を提供する必要があることです。

まとめ

消費者向けapplicationsを提供する組織は、顧客のデータプライバシーと財務セキュリティを保護し、オンラインでの安全を確保する必要があります。 DevOps によって可能になる急速なイノベーションを通じて競争上の優位性を追求する組織では、セキュリティがリリースのペースに追いつくように DevSecOps で顧客を保護する必要があります。 DevSecOps の責任の中で、ボット管理は不可欠です。ボット攻撃は顧客のセキュリティを重大なリスクにさらします。DevSecOps は、悪意のあるボットから防御し、組織が安全に急速なイノベーションを採用できるようにするために非常に価値のあるスキルを提供します。

ボット保護の ROI に関する詳細な情報については、 Forrester Total Economic Impact Report を参照してください。詳細を確認し、F5 ボットエキスパートとの会話をスケジュールするには、 f5.com/ bot-defense にアクセスしてください。