DotSec provides managed SIEM services to customers in a range of industries but as described in cyber security standards such as APRA’s CPS 234 and the Payment Card Industry Data Security Standard (or PCI DSS), cyber-security service providers are increasingly on the hook when it comes to the certification and accreditation of their paying clients. As the saying goes, “Where there is great power, there is great responsibility” 
DotSec is a PCI DSS compliant service provider and we’ll use this blog post to look specifically at what service providers need to know to operate within the context of the PCI DSS. And even if PCI DSS is not relevant to you, you might like to read on, anyhow: Whether you are a third-party service provider or the client of one, the ideas around formalisation and documentation of service-provider engagements and responsibility-allocation may still be of assistance.
The PCI DSS describes how a merchant may use a third-party service provider to:
- Store, process, or transmit cardholder data on the merchant’s behalf, and/or
- Manage components such as firewalls and routers, call centres and call recordings, databases, physical security, and/or servers, once again on the merchant’s behalf.
In either case, the service provider’s activities may impact the security of the Cardholder Data Environment (CDE). If that’s the case, then as noted in the DSS:
“There are two options for third-party service providers to validate [their] compliance:
- Annual assessment: Service providers can undergo an annual PCI DSS assessment(s) on their own and provide evidence to their customers to demonstrate their compliance; or
- Multiple, on-demand assessments: If they do not undergo their own annual PCI DSS assessments, service providers must undergo assessments upon request of their customers and/or participate in each of their customer’s PCI DSS reviews, with the results of each review provided to the respective customer(s)”
As part of our process of continuous improvement, we spent most of 2020 revising and improving our PCI DSS service provider policies, processes and personnel-training. As a result of that work (and yes, it was much harder than expected :-)) we are now able to confirm that DotSec has completed Self-Assessment Questionnaire D and an Attestation of Compliance (AOC) for Service Providers, with an overall COMPLIANT rating!
This achievement has significant benefits for DotSec’s customers:
- As described in the PCI DSS, a service provider that provides services that can affect the security of the customer’s Card Holder Environment (CDE), but that cannot produce a SAQ D and AOC, will be brought into the scope of the customer’s PCI DSS assessment. This increases the customer’s compliance costs and also increases the risk of non-compliance since a non-compliant finding against the service provider will be reflected in the customer’s non-compliant SAQ or ROC.
- By contrast, any of DotSec’s managed SIEM customers that need to comply with the PCI DSS can rely on DotSec’s SAQ D and AOC, thereby significantly reducing the scope, cost, complexity and risk of the customer’s PCI DSS compliance efforts.
About DotSec's managed SIEM (and the PCI DSS)
DotSec’s Managed SIEM service provides centralised aggregation and storage of event logs generated by customer systems that may be in-scope for PCI DSS compliance. In-scope systems are configured to forward event logs to the Managed SIEM environment which is deployed on AWS infrastructure, and DotSec cyber security professionals will use the Managed SIEM service to monitor log events and raise alerts when reportable (suspicious or anomalous) activity is detected.
DotSec is already a long-standing Payment Card Industry (PCI) Qualified Security Assessor (QSA) company meaning that DotSec is qualified to assess entities (including on-line merchants, payment processors and service providers) for compliance with the PCI Data Security Standard (DSS). Our completion of the AOC for Service Providers is further evidence of our commitment to payment card security and our process of continual improvement.
What about that responsibility thing?
Merchants and their service providers should clearly identify the services and system components which are included in the scope of the service provider’s PCI DSS assessment, the specific PCI DSS requirements covered by the service provider, and any requirements which the service provider’s customer must include in their own PCI DSS reviews.
Service providers are responsible for demonstrating their PCI DSS compliance, and may be required to do so by the payment brands. Service providers should contact their acquirer and/or payment brand to determine the appropriate compliance validation.
By way of example, here is a Responsibility Allocation Matrix (RAM) that is associated with one of our managed SIEM customers. As you can see, the RAM clearly allocates responsibility for each of the PCI DSS controls that are relevant to the managed SIEM service. The RAM is then referenced in the Service Level Agreement (SLA) and there is no confusion as to who was responsible for what when assessment time comes around.
|Task Description||PCI DSS Req #||Who is Responsible?|
|Configure/maintain/patch all managed SIEM components.||2.1, 2.2, 2.3, 6.2, 6.4.5, 7.1, 7.2, 8.1, 8.2, 8.5||DotSec|
|Collect and secure audit trails via the managed SIEM so they cannot be altered||10.5.1, 10.5.2, 10.5.3, 10.5.4, 10.5.5, 10.5.6||DotSec|
|Monitor/review logs and security events forwarded to the managed SIEM and raise alerts in case of anomalies or suspicious activity||10.6.1, 10.6.2||DotSec|
|Prepare monthly monitoring report for Customer.||10.6.1, 10.6.2||DotSec|
|Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis||10.7||DotSec|
|Monitor host log forwarding and raise alerts in case of failure.||10.8||DotSec|
|Monitor availability of the managed SIEM components, raise alerts in case of failure, and restore monitoring functionality in a timely manner.||10.8||DotSec|
|Monitor availability of OS platforms that host managed SIEM components and raise alerts in case of failure, and restore functionality in a timely manner.||10.8||DotSec|
|Configure/maintain/patch OS that runs the managed SIEM components.||2.1, 2.2, 2.3, 5.1, 5.2, 5.3, 6.2, 6.4.5, 7.1, 7.2, 8.1, 8.2, 8.3, 8.5 10.1, 10.2||DotSec|
|Configure/maintain/patch, and monitor the availability of the OSs that run any log-forwarding functionality and should such componenets fail, notify customer in a timely manner.||2.1, 2.2, 2.3, 5.1, 5.2, 5.3, 6.2, 6.4.5, 7.1, 7.2, 8.1, 8.2, 8.3, 8.5 10.1, 10.2, 10.8||DotSec|
|Install/maintain/patch in-scope hosts to generate and forward event log entries.||6.2, 10.1, 10.2, 10.3, 10.4, 10.5.3, 10.5.4||Customer|
|Remediate log-source and log-forwarding issues, and follow up on alerts and reports of anomalies and/or suspicious activity in a timely manner when notified by DotSec.||10.5.3, 10.5.4, 10.6.3||Customer|
|Maintain in-scope logging-host list and advise DotSec of additions/deletions to that list.||2.4, 10.5.3, 10.5.4||Customer|
Standards like CPS 234 and the PCI DSS are becoming more relevant as cyber-security service providers are increasingly on the hook when it comes to the certification and accreditation of their paying clients. In order to reduce our clients’ risk and costs DotSec has therefore completed Self-Assessment Questionnaire D and an Attestation of Compliance (AOC) for Service Providers.
Please feel free to get in contact if you have any questions or comments, or would like to enquire further about our AOC.