YouTuber minutephysics explains how Shor's algorithm builds on existing formulae like Euclid's algorithm and Fourier transforms to leverage quantum superpositioning and break encryption.

The rise of quantum computing and its implications for current encryption standards are well known. But why exactly should quantum computers be especially adept at breaking encryption? The answer is a nifty bit of mathematical juggling called Shor's algorithm. The question that still leaves is: What is it that this algorithm does that causes quantum computers to be so much better at cracking encryption? In this video, YouTuber minutephysics explains it in his traditional whiteboard cartoon style.

"Quantum computation has the potential to make it super, super easy to access encrypted data — like having a lightsaber you can use to cut through any lock or barrier, no matter how strong," minutephysics says. "Shor's algorithm is that lightsaber."

According to the video, Shor's algorithm works off the understanding that for any pair of numbers, eventually multiplying one of them by itself will reach a factor of the other number plus or minus 1. Thus you take a guess at the first number and factor it out, adding and subtracting 1, until you arrive at the second number. That would unlock the encryption (specifically RSA here, but it works on some other types) because we would then have both factors.

One reason why this seemingly simple process relies on the development of powerful quantum computers is that finding the correct power to multiply the first number by in order to find a factor of the second number (N) ± 1 takes an enormous amount of tries. The encryption key is quite a long number and thus the power could be anything from 1 to millions. But brute force is not why quantum computers work so well here.

**The Superpowers of Superpositions**

Briefly, thanks to quantum superpositioning, a quantum computer can calculate many answers for a single input. However, the video says that you only get one answer output at a time, with probabilities attached. To solve that issue, the calculation is set up so that wrong answers interfere with each other so that only the correct answer (or at least a good guess) is likely to be output. That calculation, which focuses on finding the right power _p_, is Shor's algorithm.

It's all extremely mathemagical, involving an assist from Euclid's algorithm, as well as a quantum Fourier transform that turns a series of superpositions of superpositions into sine waves that either constructively (add to each other) or destructively interfere — i.e., cancel each other out. The video says that, essentially, you can rig it so that only 1/_p_ is saved, with all the other answers destructively interfered out of contention. Once you're there, it's a walk in the park to find _p_, which makes finding the two encryption factors a whole lot easier. Watch the whole video for more details, and to maybe feel a little smarter.

By the way, Peter Shor is still thriving, and if you're interested in a deep dive on how he broke the Internet, here's another video where the man himself explains how he figured out his eponymous masterpiece.

How Quantum Physics Leads to Decrypting Common Algorithms

Many enterprise applications are built outside of IT, but we still treat the platforms they're built with as point solutions.

We're used to thinking about securing software-as-a-service (SaaS) platforms and the cloud as two separate beasts. This separation stems from the way SaaS and the public cloud first emerged as small point solutions and an extension of the traditional data center, respectively. Today, due to the advent of low code, this separation is wrong, and it's holding us back from seeing what's right in front of our eyes. Low code makes SaaS platforms a part of the public cloud, a place where developers build multiple applications rather than consuming a single one: a cloud platform.

Failing to shift our mindset leads to where we are today, with those applications being left up for grabs with no security visibility. And to make matters worse, low-code applications are embedded right into platforms like Salesforce and Microsoft Dynamics, which we all use and that hold our most sensitive business data.

**How Did We Get Here?**

Origin stories are always interesting because they explain something fundamental about the way we perceive the hero of the story. While SaaS started as an extension of the corporate network, the public cloud started as an extension of the data center. Those very different starting points explain why securing SaaS started with shadow IT (protecting the perimeter) and securing the public cloud started with workload protection (lift-and-shift servers and their network/host agents). This also meant that different security teams were tasked with securing SaaS and the cloud, which of course led to a separation of tools, different threat modeling, and, most importantly, the formation of different security mindsets.

Both SaaS and the public cloud have drastically evolved from those early days. Public cloud vendors introduced ever more granular compute paradigms, gradually introducing infrastructure as a service (IaaS), platform as a service (PaaS), and serverless to help developers focus on the business problem at hand. They also built an entire ecosystem of ready-made solutions for complex yet common problems — identity, permissions, logging, configuration, and deployment, to name a few.

SaaS used to mean a point solution for a specific problem. Salesforce started as a CRM, ServiceNow as a ticketing system, and Office365 as email, spreadsheets, docs, and slides. (While this is more than one solution, these are very specific ones.) Contrast that with today: Salesforce Developers are building apps for just about any business need on top of the Salesforce Platform, ServiceNow low-code apps are handling just about anything from HR to health and finance processes, and Power Platform, Microsoft's low-code platform embedded into Office365, is being used by more than 20 million users across the industry to solve every business need, from productivity through procurement and COVID-related processes.

Clearly, these have become enterprise-grade application development platforms, not point solutions to specific business problems. Many developers today choose to build their applications on platform-provided abstractions, whether those are serverless functions on the public cloud or extendable building blocks on SaaS low-code platforms.

**The Introduction of Business Developers**

Comparing how SaaS platforms started and where they are now clearly shows how far these have come from their earlier versions. But there's still a major shift we haven't mentioned yet: the introduction of business developers.

SaaS low-code platforms draw their power from the data they maintain and their existing users. Those are both not limited to IT but rather skew heavily toward the business. Having access to both business data and business users means that SaaS is in the perfect position to tackle the most pressing issue many enterprises face today — digital transformation.

With a global shortage of developers and the difficulty of streamlining a business process with so many stakeholders, low-code platforms introduce a shortcut, letting the business users streamline their processes themselves without waiting for IT.

Low code is taking off with business users, so much so that in his 2019 Inspire keynote, Microsoft CEO Satya Nadella discussed the opportunity of low code to empower people and to create new white-collar jobs just like Excel did.

Just like the public cloud is an application development platform enabling developers to focus on their business logic, SaaS platforms have become application development platforms using low code to empower business users to become developers and address any business need.

SaaS is now focused on new types of developers addressing a whole range of unmet business needs with dedicated applications, creating a new type of cloud: the business cloud.

**Securing Low Code as an Extension of Cloud**

With the realization that some SaaS platforms are now application development platforms and an extension of the cloud, we should re-examine the responsibilities for securing those applications and bringing them under the security team's umbrella.

We should treat platforms like Salesforce, ServiceNow, and Office365 the same way we treat AWS, Azure, and GCP, where we focus on the applications that were built and are hosted in these application development platforms rather than treating the whole platform as a single application.

Shadow IT, for example, remains an issue with smaller and an ever-growing number of point-solution SaaS. But it doesn't make sense to treat any single platform mentioned above as a single app to discover and catalog. Instead, we should discover and catalog the applications built with those platforms — and there are tens of thousands of those. In most organizations, this enormous complexity is hidden behind a single line in an application inventory.

Applications built with SaaS low-code platforms should be examined with the same security rigor we use for those built on the cloud because, at the end of the day, an application is an application, no matter where it was built and hosted.

What does matter for the security of our business applications is the people, process, and tools that are involved in making, maintaining, and protecting those applications. For applications built in the cloud, we have professional developers, automated CI/CD processes, and various security tools from code scanning and dynamic analysis through runtime monitoring and prevention. For applications built on SaaS low-code platforms, we have some professional developers but also business users who are not security-savvy, with few to no deployment processes and no security controls or guarantees.

Thinking about low-code platforms as part of SaaS makes it difficult for us to see that a huge portion of our business applications are now being built by the business, outside of IT and outside of security control. To begin seeing the problem and figuring out our approach to it, we must shift our mindset to acknowledge low-code platforms as a part of the cloud and treat the applications on those platforms like we do any other application.

We're Thinking About SaaS the Wrong Way

Slack, Docker, Kubernetes, and other applications that allow developers to collaborate have become the latest vector for software supply chain attacks.

Developers are increasingly under attack through the tools that they use to collaborate and to produce code — such as Docker, Kubernetes, and Slack — as cybercriminals and nation-state actors aim to access the valuable software that developers work on every day.

For instance, an attacker claimed on Sept. 18 to have used stolen Slack credentials to access and copy more than 90 videos representing the early development of Grand Theft Auto 6, a popular game from Take-Two Interactive's Rockstar Games. And a week earlier, security firm Trend Micro discovered that attackers were systematically searching for and attempting to compromise misconfigured Docker containers.

Neither attack involved vulnerabilities in the software programs, but security missteps or misconfiguration are not uncommon on the part of developers, who often fail to take the care necessary to secure their attack surface area, says Mark Loveless, a staff security engineer at GitLab, a DevOps platform provider.

"A lot of developers don't think of themselves as targets because they are thinking that the finished code, the end result, is what attackers are going after," he says. "Developers often take security risks — such as setting up test environments at home or taking down all the security controls — so they can try out new things, with the intent of adding security later."

He adds, "Unfortunately, those habits become replicated and become culture."

Attacks against the software supply chain — and the developers who produce and deploy software — have grown quickly in the past two years. In 2021, for example, attacks that aimed to compromise developers' software — and the open source components widely used by developers — grew by 650%, according to the "2021 State of the "Software Supply Chain" report, published by software security firm Sonatype.

**Developer Pipelines & Collaboration in the Sights**

Overall, security experts maintain that the fast pace of continuous integration and continuous deployment environments (CI/CD) that form the foundations of DevOps-style approaches pose significant risks, because they are often overlooked when it comes to implementing hardened security.  

    

Slack, Teams, and Zoom top the synchronous tools used by professional developers. Source: StackOverflow

  
This affects a variety of tools used by developers in their efforts to create more efficient pipelines. Slack, for example, is the most popular synchronous collaboration tools in use among professional developers, with Microsoft Teams and Zoom coming in a close second and third, according to the 2022 StackOverflow Developer Survey. In addition, more than two-thirds of developers use Docker and another quarter use Kubernetes during development, the survey found.

Breaches of tools like Slack can be "nasty," because such tools often perform critical functions and usually only have perimeter defenses, Matthew Hodgson, CEO and cofounder of messaging-platform Element, said in a statement sent to Dark Reading.

"Slack is not end-to-end encrypted, so it’s like the attacker having access to the company’s entire body of knowledge," he said. "A real fox-in-the-henhouse situation."

**Beyond Misconfigs: Other Security Woes for Developers**

Cyberattackers, it should be noted, don't just probe for misconfigurations or lax security when it comes to going after developers. In 2021, for example, a threat group's access to Slack through the gray-market purchase of a login token led to a breach of game giant Electronic Arts, allowing the cybercriminals to copy nearly 800GB of source code and data from the firm. And a 2020 investigation into Docker images found that more than half of the latest builds have critical vulnerabilities that put any application or service based on the containers at risk.

Phishing and social engineering are also plagues in the sector. Just this week, developers using two DevOps services — CircleCI and GitHub — were targeted with phishing attacks. 

And, there is no evidence that the attackers targeting Rockstar Games exploited a vulnerability in Slack — only the claims of the purported attacker. Instead, social engineering was likely way to bypass security measures, a Slack spokesperson said in a statement.

"Enterprise-grade security across identity and device management, data protection, and information governance is built into every aspect of how users collaborate and get work done in Slack," the spokesperson said, adding: "These \[social engineering\] tactics are becoming increasingly common and sophisticated, and Slack recommends all customers practice strong security measures to guard their networks against social engineering attacks, including security awareness training."

**Slow Security Improvements, More Work to Do**

Developers have only slowly accepted security as application security professionals call for better controls, however. Many developers continue to leak "secrets" — including passwords and API keys — in code pushed to repositories. Thus, development teams should focus on not just protecting their code and preventing the importing of untrusted components but also ensuring that the critical capabilities of their pipelines are not compromised, GitLab's Loveless says.

"The whole zero-trust part, which is typically about identifying people and things like that, there also should be the same principles that should apply to your code," he says. "So don't trust the code; it has to be checked. Having people or processes in place that assumes the worst — I'm not going to trust it automatically — particularly when the code is doing something critical, like build a project."

In addition, many developers still do not use basic measures to strengthen authentication, such as using multifactor authentication (MFA). There are changes afoot, however. Increasingly, the various open source software package ecosystems have all started requiring that major projects adopt multifactor authentication.   

In terms of tools to focus on, Slack has gained attention because of the latest major breaches, but developers should strive for a baseline level of security control across all of their tools, Loveless says.

"There are ebbs and flows, but it is whatever works for the attackers," he says. "Speaking from my experience of wearing all kinds of hats of different colors, as an attacker, you look for the easiest way in, so if another way becomes easier, then you say, 'I will try that first.'"

GitLab has seen this follow-the-leader behavior in its own bug bounty programs, Loveless notes.

"We see when people send in bugs, all the sudden something — a new technique — will become popular, and a whole slew of submissions resulting from that technique will come in," he says. "They definitely come in waves."

App Developers Increasingly Targeted via Slack, DevOps Tools

The ongoing ad fraud campaign can be traced back to 2019, but recently expanded into the iOS ecosystem, researchers say.

The threat actors behind a newly discovered malicious advertising app operation have been active since at least 2019, but researchers tracking their evolution report the group has become more sophisticated, expanding beyond its previous Android-specific attacks into the iOS ecosystem.

The latest campaign, according to researchers with Human Security's Satori research team, included 80 Android Apps lurking in the Google Play store and, notably, 9 in the Apple App Store. All together, the team reported the malicious applications were downloaded at least 13 million times.

Once downloaded, the malicious applications spoof other apps to rack up digital ad views, play hidden ads the user couldn't see to gain fraudulent views, and even track legitimate ad clicks to hone the group's ability to fake them more convincingly later.

The research team, which flagged the apps for removal from the official stores, calls this latest iteration of the attack group Scylla. The earliest version of the group was called Poseidon, then Charybdis. Scylla is the third wave of attacks from the threat actors, the Human team explained in their report.

"Today's announcement of the disruption of Scylla — named after the granddaughter of Poseidon — reflects a new evolution from the threat actors behind the scheme," the Human team said about the find. "While the Poseidon and Charybdis operations centered wholly on Android apps, the Satori team has found evidence that Scylla additionally targets iOS apps and has expanded the attack to other parts of the digital advertising ecosystem."

Human Security worked with Google and Apple to remove the malicious applications and is continuing to work with advertising software development kit developers to mitigate the campaign's fallout.

"These tactics, combined with the obfuscation techniques first observed in the Charybdis operation, demonstrate the increased sophistication of the threat actors behind Scylla," the Human team added. "This is an _ongoing_ attack, and users should consult the list of apps in the report and consider removing them from all devices."

Malicious Apps With Millions of Downloads Found in Apple App Store, Google Play

The bug allows unauthenticated code execution on the company's firewall products, and CISA says it poses "significant risk" to federal government.

The US Cybersecurity and Infrastructure Security Agency (CISA) is warning that a critical Zoho ManageEngine remote code execution (RCE) flaw, first disclosed in June, is now under active attack. 

According to Zoho's patch advisory, the bug "could allow remote attackers to execute arbitrary code on affected installations." 

Multiple Zoho ManageEngine products are affected, CISA said, including the Zoho ManageEngine PAM360, Password Manager Pro, and Access Manager Plus. 

Authentication is not required to exploit the vulnerability in Password Manager Pro and PAM360 products, Zoho added.

CISA has moved to add the Zoho ManageEngine bug to the Known Exploited Vulnerabilities catalog, which indicates the bug (CVE-2022-35405) is both under active exploit and poses a threat to the federal government's systems. 

CISA advises federal agencies to apply the vendor patch immediately. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

CISA: Zoho ManageEngine RCE Bug Is Under Active Exploit

Cybercriminals took control of enterprise Exchange Servers to spread large amounts of spam aimed at signing people up for bogus subscriptions.

Attackers are deploying malicious OAuth applications on compromised cloud tenants, with the goal of taking over Microsoft Exchange Servers to spread spam.  

That's according to the Microsoft 365 Defender Research Team, which detailed this week how credential-stuffing attacks have been launched against high-risk accounts that don’t have multifactor authentication (MFA) enabled, then leveraging unsecured administrator accounts to gain initial access.

The attackers were subsequently able to create a malicious OAuth app, which added a malicious inbound connector in the email server.

**Modified Server Access**

"These modifications to the Exchange server settings allowed the threat actor to perform their primary goal in the attack: sending out spam emails," the researchers noted in a blog post on Sept. 22. "The spam emails were sent as part of a deceptive sweepstakes scheme meant to trick recipients into signing up for recurring paid subscriptions."

The research team concluded that the hacker's motive was to spread misleading spam messages about sweepstakes, inducing victims to hand over credit card information to enable a recurring subscription that would offer them "the chance to win a prize."

"While the scheme likely resulted in unwanted charges to targets, there was no evidence of overt security threats such as credential phishing or malware distribution," the research team noted.

The post also pointed out that a growing population of malicious actors have been deploying OAuth applications for various campaigns, from backdoors and phishing attacks to command-and-control (C2) communication and redirections.

Microsoft recommended implementing security practices like MFA that strengthen account credentials, as well as conditional access policies and continuous access evaluation (CAE).

"While the follow-on spam campaign targets consumer email accounts, this attack targets enterprise tenants to use as infrastructure for this campaign," the research team added. "This attack thus exposes security weaknesses that could be used by other threat actors in attacks that could directly impact affected enterprises."

**MFA Can Help, but Additional Access Control Policies Required**

“While MFA is a great start and could have helped Microsoft in this case, we have seen in the news recently that not all MFA is the same," notes David Lindner, CISO at Contrast Security. "As a security organization, it is time we start from 'the username and password is compromised' and build controls around that."

Lindner says the security community needs to start with some basics and follow the principle of least privilege to create appropriate, business-driven, role-based access control policies.

"We need to set appropriate technical controls like MFA — FIDO2 as your best option — device-based authentication, session timeouts, and so on," he adds.

Lastly, organizations need to monitor for anomalies such as "impossible logins" (i.e., login attempts to the same account from, say, Boston and Dallas, that are 20 minutes apart); brute-force attempts; and user attempts to access unauthorized systems.

"We can do it, and we can greatly increase the security posture of an organization overnight by tightening our authentication mechanisms,” Lindner says.

Cyberattackers Compromise Microsoft Exchange Servers via Malicious OAuth Apps

Manufacturers need to document a medical device's intended use and operational environment, as well as plan for misuse, such as a cyberattack.

Due to the increasing concerns about medical devices' cybersecurity risks, European Union regulators put forward a new set of market entry requirements for medical devices and in vitro diagnostic medical devices to reduce the risk of patient harm as a result of a cyber incident, as well as protect national health systems.

EU regulators are raising the bar on cybersecurity requirements with the European Union Medical Device Regulation (MDR) and the European Union In Vitro Diagnostic Regulation (IVDR), which went into effect May 26, 2021. The regulations are intended to "establish a robust, transparent, predictable and sustainable regulatory framework ... which ensures a high level of safety and health whilst supporting innovation."

Organizations have until May 26, 2024, or when their current market certification expires, to make the necessary changes to their quality management systems and technical documentation to comply with the new requirements. Despite the number of assessment processes and standards and guidance documents that have been provided, medical device manufacturers, providers, and certification services may not be ready in time.

More than 90% of currently valid AIMDD/MDD certificates will expire by 2024, so a significant number of existing devices need to be reapproved, in addition to new devices entering the market. It is estimated that 85% of products currently on the market today still require new certification under MDR.IVDR. Considering that the process takes 13 to 18 months, companies need to start the process now in order to meet the 2024 deadline.

**Setting Instructions for Use**

In general, cybersecurity processes are not that different from general device performance and safety processes. The goal is to assure (through verification and validation) and demonstrate (through documentation) device performance, risk reduction and control, and minimization of foreseeable risks and undesirable side effects through risk management. Combination products or interconnected devices/systems also require management of the risks that result from interaction between software and the IT environment.

The Medical Device Coordination Group's MDCG-16 Guidance on Cybersecurity for medical devices explains how to interpret and fulfill cybersecurity requirements under MDR and IVDR. Manufacturers are expected to take into account the principles of the secure development life cycle, security risk management, and verification and validation. Further, they should provide minimum IT requirements and expectations for cybersecurity processes, such as installation and maintenance in their device's instructions for use. "Instructions for use" is a highly structured required section of the certification application manufacturers must file.

Cybersecurity measures must reduce any risks associated with the operation of medical devices, including cybersecurity-induced safety risks, to provide a high level of protection for health and safety. The International Electrotechnical Commission (IEC) spells out high-level security features, best practices, and security levels in IEC/TIR 60601-4-5. Another IEC technical report, IEC 80001-2-2, enumerates specific design and architecture security capabilities, such as automatic logoff, audit controls, data backup and disaster recovery, malware detection/protection, and system and OS hardening.

To meet ISO guidelines (ISO 14971), the Association for the Advancement of Medical Instrumentation advises striking a balance between safety and security. Careful analysis is required to prevent security measures from compromising safety and safety measures from becoming a security risk. Security needs to be right-sized and should be neither too weak nor too restrictive.

**Sharing Responsibility for Cybersecurity**

Cybersecurity is a responsibility shared between the device manufacturer and the deploying organization (typically the customer/operator). Thus, specific roles that provide important cybersecurity functions — such as integrator, operator, healthcare and medical professionals, and patients and consumers — require careful training and documentation.

The "instructions for use" section of a manufacturer's certification application should provide cybersecurity processes including security configuration options, product installation, initial configuration guidelines (e.g., change of default password), instructions for deploying security updates, procedures for using the medical device in failsafe mode (e.g., enter/exit failsafe mode, performance restrictions in fail-safe mode, and data recovery function when resuming normal operation), and action plans for the user in case of an alert message.

That section should also provide user requirements for training and enumerate required skills, including IT skills required for the installation, configuration, and operation of the medical device. In addition, it should specify requirements for the operating environment (hardware, network characteristics, security controls, etc.) that cover assumptions on the environment of use, risks for device operation outside the intended operating environment, minimum platform requirements for the connected medical device, recommended IT security controls, and backup and restore features for both data and configuration settings.

Specific security information may be shared through documentation other than the instructions for use, such as instructions for administrators or security operation manuals. Such information may include a list of IT security controls included in the medical device, provisions to ensure integrity/validation of software updates and security patches, technical properties of hardware components, the software bill of materials, user roles and associated access privileges/permissions on the device, logging function, guidelines on security recommendations, requirements for integrating the medical device into a health information system, and a list of the network data streams (protocol types, origin/destination of data streams, addressing scheme, etc.).

If the operating environment is not exclusively local but involves external hosting providers, the documentation must clearly state what, where (in consideration of data-residency laws), and how data is stored, as well as any security controls to safeguard the data in the cloud environment (e.g., encryption). The instructions for use section of the documentation needs to provide specific configuration requirements for the operating environment, such as firewall rules (ports, interfaces, protocols, addressing schemes, etc.).

Security controls implemented during premarket activities may be inadequate to maintain an acceptable benefit-risk level during the operational life of the device. Therefore, regulations require the manufacturer to establish a post-market cybersecurity surveillance program to monitor operation of the device in the intended environment; to share and disseminate cybersecurity information and knowledge of cybersecurity vulnerabilities and threats across multiple sectors; to perform vulnerability remediation; and to plan for incident response.

The manufacturer is further responsible for investigating and reporting serious incidents and fielding safety corrective actions. Specifically, incidents that have cybersecurity-related root causes are subject to trend reporting, including any statistically significant increase in the frequency or severity of incidents.

**Planning for All Scenarios**

Today's medical devices are highly integrated and operate in a complex network of devices and systems, many of which may not be under control of the device operator. Therefore, manufacturers should carefully document the device's intended use and intended operational environment, as well as plan for reasonably foreseeable misuse, such as a cyberattack.

Cybersecurity pre- and post-market risk management requirements and supporting activities are not necessarily different from traditional safety programs. However, they do add an additional level of complexity as:

*   The range of risks to consider is more complex (safety, privacy, operations, business). 
*   They require a specific set of activities that need to be conducted along the device development life cycle via a Secure Product Development Framework (SPDF).

Global regulators, including MDR/IVDR, are starting to enforce a higher level of security for medical devices and specifically requiring demonstrable security as part of the larger device life cycle. Devices should meet, based on device type and use case, a security baseline, and manufacturers need to maintain that baseline over the entire lifetime of the device.

How Europe Is Using Regulations to Harden Medical Devices Against Attack

From creating a software bill of materials for applications your company uses to supporting open source projects and maintainers, businesses need to step up their efforts to help reduce risks.

Software is at the core of all modern businesses and is crucial in every aspect of operations. Almost every business will use open source software, knowingly or otherwise, since even proprietary software depends on open source libraries. OpenUK's 2022 "State of Open" report found that 89% of businesses were relying on open source software, but not all of them are clear on the details of the software they rely on.

Businesses are increasingly demanding more information about their operation-critical software. Responsible businesses are taking a detailed interest in their software supply chain and creating a software bill of materials (SBOM) for each application. This level of information is crucial so that when security flaws are identified in their software, they can immediately be certain which software and versions are in use, and which systems are affected. Knowledge is power in these situations!

**Reliance on Volunteers**

In late 2021, a security vulnerability called Log4Shell was identified in a widely used Java logging framework, Log4j. Since this is a widely used, open source library, the vulnerability was well-publicized, and fixes were expected. However, the maintainers of the project were volunteers. They had day jobs and were not on call for urgent security fixes, even if a large number of systems were affected. This vulnerability alone was estimated to have affected 93% of enterprise cloud environments.

At the time, there was some negative press about open source, but the truth is that if this was a closed-source component, the vulnerability may never have been publicly known, leaving organizations open to attack. The open source nature of the library meant that it could be inspected, the problems found, and advice offered by others. So, yes, the maintainers weren't on call for security problems in their volunteer project. The big question, then, is: How did we get into a situation where major companies were depending on software that was the responsibility of someone who does something else to pay their bills?

Neglect of software dependencies is a risky business whatever the license of the software, but when it's open source and very widely used, it becomes especially dangerous. Sticking with the story of one vulnerability; the problem had existed in the codebase for years, but wasn't spotted. The tool that was so widely used was not, in fact, so widely supported — and what happened next is history.

This story is repeated over and over, across so many businesses that have critical dependencies but don't take action to support either the maintainers or the projects themselves. Having an SBOM for the software used by a business means they have the information on hand. For organizations that supply software to others, the expectation of supplying the SBOM alongside the code is increasingly the norm.

**Know Dependencies to Assess Risk**

Bringing knowledge of the dependencies makes it easier to assess the risk associated with each one. These open source projects are the simplest to assess: are issues responded to, and have there been any releases recently? Being able to see the maintainers and project activity for each project gives good insight into the project's health.

Businesses can play their part to reduce the risks by supporting the projects upon which they depend. Some projects accept sponsorship directly via the GitHub Sponsors scheme, others might instead appreciate offers of hosting, or a security audit. Every open source project appreciates contributions. If your business had created this library itself, then the engineers inside the company would have to fix every bug themselves.

Open source is more like a shared ownership scheme. We don't all have to build the same thing repeatedly, but rather can contribute, which is both less effort and leads to better quality as a result. One of the most impactful things businesses can do is use a little of their engineering resources and contribute to bug fixes or features to projects that are so core to the business.

Keeping your own engineers involved in a project has many benefits. They get to know it and can keep an eye on new features, or when a new release is available. Crucially, the business has insight into the health and status of the dependent project and is part of what keeps it healthy, reducing the risk to the business of a problem with a dependency. A number of organizations, including Aiven, have an OSPO (open source program office), with staff dedicated to contributing to or even maintaining the projects used by the organization. These departments often contribute to the general presence of the company in the open source ecosystem and enable other employees to engage with open source.

Another approach is to support the organizations that exist to support open source. The OpenSSF (Open Source Security Foundation) works to improve the security of open source projects and is funded by the organizations that depend on those projects. It also publishes excellent learning resources so that businesses can educate themselves about the risks of the software they use. Another similar organization is Tidelift, which partners with maintainers to ensure certain basic requirements are met, again funded by the organizations. Tidelift also provides tooling and education to help businesses manage their software supply chain and adopt best practices in this area.

**Securing a Safer Software Future**

Businesses depend on software, and this includes open source software, which is widely used and typically more secure than proprietary alternatives.

This is a smart move, but an even smarter move is to have clear knowledge of the software supply chain and its dependencies. When a problem does arise, depending on healthy projects and having the details of your software available helps every organization. If every organization did this, then the risk of having events such as the Log4Shell vulnerability are reduced.

Neglecting Open Source Developers Puts the Internet at Risk

With the update, Microsoft adds features to allow easier deployment of zero-trust capabilities. Considering the 1.3 billion global Windows users, the support could make a difference.

Organizations aiming to boost their security with zero-trust initiatives got some help from Microsoft this week, when the computing giant announced that a slew of zero-trust features are now available in its Windows 11 operating system.

The zero-trust approach to security aims to secure workers' access to sensitive systems, network, and data by using additional context, analysis, and security controls. The goal is to give "the right people the right access at the right time," Microsoft stated in the Windows 11 Security Book, a 74-page report on Windows 11's security architecture.

The model checks a user's identity and location, as well as their device's security status, and only allows access to the appropriate resources, according to the Windows 11 Security Book. In addition, zero-trust capabilities include continuous visibility and analysis to catch threats and improve defenses.

The latest version of the operating system and software platform adds a variety of features, from support for the Pluton security processor and trusted platform modules (TPMs) to comprehensive features around Trusted Boot, cryptography, and code-signing certificates, says David Weston, vice president of enterprise and OS security at Microsoft.

"Organizations worldwide are adopting a zero-trust security model based on the premise that no person or device anywhere can have access until safety and integrity is proven," he says. "We know that our customers need modern security solutions with tightly integrated hardware and software that protects from entire classes of attack."

**The Zero-Trust Buzz Gets a Boost**

The zero-trust concept has been knocking around for years, with technologists and government agencies first discussing it for security with the dawning realization that network perimeters were rapidly disappearing. Then, the work-from-home surge caused by the coronavirus pandemic injected more urgency into the movement. Now, three-quarters of security decision-makers (75%) believe that the increase in hybrid work creates vulnerabilities at their organization, leaving them more open to attacks.

"When employees are given the freedom to choose their work location, device, tools, and/or software, it becomes a challenge to establish trust based on static attributes," says Ben Herzberg, chief scientist at Satori. "As the competitive pressure pushes companies to democratize data and release new customer value faster, employees will be provided more flexibility, and zero trust will be the go-to approach for enabling that flexibility while ensuring security."

That said, implementing zero trust is a complex endeavor, as evidenced by the list of aspects that Microsoft has now built in:

    

Microsoft's Windows 11 security architecture. Source: Microsoft's Windows 11 Security Book.

The new Windows 11 features include Smart App Control, which uses machine learning, AI modeling, and Microsoft's vast telemetry network of 43 trillion daily signals to determine if an application is safe. Other features also determine whether driver code and virtual-machine code have signs of maliciousness. Additional improvements include credential checks in Windows Defender, password-less support with Windows Hello for Business, and protection against credential-harvesting websites, the company stated.

Complexity has hampered zero-trust rollouts, but adding these feature directly into Windows 11 makes it more likely that companies can easily deploy zero-trust capabilities, says Microsoft's Weston.

"Building in instead of bolting on makes deployment and management of zero-trust capabilities much simpler and efficient," he says. "In addition, having these \[features\] directly integrated in the OS enables Windows to provide key measurements in hardware increasing the trust and validity of measurements."

He adds, "The minute zero-trust capabilities are embedded into enterprise infrastructure, it becomes accessible for many companies that would otherwise have a hard time getting access to this technology. ... An integrated client environment for zero trust will make the transition for employees much smoother and internal change management simpler."

Microsoft throwing its considerable weight behind zero trust should indeed move the needle on adoption and overall security: Microsoft sees 2.5 billion endpoint queries and 80 million password attacks on a daily basis, the firm stated in a blog post published this week.

**Zero Trust Is Still Hard**

Even with the Windows 11 updates, companies should expect implementing zero trust to be a process. Building a zero-trust framework requires deep technical integrations, and the organizations that do that best are the ones most likely to be successful in their implementation, says Satori's Herzberg.

To start off, companies should identify a group of users, devices, applications, and workflows that could benefit from zero trust; create a zero-trust architecture to protect those components; and then choose and implement the proper technologies, he says.

An incremental rollout works, given that zero trust is more of a journey than a destination, says Jason Floyd, chief technology officer at Ascent Solutions.

"Zero trust was never about solving a technology problem — it’s a strategic tool directing how to use the technology already in place," he says. "Building additional zero-trust features into Windows does encourage enterprises to adopt a healthy security mindset, but not for the one-size-fits all solution some executives might be expecting."

Overall, Windows 11 adds "chip-to-cloud security," establishing trusted processes starting with firmware and reaching out to workloads running in the cloud, Microsoft's publication stated. This support aids zero-trust architectures by minimizing the work required to prove a user's identity and check system health, says Microsoft's Weston.

"This inverts the previous paradigm of systems security where a user or device was assumed healthy until proven guilty," he says. "Microsoft's view is that the zero-trust philosophy and architecture addresses many of the current and future security challenges for customers and thus Microsoft and most of our customers believe this will be the dominant approach to security."

Microsoft Looks to Enable Practical Zero-Trust Security With Windows 11

Protecting against risk is a shared responsibility that only gets more complex as you mix the different approaches of common cloud services.

More enterprises are taking a multicloud approach as part of their digital transformation efforts to support distributed teams working in hybrid and remote models. And just as hybrid work environments are here to stay, the multicloud approach has taken hold. Gartner predicts global cloud revenue will reach $474 billion in 2022, with 90% of enterprises already working toward a multicloud strategy.

When leveraged correctly, a multicloud strategy can make many processes more efficient. It also offers greater resilience to outages and more vendor flexibility than a single-cloud strategy. Additional advantages include:

*   Avoiding vendor lock-in with one cloud provider. An organization with a global footprint and specialized data can select the location of the data center with the least impact to its business. For instance, Microsoft Azure currently leads in the Middle East from a data center location perspective.
*   The ability to take advantage of distinguishing features offered by each cloud vendor, such as unique database solutions in Google Cloud or the ability to manage your on-premises and cloud resources much more seamlessly in Microsoft Azure.
*   Better costs and business resiliency, with specific services less expensive through a specific vendor and protections against service disruptions. Both require designing your services to leverage the benefits, but once established, your organization can recoup its investment over two to three years, resulting in long-term cost savings.

However, these advantages come at a cost. It can be challenging to ensure data and cloud infrastructure is secure and aligned to your obligations and controls when disparate environments are hosted through multiple providers. Telling a unified story around the data, configuration, and security within those environments can be nearly impossible.

CISOs who are embracing a multicloud data approach must focus on two main security concerns: managing risks posed by vendors and their different cloud operating models, and demonstrating the value of their security controls and strategies in the face of increased costs of operating in a multicloud world.

**Managing Risk Across Clouds**

The impact and frequency of cyberattacks has grown in parallel to the escalating focus on multicloud strategies. Ransomware attacks, data breaches, and major IT outages topped the Allianz Risk Barometer this year for only the second time in the survey's history, with executives ranking them as more worrisome than supply chain disruption, natural disasters, and the pandemic. Companies are right to show concern: Organizations worldwide experienced 50% more weekly cyberattacks in 2021, compared with 2020.

Business leaders are catching up on the importance of cyberattacks, but most are underinformed about risks posed by their vendor partners. In PwC's "2022 Global Digital Trust Insights Survey," 57% of business leaders said they anticipate a jump in attacks on cloud services, but only 37% said they understand cloud risks. The approach and operating models of security vary among cloud providers, and protecting against risk is a shared responsibility that only gets more complex as you add common cloud services that use different approaches, such as identity and access management (IAM) or virtualized servers.

For example, different cloud vendors have their own approach to role-based access. Amazon Web Services handles identity by attaching IAM policies directly to a virtual server, which grants the server the ability to take actions. Google Cloud's offering, in contrast, focuses on creating service accounts (users) and then attaching those accounts to the server so it can interact with another resource. These small differences add up at enterprise scale, driving security complexity to ensure least privilege and other security requirements across both clouds.

Because cloud services aren't designed to integrate with their competitors, learning how to use security tools for each cloud provider is just the beginning. IT teams will need to centralize their security monitoring with a security information event management (SIEM) tool, along with other third-party tools to increase interoperability of cloud services. These added systems require additional training and resources and perhaps even additional IT staffing to ensure expertise in each cloud platform _and_ how those platforms work together.

In addition to these in-built differences between their services, most cloud vendors prioritize their own specifically tailored security offerings. This drives a host of complications that plague cloud security. For one example, a cloud Web application firewall (WAF) can be used to protect your network, but it will only work with a specific cloud service provider and cannot be expanded across multiple cloud offerings. Duplicating these functionalities for different providers requires either duplicating teams to support and manage these key security tools or buying a cloud-agnostic service — which adds yet another vendor to the mix.

This additional risk and cost, typically not discovered until late in the deployment of a multicloud model, can push out timelines, increase cost, and trigger audit findings. Failure to plan for and mitigate these risks can leave a company susceptible to financial loss, regulatory action, litigation, and reputational damage.

**Communicating Value With Risk Quantification**

Gartner estimates that by 2023, 30% of CISOs' effectiveness will hinge on their ability to demonstrate value. As multicloud data strategies become the norm and the cost of security controls within that strategy increases, risk quantification can help leaders communicate their value consistently by expressing the multicloud risk posture in clear monetary values.

According to PwC, organizations that reported the most significant improvement in data trust outcomes had two things in common: They predicted an increase in their cybersecurity spending, and they incorporated business intelligence and data analytics into their operational models, including risk quantification.

To assess the financial risks of a multicloud strategy, CISOs must take into account the costs of each platform weighed against their perceived risks. Those considerations must include the data management and cybersecurity practices of all the cloud providers you're considering, along with any cloud-agnostic tools and platforms you'll be using for joint monitoring.

With so many factors at play, you can't afford to rely on imprecise, gut-feel measuring scales like "low, medium, high" and "red, yellow, green." Expressing risk data in financial terms is a powerful tool because it offers a common language to communicate changing risk priorities, improve alignment between CISOs and the board, and facilitate better-informed risk management decisions.

Here's an example: A CISO is looking at the financial value associated with the various risks of multicloud architecture. By comparing tactics for mitigating a cybersecurity incident, they find that better controls over administrative privileges reduce the financial cost of the event far more than implementing a cybersecurity training program. While the CISO understands the technical details of cyber-risk within multicloud architecture, the rest of the C-suite will benefit from the clarity of monetary values associated with each risk and mitigation tactic. By empowering CISOs to make their case to their colleagues and the board, risk quantification brings more transparency to the many moving parts of a multicloud strategy.

According to Gartner, more than 85% of organizations will function as cloud-first by 2025, and they won't be able to fully realize their digital strategies without using cloud-native technologies. A Gartner leader put it this way: "There is no business strategy without a cloud strategy."

It's imperative that business leaders pursue strategies to safeguard their data and communicate their multicloud priorities, aligning across the organization with a common language of value.

Source

DARKReading