Skip to main content

​
Introduction

The Prowler ThreatScore is a comprehensive compliance scoring system that provides a unified metric for assessing your organization’s security posture across compliance frameworks. It aggregates findings from individual security checks into a single, normalized score ranging from 0 to 100.

​
Purpose

  • Unified View: Get a single metric representing overall compliance health
  • Risk Prioritization: Understand which areas pose the highest security risks
  • Progress Tracking: Monitor improvements in compliance posture over time
  • Executive Reporting: Provide clear, quantifiable security metrics to stakeholders

​
How ThreatScore Works

The ThreatScore calculation considers four critical factors for each compliance requirement:

​
1. Pass Rate (rate_i)

The percentage of security checks that passed for a specific requirement: 
Pass Rate = (Number of PASS findings) / (Total findings)

​
2. Total Findings (total_i)

The total number of checks performed (both PASS and FAIL) for a requirement. This represents the amount of evidence available - more findings provide greater confidence in the assessment.

​
3. Weight (weight_i)

A numerical value (1-1000) representing the business importance or criticality of the requirement within your organization’s context.

​
4. Risk Level (risk_i)

A severity rating (1-5) indicating the potential impact of non-compliance with this requirement.

​
Score Interpretation Guidelines

ThreatScoreInterpretationRecommended Actions
90-100%ExcellentMaintain current controls, focus on continuous improvement
80-89%GoodAddress remaining gaps, prepare for compliance audits
70-79%AcceptablePrioritize high-risk failures, develop improvement plan
60-69%Needs ImprovementImmediate attention required, may not pass compliance audit
Below 60%CriticalEmergency response needed, potential regulatory issues

​
Mathematical Formula

The ThreatScore uses a weighted average formula that accounts for all four factors: 
ThreatScore = (Σ(rate_i × total_i × weight_i × risk_i) / Σ(total_i × weight_i × risk_i)) × 100

​
Formula Properties

  • Normalization: Always produces a score between 0 and 100
  • Evidence-weighted: Requirements with more findings have proportionally greater influence
  • Risk-sensitive: Higher risk requirements impact the score more significantly
  • Business-aligned: Weight values allow customization based on organizational priorities

​
Parameters Explained

​
Weight Values (1-1000)

The weight parameter allows customization of ThreatScore calculation based on organizational priorities and regulatory requirements.

​
Weight Assignment Guidelines

Weight RangePriority LevelUse Cases
1-100LowOptional or nice-to-have controls
101-300MediumStandard security practices
301-600HighImportant security controls
601-850CriticalRegulatory compliance requirements
851-1000MaximumMission-critical security controls

​
Weight Selection Strategy

  1. Regulatory Mapping: Assign higher weights to controls required by industry regulations
  2. Business Impact: Consider the potential business impact of control failures
  3. Risk Tolerance: Align weights with organizational risk appetite
  4. Stakeholder Input: Involve compliance and business teams in weight decisions

​
Risk Levels (1-5)

Risk levels represent the potential security impact of non-compliance with a requirement.
Risk LevelSeverityImpact Description
1Very LowMinimal security impact, informational
2LowLimited exposure, low probability of exploitation
3MediumModerate security risk, potential for limited damage
4HighSignificant security risk, high probability of impact
5CriticalSevere security risk, immediate threat to organization

​
Risk Level Assessment Criteria

  • Confidentiality Impact: Data exposure potential
  • Integrity Impact: Risk of unauthorized data modification
  • Availability Impact: Service disruption potential
  • Compliance Impact: Regulatory violation consequences
  • Exploitability: Ease of exploitation by threat actors

​
Security Pillars and Subpillars

Prowler organizes security requirements into a hierarchical structure of pillars and subpillars, providing a comprehensive framework for security assessment and compliance evaluation.

​
Security Pillars Overview

The ThreatScore calculation considers requirements organized within the following security pillars:

​
1. IAM (Identity and Access Management)

Purpose: Controls who can access what resources and under what conditions Subpillars:
  • 1.1 Authentication: Verifying user and system identities
  • 1.2 Authorization: Controlling access to resources based on authenticated identity
  • 1.3 Privilege Escalation: Preventing unauthorized elevation of permissions

​
2. Attack Surface

Purpose: Minimizing exposure points that could be exploited by threat actors across network, storage, and application layers Subpillars:
  • 2.1 Network: Network infrastructure security, segmentation, firewall rules, VPC configurations, and traffic controls
  • 2.2 Storage: Data storage systems security, database security, file system permissions, backup security, and storage encryption
  • 2.3 Application: Application-level controls and configurations, application security settings, code security, runtime protections

​
3. Logging and Monitoring

Purpose: Ensuring comprehensive visibility and audit capabilities Subpillars:
  • 3.1 Logging: Capturing security-relevant events and activities
  • 3.2 Retention: Maintaining logs for appropriate time periods
  • 3.3 Monitoring: Active surveillance and alerting on security events

​
4. Encryption

Purpose: Protecting data confidentiality through cryptographic controls Subpillars:
  • 4.1 In-Transit: Encrypting data during transmission
  • 4.2 At-Rest: Encrypting stored data

​
Pillar Hierarchy and ThreatScore Impact

​
Hierarchy Structure

Security Framework
├── 1. IAM
│   ├── 1.1 Authentication
│   ├── 1.2 Authorization
│   └── 1.3 Privilege Escalation
├── 2. Attack Surface
│   ├── 2.1 Network
│   ├── 2.2 Storage
│   └── 2.3 Application
├── 3. Logging and Monitoring
│   ├── 3.1 Logging
│   ├── 3.2 Retention
│   └── 3.3 Monitoring
└── 4. Encryption
    ├── 4.1 In-Transit
    └── 4.2 At-Rest

Example Requirement Structure:
├── Pillar: 1. IAM
│   ├── Subpillar: 1.1 Authentication
│   │   ├── Requirement: MFA Implementation
│   │   │   ├── Check 1: Admin accounts use MFA
│   │   │   ├── Check 2: Regular users use MFA
│   │   │   └── Check 3: Service accounts use MFA
│   │   └── [Additional Requirements]
│   └── [Additional Subpillars: Authorization, Privilege Escalation]

​
Weight and Risk Assignment by Pillar

Different pillars typically receive different weight and risk assignments based on their security impact:
PillarTypical Weight RangeTypical Risk RangeRationale
1. IAM800-10004-5Critical for access control, high impact if compromised
2. Attack Surface500-9003-5Highly dependent on exposure and criticality across network, storage, and application layers
3. Logging and Monitoring600-8003-4Important for detection and compliance, moderate direct impact
4. Encryption700-9504-5Essential for data protection, regulatory compliance
Subpillar Weight Considerations:
  • 2.1 Network (Attack Surface): 500-800, Risk 3-4 - Network perimeter defense
  • 2.2 Storage (Attack Surface): 600-900, Risk 4-5 - Data exposure impact
  • 2.3 Application (Attack Surface): 400-700, Risk 2-4 - Varies by application criticality

​
Pillar-Specific Scoring Considerations

​
High-Impact Pillars (1. IAM, 4. Encryption)

  • Characteristics: Direct impact on data protection and access control
  • ThreatScore Impact: Failures in these pillars significantly lower overall score
  • Weight Strategy: Assign maximum weights (800-1000) to critical requirements
  • Risk Strategy: Most requirements rated 4-5 due to severe consequences

​
Variable-Impact Pillar (2. Attack Surface)

  • Characteristics: Impact varies significantly across subpillars (Network, Storage, Application)
  • ThreatScore Impact: Depends on specific subpillar and business context
  • Weight Strategy:
    • 2.1 Network subpillar: 500-800 (perimeter defense importance)
    • 2.2 Storage subpillar: 600-900 (data exposure risk)
    • 2.3 Application subpillar: 400-700 (application-specific criticality)
  • Risk Strategy: Wide range (2-5) based on exposure, data sensitivity, and business criticality

​
Monitoring Pillar (3. Logging and Monitoring)

  • Characteristics: Essential for compliance and incident response
  • ThreatScore Impact: Moderate influence, critical for audit requirements
  • Weight Strategy: Consistent weights (600-800) across logging, retention, and monitoring subpillars
  • Risk Strategy: Moderate risk levels (3-4) with emphasis on compliance impact

​
Cross-Pillar Dependencies

​
Authentication ↔ Authorization (IAM)

  • Strong authentication enables effective authorization controls
  • Weight both subpillars highly as they’re interdependent

​
Logging ↔ Monitoring (Logging and Monitoring)

  • Logging provides the data that monitoring systems analyze
  • Balance weights to ensure both data collection and analysis are prioritized

​
In-Transit ↔ At-Rest (Encryption)

  • Comprehensive data protection requires both encryption types
  • Consider data flow patterns when assigning relative weights

​
Pillar Coverage in ThreatScore

​
Complete Coverage Benefits

  • Comprehensive Assessment: All security domains represented in score
  • Balanced View: Prevents over-emphasis on single security aspect
  • Regulatory Alignment: Covers requirements across major compliance frameworks

​
Partial Coverage Considerations

  • Focused Assessment: Target specific security domains
  • Resource Optimization: Concentrate efforts on high-priority areas
  • Gradual Implementation: Phase in additional pillars over time

​
Scoring Examples

​
Example 1: Basic Two-Requirement Scenario

Consider a compliance framework with two requirements: Requirement 1: Encryption at Rest
  • Findings: 200 PASS, 500 FAIL (total = 700)
  • Pass Rate: 200/700 = 0.286 (28.6%)
  • Weight: 500 (High priority - data protection)
  • Risk Level: 4 (High risk - data exposure)
Requirement 2: Access Logging
  • Findings: 300 PASS, 100 FAIL (total = 400)
  • Pass Rate: 300/400 = 0.75 (75%)
  • Weight: 800 (Critical for audit compliance)
  • Risk Level: 3 (Medium risk - audit trail)
Calculation: 
Numerator = (0.286 × 700 × 500 × 4) + (0.75 × 400 × 800 × 3)
          = (400,400) + (720,000)
          = 1,120,400

Denominator = (700 × 500 × 4) + (400 × 800 × 3)
            = 1,400,000 + 960,000
            = 2,360,000

ThreatScore = (1,120,400 / 2,360,000) × 100 = 47.5%

​
Example 2: Enterprise Scenario with Pillar Structure

This example demonstrates how pillar organization affects ThreatScore calculation:
PillarSubpillarRequirementPassFailTotalWeightRiskPass Rate
1. IAM1.2 AuthorizationAccess Controls280120400800470%
2. Attack Surface2.1 NetworkNetwork Segmentation15050200750475%
2. Attack Surface2.2 StorageBackup Security200100300600366.7%
3. Logging and Monitoring3.1 LoggingAudit Logging35050400700387.5%
4. Encryption4.2 At-RestEncryption45050500950590%
Step-by-step Calculation:
  1. Calculate weighted contributions for each requirement: 
    Numerator = Σ(rate_i × total_i × weight_i × risk_i)
    • Access Controls (1.2 Authorization): 0.70 × 400 × 800 × 4 = 896,000
    • Network Segmentation (2.1 Network): 0.75 × 200 × 750 × 4 = 450,000
    • Backup Security (2.2 Storage): 0.667 × 300 × 600 × 3 = 360,060
    • Audit Logging (3.1 Logging): 0.875 × 400 × 700 × 3 = 735,000
    • Encryption (4.2 At-Rest): 0.90 × 500 × 950 × 5 = 2,137,500
  2. Sum numerator: 2,137,500 + 896,000 + 735,000 + 360,060 + 450,000 = 4,578,560
  3. Calculate total weights for each requirement: 
    Denominator = Σ(total_i × weight_i × risk_i)
    • Access Controls (1.2 Authorization): 400 × 800 × 4 = 1,280,000
    • Network Segmentation (2.1 Network): 200 × 750 × 4 = 600,000
    • Backup Security (2.2 Storage): 300 × 600 × 3 = 540,000
    • Audit Logging (3.1 Logging): 400 × 700 × 3 = 840,000
    • Encryption (4.2 At-Rest): 500 × 950 × 5 = 2,375,000
  4. Sum denominator: 2,375,000 + 1,280,000 + 840,000 + 540,000 + 600,000 = 5,635,000
  5. Final ThreatScore calculation: 
    ThreatScore = (Numerator / Denominator) × 100
ThreatScore = (4,578,560 / 5,635,000) × 100 = 81.2%
Pillar-Level Analysis:
  • 1. IAM pillar (1.2 Authorization): Significant impact despite lower pass rate (70%) due to high weight (800)
  • 2. Attack Surface pillar (2.1 Network): Strong performance (75%) with high weight (750) balances the score
  • 2. Attack Surface pillar (2.2 Storage): Lowest performance (66.7%) but limited impact due to moderate weight (600)
  • 3. Logging and Monitoring pillar (3.1 Logging): Moderate contribution with good performance (87.5%)
  • 4. Encryption pillar (4.2 At-Rest): Highest contribution due to maximum weight (950) and risk (5)

​
Example 3: Multi-Pillar Comprehensive Scenario

PillarSubpillarRequirementPassFailWeightRiskPass Rate
1. IAM1.1 AuthenticationMFA Implementation18020900590%
1. IAM1.2 AuthorizationLeast Privilege Access15050850475%
1. IAM1.3 Privilege EscalationAdmin Account Controls955950595%
2. Attack Surface2.1 NetworkFirewall Configuration400100600380%
2. Attack Surface2.1 NetworkPublic Endpoint Security8020700480%
2. Attack Surface2.2 StorageData Classification300100650375%
2. Attack Surface2.3 ApplicationInput Validation15050500375%
3. Logging and Monitoring3.1 LoggingTransaction Logging50050750390.9%
3. Logging and Monitoring3.3 MonitoringReal-time Alerts20050700480%
4. Encryption4.2 At-RestDatabase Encryption30020900593.8%
4. Encryption4.1 In-TransitAPI/Web Encryption25010800496.2%
Pillar Performance Summary:
  • 1. IAM Pillar Average: ~87% (weighted by findings across Authentication, Authorization, and Privilege Escalation subpillars)
  • 2. Attack Surface Pillar Average: ~77% (weighted across Network, Storage, and Application subpillars)
    • 2.1 Network subpillar: ~80% average
    • 2.2 Storage subpillar: 75%
    • 2.3 Application subpillar: 75%
  • 3. Logging and Monitoring Average: ~87% (weighted by findings across Logging and Monitoring subpillars)
  • 4. Encryption Pillar Average: ~94% (weighted by findings across In-Transit and At-Rest subpillars)
Overall ThreatScore: ~85.3% This comprehensive example demonstrates how:
  • High-performing, high-weight pillars (4. Encryption, 1. IAM) significantly boost the score
  • The 2. Attack Surface pillar shows how diverse subpillars (Network, Storage, Application) are aggregated
  • Multiple requirements within pillars provide detailed granular assessment
  • Cross-pillar balance prevents single points of failure in security posture

​
Example 4: Impact of Parameter Changes

Using the scenario, let’s see how parameter changes affect the score:

​
Scenario A: Increase Encryption Risk Level

Change Encryption risk from 5 to 3:
  • New ThreatScore: 77.8% (decrease of 3.4 points)
  • Impact: Lower risk weighting reduces the influence of high-performing critical controls

​
Scenario B: Improve Access Controls Pass Rate

Change Access Controls from 70% to 90% pass rate:
  • New ThreatScore: 85.1% (increase of 3.9 points)
  • Impact: Improving performance on high-weight requirements has significant score impact

​
Scenario C: Add New Low-Weight Requirement

Add “Documentation Completeness” (50 PASS, 10 FAIL, weight=100, risk=1):
  • New ThreatScore: 81.3% (minimal change of 0.1 points)
  • Impact: Low-weight requirements have minimal impact on overall score

​
Implementation Details

​
Edge Cases and Special Conditions

​
Zero Findings Scenario

When a requirement has total_i = 0 (no findings):
  • Behavior: Requirement is completely excluded from calculation
  • Rationale: No evidence means no contribution to confidence in the score
  • Impact: Other requirements receive proportionally more influence

​
Perfect Score Scenario

When all requirements have 100% pass rate:
  • Result: ThreatScore = 100%
  • Interpretation: All implemented security checks are passing

​
Zero Pass Rate Scenario

When all requirements have 0% pass rate:
  • Result: ThreatScore = 0%
  • Interpretation: Critical security failures across all requirements

​
Single Requirement Framework

For frameworks with only one requirement:
  • Formula simplification: ThreatScore = pass_rate × 100
  • Impact: Weight and risk values become irrelevant for score calculation

​
Performance Considerations

​
Computational Complexity

  • Time Complexity: O(n) where n = number of requirements
  • Space Complexity: O(1) - constant space for accumulation
  • Scalability: Efficiently handles frameworks with thousands of requirements

​
Calculation Precision

  • Floating Point: Use double precision for intermediate calculations
  • Rounding: Final score rounded to 1 decimal place for display
  • Overflow Protection: Validate that weight × risk × total values don’t exceed system limits

​
Data Requirements

​
Minimum Data Set

For each requirement, the following data must be available:
  • pass_count: Number of PASS findings (integer ≥ 0)
  • fail_count: Number of FAIL findings (integer ≥ 0)
  • weight: Business importance (integer 1-1000)
  • risk: Risk level (integer 1-5)

​
Data Validation Rules

total_i = pass_i + fail_i
rate_i = pass_i / total_i (when total_i > 0)
1 ≤ weight_i ≤ 1000
1 ≤ risk_i ≤ 5

​
Handling Invalid Data

  • Negative values: Treat as 0 and log warning
  • Out-of-range weights/risk: Clamp to valid range and log warning
  • Missing data: Exclude requirement from calculation and log warning

​
Best Practices

  1. Establish Baseline
    • Record initial ThreatScore after implementing measurement
    • Set realistic improvement targets based on organizational capacity
    • Track score changes over time to identify trends
  2. Regular Reporting
    • Generate monthly ThreatScore reports for stakeholders
    • Highlight significant score changes and their causes
    • Include requirement-level breakdowns for detailed analysis
  3. Continuous Improvement
    • Use score trends to identify systematic issues
    • Correlate score changes with security incidents or changes
    • Adjust weights and risk levels based on lessons learned
⌘I