Security Boulevard

Juneteenth National Independence Day 2025

Permalink

The post Juneteenth National Independence Day 2025 appeared first on Security Boulevard.

The rise of advanced technologies like AI, IoT, and edge computing is reshaping data center operations, demanding greater efficiency, scalability, and sustainability. Data center managers must prioritize proactive strategies that ensure uptime, optimize energy consumption, and meet compliance standards. Tools like Hyperview's DCIM solution deliver real-time insights, automated asset tracking, and energy optimization, enabling professionals to streamline operations while meeting future demands with confidence.

The post Smarter Data Center Capacity Planning for AI Innovation appeared first on Hyperview.

The post Smarter Data Center Capacity Planning for AI Innovation appeared first on Security Boulevard.

Today’s financial systems are highly digital and deeply interconnected. That’s great until something breaks. Whether it’s ransomware paralyzing critical services or cryptographic vulnerabilities quietly eroding trust, disruptions are no longer rare—they’re systemic. The Modern Heist Bank Report 2025 shows just how serious it’s become: 64% of surveyed financial institutions reported cyber incidents in the past […]

The post How Financial Institutions Can Meet DORA Compliance with Crypto-Agility appeared first on Security Boulevard.

As cyberthreats grow more sophisticated and the quantum era draws closer, resilience is no longer just a best practice—it’s a business imperative. Many organizations have focused on breach prevention. Forward-looking enterprises are shifting to a resilience-first model. This model prioritizes continuity, recovery, and adaptability in the face of emerging risks. Why Resilience Is the New..

The post Data Resilience in a Post-Quantum World appeared first on Security Boulevard.

The U.S. Department of Health and Human Services (HHS) is rolling out new HIPAA regulations in 2025. It’s designed to strengthen patient privacy and security in the face of these changes. These HIPAA updates are a response to the rise of telemedicine, the growing use of electronic health records (EHR), and an alarming increase in […]

The post How the New HIPAA Regulations 2025 Will Impact Healthcare Compliance appeared first on Centraleyes.

The post How the New HIPAA Regulations 2025 Will Impact Healthcare Compliance appeared first on Security Boulevard.

Many tech professionals see integrating large language models (LLMs) as a simple process -just connect an API and let it run. At Wallarm, our experience has proved otherwise. Through rigorous testing and iteration, our engineering team uncovered several critical insights about deploying LLMs securely and effectively.  This blog shares our journey of integrating cutting-edge AI [...]

The post Five Uncomfortable Truths About LLMs in Production appeared first on Wallarm.

The post Five Uncomfortable Truths About LLMs in Production appeared first on Security Boulevard.

What is AI Security? AI security is where traditional cybersecurity meets the chaotic brilliance of machine learning. It’s the discipline focused on protecting AI systems—not just the code, but the training data, model logic, and output—from manipulation, theft, and misuse. Because these systems learn from data, not just logic, they open up fresh attack surfaces […]

The post AI Security Guide: Protecting models, data, and systems from emerging threats appeared first on Security Boulevard.

Zero-trust security models are also changing how we think about identity management. The traditional approach of "authenticate once, access everything" is giving way to "authenticate constantly, verify everything." This doesn't change the basic roles of SCIM and SAML, but it does mean that these technologies need to work together more seamlessly and respond more quickly to changes.

The post SCIM vs SAML: Understanding the Difference Between Provisioning and Authentication appeared first on Security Boulevard.

At Sonatype, innovation knows no borders. We're excited to announce the opening of our new engineering hub in Hyderabad, India — a strategic milestone in our commitment to scale global innovation  and deliver continuous value to our customers around the world.

The post Sonatype expands global innovation with new India engineering center appeared first on Security Boulevard.

Secure your data throughout its lifecycle with End-to-End Data Protection
madhav
Thu, 06/19/2025 - 04:53

To most of us, perhaps unknowingly, data is everything. Whether it is a groundbreaking idea, sensitive health records, or confidential business strategies, data underpins both our personal and professional lives. That is why protecting it at every stage (at rest, in transit, and in use) is no longer optional. It is essential.

But in today’s fast-paced digital environment, ensuring that data stays secure is becoming more challenging than ever. Organizations are rapidly shifting to the cloud, embracing hybrid work, and collaborating across borders. These shifts offer agility and scale, but they also introduce new vulnerabilities and regulatory pressures.

How can businesses stay ahead of these challenges without slowing down innovation?

That’s where Thales’ End-to-End Data Protection (E2EDP) comes in. Designed to meet the needs of modern, multi-environment enterprises, Thales E2EDP ensures that your data stays always protected, no matter where it travels or who accesses it. By combining robust encryption, trusted execution environments, and support from Intel Tiber Trust Authority and major cloud providers, this solution brings continuous, verifiable protection to even the most sensitive workloads.

Who Needs E2EDP?

Organizations in highly regulated industries or those subject to mandates such as DORA or NIST will benefit significantly from E2EDP’s persistent protection and zero-trust approach. Whether it is public sector data, financial transactions, or healthcare records, E2EDP ensures your data remains safe, even in unfamiliar new environments.

In this blog, we will explore several real-world use cases that show how organizations can secure their data, from cloud migrations to multi-party collaborations, thanks to the powerful alliance between Intel, Thales, and today’s leading cloud platforms.  

Confidential AI: Unlocking Insights Without Exposing Data

Artificial Intelligence (AI) is transforming industries like finance, healthcare, and retail, but training AI models often requires sensitive data. How do you harness the value of AI without compromising security or privacy?

By executing AI workloads with Confidential Computing using E2EDP, the pipeline of Confidential AI is set; this secure approach allows different organizations to collaborate between them, sharing sensitive datasets within Confidential Computing Trusted Execution Environments but at the same time, preserving the privacy of their own datasets, without revealing the raw data itself to the other parties. Let us look at an example.

A bank working to prevent fraud and money laundering needs to analyze large volumes of financial data. To find broader patterns, it may need to share insights with other institutions. Traditionally, this meant risking customer privacy. With Confidential AI, however, multiple banks can analyze combined datasets without exposing any sensitive information. Thanks to confidential computing, independent attestation, and data protection powered by Thales.

With E2EDP it's ensured that:

• Only authorized users can access the raw datasets and results.
• Preserving the privacy of raw data that stays invisible to unauthorized parties.
• All operations happen in a verified, isolated environment.

Secure Cloud Migration: Lift-and-Shift with Confidence

Moving legacy systems to the cloud, especially those handling sensitive data, can be risky. But E2EDP makes "lift-and-shift" safe and seamless.

With E2EDP:

• Data is encrypted on-prem and stays protected throughout its journey.
• Customers keep full control over encryption keys.
• Data is only processed within attested secure environments in the cloud.

This enables organizations to migrate workloads with confidence while meeting compliance requirements and enabling secure multi-party collaboration in new environments.

E2EDP, Trusted Security from Edge to Cloud

E2EDP combines state-of-the-art leading technologies of Thales, Intel, and leading cloud providers. This solution is designed for organizations that need to maintain the highest levels of data security, especially in regulated sectors at all stages of data, at rest, in transit, and in use.

With E2EDP, data is protected at every stage:

• At Rest: Encrypted using Thales CipherTrust Transparent Encryption and controlled by the customer.
• In Transit: Stays encrypted from source to destination.
• In Use: Verified using Intel Trust Authority, with access granted only to authorized parties within confidential computing environments.

This level of protection ensures that no unauthorized user, not even cloud administrators, can view or tamper with your sensitive workloads.

Protect Your Data, Everywhere and Always

The future of secure data is end-to-end protection. Whether you are migrating to the cloud, running AI workloads, or sharing sensitive insights across partners, E2EDP gives you confidence that your data is private, protected, and compliant, wherever it goes.

In a world where trust and privacy are paramount, Thales’ End-to-End Data Protection sets a new standard for secure computing.

See E2EDP in action: https://youtu.be/eYybFcYc-S4.

For more information, visit  End-to-End Data Protection | Thales.

Encryption

Randy Hildebrandt | Product Marketing, Data Protection
More About This Author > Schema {
"@context": "https://schema.org",
"@type": "BlogPosting",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://cpl.thalesgroup.com/blog/encryption/end-to-end-data-protection-thales"
},
"headline": "Enterprise Data Security with Thales E2EDP",
"description": "Secure sensitive workloads at rest, in transit, and in use with Thales End-to-End Data Protection - trusted encryption from edge to cloud.",
"image": "",
"author": {
"@type": "Person",
"name": "Randy Hildebrandt",
"url": "https://cpl.thalesgroup.com/blog/auther/rhildebrandt"
},
"publisher": {
"@type": "Organization",
"name": "Thales Group",
"description": "The world relies on Thales to protect and secure access to your most sensitive data and software wherever it is created, shared, or stored. Whether building an encryption strategy, licensing software, providing trusted access to the cloud, or meeting compliance mandates, you can rely on Thales to secure your digital transformation.",
"url": "https://cpl.thalesgroup.com",
"logo": "https://cpl.thalesgroup.com/sites/default/files/content/footer/thaleslogo-white.png",
"sameAs": [
"https://www.twitter.com/ThalesCloudSec",
"https://www.linkedin.com/company/thalescloudsec",
"https://www.youtube.com/ThalesCloudSec"
]
},
"datePublished": "2025-06-19",
"dateModified": "2025-06-19"
}

basic

The post Secure your data throughout its lifecycle with End-to-End Data Protection appeared first on Security Boulevard.

Miami, June 18, 2025, CyberNewswire — Halo Security today announced that its attack surface management solution has been named a 2025 MSP Today Product of the Year Award winner by TMC, a leading global media company recognized for building communities … (more…)

The post News alert: Halo Security’s attack surface management platform wins MSP Today’s top award first appeared on The Last Watchdog.

The post News alert: Halo Security’s attack surface management platform wins MSP Today’s top award appeared first on Security Boulevard.

Why endpoint secure DNS adoption matters

In a world where we have security options (this is 2025, after all), and yet we don’t bother accessing them, it’s like having vegetables and protein at the buffet but all we eat is the desert. No wonder we’re not doing as well as we could be doing! So, we think it’s time to check on our buffet of healthy options available when it comes to DNS encryption.

Last-mile DNS Encryption and how we got here

This has been a long time coming. Many critical protocols have started out as a sketch on the back of a napkin, only to be adopted for their simplicity and immediate functionality. At some point later on, the protocol is then optimized and only after it is abused, does it finally get secured. Not surprisingly, that is the story with last-mile DNS encryption as well. It is such a broad attack vector that it’s time to address this weakness.

Encrypted DNS Server support

The DNS is the ultimate client-server application environment. Naturally, the server must offer support before client endpoints could make use of it. All things considered, server-side adoption has occurred over the past few years at a decent pace to the point where most DNS server products, including public resolvers, support DoH and DoT standards.

Endpoint OS support

It goes without saying that it will take some time before we reach critical mass on endpoint DNS encryption adoption simply because the lifecycle of endpoints can be measured in months, years or even decades. The effort in this blog article is to see where we are with the largest market share of endpoint operating systems, running the latest version of iOS, Android and Windows. Here is the TL;DR:

iOS 18.5 Android 15 Windows 11 (OS Build 27871) DDR Verified only (no support for opportunistic discovery) No support No support DNR DHCP Encrypted DNS Option No support No support Yes* Proprietary Upgrade n/a Yes** n/a

*This isn’t a default feature yet, but requires a registry entry, see below
**Android just attempts to use DNS-over-TLS immediately upon receiving a DHCP-assigned DNS option (6).

Testing environment and methodology

Our effort essentially is to use the latest available Operating System on our core product offering with DDR opportunistic support as well as DNR:

Setup with adam:ONE

• Dashboard → Manage Network → Advanced → Encryption → Enable internal DNS encryption
• Validate the DoH and DoT offers with a standard DDR query:

protectedendpoint: dig SVCB _dns.resolver.arpa ; <<>> DiG 9.20.6 <<>> SVCB @192.168.1.1 _dns.resolver.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44620 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;_dns.resolver.arpa. IN SVCB ;; ANSWER SECTION: _dns.resolver.arpa. 60 IN SVCB 1 280test-xkboiopjp0.2my.network. alpn="h2" port=443 ipv4hint=192.168.1.1 key7="/dns-query{?dns}" _dns.resolver.arpa. 60 IN SVCB 2 280test-xkboiopjp0.2my.network. alpn="dot" port=853 ipv4hint=192.168.1.1 ;; Query time: 0 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP) ;; WHEN: Wed Jun 18 20:03:26 EDT 2025 ;; MSG SIZE rcvd: 172

• DNS setup via Kea DHCP Server with the following custom JSON configuration on this LAN segment:

{ "option-data": [ { "name": "v4-dnr", "data": "1, 280test-xkboiopjp0.2my.network., 192.168.1.1, alpn=h2 dohpath=/dns-query{?dns} port=443" } ] } Setup and result on Windows:

Windows 11 requires an administrator cmd regedit like this, thanks to this blog article for the hints:

reg add HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters /v EnableDnr /t REG_DWORD /d 1

Upon restart, the very first query came via DoH as the server-side log shows with [DoH] for each entry that came in over DoH:

I 18/6 12:59:07.625203 40107 DNS? 192.168.1.102@49670 TCP4 www.msftconnecttest.com A | [DoH] I 18/6 12:59:08.797999 40107 DNS? 192.168.1.102@49676 TCP4 mobile.events.data.microsoft.com A | [DoH] I 18/6 12:59:08.801119 40107 DNS? 192.168.1.102@49676 TCP4 client.wns.windows.com A | [DoH] I 18/6 12:59:09.909035 40107 DNS? 192.168.1.102@49676 TCP4 -keyid-46027e9f5683eff2b6745379a63b00ab0b637d10.microsoftaik.azure.net A | [DoH] I 18/6 12:59:11.367439 40107 DNS? 192.168.1.102@49676 TCP4 login.live.com A | [DoH] I 18/6 12:59:11.380371 40107 DNS? 192.168.1.102@56568 UDP4 config.edge.skype.com A | [DNS] I 18/6 12:59:11.380563 40107 DNS? 192.168.1.102@60653 UDP4 config.edge.skype.com HTTPS | [DNS] I 18/6 12:59:11.522564 40107 DNS? 192.168.1.102@49676 TCP4 officeclient.microsoft.com A | [DoH] I 18/6 12:59:11.795422 40107 DNS? 192.168.1.102@49676 TCP4 fd.api.iris.microsoft.com A | [DoH] I 18/6 12:59:11.819713 40107 DNS? 192.168.1.102@49676 TCP4 www.msn.com A | [DoH] I 18/6 12:59:11.830938 40107 DNS? 192.168.1.102@49676 TCP4 odc.officeapps.live.com A | [DoH] I 18/6 12:59:11.992085 40107 DNS? 192.168.1.102@49676 TCP4 ocsp.digicert.com A | [DoH] I 18/6 12:59:12.044973 40107 DNS? 192.168.1.102@49676 TCP4 -keyid-46027e9f5683eff2b6745379a63b00ab0b637d10.microsoftaik.azure.net A | [DoH] I 18/6 12:59:12.095170 40107 DNS? 192.168.1.102@49676 TCP4 arc.msn.com A | [DoH] I 18/6 12:59:12.236387 40107 DNS? 192.168.1.102@49676 TCP4 v20.events.data.microsoft.com A | [DoH] I 18/6 12:59:12.357970 40107 DNS? 192.168.1.102@49676 TCP4 sdx.microsoft.com A | [DoH] I 18/6 12:59:12.361815 40107 DNS? 192.168.1.102@49676 TCP4 assets.msn.com A | [DoH] I 18/6 12:59:12.466024 40107 DNS? 192.168.1.102@49676 TCP4 nav.smartscreen.microsoft.com A | [DoH] I 18/6 12:59:12.721586 40107 DNS? 192.168.1.102@49676 TCP4 data-edge.smartscreen.microsoft.com A | [DoH] I 18/6 12:59:13.499324 40107 DNS? 192.168.1.102@49676 TCP4 web.vortex.data.microsoft.com A | [DoH] I 18/6 12:59:13.552460 40107 DNS? 192.168.1.102@49676 TCP4 oloobe.officeapps.live.com A | [DoH] I 18/6 12:59:14.030990 40107 DNS? 192.168.1.102@49676 TCP4 cdnjs.cloudflare.com A | [DoH] I 18/6 12:59:14.034126 40107 DNS? 192.168.1.102@49676 TCP4 content.lifecycle.office.net A | [DoH] I 18/6 12:59:14.183873 40107 DNS? 192.168.1.102@49676 TCP4 c.pki.goog A | [DoH] I 18/6 12:59:14.899057 40107 DNS? 192.168.1.102@49676 TCP4 browser.pipe.aria.microsoft.com A | [DoH] I 18/6 12:59:15.060458 40107 DNS? 192.168.1.102@60416 UDP4 www.bing.com A | [DNS] I 18/6 12:59:15.060655 40107 DNS? 192.168.1.102@59254 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:15.068097 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:15.068793 40107 DNS? 192.168.1.102@50578 UDP4 www.bing.com A | [DNS] I 18/6 12:59:15.068888 40107 DNS? 192.168.1.102@50410 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:15.080342 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:15.081047 40107 DNS? 192.168.1.102@64168 UDP4 www.bing.com A | [DNS] I 18/6 12:59:15.081146 40107 DNS? 192.168.1.102@57723 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:15.096385 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:15.402697 40107 DNS? 192.168.1.102@61377 UDP4 searchapp.bundleassets.example A | [DNS] I 18/6 12:59:15.402845 40107 DNS? 192.168.1.102@52294 UDP4 searchapp.bundleassets.example HTTPS | [DNS] I 18/6 12:59:15.406621 40107 DNS? 192.168.1.102@62267 UDP4 searchapp.bundleassets.example HTTPS | [DNS] I 18/6 12:59:15.406720 40107 DNS? 192.168.1.102@54613 UDP4 searchapp.bundleassets.example A | [DNS] I 18/6 12:59:15.410512 40107 DNS? 192.168.1.102@49676 TCP4 searchapp.bundleassets.example A | [DoH] I 18/6 12:59:15.935672 40107 DNS? 192.168.1.102@53280 UDP4 www.bing.com A | [DNS] I 18/6 12:59:15.935940 40107 DNS? 192.168.1.102@57009 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:15.953100 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:15.953972 40107 DNS? 192.168.1.102@51615 UDP4 www.bing.com A | [DNS] I 18/6 12:59:15.954168 40107 DNS? 192.168.1.102@56535 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:15.969144 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:16.235461 40107 DNS? 192.168.1.102@63650 UDP4 www.bing.com A | [DNS] I 18/6 12:59:16.235671 40107 DNS? 192.168.1.102@52874 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:16.256281 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:16.257040 40107 DNS? 192.168.1.102@51858 UDP4 www.bing.com A | [DNS] I 18/6 12:59:16.257160 40107 DNS? 192.168.1.102@62638 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:16.272239 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:17.186769 40107 DNS? 192.168.1.102@49676 TCP4 nf.smartscreen.microsoft.com A | [DoH] I 18/6 12:59:18.459635 40107 DNS? 192.168.1.102@49676 TCP4 th.bing.com A | [DoH] I 18/6 12:59:18.459869 40107 DNS? 192.168.1.102@49676 TCP4 img-s-msn-com.akamaized.net A | [DoH] I 18/6 12:59:18.460063 40107 DNS? 192.168.1.102@49676 TCP4 assets.msn.com A | [DoH] I 18/6 12:59:18.645218 40107 DNS? 192.168.1.102@49676 TCP4 ocsp.digicert.com A | [DoH] I 18/6 12:59:20.938553 40107 DNS? 192.168.1.102@64062 UDP4 www.bing.com A | [DNS] I 18/6 12:59:20.938723 40107 DNS? 192.168.1.102@52576 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:20.952151 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:20.952799 40107 DNS? 192.168.1.102@57697 UDP4 www.bing.com A | [DNS] I 18/6 12:59:20.952897 40107 DNS? 192.168.1.102@49593 UDP4 www.bing.com HTTPS | [DNS] I 18/6 12:59:20.967727 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH] I 18/6 12:59:21.534849 40107 DNS? 192.168.1.102@49676 TCP4 self.events.data.microsoft.com A | [DoH] I 18/6 12:59:25.949726 40107 DNS? 192.168.1.102@55461 UDP4 www.bing.com A | [DNS] Interesting observations of DNS queries coming from Windows when DNR is enabled

• The very first connectivity test is over DoH
• Many other queries still use legacy DNS (labeled as [DNS] at the end of each query

Setup and result on Android:

Our Android test device is a Samsung Knox phone with the latest update including Android 15. It completely ignores the DNR option, never makes a DDR query but immediately assumes DoT availability on DHCP Option 6 as can be seen in the queries for the first number of seconds on bootup:

I 18/6 12:45:04.130833 40107 DNS? 192.168.1.104@34412 TCP4 yhqakv-dnsotls-ds.metric.gstatic.com AAAA | [DoT] I 18/6 12:45:04.170452 40107 DNS? 192.168.1.104@23171 UDP4 www.google.com A | [DNS] I 18/6 12:45:04.177893 40107 DNS? 192.168.1.104@23171 UDP4 www.google.com A | [DNS] I 18/6 12:45:04.177948 40107 DNS? 192.168.1.104@34412 TCP4 yhqakv-dnsotls-ds.metric.gstatic.com AAAA | [DoT] I 18/6 12:45:04.181311 40107 DNS? 192.168.1.104@45450 UDP4 yhqakv-dnsotls-ds.metric.gstatic.com AAAA | [DNS] I 18/6 12:45:04.192875 40107 DNS? 192.168.1.104@19031 UDP4 connectivitycheck.gstatic.com A | [DNS] I 18/6 12:45:04.200337 40107 DNS? 192.168.1.104@19031 UDP4 connectivitycheck.gstatic.com A | [DNS] I 18/6 12:45:04.209486 40107 DNS? 192.168.1.104@1924 UDP4 www.google.com A | [DNS] I 18/6 12:45:04.212849 40107 DNS? 192.168.1.104@1924 UDP4 www.google.com A | [DNS] I 18/6 12:45:04.259635 40107 DNS? 192.168.1.104@62826 UDP4 time.android.com A | [DNS] I 18/6 12:45:04.262401 40107 DNS? 192.168.1.104@62826 UDP4 time.android.com A | [DNS] I 18/6 12:45:04.376422 40107 DNS? 192.168.1.104@11264 UDP4 north-america.pool.ntp.org A | [DNS] I 18/6 12:45:04.385530 40107 DNS? 192.168.1.104@11264 UDP4 north-america.pool.ntp.org A | [DNS] I 18/6 12:45:04.396185 40107 DNS? 192.168.1.104@34420 TCP4 scs-use2.bixbyllm.com A | [DoT] I 18/6 12:45:04.411160 40107 DNS? 192.168.1.104@24572 UDP4 2.android.pool.ntp.org A | [DNS] I 18/6 12:45:04.413913 40107 DNS? 192.168.1.104@24572 UDP4 2.android.pool.ntp.org A | [DNS] I 18/6 12:45:04.573249 40107 DNS? 192.168.1.104@44869 UDP4 connectivitycheck.gstatic.com A | [DNS] I 18/6 12:45:04.603191 40107 DNS? 192.168.1.104@34420 TCP4 qcc.qualcomm.com A | [DoT] I 18/6 12:45:04.699213 40107 DNS? 192.168.1.104@34420 TCP4 mtalk.google.com A | [DoT] I 18/6 12:45:05.892239 40107 DNS? 192.168.1.104@41745 UDP4 connectivitycheck.gstatic.com AAAA | [DNS] I 18/6 12:45:05.892538 40107 DNS? 192.168.1.104@39507 UDP4 www.google.com AAAA | [DNS] I 18/6 12:45:05.892656 40107 DNS? 192.168.1.104@13190 UDP4 www.google.com A | [DNS] I 18/6 12:45:06.226486 40107 DNS? 192.168.1.104@34420 TCP4 app-measurement.com A | [DoT] I 18/6 12:45:06.287595 40107 DNS? 192.168.1.104@34420 TCP4 www.googleapis.com A | [DoT] I 18/6 12:45:06.797100 40107 DNS? 192.168.1.104@34420 TCP4 api.account.samsung.com A | [DoT] I 18/6 12:45:06.813581 40107 DNS? 192.168.1.104@34420 TCP4 2.android.pool.ntp.org A | [DoT] I 18/6 12:45:06.884893 40107 DNS? 192.168.1.104@34420 TCP4 roughtime.int08h.com A | [DoT] I 18/6 12:45:07.123092 40107 DNS? 192.168.1.104@34420 TCP4 scs-use2.bixbyllm.com A | [DoT] I 18/6 12:45:07.832489 40107 DNS? 192.168.1.104@34420 TCP4 us-auth2.samsungosp.com A | [DoT] I 18/6 12:45:08.070911 40107 DNS? 192.168.1.104@34420 TCP4 voilatile-pa.googleapis.com A | [DoT] I 18/6 12:45:08.472463 40107 DNS? 192.168.1.104@34420 TCP4 www.samsung.com A | [DoT] I 18/6 12:45:08.527292 40107 DNS? 192.168.1.104@34420 TCP4 play.samsungcloud.com A | [DoT] I 18/6 12:45:08.563534 40107 DNS? 192.168.1.104@55956 UDP4 www.google.com A | [DNS] I 18/6 12:45:08.574401 40107 DNS? 192.168.1.104@34420 TCP4 remoteprovisioning.googleapis.com A | [DoT] I 18/6 12:45:08.628146 40107 DNS? 192.168.1.104@34420 TCP4 pinning-02.secb2b.com A | [DoT] I 18/6 12:45:08.680158 40107 DNS? 192.168.1.104@34420 TCP4 gmscompliance-pa.googleapis.com A | [DoT] I 18/6 12:45:08.813855 40107 DNS? 192.168.1.104@34420 TCP4 connectivitycheck.gstatic.com A | [DoT] I 18/6 12:45:08.816766 40107 DNS? 192.168.1.104@34420 TCP4 www.tizen.org A | [DoT] I 18/6 12:45:09.019037 40107 DNS? 192.168.1.104@34420 TCP4 vas.samsungapps.com A | [DoT] I 18/6 12:45:09.047106 40107 DNS? 192.168.1.104@34420 TCP4 firebaseremoteconfig.googleapis.com A | [DoT] I 18/6 12:45:09.050303 40107 DNS? 192.168.1.104@36682 UDP4 www.google.com A | [DNS] I 18/6 12:45:09.119191 40107 DNS? 192.168.1.104@50465 UDP4 216.58.202.4.in-addr.arpa PTR | [DNS] I 18/6 12:45:09.121136 40107 DNS? 192.168.1.104@55885 UDP4 *google.com A | [DNS] I 18/6 12:45:09.127663 40107 DNS? 192.168.1.104@37673 UDP4 www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com A | [DNS] I 18/6 12:45:09.130458 40107 DNS? 192.168.1.104@44701 UDP4 GOOGLE.COM A | [DNS] I 18/6 12:45:09.130650 40107 DNS? 192.168.1.104@44705 UDP4 google.com A | [DNS] I 18/6 12:45:09.135176 40107 DNS? 192.168.1.104@36207 UDP4 google.com A | [DNS] I 18/6 12:45:09.137538 40107 DNS? 192.168.1.104@38163 UDP4 google.com A | [DNS] I 18/6 12:45:09.153497 40107 DNS? 192.168.1.104@34420 TCP4 www.craigslist.org A | [DoT] I 18/6 12:45:09.158082 40107 DNS? 192.168.1.104@56577 UDP4 google.com A | [DNS] I 18/6 12:45:09.173495 40107 DNS? 192.168.1.104@47085 UDP4 google.com A | [DNS] I 18/6 12:45:09.277263 40107 DNS? 192.168.1.104@37715 UDP4 google.com.onion A | [DNS] I 18/6 12:45:09.302229 40107 DNS? 192.168.1.104@33692 UDP4 google.com NS | [DNS] I 18/6 12:45:09.307605 40107 DNS? 192.168.1.104@49151 UDP4 google.com A | [DNS] I 18/6 12:45:09.316919 40107 DNS? 192.168.1.104@34420 TCP4 gsl.samsunggsl.com A | [DoT] I 18/6 12:45:09.330382 40107 DNS? 192.168.1.104@43499 UDP4 google.com CNAME | [DNS] I 18/6 12:45:09.341423 40107 DNS? 192.168.1.104@47015 UDP4 google.com SOA | [DNS] I 18/6 12:45:09.343975 40107 DNS? 192.168.1.104@48022 UDP4 216.58.202.4.in-addr.arpa PTR | [DNS] I 18/6 12:45:09.353547 40107 DNS? 192.168.1.104@41133 UDP4 google.com 13 | [DNS] I 18/6 12:45:09.402174 40107 DNS? 192.168.1.104@60555 UDP4 google.com WKS | [DNS] I 18/6 12:45:09.515895 40107 DNS? 192.168.1.104@52889 UDP4 google.com A | [DNS] I 18/6 12:45:09.766511 40107 DNS? 192.168.1.104@34420 TCP4 time.google.com A | [DoT] I 18/6 12:45:09.798048 40107 DNS? 192.168.1.104@34420 TCP4 clienttracing-pa.googleapis.com A | [DoT] I 18/6 12:45:09.798405 40107 DNS? 192.168.1.104@34420 TCP4 www.google.com A | [DoT] I 18/6 12:45:09.806167 40107 DNS? 192.168.1.104@34420 TCP4 discover-pa.googleapis.com A | [DoT] I 18/6 12:45:09.914599 40107 DNS? 192.168.1.104@34420 TCP4 es11.samsung-sm-ds.com A | [DoT] I 18/6 12:45:10.090984 40107 DNS? 192.168.1.104@34420 TCP4 roughtime.cloudflare.com A | [DoT] I 18/6 12:45:10.402509 40107 DNS? 192.168.1.104@34420 TCP4 safebrowsing.googleapis.com A | [DoT] I 18/6 12:45:10.416315 40107 DNS? 192.168.1.104@34420 TCP4 policy.samsungcloud.com A | [DoT] I 18/6 12:45:10.466249 40107 DNS? 192.168.1.104@34420 TCP4 time.xtracloud.net A | [DoT] I 18/6 12:45:10.783074 40107 DNS? 192.168.1.104@34420 TCP4 capi.samsungcloud.com A | [DoT] I 18/6 12:45:11.148622 40107 DNS? 192.168.1.104@34420 TCP4 lpa.live.esimdiscovery.com A | [DoT] I 18/6 12:45:11.152048 40107 DNS? 192.168.1.104@34420 TCP4 us-gslu.samsunggsl.com A | [DoT] I 18/6 12:45:11.402690 40107 DNS? 192.168.1.104@34420 TCP4 encrypted-tbn3.gstatic.com A | [DoT] I 18/6 12:45:11.407567 40107 DNS? 192.168.1.104@34420 TCP4 ssl.gstatic.com A | [DoT] I 18/6 12:45:11.407745 40107 DNS? 192.168.1.104@34420 TCP4 www.gstatic.com A | [DoT] I 18/6 12:45:11.407897 40107 DNS? 192.168.1.104@34420 TCP4 encrypted-tbn0.gstatic.com A | [DoT] I 18/6 12:45:11.489656 40107 DNS? 192.168.1.104@34420 TCP4 clients2.google.com A | [DoT] I 18/6 12:45:11.641547 40107 DNS? 192.168.1.104@34420 TCP4 dvs.samsungmobile.com A | [DoT] I 18/6 12:45:11.699535 40107 DNS? 192.168.1.104@34420 TCP4 accounts.google.com A | [DoT] I 18/6 12:45:11.886269 40107 DNS? 192.168.1.104@34420 TCP4 sdk.pushmessage.samsung.com A | [DoT] I 18/6 12:45:12.151010 40107 DNS? 192.168.1.104@38163 UDP4 google.com A | [DNS] I 18/6 12:45:12.358996 40107 DNS? 192.168.1.104@34420 TCP4 encrypted-tbn2.gstatic.com A | [DoT] I 18/6 12:45:12.362051 40107 DNS? 192.168.1.104@34420 TCP4 geller-pa.googleapis.com A | [DoT] I 18/6 12:45:12.402978 40107 DNS? 192.168.1.104@60555 UDP4 google.com WKS | [DNS] I 18/6 12:45:12.446012 40107 DNS? 192.168.1.104@34420 TCP4 notifications-ueeshp-pa.googleapis.com A | [DoT] I 18/6 12:45:12.688201 40107 DNS? 192.168.1.104@34420 TCP4 ers.samsungcloud.com A | [DoT] I 18/6 12:45:12.790038 40107 DNS? 192.168.1.104@34420 TCP4 android.clients.google.com A | [DoT] I 18/6 12:45:12.859099 40107 DNS? 192.168.1.104@34420 TCP4 notifications-pa.googleapis.com A | [DoT] I 18/6 12:45:13.022836 40107 DNS? 192.168.1.104@34420 TCP4 play-fe.googleapis.com A | [DoT] I 18/6 12:45:13.081098 40107 DNS? 192.168.1.104@34420 TCP4 path2.xtracloud.net A | [DoT] I 18/6 12:45:13.279382 40107 DNS? 192.168.1.104@34420 TCP4 play.googleapis.com A | [DoT] I 18/6 12:45:13.507234 40107 DNS? 192.168.1.104@34420 TCP4 playstoregatewayadapter-pa.googleapis.com A | [DoT] I 18/6 12:45:13.747891 40107 DNS? 192.168.1.104@34420 TCP4 prod-lt-playstoregatewayadapter-pa.googleapis.com A | [DoT] I 18/6 12:45:13.986409 40107 DNS? 192.168.1.104@34420 TCP4 play-lh.googleusercontent.com A | [DoT] I 18/6 12:45:14.227720 40107 DNS? 192.168.1.104@34420 TCP4 i.ytimg.com A | [DoT] I 18/6 12:45:14.333421 40107 DNS? 192.168.1.104@34420 TCP4 api.weather.com A | [DoT] I 18/6 12:45:14.736183 40107 DNS? 192.168.1.104@34420 TCP4 oneclient.sfx.ms A | [DoT] I 18/6 12:45:14.761383 40107 DNS? 192.168.1.104@34420 TCP4 dcg.microsoft.com A | [DoT] I 18/6 12:45:14.902781 40107 DNS? 192.168.1.104@34420 TCP4 default.exp-tas.com A | [DoT] I 18/6 12:45:15.172440 40107 DNS? 192.168.1.104@34420 TCP4 ca-odc.samsungapps.com A | [DoT] I 18/6 12:45:15.374939 40107 DNS? 192.168.1.104@34420 TCP4 roughtime.sandbox.google.com A | [DoT] I 18/6 12:45:15.689301 40107 DNS? 192.168.1.104@34420 TCP4 storage.googleapis.com A | [DoT] I 18/6 12:45:15.733188 40107 DNS? 192.168.1.104@34420 TCP4 update.googleapis.com A | [DoT] I 18/6 12:45:16.031011 40107 DNS? 192.168.1.104@34420 TCP4 m.media-amazon.com A | [DoT] I 18/6 12:45:16.673755 40107 DNS? 192.168.1.104@34420 TCP4 mobile.events.data.microsoft.com A | [DoT] I 18/6 12:45:16.676291 40107 DNS? 192.168.1.104@34420 TCP4 scs-config-use2.bixbyllm.com A | [DoT] I 18/6 12:45:17.503677 40107 DNS? 192.168.1.104@34420 TCP4 in.appcenter.ms A | [DoT] Interesting observations on Android (as least on this Samsung device):

• The very first query came in over [DoT] but similar to Windows, there are queries that are not encrypted
• An invalid query is always made on startups for *google.com
• Another invalid query is always made for www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com (which, incidentally is not managed by MarkMonitor as many most Google TLD registrations are, and I know I’m far from the first one to observe this)

Setup and result on iOS:

iOS 18.5 on any modern phone produces the same result… not the first query but always the second query executes DDR, but ignored as it does not support the opportunistic feature:

I 18/6 12:52:42.703787 40107 DNS? 192.168.1.105@64126 UDP4 46-courier.push.apple.com A | [DNS] I 18/6 12:52:42.714170 40107 DNS? 192.168.1.105@54042 UDP4 _dns.resolver.arpa SVCB | [DNS] I 18/6 12:52:42.718757 40107 DNS? 192.168.1.105@54086 UDP4 280test-xkboiopjp0.2my.network HTTPS | [DNS] I 18/6 12:52:42.719385 40107 DNS? 192.168.1.105@49239 UDP4 280test-xkboiopjp0.2my.network A | [DNS] I 18/6 12:52:42.734130 40107 DNS? 192.168.1.105@65534 UDP4 gsp85-ssl.ls.apple.com HTTPS | [DNS] I 18/6 12:52:42.734293 40107 DNS? 192.168.1.105@57310 UDP4 gsp85-ssl.ls.apple.com A | [DNS] I 18/6 12:52:42.879236 40107 DNS? 192.168.1.105@57260 UDP4 configuration.ls.apple.com A | [DNS] I 18/6 12:52:42.879607 40107 DNS? 192.168.1.105@64697 UDP4 configuration.ls.apple.com HTTPS | [DNS] I 18/6 12:52:42.882839 40107 DNS? 192.168.1.105@56279 UDP4 gsp85-ssl.ls2-apple.com.akadns.net HTTPS | [DNS] I 18/6 12:52:42.883351 40107 DNS? 192.168.1.105@56222 UDP4 gsp85-ssl.ls2-apple.com.akadns.net A | [DNS] I 18/6 12:52:43.055124 40107 DNS? 192.168.1.105@52498 UDP4 mask.icloud.com HTTPS | [DNS] I 18/6 12:52:43.055247 40107 DNS? 192.168.1.105@49906 UDP4 mask.icloud.com A | [DNS] I 18/6 12:52:43.059336 40107 DNS? 192.168.1.105@51823 UDP4 configuration.ls.v.aaplimg.com HTTPS | [DNS] I 18/6 12:52:43.061545 40107 DNS? 192.168.1.105@50558 UDP4 mask-h2.icloud.com HTTPS | [DNS] I 18/6 12:52:43.061599 40107 DNS? 192.168.1.105@51986 UDP4 mask-h2.icloud.com A | [DNS] I 18/6 12:52:43.088667 40107 DNS? 192.168.1.105@58320 UDP4 configuration.ls.v.aaplimg.com A | [DNS] I 18/6 12:52:43.766236 40107 DNS? 192.168.1.105@51121 UDP4 gsp-ssl.ls.apple.com HTTPS | [DNS] I 18/6 12:52:43.766335 40107 DNS? 192.168.1.105@63807 UDP4 gsp-ssl.ls.apple.com A | [DNS] I 18/6 12:52:43.766357 40107 DNS? 192.168.1.105@60702 UDP4 _dns.resolver.arpa SVCB | [DNS] I 18/6 12:52:45.340823 40107 DNS? 192.168.1.105@53379 UDP4 captive.apple.com HTTPS | [DNS] I 18/6 12:52:45.341879 40107 DNS? 192.168.1.105@54459 UDP4 captive.apple.com A | [DNS] I 18/6 12:52:47.741795 40107 DNS? 192.168.1.105@51371 UDP4 gspe1-ssl.ls.apple.com HTTPS | [DNS] I 18/6 12:52:47.741901 40107 DNS? 192.168.1.105@51999 UDP4 gspe1-ssl.ls.apple.com A | [DNS] I 18/6 12:52:47.973044 40107 DNS? 192.168.1.105@64647 UDP4 captive.apple.com HTTPS | [DNS] I 18/6 12:52:47.973906 40107 DNS? 192.168.1.105@55777 UDP4 captive.apple.com A | [DNS] I 18/6 12:52:47.973942 40107 DNS? 192.168.1.105@57512 UDP4 gateway.icloud.com HTTPS | [DNS] I 18/6 12:52:47.975315 40107 DNS? 192.168.1.105@49851 UDP4 gateway.icloud.com A | [DNS] Observations on iOS:

• As stated above, DDR opportunistic mode is not supported, so iOS just stays on legacy Do53, cleartext, unencrypted

What about other OS platforms?

While other OS options such as vanilla Android, Chromebooks, Linux distributions, etc, are in use, I limited the report to what is represents 95% of the market usage today. Having said that, with my very simple one-shot test with the latest Ubuntu 24.04, I noticed it does not made a DDR request at all and ignores DNR, and makes not upgrade attempt unless I first added this to /etc/systemd/resolved.conf:

DNSOverTLS=opportunistic

As for DNR, it completely ignored the DHCP offer when using the same config as what Windows accepted above.

A note about Mobile Device Management

The three giant OS platforms all have MDM-enabled option for DoH:

• Windows with Intune/ZTDNS
• Samsung via Knox
• iOS with Enterprise apps enforcing a DoH URL for all DNS

The application of the above is only sometimes practical, hence a more local network or endpoint-centric option is necessary.

Call to action - we want our cake and eat it too

Wouldn’t it be nice if we made it easy for the MSP and sysadmins of the world to just make DNS be as secure as possible, starting with today’s heterogeneous environment and simply start by supporting DDR opportunistically when DNR or MDM-pushed options aren’t available? Keep in mind that rfc1918 is still the most common network IP deployment in SMB and SME and even Corporate networks. Furthermore in many organizations, the DHCP team is separate and distinct from the DNS team. Let’s give them both a chance and reduce the friction to adopting better security.

1 post - 1 participant

Read full topic

The post Endpoint adoption of Encrypted DNS appeared first on Security Boulevard.

The post The Growing Compliance Burden for GRC Teams appeared first on AI Security Automation.

The post The Growing Compliance Burden for GRC Teams appeared first on Security Boulevard.

The distinction between IAM and CIAM reflects the fundamental differences between managing internal organizational resources and serving external customers in the digital age. While both share common identity management principles, their implementation approaches, user experience requirements, and architectural considerations differ significantly.

The post Understanding IAM vs CIAM: A Comprehensive Guide to Identity Management Systems appeared first on Security Boulevard.

In a recent webinar, two expert K-12 technology leaders—Glen Drager, Network System Administrator at Tyrone Area School District, and Chris Rowbotham, Director of Technology at Siuslaw School District—joined ManagedMethods’ CRO David Waugh to explore the complexities and ever-evolving strategies behind a multilayered approach to K-12 cybersecurity. This thought leadership session walks you through building a ...

The post Defending Your Cyber Castle, Part 1: Building the Walls, Moat & Drawbridge of K-12 Security appeared first on ManagedMethods Cybersecurity, Safety & Compliance for K-12.

The post Defending Your Cyber Castle, Part 1: Building the Walls, Moat & Drawbridge of K-12 Security appeared first on Security Boulevard.

Uncover the Hidden Power of Secrets Rotation Have you ever pondered the security capabilities encrypted deep within your cloud environment? Among the most formidable tools is secrets rotation, a strategy that revolves around replacing “Secrets” or encrypted access credentials on a regular basis. I’m here to enlighten you on the powerful techniques that can enhance […]

The post Unlock Powerful Capabilities in Secrets Rotation appeared first on Entro.

The post Unlock Powerful Capabilities in Secrets Rotation appeared first on Security Boulevard.

Preventing Credential Stuffing Introduction In 2023, personal genomics company 23andMe suffered a major data breach that exposed sensitive genetic and personal information of nearly 7 million people. The breach was ultimately traced to a credential stuffing attack, in which hackers used lists of stolen username/password pairs from previous breaches to hijack 23andMe user accounts. This […]

The post Lessons from the 23andMe Breach and NIST SP 800-63B appeared first on Security Boulevard.

Online threats are everywhere, and no organization is safe from them. Whether it’s stolen data, ransomware, or phishing, attacks are becoming more frequent and severe. That’s why having a clear...

The post Cyber Risk Management Strategy: How to Plan appeared first on Security Boulevard.

The Iranian government has sharply restricted internet access in the country following almost a week of Israeli airstrikes and a cyberattacks on an Iranian bank and cryptocurrency exchange by a pro-Israeli hacker group called Predatory Sparrow.

The post Iran Reduces Internet Access After Israeli Airstrikes, Cyberattacks appeared first on Security Boulevard.

Author/Presenter: Oscar Baechler, MA (Author @ Packt Publishing, Professor, Lake Washington Institute of Technology)

Our sincere appreciation to LinuxFest Northwest (Now Celebrating Their Organizational 25th Anniversary Of Community Excellence), and the Presenters/Authors for publishing their superb LinuxFest Northwest 2025 video content. Originating from the conference’s events located at the Bellingham Technical College in Bellingham, Washington; and via the organizations YouTube channel.

Thanks and a Tip O' The Hat to Verification Labs :: Penetration Testing Specialists :: Trey Blalock GCTI, GWAPT, GCFA, GPEN, GPCS, GCPN, CRISC, CISA, CISM, CISSP, SSCP, CDPSE for recommending and appearing as speaker at the LinuxFest Northwest conference.

Permalink

The post LinuxFest Northwest: Your First Game In Godot appeared first on Security Boulevard.