Securing eCommerce with Microsoft Sentinel

The Challenge

Launching a new and potentially high-profile eCommerce website is a technically complex project, particularly if it is highly integrated with back-office systems for stock management, marketing, order management, and fulfilment. Even the most basic eCommerce website should include an edge firewall, a web application firewall, a web server, a database server, and potentially ERP or other accounting systems. Securing and then monitoring the security of all those elements requires constantly checking multiple log files and correlating entries to identify cybersecurity risks.

This becomes an impossible task for security teams without highly scalable log normalisation, advanced detection rules, and automation. It is precisely the situation that Security Information and Event Management (SIEM) systems were designed to address. However, traditional SIEM solutions require significant investments in resources and skills to deploy, so were rarely available to SMEs. Microsoft Sentinel is a scalable, cloud-native SIEM (as well as having leading security orchestration, automation, and response (SOAR) capabilities) that flips this limitation on its head. While it can scale to handle massive volumes of data, it can be utilised by the smallest SMEs wanting to improve security monitoring in their environment.

Tarbh Tech worked with a large enterprise client to deploy Microsoft Sentinel as a Microsoft native SIEM to feed cybersecurity alerts and incident data from various Microsoft platforms and other 3rd party technologies to its Security Operations Centre.

The Specifics

As part of a significant new strategy, the Client deployed a new eCommerce platform in Microsoft Azure. This platform comprised the following major components:

• Various Microsoft Azure-based technologies, including virtual machines, SQL databases, Logic Apps, Storage Accounts, and Azure Firewall.
• A content delivery network and web security product from a third-party vendor that also offered distributed denial of service attack protection.
• A backend customer relationship management (CRM) application that would collect customer and order information.
• An existing security operations centre (SoC) managed all on-premises infrastructure, reacting to cybersecurity alerts via a ticketing system.

The Solution

The Client had previously experimented with Microsoft Sentinel, and several artefacts and configuration items were left behind.

The Environment

The first task was to document the environment and clean up any resources which would no longer be required. Microsoft Sentinel is a solution deployed on an Azure Log Analytics resource. Log Analytics is a tool in the Azure portal to edit and run log queries from data collected by Azure Monitor Logs and interactively analyse their results. Usually, logs are retained for 30 days for analysis, but with Microsoft Sentinel, 90 days are included in the fee. You can change log retention (up to 730 days, with 365 required for PCI:DSS) under the “Usage and Estimated Costs” menu item for the Log Analytics workspace.

The Connectors

After Microsoft Sentinel was deployed[1], data ingestion was configured for the various components of the solution. Of all Microsoft Sentinel data connectors, the easiest is Microsoft Defender for Cloud, which requires only basic configuration to create alerts and incidents in Microsoft Sentinel as they arise in Defender for Cloud. A key detail; make sure it is enabled on all subscriptions in the environment. The Client had many subscriptions per the Microsoft Cloud Adoption Framework.

[1] Microsoft – https://docs.microsoft.com/en-us/azure/sentinel/quickstart-onboard

The subsequent major integration ingests DDOS and WAF logs from a third-party content delivery network (CDN). This integration required two VMs in the Azure environment:

• One is to access the CDN Rest API, download the logs and send them to a CEF format syslog server. This process is accomplished with a small software agent from the CDN.
• The second VM runs the Microsoft Azure Monitor Agent[1] configured to listen for and forward CEF logs to Sentinel. Some changes did have to be made to the rsyslog configuration; due to the volume of log files, the var partition was rapidly filling. This was traced to the rsyslog configuration directing all logs by default to the /var/log/messages file as well as Sentinel.

When configured, the resulting log entries are inserted into the CommonSecurityLog for further analysis.

Finally, connecting the CRM to Sentinel required the deployment of an Azure Function App. An Azure Function is a serverless compute service that enables users to run event-triggered code without provisioning or managing infrastructure. Being a trigger-based service, it runs a script or piece of code in response to various events, in this case, an hourly schedule. Two challenges were encountered with the deployment for the Client:

• The client’s CRM platform lacked the appropriate license to allow hourly querying of event logs. The Client resolved this directly with the vendor, though a daily workaround was possible.
• The Client’s Azure environment implemented many highly-secure configurations, including blocking all public access to Azure Storage Accounts. As an Azure Function App requires access to an Azure Storage Account, the existing ARM template had to be rewritten to use a construct called Private Link, which adds new DNS zones, NICs, and Vnets to the solution.

[1] Microsoft – https://docs.microsoft.com/en-us/azure/sentinel/connect-log-forwarder

The Automation

With the data flowing into the Microsoft Sentinel workspace, analytic rules were enabled to create alerts and incidents. While Microsoft Sentinel has extensive automation capabilities, the Client only required email integration with its ITSM platform at this point. Microsoft Sentinel recently introduced basic automation rules to run Logic App playbooks when an incident is created; the Logic App to send an email to the service desk is as follows:

The Result

The result for the Client is a SIEM environment which can scale to meet their growing needs while offering unparalleled visibility into their Microsoft Azure-based eCommerce platform. That is not the end of the road; a large environment such as this one will benefit from ongoing servicing to monitor data volumes, the effectiveness of analytical rules, improved reporting, and increased automation. The Microsoft Sentinel community is global and continues contributing new code, connectors, and analytics to the Microsoft Sentinel repositories on GitHub, which will add value as the clients platform expands.