PCIのセキュリティログ構成（rsyslogおよびsyslog-ng）の検証DSS 10.5
私は年1回のオンサイトQSA監査でレベル1の商人のために働いているので、これは巨大取引です。
PCI DSS 10.5では、テスト対象のエンティティが「監査証跡を変更できないように保護する」ことが必要です。UnixおよびLinux環境では、syslog構成をチェックして、次のことを確認する必要があります。監査ログを保存するためにローカルで使用されるすべてのファイル（syslogでauth、authpriv、およびセキュリティ機能として定義されています）はrootに制限されており、b）これらの機能は安全のためにログコレクターにもエクスポートされます。
以前は、クラシックsyslogを使用して、syslog.confファイルのテストでこれを管理し、権限を確認するファイルと使用中のコレクターサーバーを特定していました。問題は、syslogの新しいバージョン、つまりrsyslogとsyslog-ngにあります。
これらのログコンポーネントの構成ファイルは、以前のバージョンよりもはるかに柔軟で、人間が読める形式になっています。ただし、次の理由により、新しいツールの構成を検証しようとするのは静かです。
Rsyslog（およびsyslog-ng）では、正規表現を含め、考えられるほぼすべてのものにメッセージをルーティングできます。これらの基準でルーティングできるだけでなく、それらに基づいて特定のメッセージを完全に破棄することもできます。たとえば、システムをlookに設定するのは簡単で、単にログを調べているだけであれば、すべてのセキュリティ情報をログに記録します。ただし、その間、特定のユーザーIDを含むログメッセージは何も表示されずに破棄されます。設定が簡単で、検出が難しい。
Syslog-ngを使用して、チェックサムで「既知の正常な」構成の検証を試みました（これは、SHA-256などの適切なHMACでより安全にすることができますが、根本的な問題は解決されません）。問題は、有効な構成が急増する傾向にあり、追いつくことが不可能になることです。
どちらのツールもインクルードファイルを使用できます。特にrsyslogはこの機能を「そのまま」広く使用します。これにより、元のファイルだけでなく、インクルードするすべてのファイルをチェックサム/ハッシュする必要があるため、問題がさらに複雑になります。
1つのストップは、rsyslogまたはsyslog-ngを実行しているすべてのシステムにフラグを立て、ログが適切な場所に送信されていることを証明するためにSAを要求することですが、数万のシステムでは、このアプローチは規模を拡大することも、監査人に良い証拠を提供することもありません。
要するに、すべての認証ログがどこに保存または送信されているかを確実に知るという問題に対する技術的な解決策は見つかりませんでしたが、PCI DSS 10.5はそれを必要とします。したがって、セキュリティコミュニティに質問しています。これを促進するために彼らがしていること.
問題を過度に分析しているようです-PCI DSSでは、システムの悪用が不可能であることを確認する必要はありません。基本的な悪用ベクトルに沿って十分な注意を払う必要があります。
ここの引用は DSS 3.1 「テスト手順」からです：
10.5.1監査証跡ファイルを表示できるのは、職務に関連する必要がある個人のみです。
Auth *タイプのログがrootのみが読み取り可能であることを確認してください。それは非常に簡単です：
$ grep authpriv /etc/rsyslog.conf
# The authpriv file has restricted access.
authpriv.* /var/log/secure
$ ls -l /var/log/secure
-rw------- 1 root root 1085793 Nov 10 13:43 /var/log/secure
$
これで完了です。悪意のある管理者がどこかでauthprivをログに記録して、どこにあるかを確認し、それを誰でも読み取り可能にすることが不明瞭になる可能性はありますか？それは可能ですですが、QSAが探しているものではなく、誤ってログを誤って設定していないことを確認して、誰もがauthprivを読み取れるようにしています。
（編集）コメントで説明する状況：
チェックサムの問題は、アプリケーションが（セキュリティログに影響を与えない場所で）構成を変更する有効な必要性があり、チェックサムを破っていたことです。
実際には、rsyslogで対処する方が簡単です。
- システムログは/etc/rsyslog.confで指定され、cfengineによって標準化され、システム全体で自動管理されます。
- rsyslog.confには/etc/rsyslog.d/*.confが含まれます
- アプリケーションログの設定は/etc/rsyslog.d/application.confにあります
このようにして、ロギング（たとえば）authprivのシステム構成が正しいこと、および構成がシステム間で共通であることを簡単に証明できます。アプリケーションごとのカスタマイズは、/ etc/rsyslog.d/*。confファイルに分離されています。これは、QSAにチェックサムまたは証明する必要はありません。 1つまたは2つですが、一般に、管理者はアプリケーションレベルの構成ファイルで冗長な不正なシステムレベルの構成を隠さないようにします。
繰り返しますが、PCI DSSは、あなたが基本的なことを正しく行っていることを文書化することを望んでいます。疑いの影を越えて、あなたが何か悪いことをしてください。
10.5.2現在の監査証跡ファイルは、アクセス制御メカニズム、物理的な分離、および/またはネットワークの分離を介した不正な変更から保護されています。
ログファイルが不適切なグループや「その他」に書き込み可能でないことを示します。
# find /var/log -type f -a \( -perm -g+w -or -perm -o+w \) -ls
131282 2220 -rw-rw-r-- 1 root utmp 2265216 Oct 30 09:51 /var/log/wtmp-20151101
133888 192 -rw-rw-r-- 1 root utmp 192000 Nov 9 16:12 /var/log/wtmp
#
wtmpは、ルート以外の端末による更新を許可するためにutmpにグループ書き込み可能であるため、これは正常です。他の調査結果はありません。ログが/ var/logに移動することを示す基本的なチェックに加えて、すべての準備が整いました。
10.5.3現在の監査証跡ファイルは、一元化されたログサーバーまたは変更が困難なメディアに迅速にバックアップされます。
10.5.4外部向けテクノロジ（ワイヤレス、ファイアウォール、DNS、メールなど）のログは、安全な集中型の内部ログサーバーまたはメディアに書き込まれます。
最初に、ログが中央のSIEMに送信されることを示す構成を表示します。次に、マシンからのログがSIEMで見つかることを証明するクエリを表示します。 QSAが要求するサンプルサイズに対して繰り返します。
ローカルで検出されたすべての行がリモートサーバー上で検出されるという完全な調整を行う必要はありません。リモートサーバーにログを記録するように構成したこと、およびリモートサーバーが適切に機能していることを証明する必要があるだけです。
10.5.5システム設定、監視対象ファイル、および監視アクティビティの結果を調べて、ログでのファイル整合性監視または変更検出ソフトウェアの使用を確認します。
/ etc/rsyslog *および/ var/log/*がFIM（Tripwireなど）によって監視されていることを確認します。それでおしまい。
これらの手順は、環境を保護するのに十分ですか？番号！ PCI DSSは床であり、天井ではありません。これは、開始し、すべての人が少なくともシートベルトを締めていることを確認して試すための、基本的なデューデリジェンスのチェックリストです。あなたのセキュリティを改善する方法を探していますが、あなたはそこに行く途中でPCI監査に合格するでしょう。
さて、言われているように、私はあなたの質問で別の問題を検出しています。これにより監査が難しくなります。「ここに設定ファイルがあり、ここにサーバーの95％が使用していることを示すPuppet設定があります」と言うと、QSAが環境のサンプルにサインオフしやすくなります。 「有効な構成が急増する傾向がある」場合、PCIコンプライアンスに影響を与えるだけでなく、全体的なセキュリティにも影響を与える問題があります。集中管理を検討する必要があります（ここでは このようなツールの4つの比較 ）。
非常に賢く創造的な人々は、システムを破壊してそれらを説明する可能性のあるすべての不測の事態を考える傾向があります。これは、優れた信頼性の高いシステムを作成するための良い本能です。しかし、それが今あなたがここでやっていることです。 PCI監査に合格することと、壊れないセキュリティシステム、または本当に優れたセキュリティシステムを作成することを混同しないでください。 2つは非常に異なります。 gowenfawrが言及しているように、本当に必要なことはデューデリジェンスを維持することだけであり、システムにアクセスできるユーザーがログファイルを変更できるようにするなど、本当に愚かなことをしないでください。
変更できないと説明しているように、完璧なシステムを作成することはできません。少なくとも、熟練した攻撃者は、syslogを特定のレコードを除外する独自のバージョンに置き換えるだけで済みます。システムへの低レベルのアクセスでは、トラックをカバーするための無数の方法があります。これを検出する方法はありますが、常に回避策があります。あなたが御言葉を変えられないように考えているように「変えられない」ものはありません。