university of washington

When customers keep pointing you to a solution that overlaps with parts of your own offering, you have a choice to make. This post is about the choice we made with Upwind, and why we’d make it again. AWS Security Hub Extended exists because customers told us what was working for them in enterprise security and asked us to simplify adoption and integration. Upwind was one of the solutions customers kept naming, so we brought them in. Upwind didn’t only agree to participate, they committed fully to integration. They brought their full solution portfolio into Extended with aggressive pay-as-you-go pricing from day one. They got their field organization fully aligned on joint deal flow and have driven more customer activity and closed deals through Security Hub Extended than any other partner in the program. Giving customers choice, even when it overlaps Multiple best-of-breed options in cloud security—including one that overlaps with our own capabilities—are straightforward when you start with what customers need. Some will choose Security Hub Essentials for cloud security posture management and vulnerability scanning. Some will choose Upwind for runtime-first protection. Some will run both and get stronger outcomes from the combination. The customer decides, not us. That principle applies to every partner in Security Hub Extended. We listen to what’s working, and we simplify adoption through the same AWS relationship customers already have. “Our customers run on AWS, and Security Hub is where their security operations live,” said Amiram Shachar, Co-Founder and CEO of Upwind. “Being inside Security Hub means customers get Upwind’s cloud workload protection with the same billing, the same support path, and the same operational model they already know. We’re here because it’s a better outcome for the customers we share.” Who is Upwind? Upwind is a cloud security company trusted by Siemens, Peloton, Roku, Wix, Nextdoor, and Nubank. Fast Company named them one of the Most Innovative Companies of 2026. What makes them different is runtime. Most cloud security solutions scan configurations periodically and report what could be a risk based on static posture. Upwind deploys an eBPF-based sensor directly in the Linux kernel that sees what workloads are doing in real time, including process behavior, network connections, API calls, and container interactions. All observed continuously. That means Upwind can tell you not only what could theoretically be exploited, but what is actively at risk right now. That distinction cuts alert noise dramatically and lets security teams focus on what genuinely matters. Better together. Not only with AWS, but with each other Now extend that to the rest of your security stack. If you’re already running other Security Hub Extended solutions, they work together without you building the integrations. A customer running Chainguard for supply chain security, Upwind for runtime protection, and Splunk for security operations gets a connected experience. Chainguard helps ensure clean, malware-resistant dependencies at build time. Upwind validates workload behavior at runtime and enriches those findings with real-time context. Everything flows into Splunk through Security Hub for unified triage. One experience, one bill, no custom integration work. The security team sees the full lifecycle from build to production without stitching tools together. That same pattern applies with 7AI, where AI-driven automation can triage and investigate Upwind’s runtime events alongside endpoint, identity, and network signals, all without manual pipeline work. This is the multi-way partnership that Security Hub Extended was designed to enable. These solutions aren’t only easier to buy together, they’re building toward each other. The findings flow into Security Hub in OCSF (Open Cybersecurity Schema Framework), get correlated and prioritized together, and route to the downstream tools your team already uses. Your security stack gets stronger as a whole, not only solution by solution. How it works commercially This isn’t a paper partnership. We’re closing multi-million dollar deals together through Security Hub Extended. Upwind has engaged faster than any other partner in the program, bringing their own customer opportunities and joining AWS-originated deals to close them jointly. One enterprise customer recently replaced their incumbent CNAPP with Upwind through a Security Hub Extended Private Offer. The deciding factors were runtime visibility that their previous solution couldn’t deliver and a single predictable commercial model that replaced complex per-module pricing across multiple vendors. The commercial model has momentum, and it’s because Upwind invested not only in signing an agreement but in the engineering and go-to-market work that makes joint success real. Upwind is available through Security Hub Extended with pay-as-you-go pricing, one AWS bill, and no required long-term commitment. For enterprises that prefer committed-pricing agreements, Security Hub Extended Private Offers are also available with deeper discounts and the ability to aggregate spend across partners. You choose the path that fits how you buy. If you’re already running Security Hub for posture management and vulnerability scanning, adding Upwind gives you runtime visibility alongside what you already see. No new tooling to stand up, no new workflow to learn. It shows up in your existing prioritized view of risk. What Upwind is building next Upwind continues to expand. AI workload protection that monitors model behavior and agent tool calls at runtime. Windows Server VM coverage across AWS, Azure, and GCP. Deeper integration with the Security Hub correlation engine so runtime context enriches attack-path intelligence automatically. The partnership deepens as both sides invest. “We believe runtime context and AWS-native signals together produce stronger outcomes than either alone,” said Amiram Shachar, Co-Founder and CEO of Upwind. “As Security Hub deepens its correlation and Upwind extends its runtime fabric, customers who use both will have a view of risk that no single solution can replicate. That’s the future we’re building toward together.” What this means for you Security Hub Extended exists to give you access to the solutions your peers are already succeeding with through the AWS relationship you already have. Upwind is what that philosophy looks like when applied to a category where AWS has an existing offering. We listened to customers, saw what was working for them, and made it available with the same commercial model as everything else. Enable Upwind through the AWS Security Hub console. Pay-as-you-go. No commitment required. If you want to understand what consolidation looks like with Security Hub Extended, talk to your AWS account team. We’re just getting started, but the momentum is real. If you have feedback about this post, submit comments in the Comments section below. Michael Fuller Michael has been with AWS for 16 years and led product for AWS Security Services for 11 years. Michael has 29 years in the industry and held several roles in product management, business development, and software development for IBM, Cisco, and Amazon. Michael has a Bachelor’s of Science in Computer Engineering from the University of Arizona and an MBA from the University of Washington.

Since February, we’ve grown AWS Security Hub Extended from 14 curated partners across 9 categories to 23 partners across 10. At Black Hat this month, 14 of those partners were at the Amazon Web Services (AWS) booth demoing live. Four of those partners delivered theater talks and ten were featured on SecurityLive streaming. We hosted a partner reception that brought our leadership together with partner executives to plan what comes next. These are companies investing real engineering and real go-to-market (GTM) alongside us, and increasingly with each other, because the model resonates with the customers they’re talking to every day. The most common question we heard at the booth was when Supply Chain Security was coming. It’s here. And that’s the thing I want to spend the most time on today, because it’s the category customers keep asking us about. Supply Chain Security: The category customers have been asking for Software supply chain risk has moved from a security-team concern to a board-level conversation. SolarWinds showed what happens when a build system is compromised. Log4j showed what a single transitive dependency vulnerability can do at global scale. The xz utils backdoor showed the patience of a maintainer-compromise attack executed over years. Each demonstrated a different dimension of the same problem, and the pace is accelerating. Attackers know that a fast way into an enterprise is through the open source packages that enterprise unknowingly trust. Every customer I talked to at Black Hat had this on their risk register. Most still hadn’t operationalized a solution, because doing so meant a standalone deployment, a new contract, a new console, and integration work their security team couldn’t prioritize. That’s the friction we aim to remove. Security Hub Extended now offers Supply Chain Security with Chainguard and Socket as the curated partners. Supply Chain Security uses the same model as everything else in Extended. Every offering has pay-as-you-go pricing, one bill, no required long-term commitment. For enterprises that prefer to continue using the procurement process they always have, Security Hub Extended Private Offers are also available. These are committed term agreements with deeper discounts, the ability to aggregate spend across partners on a single AWS bill, and both monthly and annual payment options throughout the term. You pick the path that fits how you buy. What Chainguard does Chainguard gives you open source dependencies rebuilt from source in a hardened, verified build process, so what enters your environment is malware-resistant and provenance-backed. Their research shows that rebuilding from source would have stopped 98% of known malicious packages from ever reaching production. If you can’t verify the source, it never appears in the Chainguard repository. That’s the filter between the public registry and your developers. What Socket does Socket analyzes the actual behavior of open source packages to block malicious dependencies at the time of install. Not after a Common Vulnerability and Exposures (CVE) is published days or weeks later. At the moment the package tries to land in your environment, Socket flags it based on what it does, not what a database says about it. Its reachability analysis then tells you which vulnerabilities are exploitable from your code instead of drowning your team in noise. You pay for the distinct packages you check, not for how often your builds run. Why they work together Together, Chainguard and Socket cover the two questions that matter: Can I trust what I’m pulling in? Can I stop malicious components before they get built into my applications? Chainguard helps secure the foundation your code is built on. Socket secures the packages you pull into it. Both help protect your software supply chain regardless of where you deploy—across clouds or on-premises. Activate both through Security Hub Extended and their findings flow into Security Hub in OCSF (Open Cybersecurity Schema Framework) alongside everything else, so a supply chain risk is correlated and prioritized next to your endpoint, identity, and cloud signals. From there, it routes out to the downstream tools you’ve already integrated, so it fits the pipeline your builders run today. 23 partners, 10 categories. Built on what customers asked for Every partner in Security Hub Extended is here because customers told us they needed that capability and that specific solution was already working for them. We add categories because the threat landscape evolves, and we add partners because customers point us to who’s solving those problems well. The goal is straightforward: Simplify adopting the security solutions your peers are already succeeding with, through the AWS relationship you already have. The full set today spans endpoint, identity, email, network, data, browser, cloud, AI, security operations, and now supply chain. The 23 curated partners are 7AI, Britive, Chainguard, CrowdStrike, Cyera, Island, LayerX, Native Security, Noma, Okta, Oligo, Opti, Palo Alto Networks, Proofpoint, SailPoint, SentinelOne, Socket, Splunk, Sublime, Upwind, Varonis, Zenity, and Zscaler. Our focus now is deepening integrations and reducing activation friction so these solutions work together, not in isolation. That’s where the real value compounds. What we’re building next Everything I’ve described so far is the commercial model working: Customers buying best-of-breed security through one AWS relationship with the flexibility they expect. But the bigger vision is the integration layer that makes these tools genuinely better together, not just easier to buy together. The integration we’re most focused on is cross-partner correlation, turning signals from an endpoint solution, an identity solution, and a cloud solution into one exposure and one attack path instead of three disconnected alerts. Right alongside that, we’re dramatically reducing the activation, deployment, and integration friction so customers go from subscribing to seeing value in hours rather than weeks. Both efforts enable the curated solutions you already trust to deliver stronger outcomes together than they do apart. That’s the build we’re accelerating with our partners now, and you’ll hear more leading into re:Invent. Explore what’s available If you’re running open source in production and don’t yet have supply chain visibility, start there. Activate Chainguard and Socket through the Security Hub console today. If you’re managing multiple security vendor relationships and want to understand what consolidation looks like with Security Hub Extended, talk to your AWS account team. Pricing for every partner is published on our pricing page , no sales call required. And if you’re already using Security Hub for posture management and threat detection, the Extended plan is available in the same console you already use. We’re just getting started. If you have feedback about this post, submit comments in the Comments section below. Michael Fuller Michael has been with AWS for 16 years and led product for AWS Security Services for 11 years. Michael has 29 years in the industry and held several roles in product management, business development, and software development for IBM, Cisco, and Amazon. Michael has a Bachelor’s of Science in Computer Engineering from the University of Arizona and an MBA from the University of Washington.

Passwords are where PCI DSS compliance often breaks down Most PCI DSS failures do not start with malware or a targeted attack. They start with everyday behavior. Reused passwords. Credentials stored in spreadsheets. Shared logins are passed around during busy periods. For CISOs, password hygiene remains one of the least technical and most difficult parts of compliance. PCI DSS 4.0 sharpened its focus on people. Training, authentication practices, and accountability now receive more scrutiny. The shift reflects a reality security leaders already know. Controls on paper do not matter if employees do not follow them. This is where password managers move from convenience tools to compliance infrastructure. Used correctly, they support PCI DSS requirements while shaping daily behavior. Used poorly or not at all, they become another gap auditors will find. Why PCI DSS puts employees under the microscope PCI DSS treats security awareness as a continuous responsibility rather than an annual task. Requirement 12.6 expects role-based training, ongoing awareness activities, and evidence that employees understand how their actions affect cardholder data security. That emphasis runs through the standard. Authentication requirements stress unique credentials. Shared passwords are discouraged. Access must be limited and reviewed. Organizations are expected to show that employees know how to protect credentials and why that protection matters. Many compliance programs struggle to bridge this gap. Policies exist. Training slides exist. Actual behavior tells another story. Employees reuse passwords because they manage too many systems. They store credentials insecurely because there is no approved alternative. Training explains what not to do, but does not provide a safe way to get work done. Public sector and higher education organizations offer useful examples of a more practical approach. At the University of Washington, employees who handle payment cards must complete PCI compliance training before gaining access and repeat that training annually. Completion is directly tied to access privileges rather than policy acknowledgment alone. Password rules do not build a password culture Most organizations already enforce password rules. Length requirements. Complexity standards. Rotation schedules. These controls satisfy technical expectations, but they do little to change habits. Employees experience them as friction. Longer passwords lead to more resets. Complexity rules encourage predictable patterns. Frequent rotation results in reused variations. None of this improves outcomes in practice. Security awareness programs are starting to reflect this reality. Public guidance increasingly promotes passphrases, unique passwords, and approved storage tools rather than memorization alone. The University of Illinois Chicago, for example, emphasizes long passphrases and discourages reuse while pointing users toward safer management practices. PCI DSS does not require employees to remember dozens of complex passwords. It requires secure authentication. CISOs who treat password managers as optional miss a chance to align compliance goals with how people actually work. Password managers as compliance enablers A password manager changes the compliance conversation. Instead of warning employees about risky behavior, it gives them a safer default. From a PCI DSS perspective, password managers support multiple requirement areas at once. They reduce reuse by generating unique credentials. They eliminate insecure storage methods like spreadsheets and notes. They centralize access for review. They support least privilege when paired with role-based permissions. Auditors often ask how organizations prevent password sharing. A password manager with access controls and logging provides a practical answer. It turns policy language into observable behavior. Alex Muntyan, CEO at Passwork, describes the shift this way. “Compliance breaks down when security tools work against employees. A password manager changes that dynamic. It allows people to do their jobs without weakening controls, which is what assessors expect to see.” Passwork is an on-premises solution that helps organizations centralize credential management within their own infrastructure. This appeals to PCI-scoped environments that prefer to keep sensitive access data under direct operational control rather than relying on external services. This model aligns with how some government security policies frame password management. Yavapai County’s security awareness policy explicitly includes password management as part of required training, reinforcing that approved tools are part of expected behavior rather than optional aids. Training that connects passwords to risk PCI DSS training expectations focus on understanding the impact. Employees must know how poor credential handling can expose cardholder data. Generic warnings about cyber threats are not enough. Programs tie password behavior to real consequences. A reused password can expose a payment application. A shared administrator account removes accountability. A saved browser password on a shared workstation creates audit risk. Some higher education security awareness standards use role-specific scenarios to make these risks concrete. Montana State University Northern outlines security awareness training that emphasizes employee responsibilities and testing rather than passive acknowledgment. Password managers fit naturally into this approach. Training can demonstrate how the tool prevents common mistakes. Awareness campaigns can reinforce the use of the manager instead of memorization. New hires learn secure habits early rather than unlearning risky ones later. Muntyan emphasizes that tools and training must reinforce each other. “If you train people to use strong passwords but give them no way to manage them, the training fails. When the password manager is part of onboarding, secure behavior becomes routine.” Mapping password managers to PCI DSS 4.x requirements CISOs often ask where password managers fit within the PCI DSS language. The standard does not mandate specific technologies, but it defines outcomes that password managers help achieve. Requirement 8 focuses on identifying users and authenticating access. Unique credentials and protection of authentication factors are core expectations. Requirement 12.6 addresses security awareness. Training must reflect real risks and employee responsibilities. Demonstrating that employees are trained to use approved credential management tools strengthens assessment evidence. Self-assessment questionnaires reinforce this operational focus. They ask how credentials are handled, how access is reviewed, and how training is documented, pushing organizations to demonstrate process rather than policy. Documentation matters. Training records should show that password manager usage is covered. Policies should identify it as the approved method. Logs should support accountability. Why Passwork fits the compliance conversation For a trade publication audience, vendor mentions require restraint. Passwork fits this discussion because it addresses common PCI DSS pain points without reframing compliance as a tooling problem. It supports controlled deployment models. It offers role-based access and audit logs that map to PCI accountability expectations. It allows teams to share credentials without revealing passwords, reducing informal workarounds. Muntyan notes that compliance-driven buyers prioritize visibility. “Security leaders want to know who accessed what and when. That visibility turns password management from a convenience feature into a control.” Positioning Passwork within training also matters. When employees are taught that the password manager is the expected way to handle credentials, adoption improves. When it is optional, old habits persist. Building habits instead of chasing violations The most effective PCI DSS programs reduce violations by design. They make the secure path easier than the insecure one. Awareness campaigns from state IT organizations emphasize simple guidance. Use long passphrases. Use unique passwords. Use the approved tool to store them. Password managers allow CISOs to shift from enforcement to enablement since they shape behavior upfront. This matters as PCI DSS assessments become more outcome-focused. Assessors look for evidence that controls work in practice. A workforce trained to use a password manager produces stronger evidence than one trained to memorize rules. Turning password management into a culture signal Culture shows up in small choices. Whether employees ask before sharing access. Whether they trust approved tools. Whether security feels like support or friction. PCI DSS 4.x pushes organizations to take those signals seriously. Passwords sit at the center of that shift because they touch every system and every user. Training alone does not change behavior. Tools alone do not create understanding. When password managers are integrated into both, compliance becomes easier to sustain. As Muntyan puts it, “When secure password handling becomes the default way of working, compliance stops being a project and becomes part of daily operations.” In a standard that increasingly measures how people behave, that distinction matters.

Researchers at US universities have demonstrated how a malicious Android app can trick the system into leaking pixel data. That may sound harmless, but imagine if a malicious app on your Android device could glimpse tiny bits of information on your screen—even the parts you thought were secure, like your two-factor authentication (2FA) codes. That’s the chilling idea behind “Pixnapping” attacks described in the research paper coming from University of California (Berkeley and San Diego), University of Washington, and Carnegie Mellon University. A pixel is one of the tiny colored dots that make up what you see on your device’s display. The researchers built a pixel-stealing framework that bypasses all browser protections and can even lift secrets from non-browser apps such as Google Maps, Signal, and Venmo—as well as websites like Gmail. It can even steal 2FA codes from Google Authenticator. Pixnapping is a classic side-channel attack—stealing secrets not by breaking into software, but by observing physical clues that devices give off during normal use. Pixel-stealing ideas date back to 2013, but this research shows new tricks for extracting sensitive data by measuring how specific pixels behave. The researchers tested their framework on modern Google Pixel phones (6, 7, 8, 9) and a Samsung Galaxy S25 and succeeded in stealing secrets from both browsers and non-browser apps. They disclosed the findings to Google and Samsung in early 2025. As of October 2025, Google has patched part of the vulnerability, but some workarounds remain and both companies are still working on a full fix. Other Android devices may also be vulnerable. The technical knowledge required to perform such an attack is enormous. This isn’t “script kiddie” territory: Attackers would need deep knowledge of Android internals and graphics hardware. But once developed, a Pixnapping app could be disguised as something harmless and distributed like any other piece of Android malware. To perform an attack, someone would have to convince or trick the target into installing the malicious app on their device. This app abuses Android Intents—a fundamental part of how apps communicate and interact with each other on Android devices. You can think of an intent like a message, or request, that one app sends either to another app or to the Android operating system itself, asking for something to happen. The malicious app’s programming will stack nearly transparent windows over the app it wants to spy on and watch for subtle timing signals that depend on pixel color. It doesn’t take long—the paper shows it can steal temporary 2FA codes from Google Authenticator in under 30 seconds. Once stolen, the data is sent to a command-and-control (C2) server controlled by the attacker. How to stay safe From the steps it takes to perform such an attack we can list some steps that can keep your 2FA codes and other secrets safe. Update regularly: Make sure your device and apps have the latest security updates. Google and Samsung are rolling out fixes; don’t ignore those update prompts. The underlying vulnerability is tracked as CVE-2025-48561. Be cautious installing apps: Only install apps from trusted sources like Google Play and check reviews and permissions before installing. Avoid sideloading unknown APKs and ask yourself if the permissions an app asks for are really needed for what you want it to do. Review permissions: Android improved its permission system, but check regularly what apps can do, and don’t hesitate to remove permissions of the ones you don’t use often. Use app screenshots wisely: Don’t store or display sensitive info (like codes, addresses, or logins) in apps unless needed, and close apps after use. Monitor security news: Look for announcements from Google and Samsung about patches for this vulnerability, and act on them. Enable Play Protect: Keep Play Protect active to help spot malicious apps before they’re installed. Use up-to-date real-time anti-malware protection on your Android device, preferably with a web protection module. If you’re worried about your 2FA codes getting stolen, consider switching to hardware token 2FA options. Scammers know more about you than you think. Malwarebytes Mobile Security protects you from phishing, scam texts, malicious sites, and more. With real-time AI-powered Scam Guard built right in.