What does the security of modern applications consist of?

In general, the AppSec methodology helps protect application data and code from cyberattacks and data theft. The methodology considers all aspects of security in the design, development, and deployment of applications. AppSec includes the implementation of software, hardware, and procedures that identify and reduce the number of vulnerabilities in the security system and minimize the likelihood of a successful attack.

AppSec usually involves the implementation of security and control measures in software processes. For example, automatic static analysis of new code, testing new software versions for security vulnerabilities or misconfigurations, and using an application firewall to strictly define allowed and prohibited actions.

Let's take a closer look at the components of the AppSec methodology.

Secure Software Development Lifecycle

It is worth starting the discussion about AppSec by considering the concept of software development, which involves forming application requirements, secure programming, testing, certification, operation, and updates.

SSDLC involves building and analyzing a threat model for the application being created, taking into account risks, developing the application design in accordance with the data of the model, developing the application using various code analysis and testing tools, and actually deploying it in a secure configuration.

We will talk about all this further.

Threat Model

Obviously, for effective application protection, it is necessary to understand well how attackers can try to hack it. And threat modeling can help us with this. With its help, we can optimize the security of systems, business processes, and applications. It includes identifying vulnerabilities and goals, as well as determining appropriate countermeasures to mitigate and prevent the impact of threats. This is a fundamental component of a comprehensive application security program.

When performing threat modeling for the application being created, it is first necessary to identify all the assets that will be involved in its operation. We must not only know how many machines we have running Windows, Linux, MacOS, and how many server OSs are used. It is important to understand what roles certain nodes play, in which business processes they participate. The criticality of these processes plays an important role. After all, one server running Ubuntu 22.04 may be involved in a critical business process, the downtime of which will lead to significant financial losses. And another server running the same OS is used to support a less critical process of employee time tracking.

Therefore, during inventory, it is important not only to count the operating systems of nodes and container images on which application components are placed, but also to identify each node within the framework of business processes and their criticality. After identification, it is necessary to create a security profile, that is, to understand what potential threats exist for this node. To do this, it is necessary, first of all, to identify the vulnerabilities that exist in the OS and applications installed on the node.

The identified vulnerabilities need to be prioritized and, of course, try to eliminate them as much as possible.

As for the tools for inventory and vulnerability search, there are many commercial solutions from Russian vendors on the market. But in the simplest case, you can find nodes on the network using nmap, and to identify vulnerabilities, you can use, for example, the Trivy scanner.

The figure below shows a fragment of the scan results of the Nginx image. Although the utility can also find not only vulnerabilities, but also incorrect configurations, secrets left in the project, and licenses, and works with both files and virtual machine images, GIT repositories, and cloud resources.

The general format for calling the utility:

trivy [global flags] command [flags] target

Testing

AppSec testing (AST) helps identify and minimize software vulnerabilities. This allows teams to prevent software vulnerabilities before deployment and quickly identify vulnerabilities in the production environment. Let's consider the main types of tests.

Static Application Security Testing (SAST) helps identify code defects by analyzing application source files for their root causes. It allows comparing static analysis scan results with real-time solutions for quick detection of security issues, reducing troubleshooting time, and collaborative troubleshooting.

Different analyzers will be used for different languages. For C/C++, it could be clang, for Python — Bandit, and so on. The general idea is that the analyzer receives a file with source code as input and outputs a report on the found errors.

Dynamic Application Security Testing (DAST) simulates security breaches in a running web application to identify exploitable vulnerabilities. These tools evaluate applications in a working environment to help detect execution or environment-related errors.

Interactive Application Security Testing (IAST) uses elements of SAST and DAST, performing analysis in real-time or at any stage of the SDLC from the application. IAST tools access the code and components of the application, meaning the tools provide the comprehensive access needed to obtain accurate results.

Runtime Application Self-Protection (RASP) are tools that work directly within the application, providing continuous security checks and automatically responding to potential breaches. Common response measures include alerting IT professionals and terminating a suspicious session.

Cloud-Native Application Protection Platform (CNAPP) centralizes the management of all tools used to protect cloud applications. It integrates various technologies such as Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP), identity rights management, automation and security orchestration for container orchestration platforms like Kubernetes, as well as API discovery and protection.

Application Security Recommendations

Next, let's consider some basic recommendations for application security.

First of all, it is the shift of the security level "to the left". The modern fast-paced software development industry requires frequent updates — sometimes several times a day. Security tests should be included in the development process so that development and security teams can keep up with demand. Testing should begin early in the SDLC (to the left, if you look at the SDLC lifecycle diagram) to avoid release bottlenecks at the end of the pipeline.

Understanding the existing development process and the relationships between developers and security testers is important for implementing an effective "shift left" strategy. The next step is to integrate security assurance processes into the existing development pipeline so that developers can easily adapt to the new approach.

The CI/CD pipeline should include automated security tests at various stages. Integrating security automation tools into the pipeline allows the team to test the code independently, without relying on other teams, enabling developers to quickly and easily fix issues.

Effective privilege management is also necessary. Not every user in the organization requires the same access privileges. Restricting access to data and applications according to security requirements is one of the main methods of ensuring security. There are two main reasons for restricting privileges.

If hackers can gain access to the system using stolen credentials (e.g., from a marketing department employee), controls must be in place to prevent access to other data. Least privilege access controls help prevent lateral movement and minimize the attack surface.

Internal threats become more dangerous when an attacker has access to internal network resources. These threats can be malicious or unintentional, for example, an employee may incorrectly install a device or upload malicious files.

Privilege management should be based on the principle of least privilege, so that employees and external users cannot access data they do not need, reducing overall vulnerability.

Privilege analysis can be performed without the help of special tools. It is enough to look at the contents of the /etc/sudoers, /etc/groups files for users who are members of privileged groups.

You can also search the system for files with SUID/SGID permissions.

find "$DIRECTORY" -perm /u=s,g=s

You can also search for files with full 777 permissions:

find / -type f -perm 0777

These actions should be performed when the target application is already deployed, during operation. And checks need to be carried out on a regular basis, as application security is a process, not a result.

Conclusion

We have reviewed the basics of the AppSec application security process and got acquainted with some tools that can be used to perform the tasks of this process.