AppSec is the process of finding, fixing, and preventing security vulnerabilities at the application level, as part of the software development processes. This includes adding application measures throughout the development life cycle, from application planning to production use. In the past, security happened after applications were designed and developed. Today, security is “shifting left”, and security is becoming an integral process of the development and testing process. By adding AppSec from the start, organizations can significantly reduce the likelihood of security vulnerabilities in their own code, or in third-party components used within applications.
There are countless security threats that affect software applications. However, the Open Web Application Security Project (OWASP) Top 10 list compiles the application threats that are most prevalent and severe, and most likely to affect applications in production.
AppSec initiatives must focus at least on these high profile threats to modern applications:
A basic AppSec process involves the following stages:
There are three primary categories of tools in the AppSec toolset: SAST, DAST, and IAST.
SAST tools enable white box testing. They evaluate application code, scanning it to identify bugs, vulnerabilities or other weaknesses that can create a security issue. SAST can run on compiled code, non-compiled code, or both.
SAST analysis can identify issues like:
DAST tools use black-box testing methods to test running applications for security issues. They perform dynamic analysis of source code while it is running. DAST commonly uses fuzz testing, which involves hitting the application with a large number of random, unexpected requests.
DAST can detect conditions that indicate security vulnerabilities, such as:
IAST is a hybrid approach that combines SAST and DAST. The interactive approach to security testing combines static and dynamic analysis—this makes it possible to identify known vulnerabilities, and also see if they are actually used in the running application and can be exploited.
IAST tools gather detailed information about application execution flow and data flows, and can simulate complex attack patterns. As it performs a dynamic scan of a running application, it can check how the application responds, and adjust its testing accordingly. This can be used to automatically create new test cases, and so on (much like a human penetration tester).
Due to this approach, IAST tools can deeply investigate suspected security issue, which reduces the number of false positives. They also fit much more naturally into an agile development process with rapid releases.
A WAF is a solution deployed at the network edge, which inspects traffic flowing into and out of the network, and attempts to identify and block malicious traffic.
Traditional, rule-based WAFs are a high-maintenance tool that require organizations to meticulously define a rule set that matches their specific traffic and application patterns. In addition, rule-based WAFs have limited coverage of constantly changing attack vectors.
In addition, traditional WAFs cannot automatically protect new microservices, because each new microservice deployed requires a significant overhead of defining new rules and policies. In practical terms, this means new systems deployed by the organization will in many cases not be protected.
Here are some best practices you can use to effectively implement AppSec in your organization.
Investigate what are the main entry points attackers can use to breach your applications, what security measures are in place, and whether they are adequate. Set reasonable goals, and milestones over time, for the level of security you want to achieve against each type of threat.
Security testing must be fully integrated with the software development lifecycle (SDLC), from the planning stage, through to development, testing and deployment to production.
Use automated tools to ensure applications are tested as early as possible in the process, and in multiple checkpoints throughout the CI/CD pipeline. For example, when a developer commits code and triggers a build, that code should automatically undergo some form of security testing, enabling the developer to immediately fix security issues in their code.
That same code should be tested again, more comprehensively, when promoted to a testing and production environment.
Application security will result in discovery of vulnerabilities in your applications—and you won’t be able to fix all of them. Prioritization is very important to ensure that critical vulnerabilities are remediated fast, without hurting developer productivity.
Your security testing process should include automated metrics showing vulnerability severity and exploitability, and if necessary, a manual evaluation indicating whether the vulnerability really poses a business risk. Vulnerable components that are not running in production are not a priority.
Ensure developers know they are working on real, high profile vulnerabilities, and have the time to remediate them wherever they occur in the SDLC.
An AppSec program requires a major investment in time and resources, as well as cultural and organizational changes. It’s important to understand the impact of the program on security to justify the program and ensure it is supported by management.
Important metrics you can track and share to demonstrate AppSec success—a weekly or monthly trend can show the impact of introducing application security measures:
Everything related to an application security program is sensitive data that could be extremely useful to an attacker. Make sure you carefully manage:
Use the principle of least privilege, and ensure each user only has access to data and systems they absolutely need to do their job. Use zero-trust principles between integrated systems, ensuring each system has only the minimal permissions it needs to function.
Check Point’s CloudGuard includes a zero configuration application security solution which provides:
Powered by a patent pending contextual AI engine, CloudGuard Application Security is fully automated and can be deployed on any environment.