Ghost code is a major risk for web applications

A new report by Osterman Research Note that most websites use third-party libraries to simplify common functions, but these same libraries often pose application security risks. Organizations also typically lack visibility into third-party code, making it difficult to determine whether websites and web applications have been compromised.

Many organizations use third-party libraries to speed up development and use code to enable features such as ad tracking, payment integration, chatbots, customer reviews, social media integration, tag management , among others. Since these functions tend to be needed in many types of websites and applications, they are often reused by many organizations, increasing the available attack surface available to attackers when targeting these libraries. .

According to the report, 99% of respondents said their websites use supply chain vendors or third-party code from vendors who also get code from their partners. More than three-quarters (80%) said third-party scripts account for 50-70% of their website’s functionality. This exposes most websites to ghost code risks.

The lack of visibility into this third-party code is glaring, as nearly half (48%) of survey respondents could not say with certainty that their websites had not suffered a cyberattack.

With the risk of third-party libraries, organizations must take steps to prevent their websites and applications from being attacked and existing vulnerabilities from being exploited. While many are turning to WAFs to protect their applications in production, there is plenty of evidence that WAFs are less than effective at protecting web applications. The product category known as runtime application security protection, which can protect web applications and their vulnerabilities from real-time exploitation, is often overlooked.

Take a page from NIST to improve application security

Even the National Institute of Standards and Technologies (NIST) recently recognized the need for runtime application security. NIST’s SP800-53, just released on September 23, 2020, includes a requirement for runtime application security, also known as runtime application self-protection (RASP). The latest revision of NIST SP800-53 includes the requirement for RASP (Runtime Application Self-Protection) and IAST (Interactive Application Security Testing). This is a first in recognizing these two advances in application security by now requiring them as part of security.

Additionally, there are a number of simple steps an organization can take to improve its web application security position. It all starts at the very beginning of app development, and it is to ensure that developers consider security while developing and coding apps. Second, ensuring that software and operating systems are kept up to date, with the latest updates and patches to ensure that known vulnerabilities that have patches are not exploited.

In addition to these two fundamental elements of application security, there is always a need to ensure the security of web applications running in production, especially against threats that are missed or not secured by network or system level security. the OWASP Top 10 Web Application Security Risks are a prime example of risks that are typically not protected by network or system level security.

A GRATED The solution resides on the same server as the application and provides continuous security for the application during runtime. By running on the same server as the application, RASP solutions ensure continuous security of the application while it is running. For example, as mentioned earlier, a RASP solution has complete visibility into the application, so a RASP solution can analyze the execution of an application to validate code execution and can understand the context of the interactions of the app.

IAST is the other new recommendation for application security from NIST’s revised draft, and if you haven’t heard of IAST, there is a good definition available from Optiv

“IAST is an emerging application security testing approach that combines elements of its two more established siblings in SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing). IAST instruments the application binary which can provide both DAST-like confirmation of exploit success and SAST-like coverage of application code. In some cases, IAST allows security testing as part of the general application testing process, which provides significant benefits to DevOps approaches. IAST has the potential to conduct tests with fewer false positives/negatives and higher speed than SAST and DAST.

With these two new requirements (RASP and IAST) for application security added to the NIST framework, it’s really time to rethink how your organization manages application security.

At K2 Cyber ​​Security, we would like to help you with your RASP and IAST requirements. K2 offers an ideal runtime protection security solution that detects true zero-day attacks, while generating the fewest false positives and alerts. Rather than relying on technologies such as signatures, heuristics, fuzzy logic, machine learning or AI, we use a deterministic approach to detect true zero-day attacks, not limiting ourselves to detection of attacks based on prior knowledge of the attacks. Deterministic security uses validation of application execution and verifies that API calls work as expected by the code. No prior knowledge of an attack or the underlying vulnerability is used, giving our approach the true ability to detect new zero-day attacks. Our technology has 8 issued/pending patents, and has no false alarms.

We also recently released a video, The need for deterministic security. The video explains why technologies used in today’s security tools, including web application firewalls (WAFs), fail to prevent zero-day attacks and how deterministic security addresses the need to detect zero-day attacks. The video explains why technologies such as artificial intelligence, machine learning, heuristics, fuzzy logic, pattern matching and signature matching fail to detect true zero-day attacks, giving very good examples. specific attacks where these technologies work and where they fail to detect an attack.

The video also explains why deterministic security works against true zero-day attacks and how K2 uses deterministic security. Watch the video now.

Change the way you protect your apps, include RASP, and learn about K2’s app workload security.

Learn more about K2 today in to ask a demo or get your free trial.