NIST CSF 2.0 and Web Application Security
What the Framework Requires and How SiteWALL Delivers
Executive Snapshot
Risk reduced. | SiteWALL directly supports or materially contributes to CSF 2.0 subcategory outcomes primarily across Govern, Identify, Protect, Detect, and Respond, with limited contribution to selected Recover outcomes — preventing application-layer attacks, containing incidents automatically, and shielding applications from known exploits during the patching gap. |
Evidence produced. | SiteWALL’s core security and operational capabilities generate auditable artifacts — WAF policy exports, 180-day log archives, vulnerability assessment reports, incident records, SLA reports, and a documented RACI (Responsible, Accountable, Consulted, Informed) matrix — so the organisation can prove control effectiveness, not just claim it. |
Responsibilities retained. | SiteWALL owns detection and prevention at the application edge. The customer owns asset inventory completeness, application patching, identity controls, incident response governance, and recovery execution. This boundary is documented in the RACI matrix and enforceable through the SLA. |
Organisations that cannot demonstrate control effectiveness to regulators face not just audit findings, but escalating penalty frameworks and reputational consequences that can far exceed the cost of the controls. The evidence trail SiteWALL produces is not a compliance formality — it is a financial risk mitigation instrument. |
A note on this document: This paper represents PageNTRA's interpretation of how SiteWALL addresses NIST CSF 2.0 outcomes for internet-facing web applications. It is not a compliance certification, a formal audit report, or a legal attestation. Claims referencing the Service Description and License Features documents are supported by those contractual instruments; readers are encouraged to request the full document package from contact@pagentra.com. Final compliance determinations depend on implementation context, organisational scope, and assessor judgment. |
Who should read this: This paper is intended for CISOs, CIOs, risk leaders, compliance heads, and board stakeholders evaluating how web application security controls support NIST CSF 2.0 outcomes.
What CSF 2.0 Outcomes Apply to Web Application Security
The NIST Cybersecurity Framework 2.0, released on February 26, 2024, organises cybersecurity outcomes into six Functions, 22 Categories, and 106 Subcategories. The framework is technology-neutral and outcome-oriented — it describes what to achieve, not how to achieve it. It is designed to be tailored, not treated as a fixed checklist.
For organisations running internet-facing web applications, specific subcategories across multiple Functions converge into a recognisable set of security outcomes. We have distilled these into ten operational requirements — our practitioner-level interpretation of CSF 2.0 outcomes for web application environments. Each maps directly to one or more named CSF 2.0 Subcategories; a detailed subcategory-level mapping spreadsheet is available on request.
# | Operational Requirement | The Question It Answers | CSF 2.0 Subcategories |
1 | Know which applications you protect and their criticality | Do we have a clear inventory of every internet-facing application, prioritised by business risk? | ID.AM-02, ID.AM-05 |
2 | Identify vulnerabilities and understand threats | Are we actively finding weaknesses and consuming threat intelligence relevant to our web applications? | ID.RA-01, ID.RA-02, ID.RA-03, ID.RA-05 |
3 | Control who and what can reach your applications | Can we enforce access boundaries at the application perimeter and prevent unauthorised logical access? | PR.IR-01, PR.AA-01 |
4 | Prevent application-layer attacks | Are known and unknown attack patterns being blocked before they reach the application? | PR.IR-01, PR.PS-05 |
5 | Ensure applications remain available under attack | Can the application survive a sustained DDoS campaign or bot flood without degrading for legitimate users? | PR.IR-03, PR.IR-04 |
6 | Keep defences current as threats evolve | Are signatures, rules, and configurations updated continuously — and can known vulnerabilities be shielded before code is patched? | PR.PS-01, PR.PS-02 |
7 | Monitor web traffic continuously and detect anomalies | Is web traffic being inspected in real time, with behavioural and signature-based detection for threats that known patterns miss? | DE.CM-01, DE.AE-02, DE.AE-07, DE.AE-08 |
8 | Preserve evidence and correlate events across environments | Are logs retained long enough for investigation and regulatory inquiry, and are they flowing into a centralised SIEM? | DE.AE-03, DE.AE-04, DE.AE-06 |
9 | Contain and eradicate incidents rapidly | When a threat is detected, is containment automatic? Is the incident documented and triaged? | RS.MI-01, RS.MI-02, RS.MA-01, RS.MA-02, RS.AN-06 |
10 | Govern your security suppliers with evidence | Is the WAF vendor accountable through a documented RACI, enforceable SLA, and a defined change process? | GV.RR-02, GV.SC-04, GV.SC-05, GV.SC-07, GV.OC-03 |
These ten requirements are our distillation, not a mandatory NIST checklist. The framework is flexible by design. But for any organisation protecting internet-facing applications, these outcomes represent the questions a CSF-based assessment of internet-facing web application security is most likely to explore.
How SiteWALL Delivers Against Each Requirement
SiteWALL is a SaaS-delivered Web Application Firewall from PageNTRA Infosec, deployed across multiple data centres in India. Here is how it addresses each requirement — and where the customer's responsibility begins.
A note on mapping language: where SiteWALL directly produces the outcome a CSF subcategory describes, we say it “directly supports” that outcome. Where it meaningfully contributes to a broader outcome the customer ultimately owns, we say it “materially contributes.” A complete mapping workbook with this distinction for every capability is available on request from PageNTRA. |
- Application inventory and prioritisation
SiteWALL is licensed per FQDN, making the inventory of protected applications explicit and auditable. Per-application policy customisation lets security teams assign different protection profiles based on business criticality. The dashboard’s “Applications Configured” view provides a real-time count. Customer responsibility: maintaining a complete inventory of all applications, including those not yet onboarded to the WAF.
- Vulnerability identification and threat intelligence
SiteWALL includes 12 automated vulnerability assessments per application per year — one runs automatically each month, with findings broken down by severity (High, Medium, Low). Integrated third-party threat intelligence feeds and SiteWALL's own application-centric threat intelligence with attack feed provide context on active campaigns. PageNTRA issues customer advisories on emerging threats. Customer responsibility: acting on findings — remediating identified vulnerabilities within the application code and infrastructure.
- Access control at the application perimeter
Geolocation Blocking (Geo Rules), IP whitelist/blacklist, Custom Port Support, and API Protection enforce boundaries on who and what can reach protected applications — preventing unauthorised logical access at the application edge (PR.IR-01). Role-based access control (RBAC) on the SiteWALL management console ensures least-privilege access to the WAF itself (PR.AA-01). Customer responsibility: application-level identity and authentication (SSO, MFA, identity governance) remain outside the WAF's scope.
- Application-layer attack prevention
OWASP Top 10 mitigation, signature-based engines for known threats, and AI/ML-based behavioural analysis engines for unknown threats operate in inline block mode — detection translates directly into prevention (PR.IR-01). Web-shell Detection and Malware Scanning (covering both traffic and server-hosted files) prevent execution of unauthorised software (PR.PS-05). Additionally, Defacement Detection and Website Cloning Detection continuously monitor web asset integrity, alerting administrators to unauthorised changes. Customer responsibility: secure application development practices and code-level security reviews.
Deployment posture — inline block mode from day one: SiteWALL is deployed in inline block mode from the first day of service activation. PageNTRA's onboarding process includes baseline configuration and policy tuning completed before go-live — exception lists, custom rules, and application-specific parameters are established collaboratively with the customer during the onboarding call — so that blocking is active from the moment traffic routes through the WAF. There is no mandatory passive observation period post-deployment. SiteWALL's tuning process is designed to minimise false positives and support safe inline blocking from day one; the precision of the detection engine is what makes day-one protection operationally safe, not just commercially convenient. For organisations that cannot afford an exposure window while a WAF learns their traffic, this matters operationally — not just commercially. Initial configuration records and tuning documentation are available as evidence. |
- Availability under attack
Application-Layer DDoS protection with AI/ML automated blocking and rate limiting handles sustained L7 attacks. Multi-data-centre cloud infrastructure dedicated load balancers, traffic shaping, Global Server Load Balancing (GSLB), and a 99% Uptime SLA provide the resilience and capacity the framework expects (PR.IR-03, PR.IR-04). Customer responsibility: infrastructure-level redundancy, disaster recovery, and business continuity for the application stack itself.
- Defence maintenance and virtual patching
PageNTRA engineers continuously update attack signatures based on ongoing research, threat intelligence feeds, and analysis of recent attacks (PR.PS-02). Scheduled version updates follow a defined change management process (PR.PS-01) with a monthly maintenance window every Wednesday, 00:00–04:00 IST. Virtual Patching shields applications from known exploits while development teams prepare permanent fixes. Customer responsibility: secure software development lifecycle, timely application patching, and permanent code remediation.
- Continuous monitoring and anomaly detection
Web traffic is inspected continuously. AI/ML-based behavioural analysis and signature-based detection identify anomalous requests, bot activity, and known attack patterns (DE.AE-02). PageNTRA proactively monitors customer WAF policies and notifies customers of significant observations (DE.CM-01). SiteWALL integrates with third-party threat intelligence to enhance detection context (DE.AE-07). The Incident Monitoring service formalises incident declaration when adverse events meet defined criteria (DE.AE-08). Customer responsibility: monitoring non-web assets and correlating WAF events with broader organisational security telemetry.
- Evidence preservation and event correlation
The Logging API enables real-time export of WAF violation data to external log collection systems, supporting evidence preservation, SIEM correlation, and forensic analysis by the customer's security and investigation teams. Additionally, 180 days of WAF log storage is included by default with every licence, aligned with CERT-In's expectations, though full CERT-In compliance requires logs from all ICT systems, not just the WAF. SIEM integration via the Logging API gives customers a unified view across environments (DE.AE-03). Dashboard drill-down — Attack Paths, Top Attack IPs, Top Attack Sources, Top Attack Countries — helps analysts understand scope and impact (DE.AE-04). Customer responsibility: retaining logs from all other ICT systems and managing the SIEM environment.
- Rapid containment and incident management
Inline block mode and automated blocking deliver containment without waiting for an analyst (RS.MI-01). Virtual Patching and rule tuning close recurring attack patterns (RS.MI-02). Platinum support, included as standard with every licence provides Incident Monitoring and Incident Reporting through a documented support ticket workflow covering response execution (RS.MA-01) and triage (RS.MA-02). Customer responsibility: maintaining a full incident response programme — IR plans, tabletop exercises, post-incident reviews, legal and communications protocols.
- Supplier governance
The SiteWALL Service Description includes a documented Responsibilities Matrix (RACI) between PageNTRA and the customer (GV.RR-02), a 99% Uptime SLA with a defined service-extension credit process (GV.SC-05), scheduled maintenance notifications with a defined window (monthly, Wednesdays 00:00–04:00 IST) and a formal change-notification protocol (GV.SC-07). Alignment with PCI DSS and CERT-In log retention expectations supports understanding of legal and regulatory requirements (GV.OC-03). Customer responsibility: defining risk appetite, establishing cybersecurity policy, and maintaining the overall governance programme.
Shared responsibility in one sentence: SiteWALL owns detection and prevention at the application edge. The customer owns asset inventory completeness, application patching, identity controls, incident response governance, and recovery execution. This boundary is documented in the RACI matrix and enforceable through the SLA. |
Business Outcomes: What This Means Beyond Compliance
Subcategories matter to assessors. Business outcomes matter to everyone else:
The Question You Face | Business Outcome | SiteWALL Capability | Evidence for Auditors |
How do we reduce exposure before patches are ready? | Shorter vulnerability window; lower breach risk | Virtual Patching | Virtual patch records with CVE-to-rule mapping |
How do we prove controls are working? | Faster audits; defensible evidence | Dashboards, 180-day logs (Lic. item 4), VA reports (Lic. item 3), incident reports | Dashboard exports, SIEM confirmation, assessment reports |
How do we stay up during an attack? | Higher uptime; lower revenue impact | L7 DDoS + AI/ML automated blocking (Lic. item 1), rate limiting, multi-DC, GSLB, 99% SLA (SD p.15) | DDoS mitigation reports, SLA performance records |
How do we catch unknown threats? | Reduced dwell time | AI/ML behavioural + signature-based detection, threat intelligence (Lic. item 1) | Detection logs, threat intel integration records |
How do we contribute to CERT-In log-retention readiness? | Contribution toward regulatory readiness | 180-day WAF log storage (Lic. item 4), SIEM forwarding via Logging API | Log archives, SIEM ingestion confirmation |
How do we hold the vendor accountable? | Clear ownership; enforceable SLA | RACI matrix (SD p.9), 99% SLA (SD p.15), service extension credits | SLA reports, RACI, change notification records |
How fast can we respond? | Faster containment; documented trail | Automated blocking, Platinum support (Lic. item 7) | Block logs, incident reports, ticket records |
Which apps are most exposed? | Risk-informed prioritisation | 12 VA/app/year (Lic. item 3), severity dashboards | Assessment reports, dashboard exports |
In Practice: Evidence That Changes the Audit Experience
Across customer engagements, a consistent pattern emerges: organisations that deploy SiteWALL arrive at regulatory assessments materially better prepared than before — not because the WAF blocked more attacks, but because it produced the evidence auditors actually ask for.
The typical before-state is familiar: controls exist, but the evidence trail does not. WAF logs are scattered or inaccessible, vulnerability tracking is manual, and assembling a control-effectiveness narrative for a GRC or regulatory review consumes significant time from security and compliance teams that have no margin to spare.
After deployment, the same teams can present 180-day log archives forwarded to their SIEM , scheduled vulnerability assessment reports with severity breakdowns, executive dashboards showing attack trends and mitigation actions, Platinum support incident monitoring records, and a documented RACI matrix with controls mapped to NIST CSF 2.0 subcategories — all from a single deployment.
The audit preparation effort drops significantly. More importantly, the nature of the effort changes: from assembling scattered evidence under pressure to presenting a pre-existing, continuously maintained evidence trail. That shift — from reactive scramble to documented readiness — is what SiteWALL is designed to enable.
The value is not that SiteWALL blocked more attacks. It is that the organisation can finally prove it did. |
Where No WAF Is the Answer
Several CSF 2.0 outcomes for application security sit outside what any WAF, SiteWALL or otherwise, can deliver. An honest assessment of these boundaries is more useful than a vendor that overclaims:
Governance, policies, and training - remain the customer's responsibility. SiteWALL contributes supplier governance evidence through the RACI matrix and SLA, but the security programme, risk appetite, and awareness training are organisational outcomes that no tool can provide.
Patching applications and infrastructure - is still required. Virtual Patching reduces the exposure window between vulnerability disclosure and code fix; it does not eliminate the need for a disciplined patch management programme.
Full incident response programmes - IR plans, tabletop exercises, post-incident reviews, legal protocols — extend beyond any tool. SiteWALL contributes detection, automated containment, and evidence preservation. The broader IR capability is yours to build and exercise.
Business continuity and disaster recovery - for databases, application servers, and business processes sit with your BCP/DR programme. SiteWALL's multi-data-centre redundancy protects the WAF service itself, not the customer's application stack.
Application-level identity and authentication - SSO, MFA, identity governance — sit outside the WAF's scope. SiteWALL enforces perimeter access rules (geo-blocking, IP lists, port restrictions), but application identity is a different control domain entirely.
Any vendor that claims their WAF solves your entire compliance challenge is a vendor you should question. Honest scoping of responsibilities — documented in a RACI matrix — is a sign of maturity. |
Context: Data Residency, PCI DSS, and What's Ahead
Data residency and sovereignty
For organisations operating under Indian regulatory expectations — including RBI, SEBI, IRDAI, and CERT-In-aligned environments — data residency and jurisdictional control over logs, traffic processing, and incident data are increasingly important governance considerations. SiteWALL is architected entirely within Indian data centres, which means customer web traffic is inspected, processed, and logged without leaving Indian infrastructure. This architecture supports data sovereignty obligations by design, not as an optional configuration or a regional add-on that depends on tier or plan selection. Organisations evaluating any WAF provider — domestic or global — should ask specifically: under your standard subscription, is all traffic processing, log storage, and incident data retention guaranteed to remain within Indian jurisdiction? The answer determines whether data residency is contractually assured or only positioned as a marketing claim.
PCI DSS
PCI DSS v4.0.1 Requirement 6.4.2 requires an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks. A WAF is the most common approach to satisfying this requirement. The same SiteWALL capabilities that address requirements 3, 4, 7, and 8 in this article — application-layer attack prevention, continuous monitoring, logging, and incident reporting — contribute directly to PCI DSS readiness. One deployment, two frameworks, less duplication.
CERT-In
CERT-In requires logs of all ICT systems to be enabled and retained securely for a rolling 180 days within Indian jurisdiction. SiteWALL's licence includes 180 days of WAF log storage for all applications, aligned with CERT-In guidelines. WAF logs alone do not satisfy the full CERT-In logging requirement. Organisations must also retain logs from firewalls, DNS servers, mail servers, endpoints, and other ICT systems. SiteWALL's Logging API facilitates forwarding WAF logs to the customer's centralised log management system to support a comprehensive retention programme.
Security certifications
PageNTRA engages directly with customers on their specific audit framework requirements. Organisations with SOC 2 or ISO 27001 obligations should contact contact@pagentra.com to discuss applicable documentation and security assurance materials.
Evolving threats
Attack techniques are evolving rapidly — adversaries are leveraging automation to scale application-layer attacks, API abuse is outpacing traditional web attacks, and bot campaigns are increasingly sophisticated at evading conventional defences. CERT-In's reporting timelines have compressed and RBI's cybersecurity frameworks are becoming more prescriptive. Organisations that demonstrate a strong, evidence-producing control layer today will be better positioned as these requirements tighten.
Six Questions Every Board Should Ask About Their WAF
Whether you evaluate SiteWALL or any other WAF, these questions separate a mature security investment from an expensive checkbox:
- Can it prove what it blocked and what it allowed?
Dashboards and claims are different things. Ask for exportable logs, incident reports, and evidence artefacts — not just a summary screen.
- How long are logs retained, and can they reach our SIEM?
180 days is the CERT-In baseline for WAF logs, but your organisation's overall logging obligation extends well beyond the WAF. Ensure the WAF's logs are exportable and correlatable.
- Can it show which applications are most exposed?
Blocking attacks is table stakes. Prioritising remediation based on vulnerability severity and attack frequency is the real value.
- How fast does it adapt to new threats?
Virtual patching speed, signature update cadence, and threat intelligence integration matter more than feature lists. Ask about the process, the team, and the cadence — not just the capability.
- Does it feed our incident response workflow?
A WAF that blocks but doesn't alert, report, or integrate with your SIEM creates a dangerous visibility gap. Containment without documentation is a liability.
- What is still our responsibility?
If the vendor cannot clearly answer this with a documented RACI matrix, they're not ready for an enterprise relationship. The best vendors make the shared responsibility boundary explicit.
SiteWALL is designed to answer each of these questions with documented capabilities and auditable evidence. PageNTRA maintains a living NIST CSF 2.0 mapping for SiteWALL; request the latest version at contact@pagentra.com. Request the SiteWALL NIST CSF 2.0 Mapping Workbook, RACI Matrix, and Evidence Pack from contact@pagentra.com. NIST CSF 2.0 defines the outcomes. SiteWALL helps produce the evidence. |
Appendix: Complete SiteWALL-to-CSF 2.0 Capability Mapping
How to read this mapping. NIST CSF 2.0 defines outcomes, not products. No single tool satisfies the framework. This appendix maps every SiteWALL capability to its corresponding CSF 2.0 subcategory outcome. Mapping reviewed quarterly; next scheduled review: July 2026. Material CSF 2.0 errata or SiteWALL capability changes trigger out-of-cycle updates. "Directly Supports" means the capability produces the outcome the subcategory describes for web application traffic. "Materially Contributes" means it meaningfully supports a broader outcome the customer ultimately owns. The Customer Responsibility column explains what remains the customer’s obligation. Final determinations depend on implementation context and assessor judgment. NIST publishes Implementation Examples for each subcategory as informative, non-normative guidance updated independently of the core framework. This mapping aligns to subcategory outcome statements rather than specific Implementation Examples; readers seeking example-level alignment for a particular subcategory should request the supplementary mapping workbook from contact@pagentra.com. |
SiteWALL Capability | CSF 2.0 | Strength | How SiteWALL Addresses It | Customer Responsibility & Evidence |
IDENTIFY — 9 capability-to-subcategory pairings | 7 unique subcategories | ||||
Vulnerability Assessment (12/app/year) | ID.RA-01 | Directly Supports | 12 scheduled VAs per app/year with severity breakdowns (H/M/L). | Customer must also assess non-web assets and remediate findings in code. Evidence: VA reports |
Vulnerability Management & Tracking | ID.RA-01 | Directly Supports | Maintains and tracks vulnerabilities; transparent view of security posture over time. | Customer must track vulnerabilities across all other asset classes. Evidence: Vulnerability status dashboard |
Third-Party Threat Intelligence | ID.RA-02 | Directly Supports | Integrates with third-party threat intel services to enhance detection. | Customer must consume threat intel for non-web vectors. Evidence: Feed config records |
Application-Centric Threat Intel + Attack Feed | ID.RA-03 | Directly Supports | Proprietary threat intel with attack feed on active campaigns targeting web apps. | Internal threats and non-web vectors require separate detection. Evidence: Attack feed records, advisories |
Customer Advisories on Emerging Threats | ID.RA-03 | Materially Contributes | PageNTRA issues advisories on significant security updates and emergent threats. | Advisories inform but do not execute response. Customer must assess impact and act. Evidence: Advisory emails |
Dashboard Severity View + Automated Virtual Patching | ID.RA-05 | Directly Supports | Dashboard shows vulnerability severity alongside attack trends; virtual patch auto-shields identified vulnerabilities. | Customer must integrate WAF risk data into enterprise risk register. Evidence: Dashboard exports, VP records with CVE mapping |
Per-FQDN Licensing + Applications View | ID.AM-02 | Directly Supports | Per-FQDN licensing creates explicit, auditable inventory of protected web applications. | Covers only WAF-onboarded apps. Customer must inventory ALL applications. Evidence: Licence records, dashboard count |
Per-Application Policy Customisation | ID.AM-05 | Materially Contributes | Different protection profiles per application based on business criticality. | SiteWALL enables differentiation but customer defines classification criteria. Evidence: Policy exports |
VA Findings Drive Remediation | ID.IM-02 | Materially Contributes | VA findings with severity breakdowns inform remediation priorities. | One input to improvement. Customer must also incorporate lessons from incidents, exercises, audits. Evidence: Assessment reports |
PROTECT — 20 capability-to-subcategory pairings | 8 unique subcategories | ||||
WAF Inline Block Mode (Signature + AI/ML Behavioural) | PR.IR-01 | Directly Supports | OWASP Top 10, signature engines for known threats, AI/ML behavioural analysis for unknown threats — inline block mode from day one. | Protects web traffic only. Network-level controls are customer responsibility. Evidence: Policy exports, block logs |
Automated Virtual Patching | PR.IR-01 | Directly Supports | Blocks exploit path at application edge while dev teams prepare permanent fixes. | Does not fix the vulnerability. Customer must remediate through code patches. Evidence: VP records with CVE, date, duration |
API Protection | PR.IR-01 | Directly Supports | Secures APIs: blocks unauthorised access, identifies vulnerabilities, filters harmful traffic. | API design security, auth schemes, authorisation logic remain customer responsibility. Evidence: API policy config, block logs |
Geolocation Blocking (Geo Rules) | PR.IR-01 | Directly Supports | Enforces geographic access boundaries at the application perimeter. | Customer defines which geographies to block/allow. Evidence: Geo-rule config exports |
IP Whitelist/Blacklist | PR.IR-01 | Directly Supports | Enforces IP-based access control at the application edge. | Customer maintains accurate IP lists. Evidence: Config exports |
Custom Port Support | PR.IR-01 | Directly Supports | Restricts access to specific ports, reducing attack surface. | Customer defines required ports. Evidence: Port config records |
Custom Rules (HTTP headers, payloads, params) | PR.IR-01 | Directly Supports | Custom rules based on HTTP headers, payloads, and request parameters per customer. | Customer defines application-specific requirements. Evidence: Custom rule exports |
Multi-DC Infrastructure + Redundancy | PR.IR-03 | Directly Supports | Multiple data centres in India with built-in redundancy and HA architecture. (SD, How It Works, p.7) | WAF service resilience only. App-stack DR is customer responsibility. Evidence: Architecture docs |
GSLB + Load Balancing | PR.IR-03 | Directly Supports | Global Server LB and Link/Network LB ensure traffic distribution and failover. | Application-level LB within customer infra is separate. Evidence: LB config, failover records |
Dedicated Load Balancers + Traffic Shaping | PR.IR-03 | Directly Supports | Dedicated LBs and traffic shaping for consistent performance under load. | Customer handles capacity planning for own infrastructure. Evidence: Config, performance reports |
99% Uptime SLA | PR.IR-03 | Directly Supports | Contractual 99% uptime with service extension credits (1/365th per outage day). (SD, Service Availability, p.15) Note: The 99% SLA reflects measured service availability inclusive of scheduled maintenance windows. Cumulative credits and historical performance are reported to customers on request. | Covers WAF service only. Customer's own app uptime requires separate commitments. Evidence: SLA reports |
L7 DDoS Protection + AI/ML Rate Limiting | PR.IR-04 | Directly Supports | Automated L7 DDoS protection with AI/ML automated blocking and rate limiting. | L3/L4 DDoS and app capacity planning remain customer responsibility. Evidence: DDoS reports, rate config |
Web-shell Detection | PR.PS-05 | Directly Supports | Identifies and blocks web-shell attacks preventing unauthorised remote access. | Server hardening and endpoint protection beyond WAF scope are customer responsibility. Evidence: Detection logs |
Malware Scanning (Traffic + Server + Uploads) | PR.PS-05 | Directly Supports | Scans inbound/outbound traffic and server files for malware; file upload protection. | Endpoint/email malware controls remain customer responsibility. Evidence: Scan logs, blocked file records |
Continuous Signature Updates | PR.PS-02 | Directly Supports | Engineers continually refine signatures from research, threat intel, and attack analysis. (SD, Proactive Threat Management, p.11) | App patching, OS updates, library maintenance are customer responsibility. Evidence: Signature history |
Scheduled Version Updates (Change Mgmt) | PR.PS-01 | Directly Supports | Major/minor updates via defined change process (monthly, Wed 00:00–04:00 IST). (SD, Scheduled Maintenance, p.14) | App config management and customer infra changes are separate. Evidence: Change tickets, version history |
WAF Policy Management | PR.PS-01 | Directly Supports | PageNTRA builds, implements, maintains, and customises WAF policies per application. (SD, Roles & Responsibilities, p.8) | Customer provides accurate app/infra details and validates tuning. Evidence: Policy exports, change records |
Automated & Precision Tuning | PR.PS-01 | Directly Supports | Automates signature tuning balancing security with false-positive minimisation. | Customer reports FPs and validates outcomes. Evidence: Tuning records, FP reduction reports |
SSL Certificate Management | PR.DS-02 | Materially Contributes | SiteWALL terminates TLS at the WAF edge, decrypts inbound traffic for deep inspection, and re-encrypts to origin — enforcing HTTPS redirection and ensuring encrypted data in transit is inspected, not just passed through. Certificate lifecycle management is included for all WAF-fronted FQDNs. | WAF-proxied traffic only. E2E encryption and non-WAF cert lifecycle are customer responsibility. Evidence: SSL config records |
RBAC on Management Console | PR.AA-01 | Directly Supports | Role-based access control ensures least-privilege access to WAF administration. | App-level IAM (SSO, MFA, identity governance) is entirely separate. Evidence: Console access config |
DETECT — 10 capability-to-subcategory pairings | 9 unique subcategories | ||||
Continuous Traffic Monitoring | DE.CM-01 | Directly Supports | Continuous threat analysis on web traffic. | Non-web network traffic, endpoints, internal networks remain customer responsibility. Evidence: Dashboard reports, logs |
Backend Health Monitoring | DE.CM-09 | Materially Contributes | Continuous backend health and availability monitoring through the WAF. | Monitors from WAF perspective only. Full APM and infra monitoring need additional tools. Evidence: Health reports |
AI/ML Bot Detection (Behavioural + Signature) | DE.AE-02 | Directly Supports | AI/ML behavioural analysis and signature-based detection for anomalous requests, bots, and known patterns. | Non-web bot detection requires separate controls. Evidence: Bot detection logs, analyser reports |
Signature-less AI/ML Behavioural Engine | DE.AE-02 | Directly Supports | Advanced AI/ML engine for unknown threats through behavioural analysis beyond known signatures. | Broader anomaly correlation (UBA, insider threats) remains customer responsibility. Evidence: Behavioural logs |
SIEM Integration via Logging API | DE.AE-03 | Directly Supports | Real-time WAF violation data to external SIEM for centralised correlation. (SD, System Logs Integration, p.14) | SIEM admin, correlation rules, non-WAF log ingestion are customer responsibility. Evidence: SIEM forwarding confirmation |
Dashboard Drill-Down (Paths, Sources, IPs) | DE.AE-04 | Directly Supports | Custom drill-down: Attack Paths, Top Sources, Countries, IPs for scope/impact analysis. | Enterprise-wide impact assessment beyond web apps requires broader investigation. Evidence: Dashboard exports |
Threat Incident Reporting + Alerting | DE.AE-06 | Directly Supports | Reporting and email alerting ensure findings reach designated personnel. | Internal escalation for non-WAF events remains customer responsibility. Evidence: Alert records, reports |
Integrated Threat Intelligence (Detection) | DE.AE-07 | Directly Supports | Third-party + SiteWALL application-centric intel integrated into detection analysis. | Threat intel for non-web vectors is customer responsibility. Evidence: Threat intel integration records |
Incident Monitoring Service (Platinum) | DE.AE-08 | Directly Supports | Formalises incident declaration when adverse events meet defined criteria. | Org-wide incident criteria and declaration processes are customer responsibility. Evidence: Declaration records |
DE.CM-06 — Customer Obligation (SiteWALL enables evidence) | DE.CM-06 | Materially Contributes | DE.CM-06 requires the customer to monitor its external service providers. SiteWALL produces the notification records and policy observation logs the customer needs as evidence to demonstrate active supplier oversight. The monitoring obligation itself — the programme, cadence, and governance — remains with the customer. | Customer must establish and operate the supplier monitoring programme. SiteWALL provides the evidence trail; the customer owns the monitoring obligation. Evidence: Notification records, policy observation logs, supplier review documentation |
RESPOND — 9 capability-to-subcategory pairings | 9 unique subcategories | ||||
Inline Block Mode (Containment) | RS.MI-01 | Directly Supports | Automated inline blocking delivers containment in real-time without analyst intervention. | Containment of non-web incidents remains customer responsibility. Evidence: Block logs with timestamps, IPs, rules |
Virtual Patching + Rule Tuning | RS.MI-02 | Materially Contributes | VP neutralises exploits; rule tuning closes recurring patterns. | Blocks exploit path but does not eradicate root cause. Full eradication requires customer remediation. Evidence: VP records, tuning logs |
Support Ticket Workflow (IR) | RS.MA-01 | Materially Contributes | Documented workflow for coordinated incident response with PageNTRA. | One component of IR. Customer must maintain full IR plan, exercises, legal/comms. Evidence: Ticket records |
Incident Triage by PageNTRA | RS.MA-02 | Directly Supports | Engineers investigate root cause and determine best course of action on support requests. | Covers WAF incidents. Enterprise-wide triage requires broader capability. Evidence: Investigation reports, RCA |
Ticket Priority Framework | RS.MA-03 | Directly Supports | Incidents categorised and prioritised according to defined severity framework. | Enterprise incident categorisation policies are customer responsibility. Evidence: Priority records |
Dashboard Root-Cause Analysis | RS.AN-03 | Directly Supports | Drill-down analysis enables investigation of specific attacks with detailed information. | Forensic analysis of app servers, databases, infra requires additional tools. Evidence: Dashboard exports |
180-Day WAF Log Retention | RS.AN-06 | Directly Supports | 180 days of WAF log storage preserves evidence for investigation and regulatory inquiry. | WAF logs only. CERT-In requires logs from ALL ICT systems. Customer must ensure comprehensive retention. Evidence: Log archives |
Real-Time Export via Logging API | RS.AN-07 | Materially Contributes | Secure real-time export of WAF violation data to external systems, supporting evidence preservation and forensic analysis by the customer's security and investigation teams. (SD, System Logs Integration, p.14) | Forensic analysis itself, and preservation of non-WAF incident data, are customer responsibility. Evidence: API config, data flow docs |
Customer Advisories & Threat Alerts | RS.CO-02 | Materially Contributes | PageNTRA issues advisories on significant events and required actions. | Does not substitute for customer's incident comms plan. Regulatory notifications are customer responsibility. Evidence: Advisory records |
GOVERN — 6 capability-to-subcategory pairings | 5 unique subcategories | ||||
Responsibilities Matrix (RACI) | GV.RR-02 | Directly Supports | Documented RACI: implementation, monitoring, maintenance, access, and incident management. (SD, Responsibilities Matrix, p.9) | Covers PageNTRA relationship only. Org-wide cybersecurity roles are customer responsibility. Evidence: RACI matrix |
Service Description + Licence Agreement | GV.SC-05 | Directly Supports | Contractual requirements defined in Service Description, Licence, SLA, and subscription agreement. | Covers WAF vendor only. Customer must establish requirements for ALL third-party vendors. Evidence: Signed contracts |
SLA + Credits + Change Notifications | GV.SC-07 | Directly Supports | 99% SLA (SD p.15), service extension credits, maintenance windows, and change notification protocol (SD p.14). | Covers WAF vendor monitoring only. Customer must monitor all suppliers. Evidence: SLA reports, notifications |
PageNTRA Proactive Policy Monitoring & Notifications | GV.SC-07 | Directly Supports | PageNTRA proactively monitors customer WAF policies and notifies customers of significant observations, producing the supplier-monitoring artifacts (notification records, policy observation logs) that the customer needs to demonstrate active vendor oversight under GV.SC-07. | Covers SiteWALL-side service delivery only. Customer must define the supplier oversight programme, cadence, and review governance into which these artifacts feed. Evidence: Notification records, policy observation logs |
Multi-DC Redundancy (WAF Continuity) | GV.SC-04 | Materially Contributes | Multi-DC architecture across Indian data centres provides built-in supplier resilience — SiteWALL’s WAF service recovers automatically from infrastructure failures without customer intervention. (SD, How It Works, p.7) Note: Recovery of customer applications, data, and business processes sits with the customer’s BCP/DR programme, not the WAF service. | WAF service only. Recovery plans for applications, databases, and business processes are entirely customer responsibility. Evidence: Architecture docs, failover records |
PCI DSS + CERT-In Alignment | GV.OC-03 | Materially Contributes | 180-day WAF logs toward CERT-In (Lic. item 4); capabilities toward PCI DSS v4.0.1 Req 6.4.2. | WAF logs do NOT satisfy full CERT-In obligation (all ICT systems). PCI needs controls well beyond WAF. Evidence: Compliance docs, log archive |
RECOVER — 1 capability-to-subcategory pairing | 1 unique subcategory | ||||
Customer Notifications (Recovery Comms) | RC.CO-03 | Materially Contributes | Notification processes during incidents and maintenance communicate recovery progress. | WAF service comms only. All other recovery communications to stakeholders, regulators, public are customer responsibility. Evidence: Notification records |
Coverage Summary
CSF 2.0 Function | Directly Supports | Materially Contributes | Total Pairings | Unique Subcategories |
IDENTIFY | 6 | 3 | 9 | 7 |
PROTECT | 19 | 1 | 20 | 8 |
DETECT | 8 | 2 | 10 | 9 |
RESPOND | 5 | 4 | 9 | 9 |
GOVERN | 4 | 2 | 6 | 5 |
RECOVER | 0 | 1 | 1 | 1 |
TOTAL | 42 | 13 | 55 | 39 |
The appendix contains 55 capability-to-subcategory pairings across 39 unique CSF 2.0 subcategories. Where multiple capabilities address the same subcategory — for example, seven capabilities contribute to PR.IR-01 — each pairing is counted separately. The unique subcategory count reflects how many distinct CSF 2.0 outcomes SiteWALL addresses, regardless of how many capabilities contribute to each. SiteWALL directly supports 42 and materially contributes to 13 of the 55 pairings, across all six CSF 2.0 Functions. This mapping is reviewed quarterly; next scheduled review: July 2026. Material CSF 2.0 errata or SiteWALL capability changes trigger out-of-cycle updates. |
What is Not in This Mapping
Honest scoping requires saying not just what is mapped, but what is deliberately not. The CSF 2.0 areas below are outside the realistic scope of any web application firewall, including SiteWALL. Listing them is not a gap — it is a scoping decision. Customers should expect to evidence these outcomes through other controls in their security programme.
Organisational Context (most of GV.OC). Mission, stakeholder expectations, and legal/regulatory environment definition are organisational outcomes. SiteWALL contributes only GV.OC-03 alignment evidence for PCI DSS and CERT-In log retention.
Risk Management Strategy (GV.RM). Risk appetite, tolerance, and enterprise risk strategy are board- and executive-level outcomes that no security tool produces.
Cybersecurity Awareness and Training (PR.AT). User and specialised role training programmes sit entirely with the customer. SiteWALL produces evidence assessors can use during training, but does not deliver the training.
Data Security beyond TLS in transit (most of PR.DS). Data-at-rest encryption, key management, data classification, and data lifecycle controls are infrastructure and application-layer obligations. SiteWALL addresses PR.DS-02 (data in transit) only, for WAF-fronted traffic.
Identity and Access Management beyond perimeter and console (most of PR.AA). SSO, MFA, identity governance, credential management, and authentication assurance levels for application users sit outside WAF scope. SiteWALL addresses PR.AA-01 only for WAF console access.
Recovery Planning and Execution (most of RC). Recovery plan execution, backup integrity verification, and restoration of normal operations for customer applications, databases, and business processes sit with the customer’s BCP/DR programme. SiteWALL addresses RC.CO-03 (recovery communications) for the WAF service only.
Physical Security and Asset Disposal (PR.AA-06, ID.AM-08). Physical access controls and secure asset disposal are facilities and procurement obligations outside any WAF’s scope.
About PageNTRA Infosec - SiteWALL
SiteWALL is a SaaS-delivered Web Application Firewall from PageNTRA Infosec Pvt. Ltd., Mumbai. Deployed across multiple Indian data centres, every licence includes Platinum support, 12 vulnerability assessments per application per year, and 180 days of log storage as standard. Learn more at www.sitewall.net or write to contact@pagentra.com.
This article references NIST Cybersecurity Framework 2.0 (February 26, 2024), comprising 6 Functions, 22 Categories, and 106 Subcategories. The ten operational requirements presented are PageNTRA's practitioner-level interpretation of CSF 2.0 outcomes for internet-facing web applications, not a mandatory NIST checklist. SiteWALL directly supports some outcomes and materially contributes to others; final compliance determinations depend on implementation context, organisational scope, and assessor judgment. Document v1.5, May 2026. PageNTRA Infosec Pvt. Ltd. |
