Tag Archives: cybersecurity

Backdoor in XZ Utils That Almost Happened

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/04/backdoor-in-xz-utils-that-almost-happened.html

Last week, the Internet dodged a major nation-state attack that would have had catastrophic cybersecurity repercussions worldwide. It’s a catastrophe that didn’t happen, so it won’t get much attention—but it should. There’s an important moral to the story of the attack and its discovery: The security of the global Internet depends on countless obscure pieces of software written and maintained by even more obscure unpaid, distractible, and sometimes vulnerable volunteers. It’s an untenable situation, and one that is being exploited by malicious actors. Yet precious little is being done to remedy it.

Programmers dislike doing extra work. If they can find already-written code that does what they want, they’re going to use it rather than recreate the functionality. These code repositories, called libraries, are hosted on sites like GitHub. There are libraries for everything: displaying objects in 3D, spell-checking, performing complex mathematics, managing an e-commerce shopping cart, moving files around the Internet—everything. Libraries are essential to modern programming; they’re the building blocks of complex software. The modularity they provide makes software projects tractable. Everything you use contains dozens of these libraries: some commercial, some open source and freely available. They are essential to the functionality of the finished software. And to its security.

You’ve likely never heard of an open-source library called XZ Utils, but it’s on hundreds of millions of computers. It’s probably on yours. It’s certainly in whatever corporate or organizational network you use. It’s a freely available library that does data compression. It’s important, in the same way that hundreds of other similar obscure libraries are important.

Many open-source libraries, like XZ Utils, are maintained by volunteers. In the case of XZ Utils, it’s one person, named Lasse Collin. He has been in charge of XZ Utils since he wrote it in 2009. And, at least in 2022, he’s had some “longterm mental health issues.” (To be clear, he is not to blame in this story. This is a systems problem.)

Beginning in at least 2021, Collin was personally targeted. We don’t know by whom, but we have account names: Jia Tan, Jigar Kumar, Dennis Ens. They’re not real names. They pressured Collin to transfer control over XZ Utils. In early 2023, they succeeded. Tan spent the year slowly incorporating a backdoor into XZ Utils: disabling systems that might discover his actions, laying the groundwork, and finally adding the complete backdoor earlier this year. On March 25, Hans Jansen—another fake name—tried to push the various Unix systems to upgrade to the new version of XZ Utils.

And everyone was poised to do so. It’s a routine update. In the span of a few weeks, it would have been part of both Debian and Red Hat Linux, which run on the vast majority of servers on the Internet. But on March 29, another unpaid volunteer, Andres Freund—a real person who works for Microsoft but who was doing this in his spare time—noticed something weird about how much processing the new version of XZ Utils was doing. It’s the sort of thing that could be easily overlooked, and even more easily ignored. But for whatever reason, Freund tracked down the weirdness and discovered the backdoor.

It’s a masterful piece of work. It affects the SSH remote login protocol, basically by adding a hidden piece of functionality that requires a specific key to enable. Someone with that key can use the backdoored SSH to upload and execute an arbitrary piece of code on the target machine. SSH runs as root, so that code could have done anything. Let your imagination run wild.

This isn’t something a hacker just whips up. This backdoor is the result of a years-long engineering effort. The ways the code evades detection in source form, how it lies dormant and undetectable until activated, and its immense power and flexibility give credence to the widely held assumption that a major nation-state is behind this.

If it hadn’t been discovered, it probably would have eventually ended up on every computer and server on the Internet. Though it’s unclear whether the backdoor would have affected Windows and macOS, it would have worked on Linux. Remember in 2020, when Russia planted a backdoor into SolarWinds that affected 14,000 networks? That seemed like a lot, but this would have been orders of magnitude more damaging. And again, the catastrophe was averted only because a volunteer stumbled on it. And it was possible in the first place only because the first unpaid volunteer, someone who turned out to be a national security single point of failure, was personally targeted and exploited by a foreign actor.

This is no way to run critical national infrastructure. And yet, here we are. This was an attack on our software supply chain. This attack subverted software dependencies. The SolarWinds attack targeted the update process. Other attacks target system design, development, and deployment. Such attacks are becoming increasingly common and effective, and also are increasingly the weapon of choice of nation-states.

It’s impossible to count how many of these single points of failure are in our computer systems. And there’s no way to know how many of the unpaid and unappreciated maintainers of critical software libraries are vulnerable to pressure. (Again, don’t blame them. Blame the industry that is happy to exploit their unpaid labor.) Or how many more have accidentally created exploitable vulnerabilities. How many other coercion attempts are ongoing? A dozen? A hundred? It seems impossible that the XZ Utils operation was a unique instance.

Solutions are hard. Banning open source won’t work; it’s precisely because XZ Utils is open source that an engineer discovered the problem in time. Banning software libraries won’t work, either; modern software can’t function without them. For years, security engineers have been pushing something called a “software bill of materials”: an ingredients list of sorts so that when one of these packages is compromised, network owners at least know if they’re vulnerable. The industry hates this idea and has been fighting it for years, but perhaps the tide is turning.

The fundamental problem is that tech companies dislike spending extra money even more than programmers dislike doing extra work. If there’s free software out there, they are going to use it—and they’re not going to do much in-house security testing. Easier software development equals lower costs equals more profits. The market economy rewards this sort of insecurity.

We need some sustainable ways to fund open-source projects that become de facto critical infrastructure. Public shaming can help here. The Open Source Security Foundation (OSSF), founded in 2022 after another critical vulnerability in an open-source library—Log4j—was discovered, addresses this problem. The big tech companies pledged $30 million in funding after the critical Log4j supply chain vulnerability, but they never delivered. And they are still happy to make use of all this free labor and free resources, as a recent Microsoft anecdote indicates. The companies benefiting from these freely available libraries need to actually step up, and the government can force them to.

There’s a lot of tech that could be applied to this problem, if corporations were willing to spend the money. Liabilities will help. The Cybersecurity and Infrastructure Security Agency’s (CISA’s) “secure by design” initiative will help, and CISA is finally partnering with OSSF on this problem. Certainly the security of these libraries needs to be part of any broad government cybersecurity initiative.

We got extraordinarily lucky this time, but maybe we can learn from the catastrophe that didn’t happen. Like the power grid, communications network, and transportation systems, the software supply chain is critical infrastructure, part of national security, and vulnerable to foreign attack. The US government needs to recognize this as a national security problem and start treating it as such.

This essay originally appeared in Lawfare.

In Memoriam: Ross Anderson, 1956–2024

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/04/in-memoriam-ross-anderson-1956-2024.html

Last week, I posted a short memorial of Ross Anderson. The Communications of the ACM asked me to expand it. Here’s the longer version.

EDITED TO ADD (4/11): Two weeks before he passed away, Ross gave an 80-minute interview where he told his life story.

XZ Utils Backdoor

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/04/xz-utils-backdoor.html

The cybersecurity world got really lucky last week. An intentionally placed backdoor in XZ Utils, an open-source compression utility, was pretty much accidentally discovered by a Microsoft engineer—weeks before it would have been incorporated into both Debian and Red Hat Linux. From ArsTehnica:

Malicious code added to XZ Utils versions 5.6.0 and 5.6.1 modified the way the software functions. The backdoor manipulated sshd, the executable file used to make remote SSH connections. Anyone in possession of a predetermined encryption key could stash any code of their choice in an SSH login certificate, upload it, and execute it on the backdoored device. No one has actually seen code uploaded, so it’s not known what code the attacker planned to run. In theory, the code could allow for just about anything, including stealing encryption keys or installing malware.

It was an incredibly complex backdoor. Installing it was a multi-year process that seems to have involved social engineering the lone unpaid engineer in charge of the utility. More from ArsTechnica:

In 2021, someone with the username JiaT75 made their first known commit to an open source project. In retrospect, the change to the libarchive project is suspicious, because it replaced the safe_fprint function with a variant that has long been recognized as less secure. No one noticed at the time.

The following year, JiaT75 submitted a patch over the XZ Utils mailing list, and, almost immediately, a never-before-seen participant named Jigar Kumar joined the discussion and argued that Lasse Collin, the longtime maintainer of XZ Utils, hadn’t been updating the software often or fast enough. Kumar, with the support of Dennis Ens and several other people who had never had a presence on the list, pressured Collin to bring on an additional developer to maintain the project.

There’s a lot more. The sophistication of both the exploit and the process to get it into the software project scream nation-state operation. It’s reminiscent of Solar Winds, although (1) it would have been much, much worse, and (2) we got really, really lucky.

I simply don’t believe this was the only attempt to slip a backdoor into a critical piece of Internet software, either closed source or open source. Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone unpaid distracted—or worse—individuals.

Ross Anderson

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/03/ross-anderson.html

Ross Anderson unexpectedly passed away Thursday night in, I believe, his home in Cambridge.

I can’t remember when I first met Ross. Of course it was before 2008, when we created the Security and Human Behavior workshop. It was well before 2001, when we created the Workshop on Economics and Information Security. (Okay, he created both—I helped.) It was before 1998, when we wrote about the problems with key escrow systems. I was one of the people he brought to the Newton Institute, at Cambridge University, for the six-month cryptography residency program he ran (I mistakenly didn’t stay the whole time)—that was in 1996.

I know I was at the first Fast Software Encryption workshop in December 1993, another conference he created. There I presented the Blowfish encryption algorithm. Pulling an old first-edition of Applied Cryptography (the one with the blue cover) down from the shelf, I see his name in the acknowledgments. Which means that sometime in early 1993—probably at Eurocrypt in Lofthus, Norway—I, as an unpublished book author who had only written a couple of crypto articles for Dr. Dobb’s Journal, asked him to read and comment on my book manuscript. And he said yes. Which means I mailed him a paper copy. And he read it. And mailed his handwritten comments back to me. In an envelope with stamps. Because that’s how we did it back then.

I have known Ross for over thirty years, as both a colleague and a friend. He was enthusiastic, brilliant, opinionated, articulate, curmudgeonly, and kind. Pick up any of his academic papers—there are many—and odds are that you will find a least one unexpected insight. He was a cryptographer and security engineer, but also very much a generalist. He published on block cipher cryptanalysis in the 1990s, and the security of large-language models last year. He started conferences like nobody’s business. His masterwork book, Security Engineering—now in its third edition—is as comprehensive a tome on cybersecurity and related topics as you could imagine. (Also note his fifteen-lecture video series on that same page. If you have never heard Ross lecture, you’re in for a treat.) He was the first person to understand that security problems are often actually economic problems. He was the first person to make a lot of those sorts of connections. He fought against surveillance and backdoors, and for academic freedom. He didn’t suffer fools in either government or the corporate world.

He’s listed in the acknowledgments as a reader of every one of my books from Beyond Fear on. Recently, we’d see each other a couple of times a year: at this or that workshop or event. The last time I saw him was last June, at SHB 2023, in Pittsburgh. We were having dinner on Alessandro Acquisti‘s rooftop patio, celebrating another successful workshop. He was going to attend my Workshop on Reimagining Democracy in December, but he had to cancel at the last minute. (He sent me the talk he was going to give. I will see about posting it.) The day before he died, we were discussing how to accommodate everyone who registered for this year’s SHB workshop. I learned something from him every single time we talked. And I am not the only one.

My heart goes out to his wife Shireen and his family. We lost him much too soon.

EDITED TO ADD (4/10): I wrote a longer version for Communications of the ACM.

Security Vulnerability in Saflok’s RFID-Based Keycard Locks

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/03/security-vulnerability-in-safloks-rfid-based-keycard-locks.html

It’s pretty devastating:

Today, Ian Carroll, Lennert Wouters, and a team of other security researchers are revealing a hotel keycard hacking technique they call Unsaflok. The technique is a collection of security vulnerabilities that would allow a hacker to almost instantly open several models of Saflok-brand RFID-based keycard locks sold by the Swiss lock maker Dormakaba. The Saflok systems are installed on 3 million doors worldwide, inside 13,000 properties in 131 countries. By exploiting weaknesses in both Dormakaba’s encryption and the underlying RFID system Dormakaba uses, known as MIFARE Classic, Carroll and Wouters have demonstrated just how easily they can open a Saflok keycard lock. Their technique starts with obtaining any keycard from a target hotel—say, by booking a room there or grabbing a keycard out of a box of used ones—then reading a certain code from that card with a $300 RFID read-write device, and finally writing two keycards of their own. When they merely tap those two cards on a lock, the first rewrites a certain piece of the lock’s data, and the second opens it.

Dormakaba says that it’s been working since early last year to make hotels that use Saflok aware of their security flaws and to help them fix or replace the vulnerable locks. For many of the Saflok systems sold in the last eight years, there’s no hardware replacement necessary for each individual lock. Instead, hotels will only need to update or replace the front desk management system and have a technician carry out a relatively quick reprogramming of each lock, door by door. Wouters and Carroll say they were nonetheless told by Dormakaba that, as of this month, only 36 percent of installed Safloks have been updated. Given that the locks aren’t connected to the internet and some older locks will still need a hardware upgrade, they say the full fix will still likely take months longer to roll out, at the very least. Some older installations may take years.

If ever. My guess is that for many locks, this is a permanent vulnerability.

NIS2, DORA, CER and GDPR: A Comparative Overview of Crucial EU Compliance Directives and Regulations

Post Syndicated from Editor original https://nebosystems.eu/comparative-guide-dora-gdpr-nis2-cer/

In the evolving regulatory landscape, organizations operating within the EU must navigate through a complex web of regulations and directives, including NIS2 (Network & Information System) Directive, CER (Critical Entities Resilience) Directive, DORA (Digital Operational Resilience Act) and GDPR (General Data Protection Regulation). Each of these frameworks has a distinct focus, from enhancing cybersecurity and operational resilience to protecting personal data and ensuring the resilience of critical entities.

This guide outlines the essential aspects of DORA (EU) 2022/2554, GDPR (EU) 2016/679, NIS2 (EU) 2022/2555 directive and the CER/RCE (EU) 2022/2557 directive, including their scope, objectives, key requirements, sanctions for non-compliance, implementation deadlines, technical and organizational measures, key differences and compliance intersections.

Scope and Applicability

  • NIS2 (Network & Information System) Directive : Applies to essential and important entities across various sectors expanding the scope of its predecessor, the NIS Directive.
  • Essential entities include sectors such as energy (including electricity, oil, and gas), transport (air, rail, water and road), banking, financial market infrastructures, health care, drinking water, wastewater, and digital infrastructure. Essential entities are those whose disruption would cause significant impacts on public safety, security, or economic or societal activities.
  • Important Entities covers postal and courier services, waste management, manufacture, production and distribution of chemicals, food production, distribution and sale, manufacturing of medical devices, computers and electronics, machinery equipment, motor vehicles, digital providers such as online marketplaces, online search engines, and social networking services platforms, and certain entities within the public administration sector.
  • DORA (Digital Operational Resilience Act): Specifically focuses on the resilience of the financial sector to ICT risks, encompassing a wide range of entities that play pivotal roles in the financial ecosystem. This includes credit institutions, investment firms, insurance and reinsurance companies, payment institutions, electronic money institutions, crypto-asset service providers, central securities depositories, central counterparties, trading venues, managers of alternative investment funds and management companies of undertakings for collective investment in transferable securities (UCITS). Additionally, it covers ICT third-party service providers to these financial entities, emphasizing the importance of digital operational resilience not just within financial entities themselves but also within their extended digital supply chains.
  • GDPR (General Data Protection Regulation): Has a global reach, affecting any organization that processes personal data of EU citizens, focusing on data protection and privacy regardless of the sector.
  • CER (Critical Entities Resilience) Directive: Aims to enhance the resilience of critical entities operating in vital sectors such as energy, transport, banking, financial market infrastructure, health, drinking water, waste water, public administration, space, digital infrastructure, production, processing and distribution of food sector within the EU.

Objectives

  • NIS2 Directive: Seeks to significantly raise cybersecurity standards and improve incident response capabilities across the EU.
  • DORA: Ensures that the financial sector can withstand, respond to, and recover from ICT-related disruptions and threats.
  • GDPR: Protects EU citizens’ personal data, ensuring privacy and giving individuals control over their personal information.
  • CER Directive: Focuses on enhancing the overall resilience of entities that are critical to the maintenance of vital societal or economic activities against a range of non-cyber and cyber threats.

Key Requirements

  • NIS2 Directive: Mandates robust risk management measures, timely incident reporting, supply chain security and resilience testing among affected entities.
  • DORA: Requires financial entities to establish comprehensive ICT risk management frameworks, report significant ICT-related incidents, conduct resilience testing and manage risks related to third-party ICT service providers.
  • GDPR: Enforces principles such as lawful processing, data minimization and transparency; upholds data subjects’ rights; mandates data breach notifications; and requires data protection measures to be embedded in business processes.
  • CER Directive: Calls for national risk assessments, enhanced security measures, incident notification, and crisis management for critical entities, ensuring they can maintain essential services under adverse conditions.

Sanctions and Penalties

  • NIS2 Directive: The directive suggests Member States ensure that penalties for non-compliance are effective, proportionate, and dissuasive, but does not specify amounts, leaving it to individual Member States to set.
  • DORA: Specific sanctions and penalties are not detailed, implying that penalties would be defined at the Member State level or in subsequent regulatory guidance.
  • GDPR: Known for its strict penalties, organizations can face fines up to €20 million or 4% of their total global turnover, whichever is higher.
  • CER Directive: Similar to NIS2, the CER Directive leaves the specifics of sanctions and penalties to Member States, emphasizing the need for them to be effective, proportionate, and dissuasive.

Implementation Deadline Date

  • NIS2 Directive: Member States are required to transpose and apply the measures of the NIS2 Directive by 18 October 2024 .
  • DORA: The regulation will become applicable from 17 January 2025, marking the deadline for entities within the financial sector to comply with its requirements .
  • GDPR: This regulation has been in effect since 25 May 2018, requiring immediate compliance from the effective date.
  • CER Directive: Similar to NIS2, the CER Directive must be transposed and applied by Member States by 18 October 2024 .

Key Differences

While NIS2, DORA, GDPR and CER directives and regulations share common goals related to security and privacy, they differ significantly in their primary focus and applicability:

  • NIS2 Directive primarily enhances cybersecurity across various critical sectors, emphasizing sector-specific risk management and incident reporting.
  • DORA focuses on the financial sector’s digital operational resilience, detailing ICT risk management and third-party risk, specific to financial services.
  • GDPR is dedicated to personal data protection, granting extensive rights to individuals regarding their data, applicable across all sectors.
  • CER Directive aims to ensure the resilience of entities vital for societal and economic well-being, focusing on both cyber and physical resilience measures.

Overlapping Areas

Despite their differences, these frameworks overlap in several key areas, allowing for synergistic compliance efforts:

  • Risk Management: NIS2, DORA and the CER Directive all emphasize robust risk management, albeit with different focal points (cybersecurity, ICT and critical entity resilience, respectively).
  • Incident Reporting: NIS2 and DORA require incident reporting within their respective domains, which can streamline processes for entities covered by both.
  • Data Protection Measures: GDPR’s data protection principles can complement the cybersecurity measures under NIS2 and CER, enhancing overall data security.

Incident Response and Recovery

  • NIS2 Directive: Requires entities to have incident response capabilities in place, ensuring timely detection, analysis, and response to incidents. It emphasizes the need for recovery plans to restore services after an incident.
  • DORA: Mandates financial entities to establish and implement an incident management process capable of responding swiftly to ICT-related incidents, including recovery objectives, restoration of systems, and lessons learned activities.
  • GDPR: While not explicitly detailing incident response processes, GDPR mandates notification of personal data breaches to supervisory authorities and, in certain cases, to the affected individuals, highlighting the need for an effective response mechanism.
  • CER Directive: Stresses the importance of having incident response plans, ensuring critical entities can quickly respond to and recover from disruptive incidents, maintaining essential services.

Technical and Organizational Measures

  • NIS2 Directive: Entities should incorporate state-of-the-art cybersecurity solutions like advanced threat detection systems, comprehensive data encryption, secure network configurations and regular security assessments to safeguard sensitive information. Additional technical measures might include continuous monitoring and anomaly detection systems to identify suspicious activities in real time, and the implementation of Security Information and Event Management (SIEM) systems and next-generation firewalls (NGFWs). Organizational strategies involve establishing a robust cybersecurity governance framework, conducting frequent cybersecurity awareness training, and formulating clear policies for effective incident response and thorough business continuity planning.
  • DORA: For compliance with DORA, financial entities are advised to utilize secure communication protocols and robust encryption for protecting data during transmission and storage, supplemented by multi-factor authentication systems to enhance access security. Additional technical measures could involve the deployment of advanced cybersecurity tools like Security Information and Event Management (SIEM) systems for integrated threat analysis and response, and next-generation firewalls (NGFWs). On the organizational front, setting up a dedicated ICT risk management team, clearly defining cybersecurity roles, and embedding cybersecurity risk considerations into the overarching risk management framework are essential.
  • GDPR: In alignment with GDPR, technical safeguards such as strong data encryption, pseudonymization of personal data where feasible, and stringent access control mechanisms are pivotal. Expanding on these, additional technical measures may include the use of Data Loss Prevention (DLP) tools to prevent unauthorized data disclosure or loss and employing regular penetration testing to identify and rectify vulnerabilities. Organizational measures encompass the implementation of comprehensive data protection policies, conducting DPIAs for high-risk data processing activities, and appointing a Data Protection Officer in specific scenarios to oversee data protection strategies and compliance.
  • CER Directive: Adhering to the CER Directive involves applying network segmentation to isolate and protect critical systems, utilizing intrusion detection and prevention systems, and ensuring resilient data backup and recovery strategies. Enhancing these measures, technical strategies could also include the deployment of next-generation firewalls (NGFWs) and the use of automated patch management systems to ensure timely application of security updates. Organizational approaches include developing a detailed incident management plan, establishing a dedicated crisis management team, and conducting regular resilience testing and drills to validate and improve recovery processes.

Compliance Intersections and Synergies

While each framework has its unique focus, there are notable intersections, particularly in the areas of risk management, incident reporting, and the overarching emphasis on security and resilience. For instance, the risk management strategies advocated by NIS2 and the CER Directive can complement the ICT risk management framework of DORA. GDPR’s requirement for data protection by design and default can also support the cybersecurity measures outlined in NIS2 and CER, promoting a secure and privacy-focused operational environment. Furthermore, the incident reporting mechanisms mandated by both NIS2 and DORA underscore a shared commitment to transparency and accountability in the face of security incidents, which can drive improvements in organizational responses to breaches, including those involving personal data under GDPR. This alignment not only streamlines compliance processes but also fortifies the organization’s overall security framework, enhancing its ability to protect against and respond to cyber threats and operational disruptions. By recognizing and acting upon these synergies, organizations can more effectively allocate resources, avoid duplicative efforts, and foster a culture of continuous improvement in cybersecurity and data protection practices.

Conclusion

Understanding the nuances and requirements of NIS2, DORA, GDPR, and the CER Directive is crucial for organizations operating within the EU, especially those that fall under the scope of multiple frameworks. By recognizing the overlaps and leveraging synergies between these regulations and directives, organizations can streamline their compliance efforts, enhance their operational resilience and data protection measures, and contribute to a safer, more secure digital and physical environment within the EU. This integrated approach not only ensures regulatory compliance but also builds a strong foundation of trust with customers, stakeholders, and regulatory bodies.

For streamlined compliance with EU directives like NIS2, DORA and GDPR, Nebosystems offers expert services tailored to your needs. Learn more about our cybersecurity solutions or get in touch directly.

Contact us

References:

NIS2 (Network & Information System) Directive (EU) 2022/2555. EUR-Lex.

General Data Protection Regulation (EU) 2016/679. EUR-Lex.

Digital Operational Resilience Act (EU) 2022/2554. EUR-Lex.

Critical Entities Resilience Directive (EU) 2022/2557. EUR-Lex.

On Secure Voting Systems

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/03/on-secure-voting-systems.html

Andrew Appel shepherded a public comment—signed by twenty election cybersecurity experts, including myself—on best practices for ballot marking devices and vote tabulation. It was written for the Pennsylvania legislature, but it’s general in nature.

From the executive summary:

We believe that no system is perfect, with each having trade-offs. Hand-marked and hand-counted ballots remove the uncertainty introduced by use of electronic machinery and the ability of bad actors to exploit electronic vulnerabilities to remotely alter the results. However, some portion of voters mistakenly mark paper ballots in a manner that will not be counted in the way the voter intended, or which even voids the ballot. Hand-counts delay timely reporting of results, and introduce the possibility for human error, bias, or misinterpretation.

Technology introduces the means of efficient tabulation, but also introduces a manifold increase in complexity and sophistication of the process. This places the understanding of the process beyond the average person’s understanding, which can foster distrust. It also opens the door to human or machine error, as well as exploitation by sophisticated and malicious actors.

Rather than assert that each component of the process can be made perfectly secure on its own, we believe the goal of each component of the elections process is to validate every other component.

Consequently, we believe that the hallmarks of a reliable and optimal election process are hand-marked paper ballots, which are optically scanned, separately and securely stored, and rigorously audited after the election but before certification. We recommend state legislators adopt policies consistent with these guiding principles, which are further developed below.

DORA Regulation: Essential Requirements for Compliance

Post Syndicated from Editor original https://nebosystems.eu/dora-regulation-compliance-requirements/

What is DORA?

The Digital Operational Resilience Act (DORA) is a EU regulation that entered into force on 16 January 2023 and will apply as of 17 January 2025. DORA (EU) 2022/2554 is a regulatory framework established by the European Union to enhance the digital operational resilience of the financial sector. It aims to ensure that all participants in the financial system have the necessary safeguards and measures in place to withstand, respond to, and recover from ICT (Information and Communication Technology) related disruptions and threats.

Who is Affected?

DORA affects a wide range of entities within the EU financial sector, including:

  1. Credit Institutions and Banks: These are financial institutions that have the authority to accept deposits from the public and provide credit to individuals and businesses. Their services may include offering checking and savings accounts, loans, mortgages, and financial advice.
  2. Investment Firms: Firms that engage in various investment services such as portfolio management, investment advice, and trading in financial instruments on behalf of clients. They play a crucial role in securities markets and can range from brokerage firms to asset management companies.
  3. Insurance and Reinsurance Companies: Insurance companies provide risk management to individuals and entities by offering insurance policies. Reinsurance companies, in turn, provide insurance to other insurance companies, helping to manage and mitigate risks across the insurance industry.
  4. Payment and Electronic Money Institutions: These entities facilitate payment services and transactions, including transfers, direct debits, and credit transfers. Electronic money institutions issue electronic money, which is a digital alternative to cash used for making electronic transactions.
  5. Crypto-Asset Service Providers: These providers offer services related to cryptocurrencies and other digital assets, including exchange platforms, wallet services, and financial services involving digital tokens.
  6. Central Securities Depositories (CSDs): CSDs are institutions that hold financial instruments like stocks and bonds in electronic form and enable their transfer through book-entry. They play a pivotal role in the settlement and safekeeping of securities in financial markets.
  7. Central Counterparties (CCPs): CCPs are entities that act as intermediaries between buyers and sellers in derivative and securities markets, guaranteeing the terms of a trade even if one party defaults, thus reducing counterparty risk.
  8. Trading Venues: This term encompasses various platforms where financial instruments are traded, including regulated markets, Multilateral Trading Facilities (MTFs), and Organized Trading Facilities (OTFs).
  9. Managers of Alternative Investment Funds (AIFs) and UCITS (Undertakings for Collective Investment in Transferable Securities): These managers operate investment funds not covered by traditional banking regulations. Alternative Investment Funds (AIFs) include hedge funds, private equity, and real estate funds, while UCITS are mutual funds that are regulated at the European level, designed for retail investors.
  10. Data Reporting Service Providers: Entities that provide reporting and data services related to financial transactions, ensuring transparency and regulatory compliance in financial markets. This includes trade repositories and approved reporting mechanisms.
  11. Crowdfunding Service Providers: Platforms that connect individuals or businesses seeking to fund projects or ventures with people willing to contribute small amounts of money, typically via the internet.
  12. ICT Third-Party Service Providers to Financial Entities: These include providers offering critical ICT services such as cloud computing, data analytics, cybersecurity solutions, and software development, which are essential for the digital operations of financial entities.

These entities encompass a broad spectrum of the financial sector within the EU, each playing a critical role in maintaining the stability and integrity of financial markets, and are thus subject to DORA’s regulatory framework aimed at enhancing their operational resilience against ICT risks.

Sanctions and Penalties:

DORA, the Digital Operational Resilience Act empowers competent authorities to impose administrative penalties and remedial measures for breaches of its regulations. This includes issuing orders to cease breaches, requiring the cessation of practices contrary to DORA provisions, adopting measures to ensure ongoing compliance with legal requirements, requiring existing data traffic records from telecommunication operators under suspicion of a breach, and issuing public notices or statements about the breach and responsible parties . The imposition of penalties considers the breach’s materiality, gravity, duration, the responsible party’s degree of responsibility, financial strength, profits gained or losses avoided due to the breach, losses caused to third parties, and the level of cooperation with the competent authority.

Key Requirements of DORA:

  1. ICT Risk Management: Entities must implement and maintain an effective and comprehensive ICT risk management framework, including policies, procedures and measures to identify, protect, detect, respond and recover from ICT-related incidents.
  2. Incident Reporting: Financial entities are required to establish and maintain mechanisms for the timely detection and reporting of significant ICT-related incidents to relevant authorities.
  3. Digital Operational Resilience Testing: Financial entities must regularly test their digital resilience capabilities through various means, including threat-led penetration testing, to identify vulnerabilities and address them proactively.
  4. ICT Third-Party Risk: Entities must manage and monitor the ICT risks stemming from their reliance on third-party service providers, including cloud computing services, ensuring that these relationships do not undermine their digital operational resilience.
  5. Information Sharing: The framework encourages financial entities to share information related to cyber threats and vulnerabilities to enhance collective defense mechanisms and resilience across the financial sector.
  6. Oversight of Critical ICT Third-Party Service Providers: DORA introduces a framework for the oversight of critical ICT third-party service providers to the financial sector, aiming to mitigate systemic risk and ensure the stability of the financial system.
  7. Compliance and Enforcement: DORA establishes mechanisms for supervisory oversight, compliance and enforcement, including the potential for sanctions in cases of non-compliance with the regulation’s requirements.

By adhering to these requirements, financial entities and their ICT third-party service providers will contribute to a more resilient and stable financial system capable of withstanding and responding effectively to digital disruptions and threats.

Navigating DORA’s requirements can be complex, but you don’t have to do it alone. Nebosystems offers tailored cybersecurity measures and consulting to ensure your compliance. Ready to secure your digital resilience? Contact us today.

Contact us

Reference: Digital Operational Resilience Act (EU) 2022/2554. EUR-Lex.

Understanding GDPR: A Definitive Guide on Key Requirements and Compliance

Post Syndicated from Editor original https://nebosystems.eu/what-is-gdpr-key-requirements-guide/

In the digital landscape where data breaches and privacy concerns are increasingly prevalent, understanding the General Data Protection Regulation (GDPR) is essential for businesses and individuals alike. Implemented on May 25, 2018, GDPR represents a significant overhaul of data protection laws, setting a new global benchmark for privacy rights, security, and compliance.

What is GDPR?

The GDPR is a comprehensive data protection law that came into effect in the European Union (EU) but has far-reaching implications for companies worldwide. It represents a significant shift in the way personal data of individuals within these regions is collected, stored, processed, and protected by organizations worldwide. It aims to give individuals more control over their personal data and to unify data protection regulations across the EU, thereby simplifying the regulatory environment for international business

Who is Affected?

The GDPR affects:

  • Organizations within the EU: All entities operating within the EU, regardless of their size, that process personal data are subject to the GDPR.
  • Organizations outside the EU: Non-EU organizations that offer goods or services to individuals in the EU or monitor the behavior of individuals within the EU are also subject to the GDPR.
  • Individuals within the EU: The GDPR enhances the rights of EU residents, offering them greater control over their personal data.

Key Requirements of GDPR

The GDPR is built around several key principles that dictate how personal data should be handled, processed, and protected. Understanding these requirements is crucial for any organization striving for compliance:

  1. Lawfulness, Fairness, and Transparency: Processing must be lawful, fair and transparent to the data subject.
  2. Purpose Limitation: Data must be collected for specified, explicit and legitimate purposes, and not further processed in a manner that is incompatible with those purposes.
  3. Data Minimization: The collection of data should be limited to what is necessary in relation to the purposes for which they are processed.
  4. Accuracy: Personal data must be accurate and, where necessary, kept up to date.
  5. Storage Limitation: Data should be retained only as long as necessary for the purposes for which they are processed.
  6. Integrity and Confidentiality (Security): Personal data must be processed in a manner that ensures appropriate security, including protection against unauthorized or unlawful processing, accidental loss, destruction or damage.
  7. Accountability: The data controller is responsible for, and must be able to demonstrate, compliance with all the principles mentioned above.

Rights of Data Subjects

The GDPR enhances and introduces new rights for data subjects, including:

  • The right to be informed: Individuals have the right to be informed about the collection and use of their personal data.
  • The right of access: Individuals can access their data and ask how their data is being used.
  • The right to rectification: Individuals have the right to have inaccurate data corrected.
  • The right to erasure (Right to be Forgotten): Individuals can request the deletion of their data under certain conditions.
  • The right to restrict processing: Individuals can request the restriction of processing of their personal data.
  • The right to data portability: Individuals have the right to receive their personal data in a structured, commonly used, and machine-readable format.
  • The right to object: Individuals can object to the processing of their personal data in certain circumstances, including for direct marketing.

Additional Requirements:

  • Consent: When processing is based on consent, it must be freely given, specific, informed, and unambiguous, with a clear affirmative action by the data subject.
  • Data Protection by Design and by Default: Organizations must implement appropriate technical and organizational measures to meet the principles of data protection effectively and safeguard individual rights. Integrating privacy considerations into the design of systems and processes, known as ‘Privacy by Design,’ is a GDPR principle that emphasizes proactive privacy measures from the outset of any project or process involving personal data.
  • Data Protection Impact Assessments (DPIAs): DPIAs are required where data processing is likely to result in high risk to the rights and freedoms of individuals, particularly with the use of new technologies.
  • Data Breach Notification: Organizations must notify the appropriate data protection authority of a data breach within 72 hours, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. Affected individuals must also be notified if there is a high risk to their rights and freedoms.
  • Data Protection Officers (DPOs): Organizations must appoint a DPO if they are a public authority, their core activities require large scale, regular and systematic monitoring of individuals, or their core activities consist of large scale processing of special categories of data or data relating to criminal convictions and offences.
  • One-Stop-Shop: The GDPR introduces a one-stop-shop mechanism for organizations operating in multiple EU countries, meaning they only have to deal with a single supervisory authority.
  • Cross-Border Data Transfers: The GDPR imposes restrictions on the transfer of personal data outside the EU, ensuring that such transfers only occur to countries or entities providing an adequate level of data protection.
  • Processors Obligations: Processors are directly responsible for processing personal data in accordance with the GDPR’s mandates, including processing data based on the controller’s documented instructions, ensuring the confidentiality of the processed data, and aiding controllers in meeting their GDPR obligations .
  • Record Keeping: Controllers and processors must keep detailed records of processing activities.
  • Security of Processing: Controllers and processors must implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk.
  • Cooperation Among Supervisory Authorities: Supervisory authorities must cooperate with each other to ensure consistent application of the GDPR across the EU.
  • Certification Mechanisms, Seals, and Marks: The GDPR encourages the use of certification mechanisms, seals, and marks as evidence of compliance with its provisions, including for controllers or processors not directly subject to the regulation due to their geographical location .

By adhering to these requirements, organizations can ensure compliance with the GDPR, thereby enhancing the protection of personal data and potentially avoiding significant penalties for non-compliance. Non-compliance with the GDPR can result in hefty fines, with penalties reaching up to €20 million or 4% of the annual worldwide turnover of the preceding financial year, whichever is greater, for the most serious infringements.

The GDPR’s impact extends beyond the borders of the EU and EEA, affecting any organization worldwide that processes the personal data of individuals within these regions. Its implementation marks a significant step towards enhancing individuals’ privacy rights and setting a new global standard for data protection.

For organizations seeking to fortify their data protection measures in line with GDPR standards, our Comprehensive GDPR Compliance Cybersecurity Solutions provide a robust framework tailored to meet the unique challenges of your business.

Whether you’re looking to enhance your cybersecurity measures or seeking expert consulting to navigate GDPR compliance, reach out Nebosystems today. Let us help you transform GDPR compliance from a daunting obligation into an opportunity for enhanced data security and trust building.

Contact us

Reference: General Data Protection Regulation (2016/679). EUR-Lex.

NIS2 Directive Compliance: A 10-Step Comprehensive Guide for Organizations

Post Syndicated from Editor original https://nebosystems.eu/nis2-directive-compliance-10-step-guide/

The Network & Information System (NIS2) Directive represents a significant shift in the European Union’s approach to bolstering digital infrastructure security, aiming to strengthen the defenses of network and information systems across key sectors. This directive, building upon the foundations laid by the original NIS Directive, introduces more stringent compliance requirements to combat the escalating cyber threats that pose risks to essential societal and economic services. This guide provides a succinct overview for businesses navigating the intricacies of the NIS2 Directive, ensuring readiness and compliance through a structured 10-step process.

Understanding the NIS2 Directive

Adopted on December 14, 2022, as Directive (EU) 2022/2555, the NIS2 Directive embodies a significant advancement in the EU’s cybersecurity efforts. It aims to bolster the resilience and reliability of essential network and information systems against cyber threats, which are integral to daily life and economic stability. By 17 October 2024, EU member states will have to transpose NIS2 into their national legislation. The directive’s development reflects a response to both current and anticipated cybersecurity challenges, emphasizing the vital role these systems play in maintaining societal and economic well-being.

Key Objectives and Broadened Scope

The primary aim of the NIS2 Directive is to reduce the risks posed to entities deemed ‘essential’ and ‘important’ within crucial network and information systems. These systems are pivotal for the smooth functioning of societal and economic activities. The directive seeks innovative and coordinated measures to counter the increasingly frequent, sophisticated, and impactful cyber threats. Notably, the NIS2 Directive widens its purview to include additional sectors, enforcing stringent requirements to achieve a uniformly high level of cybersecurity throughout the EU.

Applicability and Classification of Entities

The NIS2 Directive categorizes entities as either ‘essential’ or ‘important’, considering their significance to the economy and society as well as their size. This classification extends the directive’s applicability to a broader range of sectors critical to key societal functions and economic activities, aiming for a more inclusive coverage than what was provided by the original NIS Directive.

Steps Toward NIS2 Directive Compliance

To align with the NIS2 Directive and enhance cybersecurity frameworks, businesses could follow a systematic 10-step approach, ensuring compliance and strengthening defenses.

Step 1: Assessing Applicability

Assess whether your company falls within the scope of the sectors outlined by the NIS2 Directive to determine its relevance. Consider the potential impact of operational disruptions on societal and economic stability. For a detailed understanding, refer to our NIS2 Directive Compliance Checklist for Companies, which is intended to assist in determining if your business is impacted.

Step 2: Conducting Risk Assessments

A cornerstone of compliance is the execution of detailed risk assessments. This process entails identifying the vital components of your network and information systems and scrutinizing them for vulnerabilities that could be exploited by cyber threats. Assessing the severity and probability of these risks is crucial for prioritizing security measures. It’s not just about finding weaknesses but understanding their potential impact on your operations and the broader network, guiding a targeted approach to mitigating the most critical threats.

Step 3: Developing Cybersecurity Policies

The foundation of a resilient cybersecurity posture lies in the establishment of robust policies. These policies should encompass critical security domains, including but not limited to, access control mechanisms, data protection protocols and structured incident response strategies. The success of these policies depends on transparent communication and thorough training across the organization, guaranteeing that each member recognizes their part in maintaining cybersecurity standards

Step 4: Implementing Robust Cybersecurity Measures

Achieving NIS2 compliance requires the deployment of both technical and organizational measures, such as firewalls, encryption and access control, supplemented by organizational strategies like employee training and clear communication protocols. Explore our cybersecurity solutions to find the right strategies and tools to enhance your cybersecurity posture.

Step 5: Enhancing Supply Chain Security

The security of your supply chain is integral to your overall cybersecurity health. Evaluating the security practices of your suppliers and ensuring that cybersecurity expectations are explicitly stated in contracts with third-party vendors are essential steps. This not only protects your company but also contributes to the elevation of security standards across your entire supply network.

Step 6: Fostering Cybersecurity Awareness

Building a strong culture of cybersecurity awareness is crucial. Implementing consistent and interactive training programs, along with awareness initiatives, is key to ensuring staff are up-to-date on emerging threats and best practices. Equipping your employees with the necessary understanding and resources to identify and respond to security challenges can greatly reduce vulnerabilities.

Step 7: Establishing Incident Response Plans

Preparedness for potential cybersecurity incidents involves setting up clear, actionable response protocols. These plans should detail the steps to be taken in the event of a breach, including containment, eradication, and recovery processes. Equally important is establishing procedures for notifying the relevant authorities in a timely manner, in accordance with the Directive’s stipulations.

Step 8: Documentation and Reporting

Comprehensive record-keeping is a critical aspect of demonstrating compliance. Detailed documentation of risk assessments, policy updates, training sessions, and incident responses not only serves as evidence of compliance but also as a valuable resource for continuous improvement. Regular compliance reporting, as mandated by the NIS2 Directive, must be integrated into your organizational processes.

Step 9: Regular Review and Updates

The cybersecurity landscape is perpetually evolving, necessitating the ongoing evaluation and refinement of your cybersecurity strategies. This entails regularly revisiting your risk assessments, policies, and defensive measures to ensure they remain effective against emerging threats and align with the latest technological advancements.

Step 10: Engaging with Authorities

Active engagement with national and sector-specific cybersecurity authorities provides valuable insights and guidance. Participation in industry forums and information-sharing platforms facilitates a collaborative approach to cybersecurity, keeping you abreast of regulatory developments, best practices and sector-specific threats.

Conclusion

The NIS2 Directive offers an extensive framework for enhancing EU cybersecurity, addressing the dynamic digital threat landscape. By adhering to the outlined 10-step guide, companies could ensure compliance with the directive, contributing to the EU’s digital infrastructure’s resilience and security and safeguarding critical societal and economic functions against cyber threats.

Navigate the complexities of NIS2 compliance with confidence alongside Nebosystems. Let our seasoned cybersecurity experts lead the way, ensuring your company not only adheres to compliance mandates but also builds a strong cybersecurity infrastructure. Reach out to us now to enhance your defenses and protect your business from the ever-changing cyber threats.

Contact us

Reference: NIS2 Directive (Directive (EU) 2022/2555). EUR-Lex.

Improving C++

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/03/improving-c.html

C++ guru Herb Sutter writes about how we can improve the programming language for better security.

The immediate problem “is” that it’s Too Easy By Default™ to write security and safety vulnerabilities in C++ that would have been caught by stricter enforcement of known rules for type, bounds, initialization, and lifetime language safety.

His conclusion:

We need to improve software security and software safety across the industry, especially by improving programming language safety in C and C++, and in C++ a 98% improvement in the four most common problem areas is achievable in the medium term. But if we focus on programming language safety alone, we may find ourselves fighting yesterday’s war and missing larger past and future security dangers that affect software written in any language.

NIS2 Directive Compliance Checklist for Companies

Post Syndicated from Editor original https://nebosystems.eu/nis2-compliance-checklist-guide/

NIS2 Directive Compliance Checklist for Companies

In response to the evolving cybersecurity threats, the European Union has introduced the Network & Information System (NIS2) Directive, setting a new standard for cybersecurity measures across member states. Understanding and complying with these requirements is crucial for organizations operating within the EU.

This checklist is designed to help companies understand whether they are affected by the NIS2 Directive (Directive (EU) 2022/2555) and need to comply with its cybersecurity requirements. Answering these questions will provide an initial assessment of your company’s obligations under the Directive.

Section 1: Company Size and Type

  1. Is your company considered a medium-sized enterprise or larger according to the EU definition? (More than 50 employees and an annual turnover or balance sheet exceeding €10 million)
  • Yes
  • No
  1. Does your company operate in the digital infrastructure, including as a DNS service provider, TLD name registry, or cloud computing service provider?
  • Yes
  • No
  1. Is your company a small enterprise or micro-enterprise that plays a key role in society, the economy, or within specific sectors or types of service? (Consider if your services are critical even if your company is small.)
  • Yes
  • No

Section 2: Sector-Specific Questions

  1. Is your company involved in any of the following sectors?
  • Energy
  • Transport
  • Banking
  • Financial Market Infrastructure
  • Health sector
  • Drinking water
  • Digital infrastructure
  • Public administration
  • Space
  • None of the above
  1. Does your company provide essential services within these sectors that, if disrupted, would have a significant impact on societal or economic activities?
  • Yes
  • No

Section 3: Operational Impact

  1. Does your company rely heavily on network and information systems for the provision of your services?
  • Yes
  • No
  1. In the event of a cybersecurity incident, could your company’s services be significantly disrupted, leading to substantial financial loss or societal impact?
  • Yes
  • No

Section 4: Exclusions

  1. Is your company’s primary activity related to national security, public security, defense, or law enforcement? (Note: If only marginally related, you might still fall under the Directive.)
  • Yes
  • No
  1. Is your company a public administration entity that predominantly carries out activities in the areas of national security, public security, defense, or law enforcement?
  • Yes
  • No

Section 5: Additional Considerations

  1. Has your company been previously identified as an operator of essential services under the NIS Directive or any national legislation related to cybersecurity?
  • Yes
  • No
  1. Is your company part of the supply chain for critical services in any of the sectors identified in question 4?
  • Yes
  • No

Conclusion

  • Questions 1, 2, or 3 (Company Size and Type): If you answered “Yes” to any of these, your company falls within the scope of the NIS2 Directive due to its size, operation within digital infrastructure, or significant role despite being a small or microenterprise. Next Steps: Assess specific obligations under the NIS2 Directive and begin implementing necessary cybersecurity measures and reporting mechanisms.
  • Question 4 (Sector Involvement): A “Yes” response indicates your company operates in a sector directly affected by the NIS2 Directive. Next Steps: Identify sector-specific cybersecurity requirements and engage with sector regulators or national cybersecurity authorities for guidance.
  • Question 5 (Provision of Essential Services): If “Yes,” your services are crucial, making compliance with the NIS2 Directive imperative to ensure service continuity and security. Next Steps: Prioritize establishing a comprehensive risk management framework and incident response plan as per NIS2 requirements.
  • Questions 6 and 7 (Operational Impact): Affirmative answers highlight your reliance on network and information systems and potential significant impacts from cybersecurity incidents. Next Steps: Strengthen your cybersecurity infrastructure, focusing on resilience and rapid incident response capabilities.
  • Questions 8 and 9 (Exclusions): If you answered “Yes,” your company might be excluded due to its primary focus on national security or law enforcement. However, marginal involvement doesn’t grant exclusion. Next Steps: Clarify your exclusion status with legal experts and, if applicable, review your cybersecurity practices to ensure they’re adequate for your operational needs.
  • Question 10 (Previous Identification as Essential Service Operator): A “Yes” answer suggests your company was already under obligations similar to those in the NIS2 Directive, which will likely continue or expand under the new directive. Next Steps: Update your cybersecurity and compliance strategies to align with NIS2 enhancements and consult with authorities for transitional requirements.
  • Question 11 (Part of the Supply Chain for Critical Services): Answering “Yes” indicates your role in the supply chain could bring you under the NIS2 Directive’s purview, especially with its increased focus on supply chain security. Next Steps: Evaluate your cybersecurity practices in the context of supply chain integrity, collaborate with your partners to understand your shared responsibilities, and implement any necessary security and reporting enhancements.

Please note that this checklist provides a preliminary assessment, and the specific obligations under the NIS2 Directive may vary based on national transposition and interpretation by regulatory authorities.

Download the NIS2 Compliance Checklist

General Advice

Regardless of your answers, it’s advisable for all companies, especially those operating within or closely related to critical sectors, to adopt robust cybersecurity measures. The evolving cybersecurity landscape and the interconnected nature of digital services mean that comprehensive security practices are essential for resilience against cyber threats.

For companies potentially falling under the NIS2 Directive, consider the following steps:

  1. Review and Update Security Policies: Ensure that your cybersecurity policies are up-to-date and align with the best practices.
  2. Engage with Regulatory Authorities: Reach out to your national cybersecurity authority or sector-specific regulatory bodies to clarify your status under the NIS2 Directive and to obtain guidance on compliance.
  3. Consult Legal and Cybersecurity Experts: Seek advice from professionals specializing in cybersecurity law and technical security measures to ensure that your company meets all legal obligations and effectively mitigates cyber risks.
  4. Implement a Compliance Plan: Develop or update your cybersecurity compliance plan to address the requirements of the NIS2 Directive, focusing on risk management, incident reporting, supply chain security, and other relevant areas.

Remember, even if your company is not directly affected by the NIS2 Directive, adopting its principles can enhance your cybersecurity posture and potentially offer a competitive advantage by demonstrating a commitment to security to your clients and partners.

Ready to ensure your company is NIS2 compliant? Contact Nebosystems today for expert NIS2 compliance consulting. Our team is dedicated to helping you navigate these regulations, ensuring your cybersecurity measures are robust and compliant. Explore our NIS2 Compliance Cybersecurity Solutions for more information on how we can assist.

Contact us

Reference: NIS2 Directive (Directive (EU) 2022/2555). EUR-Lex.

Lessons from video game companies: automation unleashes robust monitoring & observability

Post Syndicated from Rapid7 original https://blog.rapid7.com/2024/03/04/lessons-from-video-game-companies-automation-unleashes-robust-monitoring-observability/

Lessons from video game companies: automation unleashes robust monitoring & observability

Video game organizations need robust monitoring and observability solutions to stay one step ahead of cyber adversaries. Chances are, so do we all.

In this blog post, we’ll delve into how monitoring and observability capabilities enable video game organizations to bolster their cybersecurity defenses – and provide a better, more reliable gaming experience. Before we delve into the specific use case, let’s establish a foundation with a few definitions.

Monitoring involves actively tracking and analyzing events within an environment to identify potential security threats around the game and the player. Observability, on the other hand, goes beyond monitoring. It provides a holistic view of the entire system’s behavior, enabling video game organizations to understand and troubleshoot complex issues effectively. Together, robust monitoring and observability create a proactive cybersecurity stance that lets teams stop threats from escalating.

Automated Threat Detection: Automation with AI empowers Video game organizations to automate the detection of threats based on ML-predefined rules and behavioral analytics. This proactive approach ensures that potential security incidents are identified promptly, reducing the dwell time of threats within the network.

Real-time Response: Event-driving harvesting accelerates response with predefined actions in real-time. This includes isolating compromised endpoints, blocking malicious IP addresses, or executing custom response actions tailored to the organization’s security policies. The result is a swift and efficient containment of security incidents.

Adaptive Alerting: In addition to traditional alerting, automation can dynamically adjust alert thresholds and criteria based on historical data. This means that security teams can receive alerts for anomalous activities without being overwhelmed by false positives. This not only saves time and resources but also ensures that critical threats are not missed.

Contextual Enrichment: To enhance observability, Layered Context provides a holistic view of the most critical resources found in all environments; it is an enrichment of security alerts with contextual information. This includes user and asset details, historical behavior, and threat intelligence feeds. The enriched data provides security analysts with a comprehensive understanding of the security incident, enabling more informed and effective decision-making.

Customizable Process Workflows: Process-automated workflow capabilities are highly customisable, allowing video game organizations to create tailored workflows that align with their unique security requirements. This flexibility ensures that automation is not a one-size-fits-all solution but a dynamic tool that adapts to the specific needs of each organization.

In theory, this means you are adding protection and improving preventive measures while getting better at detecting threats that slip past our defenses. In reality, it means the security team has more and more tools for learning, configuring, monitoring and using.

In a digital landscape where cyber threats are becoming more sophisticated and prevalent, video game organizations must leverage advanced solutions that provide robust monitoring and observability. Rapid7, with its powerful automation features, is at the forefront of this cybersecurity evolution. Automating threat detection, incident response, alerting, contextual enrichment, and workflows empowers Video game organizations to enhance their cybersecurity defenses and respond effectively to the ever-changing threat landscape.

NIST Cybersecurity Framework 2.0

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/03/nist-cybersecurity-framework-2-0.html

NIST has released version 2.0 of the Cybersecurity Framework:

The CSF 2.0, which supports implementation of the National Cybersecurity Strategy, has an expanded scope that goes beyond protecting critical infrastructure, such as hospitals and power plants, to all organizations in any sector. It also has a new focus on governance, which encompasses how organizations make and carry out informed decisions on cybersecurity strategy. The CSF’s governance component emphasizes that cybersecurity is a major source of enterprise risk that senior leaders should consider alongside others such as finance and reputation.

[…]

The framework’s core is now organized around six key functions: Identify, Protect, Detect, Respond and Recover, along with CSF 2.0’s newly added Govern function. When considered together, these functions provide a comprehensive view of the life cycle for managing cybersecurity risk.

The updated framework anticipates that organizations will come to the CSF with varying needs and degrees of experience implementing cybersecurity tools. New adopters can learn from other users’ successes and select their topic of interest from a new set of implementation examples and quick-start guides designed for specific types of users, such as small businesses, enterprise risk managers, and organizations seeking to secure their supply chains.

This is a big deal. The CSF is widely used, and has been in need of an update. And NIST is exactly the sort of respected organization to do this correctly.

Some news articles.

On the Insecurity of Software Bloat

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/02/on-the-insecurity-of-software-bloat.html

Good essay on software bloat and the insecurities it causes.

The world ships too much code, most of it by third parties, sometimes unintended, most of it uninspected. Because of this, there is a huge attack surface full of mediocre code. Efforts are ongoing to improve the quality of code itself, but many exploits are due to logic fails, and less progress has been made scanning for those. Meanwhile, great strides could be made by paring down just how much code we expose to the world. This will increase time to market for products, but legislation is around the corner that should force vendors to take security more seriously.

On Software Liabilities

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/02/on-software-liabilities.html

Over on Lawfare, Jim Dempsey published a really interesting proposal for software liability: “Standard for Software Liability: Focus on the Product for Liability, Focus on the Process for Safe Harbor.”

Section 1 of this paper sets the stage by briefly describing the problem to be solved. Section 2 canvasses the different fields of law (warranty, negligence, products liability, and certification) that could provide a starting point for what would have to be legislative action establishing a system of software liability. The conclusion is that all of these fields would face the same question: How buggy is too buggy? Section 3 explains why existing software development frameworks do not provide a sufficiently definitive basis for legal liability. They focus on process, while a liability regime should begin with a focus on the product—­that is, on outcomes. Expanding on the idea of building codes for building code, Section 4 shows some examples of product-focused standards from other fields. Section 5 notes that already there have been definitive expressions of software defects that can be drawn together to form the minimum legal standard of security. It specifically calls out the list of common software weaknesses tracked by the MITRE Corporation under a government contract. Section 6 considers how to define flaws above the minimum floor and how to limit that liability with a safe harbor.

Full paper here.

Dempsey basically creates three buckets of software vulnerabilities: easy stuff that the vendor should have found and fixed, hard-to-find stuff that the vendor couldn’t be reasonably expected to find, and the stuff in the middle. He draws from other fields—consumer products, building codes, automobile design—to show that courts can deal with the stuff in the middle.

I have long been a fan of software liability as a policy mechanism for improving cybersecurity. And, yes, software is complicated, but we shouldn’t let the perfect be the enemy of the good.

In 2003, I wrote:

Clearly this isn’t all or nothing. There are many parties involved in a typical software attack. There’s the company who sold the software with the vulnerability in the first place. There’s the person who wrote the attack tool. There’s the attacker himself, who used the tool to break into a network. There’s the owner of the network, who was entrusted with defending that network. One hundred percent of the liability shouldn’t fall on the shoulders of the software vendor, just as one hundred percent shouldn’t fall on the attacker or the network owner. But today one hundred percent of the cost falls on the network owner, and that just has to stop.

Courts can adjudicate these complex liability issues, and have figured this thing out in other areas. Automobile accidents involve multiple drivers, multiple cars, road design, weather conditions, and so on. Accidental restaurant poisonings involve suppliers, cooks, refrigeration, sanitary conditions, and so on. We don’t let the fact that no restaurant can possibly fix all of the food-safety vulnerabilities lead us to the conclusion that restaurants shouldn’t be responsible for any food-safety vulnerabilities, yet I hear that line of reasoning regarding software vulnerabilities all of the time.

2023 PiTuKri ISAE 3000 Type II attestation report available with 171 services in scope

Post Syndicated from Tariro Dongo original https://aws.amazon.com/blogs/security/2023-pitukri-isae-3000-type-ii-attestation-report-available-with-171-services-in-scope/

Amazon Web Services (AWS) is pleased to announce the issuance of the Criteria to Assess the Information Security of Cloud Services (PiTuKri) International Standard on Assurance Engagements (ISAE) 3000 Type II attestation report. The scope of the report covers a total of 171 services and 29 global AWS Regions.

The Finnish Transport and Communications Agency (Traficom) Cyber Security Centre published PiTuKri, which consists of 52 criteria that provide guidance when assessing the security of cloud service providers. The criteria are organized into the following 11 subdivisions:

  • Framework conditions
  • Security management
  • Personnel security
  • Physical security
  • Communications security
  • Identity and access management
  • Information system security
  • Encryption
  • Operations security
  • Transferability and compatibility
  • Change management and system development

The report includes 17 additional services in scope, for a total of 171 services. See the full list on our Services in Scope by Compliance Program page.

The following are the 17 additional services now in scope for the 2023 Pitukri report:

Five additional AWS Regions have been added to the scope, for a total of 29 Regions. The following are the five additional Regions now in scope:

  • Australia: Asia Pacific (Melbourne) (ap-southeast-4)
  • India: Asia Pacific (Hyderabad) (ap-south-2)
  • Spain: Europe (Spain) (eu-south-2)
  • Switzerland: Europe (Zurich) (eu-central-2)
  • United Arab Emirates: Middle East (UAE) (me-central-1)

The latest report covers the period from October 1, 2022, to September 30, 2023. An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and implemented for support of adherence with PiTuKri requirements. This attestation demonstrates the AWS commitment to meet security expectations for cloud service providers set by Traficom.

Customers can find the full PiTuKri ISAE 3000 report on AWS Artifact. To learn more about the complete list of certified services and Regions, see AWS Compliance Programs and AWS Services in Scope for PiTuKri.

AWS strives to continuously bring new services into the scope of its compliance programs to help you meet your architectural and regulatory needs. Contact your AWS account team for questions about the PiTuKri report.

 
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Tariro Dongo

Tariro Dongo

Tariro is a Security Assurance Program Manager at AWS, based in London. Tari is responsible for third-party and customer audits, attestations, certifications, and assessments across EMEA. Previously, Tari worked in security assurance and technology risk in the big four and financial services industry over the last 12 years.

Facebook Enables Messenger End-to-End Encryption by Default

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/12/facebook-enables-messenger-end-to-end-encryption-by-default.html

It’s happened. Details here, and tech details here (for messages in transit) and here (for messages in storage)

Rollout to everyone will take months, but it’s a good day for both privacy and security.

Slashdot thread.

Security Analysis of a Thirteenth-Century Venetian Election Protocol

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/12/security-analysis-of-a-thirteenth-century-venetian-election-protocol.html

Interesting analysis:

This paper discusses the protocol used for electing the Doge of Venice between 1268 and the end of the Republic in 1797. We will show that it has some useful properties that in addition to being interesting in themselves, also suggest that its fundamental design principle is worth investigating for application to leader election protocols in computer science. For example, it gives some opportunities to minorities while ensuring that more popular candidates are more likely to win, and offers some resistance to corruption of voters.

The most obvious feature of this protocol is that it is complicated and would have taken a long time to carry out. We will also advance a hypothesis as to why it is so complicated, and describe a simplified protocol with very similar properties.

And the conclusion:

Schneier has used the phrase “security theatre” to describe public actions which do not increase security, but which are designed to make the public think that the organization carrying out the actions is taking security seriously. (He describes some examples of this in response to the 9/11 suicide attacks.) This phrase is usually used pejoratively. However, security theatre has positive aspects too, provided that it is not used as a substitute for actions that would actually improve security. In the context of the election of the Doge, the complexity of the protocol had the effect that all the oligarchs took part in a long, involved ritual in which they demonstrated individually and collectively to each other that they took seriously their responsibility to try to elect a Doge who would act for the good of Venice, and also that they would submit to the rule of the Doge after he was elected. This demonstration was particularly important given the disastrous consequences in other Mediaeval Italian city states of unsuitable rulers or civil strife between different aristocratic factions.

It would have served, too, as commercial brand-building for Venice, reassuring the oligarchs’ customers and trading partners that the city was likely to remain stable and business-friendly. After the election, the security theatre continued for several days of elaborate processions and parties. There is also some evidence of security theatre outside the election period. A 16th century engraving by Mateo Pagan depicting the lavish parade which took place in Venice each year on Palm Sunday shows the balotino in the parade, in a prominent position—next to the Grand Chancellor—and dressed in what appears to be a special costume.

I like that this paper has been accepted at a cybersecurity conference.

And, for the record, I have written about the positive aspects of security theater.

2023 Canadian Centre for Cyber Security Assessment Summary report available with 20 additional services

Post Syndicated from Naranjan Goklani original https://aws.amazon.com/blogs/security/2023-canadian-centre-for-cyber-security-assessment-summary-report-available-with-20-additional-services/

At Amazon Web Services (AWS), we are committed to providing continued assurance to our customers through assessments, certifications, and attestations that support the adoption of current and new AWS services and features. We are pleased to announce the availability of the 2023 Canadian Centre for Cyber Security (CCCS) assessment summary report for AWS. With this assessment, a total of 150 AWS services and features are assessed in the Canada (Central) Region, including 20 additional AWS services and features. The assessment report is available for review and download on demand through AWS Artifact.

The full list of services in scope for the CCCS assessment is available on the Services in Scope page. The 20 new services and features are the following:

The CCCS is Canada’s authoritative source of cyber security expert guidance for the Canadian government, industry, and the general public. Public and commercial sector organizations across Canada rely on CCCS’s rigorous Cloud Service Provider (CSP) IT Security (ITS) assessment in their decision to use CSP services. In addition, CCCS’s ITS assessment process is a mandatory requirement for AWS to provide cloud services to Canadian federal government departments and agencies.  

The CCCS cloud service provider information technology security assessment process determines if the Government of Canada (GC) ITS requirements for the CCCS Medium cloud security profile (previously referred to as GC’s PROTECTED B/Medium Integrity/Medium Availability [PBMM] profile) are met as described in ITSG-33 (IT security risk management: A lifecycle approach, Annex 3 – Security control catalogue). As of November 2023, 150 AWS services in the Canada (Central) Region have been assessed by CCCS and meet the requirements for the Medium cloud security profile. Meeting the Medium cloud security profile is required to host workloads that are classified up to and including Medium categorization. On a periodic basis, CCCS assesses new or previously unassessed services and re-assesses the AWS services that were previously assessed to verify that they continue to meet the GC’s requirements. CCCS prioritizes the assessment of new AWS services based on their availability in Canada, and customer demand for the AWS services. The full list of AWS services that have been assessed by CCCS is available on our Services in Scope for CCCS Assessment page.

To learn more about the CCCS assessment or our other compliance and security programs, visit AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

 
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Naranjan Goklani

Naranjan Goklani

Naranjan is an Audit Lead for Canada. He has experience leading audits, attestations, certifications, and assessments across the Americas. Naranjan has more than 13 years of experience in risk management, security assurance, and performing technology audits. He previously worked in one of the Big 4 accounting firms and supported clients from the financial services, technology, retail, and utilities industries.