Articles

US cryptocurrency exchange sanctions over ransomware likely not the…

The sanctions against Suex, aimed to cut ransomware gangs off from their revenue, sends a signal to other exchanges that support criminal activity.

Days after the Russia-linked BlackMatter ransomware gang hit an Iowa grain cooperative with a ransomware attack, the Biden administration unveiled its latest effort to address the ongoing ransomware crisis. In a move designed to cut off ransomware gangs from their financial rewards, the Treasury Department announced that its Office of Foreign Asset Control (OFAC) placed Czech Republic-registered but Russian national-owned and -operated cryptocurrency exchange Suex on its sanctioned entity list, formally called the Specially Designated Nationals and Blocked Persons (SDN) List.

Suex facilitates “financial transactions for ransomware actors, involving illicit proceeds from at least eight ransomware variants,” according to the announcement. Treasury says that over 40% of Suex’s known transaction history is associated with illicit actors, representing $370 million in illicit trading.

OFAC included on the SDN list a total of 25 bitcoin, ethereum, and tether addresses known to be controlled by Suex. These addresses received more than $934 million in various crypto assets overall. In addition, blockchain transactions tracking company Chainanalysis said that the Suex addresses have received more than $160 million in bitcoin alone from “ransomware actors, scammers, and dark net market operators” since the exchange was founded in 2018.

This article appeared in CSO Online. To read the rest of the article please visit here.

Photo by Jon Tyson on Unsplash

Articles

Software cybersecurity labels face practical, cost challenges

The federal government wants consumer software to have cybersecurity labels; experts question the feasibility of the mandate.

As part of his extensive cybersecurity executive order issued in May, President Biden directed the National Institute of Standards and Technology (NIST) to develop two pilot labeling programs on the cybersecurity capabilities of internet-of-things (IoT) consumer devices and software development practices. Although these pilot programs won’t be mandatory for device or software sellers, they could likely raise market expectations. In addition, whatever labels come out of these programs would also carry with them some sense of government authority and might ultimately become part of the government contracting process.

Last week NIST held a two-day workshop on these topics. Of the two pilot programs, the consumer software labeling initiative is the trickier one given the ever-changing nature of software and the absence of any similar existing consumer software labeling initiative.

To help it grasp the more complex task of developing labels for software, NIST solicited one- to two-page labeling position papers from interested parties. In calling for these papers, NIST cited “the challenges and practical approaches to consumer software labeling,” asking` for feedback on the “technical criteria needed to support validation of consumer software security assertions that reflect a baseline level of secure practices.”

This article appeared in CSO Online. To read the rest of the article please visit here.

Photo by Jon Tyson on Unsplash

Articles

Federal agencies face new zero-trust cybersecurity requirements

The OMB and CISA issue guidance to move all federal agencies to a shared zero-trust maturity model for FY22-24. The catch: No new funding.

As part of the Biden administration’s wide-ranging cybersecurity executive order (EO) issued in May, the Office of Management and Budget (OMB) and the Cybersecurity and Infrastructure Security Agency (CISA) issued three documents on zero trust last week. Zero trust is a security concept that “eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses,” according to the EO.

From a cybersecurity practitioner’s perspective, zero trust is a security approach that, among other things, relies on stringent authentication and authorization processes to give users needed access to digital assets but in constrained ways that limit damage when a breach or compromise occurs. The EO repeatedly references zero trust and directs CISA and OMB to develop initiatives to incorporate zero-trust cybersecurity security models throughout the federal government.

The documents released last week offer draft versions of these models. CISA and OMB call them “strategic and technical guidance documents meant to move the US government towards a zero-trust architecture.”

This article appeared in CSO Online. To read the rest of the article please visit here.

Photo by Laura Heimann on Unsplash

Articles

Federal agencies face new zero-trust cybersecurity requirements

The OMB and CISA issue guidance to move all federal agencies to a shared zero-trust maturity model for FY22-24. The catch: No new funding.

As part of the Biden administration’s wide-ranging cybersecurity executive order (EO) issued in May, the Office of Management and Budget (OMB) and the Cybersecurity and Infrastructure Security Agency (CISA) issued three documents on zero trust last week. Zero trust is a security concept that “eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses,” according to the EO.

From a cybersecurity practitioner’s perspective, zero trust is a security approach that, among other things, relies on stringent authentication and authorization processes to give users needed access to digital assets but in constrained ways that limit damage when a breach or compromise occurs. The EO repeatedly references zero trust and directs CISA and OMB to develop initiatives to incorporate zero-trust cybersecurity security models throughout the federal government.

The documents released last week offer draft versions of these models. CISA and OMB call them “strategic and technical guidance documents meant to move the US government towards a zero-trust architecture.”

This article appeared in CSO Online. To read the rest of the article please visit here.

Photo by Laura Heimann on Unsplash

Articles

NIST’s EO-mandated software security guidelines could be a game-changer

While experts applaud the new security guidance, it’s unclear whether software vendors will completely embrace and implement the needed security practices.

Following a string of high-profile supply chain hacks, President Biden’s wide-ranging executive order on cybersecurity (EO) issued on May 12 directed the National Institute of Standards and Technology (NIST) to produce guidance on a series of software security matters. First, the EO asked NIST to produce a definition of critical software, which it released at the end of June. Second, the EO directed NIST to publish guidance on security measures for EO-critical software use, which NIST released last Friday.

To tackle the complex issue of keeping software secure, NIST solicited papers from interested parties and held a two-day workshop to gain insight from industry and other experts.  NIST defined five objectives for the operational-only (not covering development and acquisition matters) security measures:

  1. Protect EO-critical software and EO-critical software platforms (the platforms on which EO-critical software runs, such as endpoints, servers, and cloud resources) from unauthorized access and usage. Measures here include use of multi-factor authentication, following privileged access management principles, and employing boundary protection techniques.
  2. Protect the confidentiality, integrity, and availability of data used by EO-critical software and EO-critical software platforms. Measures here include maintaining a data inventory, protecting data at rest and in transit, and back up data with a tested recovery plan.
  3. Identify and maintain EO-critical software platforms and the software deployed to those platforms to protect the EO-critical software from exploitation. Measures here include maintaining a software inventory, have a patch management plan, and use configuration management practices.
  4. Quickly detect, respond to, and recover from threats and incidents involving EO-critical software and EO-critical software platforms. Measures here include recording necessary logging information, continuous security monitoring, and using endpoint and network security protection.
  5. Strengthen the understanding and performance of humans’ actions that foster the security of EO-critical software and EO-critical software platforms. Measures here include training all users and administrators of EO-critical software and conducting frequent awareness activities.

This article appeared in CSO Online. To read the rest of the article please visit here.

Photo by Fotis Fotopoulos on Unsplash