1つのファイルが、1つの攻撃になりうる。

検査結果が陽性であるか陰性であるかだけでは、アプリケーション側のすべての疑問には答えられません。業務上どのファイル形式が必要か、どのアクティブコンテンツを許可するか、未知の結果にはどう対応するかを、実際の業務プロセスに即して私たちと一緒に定義します。その際、マルチスキャニングとコンテンツの無害化と再構築（CDR）を補完的な手法として活用します。業務上必要なファイルであっても、検査を経ないまま単純に受け渡すことはありません。その処理状態によって、次のステップへ到達できるかどうか、またどのような形で到達するかが決まります。

無害化はコンテンツを変化させる可能性があるため、代表的な文書を用いてテストする必要があります。マクロなどのアクティブな要素は、保護ポリシー上は削除すべきものであっても、業務プロセスにとって重要な場合があります。こうした矛盾には、意識的な判断が求められます。暗号化されたアーカイブについては、正当に提供されたパスワードによってまずコンテンツにアクセスできる状態にする必要があります。スキャナーは未知の暗号化を単純に回避することはできません。そのため、検査できないファイル、フォーマットエラー、上限値の超過については、明確な例外・隔離手順をあらかじめ取り決めます。

適した提供形態は、ファイル量、サイズ、フォーマットの組み合わせ、許容できる待ち時間によって異なります。予測可能な量を扱う一元的な検査拠点と、SaaSアプリケーションで大きく変動するアップロードとでは、求められる要件が異なります。想定するスループットと必要なモジュールを共に検討し、代表的なデータセットでテストを行います。そこから容量、キュー、障害時の挙動を導き出します。利用可能なクラウドイメージやコンテナは1つの提供方法にすぎず、それだけで完全に構築・運用されたサービスになるわけではありません。

オンプレミスや隔離された環境では、これに加えて更新、ライセンス、許可された情報のやり取りも考慮する必要があります。エンジンの更新や外部のレピュテーション・インテリジェンス照会は、運用コンセプトに適合していなければなりません。また、ファイルスキャンシステム単体では、セキュリティドメイン間の承認された接続を実現するものではありません。管理された転送やエアギャップ方式が必要な場合、検査はそのために設けられた全体プロセスの中に組み込まれます。許可されるアーキテクチャとその承認は、別途のプロジェクト判断として扱います。

アプリケーションには明確な回答が必要である一方、SOCには調査のための詳細な情報が求められます。そのため、業務上の承認ステータスと、より深い分析情報とを分けて扱います。検査結果は想定するファイル処理と結びつけ、ログは合意した宛先に届けます。レポートやメタデータ自体が機微な情報を含み得るため、保持期間とアクセス権限は慎重に決める必要があります。手動確認については、責任の所在と、後続の承認を行うための条件を文書化します。

本番導入の前に、許可されたファイル、想定されるブロック、技術的なエラーケースをテストします。これにはタイムアウトや不完全な解析も、通常の結果と同様に含まれます。メーカーが示す数値は、特定の製品範囲やテストを説明するものであり、あらゆる脅威の検知を保証するものではありません。貴社の案件にとって重要なのは、実際にライセンスされたモジュール、貴社のポリシー、そして検証済みの運用手順です。引き渡しの際には、この前提を明確に文書化し、新しいファイル形式や要件の変更をどのように取り込むかを記録します。