Tag Archive for: Protecting

Protecting cryptocurrency assets in wake of the Solana Wallet hack

/in


The incident has brought up numerous concerns regarding the security provided by both the Solana network and “hot” wallets, which are fairly popular with the typical crypto investor, with cryptocurrency assets worth more than $8 million taken from about 8,000 people.

Cause of Solana attack unknown

While Solana’s Twitter account was quick to point out that the attack was not caused by a software compromise on the network, it also stated that its team of engineers was assiduously working with security researchers and ecosystem teams to determine the cause of this wallet attack.

According to preliminary investigations, hardware wallets used by Slope were safe from this issue because they only affected the Slope wallet on the Solana ecosystem.

According to Solana, impacted wallet addresses had their private key information sent to an application monitoring service at some point when they were generated, imported, or used in Slope mobile wallet programs.

Solana has already urged investors affected by the attack to abandon the affected wallets as they could still be compromised even after revoking wallet approvals. While the exact modus operandi employed is still unknown, crypto industry leaders have highlighted that the suspect transactions were properly signed, further indicating that it could be a supply chain attack with a specific focus on Slope ‘hot’ wallet users.

Applications, and devices can be hacked

Applications (software) and devices can be hacked. Since private keys are stored in application and device wallets, hackers can access them and steal your cryptocurrency and that sums up the Solana hack.

And if your wallet has been compromised, it’s paramount that you transfer any existing funds from your compromised wallet to another wallet.

Hackers will wipe your account of funds immediately, but if you’re lucky and they have not done this yet, it’s time for investors to take immediate action.

…

Source…

Protecting Against Kubernetes-Borne Ransomware

/in


Kubernetes and container technology in general had a good run as seemingly immune to malware, but that ended when Siloscape burst onto the scene in March 2021. It was the first known threat targeting Kubernetes environments to potentially do all kinds of nefarious things, including spread ransomware. In the ensuing 16 months, Siloscape has undoubtedly provided other cybercriminals with a blueprint for attacking container environments.

It’s worth reviewing the details of Siloscape. Threat researcher Daniel Prizmant, who discovered the malware, put it this way: “Siloscape is heavily obfuscated malware targeting Kubernetes clusters through Windows containers. Its main purpose is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.

“Compromising an entire cluster is much more severe than compromising an individual container, as a cluster could run multiple cloud applications whereas an individual container usually runs a single cloud application,” he continued. “For example, the attacker might be able to steal critical information such as usernames and passwords, an organization’s confidential and internal files or even entire databases hosted in the cluster. Such an attack could even be leveraged as a ransomware attack by taking the organization’s files hostage.”

A Distant Threat? No! 

It’s easy to fall into the trap of thinking this is some distant threat affecting an obscure technology few companies are deploying.

Au contraire. Prizmant himself pointed out that “with organizations moving to the cloud, many use Kubernetes clusters as their development and testing environments, and a breach of such an environment can lead to devastating software supply chain attacks.”

And recent research revealed one-third of organizations already rely on Kubernetes. Of the remaining two-thirds that do not yet use it, 86% expect to deploy the technology in the next two to three years.

Alarmingly, though, just 33% of organizations that have deployed Kubernetes so far have tools in place to protect their container environments against data loss incidents such as ransomware. That may be why it didn’t take long for Prizmant’s ransomware prediction to…

Source…

The PATCH Act: Protecting Medical Devices from Cyber Attacks | Spilman Thomas & Battle, PLLC

/in


INTRODUCTION
In a previous issue of Decoded, we discussed the alarming fact that many medical devices, including those implanted in patients’ bodies, are leaving the manufacturers with known cybersecurity flaws. Due to these known flaws, these devices are vulnerable to being hacked, and patients’ personal/protected health information (“PHI”) stolen; or worse, the device being held hostage in a ransomware attack. In hopes of preventing a medical disaster associated with unprotected medical devices, this year, the House and the Senate are considering companion bills intended to significantly improve security and safety for medical devices. Senate Bill 3983, the “Protecting and Transforming Cyber Health Care Act” or “PATCH Act,” and the House companion, the PATCH Act of 2022, H.R. 7084, are currently under consideration in their respective Committees. The PATCH Act represents a major step forward in securing networkable medical devices, but there are significant shortcomings in the way it addresses the ever-evolving threat of cybersecurity vulnerabilities in those medical devices.

A PROBLEMATIC DEFINITION OF “CYBER DEVICE”
At the outset, the PATCH Act must define what medical devices it intends to cover. Medical devices come in all shapes and sizes – from implanted devices such as a pacemaker or a child’s RFID tag, to robotic assisted surgical equipment such as the Da Vinci, or even MRI or X-Ray imaging machinery. These devices are known to be vulnerable to cyberattacks, with a wide range of medical impacts and risks to health and safety. With the PATCH Act, Congress is trying to address vulnerabilities of all of these devices under the simple umbrella of “cyber devices.”

The PATCH Act defines a “cyber device” as “a device that (A) includes software; or (B) is intended to connect to the internet.” This definition demonstrates the complexity of the issue, because it includes amorphous terms. What constitutes “software” in this context? Is software specific computer programing, or does it include passive RFID chip technology? Title 21 of the United States does not otherwise define “software” as a standalone term. Likewise, the phrase “intended…

Source…

Protecting Against Cyber Threats to Managed Service Providers and their Customers

/in


Tactical actions for MSPs and their customers to take today:
• Identify and disable accounts that are no longer in use.
• Enforce MFA on MSP accounts that access the customer environment and monitor for unexplained failed authentication.
• Ensure MSP-customer contracts transparently identify ownership of ICT security roles and responsibilities.

The cybersecurity authorities of the United Kingdom (NCSC-UK), Australia (ACSC), Canada (CCCS), New Zealand (NCSC-NZ), and the United States (CISA), (NSA), (FBI) are aware of recent reports that observe an increase in malicious cyber activity targeting managed service providers (MSPs) and expect this trend to continue.[1] This joint Cybersecurity Advisory (CSA) provides actions MSPs and their customers can take to reduce their risk of falling victim to a cyber intrusion. This advisory describes cybersecurity best practices for information and communications technology (ICT) services and functions, focusing on guidance that enables transparent discussions between MSPs and their customers on securing sensitive data. Organizations should implement these guidelines as appropriate to their unique environments, in accordance with their specific security needs, and in compliance with applicable regulations. MSP customers should verify that the contractual arrangements with their provider include cybersecurity measures in line with their particular security requirements.

The guidance provided in this advisory is specifically tailored for both MSPs and their customers and is the result of a collaborative effort from the United Kingdom National Cyber Security Centre (NCSC-UK), the Australian Cyber Security Centre (ACSC), the Canadian Centre for Cyber Security (CCCS), the New Zealand National Cyber Security Centre (NCSC-NZ), the United States’ Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), and Federal Bureau of Investigation (FBI) with contributions from industry members of the Joint Cyber Defense Collaborative (JCDC). Organizations should read this advisory in conjunction with NCSC-UK guidance on actions to take when the cyber threat is heightened, CCCS guidance on Cyber Security Considerations for Consumers of Managed Services, and CISA guidance provided on the Shields Up and Shields Up Technical Guidance webpages.

Managed Service Providers

This advisory defines MSPs as entities that deliver, operate, or manage ICT services and functions for their customers via a contractual arrangement, such as a service level agreement. In addition to offering their own services, an MSP may offer services in conjunction with those of other providers. Offerings may include platform, software, and IT infrastructure services; business process and support functions; and cybersecurity services. MSPs typically manage these services and functions in their customer’s network environment—either on the customer’s premises or hosted in the MSP’s data center. Note: this advisory does not address guidance on cloud service providers (CSPs)—providers who handle the ICT needs of their customers via cloud services such as Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service; however, MSPs may offer these services as well. (See Appendix for additional definitions.)

MSPs provide services that usually require both trusted network connectivity and privileged access to and from customer systems. Many organizations—ranging from large critical infrastructure organizations to small- and mid-sized businesses—use MSPs to manage ICT systems, store data, or support sensitive processes. Many organizations make use of MSPs to scale and support network environments and processes without expanding their internal staff or having to develop the capabilities internally. 

Threat Actors Targeting MSP Access to Customer Networks

Whether the customer’s network environment is on premises or externally hosted, threat actors can use a vulnerable MSP as an initial access vector to multiple victim networks, with globally cascading effects. The UK, Australian, Canadian, New Zealand, and U.S. cybersecurity authorities expect malicious cyber actors—including state-sponsored advanced persistent threat (APT) groups—to step up their targeting of MSPs in their efforts to exploit provider-customer network trust relationships. For example, threat actors successfully compromising an MSP could enable follow-on activity—such as ransomware and cyber espionage—against the MSP as well as across the MSP’s customer base.

The UK, Australian, Canadian, New Zealand, and U.S. cybersecurity authorities have previously issued general guidance for MSPs and their customers.[2],[3],[4],[5],[6],[7],[8] This advisory provides specific guidance to enable transparent, well-informed discussions between MSPs and their customers that center on securing sensitive information and data. These discussions should result in a re-evaluation of security processes and contractual commitments to accommodate customer risk tolerance. A shared commitment to security will reduce risk for both MSPs and their customers, as well as the global ICT community. 

Download the Joint Cybersecurity Advisory: Protecting Against Cyber Threats to Managed Service Providers and their Customers (pdf, 697kb).

Recommendations 

MSPs and their Customers

The UK, Australian, Canadian, New Zealand, and U.S. cybersecurity authorities recommend MSPs and their customers implement the baseline security measures and operational controls listed in this section. Additionally, customers should ensure their contractual arrangements specify that their MSP implements these measures and controls.

Prevent initial compromise. 

In their efforts to compromise MSPs, malicious cyber actors exploit vulnerable devices and internet-facing services, conduct brute force attacks, and use phishing techniques. MSPs and their customers should ensure they are mitigating these attack methods. Useful mitigation resources on initial compromise attack methods are listed below:

  • Improve security of vulnerable devices.
  • Protect internet-facing services.
  • Defend against brute force and password spraying.
  • Defend against phishing.

Enable/improve monitoring and logging processes. 

It can be months before incidents are detected, so UK, Australian, Canadian, New Zealand, and U.S. cybersecurity authorities recommend all organizations store their most important logs for at least six months. Whether through a comprehensive security information and event management (SIEM) solution or discrete logging tools, implement and maintain a segregated logging regime to detect threats to networks. Organizations can refer to the following NCSC-UK guidance on the appropriate data to collect for security purposes and when to use it: What exactly should we be logging? Additionally, all organizations—whether through contractual arrangements with an MSP or on their own—should implement endpoint detection and network defense monitoring capabilities in addition to using application allowlisting/denylisting. 

  • MSPs should log the delivery infrastructure activities used to provide services to the customer. MSPs should also log both internal and customer network activity, as appropriate and contractually agreed upon. 
  • Customers should enable effective monitoring and logging of their systems. If customers choose to engage an MSP to perform monitoring and logging, they should ensure that their contractual arrangements require their MSP to:
    • Implement comprehensive security event management that enables appropriate monitoring and logging of provider-managed customer systems; 
    • Provide visibility—as specified in the contractual arrangement—to customers of logging activities, including provider’s presence, activities, and connections to the customer networks (Note: customers should ensure that MSP accounts are properly monitored and audited.); and
    • Notify customer of confirmed or suspected security events and incidents occurring on the provider’s infrastructure and administrative networks, and send these to a security operations center (SOC) for analysis and triage. 

Enforce multifactor authentication (MFA). 

Organizations should secure remote access applications and enforce MFA where possible to harden the infrastructure that enables access to networks and systems.[9],[10] Note: Russian state-sponsored APT actors have recently demonstrated the ability to exploit default MFA protocols; organizations should review configuration policies to protect against “fail open” and re-enrollment scenarios.[11] 

  • MSPs should recommend the adoption of MFA across all customer services and products. Note: MSPs should also implement MFA on all accounts that have access to customer environments and should treat those accounts as privileged.
  • Customers should ensure that their contractual arrangements mandate the use of MFA on the services and products they receive. Contracts should also require MFA to be enforced on all MSP accounts used to access customer environments.

Manage internal architecture risks and segregate internal networks. 

Organizations should understand their environment and segregate their networks. Identify, group, and isolate critical business systems and apply appropriate network security controls to them to reduce the impact of a compromise across the organization.[12],[13]

  • MSPs should review and verify all connections between internal systems, customer systems, and other networks. Segregate customer data sets (and services, where applicable) from each other—as well as from internal company networks—to limit the impact of a single vector of attack. Do not reuse admin credentials across multiple customers. 
  • Customers should review and verify all connections between internal systems, MSP systems, and other networks. Ensure management of identity providers and trusts between the different environments. Use a dedicated virtual private network (VPN) or alternative secure access method, to connect to MSP infrastructure and limit all network traffic to and from the MSP to that dedicated secure connection. Verify that the networks used for trust relationships with MSPs are suitably segregated from the rest of their networks. Ensure contractual agreements specify that MSPs will not reuse admin credentials across multiple customers.

Apply the principle of least privilege. 

Organizations should apply the principle of least privilege throughout their network environment and immediate update privileges upon changes in administrative roles. Use a tiering model for administrative accounts so that these accounts do not have any unnecessary access or privileges. Only use accounts with full privileges across an enterprise when strictly necessary and consider the use of time-based privileges to further restrict their use. Identify high-risk devices, services and users to minimize their accesses.[14]

  • MSPs should apply this principle to both internal and customer environments, avoiding default administrative privileges. 
  • Customers should ensure that their MSP applies this principle to both provider and customer network environments. Note: customers with contractual arrangements that provide them with administration of MSP accounts within their environment should ensure that the MSP accounts only have access to the services/resources being managed by the MSP.

Deprecate obsolete accounts and infrastructure. 

Both MSPs and customers should periodically review their internet attack surface and take steps to limit it, such as disabling user accounts when personnel transition.[15] (Note: although sharing accounts is not recommended, should an organization require this, passwords to shared account should be reset when personnel transition.) Organizations should also audit their network infrastructure—paying particular attention to those on the MSP-customer boundary—to identify and disable unused systems and services. Port scanning tools and automated system inventories can assist organizations in confirming the roles and responsibilities of systems.

  • Customers should be sure to disable MSP accounts that are no longer managing infrastructure. Note: disabling MSP accounts can be overlooked when a contract terminates.

Apply updates. 

Organizations should update software, including operating systems, applications, and firmware. Prioritize applying security updates to software containing known exploited vulnerabilities. Note: organizations should prioritize patching vulnerabilities included in CISA’s catalogue of known exploited vulnerabilities (KEV) as opposed to only those with high Common Vulnerability Scoring System (CVSS) scores that have not been exploited and may never be exploited.[16],[17],[18],[19]

  • MSPs should implement updates on internal networks as quickly as possible.
  • Customers should ensure that they understand their MSP’s policy on software updates and request that comprehensive and timely updates are delivered as an ongoing service.

Backup systems and data. 

Organizations should regularly update and test backups—including “gold images” of critical systems in the event these need to be rebuilt (Note: organizations should base the frequency of backups on their recovery point objective [20]). Store backups separately and isolate them from network connections that could enable the spread of ransomware; many ransomware variants attempt to find and encrypt/delete accessible backups. Isolating backups enables restoration of systems/data to their previous state should they be encrypted with ransomware. Note: best practices include storing backups separately, such as on external media.[21],[22],[23] 

  • MSPs should regularly backup internal data as well as customer data (where contractually appropriate) and maintain offline backups encrypted with separate, offline encryption keys. Providers should encourage customers to create secure, offsite backups and exercise recovery capabilities.
  • Customers should ensure that their contractual arrangements include backup services that meet their resilience and disaster recovery requirements. Specifically, customers should require their MSP to implement a backup solution that automatically and continuously backs up critical data and system configurations and store backups in an easily retrievable location, e.g., a cloud-based solution or a location that is air-gapped from the organizational network.

Develop and exercise incident response and recovery plans. 

Incident response and recovery plans should include roles and responsibilities for all organizational stakeholders, including executives, technical leads, and procurement officers. Organizations should maintain up-to-date hard copies of plans to ensure responders can access them should the network be inaccessible (e.g., due to a ransomware attack).[24]

  • MSPs should develop and regularly exercise internal incident response and recovery plans and encourage customers to do the same.
  • Customers should ensure that their contractual arrangements include incident response and recovery plans that meet their resilience and disaster recovery requirements. Customers should ensure these plans are tested at regular intervals.

Understand and proactively manage supply chain risk. 

All organizations should proactively manage ICT supply chain risk across security, legal, and procurement groups, using risk assessments to identify and prioritize the allocation of resources.[25],[26]

  • MSPs should understand their own supply chain risk and manage the cascading risks it poses to customers.
  • Customers should understand the supply chain risk associated with their MSP, including risk associated with third-party vendors or subcontractors. Customers should also set clear network security expectations with their MSPs and understand the access their MSP has to their network and the data it houses. Each customer should ensure their contractual arrangements meet their specific security requirements and that their contract specifies whether the MSP or the customer owns specific responsibilities, such as hardening, detection, and incident response.[27]

Promote transparency. 

Both MSPs and their customers will benefit from contractual arrangements that clearly define responsibilities. 

  • MSPs, when negotiating the terms of a contract with their customer, should provide clear explanations of the services the customer is purchasing, services the customer is not purchasing, and all contingencies for incident response and recovery.
  • Customers should ensure that they have a thorough understanding of the security services their MSP is providing via the contractual arrangement and address any security requirements that fall outside the scope of the contract. Note: contracts should detail how and when MSPs notify the customer of an incident affecting the customer’s environment.

Manage account authentication and authorization. 

All organizations should adhere to best practices for password and permission management. [28],[29],[30] Organizations should review logs for unexplained failed authentication attempts—failed authentication attempts directly following an account password change could indicate that the account had been compromised. Note: network defenders can proactively search for such “intrusion canaries” by reviewing logs after performing password changes—using off-network communications to inform users of the changes—across all sensitive accounts. (See the ACSC publication, Windows Event Logging and Forwarding as well as Microsoft’s documentation, 4625(F): An account failed to log on, for additional guidance.) 

  • MSPs should verify that the customer restricts MSP account access to systems managed by the MSP.
  • Customers should ensure MSP accounts are not assigned to internal administrator groups; instead, restrict MSP accounts to systems managed by the MSP. Grant access and administrative permissions on a need-to-know basis, using the principle of least privilege. Verify, via audits, that MSP accounts are being used for appropriate purposes and activities, and that these accounts are disabled when not actively being used. 

Purpose

This advisory was developed by UK, Australian, Canadian, New Zealand, and U.S. cybersecurity authorities in furtherance their respective cybersecurity missions, including their responsibilities to develop and issue cybersecurity specifications and mitigations.

Acknowledgements

The UK, Australian, Canadian, New Zealand, and U.S. cybersecurity authorities would like to thank Secureworks for their contributions to this CSA.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. NCSC-UK, ACSC, CCCS, NCSC-NZ, CISA, NSA, and FBI do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favouring.

Source…