Category: Data Theorem

[By Doug Dooley, COO, Data Theorem]

The rise of OpenAI and new changes with ChatGPT-4 Turbo will help to revolutionize the way financial services organizations take advantage of their data, enabling them to scale their analysis rapidly and stay agile in a fast-paced digital environment. However, the number of enterprise Application Programming Interfaces (APIs) to connect and share data with GenAI system like OpenAI has also brought new risks and vulnerabilities to the forefront. With every new API integration that OpenAI gets access to, the attack surface of a financial organization grows, creating new opportunities for attackers to exploit vulnerabilities and gain access to sensitive customer and financial data.

APIs have become the backbone of modern digital ecosystems, allowing financial organizations to streamline operations, automate processes, and provide seamless user experiences. They are the data transporters for all cloud-based applications and services. APIs act as intermediaries between applications, enabling them to communicate with each other and exchange data. They also provide access to critical services and functionality in your cloud-based applications. If an attacker gains access to your APIs, they can easily bypass security measures and gain access to your cloud-based applications, which can result in data breaches, financial losses, compliance violations, and reputational damage. For hackers looking to have the best return on investment (ROI) of their time and energy for exploiting and exfiltrating data, APIs are one of the best targets available today.

It’s clear these same APIs that enable innovation, revenue, and profits also create new avenues for attackers to achieve successful data breaches for their own gains. As the number of APIs in use grows, so does the attack surface of a financial organization. According to an industry study by Enterprise Strategy Group (ESG) titled “Securing the API Attack Surface”, the majority (75%) of organizations typically change or update their APIs on a daily or weekly basis, creating a significant challenge for protecting the dynamic nature of API attack surfaces.

API security is critical because APIs are often the important link in the security chain of modern applications. Developers often prioritize speed, features, functionality, and ease of use over security, which can leave APIs vulnerable to attacks. Additionally, cloud-native APIs are often exposed directly to the internet, making them accessible to anyone. This can make it easier for hackers to exploit vulnerabilities in your APIs and gain access to your cloud-based applications. As evidence, the same ESG study also revealed most all (92%) organizations have experienced at least one security incident related to insecure APIs in the past 12 months, while the majority of organizations (57%) have experienced multiple security incidents related to insecure APIs during the past year.

One of the biggest challenges for banks and other financial service organizations is protecting their APIs and proprietary data from OpenAI and other generative AI tools. With ChatGPT 4-Turbo, the technical and cost barriers for experimentation on APIs and data have substantially lowered. Further, the new support for API keys, OAuth 2.0 workflow, and Microsoft Azure Active Directory opens up enterprise data like never before. As a result, the popularity and growth of Enterprise AI assistants enabled by tools such as OpenAI’s Playground and the new “My ChatGPT” creator will invite an onslaught of new users attempting to gain greater insights on proprietary banking data. The intention for nearly all these new Enterprise AI experiments will be to help customers get better financial services and insights, but as the popularity and usage of Enterprise AI continue to surge, financial institutions will find themselves facing a unique dilemma. On one hand, the potential benefits of harnessing AI-powered tools like OpenAI’s Playground for automating tasks, enhancing customer experiences, and increasing their clients’ wealth are enticing. However, this newfound capability also opens the door to unforeseen vulnerabilities, as these AI agents access and interact with sensitive financial APIs and private data sources.

The advent of Enterprise AI assistants introduces a host of security concerns for the financial sector. One immediate concern is the potential for unintended data exposure or leakage as AI systems learn and adapt to their environment. While AI-driven tools aim to streamline processes and improve decision-making, they also have the capacity to inadvertently access or expose critical financial data, likely violating many privacy laws such as the General Data Protection Regulation (GDPR), Payment Card Industry Data Security Standard (PCI DSS), and California Consumer Privacy Act (CCPA) to name a few. Financial institutions must carefully monitor and regulate these interactions to prevent unauthorized access or misuse of sensitive information.

Furthermore, financial service companies must grapple with the challenge of securing their APIs against malicious actors who may exploit AI-powered systems for nefarious purposes. The integration of AI agents into financial processes creates an additional attack surface that can be targeted by cybercriminals seeking to breach systems, steal valuable data, or disrupt operations. Robust security measures and continuous monitoring are essential to mitigate these risks and safeguard against potential breaches.

As Enterprise AI assistants become increasingly prevalent within the financial services sector, institutions must strike a delicate balance between harnessing the potential of AI for innovation and ensuring the highest standards of data protection and cybersecurity. A proactive and comprehensive approach to API security, data governance, and AI-assisted decision-making is paramount to navigating these new challenges successfully while maintaining the trust of customers and regulatory bodies.

When it comes to securing APIs and reducing attack surfaces to help protect from ChatGPT threats, Cloud Native Application Protection Platform (CNAPP) is a newer security framework that provides security specifically for cloud-native applications by protecting them against various API attacks threats. CNAPPs do three primary jobs: (1) artifact scanning in pre-production; (2) cloud configuration and posture management scanning; (3) run-time observability and dynamic analysis of applications and APIs, especially in production environments. With CNAPP scanning pre-production and production environments, an inventory list of all APIs and software assets is generated. If the dynamically generated inventory of cloud assets has APIs connected to them, ChatGPT, Open AI, and other AI and ML libraries can be discovered. As a result, CNAPPs help to identify these potentially dangerous libraries connected to Enterprise APIs and help to add layers of protection to prevent them from causing unauthorized exposure from API attack surfaces to protect your organization’s reputation and clients’ private data, and build trust with your customers.

Ultimately, the key to managing the risks posed by expanding API attack surfaces with ChatGPT is to take a proactive approach to API management and security. When it comes to cloud security, CNAPP is well suited for financial organizations with cloud-native applications, microservices, and APIs that require application-level security. API security is a must-have when building out cloud-native applications, and CNAPP offers an effective approach for protecting expanding API attack surfaces, including those caused by ChatGPT.

The post Beware of OpenAI and ChatGPT-4 Turbo in Financial Services Organizations’ Growing API Attack Surface appeared first on Cybersecurity Insiders.

By Anna Tang, Information Security Officer, Data Theorem

In recent years, financial services organizations have increasingly moved their applications and infrastructure to the cloud to take advantage of its scalability, flexibility, and cost-effectiveness. However, this shift to the cloud has also introduced new security challenges, particularly in the realm of application security. Attackers are constantly looking for ways to exploit vulnerabilities in financial applications to gain access to sensitive data or disrupt business operations. To mitigate these risks, financial firms need to adopt a comprehensive security posture management approach that covers both cloud security posture management (CSPM) and application security posture management (ASPM).

While CSPM solutions focus on monitoring and securing the cloud infrastructure itself, it’s the ASPM solutions that secure the financial applications running on that infrastructure. ASPM is a holistic approach to application security that involves continuous discovery and monitoring, assessment, business logic exploitation, and remediation of applications and their vulnerabilities across the entire software development lifecycle. It helps organizations identify and prioritize security issues, and provides guidance and tools to help them mitigate and remediate vulnerabilities, protecting firms from unauthorized data access, interception, manipulation, regulatory violations, fraud, and disruption of services.

By integrating ASPM into their security posture management strategy, financial organizations can discover APIs in use they may not have known about, identify vulnerabilities in their applications, prioritize remediation efforts, and ultimately reduce their overall security risk. Furthermore, by filling coverage gaps in CSPM, ASPM can help financial firms save money by avoiding costly security breaches, financial losses, compliance issues, reputation damage, and downtime.

To leverage ASPM to save costs and fill coverage gaps found in CSPM, follow these best practices:

  • Discover and prioritize critical applications – One of the biggest challenges for CSPM is discovering and determining which applications and services are most critical to the organization. ASPM can help by discovering all APIs in use, mapping those APIs to specific web and mobile applications, providing visibility into the security posture of all applications, and identifying which ones have the most sensitive data. This information can help financial organizations prioritize their security efforts and allocate resources more effectively.

    By focusing on the most critical APIs and applications first, organizations can save costs and reduce their overall risk exposure, particularly since they deal with so much sensitive customer information, including financial transactions and account details. They can also ensure that their security efforts are aligned with their business goals and objectives.

  • Automate security testing and compliance checks – Another way that ASPM can save costs and fill coverage gaps is by automating security testing and compliance checks. With the increasing complexity of cloud environments, manual testing and compliance checks can be time-consuming and error-prone. Automating these processes can help financial firms identify vulnerabilities and non-compliant configurations more quickly and accurately, helping to protect their reputation and clients’ private data, and build trust with customers.

    By automating security testing and compliance checks, organizations can save costs on manual testing and reduce the risk of human error. They can also ensure that their security efforts eliminate regressions as new features are added to cloud-native applications in today’s dynamic environments.

  • Integrate security into the development process – ASPM can also help financial organizations fill coverage gaps by integrating security into the software development process. By incorporating security scans into this process, firms can ensure that security is built into the application from the ground up. This can help reduce the number of vulnerabilities that need to be remediated later.
  • Monitor application behavior in real-time – Another key aspect of ASPM is monitoring application behavior in real-time. This involves using runtime tools that can detect and alert on suspicious activity, such as unauthorized access attempts or data exfiltration. By monitoring application behavior in real-time, financial firms can quickly detect and respond to security incidents, minimizing the potential impact on the business. Machine-learning (ML) based anomaly detection has become more mainstream with addressing these types of API and application-centric attacks in recent years.
  • Use automation to streamline remediation efforts – Remediating vulnerabilities can be a time-consuming and resource-intensive process. However, by using automation tools to streamline the process, financial organizations can reduce the time and effort required to fix vulnerabilities in application code, infrastructure-as-code (IaC), and cloud services. For example, some ASPM solutions can automatically provide Terraform and CloudFormation scripts to auto-remediate application- and API-layer exploits by hardening runtime production configurations. By using these tools to automate the remediation process, organizations can save time and reduce their overall security risk.

Integrate ASPM with CSPM

To get the most out of their security posture management efforts, financial firms should integrate ASPM with CSPM. By doing so, they can fill coverage gaps in CSPM – including API discovery and vulnerability checks – to identify and address vulnerabilities in their applications that cannot be detected by CSPM alone. This integration can also help organizations save costs by avoiding security breaches, compliance issues and fines, and downtime caused by application vulnerabilities. Unlike CSPM, ASPM enables organizations to continuously monitor the security posture of applications and services so they can identify areas for improvement and take action to remediate vulnerabilities and reduce risks.

Overall, ASPM is a powerful tool. By discovering all APIs, identifying and prioritizing critical applications, prioritizing remediation efforts, automating security testing and compliance checks, integrating security into the development process, using risk-based prioritization, and monitoring for continuous improvement and auto-remediation, financial organizations can reduce their overall risk exposure and ensure that their applications and data are secure.

The post How Financial Services Firms Can Use Application Security Posture Management (ASPM) to Save Costs and Fill Cloud Security Posture Management (CSPM) Coverage Gaps appeared first on Cybersecurity Insiders.

By Doug Dooley, COO, Data Theorem

The rise of cloud-native applications has revolutionized the way businesses operate, enabling them to scale rapidly and stay agile in a fast-paced digital environment. However, the increasing reliance on Application Programming Interfaces (APIs) to connect and share data between disparate systems has also brought new risks and vulnerabilities to the forefront. With every new API integration, the attack surface of an organization grows, creating new opportunities for attackers to exploit vulnerabilities and gain access to sensitive data.

This article will attempt to shed some more light on:

  • API Attack Surfaces
  • Shadow APIs
  • Zombie APIs
  • API Protection

APIs have become the backbone of modern digital ecosystems, allowing organizations to streamline operations, automate processes, and provide seamless user experiences. They are the data transporters for all cloud-based applications and services. APIs act as intermediaries between applications, enabling them to communicate with each other and exchange data. They also provide access to critical services and functionality in your cloud-based applications. If an attacker gains access to your APIs, they can easily bypass security measures and gain access to your cloud-based applications, which can result in data breaches, financial losses, and reputational damage. For hackers looking to have the best return on investment (ROI) of their time and energy for exploiting and exfiltrating data, APIs are one of the best targets available today.

It’s clear these same APIs that enable innovation, revenue, and profits also create new avenues for attackers to achieve successful data breaches for their own financial gains. As the number of APIs in use grows, so does the attack surface of an organization. According to a recent industry study by Enterprise Strategy Group (ESG) titled “Securing the API Attack Surface”, the majority (75%) of organizations typically change or update their APIs on a daily or weekly basis, creating a significant challenge for protecting the dynamic nature of API attack surfaces.

API security is critical because APIs are often the important link in the security chain of modern applications. Developers often prioritize speed, features, functionality, and ease of use over security, which can leave APIs vulnerable to attacks. Additionally, cloud-native APIs are often exposed directly to the internet, making them accessible to anyone. This can make it easier for hackers to exploit vulnerabilities in your APIs and gain access to your cloud-based applications. As evidence, the same ESG study also revealed most all (92%) organizations have experienced at least one security incident related to insecure APIs in the past 12 months, while the majority of organizations (57%) have experienced multiple security incidents related to insecure APIs during the past year.

One of the biggest challenges in protecting an API environment is the proliferation of Shadow APIs. Shadow APIs are APIs that are used by developers or business units without the knowledge or approval of IT security teams. These APIs can be created by anyone with the technical knowledge to build them, and because they are not managed by the IT department they are often not subject to the same security controls and governance policies as officially sanctioned APIs.

Shadow APIs lack clarity of priority, ownership, and security policy controls. They often have a business purpose such as supporting features in a mobile and web applications, but no one is sure whether these APIs are running in production or non-production, who the clear owners are, and which security policy controls should be applied to protect them from attack. For example, a developer may create an API to streamline a workflow, or a business unit may create an API to integrate a third-party application. However, when these APIs are not properly vetted, tested, and secured, they can pose a significant risk to the organization. Shadow APIs can introduce vulnerabilities, such as unsecured endpoints, weak authentication mechanisms, and insufficient access controls, which can be exploited by attackers to gain unauthorized access to sensitive data.

Another challenge facing organizations is the emergence of Zombie APIs. Zombie APIs are APIs that are no longer in use but are still active on the network and running in the cloud. These APIs can be left over from legacy systems, previous versions of the API, or retired applications; or they may have been created by developers who have since left the organization. Zombie APIs can be particularly dangerous because they may not be monitored or secured, making them vulnerable to exploitation.

While Zombie APIs do not have a clear business purpose, they consume resources, can add an expense for organizations, and create additional attack surface. For example, a Zombie API can be an older version of an API that is no longer connected to its original application but left in place for potential backward compatibility reasons. However, over time that legacy API is forgotten, yet its underlying resources (compute, storage, databases) that fuel the API’s operations are left running without proper oversight, maintenance, and security hardening. Attackers can use these APIs to gain unauthorized access to sensitive data, bypass security controls, and launch lateral movement attacks against other systems on the network. Zombie APIs can also be used to launch Server-Side Request Forgery (SSRF) or remote code execution (RCE) attacks, which can bring down entire systems and cause significant damage to an organization’s reputation as seen with the Capital One Breach and Log4shell global exploits, respectively.

To mitigate the risks posed by Shadow and Zombie APIs, organizations must take a proactive approach to API management and security. This includes developing a comprehensive API management strategy that includes security controls, active monitoring, and reporting capabilities.

One key aspect of API management is the establishment of a centralized API inventory catalog. This catalog should include all approved APIs, along with information about their functionality, usage, and security controls. This can help IT and security teams identify Shadow APIs and Zombie APIs, as well as track and monitor API usage to ensure compliance with governance policies.

Another important aspect of API management is the implementation of security controls. These may include encryption, access controls, authentication mechanisms, and threat detection and response capabilities. Security controls should be implemented at all layers of the API stack, from the application layer to the transport and infrastructure service layers, to ensure that APIs are protected against a wide range of attacks.

In addition, organizations should also implement scanning, observability, dynamic analysis and reporting capabilities to detect and respond to API-related threats. This may include real-time scanning of API usage, logging and run-time analysis of API activity, and alerting and reporting capabilities to notify IT and security teams of potential threats.

When it comes to securing APIs and reducing attack surfaces, Cloud Native Application Protection Platform (CNAPP) is a newer security framework that provides security specifically for cloud-native applications by protecting them against various API attacks threats. CNAPPs do three primary jobs: (1) artifact scanning in pre-production; (2) cloud configuration and posture management scanning; (3) run-time observability and dynamic analysis of applications and APIs, especially in production environments. With CNAPP scanning pre-production and production environments, an inventory list of all APIs and software assets is generated. If the dynamically generated inventory of cloud assets has APIs connected to them, Shadow or Zombie APIs can be discovered. As a result, CNAPPs help to identify these dangerous classes of APIs and help to add layers of protection to prevent them from causing harm and exposure from vulnerable API attack surfaces.

Ultimately, the key to managing the risks posed by expanding API attack surfaces with Shadow and Zombie APIs is to take a proactive approach to API management and security. When it comes to cloud security, CNAPP is well suited for organizations with cloud-native applications, microservices, and APIs that require application-level security. API security is a must-have when building out cloud-native applications, and CNAPP offers an effective approach for protecting expanding API attack surfaces, including those caused by Shadow and Zombie APIs.

The post Shadow APIs and Zombie APIs are Common in Every Organizations’ Growing API Attack Surface appeared first on Cybersecurity Insiders.

By Doug Dooley, COO, Data Theorem

The software supply chain has become increasingly complex and dynamic with the rise of cloud computing, open-source software, and third-party software components and APIs. Widespread damage can occur for organizations if third-party APIs, cloud services, SDKs, and open-source software have security flaws. As a result, software supply chain security has emerged as a critical concern for organizations across industries. Supply chain attacks have become more frequent, sophisticated, and devastating, as evidenced by high-profile incidents such as SolarWinds, Kaseya and Apache Log4j.

To address the growing challenge of software supply chain security, organizations have turned to leveraging software bill of materials (SBOMs). SBOMs are a standardized inventory of software components used in a particular product or system, including their versions, dependencies, and sources. SBOMs provide transparency and visibility into the software supply chain. They can be an effective approach for identifying and mitigating security risks, compliance issues, and operational challenges – assuming organizations have the right tools to fully benefit from SBOMs, including runtime discovery, in place.

SBOMs are not a new concept, but their adoption has accelerated in recent years due to a number of important factors, including the following Top Five.

First, regulatory agencies, such as the U.S. National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA), have been advocating for SBOMs as a best practice for software supply chain security. NIST has released a draft guidance document on SBOMs, and CISA has mandated SBOMs for federal contractors and subcontractors.

Second, industry initiatives, such as the Open Source Security Foundation (OpenSSF) and the Software Assurance Forum for Excellence in Code (SAFECode), have promoted SBOMs as a key element of software security. OpenSSF has launched a working group on SBOMs, and published the Open Source Software Security Mobilization Plan to improve the resiliency and security of open source software (OSS), including guidelines for SBOM management; while SAFECode has published a whitepaper on SBOMs.

Third, supply chain attacks have highlighted the need for SBOMs as a proactive and preventive measure. SBOMs can help organizations detect and respond to vulnerabilities, malicious code, and unauthorized changes in the software supply chain. SBOMs can also support incident response and recovery efforts by providing accurate and comprehensive information about the affected software components.

Fourth, customer demands and market pressures have influenced the adoption of SBOMs. Customers are increasingly aware of software supply chain risks and are asking for SBOMs as part of their procurement and evaluation processes. Some industries, such as healthcare and automotive, have mandated SBOMs for safety and liability reasons. SBOMs can also enhance brand reputation, customer trust, and competitive advantage for software vendors.

Fifth, technological advancements have facilitated the creation and consumption of SBOMs. The emergence of open standards, such as CycloneDX and SPDX, has enabled interoperability and integration of SBOMs across different tools and platforms. The development of automated tools, such as software composition analysis (SCA) and vulnerability scanners, has enabled the generation and validation of SBOMs in a timely and accurate manner. The integration of SBOMs with other security measures, such as identity and access management (IAM) and security information and event management (SIEM), has enabled an effective view of software supply chain security.

However, SBOMs are not a silver bullet for software supply chain security. SBOMs are only as good as the data they contain, and the quality of data can vary depending on the source and the method of collection, particularly around the application software stack of APIs, cloud services, and SDKs. SBOM inventory is constantly changing, and being able to leverage their up-to-date data requires more than a snapshot from traditional source code static analysis approaches, but rather continuous runtime analysis and dynamic inventory.

For example, common vendor management and software composition analysis (SCA) approaches often lack source code access for mobile, web, cloud, and commercial-off-the-shelf (COTS) software, as well as third-party API services.

Following a more effective approach, organizations can benefit from a full-stack attack surface management (ASM) software supply chain solution that delivers continuous third-party application asset discovery and dynamic tracking of third-party vendors. These newer approaches automatically categorize assets under known vendors, allow customers to add additional new vendors, curate individual assets under any vendor, and alert on increases in policy violations and high embed rates of third-party vendors within key applications. These automated capabilities allow vendor management teams to remedy supply chain security problems faster and easier, and much more accurately than older approaches.

It is important to note that SBOMs also require collaboration and communication among multiple stakeholders, including software vendors, suppliers, customers, and regulators. SBOMs may also pose some privacy and intellectual property concerns, since they can reveal information about the software components and their relationships.

Overall, organizations need to adopt a comprehensive and risk-based approach to software supply chain security, of which SBOMs and tools to best leverage their information are an important component. Organizations should establish policies and procedures for SBOM creation, management, and sharing, as well as for SBOM validation and verification. Organizations should also integrate SBOMs with other security measures and practices, such as threat modeling, penetration testing, and code review to best ensure the security of their software supply chains.

The post The Rise in SBOM Adoption and How They Can Effectively Improve Software Supply Chain Security Programs appeared first on Cybersecurity Insiders.