Category: Uncategorized

The enactment of the Digital Personal Data Protection Act, 2023 (DPDP Act) represents a significant development in India’s legal framework governing the processing of personal data. As organisations increasingly rely on digital systems for accounting, taxation, compliance, customer management, analytics, and automation, personal data has become deeply embedded in everyday business operations. In this context, the protection of personal data is no longer a purely technological or IT-led concern, but an essential aspect of organisational responsibility and trust.

From a professional perspective, the DPDP Act requires an interpretative understanding rather than a narrow, checklist-driven approach. Its implications extend well beyond statutory compliance to areas such as corporate governance, internal controls, risk management, and audit assurance. Organisations are therefore expected to assess not only whether they comply with the letter of the law, but also whether appropriate governance frameworks, processes, and accountability mechanisms exist for responsible data handling.

This article provides an interpretative overview of the DPDP Act, 2023, and briefly explains the role of the Rules introduced in 2025, with a focus on aspects most relevant to professional and organisational practice.

Legislative Background and Scope

The DPDP Act is grounded in the Supreme Court’s recognition of the right to privacy as a fundamental right (Justice K.S. Puttaswamy v. Union of India, 2017). This landmark judgment established the constitutional basis for a comprehensive data protection regime in India, paving the way for legislation that balances individual rights with legitimate business and state interests.

Enacted in August 2023, the DPDP Act establishes a unified and nationally applicable framework for the processing of digital personal data in India. It seeks to replace fragmented and sector-specific practices with a consistent approach that applies across industries and organisational sizes.

The Act applies to:

• Processing of digital personal data within India, and
• Processing outside India where such data relates to individuals in India.

By adopting a principle-based approach, the legislature has focused on accountability and proportionality, rather than prescriptive compliance checklists. This provides organisations with flexibility in implementation, while placing the responsibility on them to demonstrate that data is handled lawfully and responsibly.

Key Concepts under the DPDP Act

The DPDP Act introduces foundational terms that carry significant governance implications and help clarify roles and responsibilities within the data ecosystem.

• Data Principal – the individual to whom personal data relates, such as customers, employees, vendors, or users.
• Data Fiduciary – the entity that determines the purpose and means of processing personal data.

This framework emphasises that organisations act as custodians of personal data, rather than owners. Personal data is therefore held in trust, and organisations are expected to exercise care, transparency, and accountability in how such data is collected, processed, and retained.

Consent and Lawful Processing

Consent forms the primary basis for lawful processing under the DPDP Act. Such consent must be free, specific, informed, and unambiguous, and must relate to a clearly defined and lawful purpose. Importantly, the Act also requires that consent be capable of being withdrawn, reinforcing individual control over personal data.

Although the Act recognises limited circumstances where processing may occur without consent—such as compliance with legal obligations—these situations are narrowly defined. Organisations must therefore design processes that ensure consent is not only obtained properly, but also documented, tracked, and honoured throughout the data lifecycle.

For professionals and organisations, this creates expectations similar to internal control documentation, where consent records, purpose limitation, and withdrawal mechanisms must be demonstrable, auditable, and consistently applied across systems.

Rights of the Data Principal

The DPDP Act grants enforceable rights to individuals, strengthening their ability to exercise control over their personal data. These include:

• The right to access information relating to personal data.
• The right to correction and erasure
• The right to grievance redressal

These rights impose operational responsibilities on organisations to maintain systems and processes that enable timely responses, ensure data accuracy, and track actions taken. Inadequate handling of such requests may indicate governance and control deficiencies and may also undermine stakeholder trust.

Significant Data Fiduciaries

Certain entities may be classified as Significant Data Fiduciaries (SDFs) based on the volume and sensitivity of personal data processed, or the potential risk posed to individuals. This classification reflects the principle that higher-risk data processing should be subject to enhanced safeguards.

SDFs are subject to additional obligations, including the appointment of a Data Protection Officer and the conduct of Data Protection Impact Assessments. These measures are intended to embed privacy considerations into organisational decision-making and to proactively identify and mitigate data-related risks.

This risk-based differentiation aligns with established governance and assurance principles and mirrors global best practices in data protection regulation.

DPDP Act, 2023 and the Role of the Rules Introduced in 2025

While the DPDP Act was enacted in 2023, its implementation is supported by delegated legislation in the form of Rules. In 2025, the Government initiated the issuance of draft Digital Personal Data Protection Rules to operationalise the Act and provide procedural clarity.

It is important to clarify that:

• The DPDP Act, 2023 remains the principal law.
• The Rules do not amend or replace the Act.
• The Rules specify procedural and operational requirements for compliance.

In effect, the Act defines what must be complied with, while the Rules outline how compliance is to be achieved. This distinction is well recognised in Indian regulatory practice and helps organisations translate legal principles into practical, implementable processes.

Penalties, Governance, and Professional Implications

The DPDP Act provides for significant monetary penalties in cases of non-compliance, particularly for failures relating to data security safeguards and personal data breaches. These penalties underscore the seriousness with which data protection obligations are viewed under the law.

However, for organisations, reputational impact and stakeholder trust often present greater risk than financial penalties alone. A data protection failure can affect customer confidence, business relationships, and regulatory standing.

From a governance perspective, the Act has direct implications for:

• Internal control assessment
• Risk management frameworks.
• Vendor and outsourcing oversight
• Board and audit committee reporting.

Organisations are increasingly expected to treat data protection as a board-level governance issue rather than an isolated compliance function.

Conclusion

The Digital Personal Data Protection Act, 2023 represents a significant step towards accountable and responsible data governance in India. For organisations and professionals alike, the Act reinforces the importance of trust, transparency, and sound governance in a digital economy.

An interpretative understanding of the Act—supplemented by awareness of the evolving Rules introduced in 2025—is essential for effective implementation. Viewed holistically, DPDP compliance should be regarded not merely as a legal requirement, but as an integral component of good corporate governance and sustainable business practice.

References

Draft-Digital-Personal-Data-Protection-Rules,2025(English).pdf

Digital-Personal-Data-Protection-Rules-2025.pdf

DPDP Rules 2025: India Notifies Digital Privacy Law

Artificial Intelligence is no longer experimental or limited to tech teams. Today, it influences how businesses make decisions, interact with customers, automate operations, and extract insights from data. As AI becomes part of everyday business workflows, one question keeps coming up: how do we make sure AI is used responsibly?

This is where governance becomes essential. Without clear guardrails, AI systems can quietly introduce bias, make decisions that are hard to explain, or expose organizations to compliance and reputational risks.

To address this growing need, ISO/IEC 42001:2023 introduces a dedicated management system for Artificial Intelligence. Instead of focusing only on technology, the standard looks at how AI should be governed—covering people, processes, and oversight—so that AI systems remain ethical, safe, and transparent throughout their lifecycle.

More importantly, ISO/IEC 42001 provides a common language for AI governance. It helps organizations move from ad-hoc controls to a structured and auditable approach, where accountability and trust are built into AI operations from the start.

What is ISO/IEC 42001:2023?

ISO/IEC 42001:2023 is the first international standard created specifically to help organizations manage AI systems through an AI Management System (AIMS). It applies whether an organization is building AI models in-house, using third-party AI tools, or relying on AI features embedded in enterprise software.

Rather than prescribing how to build AI, the standard focuses on how AI should be governed across its lifecycle—from design and deployment to monitoring and improvement.

Key areas covered by the standard include:

• Reducing bias and promoting fairness in AI outcomes

• Improving transparency and explainability of automated decisions

• Ensuring data quality and reliability

• Managing safety, security, and system resilience

• Addressing privacy and data protection concerns

• Defining human oversight and accountability

• Continuously monitoring AI performance and risks

Because of this broad scope, ISO/IEC 42001 is relevant to organizations of all sizes and across industries.

Why AI Governance Matters Today

As AI adoption increases, so do the risks that come with it. When AI systems are not properly governed, organizations may face challenges such as:

• Biased or unfair decisions that impact customers or employees.

• Black-box models that no one can fully explain.

• Privacy breaches or misuse of sensitive data

• Gaps between AI usage and regulatory expectations

• Operational failures caused by unstable or poorly monitored models.

• Loss of trust among users, regulators, and stakeholders

AI governance is no longer just a technical concern—it is a business and leadership responsibility. ISO/IEC 42001:2023 helps organizations address these issues by setting clear expectations for how AI should be managed responsibly.

Preparing for ISO/IEC 42001: Key Steps for Organizations

Organizations looking to align with ISO/IEC 42001 do not need to start from scratch. The journey typically begins with a few practical and achievable steps.

1. Identify and Classify AI Systems

Start by listing all AI applications used across the organization, including internal tools, vendor solutions, and embedded AI features.

Once identified, classify them based on their purpose, business impact, and potential risk.

2. Assess Risks and Impacts

For each AI use case, evaluate risks such as bias, lack of explainability, data privacy concerns, and operational dependency.

This helps determine where stronger controls or human oversight may be needed.

3. Define Ownership and Accountability

Clearly assign responsibility for AI systems, covering areas such as development, approval, monitoring, and escalation.

This ensures AI decisions are not “ownerless” and can be challenged or reviewed when needed.

4. Establish AI Policies and Guidelines

Develop or refine policies that define acceptable AI use, data handling practices, and ethical expectations.

These policies should align with ISO/IEC 42001 and integrate with existing governance frameworks.

5. Monitor, Review, and Improve

Set up ongoing monitoring to track AI performance, risks, and unintended outcomes over time.

Regular reviews help ensure AI systems continue to behave as expected as data, models, and contexts change.

6. Build Awareness Across Teams

Train employees involved in AI development, deployment, and decision-making on responsible AI practices.

Creating awareness ensures governance is not limited to compliance teams but shared across the organization.

Conclusion

AI has the potential to deliver enormous value, but only when it is deployed with care and accountability. ISO/IEC 42001:2023 offers a practical framework for organizations that want to move beyond informal controls and adopt a structured approach to trustworthy AI.

By following the principles of this standard, organizations can improve transparency, reduce AI-related risks, and show regulators, customers, and partners that they take responsible AI seriously. In an era where trust matters as much as innovation, strong AI governance is becoming a true competitive advantage.

Reference Links

• ISO/IEC 42001:2023 standard
• https://www.iso.org/obp/ui/en/#iso:std:iso-iec:42001:ed-1:v1:en
• https://www.a-lign.com/articles/understanding-iso-42001

IBM Security X-Force Threat Researchers have discovered a new variant of the RansomExx ransomware that has been rewritten in the Rust programming language, joining a growing trend of ransomware developers switching to the language.

Malware written in Rust often benefits from lower AV detection rates (compared to those written in more common languages) and this may have been the primary reason to use the language. For example, the sample analyzed in this report was not detected as malicious in the VirusTotal platform for at least 2 weeks after its initial submission. As of the time of writing, the new sample is still only detected by 14 out of the 60+ AV providers represented in the platform.

RansomExx is operated by the DefrayX threat actor group (Hive0091), which is also known for the PyXie malware, Vatet loader, and Defray ransomware strains. The newly discovered ransomware version is named RansomExx2 according to strings found within the ransomware and is designed to run on the Linux operating system. The group has historically released both Linux and Windows versions of their ransomware, so it is likely that a Windows version is also in the works.

RansomExx2 has been completely rewritten using Rust, but otherwise, its functionality is similar to its C++ predecessor. It requires a list of target directories to encrypt to be passed as command line parameters and then encrypts files using AES-256, with RSA used to protect the encryption keys.

The Rust programming language has been steadily increasing in popularity among malware developers over the course of the past year, thanks to its cross-platform support and low AV detection rates. Like the Go programming language, which has experienced a similar surge in usage by threat actors over the past few years, Rust’s compilation process also results in more complex binaries that can be more time-consuming to analyse for reverse engineers.

Several ransomware developers have released Rust versions of their malware including BlackCat, Hive, and Zeon, with RansomExx2 being the most recent addition. X-Force has also analysed an ITG23 crypter written in Rust, along with the CargoBay family of backdoors and downloaders.

Analysis

The newly identified RansomExx2 sample has MD5 hash 377C6292E0852AFEB4BD22CA78000685 and is a Linux executable written in the Rust programming language.

Notable source code path strings within the binary indicate that the ransomware is a variant of RansomExx and likely named RansomExx2.

/mnt/z/coding/aproject/ransomexx2/ransomexx/src/parallel_iter.rs ransomexx/src/ciphers/aes256_impl.rs ransomexx/src/footer.rs ransomexx/src/logic.rs ransomexx/src/ransom_data.rs

The website operated by the ransomware group has also been updated with the page title now listed as ‘ransomexx2’.

Figure 1 — A screenshot of the ransomware group’s website showing the page title configured as ‘ransomexx2’

Overall, the functionality of this ransomware variant is very similar to previous RansomExx Linux variants.

The ransomware expects to receive a list of directory paths to encrypt as input. If no arguments are passed to it, then it does not encrypt anything. The following command line format is required by the ransomware in order to execute correctly.

<ransomexx2_sample> –do <target_path_to_encrypt> [<additional_paths_to_encrypt> (optional)]

Upon execution, the ransomware iterates through the specified directories, enumerating and encrypting files. All files greater than or equal to 40 bytes are encrypted, with the exception of the ransom notes and any previously encrypted files.

Each encrypted file is given a new file extension. It is common for RansomExx ransomware file extensions to be based on a variation of the target company name, sometimes followed by the numbers such as ‘911’ or random characters.

A ransom note is dropped in each directory where file encryption occurs. The ransom note is named:

!_WHY_FILES_ARE_ENCRYPTED_!.txt

The contents of this note are as follows:

Hello! First of all it is just a business and the only thing we are interested in is money. All your data was encrypted. Please don’t try to modify or rename any of encrypted files, because it can result in serious data loss and decryption failure. Here is your personal link with full information regarding this accident (use Tor browser): http://rnsm777cdsjrsdlbs4v5qoeppu3px6sb2igmh53jzrx7ipcrbjz5b2ad.onion/<victim_id>/

Files are encrypted using AES-256 and a randomly generated key. The AES key is itself encrypted using RSA and a hardcoded public key, and appended to the end of the encrypted file. As a result of this encryption method, the corresponding RSA private key, held by the attacker, would be required to decrypt the files.

The following RSA public key was used in the analysed sample:

—–BEGIN PUBLIC KEY—– MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAnU8bw0DQKJjkX1QWFUM8 o52NWkUNz4zvrGRJEwhGpJZ99ho0A/BqG5kK7X9pq3GOICD3+6g928JBo6d/3cNM Ql5lS0LaZN3bxgiNPCWFEnYjLAagRMmi8unfZmGLjc3DDKT62Q0hrI86s1zB3ZhX 6biNhXmwMaKEenpuqRBzGDqmIP9Uc9jK75SqF9T7nK1L9j+nKhYqWpeRDjDuvYPY XHdstU0TN/OmKvPosiQaIrcIs2MNQXP7rLtMbr9knJucwLymCkF+IpMky/NTKt3u DR+OJZZMSbmWCBATmz7P9E9Vp8jwrLzhMzEgs0G8yeseMQ2ZpZEm+MKabqkro74M xldocxoK2AL51ZE8c5TLYGOYbG2PAsdk/rlyRDk1diI07mCw/R4RlPcJRFDJO1eF b1A8yp6pQjD7rg+Y38b0Z8AZzmf3aKj2B8sHOtKoNR8hKJQRtWhqKAgpQtsJY81/ 2SaMLdU7yOqY34QWrGwiRei1WoJKzeyMvJjzmbTbYQYePxlbWeoV/fJ0P0IboYPH iZ+WzXGG5Cxf7+zfZiCrbZuMqgCZdqc6ntQRcZqvw66a2Pxx4dO8AmGmxIJNzDnK lA6CHTwDeH7BgzYDD3IJxA7ofAAzqpw8H2eyRxsqLKTI2SAnmFqk85xpxWptmhOS BshihPaOu5a2ZXaPDeg6Lw8CAwEAAQ== —–END PUBLIC KEY—–

Elements such as RSA key, file extension, and the ransomware note name and contents, are encrypted within the binary and decrypted by xoring the encrypted data with an equal-sized key.
Conclusion
X-Force assesses it is highly likely that more threat actors will experiment with Rust going forward. RansomExx is yet another major ransomware family to switch to Rust in 2022 (following similar efforts with Hive and Blackcat). While these latest changes by RansomExx may not represent a significant upgrade in functionality, the switch to Rust suggests a continued focus on the development and innovation of the ransomware by the group, and continued attempts to evade detection.

Researchers spotted a new evasive malware, tracked as KmsdBot, that infects systems via an SSH connection that uses weak credentials.

Akamai Security Research discovered a new evasive Golang-based malware, tracked as KmsdBot, that infects systems via an SSH connection that uses weak login credentials.

The malware was employed in cryptocurrency mining campaigns and to launch denial-of-service (DDoS) attacks. KmsdBot supports multiple architectures, including Winx86, Arm64, and mips64, x86_64, and does not stay persistent to avoid detection.

The malicious code was used in attacks targeting multiple sectors including the gaming industry, technology industry, and luxury car manufacturers. The first DDoS attack observed by Akamai targeted a gaming company named FiveM, which allows gamers to host custom private servers for Grand Theft Auto Online. The malware employed specific targeted attacks along with generic Layer 4 and Layer 7 attacks.

“we found an interesting log entry: A cryptominer with distributed denial-of-service (DDoS) functionality tailored to the gaming industry. It’s not often we see these types of botnets actively attacking and spreading, especially ones written in Golang.” reads the post published by Akamai. “The targets range from gaming companies to luxury car brands to security companies — this malware is almost erratic with regard to its targets.”

The analysis of the ksmdx sample reveals functions to perform scanning operations, software updates and crypto mining activities.

Once a system has been infected, the ksmdx binary notifies the C2 that by sending it an HTTP POST request with the notification of ‘Bruh Started:’.

The bot downloads a list of login credentials to use when it scans for open SSH ports.

When analyzing the cryptomining activity, the experts noticed that operators used crypto wallets allegedly chosen randomly to contribute to various mining pools.

The bot does implement its own functionality to launch cryptomining activity, however, it is actually launching a renamed xmrig binary.

“This botnet is a great example of the complexity of security and how much it evolves. What seems to have started as a bot for a game app has pivoted into attacking large luxury brands. What’s new is how it infects — via an SSH connection that uses weak login credentials.” concludes the report. “The good news is that the same techniques we recommend to keep most organizations’ systems and networks secure still apply here.

• Don’t use weak or default credentials for servers or deployed applications.
• Ensure you’re keeping those deployed applications up-to-date with the latest security patches, and check in on them from time to time.
• Use public key authentication for your SSH connections. This is the best way to prevent this type of system compromise.”

A one-stop shop for data and crypto kleptomaniacs

Malware that steals passwords, cookies, and payment card data from web browsers is being sold via a Telegram channel and a Tor website, security researchers have discovered.

Collectively named the ‘Eternity Project’ by its architects, the suite of malware already includes stealers, clippers, worms, miners, and ransomware, with a Distributed Denial of Service (DDoS) bot apparently under development.

A Telegram channel provides information about forthcoming software updates and videos documenting the malware’s functionality to around 500 subscribers.

“Interestingly, individuals who purchase the malware can utilize the Telegram Bot to build the binary,” according to a blog post by Cyble Research Labs.

“The TAs [threat actors] provide an option in the Telegram channel to customize the binary features, which provides an effective way to build binaries without any dependencies.”

Versatile

A Stealer module, which costs $260 for an annual subscription, also exfiltrates AutoFill data, tokens, history, and bookmarks from Chrome, Chromium, Firefox, Edge, Opera, and more than 20 other browsers.

Other data extracted from infected machine to the threat actor’s Telegram bot are various system credentials, and cryptocurrency via a wide range of crypto-wallets and browser cryptocurrency extensions.

Eternity ransomware, meanwhile, can encrypt documents, photos, and databases on disks, local shares, and USB drives on compromised machines.

The ransomware facility – the most expensive option at $490 – offers offline encryption, an encryption algorithm combining AES and RSA, and the option to set a time limit after which files cannot be decrypted.

The Eternity worm, priced at $390, propagates through infected machines via local files and local network shares; Google Drive, OneDrive, and DropBox; and Discord, Telegram, and Python Interpreter.

For $110, budding cybercrooks can harness clipper malware that supports multiple address formats for BTC, LTC, ZEC, and BCH, while a $90-a-year cryptocurrency mining module offers silent Monero mining and automatic restarts.

Cybercrime increase

Researchers suspect the developer behind the Eternity Project is repurposing code in the ‘DynamicStealer’ GitHub repository, and have identified possible links with the threat actor behind the Jester Stealer malware Cyble documented in February.

Cyble Research Labs said it had recently “observed a significant increase in cybercrime through Telegram channels and cybercrime forums”.

Individuals and organizations are advised to protect themselves by installing reputable security software, enabling automatic software updates if practicable, regularly backing up data and keeping backups offline or on a separate network, and refraining from opening untrusted links and email attachments without verifying their authenticity.

Venezuelan cardiologist allegedly tied to cybercrime scams through multiple OpSec mistakes

A cardiologist turned alleged malware developer has been charged with creating the Thanos ransomware builder.

Moises Luis Zagala Gonzalez, 55, a citizen of France and Venezuela who resides in Ciudad Bolivar, Venezuela, engaged in attempted computer intrusions and conspiracy to commit computer intrusions, according to a US criminal complaint that was unsealed on Monday (May 16).

Zagala is alleged to have both sold and leased ransomware packages he developed to cybercriminals.

He is also accused of training would-be attackers on how to use his wares to extort victims, and subsequentially boasted about successful attacks, according to US prosecutors.

RaaS platform

The self-taught part-time programmer allegedly designed several ransomware tools, malicious packages designed to encrypt files on a compromised systems before demanding extortionate payments in exchange for a decryption key.

Zagala developed a ransomware tool called ‘Jigsaw v.2’ before designing a more sophisticated private ransomware builder called Thanos, a reference to either the Marvel supervillain or the figure ‘Thanatos’ from Greek mythology, according to the DoJ.

The Thanos platform could be used to develop ransomware campaigns with custom ransom notes, features designed to frustrate security researchers and a “data stealer” facility that could be used to extract files from compromised systems.

Zagala allegedly profited from the ransomware-as-a-service (Raas) operation by licensing his software to other cybercriminals, obtaining payments in either cryptocurrency or fiat currencies.

The ransomware products and services allegedly offered by Zagala were advertised and marketed through online forums frequented by cybercriminals.

OpSec mistakes

A number of OpSec mistakes allowed investigators to identify Zagala as a suspect, the DoJ said.

In September 2020, an undercover FBI agent allegedly purchased a license for Thanos from Zagala and downloaded the software. In addition, an FBI informant spoke with Zagala about the possibility of establishing an affiliate program using Thanos, according to the DoJ filing.

In addition, Zagala is said to have publicly boasted about how an Iranian state-sponsored hacking group’s use of Thanos to attack Israeli companies.

The Thanos software was designed to make periodic contact with a server in Charlotte, North Carolina, to check on licences. This system was apparently linked back to Zagala.

Moreover, a Florida-based relative of Zagala was interviewed by law enforcement on May 3, 2022, and admitted that their PayPal account was used by Zagala to receive illicit funds.

According to the DoJ, the relative used an email address to contact Zagala that matched the registered email for malicious infrastructure associated with the Thanos malware.

Prosecutors do not state how much Zagala made from his alleged malfeasance, but if convicted the suspect faces up to five years’ imprisonment for attempted computer intrusion, and five years’ imprisonment for conspiracy to commit computer intrusions.

ZombieLoad 2, aka TSX Asynchronous Abort, is a new flaw that affects the latest Intel CPUs that could be exploited to launch TSX Speculative attack.

ZombieLoad 2, aka TSX Asynchronous Abort, is a new vulnerability tracked as CVE-2019-11135 that affects the latest Intel CPUs that could be exploited to launch TSX Speculative attack.

The flaw affects the Transactional Synchronization Extensions (TSX) feature in Intel processors, it could be exploited by a local attacker or malicious code to steal sensitive data from the underlying operating system kernel.

The ZombieLoad 2 attack also targets the speculative execution implemented in modern CPU to improve performance.

In the past months, security researchers devised several speculative -channel RIDL (Rogue In-Flight Data Load), Fallout, Microarchitectural Data Sampling (MDS attack), and ZombieLoad.

Unlike Meltdown, Spectre, and Foreshadow attacks, MDS attakes target CPU’s microarchitectural data structures.

News of the day is that a new version of the ZombieLoad attack was devised by researchers, it also impacts processors in the Intel Cascade Lake CPU family that are not impacted by other attacks.

The Zombieload 2 attack only affects CPU supporting the Intel TSX instruction-set extension, a condition that is true in all Intel CPUs manufactured since 2013.

The TSX feature allows improving performance by leveraging a hardware transactional memory, any operation on this memory doesn’t impact on the overall performance of the systems.

“The TSX Asynchronous Abort (TAA) vulnerability is similar to Microarchitectural Data Sampling (MDS) and affects the same buffers (store buffer, fill buffer, load port writeback data bus).” reads the security advisory published by Intel.

“Intel TSX supports atomic memory transactions that are either committed or aborted. When an Intel TSX memory transaction is aborted, either synchronously or asynchronously, all earlier memory writes inside the transaction are rolled back to the state before the transaction start. While an Intel TSX asynchronous abort (TAA) is pending, certain loads inside the transaction that are not yet completed may read data from microarchitectural structures and speculatively pass that data to dependent operations. This may cause microarchitectural side effects, which can later be measured to infer the value of the data in the microarchitectural structures.”

Experts discovered that aborting memory transactions may allow processes to compute the data found in other running processes, including operating system kernel data. An attacker could exploit the flaw to steal sensitive data, including passwords and encryption keys.

Google this week made it easier for Android users to enable strong 2-factor authentication (2FA) when logging into Google’s various services. The company announced that all phones running Android 7.0 and higher can now be used as Security Keys, an additional authentication layer that helps thwart phishing sites and password theft.

As first disclosed by KrebsOnSecurity last summer, Google maintains it has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017, when it began requiring all employees to use physical Security Keys in place of passwords and one-time codes.

The most commonly used Security Keys are inexpensive USB-based devices that offer an alternative approach to 2FA, which requires the user to log in to a Web site using something they know (the password) and something they have (e.g. a one-time token, key fob or mobile device).

But Google said starting this week, any mobile phone running Android 7.0+ (Nougat) can serve the same function as a USB-based security key. Once a user has enrolled their Android phone as a Security Key, the user will need to approve logins via a prompt sent to their phone after submitting their username and password at a Google login page.

Many readers have expressed confusion or skepticism about how Security Keys can prevent users from getting hooked by phishing sites or clever man-in-the-middle attacks. This capability was described in far greater visual detail in this video last year by Christiaan Brand, product manager at Google Cloud.

But the short version is that even if a user who has enrolled a Security Key for authentication tries to log in at a site pretending to be Google, the company’s systems simply refuse to request the Security Key if the user isn’t on an official Google site, and the login attempt fails.

“It puts you in this mode….[in] which is there is no other way to log in apart from the Security Key,” Brand said. “No one can trick you into a downgrade attack, no one can trick you into anything different. You need to provide a security key or you don’t get into your account.”

Google says built-in security keys are available on phones running Android 7.0+ (Nougat) with Google Play Services, enabling existing phones to act as users’ primary 2FA method for work (G Suite, Cloud Identity, and GCP) and personal Google accounts to sign in on a Bluetooth-enabled Chrome OS, macOS X, or Windows 10 device with a Chrome browser.

The basic idea behind two-factor authentication (Google calls it “two step verification” or 2SV) is that even if thieves manage to phish or steal your password, they still cannot log in to your account unless they also hack or possess that second factor.

The most common forms of 2FA require the user to supplement a password with a one-time code sent to their mobile device via an app (like Authy or Google Authenticator), text message, or an automated phone call. But all of these methods are susceptible to interception by various attacks.

For example, thieves can intercept that one-time code by tricking your mobile provider into either swapping your mobile device’s SIM card or “porting” your mobile number to a different device.

A Security Key implements a form of multi-factor authentication known as Universal 2nd Factor (U2F), which allows the user to complete the login process simply by inserting the USB device and pressing a button on the device. The key works without the need for any special software drivers.

Probably the most popular maker of Security Keys is Yubico, which sells a basic U2F key for $20 (it offers regular USB versions as well as those made for devices that require USB-C connections, such as Apple’s newer Mac OS systems). Yubikey also sells more expensive U2F keys designed to work with mobile devices.

A number of high-profile sites now allow users to enroll their accounts with USB- or Bluetooth-based Security Keys, including Dropbox, Facebook, Github and Twitter. If you decide to use Security Keys with your account, it’s a good idea to register a backup key and keep it in a safe place, so you can still get into your account if you loose your initial key (or phone, in Google’s case).

To be sure you’re using the most robust forms of authentication at sites you entrust with sensitive data, spend a few minutes reviewing the options at twofactorauth.org, which maintains probably the most comprehensive list of which sites support 2FA, indexing each by type of site (email, gaming, finance, etc) and the type of 2FA offered (SMS, phone call, software token, etc.).

Please bear in mind that if the only 2FA options offered by a site you frequent are SMS and/or phone calls, this is still better than simply relying on a password to secure your account.

Google says Android 7.0+ phones also can be used as the Security Key for people who have adopted the company’s super-paranoid Advanced Protection option. This is a far more stringent authentication process for Google properties designed specifically for users who are most likely to be targeted by sophisticated attacks, such as journalists, activists, business leaders and political campaigns.