Implementing security notifications for end user activity on Amazon FSx for Windows File Server

Security is job zero at AWS. Logging end user access to customer data is a key component of many customers’ internal security policies and compliance needs. End user access audit logs can be used to conduct periodic security audits and forensic investigations for security incidents. However, customers often need to learn about potentially anomalous behavior in near-real-time so that they can proactively evaluate emerging security risks and take actions to reduce the harm that a malicious user can cause. Data security managers are often required to react quickly when repeated unauthorized access attempts occur on their shared file storage such as when a large number of files are deleted unexpectedly.

With the new support for file access auditing customers can now log end user access to Amazon FSx for Windows File Server file system to meet security and compliance requirements. Audit logs can be forwarded to Amazon CloudWatch Logs or streamed to Amazon Kinesis Data Firehose. Customers can query audit events in CloudWatch Logs, trigger CloudWatch alarms or AWS Lambda functions to report on user activity. They can also archive logs to Amazon S3 or use AWS Partner solutions like Splunk or Datadog to monitor and report on events.

In this blog, I will explain how customers can set up file access auditing on Amazon FSx for Windows File Server to forward logs to Amazon CloudWatch Logs and trigger notifications for suspicious user activity in near-real-time using CloudWatch alarms. This solution can be used to get a notification when there’s an increase of suspicious access attempts above the baseline. This can be set up for an entire file share, individual home folders, or a particular file. Following such a notification customers can investigate logs within a given timeframe to understand what has caused this influx and take appropriate action.

Prerequisites

• AWS Managed Microsoft AD or a self-managed Active Directory to which your Amazon FSx file system will be joined.
• Amazon FSx file system created after 8^th June 2021 with at least 32 MB/s throughput capacity. To create a new file system, please refer to the Getting Started documentation.
• Amazon EC2 Windows instance to map your Amazon FSx file share.

Setting up the environment

First, let’s have a look at the infrastructure I deploy for showcasing this new capability.

Figure 1: Architecture diagram

I have a VPC across two Availability Zones with two layers of private subnets as shown in Figure 1. There is a management server which I use for configuring the environment and for accessing Amazon FSx file system as a client. I am using AWS Systems Manager Session Manager to securely connect to my server without the need of exposing it to the Internet. AWS Managed Microsoft AD is deployed in two private subnets. Both the jump server and the Amazon FSx file system are members of an Active Directory domain called AWS.CORP. This is joined to the AWS Managed Active Directory service. I add an Active Directory user called fsxclient which is used to simulate an unauthorized access activity. I create an Amazon FSx file system using a Multi-AZ deployment type across the two Availability Zones as shown above. This completes the infrastructure setup – now let’s have a look at how our auditing process works.

Enabling file access auditing on Amazon FSx

Amazon FSx supports auditing of end user accesses on files, folders, and file shares, which you can manage using the Amazon FSx console, AWS CLI, or API. Refer to our documentation to learn more about File Access Auditing capabilities, supported events, and event log destinations. The destination for these logs can either be CloudWatch Logs or Amazon Kinesis Data Firehose. I use CloudWatch Logs in my setup.

Figure 2: Amazon FSx audit logging settings

File access auditing can be enabled on an Amazon FSx file system during creation or at any time afterwards as long as the file system was created after June 8^th 2021. File access auditing is only supported on file systems with a throughput capacity of 32 MB/s or higher. When auditing is enabled, a message is logged to your event log destination which validates that the configuration is working.

I create a folder called “secret” in the root of the Amazon FSx share which hosts a file called “roadmap_do_not_share.doc”. I change permissions on the file to only allow access to it by the security principals listed in Figure 3. This denies access to my fsxclient user.

Figure 3: File Access Control List

Amazon FSx for Windows File Server auditing settings only enable the audit capability. For getting events on files and folders, I still need to configure audit controls using NTFS system access control lists (SACLs) on individual file system objects such as files and folders using the File Explorer in Figure 4 or PowerShell. To get auditing configuration of a folder I have to right click on it and select Properties, switch to Security tab, then click on Advanced.

Figure 4: Folder properties

This takes me to Advanced Security Settings where I can find the Auditing tab and I can add individual auditing entries as shown in Figure 5. I configure auditing settings to capture all failed attempts accessing either the folder itself or any object within by the Authenticated Users group. The Authenticated Users group is a special identity group which includes all Microsoft AD users who access the system through a sign-in process. Any other security principals can be used such as an existing or newly created group, an individual user, or Everyone group for all users.

Figure 5: Configuring audit policy using File Explorer

Architecture for near-real-time notification of audit events

Figure 6: Logical auditing diagram

Auditing event log filtering

With the infrastructure setup done, I’m receiving log events into my CloudWatch Logs log group whenever anyone tries accessing objects and gets an “Access Denied” message. I generate file access requests from my Admin server logged in as fsxclient user. This results in log events you can see in Figure 7.

Figure 7: Viewing audit events in a CloudWatch Logs

All events contain the exact content found in Windows Event Log records that are generated on the Amazon FSx file system. Figure 8 details a log event when I tried accessing secret roadmap file (“roadmap_do_not_share.doc”) with my fsxclient Microsoft Active Directory user which doesn’t have access to it. I have highlighted key information in the event which is most relevant:

• “Event ID 4656” is generated when access for an object is requested
• “Keywords” value “0x8010000000000000”^*1 indicates a failed access attempt (Audit Failure)
• “SubjectUserName” is the user name which was used to access the file
• “ObjectName” is the path to the object and its name

<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA-3E3B0328C30D}'/><EventID>4656</EventID><Version>1</Version><Level>0</Level><Task>12800</Task><Opcode>0</Opcode><Keywords>0x8010000000000000</Keywords><TimeCreated SystemTime='2021-05-24T22:44:34.112664300Z'/><EventRecordID>286071</EventRecordID><Correlation/><Execution ProcessID='4' ThreadID='924'/><Channel>Security</Channel><Computer>amznfsxywbathys.aws.corp</Computer><Security/></System><EventData><Data Name='SubjectUserSid'>S-1-5-21-3542593015-1953306266-3715292216-1144</Data><Data Name='SubjectUserName'>fsxclient</Data><Data Name='SubjectDomainName'>AWSCORP</Data><Data Name='SubjectLogonId'>0xd855722</Data><Data Name='ObjectServer'>Security</Data><Data Name='ObjectType'>File</Data><Data Name='ObjectName'>\Device\HarddiskVolume16\share\secret\roadmap_do_not_share.doc</Data><Data Name='HandleId'>0x0</Data><Data Name='TransactionId'>{00000000-0000-0000-0000-000000000000}</Data><Data Name='AccessList'>%%1541%%4423</Data><Data Name='AccessReason'>%%1541:   %%1805%%4423:  %%1811   D:(A;OICIID;0x1301bf;;;AU) </Data><Data Name='AccessMask'>0x100080</Data><Data Name='PrivilegeList'>-</Data><Data Name='RestrictedSidCount'>0</Data><Data Name='ProcessId'>0x4</Data><Data Name='ProcessName'></Data><Data Name='ResourceAttributes'>-</Data></EventData></Event>

Figure 8: Audit Failure log event

*1 – Audit Success event equals “0x8020000000000000” keyword, for more information please refer to this User Guide.

I’m using the Event ID and the name of the folder to create a metric filter for the CloudWatch Logs log stream to discard any other log entries and give me statistics on failed attempts to access this folder or objects within it. Another option I can used is CloudWatch Logs Subscription Filters, which provides the ability to pass event data to additional sources like AWS Lambda where you can deploy a Lambda function to parse the event data and gain meaningful insights into all fields reported in the event message.

I create a metric namespace to carry meaningful information as this provides helpful details when an alarm is triggered (see Figure 9). I use “folder/secret/4656” as the namespace which captures the folder name and Event ID. This helps me identify folder in question and Event ID logged when I receive an email related to the alarm. I define a metric value equal to 1 which means when a single log event matches my pattern, a counter will be incremented by one. I specified the default value as 0, which means that non-matching entries will have no effect on the counter.

Figure 9: Creating a CloudWatch metric filter

After I have a metric filter defined I’m able to see it as a metric in CloudWatch and I can configure a CloudWatch alarm using the metric. I’m using resolution of 1 minute with the Sum function to display the count of failed access attempts in any given minute.

Figure 10: CloudWatch ‘Access Denied’ custom metric

With this solution every object requiring monitoring needs a separate metric filter and metric namespace. For example, when monitoring user home folders, every folder would need these defined to be able to differentiate between their metrics.

Configuring alarms and notifications

Now the last step is to configure the alarm itself which will notify me of the increased number of unauthorized access attempts. This process can be tailored for various use cases – I can choose to send notification on every attempt or send no notifications at all and just monitor the alarm status in the CloudWatch console. I will use the same statistics Sum function over the period of 1 minute for my alarm as shown in Figure 11. The threshold for the alarm will be set at 5 or more failed access attempts. When the threshold is exceeded, an email notification will be triggered. I will also set “Missing data treatment” to “Treat missing data as good”. This is required to avoid my alarm going into “Insufficient Data” state, which can happen, for example, during the night when there is no user activity and the metric doesn’t generate any statistics. As an alternative to static threshold CloudWatch anomaly detection can be enabled for a metric. It applies statistical and machine learning algorithms to surface anomalies with minimal user intervention.

Figure 11: Configuring CloudWatch alarm

Notifications are set for “In alarm” state to trigger an Amazon SNS topic to send an email (see Figure 12).

Figure 12: Configuring CloudWatch alarm

Figure 13 shows the metric statistic over time with moments when the threshold that I had set for unauthorized access attempts is breached.

Figure 13: CloudWatch alarm graph

Results

Here is a sample email which I receive upon threshold breach. This is where my metric namespace comes into play as it helps me identify which folder and event id this particular alarm is associated with.

You are receiving this email because your Amazon CloudWatch Alarm "AccessDenied" in the US East (Ohio) region has entered the ALARM state, because "Threshold Crossed: 1 out of the last 1 datapoints [6.0 (01/06/21 18:08:00)] was greater than the threshold (5.0) (minimum 1 datapoint for OK -> ALARM transition)." at "Tuesday 01 June, 2021 18:09:35 UTC".

View this alarm in the AWS Management Console:
https://us-east-2.console.thinkwithwp.com/cloudwatch/deeplink.js?region=us-east-2#alarmsV2:alarm/AccessDenied

Alarm Details:
- Name:                       AccessDenied
- Description:               
- State Change:               OK -> ALARM
- Reason for State Change:    Threshold Crossed: 1 out of the last 1 datapoints [6.0 (01/06/21 18:08:00)] was greater than the threshold (5.0) (minimum 1 datapoint for OK -> ALARM transition).
- Timestamp:                  Tuesday 01 June, 2021 18:09:35 UTC
- AWS Account:                231573846347
- Alarm Arn:                  arn:aws:cloudwatch:us-east-2:231573846347:alarm:AccessDenied

Threshold:
- The alarm is in the ALARM state when the metric is GreaterThanThreshold 5.0 for 60 seconds.

Monitored Metric:
- MetricNamespace:                     folder/secret/4656
- MetricName:                          AccessDenied
- Dimensions:                         
- Period:                              60 seconds
- Statistic:                           Sum
- Unit:                                not specified
- TreatMissingData:                    notBreaching

State Change Actions:
- OK:
- ALARM: [arn:aws:sns:us-east-2:231573846347:Inform_about_access_denied]
- INSUFFICIENT_DATA:
--

While your experience might not match my test exactly, I have captured the time series below from when an unauthorized access attempt is logged until the email notification is received:

• Event timestamps are 18:07:09 – 18:07:46 (event count breaches threshold set)
• CloudWatch Alarm triggered 18:09:35 (state change from OK to ALARM)
• Email received in inbox 18:10:44

This timeline will vary depending on your particular configuration of the CloudWatch metric, CloudWatch alarm, SNS topic, email system, and other components.

Cleaning up

Remember to remove the deployment once you are done testing to avoid incurring costs. You can either delete the resources created using the console or if you used the Infrastructure as Code approach leveraging AWS CloudFormation then remove all related stacks.

Conclusion

Amazon FSx for Windows File Server now supports auditing end user access to files, folders, and file shares, enabling you to query, process, store, and archive logs and trigger actions to further advance your security and compliance goals. In this blog, I have explained how to configure file access auditing on Amazon FSx. I used CloudWatch Logs to accumulate audit events, filtered events according to a pattern that resembles suspicious user activity, and counted occurrences of suspicious activity as a CloudWatch metric. Using the CloudWatch metric, I showed how a CloudWatch alarm can be triggered and an email notification sent out when a metric threshold is breached. This approach can be further tailored and customized for various use cases. The new file access auditing capability provides visibility into Amazon FSx file system access patterns and enables customers to further strengthen their security posture.

Amazon FSx file access auditing is available at no additional cost in all AWS Regions where Amazon FSx is available. Learn more about its features in the Amazon FSx documentation.

AWS can help you assess how your company can get the most out of cloud. Join the millions of AWS customers that trust us to migrate and modernize their most important applications in the cloud. To learn more on modernizing Windows Server or SQL Server, visit Windows on AWS. Contact us to start your migration journey today.