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. |