Re: File Integrity Monitoring - PCI

[Kevin Wilcox <wilcoxkm () APPSTATE EDU>]

On 18 October 2017 at 13:58, Justin Harwood <Justin.Harwood () cpcc edu> wrote:

> ?Can anyone recommend what you are doing with your college as it relates to File Integrity Monitoring // PCI - 
> Products/Processes/Things that worked/didn't work, etc.  Would be interested in seeing your thoughts on a manageable 
> solution.

Justin - I think my question is really, "what are you trying to accomplish?"

For example, you could say, "I just want to know if files change and
check the box".
- okay, that's cool, it's an honest response. If you're on a budget,
OSSEC is fantastic. Upside: you'll know when files change. Downside:
you won't know who did it. Arguable either way: there is no
distinction between you changing a file as part of an update or an
attacker changing a file (also arguable, if it happens outside of
maintenance then are your admins aggressors?). Does it make you
compliant? Ask your QSA but it probably meets the requirement.

You could say, "I want to know if files change and who did it".
- okay, even better. You can turn on filesystem auditing through Group
Policy or with something like auditd and collect it with via Windows
Event Forwarding, a Splunk agent or winlogbeat; if you need to, send
it to a syslog cluster with something like nxlog. If they're Windows
systems, enable powershell logging with at-least script block logging.
Go straight for transcription logging if you can get it. Alert on the
data with your SIEM, log agg solution, tripwire, OSSEC, etc. Upside:
you know when files change and who did it. Downside: it's somewhat
chatty and a little disk intensive. Does it make you compliant? Ask
your QSA but it probably meets the requirement.

Or you could say, "PCI compliance is important but I want to know
what's happening in that ecosystem. If something changes then it needs
to be corrected ASAP.".
- This is my personal favourite and it's the direction I'm pushing,
well, pretty much everyone - to the point I'm trying to make it the
_baseline_ for _all servers_ and for all systems in regulated
environments. File audit logging + sysmon on Windows with full
process/network accounting or auditd on Linux with full execve/socket
accounting, forward it with WEF/Splunk/winlogbeat/filebeat/nxlog to
your SIEM or log agg solution of choice. Use a configuration manager
like puppet, chef, etc., that on <x> delta ensures <y resources> are
configured a certain way. Upside: you know every process that runs,
its parent PID, the network connections it makes, files that are
opened, the whole bit. Potential malware infection? No problem, track
it down (at least to the point it kills your telemetry, which should
be enough to alert you to Shut It Down). Potential bad actor? You know
what they did and when (again, until they kill your telemetry). As
long as the configuration agent is running, even config changes get
corrected. Use the config manager to ensure your telemetry is running.
Downside: it's a little chatty, some work and takes some storage. If a
node stops checking in, go check on it immediately. Does it make you
compliant? I'd like to meet the QSA who seriously wants to argue that
it fails to meet requirements. Don't stop at PCI, do this across your
entire server environment. Do it for your sys-admins, net-admins and
security folks. Do it for anyone doing research. Seriously, push it to
all managed systems.

Because most folks are in Windows environments,
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon.

Don't sell it as PCI compliance. Sell it as PCI compliance plus
troubleshooting plus incident response. FIM is just a fancy way of
saying, "know your system".

With a bit of luck there will be at least one "telemetry for
compliance and incident response" presentation and a full-day seminar
on log aggregation with the Elastic stack (including alerting) at SPC
in 2018 *fingers crossed*.

kmw