Development teams play a critical role in the security of internet-facing applications. While bad actors are the most significant threat these teams encounter, they also face internal challenges with implementing security fixes while balancing functional and non-functional requirements across the business, engineering, and security realms. The increasing velocity at which development teams can release code, thanks to CI/CD automation, also highlights the critical importance of fully integrating security processes and tools in the development and release cycle process. Here are five security questions that will improve awareness of your application security needs and reduce the risk of a web application security event impacting your business.
Dynamic (DAST), static (SAST), and interactive application security testing tools help find vulnerabilities in a web application. The DAST and SAST tools help find runtime weaknesses in different ways. DAST attempts to perform attacks (e.g., cross-site scripting) on the web application while SAST tools look for insecure practices in the source code (e.g., uninitialized variables). Using both in a continuous integration/continuous deployment (CI/CD) pipeline helps find flaws as part of the devsecops process before they ever reach production.
Some source control repositories can integrate with a CI practice to run security scans with each change. The repository may require that the CI practice perform SAST as part of every change request. If the scans report security findings, the repository may prevent approval of the change request. Teams that perform these scans manually or automatically can significantly reduce their security risk. Similarly, the CD can include a DAST scan during the deployment of new code.
Software Composition Analysis (SCA) tools can also be used to scan and identify vulnerabilities in open-source or third-party libraries so that problems can be remediated. As composable or progressive web apps leveraging microservices and APIs have become more common, having adequate protections for APIs is just as critical. This includes checkpoints for API discovery, JSON schema validation, and ensuring that the integrity of property types and property values cannot be compromised by an attacker. Leveraging an API Gateway solution to prevent unauthorized access to APIs along with third-party script protection all play a role in preventing malicious activity and Magecart-style supply chain attacks.
Scans may produce many results. It takes time to assess and prioritize them all, even with the help of a vulnerability management system. Web application and API protection (WAAP) enables you to take immediate action to mitigate the vulnerabilities while your team prioritizes and applies fixes.
Additionally, running a DAST scan against a web app or API protected by a WAAP can improve the app’s overall security posture. Any attacks the WAAP fails to stop can be identified by the security team for further fine-tuning. If the rules included with a WAAP fail to mitigate a finding from the DAST scan, a custom WAAP rule can be written and deployed to address the specific finding. The team no longer needs to wait for a security patch or an imminent attack to mitigate these threats.
Modern web application technology stacks consist of many components, such as web and database servers and web development frameworks. Some of the components are extensible with a plug-in, extensions, and add-ons. Having an inventory of each third-party component and understanding and applying critical security patches should be part of every application security program. However, critical patches sometimes cannot be applied without changes to the application code requiring a development sprint.
Unpatched vulnerabilities in software and systems are an all-too-common attack vector for cybercriminals. According to IBM, in 2022 the average global cost of a data breach exceeded USD $4.35M and the time to fully address a breach is often measured in months. Software patching provides the organization more time to fix a known security vulnerability. Web applications teams should test and apply software patches regularly, such as monthly or whenever there’s a software release. Doing so reduces the time flaws exist and the amount of time an attacker has to exploit them. The longer the weaknesses remain, the greater the likelihood that malicious actors will exploit them.
A WAAP with a comprehensive set of application-specific security rules, more generic OWASP rules and flexible custom rules to address corner cases empowers development teams to apply an immediate fix (aka ‘virtual patching’) to prevent exploitation while giving breathing room to patch and update application code. Additionally, security teams should insist on WAAP solutions that automatically or easily block access to sensitive operating system files and paths.
Although running a WAAP in a staging or QA environment can give insight into whether a particular WAAP configuration will prevent an attack, there is no substitute for running the WAAP against live production web traffic. Learn how our Dual WAAP mode features enable security teams to test new WAAP rules on production traffic, giving teams the observability and controls needed to stop emerging threats and massively shrink response time.
Balancing server capacity and cloud costs is a tradeoff between customer experience and business needs. However, allocating server capacity to accommodate illegitimate users is not the best approach.
While there remains a threat of high-profile DDoS attacks from Advanced Persistent Threats (APT) such as Killnet which targeted Japanese government institutions and US airport websites in the summer and fall of 2022, it’s much more common to see attacks in the multi-Gbps range. According to NETSCOUT, one DDoS attack occurs every three seconds. Apart from only using bandwidth to measure a DDoS attack, request rates (i.e. requests per second (RPS) or million packets per second (Mpps)) are an equally important consideration in protecting application infrastructure. These security events from scanners or botnets hitting web applications may not make the news but may impact your customers’ experiences on your site.
Leveraging a cloud-based WAAP with fine-grained abilities to rate limit traffic and mitigate attacks to critical endpoints can filter out much of this undesirable traffic before it impacts your web application, preserving server capacity for actual users.
Depending on your industry and application type, your application may need to conform to industry regulations. If your site processes credit card payments, it likely must be PCI-compliant. Your company may need to adhere to SOC 2 compliance because of the sensitive nature of the data your application uses and retains. Many of these regulations require the use of a WAAP.
Even when no industry regulations are applicable, you might consider following industry best practices and guidelines. You can use the Center for Internet Security controls or the AWS Well-Architected Framework. Both recommend using a WAAP because it can inspect and filter malicious web traffic.
Applications built on older tech stacks should be updated or decommissioned. Many companies can no longer fix older application code if the tech stack isn’t maintained. Balancing security with business needs may require an interim solution. Running a comprehensive DAST scan and a carefully tuned WAAP with appropriate custom rules when needed enables you to safely run web apps until they are upgraded or decommissioned.
Have more questions?
Securing your web applications is an important task that requires balancing security, engineering, and business interests. At times these interests conflict, making it challenging for developers to take action.
A WAAP can help close this gap while the team prioritizes threats and implements fixes into your CI/CD pipeline. Our powerful, cost-effective WAAP Insights have lowered the barrier to WAAP adoption.
Contact us to get all your questions about hardening your web security and our WAAP Insights answered.