Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label CSP. Show all posts

Challenges With Software Supply Chain & CNAPP


In 2021, sales of CNAPP exceeded $1.7 billion, an increase of roughly 49% over 2020, according to a recent Frost & Sullivan analysis. According to Frost & Sullivan, CNAPP revenue growth will average over 26% annually between 2021 and 2026.

Anh Tien Vu, industry principal for international cybersecurity and the author of the report, projects that by 2026, revenues will surpass $5.4 billion "due to the increasing demand for a unified cloud security platform that strengthens cloud infrastructure security and protects applications and data throughout their life cycle."

How Does CNAPPs Function?

CNAPP platforms combine many security technologies and features to cut down on complexity and expense, offering:
  • The capabilities of the CSPM, CIEM, and CWPP tools are combined across the development life cycle, correlation of vulnerabilities, context, and linkages.
  • Identifying high-risk situations with detailed context.
  • Automatic and guided cleanup to address flaws and configuration errors.
  • Barriers to stopping unauthorized alterations to the architecture.
  • Simple interaction with SecOps ecosystems to quickly deliver notifications.
Security teams must transition from guarding infrastructure to guarding workload-running applications in order to maximize cloud security and compliance, enable DevOps, and reduce friction. That entails, at the very least, protecting the security of the production environment and cloud service configurations, with runtime protection serving as an important extra layer of security.

Attackers are focusing more and more on cloud-native targets in an effort to find vulnerabilities that may be used to compromise the software supply chain. The widespread effect that a vulnerability of this kind can have on the application environment was demonstrated by the Log4Shell flaw in the widely used Log4j Java runtime library last year.

Melinda Marks, a senior analyst at Enterprise Strategy Group, claims that while CNAPP helps businesses to set up DevSecOps processes where software engineers take the initiative to find potential bugs in code before delivering application runtimes into production, it also goes beyond. Before you release your applications to the cloud, this is crucial for preventing security risks since once you do, hackers can access them.

The scanning of development artifacts like containers and infrastructure as code (IaC), cloud infrastructure management (CIEM), runtime cloud workload protection platforms, and cloud security posture management (CSPM) are just a few of the siloed capabilities that CNAPPs combine. Together with a more uniform approach and improved awareness of the risk associated with cloud-native computing environments, CNAPP offers standard controls to reduce vulnerabilities.

Significantly, CNAPP also promotes communication between teams working on application development, cybersecurity, and IT infrastructure, opening the door to finding and fixing flaws before apps are put into use. CNAPP features are being added to security platforms by security manufacturers like Check Point and Palo Alto Networks. Marks cautions against the common misunderstanding that shifting security left is all about putting security first during the software development and build process.





The Cloud Shared Responsibility Model: An Overview

 

Control over security is mostly at the purview of internal teams when an organisation manages its own on-premise data centres. They are in charge of maintaining the security of both the data stored on servers and the servers themselves. 

With the introduction of a cloud service provider (CSP), the security discussion in a hybrid or cloud environment invariably changes. While the CSP is in charge of various security measures, clients frequently "over trust" cloud providers to keep their data secure. 

According to a recent McAfee report, 69% of CISOs have confidence in their cloud service providers to protect their data, and 12% think that cloud service providers are completely in charge of data security. 

In reality, everyone has a role to play in maintaining cloud security. The cloud shared responsibility concept was developed by CSPs like Amazon Web Services (AWS) and Microsoft Azure to inform cloud consumers of their responsibilities (SRM). 

In its most basic form, the cloud shared responsibility model signifies that CSPs are in charge of the cloud's security and that customers are in charge of protecting the data they upload to the cloud. Customer obligations will be decided by the deployment type—IaaS, PaaS, or SaaS. 

Infrastructure-as-a-Service (IaaS) 

IaaS services increase customers' security responsibilities while being designed to give them the maximum level of flexibility and administrative control. Let's utilise Amazon Elastic Compute Cloud (Amazon EC2) as an illustration. 

Customers are in charge of managing the guest operating system, any applications they install on these instances, and the configuration of the offered firewalls when they deploy an Amazon EC2 instance. They are also in charge of managing data, categorising assets, and putting the right permissions in place for identity and access management. 

IaaS consumers have a lot of control, but they can rely on CSPs to provide security in terms of physical, infrastructure, network, and virtualization. 

Platform-as-a-Service (PaaS) (PaaS) 

Most of the labor-intensive tasks are delegated to CSPs in PaaS. CSPs manage running the underlying infrastructure, including guest operating systems, while customers concentrate on building and administering applications (as well as managing data, assets, and rights). PaaS has definite advantages in terms of efficiency. Security and IT personnel recovery time that may be devoted to other urgent issues by not having to worry about patching or other operating system changes. 

Software-as-a-Service (SaaS) 

SaaS imposes the highest level of duty on the CSP out of the three deployment options. Customers are solely responsible for controlling data and user access/identity permissions because the CSP manages the complete infrastructure and the apps. Customers merely need to choose how they wish to utilise the software, as the service provider will manage and maintain it.

The Shared Responsibility Model: How to Keep Your End of the Deal

It is predicted that consumer errors would account for at least 95% of cloud security failures through 2023. Because of this, it's more crucial than ever to dispel misconceptions about the cloud-shared responsibility model and position customers for success. A consistent theme persists despite the obvious changes in duties based on deployment types: it is crucial that organisations be able to see communications between devices, identify potential security concerns in real time, and quickly investigate and fix problems. More security in your cloud investment comes from the absence of black space and quicker response times.

Expert Posts About Blogger's CSP Flaw

A cybersecurity expert found a strategy to escape Content Security Policy (CSP) functions via WordPress. The hack, found by Paulos Yibelo, depends on exploiting origin method execution. The strategy incorporates JSON padding to execute a function. 

It allows the exploit of a WordPress account, however, along with cross-site scripting (XSS) exploit, that the expert doesn't have as of now. Yibelo hasn't tried to use the trick on live websites yet, limiting the exploits for test research websites owned by the experts. 

“I haven’t really attempted to because it requires a logged-in WordPress user or admin to visit my website, so I install the plugin and have an HTML injection – which is illegal to do," said Yibelo. He also mentioned that they didn't try to abuse the bug in the open on bug bounty forums. 

The exports informed WordPress about the issue three months ago, however, the latter didn't reply. It was then that Yibelo published the findings publically on a tech blogpost. 

Attacks may happen in two situations: First, websites that don't use WordPress primarily but have a WordPress endpoint on the same domain or subdomain. Second, a WordPress-hosted website that uses a CSP header. 

Yibelo's blog says if an attacker finds an HTML injection vulnerability within the main domain (ex: website1.com – not WordPress,) using this vulnerability, they can use a WordPress endpoint to upgrade a useless HTML Injection to a full-blown XSS that can be escalated to perform [remote code execution] RCE. This means having WordPress anywhere on the site defeats the purpose of having a secure CSP. 

Yibelo hopes that wordpress fixes this issue soon for CSP to stay relevant on WordPress endpoint hosting sites. CSP is a technology established by sites and in use by browsers that may restrict resources and block XSS attacks. 

Port Swigger reports "CSP is a browser security mechanism that aims to mitigate XSS and some other attacks. It works by restricting the resources (such as scripts and images) that a page can load and restricting whether a page can be framed by other pages."