インシデントレスポンダー：完全にまたは部分的に自動化された応答に適したインシデント/インシデントのタイプの例をいくつか挙げていただけますか？
セキュリティ監視を設定します-完全な商用SIEM/SOCまたは自家製の何か（たとえば、rsyslog-> OSSIM/MozDef/Splunk/...）。また、イベントのトリアージが行われるようにいくつかのルールを設定し、潜在的なインシデントについてのみアラートを取得します。
この時点以降、どのような自動化が行われているかを知りたいのですが。より多くの警告/電子メールまたはレポートの送信だけでなく、インシデント自体を解決しようとする何か。
いくつかの使用例と自動化ソリューションのいくつかの例（標準またはDIY）が役立ちます。
頭のてっぺんには何も言わない。 SoC/SIEMの目的は、インシデントを評価し、次に実行するアクションを決定するために、人間のアナリストに注意を向けることです。人間が「目を向ける」ことを望まないものはすべて、SIEMのルールセットから調整する必要があります。
自動化したい特定のリスクの低いものがあるかもしれません。たとえば、マルウェアが隔離または削除されたAVヒットが発生するたびに、アナリストが最初の調査を実行している間にチケットが発生し、ボックスが再スキャンされますが、通常これはSIEMによって行われることはありません。 （一部のSIEMはこの機能を備え、一部のSoCはこれを行うためにSIEMを使用します。）
通常、成熟したSoCには、調整されていない一般的なアラートの手引きがあります。たとえば、xが発生した場合、次にa、b、cを実行し、さらにレベル2のアナリストにエスカレートして、調査。これは、自動化というよりは、標準的な操作手順を持つことです。
リクエストの破棄や無視などのアクティブな応答は、私が取り組んだ唯一の自動応答です。
すべての商用IPSまたはWebアプリケーションファイアウォールがこれを行います。HIDS/ HIPSは、非常に小規模な展開の場合にも考慮できます。
単純なWAFルールは、次の場合に攻撃者を一定期間ブロックする可能性があります。
- User-Agentがwgetまたはcurlまたは同様の自動化である場合
- 誰かが既知の特定の明確なエクスプロイトを試みた場合
- 誰かが悪用の明確に定義されたカテゴリーを試みた場合：ディレクトリトラバーサル、SQLインジェクション、
WAFを調整して、以下のようなブロックを含めることができます。
- 所有していないテクノロジーを示すページのリクエスト（aspxなど）
- 一般的な管理ページ/admin.phpのリクエスト
IPSもこれを実行できますが、httpプロトコルに関する情報を提供せず、代わりに生のパケットを提供する傾向があるため、署名の精度は低くなります。これにより、WAFやプロキシ自体への攻撃の検出、HTTP/HTTPS以外の攻撃などの追加機能が提供されます。
これらの種類の応答は、通常、信頼性の高い署名に限定されます。商用ベンダーは、その署名情報に信頼係数を含める傾向があり、それに応じてブロックを制限できます。
Snort、McAfee Intrushield、IBM SiteProtectorは、これまで使用してきたIPSです。 WAF応答に使用したF5のASM。 fail2ban、OSSSEC、HIDS側。
http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node26.html
http://ossec-docs.readthedocs.io/en/latest/manual/ar/
自動化されたブロックは毎日レビューされ、リアルタイムで監視されます。署名が制作に影響を与えるリスクは非常に現実的です。シグネチャはDev/Stage/Prodサイクルで展開されるため、完全なテストサイクルなしでは新しいシグネチャが本番環境に到達しません。