Enterprise Security Capabilities: The Integration Challenge
Article 5 of 7 in the System Security Concepts series
The Integration Gap
Most security concepts document what controls a system should have. Few document how the system leverages enterprise security capabilities that already exist.
This is the most common gap in security concept maturity. Organizations invest millions in IAM platforms, SIEM systems, vulnerability management, DLP, and security testing tools—then document systems as if these capabilities don’t exist. Each security concept reinvents authentication, logging, monitoring, and vulnerability management as if starting from zero.
The consequences:
Control duplication: Systems build local authentication when enterprise SSO exists. Applications implement custom logging when SIEM integration is available. Teams create system-specific vulnerability tracking when enterprise processes exist.
Integration failures: Dependencies on enterprise capabilities remain undocumented until they fail. SSO outage affects 50 systems, but nobody knew which ones. SIEM upgrade breaks application logging, surprising application teams.
Invisible architecture: Security concepts describe system-level controls. Stack them together and you see… disconnected islands. The actual enterprise security architecture—the capabilities systems share—remains invisible. The CISO can’t answer “how mature is our IAM capability?” because no view shows which systems use it and how.
Lost optimization opportunities: Similar systems solve identical problems differently because previous solutions aren’t documented in reusable form. Authentication patterns, monitoring configurations, access control models—reinvented repeatedly.
The solution: document enterprise security capability integration explicitly in every security concept.
What Are Enterprise Security Capabilities?
Enterprise security capabilities are shared security services, platforms, and processes that multiple systems use.
Common enterprise capabilities:
Identity and Access Management (IAM)
- Single sign-on (SSO) platforms (Azure AD, Okta, Ping Identity)
- Privileged access management (CyberArk, BeyondTrust)
- Access governance and access reviews
- Multi-factor authentication enforcement
- Identity lifecycle management (provisioning/de-provisioning)
Security Monitoring and Detection
- Security information and event management (SIEM) (Splunk, QRadar, Sentinel)
- Security orchestration, automation and response (SOAR)
- User and entity behavior analytics (UEBA)
- Network detection and response (NDR)
- Endpoint detection and response (EDR)
Vulnerability and Threat Management
- Vulnerability scanning (Qualys, Tenable, Rapid7)
- Penetration testing programs
- Security testing in development (SAST/DAST/SCA)
- Threat intelligence platforms
- Security posture management
Data Protection
- Data loss prevention (DLP) (Forcepoint, McAfee, Symantec)
- Email security gateways
- Cloud access security brokers (CASB)
- Encryption key management
- Data classification tools
Incident Response
- Incident response procedures and playbooks
- Security operations center (SOC)
- Forensic investigation capabilities
- Crisis management processes
Governance and Compliance
- GRC platforms (ServiceNow, RSA Archer)
- Policy management and distribution
- Compliance monitoring and reporting
- Security awareness training
Not all organizations have all capabilities. Mature organizations have most. Even organizations with limited capabilities have some shared services—enterprise antivirus, network firewalls, backup systems.
The question isn’t “do we have enterprise capabilities?” but “which capabilities do we have, and how do systems integrate with them?”
Documenting Capability Integration
Document capability integration in three parts: what exists, how this system uses it, and what gaps remain.
What Enterprise Capabilities Exist
Security concepts reference organizational capability inventory:
## Enterprise Security Capabilities (Organizational Context)
Our organization maintains the following enterprise security capabilities:
### Identity and Access Management
- SSO: Azure AD with SAML/OIDC support
- MFA: Azure AD Conditional Access
- PAM: CyberArk for privileged accounts
- Access Reviews: Quarterly via IT Operations
### Security Monitoring
- SIEM: Splunk Enterprise
- EDR: CrowdStrike Falcon
- NDR: Darktrace
- SOC: 24/7 security operations team
### Vulnerability Management
- Infrastructure Scanning: Qualys
- Application SAST: SonarQube (CI/CD integrated)
- Application DAST: OWASP ZAP (pre-production)
- Pen Testing: Annual third-party testing program
### Data Protection
- DLP: Microsoft Purview
- Email Security: Proofpoint
- Encryption: BitLocker (endpoints), Azure Storage Encryption (cloud)
### Incident Response
- IR Process: Documented in ISMS
- SOC: Security Operations Center (24/7)
- Forensics: Retained consultant (as-needed)This section appears in a template or appendix referenced by all security concepts. Don’t duplicate in every security concept—reference centrally maintained organizational capability inventory.
How This System Integrates
For each relevant capability, document integration:
## System Security Capability Integration
### Authentication and Access Control
**Enterprise Capability**: Azure AD SSO
**Integration Approach**: SAML 2.0 integration for user authentication
**What System Inherits**:
- User identity verification
- MFA enforcement (Conditional Access policies)
- Password policy enforcement
- Account lockout protection
- Authentication logging to Azure AD
**System-Specific Implementation**:
- Application role definitions (mapped to Azure AD groups)
- Data-level access controls (based on user attributes)
- Session management (30-minute idle timeout)
**Dependency**: System cannot authenticate users if Azure AD unavailable
**Fallback**: None (by design - no local authentication)
### Security Monitoring
**Enterprise Capability**: Splunk SIEM
**Integration Approach**: Application logs forwarded via Splunk Universal Forwarder
**What System Inherits**:
- Centralized log collection and retention (90 days hot, 7 years archived)
- Security event correlation
- SOC monitoring (24/7)
- Automated alerting on suspicious patterns
**System-Specific Implementation**:
- Application-specific log format (JSON)
- Business transaction logging (regulatory requirement)
- Sensitive data masking in logs
**Dependency**: Log forwarding requires network connectivity to Splunk indexers
**Fallback**: Local logging (24 hours retention) if SIEM unavailable
### Vulnerability Management
**Enterprise Capability**: Qualys vulnerability scanning + SonarQube SAST
**Integration Approach**:
- Infrastructure: Weekly Qualys authenticated scans
- Application: SonarQube integrated in CI/CD pipeline (build fails on Critical/High findings)
**What System Inherits**:
- Automated vulnerability identification
- Centralized remediation tracking
- SLA-based remediation requirements
**System-Specific Implementation**:
- Application-specific security test cases
- Pre-production penetration testing checklist
**Dependency**: Build pipeline dependent on SonarQube availability
**Fallback**: Manual security review if SonarQube unavailable (degraded process)This format answers five questions:
- Which enterprise capability applies?
- How does the system integrate technically?
- What security benefits does the system inherit?
- What system-specific controls supplement enterprise capability?
- What breaks if the enterprise capability fails?
Gap Analysis: Where Enterprise Capabilities Don’t Cover Requirements
Enterprise capabilities may not satisfy all requirements. Document gaps and how you address them:
## Enterprise Capability Gaps and System-Specific Controls
### Gap: Application-Layer Authorization
**Requirement**: Fine-grained data access control based on customer relationship
**Enterprise Capability**: Azure AD provides authentication and basic role assignment
**Gap**: Azure AD doesn't support data-level authorization logic (which customers user can view)
**System-Specific Control**: Application authorization layer checking user-customer relationships
**Rationale**: Business logic specific to this application, not generalizable to enterprise capability
### Gap: Financial Transaction Audit Logging
**Requirement**: 7-year audit log retention for financial transactions (regulatory)
**Enterprise Capability**: Splunk retains logs for 90 days hot, 7 years archived
**Gap**: Splunk archive not optimized for regulatory audit retrieval
**System-Specific Control**: Application-specific audit database with optimized query performance
**Rationale**: Regulatory audit response time requirements necessitate purpose-built solution
**Integration**: Audit logs also forwarded to Splunk for security monitoringGap documentation serves three purposes. First, it prevents “why doesn’t this system use enterprise capability?” questions by explaining why system-specific controls are necessary. Second, it identifies opportunities for enterprise capability enhancement—if five systems have the same gap, maybe enhance the enterprise capability. Third, it provides transparency for risk assessment—gaps mean potential inconsistency in control implementation.
The Architecture View: Stacking Security Concepts
Individual security concepts document how one system integrates with enterprise capabilities. Stack all security concepts together and something valuable emerges: your actual enterprise security architecture.
Portfolio-Level Questions Security Concepts Answer
How many systems integrate with Azure AD SSO? Which don’t, and why?
- Query: Search all security concepts for “Azure AD” integration section
- Result: 47 systems integrated, 8 with local authentication (6 legacy systems pending migration, 2 OT systems with technical constraint)
Which systems depend on Splunk SIEM? What’s the blast radius if Splunk has extended outage?
- Query: Search all security concepts for “Splunk” dependency
- Result: 52 systems forward logs to Splunk, 15 marked as “critical dependency” (no fallback), 37 marked as “degraded functionality” (local logging fallback)
How consistently are we implementing authentication controls across similar systems?
- Query: Compare authentication sections across all web applications
- Result: 34 web apps use Azure AD SSO, 5 use Okta (M&A remnants), 2 use local authentication (inconsistency flags for remediation)
Which systems are in scope for PCI DSS? Do they all use required enterprise capabilities?
- Query: Filter security concepts by “PCI DSS” compliance tag, check DLP and encryption integration
- Result: 8 systems in scope, all use Microsoft Purview DLP, all use required encryption - control consistency verified
Portfolio Maturity Assessment
Security concepts enable capability maturity assessment:
IAM Capability Maturity Analysis (60 systems analyzed):
- SSO Integration: 78% (47/60 systems)
- MFA Enforced: 85% (51/60 systems) - higher than SSO due to local MFA in some legacy systems
- Privileged Access via CyberArk: 45% (27/60 systems) - gap identified, roadmap needed
- Access Reviews: 92% (55/60 systems) - strong coverage
This data-driven view enables informed investment decisions. The IAM platform is well-adopted for authentication and MFA. Privileged access management adoption is weak—investigate why and create adoption roadmap. Access review process is mature and widely implemented.
Identifying Capability Gaps and Duplicates
Security concepts reveal where enterprise capabilities should exist but don’t:
Gap pattern identified: 12 web applications implement custom rate-limiting/DDoS protection
- Observation: No enterprise capability for application-layer DDoS protection
- Recommendation: Evaluate enterprise Web Application Firewall (WAF) to provide consistent protection and reduce duplication
Gap pattern identified: 8 systems implement custom secrets management
- Observation: No enterprise secrets management capability (vault, key management)
- Recommendation: Implement HashiCorp Vault or Azure Key Vault as enterprise capability
Security concepts also reveal redundant capability investments:
Redundancy identified: 3 different SAST tools in use across application portfolio
- SonarQube: 25 applications
- Checkmarx: 15 applications
- Veracode: 8 applications
- Observation: Overlap without clear selection criteria
- Recommendation: Standardize on one platform, migrate applications, save licensing costs
Practical Integration Examples
Abstract principles need concrete examples. Here’s how different system types integrate with enterprise capabilities:
SaaS Application Integration
Example: Salesforce CRM
### IAM Integration
- SSO: Salesforce federated authentication via Azure AD (SAML 2.0)
- Provisioning: Automated user provisioning via SCIM from Azure AD
- De-provisioning: Automated via Azure AD (disable within 1 hour of HR termination)
### Monitoring Integration
- Authentication Events: Forwarded to Azure AD, aggregated in Splunk
- Application Activity Logs: Salesforce Shield Event Monitoring forwarded to Splunk
- API Activity: Monitored via Salesforce Setup Audit Trail + Splunk correlation
### Data Protection Integration
- DLP: Microsoft Purview monitors Salesforce via API (detects sensitive data sharing)
- Encryption: Salesforce Shield Platform Encryption (data at rest)
- Backup: Automated via OwnBackup (SaaS backup platform)
### Vulnerability Management
- SaaS Security Posture: Monitored via CloudGuard (SSPM)
- Configuration Review: Quarterly review by security team
- Vendor Security: Annual third-party attestation review (SOC 2, ISO 27001)Internal Web Application Integration
Example: Customer Portal (custom .NET application)
### IAM Integration
- SSO: Azure AD via OpenID Connect
- Application Roles: Defined in application, mapped to Azure AD groups
- API Authentication: OAuth 2.0 client credentials flow (machine-to-machine)
### Monitoring Integration
- Application Logs: JSON format via Splunk Universal Forwarder
- Performance Monitoring: Application Insights (Azure Monitor)
- Security Events: Authentication failures, authorization denials, data access → Splunk
### Data Protection Integration
- Encryption in Transit: TLS 1.3 (Azure Application Gateway)
- Encryption at Rest: Azure SQL TDE + Azure Storage SSE
- Secrets Management: Azure Key Vault for connection strings and API keys
### Vulnerability Management
- Infrastructure Scanning: Qualys (weekly authenticated scans)
- Application SAST: SonarQube in Azure DevOps pipeline
- DAST: OWASP ZAP in pre-production environment
- Pen Testing: Included in annual third-party testing scopeLegacy System with Limited Integration
Example: Manufacturing Execution System (MES) - legacy Java application
### IAM Integration
- SSO: Not supported (legacy authentication)
- Local Authentication: Strong password policy enforced
- Compensating Control: MFA via RSA SecurID tokens for privileged users
- Access Reviews: Manual quarterly review by application owner
### Monitoring Integration
- Application Logs: Custom syslog integration to Splunk (limited format)
- Authentication Events: Captured in application database, exported to Splunk daily
- Limitation: No real-time security event forwarding (technical constraint)
### Data Protection Integration
- Encryption in Transit: TLS 1.2 (limited by application capabilities)
- Encryption at Rest: Database-level encryption (Oracle TDE)
- DLP: Not applicable (no external data transfer)
### Vulnerability Management
- Infrastructure Scanning: Qualys (monthly - production change control limits frequency)
- Application SAST: Not integrated (legacy codebase, limited changes)
- Pen Testing: Included in annual testing (limited scope due to stability requirements)
### Migration Plans
- Target: Replacement with cloud-native MES (24-month roadmap)
- Interim: Accept limited integration due to legacy constraints
- Risk Accepted By: VP Manufacturing, CISO (documented in risk register)Benefits of Explicit Integration Documentation
Documenting enterprise capability integration provides multiple benefits:
For System Architects
- Clear guidance on what to use vs. build
- Reduce rework from missed capability dependencies
- Faster design decisions (reference previous integration patterns)
For Security Teams
- Portfolio visibility without investigating every system individually
- Consistent control implementation across systems
- Identify adoption gaps and prioritize remediation
For Business Owners
- Understand dependencies on shared services
- Plan for enterprise capability changes (migration impact analysis)
- Justify system-specific control costs when enterprise capabilities don’t fit
For Auditors
- Evidence that controls are actually implemented, not just documented
- Consistent control application across system portfolio
- Clear accountability for enterprise vs. system-specific controls
For CISO/Leadership
- Data-driven enterprise capability investment decisions
- Security architecture visibility (actual, not theoretical)
- Maturity assessment based on real adoption data
Conclusion
Enterprise security capabilities represent significant organizational investment. Most security concepts ignore them, documenting systems as isolated islands rather than integrated architecture.
The integration gap creates control duplication, invisible dependencies, and lost optimization opportunities. Organizations reinvent authentication, monitoring, and vulnerability management repeatedly because previous solutions aren’t documented in reusable form.
The solution: document enterprise capability integration explicitly. Show what capabilities exist, how systems use them, where gaps remain, and why system-specific controls are necessary.
Stack all security concepts together and you gain portfolio-level visibility. How many systems use IAM? Which depend on SIEM? Where are controls inconsistent? This enables data-driven capability investment and maturity assessment.
Article 6 examines access control and data protection in detail—two security domains that appear in every security concept yet are often poorly documented. How to specify authentication requirements, define authorization models, classify data, and document encryption implementation.
Next in series: Article 6 - Access Control and Data Protection: Getting the Details Right
Article 5 of 7 | Ready for publication Target audience: Security Architects, Enterprise Architects, CISO Word count: ~2,450