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.

How CrowdStrike Helps Secure Business-Critical Applications

Business-critical applications are valuable assets that require a comprehensive protection plan. The AI-native CrowdStrike Falcon® platform helps you at every step of the journey, from cloud misconfiguration detection to application security posture management and runtime protection.

To learn more, request a demo.

Additional Resources

• Learn how Bionic, a CrowdStrike company, can expose threats on every application attack surface.
• Read the press release on CrowdStrike’s acquisition of Bionic.
• See why Forrester named CrowdStrike a Leader in The Forrester Wave: Cloud Workload Security, Q1 2024. 

Cybercriminals work around the clock to discover new tactics to breach systems. Each time a digital ecosystem changes, it can introduce a weakness for a threat actor to quickly discover and exploit. As technological innovation progresses rapidly, and organizations expand their infrastructure, this weakness may take shape in the form of architecture drift. 

Today, we explore the concept of architecture drift: what it is, why it matters and how application security posture management (ASPM) can help.

Why Architecture Drift Is a Problem for DevSecOps

The rise of continuous integration and continuous delivery (CI/CD) and infrastructure-as-code (IaC) means apps, clusters and environments are constantly changing across organizations. Architecture drift occurs when an app, microservice or infrastructure “drifts” out of its intended configuration or approved operating boundaries.

Drift is difficult to detect and it introduces risk, which often isn’t seen or managed until something serious happens, such as an outage, incident or breach. It can happen in a variety of places, including:

• Infrastructure
• Network
• Container orchestration
• Application runtime
• Business logic
• Data flow

Architecture drift may affect infrastructure, for example, when IaC scripts such as Terraform or CloudFormation get out of sync with what’s running in the environments. For example, a development team might use a CloudFormation script to provision a new environment that declares all EC2 instances should be “t2.small.” Meanwhile, an engineer decides to manually add a “c4.large” instance to the same environment. Because C4 compute instances cost significantly more than T2 instances, this change will increase the company’s cloud bill and possibly create problems with reliability and performance.

Business Logic and Data Flows Can Drift Too

Continuous development means code, business logic, data flows and application architecture can change hourly in your environments. Depending on the level of automation and guardrails in your CI/CD pipelines, engineers might deploy code changes on demand or be required to follow a review process should a change be significant. These code changes can cause assets to drift, potentially interacting with one another and creating new risks.

A single code change can introduce new:

• Services
• APIs
• Dependencies
• Libraries
• Third-party service calls
• Datastore or database connections
• Data flows
• Risks you might not have considered or thought about

Even tiny changes can have a big impact. For example, several years ago, a small code change resulted in a personally identifiable information (PII) exposure at an enterprise. The risk made its way into production because the engineer who committed the code change didn’t know their code touched PII and stated this in their change request questionnaire. As a result, they caused code to drift and interfere with data it shouldn’t have been near, unintentionally exposing the sensitive data.

We detect and observe drift frequently among customers of Bionic, a CrowdStrike company. More often than not, that drift is related to business logic, architecture and data flows. You can’t eliminate all risks in applications or the business, but you can start to go beyond what you know and think differently about what could impact your business.

Applications are complex beasts to tame, encompassing hundreds or thousands of components and dependencies. Every code change introduces potential risk. The question is: Do you see these risks and know their potential impact?

How to Detect Architecture Drift

With application security posture management, you can detect and manage application drift in real time. ASPM allows teams to quickly baseline and lock in their application architectures, so they have drift policies that can notify them in real time, should an architecture change. For example, ASPM can detect things like new services, APIs, new libraries, ports, connections, dependencies or even data flows that an application might start to exhibit following CI/CD deployments or code changes.

ASPM flags these drifts and provides full business and application context so your teams can prioritize the cruciality of critical services or data flows that are impacted. They can also visualize where each drift is occurring so teams see the full picture and catch drift before it causes a problem.

ASPM at CrowdStrike

CrowdStrike acquired Bionic in September 2023 to bring market-leading application security to CrowdStrike’s leading cloud-native application protection platform (CNAPP). With ASPM, CrowdStrike delivers comprehensive risk visibility and protection across the entire cloud estate, from cloud infrastructure to the applications and services running inside of them.

Stay tuned for more educational blogs on this important topic! 

Additional Resources

• Learn how Bionic, a CrowdStrike company, can expose threats on every application attack surface.
• Read the press release on CrowdStrike’s acquisition of Bionic.
• See why Forrester named CrowdStrike a Leader in The Forrester Wave: Cloud Workload Security, Q1 2024. 

Modern applications are designed to process, use and store vast amounts of sensitive data. As adversaries seek to infiltrate these applications, IT and security teams must ensure the software they use has the strongest possible security. The first step to implementing strong application security is understanding the type of application you need to protect.

The two types of applications security teams must be familiar with are custom-developed software and commercial off-the-shelf (COTS) software. In this blog, we explain the differences between custom-developed applications and COTS applications and how each type of application is secured.

What Is Custom-Developed Software?

The crucial difference between these two types of applications is who owns the source code — the set of computer instructions that accomplishes some task. Every application is built from source code, and that source code is created by software developers. Modern programming languages you’re likely to encounter in source code include Java, Python, .NET, Node.js and Go.

Custom software consists of proprietary source code, which is typically owned by the developer or company that created it. If you’re interfacing with proprietary source code, then you’re managing custom-developed software — software that is “built in-house” to fulfill a specific business requirement. Companies either sell their custom-developed applications or use them for internal business needs.

Here’s an example. Suppose you work in security at a company called Math Tutors. The company’s developers created the Python code shown below.

Customers have purchased version 1.0.0 of your software, and you’re responsible for ensuring the custom-developed Python code is secure.

One day, you realize your “sum” function leaks proprietary data when the user enters a non-integer. Your developers add error handling to the sum function to secure it. The updated source code is shown below.

After securing your custom-developed software, you release version 1.1.0 of your product. When customers purchase your software, it’s their responsibility to upgrade to the latest version, meaning they must now use version 1.1.0 to ensure they’re using the most secure version of your software.

How Are Custom-Developed Applications Secured?

Securing custom software begins before writing the first line of code. Once functional requirements are defined, architects lay out the initial design. The architecture should then go through a threat model where the likely attack vectors are analyzed. After the initial threat model is complete and design changes implemented, software development begins.

Most modern software teams use some form of Agile software development. With Agile development, the software is iterated over time and updates occur on a regular basis. The scope of work is decomposed into stories, which typically include small feature implementations (building a new capability) or bug fixes (fixing problems in existing code). Stories that are not actively being worked on are placed in the backlog. When the security team needs developers to fix a security issue, they create a story that lives in the backlog until the development team is able to resolve the problem.

With the “shift left” approach to security, vulnerable code detection begins during development through software composition analysis (SCA), static application security testing (SAST) and dynamic application security testing (DAST). These tools are effective at isolating unique instances of vulnerable code.

The most challenging aspect of securing custom software is finding the weaknesses that lurk in production. Common issues that plague application security include:

• Unauthenticated APIs
• Unknown sensitive data stores or data flows
• Internet-facing microservices
• Third-party communication

What makes this set of issues particularly challenging is they frequently deviate from the original design. This is why having visibility into what’s deployed in production is essential. When the true architecture is unknown, inferred or outdated, it’s difficult to detect and prioritize security weaknesses. This can lead teams to rely solely on security scanning tools, which tend to provide an overwhelming list of vulnerabilities.

The most effective solution to this problem is application security posture management (ASPM). ASPM provides specific remediation advice based on the real-time status of your software architecture. You not only receive a concise list of the highest priority security weaknesses, but you can also speak clearly to engineering teams about the business impact of vulnerabilities.

 

To learn more about preventing breaches in custom-developed software, check out how CrowdStrike Falcon Cloud Security delivers powerful ASPM capabilities as part of a unified cloud-native application protection platform (CNAPP) to offer full-stack protection for your applications.

What Is Commercial Off-the-Shelf Software?

COTS software is built for commercial use and is readily available for purchase. If you pay for application access but can’t see the source code, you’re working with commercial-off-the-shelf software.

When the application is paid for on a recurring basis, you’re purchasing software as a service (SaaS). SaaS is a revenue model, but the terms COTS and SaaS are often used synonymously.

Now, think back to the Math Tutors example, but this time, imagine you work in security at a different company called Math Learners and you’re using the software that Math Tutors developed. From your perspective, the application is a COTS application. Rather than seeing source code, your view of the application will look like the screen shown below.

When version 1.1.0 of the application is released, your team at Math Learners is responsible for upgrading your systems to ensure the vulnerability is patched and they use the secure version. Even though you don’t notice a visible change, upgrading the version adds security fixes to the software.

Common examples of COTS applications that organizations purchase include Google Workspace, Microsoft Outlook and many others. Each of these applications is considered “custom-developed” by the organizations selling them.

How Are COTS Applications Secured?

Purchasing COTS software introduces several security responsibilities. The steps for initial setup and continuous monitoring are as follows:

1. Perform a security review of the COTS vendor and application.
2. Provision access to the necessary members of your organization.
3. Continuously monitor:

• Application programming interface (API) connections between internal custom developed applications and the COTS application
• Individual access permissions and configuration
• Data transmitted to (and from) the COTS application

From a security perspective, the first step to introducing new COTS software to an organization is to understand the risks. Vendors will not typically share source code, so customers must rely on a limited scope of information. You may consider asking for:

• A recent penetration test
• A software bill of materials (SBOM)
• Documentation on a vendor’s software development lifecycle (SDLC)
• Certifications such as SOC 2 or ISO
• Customer references
• Data access rights in the terms and conditions

Each of these items can give a deeper understanding of the COTS software security posture, but there will always be inherent risk when using another company’s software.

Once the software is approved, the next step is to grant access to the appropriate users. This may be done through role-based access control if entire departments will use the software, or discretionary access control if only certain users need the application.

With access granted, it’s vital to monitor COTS applications continuously. The first area to manage is software-to-software access. This type of access occurs via the APIs that software developers create.

A successful implementation of API management includes an inventory of all API calls to COTS applications. The API inventory should update as software developers create and remove APIs, and note all APIs transmitting sensitive data. ASPM tools automatically generate a comprehensive list of API calls to third-party applications.

 

The second area to manage is user provisioning. Security teams must audit and update user access to COTS applications regularly. Additionally, security teams are responsible for managing the configuration of COTS applications. Both identity access management (IAM) and SaaS security posture management (SSPM) help ensure COTS configurations are correct.

The third area to manage is sensitive data transfer. Detecting and preventing unauthorized data egress requires a data protection solution. The data protection solution should combine content with context to provide deep real-time visibility into what is happening with your sensitive data, including data artifacts, as they move from the source to the destination, which could be COTS applications.

Consider the following scenario, for example:

1. A sensitive file is downloaded.
2. The contents are copied to a spreadsheet.
3. Smaller chunks of the data are copied to another sheet and moved to a personal google drive.

Data protection solutions provide the complete flow, along with who performed the actions and where this data landed.

How CrowdStrike Helps Secure Custom and COTS Software

Both custom and COTS software present unique challenges, but visibility is crucial in both cases. Both custom and COTS software present unique challenges, but visibility is crucial in both cases. With Falcon Cloud Security and CrowdStrike Falcon® Data Protection, you can keep track of your organization’s use of COTS software and prevent data loss.

The CrowdStrike Falcon platform provides insights on both your custom developed applications and third-party software use. To learn more, request a demo.

Additional Resources

• Learn more about the world’s leading AI-native platform for complete cloud security.
• Take a free Cloud Security Risk Review to visualize misconfigurations and other vulnerabilities in minutes.