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

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

 

Articles

NIST defines “critical software” with a broad range of…

The goal is to enable stronger security practices for government-purchased software mandated by President Biden’s cybersecurity executive order.

A significant part of the Biden administration’s wide-ranging cybersecurity executive order (EO) mandates that the National Institute of Standards and Technology (NIST) define what constitutes “critical software,” a deliverable that is central to the wider effort of securing software supply chains. Last week NIST made good on this assignment when it released a preliminary list of software categories within the scope of this definition.

The EO stipulates that NIST’s definition “shall reflect the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.” Thus, the goal of the definition is to drive several additional activities required under the EO to shape how the federal government purchases and manages deployed critical software.

One driving principle behind the critical software definition is that when combined with other aspects of the EO, software acquisition by the federal government would tilt over time toward only those products that have met reasonable security measures. The hope is that the federal government’s “power of the purse” would spill over to the private sector because most major software suppliers sell to both public and private sector customers and would find it more efficient to create a single secure product for both sectors.

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

 

Articles

The cybersecurity legislation agenda: 5 areas to watch

lead centered=”no”The 116th Congress is only a few months old, but far-reaching cybersecurity bills to protect infrastructure and the supply chain, ensure election integrity, and build a security workforce are now being considered. Here’s the list. /lead

New digital threats that could topple business, government, military and political institutions is moving cybersecurity to the top of the congressional agenda. The newly seated 116th Congress has so far seen 30 bills introduced in the House of Representatives and seven bills introduced in the Senate that directly deal with cybersecurity issues. That does not include other pieces of legislation that have at least some provisions that deal with information and digital security.

A key problem in grappling with such a complex issue as cybersecurity in Congress — and in Washington in general — is the diffused responsibility spawned by the wide-ranging, interconnected nature of the topic. Representative Jim Langevin (D-RI), a member of the Armed Services and Homeland Security Committees, and one of the founders of the Congressional Cybersecurity Caucus, flagged this stumbling block at the 2019 State of the Net conference in January by calling for consolidation in Congress over cybersecurity.

Noting that around 80 groups within the legislative branch claim some jurisdiction over cybersecurity matters, Langevin said, “We as a Congress are going to have to move with greater agility to respond to the cybersecurity threats we face going forward, and we can’t do it under the current construct.” Langevin wants the House Homeland Security issue to take the lead on all matters related to cybersecurity.

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

Articles

Who is responsible for IoT security in healthcare?

lead centered=”no”NIST panel debates who should own IoT security: vendors or users. The issue is especially important when it comes to protecting medical devices./lead

The next big challenge in cybersecurity will undoubtedly be to secure the billion-plus (and growing) internet-of-things (IoT) devices around the globe, which exponentially expand the attack vector across the increasingly interconnected IT sector. Based on statistics from Symantec, attacks that leverage internet-connected cameras, appliances, cars, and medical devices to launch attacks or infiltrate networks soared by 600 percent from 2016 to 2017.

“It was a big year for cyberattacks,” Ken Durbin, senior strategist for global government affairs at Symantec, said speaking on a panel at NIST’s Cybersecurity Risk Management Conference. Much of that panel’s discussion focused on who should own IoT security. The nature of IoT risk makes that a hard question to answer.

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

Articles

With supply chain security grabbing headlines, NIST sees new…

lead centered=”no”Supply chain is sexy again, and NIST hopes that means more companies take its supply chain risk guidance seriously./lead

Cybersecurity in the supply chain is a dense, massively complicated topic that lies beyond the comprehension of all but a few dedicated experts. It has nonetheless risen to the top of security challenges organizations face today. “Supply chain is the new black. Supply chain is sexy again. That’s kind of hard to imagine,” said Jon Boyens, manager, security engineering and risk management at the National Institute of Standards and Technology (NIST). Boyens, who manages cybersecurity supply chain efforts at the National Institute of Standards and Technology (NIST), made that comment during a plenary session at NIST’s Cybersecurity Risk Management Conference.

NIST’s long history with supply chain risk

NIST is an old hand at supply chain outside the cybersecurity realm, starting decades ago when it began developing guidance for managing risk in global industrial and defense supply chains. “Supply chain is the most mature in its gestation because we’ve had all sorts of permutations along the way. This is an old topic for defense organizations,” says Matt Barrett, NIST’s Cybersecurity Framework lead.

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

Articles

Why NIST’s privacy framework could help security efforts

lead centered=”no”Although many people, even some cybersecurity practitioners, tend to conflate data security and data privacy as one and the same, privacy experts see them as two different, often contradictory, yet frequently overlapping objectives./lead

Although many people, even some cybersecurity practitioners, tend to conflate data security and data privacy as one and the same, privacy experts see them as two different, often contradictory, yet frequently overlapping objectives.

“We look at it as a Venn diagram,” Naomi Lefkovitz, privacy engineering program head at the National Institute of Standards and Technology (NIST), said during a plenary session here at NIST’s Cybersecurity Risk Management conference.

Lefkovitz is spearheading NIST’s initiative to create a Privacy Framework, along the lines of NIST’s successful Cybersecurity Framework, which could help pave the way toward the development of trustworthy information systems that protect privacy. From the Venn diagram perspective, the protection of individual privacy cannot be achieved by merely securing personally identifiable information (PII) because security risks arise from unauthorized system behavior while privacy risks arise as a byproduct of authorized PII. The area where security concerns overlap privacy concerns is the only area where true PII privacy currently occurs.

(This article appeared in Cyberscoop. Please read the rest of the article here.)