User Profile
Bigdogburr
Google Team
Joined 2 years ago
User Widgets
Contributions
Android 16 STIG is now live!
Hey friends, We are pleased to announce the release of Google’s Security Technical Implementation Guide (STIG) for Android 16. Developed in partnership with the Defense Information Systems Agency (DISA), this guide provides a robust, expert-defined security baseline for organizations that require the highest level of security. It is an essential resource for government, defense, and security-conscious customers like FSI and Healthcare, who handle sensitive data and operate in compliance-driven environments. What is a STIG? A STIG is a detailed security checklist designed to “harden” an operating system. In short, it’s a technical manual that provides prescriptive, step-by-step guidance on how to adjust default settings, disable unnecessary functions, and configure a system to protect against common vulnerabilities. By following a STIG, you proactively close the doors that cyber attackers often use to exploit systems. Who can benefit from the STIG? While STIG compliance is mandatory for DoD (Department of Defense) and federal agencies, its guidance represents the gold standard for security that any organisation can use to improve its security posture. Specifically, the Android 16 STIG provides official configurations for devices deployed in Corporate-owned, business-only (COBO), and Corporate-Owned, Personally-Enabled (COPE) management modes. The key value for your business Adopting the Android 16 STIG goes beyond meeting a mandate, enabling several key business benefits. Achieve the highest security posture: The guide closes configuration weaknesses and minimizes your system’s attack surface, dramatically improving your defence against threats and enhancing system resilience. Ensure mandatory compliance: For federal and DoD-connected systems, STIG compliance is a non-negotiable step to meet the Risk Management Frameworks (RMF) and gain Authority to Operate (ATO). Unlock a standardized and efficient management framework: It provides a single, expert-defined security baseline across all your devices, which simplifies system auditing, prioritizes critical fixes (using the CAT I, II, III severity levels) and streamlines auditing and reporting. Ready to strengthen your security? Get everything your team needs to harden your Android devices, meet compliance mandates, and build a more resilient mobile fleet directly from the DISA repository. ➡️ Download the Google Android 16 STIG here For those interested in federal device certification, our latest episode of The Secure Element delves into the approval process for Android devices in compliance-focused sectors.The Secure Element podcast - Episode #3
Hey Friends, Episode 3 of The Secure Element is here! This month, I spoke with Brian Wood who runs the Android Certifications Programs to demystify what it takes to get a device approved for the federal government, a process that also benefits other security-focused industries like finance and healthcare. Join us as we dive into: The exact process for federal government device certification. The roles of NIST (National Institute of Standards and Technology) and NIAP (National Information Assurance Partnership) in setting security standards. Debunking myths about Android encryption, including its standing against iOS. Listen to the episode here: Thanks for tuning in! We’d love to hear your thoughts or any further questions in the comments below and we’ll be sure to follow them up. New to the series? Listen to Episode 1 and Episode 2 to hear more insights from industry leaders. Stay secure, BurrThe Secure Element podcast - Episode #2
Hey friends, Episode 2 of our new podcast; The Secure Element is now available to watch below. This month, I met with Theresa Lanowitz, Chief Cybersecurity Evangelist at LevelBlue and a globally respected leader in the Cybersecurity world. In Episode 2, we dive into: Cyber Resilience on Edge Devices Phishing Difficulties in compromising Devices M&A causes security slips Application defenses You can listen to the episode below: We'd love to hear if any of the topics mentioned here resonate with you. If you have anything you’d like to add or any challenges you currently face, please comments below. Stay secure, Burr —------------ Missed episode #1 with Bhavesh Kumar, Senior Director of Product Management at Omnissa? Catch-up here.Introducing The Secure Element podcast - Episode #1 is LIVE!
Hey friends, I'm pleased to announce the launch of our brand new security podcast: "The Secure Element"! This podcast is dedicated to all things security, covering topics relevant to our community and beyond. Plus, I am joined by some incredible people across the ecosystem along the way. We're kicking things off with our first episode, featuring special guest Bhavesh Kumar, Senior Director of Product Management at Omnissa. In Episode 1, we dive into: UEM controls to manage security Ecosystem of malware protection New capabilities for Device Trust principles You can listen to the first episode below: We'd love to carry on the conversation after you have listened/watched the video, so please do share your thoughts on any of the topics discussed in the comments below and/or any suggestions you might have for future topics. Stay secure, BurrRe: Do you really need a long pass code on Android?
Hi Yann_ROLAND, all great points. We mostly see Smart Cards and CAC/PIV cards still used in Laptops, but the use of them on Mobile has significantly dropped off due to user experience issues. Users will have to carry a special sled or external card reader that connects to the phone by Bluetooth to insert the card into. We see more customers like that using Derived Credentials that are linked to the Smart cards that are sent to the devices with a short TTL. We do use Yubi keys here at Google on mobile, but only for enrollment, not for an ongoing basis.Re: Are managed Android devices really prone to malware?
Hi Michel, we do not do any malware protection for AOSP, only Google Play Protect certified devices. We do not have visibility into A Device Maker that uses AOSP devices and cannot guarantee much of any security requirements. Those device makers are not required to stick to the guidelines and requirements that are in the Compatibility Definition Document (CDD) nor do the devices have a Google Cert embedded in hardware backed security. We do however implement all kinds of platform security mechanisms in AOSP which are standard such as memory sanitizers, ASLR, KASLR, MAC for the Kernel Domains, etc.... But again, a device maker that makes an AOSP version can remove and alter any of the protections we put in place. I am also in the process of building a new updated AE Security course on the academy that touches on some of the platform items.Are managed Android devices really prone to malware?
The digital landscape is constantly evolving, and with it, the threats to our devices. A common question that arises, particularly in enterprise settings utilizing managed Android devices, is whether these devices are inherently susceptible to malware. The answer isn't a simple yes or no; rather, it hinges on several key factors: The first question we need to consider is whether Android devices, in general, are truly that susceptible to malware. This depends significantly on user behavior, specifically whether you primarily use the Google Play Store or install apps from unapproved third-party app stores. Are you intentionally enabling the installation of downloaded APK files from unknown sources? Are you enabling Developer Options and subsequently permitting OEM Unlock and/or ADB (Android Debug Bridge)? Risk Factors: App Sources and User Behavior The choices users make regarding app installation and device settings play a crucial role in their security posture. Sticking to the official Google Play Store provides a level of scrutiny and protection that third-party stores often lack. Similarly, enabling the installation of apps from "unknown sources" bypasses built-in security measures designed to prevent the installation of potentially harmful software. Furthermore, activating Developer Options and enabling features like OEM Unlock and ADB, while useful for development purposes, can also open avenues for malware installation. Why Users Deviate from Official Channels Understanding why users might take these risks is important. Some users may seek apps not available on the Google Play Store, while others might be tempted by pirated or modified versions of popular applications. Developers need to use features like ADB for testing and debugging, but leaving these enabled on production devices can be a huge security risk. Sources of Android Malware Android malware primarily originates from unofficial sources. The Google Play Store employs various mechanisms, such as the App Defense Alliance and Google Play Protect, to identify and remove malicious apps. Third-party app stores, on the other hand, often have less stringent review processes, increasing the likelihood of encountering malware. Downloading APK files directly from the internet also carries significant risk, as these files may not have undergone any security checks. Android's Built-in Protections: Google Play Protect and the Permissions Model Android incorporates several built-in security features to protect users. Google Play Protect (GPP) is a comprehensive security service that scans apps on the Google Play Store before you download them and regularly checks your device and apps for harmful behavior. Live Threat Detection is a component of GPP that provides continuous monitoring for emerging threats. The Permissions Model is another crucial security mechanism. When an app wants to access certain features or data on your device (like your camera, microphone, contacts, or location), it must request your permission. This model puts you in control of what apps can access, limiting the potential damage a malicious app can cause. The Role of Cloud-Based App Scanning Beyond on-device scanning, Google also employs cloud-based scanning to analyze apps for malicious behavior. This allows for the identification of threats even before they become widespread. By analyzing app behavior in a controlled environment, potential malware can be detected and removed from the Play Store. The Growing Threat of Phishing While technical controls are essential, it's crucial to recognize that phishing has become a significant attack vector – akin to obtaining the keys to a house. Attackers often try to trick users into clicking malicious links, downloading harmful attachments, or providing sensitive information through deceptive emails, messages, or websites. The good news is that Google Messages and Google Phone apps have new capabilities to protect users from falling victim to Spam and Phishing attempts. Security of Managed Android Devices Now, returning to the central question: are managed Android devices really prone to malware? In many ways, managed devices are much more secure than personal devices. Organizations deploying managed devices can implement policies that restrict app installations to the Google Play Store (a curated list of only approved apps), disable the installation of apps from unknown sources, and prevent users from enabling developer options. These controls significantly reduce the attack surface and limit the opportunities for malware to be introduced. Furthermore, Mobile Device Management (MDM) solutions often provide additional security features, such as the ability to remotely scan devices for threats with the Play Integrity API, enforce strong password policies, and integrate with leading 3rd party Mobile Threat Detection solutions. Understanding Reports of Widespread Infections So, why do we still encounter online posts claiming “Millions of Android devices infected with XYZ” or urging users to “Uninstall these Android apps with malware”? These reports often highlight instances where malicious apps and malware are installed from 3rd party app stores, are installed on non-Google Play Protect certified Android devices, or installed on low cost AOSP or rooted devices. While these incidents are concerning, they often affect consumer users who have not adhered to basic security practices or who have ventured outside of the official app ecosystem. For managed devices with appropriate controls in place, the risk of such widespread infections is considerably lower. In fact, in 2024, the Android Transparency Report highlights that only .009% of devices were seen with a potentially harmful app. It’s important to highlight that of those .009% detected apps, many are simply “potentially harmful” and actually pose no threat. These apps are often simply coded with insecure coding practices where Google Play & Google Play Protect find them. Conclusion While Android devices, like any connected device, can be susceptible to malware, the level of risk is largely determined by user behavior and the security measures in place. For most users who primarily use their smart devices and exclusively install apps from the Google Play Store, the risk is significantly reduced. Managed Android devices, with their ability to enforce stricter security policies and limit risky user behaviors, are even more secure. By understanding the sources of malware, utilizing the built-in security features of Android, and remaining vigilant against threats like phishing, organizations managing Android devices can significantly mitigate the risk of malware infection. Let’s keep the conversation going, it would be great to hear your thoughts on this below.Re: Do you really need a long pass code on Android?
Michel For sure too much to discuss here in comments, but that is the problem which I will be addressing in 2025. There is a ton of verifiable data on your question, the issue is that many do not know where to find it. Stay tuned as I have some exciting updates coming that will certainly provide access to the details of which you seek..... Mike.Do you really need a long pass code on Android?
Do you really need a long complicated pass code on Android? Traditionally, IT admins applied similar pass code requirements to Android devices as with server and desktop operating systems. However, this approach can be excessive and unnecessarily restrictive. Unlike laptops or desktops, where unlocking grants access to all user apps and services, Android operates differently. As “Android is now the most common interface for global users to interact with digital services”*(1) with many organizations, from small businesses to large multinational corporations and government agencies, relying on Android devices to access sensitive company data, it’s important to understand the distinction. The key difference lies in how these operating systems handle app permissions. While server/desktop OS's typically consider all apps running within the context of the logged-in user account as fully authorized, Android operates with a more granular approach. Android apps are not inherently granted full authorization for all user actions.*(1) This inherent security measure within Android mitigates the risk of malicious code exploiting the vulnerabilities of server/desktop OS's. On server/desktop systems, attackers often only need to execute malicious code with the currently logged in user's privileges to gain significant control. Android's more restrictive environment makes this type of attack more challenging. Windows, macOS, and Chrome will typically use a username and password coupled with Single Sign-On (SSO) or Multi-Factor Authentication (MFA) that is tied to a corporate account to log into the OS. Android simply uses a PIN, pass code, or pattern that is not tied to a user’s LDAP or domain account to unlock the device. This separates the device unlock on Android by not having that tied to a corporate identity. This difference keeps an Android pass code to unlock a device separate from the user's account to access corporate services and applications. In this way, the Android security model grants less power to users versus traditional OS's that do not require multi-consent models. The immediate benefit to users is that one app cannot act with full user privileges. The user cannot be tricked into letting it access data controlled by other apps due to the robust app sandboxing on Android. So, do you really need a long pass code on Android if the unlock pass code is not tied to your corporate account? Let's consider some more interesting facts to determine if a long pass code is needed to protect an Android device. NIST passcode guidelines: A shift in perspective What does the National Institute of Standards and Technology (NIST) have to say? The general password guidance from the latest version of SP 800-63b *(2) are listed below: Pass code Length: Minimum 8 digits Complexity (Special characters, uppercase, lowercase, number): No longer required Pass code hints: Do not allow Simple or known pass codes: Do not allow Periodic pass code changes (every 90 days, etc.): Not required. Only force changes when a known compromise is detected. SMS for MFA Codes: Do not use Pass code guess prevention (Throttling): Implement NIST’s updated requirements are a result of technology advances that prevent guessing a pass code. As an example, 8 digits without special characters, upper and lower case, and pass code changing requirements are no longer recommended. An 8-digit pass code of non-repeating numbers is now sufficient to provide very strong protection. On Android we actually changed our PASSWORD_COMPLEXITY_HIGH to 6 digits back in Android 12. Let's explore this a little more. Rate limiting and password guessing Android implements a very strong default rate-limiting capability, which imposes increasing delays after the 5th failed login attempt, culminating in a 24-hour lockout after 100 attempts. The benefit to a managed device is that Android Enterprise can limit the attempts to a specific number before a device wipe is triggered automatically. This helps prevent access to personal and company data. Assuming that an Android device is properly managed with a limited number of failed pass code attempts, let's say 10 tries, enforcing a device wipe by policy renders an attack mostly infeasible. Even the latest version of the password-guessing USB tool, rubber ducky, is ineffective. Now, let's explore a simplified explanation of what a hash is in this context. Imagine your pass code to unlock your Android device is "019283". Android has an "algorithm machine" (called a hash function, or algorithm such as SHA256) that takes that password and generates a unique string of characters that represents that specific data, such as "a5f4g6h7j8k9l0". This is the hash of your password. It looks nothing like your original password, making it virtually impossible to figure out your lock screen pass code "019283" just by looking at the hash. Additionally, reversing the hashing calculations is infeasible and the algorithms are created in such a way as to protect against a reversing calculation. Now, every time you try to unlock your device, Android securely feeds what you type into the unlock prompt and puts it through the same hashing algorithm. If the resulting hash matches what is stored in secure hardware on the device, then Android knows you've entered the correct password and it unlocks. What is stored in secure hardware on Android is the hash of your pass code, not your pass code itself. We have all seen the following image on social media, but it portrays incorrect data when it comes to Android. This table does not take into consideration that the attacker has successfully been able to capture the hash of the pass code. Extracting the hash of a pass code from a locked Android device's secure hardware is non-trivial and is extremely difficult, actually infeasible on Android. Conclusion: Rethinking pass code complexity for Android In conclusion, it is important to note that I have only covered a small portion of a very complicated topic that involves encryption, key storage, hashing, and rate-limiting in Android kernel and services. While anything is potentially possible, the reality of exfiltrating a hash from secure hardware is really not feasible or practical. Requiring a pass code that is long and complicated is not a factor in 2025 on Android. With the proper management policies, guessing a pass code to unlock a stolen or lost device should not be a concern any longer. Have a look at what your EMM provider options are when setting a pass code requirement and consider how you can make the user experience for your users better by not having to enforce long complex pass codes, it just frustrates users. *(1) Android Security Model: https://arxiv.org/pdf/1904.05572 *(2) https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-63b.pdfEnhanced Factory Reset Protection in Android 15
Factory Reset Protection: A Shield for Everyone Smartphones and tablets have become integral to our work and personal lives, however, they can also be easily lost, and on occasion, stolen by opportunistic thieves. Many times these bad actors will simply wipe the device to remove any personal and business data, with the intent of selling or using the device themselves. That's where Factory Reset Protection (FRP) steps in as a crucial line of defense. FRP is an Android security feature designed to prevent the reuse of a lost or stolen Android device. It requires your Google account or lockscreen credentials after a factory reset, ensuring that only the rightful owner can access and use the device once it has been wiped. Enhanced Factory Reset Protection Building on its initial purpose, FRP has evolved significantly with the release of Android 15. In the past, tech-savvy thieves and users found ways to bypass FRP, but Android 15 closes those loopholes with powerful new protections. These enhancements were added to combat unauthorized access and make stolen devices much less appealing to thieves, whether they're targeting personal or company-owned devices. Prior to Android 15, the Setup Wizard was responsible for determining whether FRP should be activated, and for enforcing it, including determining whether you have authenticated with the correct credentials to get out of FRP mode and proceed with setup normally. But the Setup Wizard was designed to be a user-friendly tool to walk through setting up a device, not a security enforcement barrier. In Android 15, FRP enforcement has been moved deep into the system, where it’s much harder to overcome. Benefits You Can Count On These enhancements translate into real-world benefits for everyone: Individuals: Deters Theft: FRP makes stolen devices far less valuable, as thieves can't bypass the Google account login or lock screen credential check. This significantly reduces the incentive for theft. Peace of Mind: Knowing that your Android device has this robust security feature gives you peace of mind. You can rest assured that if your device falls into the wrong hands, it cannot be used for anything. Enterprise and Managed Devices: Enhanced Device Security: Factory Reset Protection makes it much harder to reuse or sell stolen devices, which discourages thieves from stealing them in the first place. Simplified Device Management: FRP integrates seamlessly with enterprise mobility management (EMM) solutions, allowing IT administrators to enforce FRP policies and ensure devices are protected. With Android 15, FRP has evolved into a powerful deterrent against device theft by making stolen devices unusable.Read this year's 2024 Android Security Paper
Hey Friends, this year's new 2024 Android Security paper is now available, take a look! In today’s modern world, we use mobile devices everywhere – at home, on the go, and at the office. So, protecting them against cyber threats has never been more important. Mobile devices are attractive targets for bad actors to steal or compromise to gain access to personal and business data. 83% of all phishing sites specifically target mobile devices and render in mobile browsers differently than desktop browsers. With that in mind, I’m happy to announce the updated Android Security Paper. Here, we detail our latest security measures to help protect your fleet of devices. By combining Zero Trust principles, enhanced privacy features, and advanced security capabilities, Android continues to set the standard for a secure, privacy preserving, and user-friendly mobile platform across use cases. What's new in Android 15 Android 15 brings more robust anti-theft protection capabilities, Private space to help protect users personal apps, and more dynamic audit logging. Additionally, we have introduced a simplified eSIM management feature, artificial intelligence management capabilities for IT admins, and a host of privacy preserving features. Plus, you’ll discover improvements to make customer sign-up and account governance easier and more secure. Finally, we have hardened the OS by enhancing memory safety to help minimize vulnerabilities. Enjoy! 2024 Android Security PaperRe: Fraud or hacked, very upset, and need help
Hi Sher, I can see that you are unsure of what this Device Policy app is and why you have it on your Android Phone. The Device Policy App from Google is actually a normal app that is installed on all Android devices that are GMS / Google Play Protect certified and is part of Google Services. It is a Device Policy agent that allows all Android devices to be enrolled into an organization. This app is basically the on-device agent used by EMM's to enable device management, but please note that just because its installed, does not mean your device is under management or being controlled by an Enterprise EMM. You would have to initiate an enrollment process in order for the app to be used by the EMM you are enrolling into. You can read more details about Android Management API's HERE.
