WAF Deployment proposal
0 likes99 views
The document outlines the necessity for deploying a Web Application Firewall (WAF) due to the current lack of protection against web-based attacks on the organization's applications. It details a comprehensive project plan for the WAF implementation, highlighting phases such as application discovery, proof of concept, global deployment, and security policy formulation. The project's expected outcome is a significant reduction in security risks through enhanced threat protection, logging, and monitoring capabilities for all external-facing web services.
WAF Deployment proposal
- 1. Web Application Firewall (WAF) Deployment Jeremy Quadri Feb 2016 There is a need for enhanced layered web security to prevent malicious web attacks attempts from sailing through the first defence in the network firewalls, tactical filters without notice because the attacks are buried within valid HTTP requests.
- 2. 2 Background Currently your web server estate is not protected from web based attacks, thus, there is zero level of threat detection and subsequent blocking of bad actors. • There is no Web Application Firewall (WAF) to protect the applications. • A complete review needs to be undertaken in conjunction with Infrastructure team to determine an appropriate solution to align with industry best practices and the merging of the on-premise and Cloud WAF requirement, which should result in a requirement to implement a global centralized WAF solution. • As such a funding application will be made to procurement to implement a centralised WAF solution to terminate and inspect all inbound and outbound HTTP traffic. • A Four-layer defence (WAF + SAST+DAST+Pentesting) will address any increasing number of threats Project Scope Scope of the WAF Implementation covers effort associated Design, Build/Test and Execution of a global on-premise and Cloud WAF capability. Planning assumption is a global inline implementation, with the phased on-boarding of Internet facing Application Services. This will address PCI DSS requirement 6.6. This will involve: •The completion of a Proof of Concept for at least a couple approved WAF solution to validate functional capability and prove design and implementation assumptions. •Application discovery / testing and remediation where required. •The global implementation of the Web Application Firewall will provide the capability for securing the application for staging and production environments. •The integration of a central logging management to permit application owners to review security alerts and make corrections. It is expected that the WAF project will take approximate 6-8 months to complete, resulting in the Risk reduction to Marginal. Further work will be required by the Application Development teams & Information Security team to close the Risk completely.
- 3. 3 Proposed Reference Architecture-WAF Placement The connection from the client is SSL terminated at the Load Balancer. The WAF module has never configured to block illegal traffic and is now turn-off completely. Though the WAF functionality is paid for, it is not used. The LB makes all load balancing decisions. The load balancer sends its certificate to the browser 1. The Browser initiates a connection to the Load Balancer. 2. Client browser checks it is issued by a trusted CA The client encrypted data will be terminated, and decrypted at the WAF. The WAFs checks the traffic for protocol violation & vulnerabilities then sends it to the load balancer without re-encryption to get the best performance All user connection to the infrastructure is SSL terminated at the WAF. The LB/ELB checks the availability of the backend webserver associated with each request, prior to load balancing traffic across the actual web server.
- 4. 4 High Level Project / Implementation Approach Delivery Phase Description EndDate Application Discovery Identification and verification of all external facing application. Proof of Concept Evaluate the functional capability of the WAF appliance covering: •Business Requirement Document •Architecture Definition document •Setup & Configuration •Functional capability •Security policy management •Scalability •Performance •Operability •Resilience Procurement & POC validation • Global Procurement of agreed WAF platform with direct regional & Cloud deployment. • Engineering and build standards validation. Global Build and Deployment • Global Build of Staging and Production infrastructure using the previously defined Engineering patterns and standards Staging Application on-boarding and testing • Modify on Premise and Cloud Load Balancers to redirect all Applications via the WAF and validate application functionality and Penetration testing. Production Application on-boarding & Testing • Modify on Premise and Cloud Load Balancers to redirect all Applications via the WAF and validate application functionality.
- 5. 5 High Level Project Timeline Activities Period Apr May Jun Jul Aug Sep Oct Nov Governance & Application Discovery 10 days Infrastructure Build/ Deploy & Config Proof of Concept 40 days Procurement & POC Validation 40 days Staging WAF Deployment 60 days Production WAF Deployment Application on-boarding Planning 30 days Staging Application Migration 60 days Production Migration 40 days Regression Testing & Pentesting 60 days Project Closure Planning the Application migration to the WAF Infrastructure Team Activity InfoSec activity Global delivery / cloud /WAF module build and configure UAT & production Validating the functional aspects of the WAF and validating application functionality Joint team support AppDev team activity Joint Team activity
- 6. 6 WAF Benefit & FAQ The delivery of the project will result in the following benefits: 1. Implementation of the following security principles: a. External Internet Traffic will be terminated inspected and validated within a the first zone of the multi-cloud prior to onward transmission to the Internal APIs. b. Monitor all website traffic and send logs for application exceptions and abnormal traffic behaviour/patterns to Splunk c. Deployment of a enhanced ‘reverse proxy’ solution that will allow application/business presentation logic to reside in the external AWS rather than internally. 2. Enhanced Threat Protection for all external facing Web Application/Services 3. Enhanced log analysis and monitoring for all Web Application/Services 4. Implementation of ‘Threat Radar’ services to ensure the protection capability is maintained and up-to-date in line with the ever evolving threat landscape to mitigate future vulnerabilities. FAQ Will the delivery of WAF completely remove the risk from attacks? No. The risk will be significantly reduced, as a scalable, manageable WAF solution will have been provided. There is then a further phase required where the application teams together with Information Security work to further test the applications and apply more granular security policies per application. This will need to be funded later in the project. Who decided this was the best solution? Given the change in the threat landscape, this Risk was reviewed by the security team. It was then assessed and agreed that the security policy should be adhered too, hence the introduction of a Cloud based Application Firewall. What Application traffic will go via the WAF Cloud? The current assumption is that all web traffic will go via the WAF Cloud. Will the Application(s) break? The current working assumption is No. The WAF appliances are able to run in a variety of modes. Once the application is on-boarded into staging and simulation mode is activated, this will help determine if any application remediation is required. What will the default policy rule set be at the point of go-live? The working assumption is that a basic WAF rule will be set and further increased to attain a tighter security policy. Will the new WAF solution introduce additional Application / Network latency? The complete impact of the introduction of the WAF is unclear at this stage. Confirm as to the latency impact for the introduction of the WAF will be better understood post the installation stage.
- 7. 7 Proposed WAF Security Policy: Phase-1 The WAF MUST be tuned NOT to deny legitimate web request. Enforcement of Baseline security Policy for rapid application deployment Tightening of the Baseline security The negative security model violations categories are: 1. RFC violations 2. Access violations 3. Length violations 4. Input violations 5. Cookie violations 6. Negative security violations such as blocking of XSS, SQL injection attacks The WAF MUST allow request with HEAD, POST & GET methods, all other Methods MUST be blocked. The WAF MUST Generate alerts on violation and send violation log events to Splunk The WAF may prevent CSRF attacks The WAF should prevent Phishing attacks HTTP Timeout Considerations: The WAFs timeout value should be a higher value than the timeout set on the backend web apps. If the HTTP request does not comply with the defined security policy, a violation must be triggered and logged to Splunk. The WAF MUST send a customized generic blocking response page to the user, which advises the user that the request was blocked and provides the user with a unique support ID number for the violating event. The customised page will be designed and agreed by the stakeholders The WAF MUST be able to detect and block scanning attacks from automatic scanning commercial or Free tools from attacker, these tools by default generate a large amount of non-existent URL’s or query string, and signature violations. Exception: Vulnerability scanner is deployed to scan the web estate, Vulnerability scanner system’s ip addresses will be whitelisted on the WAF, to enable internal scanning of the infrastructure. The WAF MUST preserve the User IP-Address within the HTTP request through to the backend, by replacing the source IP variable header with X-Forwarded-For variable.
- 8. 8 WAF Certificate & Key Management Configuration As a baseline, this WAF project will use negative security model by applying the policy rules and patterns that identify common attacks on web applications. These attack signatures can be quickly applied to request and responses. On top of that high priority qualys scan results can be imported to form an additional part policy. It proposed that the learning mode be turned on during regression testing for each signature in order to evaluate and act on learning suggestions by the WAF in UAT and production. The WAF MUST support High Encryption ciphers for SSL traffic: AES256-SHA256 WAF MUST use valid certificate for external facing sites. The WAF certificate MUST support Strong SSL Protocol -all +TLSv1.1 (1.2 is recommended) or above . The WAF MUST use sufficient key length at least 2048 bit. Generate the WAF’s private keys and Certificate Signing Requests (CSRs) on the WAF. For best practise on certificate and key management refer to https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
- 9. 9 Appendix Injection Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data. Cross Sign Scripting (XSS) XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. Broken Authentication and Session Management Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities. Insecure Direct Session Objects A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data. Cross Sire Request Forgery (CSRF) A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. Security Mis-configuration Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application. Insecure Cryptographic storage Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes. Failure to Restrict URL Access Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway. Insufficient Transport Layer Protection Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly. Un-validated Redirects and Forwards Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access Below are the top 10 known Industry recognised application vulnerabilities