How to Secure Business-Critical Applications

Originally published by CrowdStrike.

As organizations move more of their business-critical applications to the cloud, adversaries are shifting their tactics accordingly. And within the cloud, it’s clear that cybercriminals are setting their sights on software applications: In fact, industry data shows 8 out of the top 10 breaches in 2023 were related to applications.

The most valuable of these, known as business-critical applications, typically process large amounts of sensitive data including customer information, intellectual property and other critical data. These often have vulnerabilities or are poorly configured, leaving important information exposed to threat actors. Adversaries know this; as a result, many cybercrime groups focus their attacks on this type of software.

In this blog, we detail the steps to protecting your custom-developed business-critical applications to prevent your sensitive data from getting into the wrong hands.

Identify Your Business-Critical Applications

Business-critical applications are fundamental to a company’s operations. They typically process large amounts of sensitive information while creating revenue for the business.

If a business-critical application is breached, the parent company will be forced to deal with fines, data loss, reputational damage, loss of customers and other concerns. Additionally, the company may see revenue fall if the software goes offline unexpectedly and customers cannot transact on the platform.

Common examples of critical applications include stock trading applications, e-commerce sites, healthcare software, and any other custom software that processes private information or business-critical data. Once custom-developed applications are deemed “business-critical,” they should be considered a top priority for security monitoring and reviews.

Configure a Secure Digital Infrastructure

Protecting the machines that run business-critical applications is a complex task with many moving pieces. Consider each of the following infrastructure needs:

• Network segmentation
• Firewalls
• Operating system and virtual machine (VM) patching
• Cryptography
• Secrets management

Restricting an attacker’s ability to move laterally through the network goes a long way in stopping breaches. By isolating digital assets and requiring authorization to access critical applications, the likelihood of a successful attack is reduced. Furthermore, network packets can be rejected by access control lists and firewalls, including web application firewalls.

Operating systems and VMs must be patched regularly. These underlying systems provide the backbone on which all other software runs; as a result, they are appealing adversary targets and new vulnerabilities must be patched as they are found and disclosed.

In some cloud configurations, known as “platform as a service” (PaaS), the cloud provider will automatically update the OS and VM to patch vulnerabilities. With on-premise deployments and other cloud configurations, known as “infrastructure as a service” (IaaS), the end user is responsible for patching their own systems.

Data can be stored securely to further protect it in the event of a breach. Ensuring sensitive data is encrypted, both at rest and in transit, and passwords are hashed both reduce the likelihood an attacker extracts valuable information. Additionally, secrets such as SSH keys and certificates must be protected. A secure digital infrastructure creates a safe environment to run business-critical applications.

Restrict Access Permissions to Required Individuals

Most successful cyberattacks begin with stolen credentials. By limiting both general and administrative access to individuals with a business need for it, you can greatly reduce the risk of compromise.

The nature of an application determines this access strategy. Internal business applications often use role-based access control (RBAC) to allow or disallow branches of an organization to access an application. For a business-to-consumer application, the access strategy is different. Applications serving a wide audience often grant access to any user who chooses to sign up.

Regardless of who can access the application as a whole, in all cases it’s crucial to ensure users can only access portions of the application relevant to them. Often, common features are available to all users while specialized features are available to a limited audience. For example, administrative functions may be restricted to a small subset of people who work in the IT department and the parent organization. Business-critical applications should regularly revoke access from users who no longer require access to the system, such as terminated employees.

Once users are authenticated, they are typically provided an application access token. These tokens uniquely identify an individual and allow the software to authorize user requests, rather than repeatedly requiring a username and password. Attackers attempt to steal access tokens so they can impersonate valid users and steal sensitive data from software. Special care must be taken to protect access tokens from attackers. Requiring HTTPS connections for token issue and enforcing token expiration are common defense mechanisms.

Additionally, user permissions should be tested at every server request. Every application programming interface (API) should require that the user’s identity is authenticated and they’re authorized to access the requested information. Establishing effective access permissions for business-critical applications is essential to prevent unwanted users in software and stop breaches.

Proactively Monitor for Suspicious Activity

Business-critical applications have great appeal to adversaries. Implementing a robust monitoring solution to detect attacks and stop suspicious data access is essential.

Every software application is hosted somewhere. By adding a runtime protection agent to servers that run business-critical applications, security teams can halt dangerous activity. Common indicators of attack such as persistence, lateral movement and enumeration should trigger alerts to the organization. Real-time insights allow detection and response teams to intercept suspicious activity before data exfiltration occurs. On-premises software benefits from endpoint detection and response solutions, while cloud-native applications use cloud workload protection to stop attacks in real time.

Improve Security Testing in the Software Development Pipeline

Implementing security controls early in the development process helps reduce risk in production. By “shifting security left” and integrating vulnerability scanners in the software development pipeline, development teams can find and fix security bugs early. Security teams that already measure security posture in production can quantify how efforts to shift left reduce risk to the business over time. Integrating vulnerability scanning tools is particularly useful in net-new development, since vulnerabilities are easier to mitigate during initial development.

Custom software applications contain native code and third-party code, often known as “open source.” The owner of the custom software is always responsible for ensuring imported packages do not contain common vulnerabilities and exposures (CVEs). Additionally, the development team can introduce vulnerabilities in their code built in-house. It is the organization’s responsibility to ensure their developers are shipping secure code regardless of deployment location.

Resolve Immediate Risks in Production

Application risk posture is a combination of infrastructure misconfigurations, security vulnerabilities, trust boundaries, business logic and data sensitivity. Analyzing the current risk posture of business-critical applications should be a priority.

Misconfigurations and vulnerabilities are distinct from one another but introduce similar security concerns. Misconfigurations are insecure infrastructure settings that increase the likelihood of unwanted access. Common misconfigurations include default credentials, unrestricted inbound traffic, public storage buckets and plaintext SSH keys. Software vulnerabilities, on the other hand, are security flaws in code that an attacker can exploit.

Weakness must be paired with accessibility to be exploitable. For example, a CVE enabling remote code execution is substantially more dangerous when it exists in a public-facing microservice. Trust boundaries, which are theoretical “boundaries,” define where incoming data from an unreliable source appears. Business-critical applications are more likely to be exploited when their vulnerabilities exist on the edge of a trust boundary. Production risk increases where applications communicate with the public internet or a third-party-owned software.

Understanding data flows and APIs is crucial when quantifying business risk. Security teams can make more informed decisions when they understand the data processed at various stages of a business-critical application. APIs transmitting sensitive payloads are a bigger concern than those without sensitive data. Similarly, databases with personally identifiable information present a greater risk than those without. Correlating business logic with sensitive data allows security teams to make more informed decisions.

Monitor Changes to Production

As code changes alter custom applications, it’s imperative to track changes to their risk posture.

Newly introduced dataflows and APIs can have a massive influence on the likelihood of sensitive data exposure. Even more challenging to manage are changes to existing data flows and APIs — small updates can present massive risk, such as accidentally removing authentication from an API or returning sensitive data in an API’s payload for the first time.

Most code is not created in-house. In fact, open source software accounts for more than 80% of the lines of code in modern software applications. As library versions change, and new libraries are imported for the first time, the CVEs present in an application will change. Understanding both the business impact and likelihood of exploitation for each CVE in production allows security teams to prioritize their efforts.

Maintaining a constant measurement of the production risk posture empowers security teams to stay in sync with their software development counterparts and respond to dangerous changes quickly.