cloud

Mar 30 2021

Zimperium Collaborates with Oracle to Provide Mission Critical Mobile Security to Customers

Today, Zimperium – a leader in enterprise mobile security and a member of Oracle PartnerNetwork (OPN) – announced that we are collaborating with Oracle to offer our mobile threat defense (MTD) solutions on Oracle Cloud Infrastructure (OCI). We are working together with Oracle to help enterprises around the world combat advanced mobile threats.

Zimperium offers the only real-time, on-device, machine learning-based protection against Android, iOS, and Chromebooks threats. Zimperium zIPS protects mobile endpoints against device compromises, network-based risks, phishing, and mobile malware. And Zimperium MAPS (Mobile Application Protection Suite) identifies security, privacy, and compliance risks during mobile app development and protects apps from attacks while in use.

We are now joining a notable group of ISV partners that Oracle has selected for comprehensive sales and marketing support, as well as go-to-market initiatives enabled through its Oracle PartnerNetwork (OPN).

“We are excited to work with Zimperium, the provider of the only MTD solution that runs natively in Oracle Cloud Infrastructure,” said Dave Profozich, senior vice president, Oracle ISV Ecosystem, Oracle. “With Zimperium, Oracle customers can help protect the mobile endpoints and applications that are enabling crucial initiatives such as remote working, bring your own device (BYOD) and zero trust.”

We are a new security Oracle Cloud Marketplace partnership with real-time, on-device machine learning-based protection. While native OCI features help establish the robust security of the platform with simple, prescriptive, and automated security services, Zimperium complements these protections for customers who utilize both Oracle and Zimperium to secure their workloads.

“Our direct working relationship with Oracle protects enterprises around the world against advanced mobile threats and risks,” said Shridhar Mittal, CEO of Zimperium. “Our mutual customers benefit from OCI’s global scalability and cost savings, as well as from Oracle’s world-class cloud solution architects working closely with Zimperium engineering to accelerate automation, deployment and delivery of solutions for high performance, large scale and secure environments.”

Zimperium Collaborates with Oracle to Provide Mission Critical Mobile Security to Customers

Source

Mar 26 2021

New Advanced Android Malware Posing as “System Update”

Another week, and another major mobile security risk. A few weeks ago, Zimperium zLabs researchers disclosed unsecured cloud configurations exposing information in thousands of legitimate iOS and Android apps (you can read more about it in our blog). This week, zLabs is warning Android users about a sophisticated new malicious app.

The new malware disguises itself as a System Update application, and is stealing data, messages, images and taking control of Android phones. Once in control, hackers can record audio and phone calls, take photos, review browser history, access WhatsApp messages, and more (a complete list is below).

The “System Update” app was identified by zLabs researchers who noticed an Android application being detected by the z9 malware engine powering zIPS on-device detection. Following an investigation, we discovered it to be a sophisticated spyware campaign with complex capabilities. We also confirmed with Google that the app was not and has never been on Google Play.

In this blog, we will:

Cover the capabilities of the spyware;
Discuss the techniques used to collect and store data; and
Show the communication with the C&C server to exfiltrate stolen data.

What can the malware do?

The mobile application poses a threat to Android devices by functioning as a Remote Access Trojan (RAT) that receives and executes commands to collect and exfiltrate a wide range of data and perform a wide range of malicious actions, such as:

Stealing instant messenger messages;
Stealing instant messenger database files (if root is available);
Inspecting the default browser’s bookmarks and searches;
Inspecting the bookmark and search history from Google Chrome, Mozilla Firefox, and Samsung Internet Browser;
Searching for files with specific extensions (including .pdf, .doc, .docx, and .xls, .xlsx);
Inspecting the clipboard data;
Inspecting the content of the notifications;
Recording audio;
Recording phone calls;
Periodically take pictures (either through the front or back cameras);
Listing of the installed applications;
Stealing images and videos;
Monitoring the GPS location;
Stealing SMS messages;
Stealing phone contacts;
Stealing call logs;
Exfiltrating device information (e.g., installed applications, device name, storage stats); and
Concealing its presence by hiding the icon from the device’s drawer/menu.

How does the malware work?

Upon installation (from a third party store, not Google Play Store), the device gets registered with the Firebase Command and Control (C&C) with details such as the presence or absence of WhatsApp, battery percentage, storage stats, the token received from the Firebase messaging service, and the type of internet connection.

Options to update the mentioned device information exist as “update” and “refreshAllData,” the difference being, in “update,” the device information alone is being collected and sent to C&C, whereas in “refreshAllData,” a new Firebase token is also generated and exfiltrated.

The spyware’s functionality and data exfiltration are triggered under multiple conditions, such as a new contact added, new SMS received or, a new application installed by making use of Android’s contentObserver and Broadcast receivers.

Commands received through the Firebase messaging service initiate actions such as recording of audio from the microphone and exfiltration of data such as SMS messages. The Firebase communication is only used to issue the commands, and a dedicated C&C server is used to collect the stolen data by using a POST request.

Figure 1: Code to parse and execute the commands from Firebase C&C (refer to IOCs)

The spyware is looking for any activity of interest, such as a phone call, to immediately record the conversation, collect the updated call log, and then upload the contents to the C&C server as an encrypted ZIP file. Determined to leave no traces of its malicious actions, the spyware deletes the files as soon as it receives a “success” response from the C&C server on successfully receiving the uploaded files.

Figure 2: Broadcast receiver declaration in AndroidManifest.xml

The collected data is organized into several folders inside the spyware’s private storage, located at: “/data/data/com.update.system.important/files/files/system/FOLDER_NAME” where the “FOLDER_NAME” is specified as shown in the following image.

Figure 3: Names of folders for storing stolen data in the app’s private directory

Along with the command “re” for recording the audio from the microphone, the parameters received are “from_time” and “to_time,” which is used to schedule an OneTimeWorkRequest job to perform the intended malicious activity. Such usage of job scheduling can be affected by battery optimizations applied on applications by the Android OS, due to which, the spyware requests permission to ignore battery optimizations and function unhindered.

Figure 4: Scheduling a job using parameters from the Firebase C&C

Figure 5: Code to prevent battery optimizations on the spyware application

Being very concerned about the freshness of the data, the spyware doesn’t use data collected before a fixed period.

For example, location data is collected either from the GPS or the network (whichever is the more recent) and if this most recent value is more than 5 minutes in the past, it decides to collect and store the location data all over again. The same applies to photos taken using the device’s camera, and the value is set to 40 minutes.

Figure 6: Code to capture a picture using the camera if last taken is at least 40 mins ago

The spyware abuses the device’s Accessibility Services (gained from social engineering by asking users to enable accessibility services) to collect conversations and message details from WhatsApp by scraping the content on the screen after detecting the package name of the top window matches WhatsApp (“com.whatsapp”). The collected data is stored within an SQLite database with a model, as seen in the images below.

Figures 7: The database models for storing data from Whatsapp

In addition to collecting the messages using the Accessibility Services, if root access is available, the spyware steals the WhatsApp database files by copying them from WhatsApp’s private storage.

Figure 8: The six files that get copied from the WhatsApp database if root is available

The spyware actively steals the clipboard data by registering clipboard listeners in just the same way as it spies on SMS, GPS location, contacts, call logs, and notifications. The listeners, observers, and broadcasted intents are used to trigger actions such as recording a phone call and collecting the thumbnails of newly captured images/videos by the victim.

Figure 9: Code to steal data from the clipboard

The Android device’s storage is searched for files smaller than 30MB and having file extensions from the list of “interesting” types (.pdf, .doc, .docx, .xls, .xlsx, .ppt, .pptx) to be copied to the private directory of the application and encrypted as a folder before exfiltration to the C&C server.

Figure 10: Code to search for files with specific extension and size less than 30MB

An aggressive capability of the spyware is to access and steal the contents cached and stored in the external storage. In an attempt to not exfiltrate all the images/videos, which can usually be quite large, the spyware steals the thumbnails which are much smaller in size. This would also significantly reduce the bandwidth consumption and avoid showing any sign of data exfiltration over the internet (assisting in evading detection). When the victim is using Wi-Fi, all the stolen data from all the folders are sent to the C&C, whereas when the victim is using a mobile data connection, only a specific set of data is sent to C&C, as seen in Figure 12.

Figure 11, 12: The code to collect thumbnails, and make a list of folders to upload from a mobile data connection

Apart from the various types of personal data stolen from the victim, the spyware wants more private data such as the victim’s bookmarks and search history from popular browsers like Google Chrome, Mozilla Firefox, and the Samsung Internet Browser.

Figure 13: The content providers to query bookmarks and searches made by the victim

To identify the victim’s device name, the spyware tries to compare the information collected from the device’s “Build.DEVICE” and “Build.MODEL” with a list of hardcoded values amounting to a total of 112 device names such as seen below.

Figure 14: Snippet of code to identify the device by matching with a list of 112 devices

The spyware creates a notification if the device’s screen is off when it receives a command using the Firebase messaging service, as shown in the below images. The “Searching for update..” is not a legitimate notification from the operating system, but the spyware.

Figure 15, 16: The Fake notification and communication with the C&C server

The spyware is capable of performing a wide range of malicious activities to spy on the victim while posing as a “System Update” application. It exhibits a rarely seen before feature, stealing thumbnails of videos and images, in addition to the usage of a combination of Firebase and a dedicated Command & Control server for receiving commands and exfiltrate data.

IOCs

Spyware applications:

96de80ed5ff6ac9faa1b3a2b0d67cee8259fda9f6ad79841c341b1c3087e4c92

6301e2673e7495ebdfd34fe51792e97c0ac01221a53219424973d851e7a2ac93

C&C servers:

hxxps://mypro-b3435.firebaseio.com

hxxps://licences.website/backendNew/public/api/

To learn more

To learn more about how Zimperium detects and prevents malware from disrupting enterprises globally, contact us.

Zimperium zIPS, powered by Zimperium’s machine learning-based engine, z9, detects this malware. Additionally, zIPS with Samsung Knox enables immediate and automated mitigation capabilities.

New Advanced Android Malware Posing as “System Update”

Source

Mar 15 2021

Top 4 Threats to O365 on Mobile Devices (and How to Stop Them)

Enterprises are continuing to work remotely and use BYO mobile devices. Doing so enables cost savings from a corporate standpoint and better user satisfaction from an employee standpoint. It also introduces and keeps Microsoft’s O365 as a mainstay.

I recently hosted a webinar with our very own Kern Smith, Vice President of Solution Engineering, on the top four threats facing O365 on mobile devices and what can be done to stop them.

To watch our on-demand webinar, please click here. To learn more about how we are protecting devices with O365, please contact us.

Why protect mobile devices

The majority of endpoints accessing the enterprise today are mobile and they have almost no protection on them. These mobile devices are spending all this time outside of the protected corporate network. The mobile devices are in the hands of users who are the ones who are usually making the worst decisions.

And why should we care if our employees make a bad decision or fall victim to an attack?

Well, it’s all of the data and information that’s accessible on and from your mobile device. For example, the typical mobile device has – on average – 80 apps on it; five to 10 of which are business-related apps, including O365 apps like Outlook and Teams. And that’s growing, especially in the remote working/zero trust world – – as is using mobile devices as a multi-authentication tool to access enterprise services and data.

4 threats to O365

While there are – indeed – four threats to O365, there is one big risk we mentioned before, which bears repeating. The carbon-based life forms known as your employees. To be clear, it isn’t all of your employees. This is Darwinism at its finest and the bad guys are looking for the weakest link.

You see, it just needs to be one employee who doesn’t update the OS because it’s going to mess up the battery life or slow down the speed of Candy Crush. What ends up happening is the window is left open and it makes it that much easier for the attackers to….well, attack.

The end game for an attacker is to elevate privileges and compromise the device. There are three other conduits or pipelines the bad guys use in order to get to that ultimate goal of device persistence – – network, malicious app, and phishing attacks.

One of the dumbest things about smart devices is they connect to the network by introducing themselves, not the other way around. Your phone literally walks up to every network and asks, “Hey, are you Starbucks?” And the bad guys, posing as the network can easily say, “well, yes I am.”

While the majority of the malicious apps we see are actually focused on fraud – BankBot, BlackRock and the like – malicious apps can also be a delivery mechanism to compromise the device.

From a phishing standpoint, overall we saw a 6X increase in 2020. In the United States, Office 365 and Outlook were two of the most often used brand names attackers leveraged in phishing attacks:

Microsoft is ahead of the curve

As shown, giving mobile devices the ability to access corporate resources is creating cybersecurity threats. Microsoft, following a Zero Trust strategy, understood the threats and looked toward mobile threat defense (MTD) solutions for device attestation. The MTD provides intelligence within their conditional access approach.

For example, before allowing access to Outlook or Teams, the MTD – working with Microsoft’s Conditional Access – will alert the enterprise if the user has downloaded a malicious app. This allows the enterprise to deny access to its Office 365 solution until the app is removed.

In our webinar, we specifically showed how Zimperium’s zIPS is being used to protect Office 365 users around the world every day. zIPS is the only mobile security solution with on-device, machine learning-based detection of device, network, phishing, and malicious app attacks.

Deploying and remediation could not be easier. Here, Kern shows just how easy:

[embedded content]

For more information

To watch our on-demand webinar, please click here. To learn more about how we are protecting devices with O365, please contact us.

Top 4 Threats to O365 on Mobile Devices (and How to Stop Them)

Source

Mar 04 2021

Unsecured Cloud Configurations Exposing Information in Thousands of Mobile Apps

Abstract

When approaching the development of a mobile application, one of the key design decisions revolves around the server side aspect of the application. Specifically, storage of information relevant to the app’s usage, as well as the backend API’s allowing the app to query the server for information in real time (as opposed to static data that’s stored in files).

In addition to the examples above, significant numbers of apps have started to rely on cloud based databases (such as Firebase), allowing the app developer to focus on storing and accessing the data without being concerned about infrastructure and APIs.

There are several popular “go to” cloud solutions providing the services described above that are widely used: AWS by Amazon, Azure by Microsoft, Google Storage and Google Firebase to name a few.

The stated purpose of all of these services is to reduce the complexity of configuring access to the relevant storage container, and allow the app developer to “focus on the important things.”

However, the process of securing these cloud containers used by mobile applications tends to be overlooked by app developers while the impact of a misconfigured cloud container on the app developer, their business and their users can be extremely high.

This blog will cover the latest research uncovered by Zimperium’s zLabs Team, including our findings on thousands of mobile apps with unsecured cloud containers throughout global markets and across both major mobile operating systems (iOS and Android).

In our analysis, 14% of mobile apps that use cloud storage had unsecure configurations and were vulnerable to the risks described in this post. In apps around the world and in almost every category, our analysis revealed a number of significant issues that exposed PII, enabled fraud and/or exposed IP or internal systems and configurations.

We will shed light on how widespread these types of configuration errors are, and how the different aspects of the leaked information can be exploited by a malicious attacker.

Another goal of this blog is to create an “aha!” moment for app developers, as one of the biggest challenges we have encountered was actually reporting our findings to the specific app developers who have unsecured cloud storage. Very few publishers have a clear path for vulnerability disclosures, so risks may remain unreported and unresolved (and possibly actively exploited).

So, in addition to helping app developers assess the current security status of apps’ cloud containers, and providing them with the tools and solutions needed to effectively secure the cloud container of choice and prevent information from leaking, we would like to raise awareness from an industry standpoint on the need for mobile app develops to be more accessible so they can receive and address security concerns stemming from the app being developed.

Overview of cloud storage services

In today’s world, apps have become ubiquitous. We have an app for everything we want to do.

How many steps you’re taking in a day? There’s an app for that.

Need to listen to your favorite playlist. App for that.

Get the latest news. You get the idea.

But, apps need data. Constantly available. Redundant. Scalable. Enter “the cloud.”

App developers rely heavily on several service providers that provide cloud infrastructure allowing access to data through a variety of forms – – from static files, to full-fledged databases to APIs.

Our zLabs research focused specifically on four main cloud storage services:

All of these services allow you to easily store data and make it accessible to your apps. But, herein lies the risk, the ease of use of these services also makes it easy for the developer to misconfigure access policies – – potentially allowing anyone to access and in some cases even alter data.

The main allure of these services is that they allow the developer to turn over the “burden” of thinking about anything but the app they are developing, with security, access controls and an overall approach to securing data being relegated to the cloud provider’s default settings.

And even though the cloud providers provide very detailed guidelines on how to secure access, most app developers neglect to follow them.

When Data Leaks

In the following section, we’ll explore what kind of data leaks when cloud storage is unsecured, and provide examples of real leaks from misconfigured cloud storage used by apps.

Leaking Information Types

Before providing examples of apps with unsecure cloud storage, it is useful to describe the types of data that we discovered to be leaking. We can divide the information into:

PII Information

This is personally identifiable information (PII), such as profile pictures, personal details (addresses, financial information etc), medical details (medical test data), etc.

The risks of this information leaking are pretty self-evident – there is a potential legal risk of leaking PII data (i.e. the people whose data is leaking might sue the app developers) and also brand damage (i.e., App X is leaking its users data, therefore all users stop using App X).

Configuration Information

This type of information leak exposes various configuration information relevant for the normal operation of the app and the infrastructure it uses. For example, we detected apps that leak their entire cloud infrastructure scripts, definitions (including SSH keys), etc. Other types of configurations are web server config files, installation files and even passwords to payment kiosks.

This kind of information could enable an attacker to understand how the computing infrastructure of a company is built. Having access to all of the infrastructure information can also allow an attacker to take over the backend infrastructure of the company, which in turn can allow the attacker to potentially “jump” to other infrastructure and hurt other products.

Examples of Apps with Unsecured Storage Vulnerabilities

In our analysis, 14% of iOS and Android apps that use cloud storage had unsecure configurations and were vulnerable to a number of significant issues that exposed PII, enabled fraud or exposed IP or internal systems. A few examples of each include:

Exposing PII

Medical Apps: Exposing personal medical information including test results, full details and profile images of users.
Social Media Apps: Exposing photos, phone numbers and other personal information of some users.
Major Game App: Exposing server configuration assists the attacker in gaining further intelligence on the target to be used for a potential attack.
Fitness App: Exposing the developer’s server app including versions of the mobile app for both Android/iOS, allowing potential reverse engineering or manipulation of the app.

Enabling Fraud

Fortune 500 Mobile Wallet: Exposing session and payment information that could lead to fraud.
Major City Transportation App: Exposing access to the payment system, this can potentially allow an attacker to obtain personal financial information of customers.
Major Online Retailer: Exposing blank checks can enable identity theft and fraudulent transactions.
Gambling App: Leaking user information (including emails, phone numbers and login information) enables attackers to login on behalf of any of the exposed users.

Putting IP or Systems at Risk

Major Music App: Exposing detailed server information that could be leveraged to gain further system access.
Major News Service: Exposing news stories, personal photos with locations and other information.
Fortune 500 Software Company: Exposing debug versions of the software or internal documentation, easing reverse engineering of product.
Major Airport: Exposing systems allow attackers to obtain, change or delete internal airport information.
Major Hardware Developer: Leaking APIs and encryption keys enables access to servers and all the information they contain.
Asian Government Travel App: Their firebase database is unsecured, exposing contained records and potentially allowing manipulation of data.

Impacted App Categories

App Categories With Unsecured Cloud Storage

The image below shows the distribution of categories (verticals) for the apps with unsecure storage issues. We can see that the bigger verticals are: Business, Shopping, Social, Communications and Tools.

Examples of Apps with Unsecured Cloud Storage

Exposing PII

During our review, we encountered several apps relying on both Google and Amazon storage that was accessible without any security. In one example, the information we were able to obtain included profile pictures and other PII information.

Since many apps revolve around people sending information to one another, the fact that specific information – not intended to be shared – can be accessed by an unauthorized third party, can cause damage to the app developer and the privacy of their users.

Enabling Fraud

Other apps leak information that enables fraud. In one example, an app shows images containing physical payment implements such as checks. These contain personal and financial information (account numbers, addresses, valid account holder names etc) and can be used to perpetuate forgery and other real-world crimes:

Another popular use-case for business/financial apps is online shopping. One online shopping app was exposing customer ID’s, login session ID’s and even payment related information (in the form of tokens). An attacker can actually use this to perform payments, steal money and even hijack accounts:

Putting IP or Systems at Risk

Another category of apps exposes configuration information that could be used for further investigation or penetration. For example, one may think music apps don’t have any important information to protect, however, we identified cases where the entire server infrastructures, scripts, servers and much more was exposed publicly. An attacker gaining access to this information can easily compromise the entire server infrastructure of the app developer.

The screenshot above shows a script that adds an SSH key to the list of authorized users. By having the ability to see SSH keys, an attacker can have access to the app developer’s servers.

To make matters worse, an attacker could obtain a full list of all of the backend resources (servers, caches, databases etc) used by the app’s infrastructure, which could allow an attacker to potentially compromise the entire infrastructure.

What you can do to avoid leaks

The simplest thing you can do is make sure your cloud storage/database is not accessible from the outside world without any sort of security around it (each cloud provider has full documentation on how to achieve this).

Once you’ve closed off your cloud service to unauthorized external access, the next thing you can do is to use a service that assesses your secure software development lifecycle as part of your standard development process.

The leading solution for continuous mobile app security testing (MAST) is Zimperium’s zScan solution, part of the industry leading Zimperium Mobile Application Protection Suite (MAPS).

Not only is it going to help you prevent leaky cloud storage, but also other security pitfalls.

That’s where zScan comes in. It integrates as part of your CI/CD process, and scans your app each time it gets built. If there are any issues found, zScan will then highlight any security issues it finds. We’ve included some example reports below:

If you are a mobile app developer and would like to know if your apps have unsecured cloud storage issues like those described in this blog, please contact us for a free consultation.

If you’d like to learn even more about this, please register for our webinar we are conducting on March 24th at 11am EDT.

In conclusion, I’d like to thank Asaf Peleg for all of his efforts with this research. For any press wanting to learn more, please reach out to [email protected].

Unsecured Cloud Configurations Exposing Information in Thousands of Mobile Apps

Source

Feb 09 2021

Let’s Protect More than 40% of our Endpoints

Imagine finding out your most recent departmental budget was only 40% of what it should be. If you’re like me, you’d get a strong feeling that “something is missing and it’s a real disaster.”

Well, here’s the thing. If you’re a CISO – or if your job involves information security in general – you should be getting that exact feeling right this minute. Because most businesses only secure 40% of their endpoints.

Clearly, no one thinks that 40% is good enough – whether it’s your budget or your endpoint protection strategy. So why would an otherwise buttoned-up, well-run enterprise security organization pursue a strategy that fails to protect 60% of their endpoints?

Mobile devices are now the most common endpoints in the enterprise

The problem, in a word, is mobile. Enterprises have had decades to plan, implement and iteratively refine robust management and security solutions for traditional endpoints like desktops and laptops. But mobile devices transformed almost overnight from a nice-to-have luxury into the single most critical endpoint in the enterprise for employee productivity, connectivity and collaboration.

Today, enterprises are still struggling to get their arms around protection for mobile devices. That struggle results in part from the vast difference between mobile threat defense and traditional threat defense. Unlike desktop PCs:

Users are the admins on mobile devices, so they decide when to upgrade their OS, what networks to connect to and what apps to install;
All apps are in containers on mobile devices, limiting the capabilities of security apps; and
Endpoint protection platforms (EPP) and endpoint detection and response (EDR) solutions are ineffective on mobile devices.

Mobile devices are under-protected and disproportionately targeted

Bad actors recognize that mobile endpoints are a relatively easy target. By September 2020, we had already recorded more mobile app breaches, failures, and data leaks than all of 2019.

Every day, Zimperium detects 600 million threat events involving enterprise mobile devices. Essentially, all the methods and strategies hackers use on traditional endpoints apply to mobile devices.

Targeted attacks against enterprises often use unknown, “zero day” attacks that require machine learning-based detection;
“Land and expand” campaigns target the weakest link for entry into the network – unprotected mobile devices are the hacker’s perfect starting point today; and
To maximize the ROI of compromising any system (including a mobile endpoint), hackers want to establish a persistent foothold that remains even after reboot.

Even aside from inadequate protection, mobile devices have inherent characteristics creating a larger attack surface than traditional endpoints. Cybercriminals can attack mobile devices from multiple vectors.

Device: Attackers’ primary goal on mobile is to fully compromise the device, be persistent, and weaponize it for “land and expand” lateral movements;
Network: Attackers use rogue access points (RAPs) and man-in-the- middle (MITMs) to steal data and deliver targeted exploits to compromise the device;
Phishing: Mobile phishing – especially via text/messaging apps and personal email – is a highly effective way to steal credentials and deliver targeted exploits; and
Apps: Malicious apps can create fraud, steal information, and deliver device exploits; even apps from legitimate sources can have coding or other errors that make them vulnerable.

All of this is to say that the endpoint security problem itself is huge. But the bigger picture is that when your endpoint security is compromised, all your information security is compromised. If 60% of your endpoints lack adequate management and security, you cannot succeed with security frameworks such as zero trust. But this is not to say that protecting mobile devices is a hopeless cause. Rather, it just requires a different approach.

EPP and EDR solutions can’t protect mobile devices, but MTD can

I mentioned earlier that EPP and EDR solutions are ineffective on mobile devices. The reasons for that are complex. For example, the kernels in mobile OSs such as Android, iOS and ChromeOS are locked down. And since EPP and EDR rely on kernel access, they are blind and ineffective on mobile.

They have no ability to detect risky or malicious networks, and cloud-based detection can easily be disabled by network attackers. They can’t even assess privacy and security risks in legitimate (non-malicious) mobile apps.

Mobile endpoints therefore require a new security approach. Gartner calls this new class of solutions mobile threat defense, or MTD. As the global leader in mobile threat defense protecting millions of enterprise mobile endpoints around the world, Zimperium’s MTD solution uniquely has the characteristics required for successful MTD:

Detects threats even with locked-down OS kernels;
Detects known and unknown (targeted) device, network, phishing and malicious app risks and attacks;
Provides on-device detection that protects user privacy and defends mobile devices even when an attacker owns the network and protects user privacy; and
Assesses privacy and security risks in legitimate mobile apps.

The Zimperium platform leverages our machine learning-based engine – z9 – to protect mobile data, apps and sessions against device compromises, network attacks, phishing attempts and malicious apps. Our solutions include zIPS which runs locally on any mobile device and detects cyberattacks without a connection to the cloud and our first-of-its-kind Mobile Application Protection Suite (MAPS), a comprehensive solution that helps organizations protect their mobile apps throughout their entire life cycle.

MAPS is comprised of three solutions: zScan, which helps organizations discover and fix compliance, privacy, and security issues; zShield, which hardens the app through obfuscation and anti-tampering; and zDefend (formerly zIAP), an SDK embedded in apps to help detect and defend against device, network, phishing and malicious app attacks while the app is in use.

For more information

If you’d like to get past the 40% mark and move to 100% endpoint protection, please feel free to reach out to me directly or to anyone at Zimperium. We are here to help.

Let’s Protect More than 40% of our Endpoints

Source