この記事について
Wazuhでどんなことができるのかと自分の手で確かめてみたかったので、公式マニュアルを見ながら何ができるのかをいじった記録として残す。
公式マニュアルが充実してるのでWazuh自体は割と簡単にいじることができるが、背景としてLinuxやセキュリティやらの知識がある程度必要。
Wazuhとは何か？
OSSのセキュリティ監査基盤、という位置づけらしい。ossecにElasticSearchとKibanaをかぶせたもの、と言ってもいいかもしれない。（ossecは廃れたと思ったらこんな形で復活していたとは）
アーキテクチャやらなんやらは公式マニュアルに書いてある。
https://documentation.wazuh.com/current/getting-started/architecture.html
Wazuhセットアップ
2021年3月時点での記録。
Wazuh Serverのインストール
All-in-one構成で構築。
VirtualBoxでVMたててCentOS7.9をいれてWazuh Serverをインストールする。
VMは下記スペック。
| OS | CentOS7.9 |
| CPUコア | 1 |
| メモリ | 4G |
| ディスク | 20G |
| NW | NATとホストオンリーアダプタ |
CPUやメモリがカツカツだがこれでも動く。
VMたててOS入れたら、下記手順に従って淡々と手を動かせばインストールできる。
https://documentation.wazuh.com/current/installation-guide/open-distro/all-in-one-deployment/all_in_one.html
Wazuhのバージョンは4.1.1でインストールされた。
多分現時点の安定板の最新なんだろう。
一気にインストールするスクリプトもあるみたいだが、step-by-stepでインストールしたほうが、何を入れてるのか自分で納得しながらできるので良い。
入れるもの入れたらhttps://＜WazuhサーバのIP＞/でアクセスし、Kibanaログイン画面でadmin/adminと入れればダッシュボードが見れるようになる。
上記画像でTotal agentsやActive agentsが1になってるのは下記手順でAgent入れたから・・・
Wazuh Agentのインストール
Wazuh Severには自分自身監視用のAgentが入っているが、せっかくなので他のVMにAgentを入れて監視できるかを見る。
Serverと同様に監視対象となるVMを適当にたてる。OSはUbuntu20にした。
| OS | Ubuntu20 |
| CPUコア | 1 |
| メモリ | 1G |
| ディスク | 10G |
| NW | NATとホストオンリーアダプタ |
この環境に対してWazuh agentをインストールする。
WAZUHアイコンの横の矢印クリックしてメニューを開き「Agents」を選択してAgent管理画面に移動。
Agent管理画面で「Deploy new Agent」をクリックするとOSやらなんやら指定する画面が出てくるので適当に選択する。Wazuh server addressのところはさっき立てたWazuh Serverのアドレスをいれる。グループはdefaultが最初からあるので、それを選択。「Install and enroll the agent」のところでインストールに必要なコマンドが出てくるので、それをコピって監視対象のVMにagentインストール。
インストールしたらwazuh-agentサービス起動する。
AgentがServerにうまく接続するようになったら一覧で下記のように確認できる。
監視対象であるUbuntuノード側で適当にsshを失敗してみたり、何かパッケージを入れてみたりするとManager側にいろいろとイベントが飛んでダッシュボードの画面に表示される。（ModulesのSecurity Evnet画面とか）
カスタマイズ
Wazuhの機能一覧は下記にある通り。
https://documentation.wazuh.com/current/user-manual/capabilities/index.html
大雑把に言えば、ルール設定に基づいたログ集めと可視化、アラート通知といったところか。あとOpenSCAPを使った構成監査がある。
とにかく機能が豊富すぎるので、これを全部使いこなすのは非常に大変。
自分が欲しいもの以外は適当に切り捨てながらカスタマイズしていかないと素では使えない。
主にいじるのは/var/ossecの中となる。
[root@wazuh-manager ossec]# pwd
/var/ossec
[root@wazuh-manager ossec]# ls
active-response agentless api backup bin etc framework integrations lib logs queue ruleset stats tmp var wodles
[root@wazuh-manager ossec]#
閾値設定
雑魚イベントを集めて表示していてもうるさいだけなのでレベルを調整する。
https://documentation.wazuh.com/current/user-manual/manager/alert-threshold.html
/var/ossec/etc/ossec.confの下記のあたりの数字をいじる。
<alerts>
<log_alert_level>7</log_alert_level>
</alerts>
設定が終わったらsystemctl restart wazuh-managerで再起動。
Slackに通知
メールはだるいので一定の閾値超えたアラートをSlackに飛ばしたい。
ということでSlack通知設定。Slack側でIncoming Webhookを作り、Wazuh側でIntegration設定する。
下記のような感じの内容でossec.confに追記する。
<integration>
<name>slack</name>
<hook_url>https://hooks.slack.com/services/XXXX/XXXX/XXXXX</hook_url>
<alert_format>json</alert_format>
<level>10</level>
</integration>
うまく設定できていれば、Slackに通知が飛ぶはず。
ほかにもPagerDutyやらViruaTotalやらと連携できるらしい。
https://documentation.wazuh.com/current/user-manual/manager/manual-integration.html
ルール設定
まずはossecのルールを最新に更新。
[root@wazuh-manager ~]# /var/ossec/bin/update_ruleset
更新したルールは下記の場所に格納されている。
[root@wazuh-manager ruleset]# pwd
/var/ossec/ruleset
[root@wazuh-manager ruleset]# ls
decoders rules sca VERSION
[root@wazuh-manager ruleset]# cd rules
[root@wazuh-manager rules]# ls
0010-rules_config.xml 0230-ms-se_rules.xml 0470-vshell_rules.xml
0015-ossec_rules.xml 0235-vmware_rules.xml 0475-suricata_rules.xml
0016-wazuh_rules.xml 0240-ids_rules.xml 0480-qualysguard_rules.xml
0020-syslog_rules.xml 0245-web_rules.xml 0485-cylance_rules.xml
0025-sendmail_rules.xml 0250-apache_rules.xml 0490-virustotal_rules.xml
0030-postfix_rules.xml 0255-zeus_rules.xml 0495-proxmox-ve_rules.xml
0035-spamd_rules.xml 0260-nginx_rules.xml 0500-owncloud_rules.xml
0040-imapd_rules.xml 0265-php_rules.xml 0505-vuls_rules.xml
0045-mailscanner_rules.xml 0270-web_appsec_rules.xml 0510-ciscat_rules.xml
0050-ms-exchange_rules.xml 0275-squid_rules.xml 0515-exim_rules.xml
0055-courier_rules.xml 0280-attack_rules.xml 0520-vulnerability-detector_rules.xml
0060-firewall_rules.xml 0285-systemd_rules.xml 0525-openvas_rules.xml
0065-pix_rules.xml 0290-firewalld_rules.xml 0530-mysql_audit_rules.xml
0070-netscreenfw_rules.xml 0295-mysql_rules.xml 0535-mariadb_rules.xml
0075-cisco-ios_rules.xml 0300-postgresql_rules.xml 0540-pfsense_rules.xml
0080-sonicwall_rules.xml 0305-dropbear_rules.xml 0545-osquery_rules.xml
0085-pam_rules.xml 0310-openbsd_rules.xml 0550-kaspersky_rules.xml
0090-telnetd_rules.xml 0315-apparmor_rules.xml 0555-azure_rules.xml
0095-sshd_rules.xml 0320-clam_av_rules.xml 0560-docker_integration_rules.xml
0100-solaris_bsm_rules.xml 0325-opensmtpd_rules.xml 0565-ms_ipsec_rules.xml
0105-asterisk_rules.xml 0330-sysmon_rules.xml 0570-sca_rules.xml
0110-ms_dhcp_rules.xml 0335-unbound_rules.xml 0575-win-base_rules.xml
0115-arpwatch_rules.xml 0340-puppet_rules.xml 0580-win-security_rules.xml
0120-symantec-av_rules.xml 0345-netscaler_rules.xml 0585-win-application_rules.xml
0125-symantec-ws_rules.xml 0350-amazon_rules.xml 0590-win-system_rules.xml
0130-trend-osce_rules.xml 0360-serv-u_rules.xml 0595-win-sysmon_rules.xml
0135-hordeimp_rules.xml 0365-auditd_rules.xml 0600-win-wdefender_rules.xml
0140-roundcube_rules.xml 0375-usb_rules.xml 0601-win-vipre_rules.xml
0145-wordpress_rules.xml 0380-redis_rules.xml 0602-win-wfirewall_rules.xml
0150-cimserver_rules.xml 0385-oscap_rules.xml 0605-win-mcafee_rules.xml
0155-dovecot_rules.xml 0390-fortigate_rules.xml 0610-win-ms_logs_rules.xml
0160-vmpop3d_rules.xml 0395-hp_rules.xml 0615-win-ms-se_rules.xml
0165-vpopmail_rules.xml 0400-openvpn_rules.xml 0620-win-generic_rules.xml
0170-ftpd_rules.xml 0405-rsa-auth-manager_rules.xml 0625-cisco-asa_rules.xml
0175-proftpd_rules.xml 0410-imperva_rules.xml 0625-mcafee_epo_rules.xml
0180-pure-ftpd_rules.xml 0415-sophos_rules.xml 0630-nextcloud_rules.xml
0185-vsftpd_rules.xml 0420-freeipa_rules.xml 0635-owlh-zeek_rules.xml
0190-ms_ftpd_rules.xml 0425-cisco-estreamer_rules.xml 0640-junos_rules.xml
0195-named_rules.xml 0430-ms_wdefender_rules.xml 0675-panda-paps_rules.xml
0200-smbd_rules.xml 0435-ms_logs_rules.xml 0680-checkpoint-smart1_rules.xml
0205-racoon_rules.xml 0440-ms_sqlserver_rules.xml 0685-macos-sshd_rules.xml
0210-vpn_concentrator_rules.xml 0445-identity_guard_rules.xml 0690-gcp_rules.xml
0215-policy_rules.xml 0450-mongodb_rules.xml 0700-paloalto_rules.xml
0220-msauth_rules.xml 0455-docker_rules.xml
0225-mcafee_av_rules.xml 0460-jenkins_rules.xml
[root@wazuh-manager rules]#
ここの内容は更新されてしまうものであるため、ルールをカスタマイズする場合は以下のlocal_rules.xmlファイルをいじることになる。
[root@wazuh-manager rules]# pwd
/var/ossec/etc/rules
[root@wazuh-manager rules]# ls
local_rules.xml
[root@wazuh-manager rules]#
下記のマニュアルに従いルールをカスタマイズ。
https://documentation.wazuh.com/current/user-manual/ruleset/custom.html
基本は既存ルールをコピってルールを上書きするような使い方となる。
例えば、SCAの19007のルールがうるさい！レベル下げてやる！と思った場合は下記のような手順をとる。
まず、対象のルールが書かれたxmlファイルを特定し、内容を見る。
/var/ossec/ruleset/rules/0570-sca_rules.xml
<rule id="19007" level="7">
<if_sid>19006</if_sid>
<field name="sca.check.result">^failed</field>
<options>no_full_log</options>
<description>$(sca.policy): $(sca.check.title)</description>
</rule>
この内容をコピって下記のような内容をlocal_rules.xmlに追記する。
<group name="sca,gdpr_IV_35.7.d,pci_dss_2.2,nist_800_53_CM.1,tsc_CC7.1,tsc_CC7.2,">
<rule id="19007" level="5" overwrite="yes">
<if_sid>19006</if_sid>
<field name="sca.check.result">^failed</field>
<options>no_full_log</options>
<description>$(sca.policy): $(sca.check.title)</description>
</rule>
</group>
変更点はlevelを5にしたところとoverwrite="yes"にしたところ。
特にoverwrite="yes"が大事。これがないとエラーになる。
具体的に何が検知できるのか
下記の内容をつまみ食いする。
https://documentation.wazuh.com/current/learning-wazuh/index.html
SSH Bruteforce Attackの検知
下記の内容に従って試してみる。
https://documentation.wazuh.com/current/learning-wazuh/ssh-brute-force.html
攻撃の準備
Bruteforce Attackの道具としてhydraを使う。まずはインストール。
[root@wazuh-manager ~]# yum install https://forensics.cert.org/cert-forensics-tools-release-el7.rpm
[root@wazuh-manager ~]# yum install hydra crunch -y
crunchで適当にパスワードリストを作る。
[root@wazuh-manager ~]# crunch 2 2 -o password.txt
Wazuhのアラートログで何が出るか見るためにtail -fをしておく。
[root@wazuh-manager ~]# tail -f /var/ossec/logs/alerts/alerts.log
攻撃開始
さあ攻撃だ！
下記のような内容を実行すれば、パスワードリストを使ってsshしまくる。
[root@wazuh-manager ~]# hydra -l logintest -P password.txt 192.168.56.101 ssh
しばらくするとドバドバとアラートが出てくるのが見れるはず。
ダッシュボードでは下記のように表示される。
syslog: User missed the password more than one timeというLevel 7のメッセージが大半だがsshd: brute force trying to get access to the systemというLevel 10のメッセージも入っているはず。
SearchのところでNOT rule.level: 7といれてやればフィルタ出来るので探しやすい。
Slackにも通知が飛んでいる。
メールなり、Slackなりで通知を受け取った人がWazuhのダッシュボード見てさらに調べる、といった運用が可能だと思う。
Active Responseの設定
SSH Bruteforceのような凶悪なものは検知したら即防ぎたいもの。
ZabbixのトリガーのようにWazuhもアラートに応じたアクションが行えて、Active Responseという。
概要は下記のあたりに記載されている。
https://documentation.wazuh.com/current/user-manual/capabilities/active-response/how-it-works.html
Active Responseとして実行されるスクリプト類は/var/ossec/active-response/binに置くことになっている。
[root@wazuh-manager bin]# pwd
/var/ossec/active-response/bin
[root@wazuh-manager bin]# ls
default-firewall-drop.sh firewall-drop.sh ipfw_mac.sh kaspersky.sh ossec-tweeter.sh restart.sh
disable-account.sh host-deny.sh ipfw.sh npf.sh pf.sh route-null.sh
firewalld-drop.sh ip-customblock.sh kaspersky.py ossec-slack.sh restart-ossec.sh
Active Responseとして実行されるコマンド定義等はossec.confの中でずらずらと設定されているcommandタグの部分で、以下のような感じで設定されている。
<command>
<name>host-deny</name>
<executable>host-deny.sh</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
Active Responceが仕事するか確認する。
今回のBruteforceで検知される5712のルールに対して反応するように、サーバ側のossec.confでactive-responseタグを以下のように追記する。
<!-- Active Response -->
<active-response>
<command>host-deny</command>
<location>local</location>
<rules_id>5712</rules_id>
<timeout>60</timeout>
</active-response>
設定が終わったらwazuh-managerを再起動。
hydraで攻撃してしばらくすると、Active Responseが動いて/etc/hosts.denyに攻撃元IPが追記される。
Wazuh Agent側で下記のようなログがでる。
root@mypc:~# tail /var/ossec/logs/active-responses.log
2021年 3月 8日 月曜日 20:31:16 JST /var/ossec/active-response/bin/host-deny.sh add - 192.168.56.102 1615203076.5570 5712
2021年 3月 8日 月曜日 20:32:17 JST /var/ossec/active-response/bin/host-deny.sh delete - 192.168.56.102 1615203076.5570 5712
timeoutを60にしていたので60秒たったら/etc/hosts.denyから対象のIPが自動削除される。
特定コマンド実行の検知
auditdを使ったコマンド実行検知をためす。
https://documentation.wazuh.com/current/learning-wazuh/audit-commands.html
サーバ側設定
まず、local_rules.xmlに設定を追加してwazuh-manager再起動。
<group name="audit">
<rule id="100200" level="12">
<if_sid>80792</if_sid>
<list field="audit.command" lookup="match_key">etc/lists/suspicious-programs</list>
<description>Audit: Suspicious Command: $(audit.exe)</description>
<group>audit_command,</group>
</rule>
</group>
/var/ossec/etc/lists/audit-keysの内容を下記のように編集。
audit-wazuh-w:write
audit-wazuh-r:read
audit-wazuh-a:attribute
audit-wazuh-x:execute
audit-wazuh-c:command
監視対象となるコマンドを設定
ncat:
nc:
tcpdump:
ping:
上記に設定したコマンドが実行されると発生するアラートをlocal_rules.xmlに設定。
<group name="audit">
<rule id="100200" level="10">
<if_sid>80792</if_sid>
<list field="audit.command" lookup="match_key">etc/lists/suspicious-programs</list>
<description>Audit: Suspicious Command: $(audit.exe)</description>
<group>audit_command,</group>
</rule>
</group>
Slackに飛ばす設定をlevel 10にしてたからこのアラートもLevel 10にしてみた。
上記設定が完了したらwazuh-managerを再起動。
監視対象側設定
監視対象側のauditdのルール設定をいじる。
-a exit,always -F egid!=994 -F auid!=-1 -F arch=b64 -S execve -k audit-wazuh-c
ルール反映。
root@mypc:~# auditctl -R /etc/audit/rules.d/audit.rules
エラーが出なければOK
root@mypc:~# auditctl -l
-a always,exit -F arch=b64 -S execve -F egid!=994 -F auid!=-1 -F key=audit-wazuh-c
実験
監視対象側でpingを実行してみる。
root@mypc:~# ping 8.8.8.8
すると、サーバ側のalerts.logに下記のようなログがでる。
** Alert 1615106851.59733: - auditaudit_command,
2021 Mar 07 03:47:31 (mypc) any->/var/log/audit/audit.log
Rule: 100200 (level 10) -> 'Audit: Suspicious Command: /usr/bin/ping'
type=SYSCALL msg=audit(1615106850.098:85): arch=c000003e syscall=59 success=yes exit=0 a0=55706846a980 a1=5570685a89e0 a2=557068561540 a3=8 items=2 ppid=6938 pid=7125 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=16 comm="ping" exe="/usr/bin/ping" subj=unconfined key="audit-wazuh-c" type=EXECVE msg=audit(1615106850.098:85): argc=2 a0="ping" a1="8.8.8.8" type=CWD msg=audit(1615106850.098:85): cwd="/root" type=PATH msg=audit(1615106850.098:85): item=0 name="/usr/bin/ping" inode=393365 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000002000 cap_fi=0 cap_fe=1 cap_fver=2 cap_frootid=0 type=PATH msg=audit(1615106850.098:85): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=394609 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1615106850.098:85): proctitle=70696E6700382E382E382E38
audit.type: SYSCALL
audit.id: 85
audit.arch: c000003e
audit.syscall: 59
audit.success: yes
audit.exit: 0
audit.ppid: 6938
audit.pid: 7125
audit.auid: 0
audit.uid: 0
audit.gid: 0
audit.euid: 0
audit.suid: 0
audit.fsuid: 0
audit.egid: 0
audit.sgid: 0
audit.fsgid: 0
audit.tty: pts0
audit.session: 16
audit.command: ping
audit.exe: /usr/bin/ping
audit.key: audit-wazuh-c
audit.execve.a0: ping
audit.execve.a1: 8.8.8.8
audit.cwd: /root
audit.file.name: /usr/bin/ping
audit.file.inode: 393365
audit.file.mode: 0100755
Slackにも通知がいってる。
もちろんダッシュボードでもこのイベントは確認できる。
ファイル変更の検知
下記を参考にファイル変更を検知する設定を入れる。
https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/fim-configuration.html
ファイル監視は一定周期でのスキャンとリアルタイム検知がある。
たとえば、/root直下をリアルタイム検知しようとした場合はossec.confのsyscheckの中で下記のように書く。
<!-- File integrity monitoring -->
<syscheck>
<directories check_all="yes" realtime="yes" report_changes="yes">/root</directories>
この設定を監視対象側で行い、wazuh-agentの再起動を行う。
監視できているか適当なファイルを作って確認する。
root@mypc:~# echo "test1" > test
root@mypc:~# echo "test2" > test
root@mypc:~# rm test
サーバ側のalerts.logで下記のようなログが出てくる
** Alert 1615114239.186321: - ossec,syscheck,syscheck_entry_modified,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2021 Mar 07 05:50:39 (mypc) any->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
File '/root/test' modified
Mode: realtime
Changed attributes: mtime,md5,sha1,sha256
Old modification time was: '1615114235', now it is '1615114239'
Old md5sum was: '3e7705498e8be60520841409ebc69bc1'
New md5sum is : '126a8a51b9d1bbd07fddc65819a542c3'
Old sha1sum was: 'dba7673010f19a94af4345453005933fd511bea9'
New sha1sum is : '9054fbe0b622c638224d50d20824d2ff6782e308'
Old sha256sum was: '634b027b1b69e1242d40d53e312b3b4ac7710f55be81f289b549446ef6778bee'
New sha256sum is : '7d6fd7774f0d87624da6dcf16d0d3d104c3191e771fbe2f39c86aed4b2bf1a0f'
Attributes:
- Size: 6
- Permissions: rw-r--r--
- Date: Sun Mar 7 05:50:39 2021
- Inode: 131348
- User: root (0)
- Group: root (0)
- MD5: 126a8a51b9d1bbd07fddc65819a542c3
- SHA1: 9054fbe0b622c638224d50d20824d2ff6782e308
- SHA256: 7d6fd7774f0d87624da6dcf16d0d3d104c3191e771fbe2f39c86aed4b2bf1a0f
What changed:
1c1
< test1
---
> test2
** Alert 1615114245.187539: - ossec,syscheck,syscheck_entry_deleted,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2021 Mar 07 05:50:45 (mypc) any->syscheck
Rule: 553 (level 7) -> 'File deleted.'
File '/root/test' deleted
Mode: realtime
Attributes:
- Size: 6
- Permissions: rw-r--r--
- Date: Sun Mar 7 05:50:39 2021
- Inode: 131348
- User: root (0)
- Group: root (0)
- MD5: 126a8a51b9d1bbd07fddc65819a542c3
- SHA1: 9054fbe0b622c638224d50d20824d2ff6782e308
- SHA256: 7d6fd7774f0d87624da6dcf16d0d3d104c3191e771fbe2f39c86aed4b2bf1a0f
ファイル追加のログが出てないなと思ったが、元のルール設定を見たらファイル追加のルールはLevel 5で設定されていた。ファイル追加を監視したい場合はルールの上書きでLevelを上げるか、監視の閾値Levelを下げるかが必要。
ちなみにファイル変更監視のルールは0015-ossec_rules.xmlに記載されている下記の内容。
<rule id="550" level="7">
<category>ossec</category>
<decoded_as>syscheck_integrity_changed</decoded_as>
<description>Integrity checksum changed.</description>
<mitre>
<id>T1492</id>
</mitre>
<group>syscheck,syscheck_entry_modified,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
<rule id="553" level="7">
<category>ossec</category>
<decoded_as>syscheck_deleted</decoded_as>
<description>File deleted.</description>
<mitre>
<id>T1107</id>
<id>T1485</id>
</mitre>
<group>syscheck,syscheck_entry_deleted,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
<rule id="554" level="5">
<category>ossec</category>
<decoded_as>syscheck_new_entry</decoded_as>
<description>File added to the system.</description>
<group>syscheck,syscheck_entry_added,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>