IT Service Management platforms occupy an unusual position in the enterprise security risk landscape: they are classified and governed as productivity tools (they help IT teams manage their work) while functioning as repositories of sensitive operational data (they contain everything IT teams know about the infrastructure, incidents, and access decisions they manage).
The ServiceNow API breach this week makes this mismatch visible. An attacker who could query a customer’s ServiceNow instance without authentication would find:
Infrastructure intelligence: Configuration items in the CMDB describe servers, network devices, applications, and their relationships. This is reconnaissance data that enables targeted attacks — knowing that ACME Corp’s payment processing runs on a specific server cluster with specific software versions is information an attacker would spend significant effort to collect. It was stored in the ServiceNow CMDB.
Incident and problem records: IT incident records routinely contain technical troubleshooting notes that include configuration details, error messages, and workarounds. Problem records describe known infrastructure weaknesses. An attacker reading these records has the benefit of IT teams’ own analysis of their infrastructure’s vulnerabilities.
Change records: Change requests document upcoming changes to infrastructure — scheduled patching windows, planned firewall rule changes, new system deployments. This operational calendar is valuable for timing attacks to coincide with maintenance windows or exploiting the window between a planned change announcement and its implementation.
Credentials in tickets: Despite security policies against it, credentials are regularly shared in IT tickets. “Reset password to Temp#1234” in an incident response ticket, database connection strings shared in a change request, API keys posted in a problem record for a debugging session — the population of credentials that pass through ticket systems is significant.
Classification Mismatch
The security classification applied to ITSM platforms typically reflects their business function (IT operations support tool) rather than their data content (high-sensitivity operational intelligence). This mismatch produces governance decisions that do not match the actual risk:
- ITSM platforms are often governed by IT operations rather than the information security programme
- Security assessments of the organisation focus on web applications, network infrastructure, and endpoints — not ITSM platforms
- Data retention policies are designed around IT workflow requirements (keep tickets for 3 years) rather than security data minimisation (reduce the window of sensitive operational data accessible in the system)
- Integration service accounts are created with broad access to ITSM data for operational convenience without a periodic access review
A Risk-Appropriate Governance Framework
Reclassify ITSM data: Apply data classification to the information stored in the ITSM platform. CMDB configuration data, incident records containing technical details, and change records should be classified at a level consistent with their sensitivity — often Confidential or Internal, not Public.
Control credential storage: Enforce a policy that credentials — passwords, API keys, connection strings — are not stored in ticket bodies, comments, or CMDB fields. Use a secrets management platform (HashiCorp Vault, AWS Secrets Manager, CyberArk) and reference the secret identifier rather than the credential in tickets.
Restrict external access: Review which source IPs and user populations can access the ITSM platform’s API. Integration service accounts should be IP-restricted to the source system. The ITSM REST API should not be accessible from untrusted networks without additional authentication controls.
Quarterly access reviews: Review ITSM platform user access, service account permissions, and integration credentials on a quarterly basis. ITSM platforms accumulate stale integration access as projects are completed and teams change.
Security team in the loop for platform updates: ITSM vendors release platform updates regularly. Security teams should be notified before production platform updates and should review the security content of each release — as the ServiceNow “Australia” release demonstrates, platform updates can introduce new API endpoints that change the security posture of the instance.
The SaaS Security Responsibility Model
The ServiceNow incident also illustrates the SaaS shared responsibility model in practice. ServiceNow introduced the unauthenticated endpoint — that is vendor-side responsibility. But the data that was exposed was customer data in the ITSM instance. What data should be in the ITSM system, how long it is retained, who can access it, and what compensating controls exist are customer-side responsibilities.
The shared responsibility model for SaaS ITSM platforms means organisations cannot rely exclusively on the vendor’s security to protect the data they store in the platform. A security governance programme for ITSM that treats “it’s a SaaS product, the vendor handles security” as a complete answer is inadequately accounting for the organisation’s side of the responsibility.
Share this article