If you’re new to Application Security, you may be confused by the different terminology and where exactly Application Security fits relative to all the different phases of application development and during runtime of applications. The term is broadly used in both the software development lifecycle as well as by security teams managing applications running in production. In this article we will cover where application security fits in both development and in production.
Application Security during Software Development
First let’s start with application security during software development. The focus on security during development has been increasing in the recent years and has led to movements like “Shift Left” and “DevSecOps” both of which target getting security thinking and practices earlier in the development life cycle. There’s good reason to “Shift Left,” since we know that finding or preventing vulnerabilities earlier in the development cycle has a significant benefit, and that’s the reduction of cost in remediating vulnerabilities. NIST (National Institute of Standards and Technologies) did a study where they found there’s a potential savings of up to 30x per bug and up to 60x for a security defect, when the problem is fixed earlier in the development process.
Security during application development should actually take place at all stages of software development. Starting at the very beginning with planning and design, through code development, code reviews, and all the QA cycles. “Shift Left” and “DevSecOps” are both about ensuring security has a focus, is implemented, and executed during all phases of the software development life cycle.
Planning and Design
It may seem strange to think about security during planning and design, when a development team is more likely to be thinking about functionality and ensuring the application meets the product requirements. But if security is planned from the beginning, it will make security fixes simpler later on. In planning the application, think about where the data is going to reside, how it’s going to be accessed, what functions will be written for access, and ensure access is given only when it’s actually necessary. Planning the functions that will access the data, and how they will access the data in a secure fashion will help ensure security later on when testing against the application.
Code development is another area you might think that security seems out of place. But in actuality, security during code development is probably one of the most important areas for security. That’s because the way code is written can impact what vulnerabilities exist in the code. It’s actually the responsibility of the coder to ensure that secure coding practices are used when writing the code to limit the number of vulnerabilities introduced into the final code. If you’re a developer and looking for a guide on where to start on security in code development, check out our blog post on a developer’s guide here.
During the code development process, code reviews are an essential milestone for checking on the functionality of the code, and for getting fresh sets of eyes (peer review) on the developed code. Code review generally looks for properly formatted code, architecture, coding best practices, non-functional requirements (readability, testability, ability to be debugged, and configurability), and analysis and design. But it’s also an equally important step to ensure that coding for security has been taken into account. It’s an opportunity review that the best practices for ensuring security were taken into account during the initial coding and development.
QA Cycles and Testing
Usually the first and primary objection of QA and testing is to ensure that the application under development’s functionality and behavior is correct and matches the requirements set in planning. Testing for security is equally important, and there’s a number of tools to help during QA and testing to ensure the security of the developed code.
SAST and DAST Testing
SAST (Static Application Security Testing) generally comes the earliest when testing for security, and SAST tools examine the code for security problems. DAST (Dynamic Application Security Testing) is sometimes called “black box” testing, and comes after the code has been completed, and can be tested operationally. DAST testing simulates attacks against the application, attempting exploits, looking for vulnerabilities in the code. Both SAST and DAST have their limitations in terms of visibility and ability to detect vulnerabilities in the application being tested.
IAST (Interactive Application Security Testing) is the latest buzzword in security testing for applications during development. IAST differs from SAST and DAST (Dynamic Application Security Testing), in that IAST uses an agent directly on the application server to observe the application as it is running, which has visibility into the application to detect and report additional detail on the vulnerabilities that are discovered.
IAST is getting new found attention recently due to the recent finalization of the National Institute of Standard and Technology (NIST)’s SP800-53 Revision 5 update, that includes the requirement to add IAST to the policy and security frameworks being used by federal government agencies. NIST is recognizing the need for better security for applications, and that starts with finding more vulnerabilities during security testing in development. By requiring IAST, organizations, will get better results from their security testing with the increased visibility provided by IAST solutions.
Application Security in Production
While some view application security as an activity for only the development phase of code production, application security during production, while the application is running live is just as important as ensuring application security during development. Traditionally, applications running on-premises were easier to protect because there’s a defined network perimeter to defend. Using a firewall or a WAF (Web Application Firewall) protects at the perimeter of the network, but fails to see activity happening directly on an application server, or between servers.
For some organizations, adding security on the application server has meant adding an anti-virus, anti-malware or EDR (Endpoint Detection and Response) solution on the server. While these security tools are designed for protecting against malware, they were really designed for end-points rather than servers, and won’t be application-aware, and typically don’t protect the applications that are running on the application server.
Since neither of these areas of security focus (WAF and EDR) have been successful at fending off attacks, then maybe it’s time to rethink the way we do application security. The new NIST SP800-53 Revision 5 discussed earlier also adds a new requirement around RASP (Runtime Application Self-Protection).
If you’re not familiar with RASP, it’s not a new concept. The product category has existed since 2014, and came about because of the need for security that is specific to the challenges and threats that web applications face. If you’re thinking your WAF is providing your application security, you wouldn’t be alone, but you’d be missing out on many application security needs. While WAFs have been around in their current form since around 2002, WAFs function as a network perimeter security solution and they have failed to meet the security needs around many of the issues that applications face in today’s threat landscape.
RASP has code level visibility into the application and can analyze all the activity related to the application to accurately identify when attack occurs, thereby reducing the amount of false positives. Unlike WAFs which only see the traffic coming to and from the server, a RASP can see what’s happening inside the application, to determine if there’s inappropriate use of the application itself. RASP is really the first security category to offer self protection for the application.
Application Security in the Cloud
The pandemic as well as operational costs have sped the adoption of the cloud, and many applications have moved to the cloud in the past year, making security for applications in the cloud an imperative.
Security in the cloud differs from security for applications that are located on-premises in a few different key areas. First, in the cloud, there’s no longer a defined network perimeter, so trying to protect a perimeter is difficult, and different components of the application can actually reside in different cloud environments, especially with the increase in use of SaaS components, making perimeter based security even harder.
Application security in the cloud is where RASP is a necessity. Having security located with the application makes sense, since the application can be can reside almost anywhere in the cloud. And because applications in the cloud can be virtual, in containers, part of Kubernetes frameworks, and even in server-less environments, having a RASP solution that can work in any environment is key.
How K2 Can Help with Application Security Requirements
For organizations that want an easy way to get IAST results using their existing DAST testing tools, they can now do this with no changes to the testing methodology or testing tools. By adding the K2 Security Platform agent to the application server under test, K2 can provide IAST results by giving the visibility to the tested applications that DAST testing tools are missing. By pairing K2 with an existing DAST tool, K2 can corroborate the DAST tool’s results, while at the same time providing additional details, including the filename containing the vulnerability and the line number within the file that contains the vulnerable code. In addition K2 can also find and report on additional vulnerabilities with the added visibility into the application that the DAST tool may miss.
By adding an agent on the application server, organizations can get IAST results from their existing DAST tools, without having to learn and implement an IAST tool. K2 Cyber Security is a great addition for adding visibility into the threats discovered by penetration and security testing tools in pre-production and can also find additional vulnerabilities during testing that testing tools may have missed. K2 can pinpoint the exact location of the discovered vulnerability in the code. When a vulnerability is discovered (for example, SQL Injection, XSS or Remote Code Injection), K2 can disclose the exact file name along with the line of code that contains the vulnerability, details that testing tools typically are unable to provide, enabling developers to start the remediation process quickly.
Here at K2 Cyber Security, we can also help with your RASP requirements. K2 offers an ideal runtime protection security solution that detects true zero-day attacks, while at the same time generates the least false positives and alerts. Rather than rely on technologies like signatures, heuristics, fuzzy logic, machine learning or AI, we use a deterministic approach to detect true zero-day attacks, without being limited to detecting attacks based on prior attack knowledge. Deterministic security uses application execution validation, and verifies the API calls are functioning the way the code intended. There is no use of any prior knowledge about an attack or the underlying vulnerability, which gives our approach the true ability to detect new zero-day attacks. Our technology has 8 patents granted/pending, and has virtually no false alerts.
We’ve also recently published a video, The Need for Deterministic Security. The video explains why the technologies used in today’s security tools, including web application firewalls (WAFs) fail to prevent zero day attacks and how deterministic security fills the need for detecting zero day attacks. The video covers why technologies like artificial intelligence, machine learning, heuristics, fuzzy logic, pattern and signature matching fail to detect true zero day attacks, giving very specific examples of 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 how you protect your applications, include RASP and check out K2’s application workload security.