Skip to main content

Security Best Practices

This document provides actionable security recommendations for deploying and operating Squid. Following these practices will help ensure your data integration remains secure.

Initial Setup

1. Enable ACL Override

The most critical configuration decision:

System Property: x_a46gh_squidx.allowAclOverride
Value: true

Why: ACLs cause silent data loss. Squid's built-in security mechanisms provide equivalent protection with predictable behavior.

Required for Support

arc46 cannot provide support unless this property is set to true.

2. Review Predefined Configurations

Before granting access to predefined configurations:

  1. Review which columns each view exposes
  2. Understand what relations are available
  3. Verify no sensitive data is unexpectedly included

3. Plan Your Role Strategy

Design your role structure before deployment:

┌─────────────────────────────────────────────────────────────────┐
│ Role Planning Matrix │
├─────────────────────────────────────────────────────────────────┤
│ │
│ System/User Configurations Roles Needed │
│ ───────────── ────────────── ──────────── │
│ Monitoring All CMDB rest + defaultAccess │
│ Asset Mgmt alm_* configs rest + alm_access │
│ Network Team cmdb_ci_network* rest + network_access│
│ Reporting All (read-only) rest + defaultAccess │
│ │
└─────────────────────────────────────────────────────────────────┘

Service Account Security

Creating Service Accounts

Do:

  • Create dedicated accounts per integration
  • Use descriptive names: squid_[purpose]_[system]
  • Assign minimal necessary roles
  • Document the purpose and owner

Don't:

  • Share accounts between integrations
  • Use personal accounts for integrations
  • Assign the admin role to service accounts

Service Account Template

Account: squid_cmdb_export_monitoring
Purpose: Export CMDB data to monitoring system
Owner: Infrastructure Team
Contact: infra@company.com

Roles:
- x_a46gh_squidx.rest # API access
- monitoring_cmdb_access # Custom role for specific configs

Configurations Accessed:
- cmdb_ci_server
- cmdb_ci_network_adapter

Review Schedule: Quarterly

Credential Management

  1. Store credentials securely - Use a secrets manager
  2. Rotate regularly - At least annually, or after personnel changes
  3. Use OAuth when possible - Tokens can be revoked
  4. Monitor for exposure - Check for credentials in logs/code

Configuration Security

Principle of Least Privilege

Configure each integration with minimal access:

# Bad: Overly permissive
Configuration: cmdb_ci
Roles: [] (empty = anyone with rest role)
Relations Restricted: false

# Good: Appropriately restricted
Configuration: cmdb_ci_server_monitoring
Roles: [monitoring_access]
Relations Restricted: true
Allowed Relations: [ci_to_ip_address, ci_to_network_adapter]
View Filter: base_install_status=1

Custom Configuration Checklist

When creating custom configurations:

  • Define appropriate view (only needed columns)
  • Set role requirements
  • Enable Relations Restricted if not all relations should be allowed
  • Set Restrict Encoded Query to true unless operators are needed
  • Set appropriate Limit for inline configurations
  • Add a descriptive Description
  • Document the configuration's purpose and users

View Design Security

When designing database views:

┌─────────────────────────────────────────────────────────────────┐
│ View Design Checklist │
├─────────────────────────────────────────────────────────────────┤
│ │
│ □ Include only columns actually needed │
│ □ Exclude sensitive fields: │
│ • comments / work_notes │
│ • u_sensitive_* custom fields │
│ • credentials / passwords │
│ • internal cost / financial data │
│ □ Consider View Fields for additional restriction │
│ □ Document the view's purpose │
│ │
└─────────────────────────────────────────────────────────────────┘

Query Security

For API Consumers

Educate API consumers on secure query practices:

# Efficient and secure
encodedQuery: base_sys_id=abc123def456...
encodedQuery: base_nameSTARTSWITHwebserver
encodedQuery: base_install_status=1

# Avoid when possible (if enabled)
encodedQuery: base_nameLIKE%server% # Performance impact
encodedQuery: base_nameENDSWITHprod # Performance impact

For Administrators

  1. Keep Restrict Encoded Query enabled - Disable only when necessary
  2. Use View Filters for complex queries - They're not restricted
  3. Monitor query patterns - Watch for abuse

Network Security

TLS/HTTPS

All Squid communication should use HTTPS (ServiceNow default):

  • Verify certificate validity
  • Use TLS 1.2 or higher
  • Disable insecure cipher suites (ServiceNow configuration)

IP Restrictions

Consider restricting API access by source IP:

  1. Identify IP ranges of legitimate clients
  2. Configure ServiceNow IP access rules
  3. Monitor for access from unexpected IPs

API Gateway

For additional control, consider fronting Squid with an API gateway:

┌─────────────┐     ┌─────────────┐     ┌─────────────────┐
│ Client │────▶│ API Gateway │────▶│ ServiceNow │
└─────────────┘ │ │ │ (Squid) │
│ • Rate limit│ └─────────────────┘
│ • IP filter │
│ • Logging │
└─────────────┘

Monitoring and Alerting

Critical Alerts

Configure alerts for:

EventThresholdPriority
Authentication failures5 in 5 minutesHigh
Forbidden operator detectedAnyHigh
Unusual data volume2x baselineMedium
After-hours accessAny (configurable)Low

Regular Reviews

ReviewFrequencyFocus
Access logsDailyAnomalies, failures
Service account usageWeeklyUnexpected patterns
Configuration changesWeeklyUnauthorized modifications
Role assignmentsMonthlyAppropriate access
Service account auditQuarterlyStill needed, proper owner

Incident Response

Suspected Unauthorized Access

  1. Contain: Disable affected service account
  2. Investigate: Review logs for scope
  3. Remediate: Rotate credentials, patch vulnerability
  4. Document: Record incident and response

Data Exposure

  1. Assess: What data was potentially accessed?
  2. Contain: Restrict access immediately
  3. Investigate: How was access obtained?
  4. Notify: Inform stakeholders per policy
  5. Remediate: Fix vulnerability

Compliance Considerations

Data Classification

Map configurations to data sensitivity:

High Sensitivity:
- Configurations accessing PII
- Financial data exports
- Credentials or security data
Protections:
- Strict role requirements
- Enhanced logging
- Regular access reviews

Medium Sensitivity:
- General CMDB data
- Asset information
Protections:
- Standard role requirements
- Normal logging

Low Sensitivity:
- Reference data
- Non-identifying metadata
Protections:
- Basic access control

Audit Trail Requirements

For regulated environments:

  1. Enable INFO-level logging
  2. Retain logs per compliance requirements
  3. Ensure logs capture:
    • Who accessed what
    • When access occurred
    • What query was used
    • How much data was returned

Access Certification

Implement periodic access reviews:

┌─────────────────────────────────────────────────────────────────┐
│ Access Certification Process │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Export list of service accounts with Squid roles │
│ 2. Send to account owners for certification │
│ 3. Owner confirms: Still needed? Access appropriate? │
│ 4. Remediate: Remove unnecessary access │
│ 5. Document: Record certification results │
│ │
│ Frequency: Quarterly or per compliance requirements │
│ │
└─────────────────────────────────────────────────────────────────┘

Security Testing

Regular Testing

TestFrequencyMethod
Authentication enforcementMonthlyAttempt access without role
Authorization enforcementMonthlyAttempt access to restricted config
Query validationMonthlyAttempt forbidden operators
View restrictionQuarterlyVerify only expected columns returned

Testing Checklist

Authentication Tests:
- [ ] Access denied without rest role
- [ ] Access denied with expired session
- [ ] Admin override works correctly

Authorization Tests:
- [ ] Config access denied without required role
- [ ] Config access granted with required role
- [ ] Relations blocked when restricted

Query Validation Tests:
- [ ] ^NQ operator blocked
- [ ] LIKE operator blocked (if restricted)
- [ ] Valid operators work correctly

Data Access Tests:
- [ ] Only view columns returned
- [ ] View filter enforced
- [ ] User filter applied correctly

Summary Checklist

Before Production Deployment

  • allowAclOverride set to true
  • Service accounts created (not personal accounts)
  • Roles assigned appropriately
  • Configurations reviewed for sensitive data
  • View filters configured where needed
  • Relations restrictions set where needed
  • Logging enabled at appropriate level
  • Monitoring and alerting configured
  • Documentation completed

Ongoing Operations

  • Regular access reviews conducted
  • Logs monitored for anomalies
  • Credentials rotated on schedule
  • Security testing performed
  • Configurations audited for changes
  • Incident response plan tested
We track. Ok?