Tag: File Integrity Monitoring

PCI Security Standards are technical and operational requirements set by the PCI Security Standards Council to protect cardholder data. Threat Stack customers frequently ask us how Threat Stack can help them comply with these two sets of requirements:

Requirement 10: Track and monitor all access to network resources and cardholder data (in other words, determine the who, what, where, and when)

Many of our AWS customers are storing their critical files on S3, and for various security and compliance reasons, those files need to be monitored to see if any are being accessed, altered, or deleted.

To help ensure the integrity of the files in S3 buckets, Threat Stack now supports alerting on access and changes to files in specific buckets. AWS now has capabilities for putting object level access into CloudTrail events, and we have added rules to our base rule set to support that feature. Read more “New Threat Stack Feature: S3 File Integrity Monitoring”

Compliance processes have a reputation for being expensive, time-consuming, and fraught with difficulties — and sometimes certifications are looked upon with skepticism. However, most of the PCI requirements are common sense, best practices that any organization that is concerned with security should adopt. At MineralTree, we use Threat Stack to mitigate security threats. Additionally Threat Stack helps us adhere to PCI requirements and document our compliance.

When’s the last time someone made an unauthorized change to your system files?

To answer this and other important security questions, as well as to meet many compliance requirements, you first need to have file integrity monitoring. In case you aren’t familiar with the term, file integrity monitoring (sometimes abbreviated to FIM) is the method for knowing exactly when and how your files are being changed at any moment in time. This includes critical system files, configuration files, and content files.

Identity management is a difficult problem in the cloud, especially when it comes to sharing user accounts — an all too familiar (and problematic) practice today. Sharing accounts is very common on EC2, in particular, because EC2 instances come with a standard set of user accounts that a team can begin using immediately. Although it’s possible to create more user accounts, doing so is a resource-intensive task that is not a top priority for most operations personnel — and as a result, teams often end up sharing the default accounts.