サイバーセキュリティ
CSIRTの主たる担当業務である。検知フェーズで発見したセキュリティイベントにタイムリーに対応できるよう対応計画を事前に定めておき、法執行機関の支援が得られるよう情報共有や利害調整を行う。そして対応計画にしたがってインシデント分類し、フォレンジックを行うなどしてセキュリティイベントを調査し、その影響範囲を把握し、事前に定めた基準に従ってインシデントの封じ込めないし低減を行う。インシデント対応の結果学んだ教訓を生かして対応計画を更新する。
タイムリーに復旧できるよう事前に復旧手順を定め、復旧の際にはその計画を実施する。システムの復旧を行うのみならず、広報活動を管理するなどして評判回復に努める。対応フェーズと同様、教訓を生かして復旧計画の更新も行う。
システムの安全性を確実に担保するにはシステム開発ライフサイクルの初期段階からセーフティ、セキュリティ、プライバシーなどを考慮しておくことが望ましい。開発プロセスのより早い段階でセキュリティを考慮する事を(開発プロセスを左から右に書いたときにセキュリティを考慮するのを左に寄せる事から)シフトレフトという。特に、情報セキュリティを企画・設計段階から確保するための方策をセキュリティ・バイ・デザイン(Secure By Design、SBD)といい、プライバシーに対する同様の概念をプライバシー・バイ・デザインという。
またDevOps(デブオプス、開発 (Development) の担当者と運用 (Operations) の担当者が一体となった開発手法)の普及に伴い、これにセキュリティの確保も一体になった開発手法であるDevSecOpsも注目を集めるようになっている。DevSecOpsでは設計段階からセキュリティを意識することはもちろん、セキュリティ対策ツールを開発ライフサイクルに組み込むなどして脆弱性診断を自動化し、アプリケーションを修正するたびに脆弱性を作り込まないようチェックし、利用しているライブラリの脆弱性を日々チェックするような活動も含む。
システム開発ではその工程の一部を外注する事も多いため、サプライチェーン全てでセキュリティを担保する事が重要となる。このような調達時の脅威に対応する事をサプライチェーンチェーンリスクマネジメント(Supply Chain Risk Management、SCRM)という。ISO/IEC 27036ではアウトソーシングの際のセキュリティのガイドラインが規定されている。米国ではNIST SP800-161やNIST IR 7622にSCRMの規定がある。またISO/IEC 20243には不良品や偽造品を排除するためのベストプラクティス等が規定されている。
また事業継続計画(BMC)の観点からもサプライチェーンの継続を図ることも重要であり、SCCM(Supply Chain Continuity Management)と呼ばれ、ISO 22318に規定されている。なお災害復旧とサプライチェーンマネジメントをあわせてSCDRM(Supply Chain Disaster Recovery Management)と呼ぶ。
多層防御 (セキュリティ)多層防御とは、様々な階層で複数のセキュリティ対策を施す事で、重要部への侵入前に攻撃の検知および対応を行う事で、軍事・戦闘の世界のDefense in Depth (縦深防御) を応用したものである。複数の防御壁を設けて、一つの壁を突破されても次の壁で阻止して、機密情報に到達されてしまう確率を下げる事を目的とする。
多層防御の手法として以下で述べる入口対策、内部対策、出口対策の3つを取り入れる組織内対策や、複数組織をまたがった攻撃連鎖を上流で断つ国レベルでの対策などがある。
入口対策はファイアウォール、ウイルス対策ソフト、脆弱性対策など、攻撃者やマルウェアが組織内に侵入するのを防ぐ対策手法で標的型攻撃やAPTが普及する以前は有効であった。しかし標的型攻撃やAPTでは組織に侵入する方法が巧妙化しており、しかも侵入方法の変化が激しいので、入口対策だけで攻撃を防御するのは難しい。そこで、攻撃者が組織内部に侵入しているのを前提として、組織の内部対策を行う事より侵入の拡大を防ぎ、攻撃の外向き通信を遮断・監視する出口対策により組織からの情報の持ち出しやC&Cサーバとの通信を防ぐ必要がある。
サイバーレジリエンスは攻撃を受けてしまう事を前提として、攻撃を受けた際に、どのように組織の機能を維持し、いかにすばやく対処・復旧するかという回復力(レジリエンス)を高めるべきという考え方である。 世界経済フォーラムによる「グローバルリスク2013」を契機として「レジリエンス」という用語がビジネス等で使われるようになり、それと時期を同じくしてサイバーレジリエンスという用語も広まった。なお「レジリエンス」という用語はISO22300では「複雑かつ変化する環境下での組織の適応能力」と定義されている。
非武装地帯(DMZ、DeMilitarized Zone)はメールサーバ、ウェブサーバ、DNSコンテンツサーバ、Proxyサーバといった、組織内、インターネット双方とアクセスする必要があるサーバ群を置いておくためのネットワーク領域で、組織内ネットワーク・インターネット・DMZの3つの領域間の通信をファイアウォールで制限する。ウェブサーバ等をDMZではなく組織内ネットワークに設置すると、ウェブサーバが用いるポートを開けて置かなければならない為、そのポートを利用してインターネットから組織内に攻撃を行う事が可能になってしまう。これを防ぐためにウェブサーバ等をDMZに設置する。
ネットワークを細かくセグメント分けする事。マイクロセグメンテーションにより、セグメントをまたいだラテラルムーブメントやウィルスの二次感染を防ぐ事ができる。実現手法としてh、スイッチングハブの各ポートにそれぞれ1台の機器を接続するというものがある。また仮想マシン(ないし仮想デスクトップ)の場合は各仮想マシンに仮想ファイヤーウォールを立てる事で、同一ネットワーク上にある仮想マシンであっても、仮想マシン一台で一つのセグメントを構成できる。
ゼロトラストはForrester ResearchのアナリストJohn Kindervag(ジョン・キンダーバグ)により提唱された概念である。従来のセキュリティ対策ではネットワークの境界で攻撃の遮断が可能であり、境界内は信頼できる事を前提としていたが、標的型攻撃や内部犯行の広がりによりこうした前提は崩れており、攻撃者が内部に侵入してくるのを前提とした対策が必要となる。
それに対しゼロトラストは従来型のセキュリティ対策よりも「性悪説」に基づいており、組織内ネットワークであっても、ユーザがデータやリソースにアクセスする際、ユーザが利用しているデバイスの信頼性とユーザ自身の信頼性とを動的に評価してデータやリソースへのアクセス認可を行う。一般的にはゼロトラストネットワークはユーザ関連情報を管理する ID プロバイダ、リソースにアクセスできるデバイスのリストを管理するデバイス ディレクトリ、管理者が設定したポリシーにユーザとデバイスが適合しているかを判断するポリシー評価サービス、リソースへのアクセス制御を行うプロキシから構成され、ゼロトラストネットワークのプロキシはユーザとリソースの間に置かれ、ユーザはプロキシでアクセス認可を受けた場合のみがデータやリソースにアクセスできる。
アクティブディフェンス(Active defense、能動的防御)は、実際の攻撃に先んじて脆弱性や攻撃方法を発見して予防策を積極的に構築する取り組みの事。攻撃者が防御技術を研究して回避・無効化する事で、対応が後手に回って攻撃側に主導権を握られるのを防ぐ。
アクティブディフェンスの基本的手法としては以下のものがある:
アノイヤンス(Annoyance):攻撃の労力を増加させる事。デコイサーバや偽のDNSエントリなど各種デセプション技術で攻撃者を騙し、時間を稼ぐ等。
アトリビューション(Attribution):攻撃者の属性(Attribution)を明らかにする事。攻撃されそうなサーバやファイルにウェブビーコンやマクロ等を仕込んで攻撃者のIPアドレスや位置情報を取得する等。
アタックバック(Attack Back):攻撃者に攻撃し返す事。
なおアタックバックはアクティブディフェンスに含まないとする意見もある。
フリーのアクティブディフェンスツールとしては、ADHD(active defence harbindger distribution)、Artillery、Nova (Network Obfuscation and Virtualized Anti-Reconnaissance)、BearTrap、Decloak、Honey Badgerなどがある。
アクティブディフェンスの手法の一つ。これまでのセキュリティ対策では、静的なシステムに検知技術や防御技術を導入することでセキュリティを担保していたが、それに対しMoving Target Defense (MTD)は、守るべきシステムの構成、特にネットワークを動的に変更する事で、攻撃者がシステム内を探索したりシステム構成を予測したりするのを難しくする手法である。従来のセキュリティ対策では、攻撃側がシステムを熟知しているのに対策側は攻撃者に関して断片的にしか知りえないという非対称ゆえの不利が対策側にあったが、MTDはこの種の不利を攻撃者にも背負わせようというアイデアである。
優先的に対策すべき場所を示したガイドラインとして下記のものがある:
2018年現在の最新版であるVersion 7の20個の評価項目は以下の通りである:
2017年度版の10項目は下記のとおりである:
2018年現在は下記8項目:
本節では、システムのセキュリティ上の問題点を洗い出す検査や診断について述べる。なお、こうした検査や診断は脆弱性検査、脆弱性診断、セキュリティ検査、セキュリティ診断等と呼ばれるが、これらの語の指す範囲は論者やセキュリティ企業により異なる場合があるので注意されたい。
このような用語上の混乱をさけるため、本節ではペネトレーションテスト等も含めた最広義の意味での脆弱性検査(すなわちIPA意味での脆弱性検査)の事を「脆弱性診断関連の検査」と呼ぶことにする。
IPAによると、脆弱性診断関連の検査にはソースコードセキュリティ検査、ファジング、システムセキュリティ検査、ウェブアプリケーションセキュリティ検査、ペネトレーションテストの5つがあり、これらの検査を行うフェーズと主な検査対象は下記のとおりである。なお本節では、これら5つにレッドチームを加えた6つの検査について述べる。
上の表の「主な利用フェーズ」は検査対象となる機器のシステムライフサイクルの中でどのフェーズでこれらの検査が利用されるのかを示している。なお、一般的にシステムの開発フェーズは企画、要件定義、設計、実装、テスト、納入という工程からなるが、これらの工程のうち脆弱性診断関連の検査が行われるのは実装工程とテスト工程である。
脆弱性診断関連の検査はPCI DSSやコモンクライテリアのような基準や規格で定期的に実施する事が要求される場合がある。
ソースコードセキュリティ検査は、開発中のソフトウェアのソースコードをチェックする事で、セキュリティ上の問題点を発見する検査であり、おもに実装工程で行われる。その目的は、脆弱性を引き起こしやすい関数をソースコードから抽出したり、構文解析により脆弱性であると思われる箇所を特定する事である。
検査は人間によるソースコードレビューにより行われることもあるし、何らかのツールやサービスを用いて自動的にソースコードを検査することもある。
なお、ソースコードセキュリティ検査は実装段階で混入する脆弱性を発見するものであるので、そもそもソフトウェアの設計そのものに脆弱性があってもそれを発見するのは難しい。
ファジングファジングは開発したソフトウェアに脆弱性を引き起こしやすい様々な入力を与える事で、脆弱性を発見する手法である(インプットとして極端に大きな値を入力してみるなど)。ファジングは実装工程やテスト工程において、何らかのツールやサービスを利用して実行される。
ソースコードセキュリティ検査がソースコードを利用するホワイトボックステストであるのに対し、ファジングはソースコードを使わないブラックボックステストないしグレーボックステストである。
ソースコードセキュリティ検査と同様、ソフトウェアの設計そのものに含まれる脆弱性を発見するのは難しい。
制御システムセキュリティのEDSA認証ではファジングが必須になっているなど、ファジングの標準化の流れがある。
ファジングを出荷前に行う事により、出荷後に脆弱性が原因で回収等で莫大なコストが発生する可能性が下げられる。ファジングも導入費用とツールの保守費用をあわせて数百万から数千万円程度かかるが、半年程度で投資回収できるとされる。
脆弱性検査ツール#ネットワーク脆弱性検査ツールシステムセキュリティ検査は、システム上の機器に対してパッチのあたっていない脆弱性が存在しないか、不必要なポートが空いているなどの設定上の不備がないかを調べる検査である。何らかのツールやサービスを用いて主に開発時のテスト工程と運用時に行われる。なお性能の良いシステムセキュリティ検査ツールであれば、既知の脆弱性はもちろん、未知の脆弱性も発見できる。
システムセキュリティ検査では検査のためにシステムをスキャン(脆弱性スキャン)する必要があり、スキャンにはパッシブスキャンとアクティブスキャンがある。パッシブスキャンはミラーポートを使ったりWiresharkなどのアナライザを使ったりした受動的なパケットキャプチャ等で脆弱性を発見する手法である。それに対しアクティブスキャンはスキャナが機器にパケットを送信してその反応を見るなど能動的な方法で脆弱性を発見する手法である。
パッシブスキャンよりもアクティブスキャンのほうがより多くの脆弱性を発見できる可能性が高いが、その分システムに負荷をあたえたり、障害の原因になったりする可能性がある。
また脆弱性スキャンはネットワークの外部から行う外部スキャンとネットワークの内部から行う内部スキャンに分類できる。外部スキャンの場合、スキャンのための通信がネットワーク境界にあるファイヤーウォールに阻まれるため、内部スキャンほど多くの情報がとれない。しかし外部スキャンは攻撃者が外部から侵入可能な入口を発見できるなど、内部スキャンとは異なった役割を果たす事ができる。
システムセキュリティ検査は障害の原因になったり、検査対象が増えるにつれて検査費用が高くなるなどの事情があるため、ネットワーク全体に対して検査を行うとは限らず、一部の機器に限定して行われる事もある。
ウェブアプリケーション脆弱性診断脆弱性検査ツール#Webアプリケーション脆弱性検査ツールウェブアプリケーションセキュリティ検査はウェブアプリケーションに文字列を送信したり、ページ遷移を確認したり、ログ解析したりするなど、ウェブアプリケーションに特化した検査である。何らかのツールやサービスを用いて主に開発時のテスト工程と運用時に行われる。他の検査と同様、実装時に作り込んだ脆弱性は発見できるものの、設計段階で入り込んだ脆弱性を発見するのは難しい。
IPAによるとウェブアプリケーションセキュリティ検査ツールは3タイプに分けられる。第一のタイプのものは、ブラウザとウェブサイトの間のプロキシとして動作するもので、検査実施者がブラウザでウェブサイトにアクセスした際に発生するリクエストをプロセスである検査ツールが補足し、取得したリクエストの一部を検査実施者が手動で検査用のコードを埋め込む形で書き換え、書き換えたリクエストをウェブサイトに送信してその反応をみる事で脆弱性検査を行う。
第二のタイプは検査ツールがウェブクライアントとして動作し、検査用コードの入ったリクエストをウェブサイトに自動送信し、ウェブサイトからのレスポンスを元に検査実施者にレポートを出力する。第二のタイプのものはツールに予め用意されている量の検査用コードを試自動で試せるのが利点であるが、人力に頼る第一のタイプほど細かな検査はできない。
第三のタイプでは検査ツールは検査実施者が操作するブラウザとウェブサイトとの通信を(書き換えずに)補足し、補足した情報から不審な動作等を探して検査実施者にレポートとして出力する。第一、第二のタイプと違い検査用コードをウェブサイトに送りつける事がないので、詳細な検査はできないが、その分検査によりウェブサイトに障害が発生する可能性が格段に低いという利点がある。
ペネトレーションテストペネトレーションテストは実際の攻撃で使われる手口をそのまま利用する事で、人間が検査システムに攻撃をしかける事によりシステムの弱点を見つけ、システムが実際に攻撃されたときどこまで侵入され、どのような被害が発生するのか明らかにする検査であり、基本的に運用フェーズに行われる。ペネトレーションテストを実施するには攻撃手法に関する高度な知識を必要とするため、セキュリティ企業に依頼して実施する形が普通である。実際の攻撃手法を用いて検査を行うため、脆弱性のみならずシステムの不適切な運用等も発見できる。
その性質上、他の検査よりもシステムに不具合を生じさせる危険が大きいため、影響範囲を事前に特定し、復旧計画を立てて実施する必要がある。
テストは対象システムの構造をテストする人(ペンテスター)が知っているホワイトボックステストとシステム構造を知らないブラックボックステストにわけられ、さらに攻撃を開始する場所がシステム外部である外部テストとシステム内部である内部テストにわけられる。
レッドチームレッドチームはペネトレーションテストと同様、「レッドチーム」と呼ばれる攻撃チームが実際に攻撃をしかけてみる検査であり、レッドチームに対抗する防御側をブルーチームと呼ぶ。これらの言葉は元々軍事用語であり、敵軍であるレッドチームの視点で、自軍であるブルーチームの防御力や対応力を検証するものである。レッドチーム検査は「脅威ベースペネトレーションテスト(Threat-Led Penetration Testing : TLPT)」とも呼ばれる。
レッドチーム検査はペネトレーションテストよりもさらに実践的な検査である。ペネトレーションテストと違い、防御側であるブルーチームが攻撃の発生を認知しておらず、この状態でブルーチームがどこまで攻撃に耐えられるのかが試される。
レッドチーム検査ではハクティビスト、愉快犯、内部犯、金銭目的の犯罪者等、攻撃者の「ペルソナ」を作り、レッドチームのメンバーはそのペルソナになりきって攻撃を行う。典型的には攻撃前に初期調査を行い、マルウェアの配送、システム上への攻撃基盤構築、権限昇格、内部調査、目的達成といった手順をたどる。
レッドチームはサイバー攻撃だけではなく、物理セキュリティや人的要素に対しても攻撃をしかける。例えば初期調査では、ゴミ漁り、エレベーターでの盗み聞き、受付に「入館カードを忘れた」といって入り込むなどのソーシャル・エンジニアリング的な手法、偽Wifiポイントの立ち上げによる盗聴、SNSで情報発信を行っている社員からのOSINTなども行われる。
レッドチームのようなサービスをセキュリティベンダーが提供するようになったのは、標的型攻撃が一般化したことにある。標的型攻撃では上述のような物理要素・人的要素を犯す攻撃手法により情報収集されることもあり、こうした攻撃に耐えられるかを試すためにレッドチームのサービスが提供されるようになったのである。
ネットワークに接続された不正機器の検出を目的とするネットワークディスカバリや、不正な無線通信を検出するワイヤレススキャンなどがある。
脆弱性情報ハンドリングとは、新たに発見された脆弱性関連情報の届け出を発見者に促し、届けられた情報を整理して製品開発者の担当窓口に提供して対策方法の立案を促し、適切なタイミングで脆弱性関連情報と対策情報を周知することで、被害を最小化するための活動である。ここで脆弱性関連情報とは脆弱性情報、脆弱性が存在する事の検証方法、およびその脆弱性を利用した攻撃方法(例えばエクスプロイトコード)の事を指す。また脆弱性への対策方法は、修正方法(=パッチ適用)と回避方法に分類でき、回避方法とはパッチ以外の方法で脆弱性の影響度を回避・低減する方法、例えば脆弱性のある機能の無効化、代替ソフトへの移行、WAFの導入等がある。
攻撃者に脆弱性関連情報を悪用されるのを防ぐため、複数の製品が影響を受ける脆弱性の場合などにおいて、情報の公表に関して関係者間で一定の足並みをそろえる事(公開日一致の原則)が重要である。特に海外機関と調整が必要な際にこの原則を破って単独で情報公開を行うと、今後の脆弱性ハンドリングから外される場合がある。
国際標準として以下のものがある:
ISO/IEC 30111 – Vulnerability handling process (脆弱性取扱い手順)
ISO/IEC 29147 – Vulnerability disclosure (脆弱性開示)
日本において脆弱性ハンドリング方法の概略は経済産業省告示「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」に規定され、その詳細は「情報セキュリティ早期警戒パートナーシップガイドラライン」に規定されている。規定されている手順は、脆弱性が発見されたのがソフトウェア製品なのかウェブサイトなのかで異なる。
ソフトウェア製品の脆弱性関連情報の発見者はその情報をIPAの窓口に届け出し、IPAはその情報をJPCERT/CCに通知する。JPCERT/CCは製品開発者にその情報を連絡し、製品開発者は脆弱性の検証や対応方法を考える。JPCERT/CCは製品開発者と調整しながら脆弱性関連情報の公開スケジュールを決める。IPAとJPCERT/CCはスケジュールで定められた期日に脆弱性への策方法および対応状況を公表すする。IPAは原則四半期毎に統計情報を公表する。
ウェブサイトの脆弱性関連情報の発見者がその情報をIPAの窓口に届け出するところまでは上の手順と同様だが、ウェブサイトの場合、IPAはJPCERT/CCを介さずに直接ウェブサイト運営者に脆弱性関連情報を通知し、ウェブサイト運営者が脆弱性を修正する。ソフトウェアの場合と異なりIPAやJPCERTの側が脆弱性情報を公開する事は基本的にはない。個人情報漏洩等があった場合、その事実を公表するなどの処置はウェブサイト運営者が行う。
個人情報が漏洩している可能性があるにもかかわらず、ウェブサイト運営者が対応しない場合は、IPAが個人情報保護法34条に従った措置(主務大臣による勧告や命令)を依頼する。
IPAは原則四半期毎に統計情報を公表する。
脆弱性の情報源としては、各種ニュースサイト以外に、脆弱性情報データベース、ベンダアドバイザリ、注意喚起サイトがある。また攻撃情報の情報源としては、前述した脆弱性の情報源の他、攻撃コードデータベースがある。
脆弱性ハンドリング等によって集められた脆弱性関連情報を公開するデータベースの事。主なものとして下記のものがある。
ベンダや開発者のサイト、ブログ、アップデート情報、リリースノート等に自社製品の脆弱性情報やその対策情報が提供されている事があり、ベンダアドバイザリ、セキュリティアドバイザリ等と呼ばれている。ベンダアドバイザリは脆弱性情報の形で公開されない場合もあるので、注意が必要である。セキュリティ担当者は基本的には各製品のサイト等を参考にしてベンダアドバイザリ手に入れる必要があるが、各種脆弱性情報データベースに載らないベンダアドバイザリを収集している有償サービスも存在するので、こうしたサービスから情報を得る事も可能である。
広く使われている製品に対して、脆弱性の周知と対策の呼び掛けを行っているサイト。国内ではJPCERT/CC、警察庁、IPA等が注意喚起を行っており、海外ではUS-CERTやICS-CERT(制御システムが対象)等がある。
攻撃コード(エクスプロイト)を収集したデータベースで、Exploit DBなどがある。
SCAP(エスキャップと発音)は、アメリカ国立標準技術研究所(NIST)が策定した「脆弱性管理、コンプライアンス管理の一部を機械化(自動化)することにより、情報システムに対するセキュリティ対策の負荷軽減と情報セキュリティ施策の推進の両立を目的とした仕様群」である。 2015年現在、SCAPには以下の6つの仕様が規定されている:
脆弱性管理とは「自社の脆弱性の状況を常に掌握して、より頻繁かつ効果的に修正するためのプロセス」の事である。脆弱性管理で行うプロセスはツールやサービスによって異なるものの、IT資産の目録作成、守るべきIT資産の優先度付け、IT資産の脆弱性の発見、脆弱性のリスクレベルの特定と対策優先度の決定、脆弱性への対処ないしその支援、対処状況の一覧化といったプロセスを含む。
ファイヤーウォールはネットワーク境界に設置して不正な通信を遮断する技術である。通信を許可・遮断するIPアドレスやポート番号をしていするタイプのファイヤーウォールをパケットフィルタリング型のファイヤーウォールという。パケットフィルタリング型のうち、管理者により予め決められたテーブルにしたがって通信の許可と遮断を行うものをスタティック型という。それに対しダイナミック型のパケットフィルタリングでは、ネットワーク境界内はネットワーク境界外より安全だという前提の元、境界内から境界外への通信が発生したときは、その返答が境界外から帰ってきた場合のみ例外的に通信を許可する。ステートフルパケットインスペクションはダイナミック型の特殊なもので、TCP/UDPセッションを認識して、正当な手順のセッションに属する場合のみ通信を許可する。
パケットフィルタリング型が通信の許可・遮断機能のみを持つのに対し、それ以外のファイヤーウォールは通信の中継機能を持つ。サーキットレベルゲートウェイ型ファイヤーウォールは、ファイヤーウォールを通過する際IPアドレスを付け替え、ネットワーク境界内のIPアドレスが境界外にもれないようにする。アプリケーションゲートウェイ型ファイヤーウォールはHTTPなどアプリケーション層のプロトコルを理解してプロキシとして振る舞う。コンテンツをキャッシュして通信速度を早くする他、有害なサイトのフィルタリングを行ったり、マルウェア対策ソフトを組み込んでファイヤーウォールをまたぐ通信に含まれるマルウェアを検知したりできる。
IDS(Intrusion Detection System、侵入検知システム)は不正侵入の兆候を検知し、管理者に通知するシステムである。IPS(Intrusion Prevention System、侵入防止システム)も不正侵入の兆候を検知するところまではIDSと同様だが、検知した不正を自動的に遮断するところに違いがある。両者を合わせてIDPSという場合もある。センサーないしエージェントと呼ばれるアプライアンスないしソフトウェアを利用して通信などの情報を集める事により不正を検知する。センサーやエージェントの集めた情報は管理サーバに送られ、管理サーバ側でも複数のセンサー・エージェントの情報を相関分析する事で不正を検知する。
IDPSは以下の4種類に分類できる:
ネットワークベースのIDPSとNBAはどちらもネットワークを監視する点では共通しているが、前者は主に組織LANと外部ネットワークの境界などネットワーク境界に設置され、境界をまたぐ通信を監視するのに対し、NBAは組織LAN内に設置され、LAN内の通信を監視する点に違いがある。
ネットワークベースIDS、IPSを略してそれぞれNIDS、NIPSと呼ぶ。同様にホストベースIDS、IPSをそれぞれ略してHIDS、HIPSという。
ネットワークベースのIDPSのセンサー設置方法としては、監視対象の通信が必ず通る場所にIDPSを設置するインライン型と、監視対象の通信が必ず通る場所にスパニングポート、ネットワークタップ、IDSロードバランサ等を設置する事で監視対象の通信をコピーし、コピーした通信をIDPSで監視する受動型がある。攻撃の遮断や回避のようなIPSとしての機能を利用する場合はインライン型が必須である。