Posts

AI Adoption for companies in the USA

/in
This is the extension of the original article AI Adoption for companies (based on OECD data)

What US Companies Are Actually Spending — And Where It Maps

The OECD data gives you the strategic framework. US-specific data gives you a reality check on spending. Here is what verified US sources report.

 

Adoption in the US right now

The US picture differs from the OECD aggregate in one notable way: adoption is accelerating faster than the global average, but the distribution is highly uneven.
The SBA’s Business Trends and Outlook Survey (BTOS) — which draws on Census Bureau data — found that small business AI usage rose from 6.3% in February 2024 to 8.8% by August 2025. Large firms (250+ employees) were at 11% as of February 2025 by the same measure. This is a  narrower gap than the OECD’s global data, where large firms are at 40%. The difference reflects measurement methodology: the BTOS captures active business-function use, while the OECD counts any AI tool use.
The U.S. Chamber of Commerce uses self-reported surveys and gets higher numbers: 58% of small businesses said they use generative AI in 2025, up from 40% in 2024 and 23% in 2023.
These figures are not contradictory — they reflect different definitions of “using AI.” The SBA measures structured business-function deployment. The U.S. Chamber captures self-identified use of any generative AI tool, including consumer apps.
For practical planning purposes, the SBA/BTOS data is more conservative and likely more relevant to real operational deployment.

 

What US firms are spending per employee

The most useful spending data comes from a May 2026 Federal Reserve Bank of Atlanta study, based on a survey of senior US business executives conducted in March 2026.
Key findings:
– US firms spent $1,358 per employee on AI in 2025 (includes software, subscriptions, hardware, training, and IT support)
– That figure is expected to rise to $2,068 per employee in 2026 — a 50% increase year-over-year
– Aggregate private-sector AI investment is estimated at $280 billion for 2026, consistent with a separate Stanford HAI estimate of $285 billion
The distribution matters here. The median firm expects to spend no more than $200 per employee in 2026. The top 10% of firms plan to invest at least $2,800 per employee. That is a 14-fold gap between the median and the leading adopters.
This matches the OECD’s warning exactly: most companies are not spending meaningfully. The average is pulled up by a small number of large, aggressive adopters.

 

How US spending maps to the four strategies

OECD strategy level Typical US company profile Implied spend/employee (Atlanta Fed)
AI Novice Most US SMBs today ~$200 or less (median firm)
AI Optimiser Active adopters, multi-function use $500 – $1,500
AI Explorer Knowledge-intensive sectors (professional services, finance) $2,000 – $3,500
AI Transformer Top 10% of firms, enterprise-wide deployment $2,800+

Source: OECD taxonomy (December 2025) mapped to Federal Reserve Bank of Atlanta spending data (May 2026). Spend figures include software, subscriptions, hardware, training, and IT support.

Note: The spend figures are labeled “implied” because the Atlanta Fed reports a per-employee average across all firm sizes — the mapping to OECD tiers is a reasoned connection, not a direct quote from either source.
The median ($200 or less) is explicitly sourced from the Atlanta Fed’s own finding that more than half of respondents expect to spend no more than $200 per employee.
The professional and business services sector is expected to spend $3,470 per employee in 2026 — a 74% increase from 2025. Manufacturing sits at the opposite end at approximately $900 per employee.
Construction, hospitality, and transportation are likely below even that, consistent with the OECD’s sectoral findings.

 

The training gap in the US

The Atlanta Fed data confirms the OECD finding on training. When firms were asked what their AI spending covers, training was included but represents a small share of total spend for most companies. The same SBA research found that skills gaps remain the primary adoption barrier, affecting 46% of US business leaders (McKinsey data, cited by SBA).
The U.S. Chamber found that concerns over cost, compliance, and workforce readiness are the top three persistent barriers — in that order. Workforce readiness is a training problem. It does not resolve itself with more tool licenses.

 

The US-specific warning on attitude vs. spending

The U.S. Chamber found that 96% of small business owners plan to adopt emerging technologies including AI.
That intention figure is strikingly high. But intention and spending are not the same thing. The SBA/BTOS data shows actual structured deployment at 8.8% for small firms.
The gap between 96% intent and 8.8% deployment is the execution problem. It is the same problem the OECD documents globally.
Companies announce AI plans. Most stay at Novice level or never deploy meaningfully. The reason, consistently, is the same: no training program, no governance, no assigned owner, and no defined use case.

Sources

OECD & G7

US Federal & Government Sources

U.S. Chamber of Commerce

The post AI Adoption for companies in the USA first appeared on Sorin Mustaca’s blog.

AI Adoption for companies (based on OECD data)

/in

 

Why You Need to Read This Now

Between 2020 and 2024, the share of firms using AI across OECD countries more than doubled — from 5.6% to 14%. Large firms (250+ employees) are at 40% adoption. Small firms (10–49 employees) are at 11.9%. Mid-sized firms sit in the middle at 20.4%.

That gap is wider than for any other digital technology. For cloud computing or IoT, smaller firms are roughly half as likely to adopt. For AI, it’s more than three times.

If you are a mid-manager, you sit at the execution layer: strategy comes from the top, AI resistance comes from the bottom. You’re the one who has to make it actually work.

This article is written for that position.

 

The Four Types of Companies — Where Does Yours Fit?

The OECD taxonomy organizes AI adoption into four profiles based on digital maturity, complexity of use, and how widely AI is applied across the business.

AI Novice. Using off-the-shelf tools (ChatGPT, Copilot) for isolated tasks — writing, marketing, simple process support. Leadership has heard about AI but no formal strategy exists. Most SMEs fall here today.

AI Optimiser. AI is used systematically across several departments. There’s coordination and some governance. Adoption covers content, customer service, and workflow efficiency.

AI Explorer. Custom AI models are being built or fine-tuned on internal data. Use cases are sector-specific. The team experiments with agents and automated pipelines.

AI Transformer. AI is embedded enterprise-wide, across operations and decision-making. In-house technical expertise exists. Infrastructure is unified.

The taxonomy matters because the right strategy — and the right costs — depend entirely on which category you’re in, or which you’re trying to reach.

 

Keep this in mind:

One size does not fit all: firms with varying levels of digital maturity may require different instruments to boost their capabilities and their ability to leverage the potential of AI.

 

Strategy 1: Start as an AI Novice (Off-the-Shelf Tools Only)

What it means

You deploy consumer-grade or SaaS AI tools directly. No custom development. No infrastructure investment. Tools include ChatGPT, Microsoft Copilot, Google Gemini, or vertical-specific tools embedded in software your team already uses.

Real example from the OECD report: a small coffee roaster in San Francisco used ChatGPT for product descriptions, SEO, marketing emails, and shipping cost analysis — entirely self-taught, no budget for specialists.

Financial cost

Item Estimated range
ChatGPT Team or Business $25–$30 per user/month
Microsoft 365 Copilot (if already on M365) $30 per user/month
Google Workspace with Gemini $20–$30 per user/month
Typical annual cost for a 20-person team $6,000–$10,000/year

These are subscription costs only. No infrastructure. No data work. No custom code.

You can start with 5–10 users before rolling out to the whole team. Most tools have free tiers for initial testing.

Training cost

This is where companies systematically fail. The OECD found that under 30% of SMEs using generative AI report providing any AI-related training to employees. Japan is at 11.3%. Germany at 23.2%. The UK at 24%.

For AI Novice rollout, training is not optional if you want results. The research shows that firm-provided training and employer encouragement significantly boost workers’ use of generative AI and reduce demographic gaps in use (OECD D4SME Survey, 2025).

Minimum training investment at this level:

Training type Cost estimate
External prompt engineering workshop (half-day, group) $1,500–$4,000 one-time
Online course per employee (Coursera, LinkedIn Learning AI courses) $300–$500/person/year
Internal champion — one person designated to run practice sessions Time cost: ~2–4 hours/week
Total for 20-person team, first year $8,000–$18,000

The time cost is often underestimated. Expect 4–8 hours per employee in the first three months to reach basic competency. That’s real productivity loss during the transition period.

What the OECD calls the J-curve risk

The research documents a J-shaped productivity curve: performance may decline temporarily before it improves. Budget for this. It is normal. Teams produce less while learning. This typically lasts 4–12 weeks depending on tool complexity and training investment. Managers who don’t anticipate this tend to abandon tools too early.

What you should do

  • Pick one use case with a measurable output (e.g., first draft of customer communications, meeting summaries, internal documentation).
  • Run a 4-week pilot with 5 people before scaling.
  • Assign an internal champion. This person does not need to be technical.
  • Create a short usage guideline (2 pages maximum) covering acceptable use, data sensitivity rules, and output review requirements.

Strategy 2: Become an AI Optimiser (Cross-Functional Integration)

What it means

You move from isolated tool use to coordinated AI integration across departments. AI is used in marketing, customer service, HR, operations, and finance — not just by individuals experimenting independently.

This requires governance. You need policies on what data goes into AI tools, who reviews outputs, and how AI decisions are audited.

Financial cost

Costs increase significantly here because you’re adding coordination infrastructure, not just tool licenses.

Item Estimated range
SaaS AI tools (expanded seat count) $15,000–$40,000/year for 50–100 users
AI governance tooling (policy management, audit logs) $5,000–$20,000/year
Process mapping and workflow redesign (consulting or internal time) $10,000–$30,000 one-time
Data audit and clean-up (making internal data usable by AI tools) $5,000–$25,000 one-time
Total first-year investment (50-person team) $35,000–$115,000

The OECD report is explicit: the cost of developing AI-ready data should not be overlooked. Most companies discover their internal data is fragmented, inconsistently labelled, or stored in formats AI tools cannot use. This cleanup is expensive and slow.

Training cost

At Optimiser level, training needs are more specific. Employees need to understand not just how to use tools, but how AI outputs feed into business processes and where human review is required.

Training type Cost estimate
Role-specific AI training (tailored by function: sales, ops, finance, HR) $500–$2,000/person
AI literacy program for managers (decision-making with AI outputs) $1,000–$3,000/manager
Change management workshops (handling team resistance) $5,000–$15,000
Ongoing skills refresher budget (tools evolve rapidly) $200–$500/person/year
Total first-year training cost (50-person team) $40,000–$100,000

The OECD survey data identifies the skills that become more important due to generative AI: data analysis and interpretation (cited by 46.4% of firms), creativity and innovation (41.9%), programming and coding (39%), and communication and collaboration (35.8%). Your training program should target these explicitly.

What the OECD says about resistance

Cultural and organizational resistance is one of the documented barriers at this level. The G7 Blueprint is specific: change management is essential to guide teams through AI integration transitions, address opposition, facilitate upskilling, and embed AI into everyday workflows.

Budget for this separately. It is not the same as technical training. Change management at this scale typically requires a structured program over 3–6 months, either run internally by HR with a framework or outsourced to a specialist.

What you should do

  • Build an AI adoption roadmap. The OECD recommendation is explicit: company-level roadmaps should align with overall business goals and articulate where, why, and how AI will be used to drive value.
  • Define a data governance policy before expanding tool use. What can employees input into external AI systems? What is off-limits (personal data, client data, confidential financial data)?
  • Establish a cross-functional AI steering group. Include someone from legal, IT, HR, and one or two operational team leads.
  • Set measurable targets. Productivity gains at this level typically show after 6–12 months. Firms in OECD research showed productivity premiums over 4%, with some above 15%, but only when AI was integrated into core operations — not kept at the periphery.

Strategy 3: Become an AI Explorer (Custom and Sector-Specific AI)

What it means

You begin building or fine-tuning AI models on your own data. Use cases are specific to your business context — custom agents, proprietary analysis pipelines, sector-specific classification or prediction tools.

Real example from the OECD report: a micro wholesale company in Tokyo built custom AI agents for Q&A, project negotiations, and multi-language translated chat, which increased revenues and shortened negotiation cycles.

This requires internal technical capability or reliable external partners. It is not viable without AI-ready data and at least one technically proficient person managing the work.

Financial cost

Item Estimated range
Cloud AI infrastructure (compute, storage, API access) $20,000–$80,000/year
AI development (internal hire or external agency) $80,000–$200,000/year
Data preparation and labelling $15,000–$50,000 one-time or ongoing
Security and compliance infrastructure $10,000–$30,000/year
Total annual investment $125,000–$360,000+

The OECD report highlights a specific market problem at this level: lack of competition among cloud AI infrastructure providers has led to over-reliance on hyperscalers (AWS, Azure, Google Cloud), which makes terms restrictive and costs high for SMEs. This is a real constraint. Plan for it.

Open-source AI models (Meta’s Llama, Mistral, and others) are specifically highlighted in the G7 Blueprint as a way to reduce costs and lower barriers. These require more technical overhead but significantly reduce licensing costs.

Training cost

Technical roles at this level are expensive. The OECD is direct about this: small companies often lack sufficient resources to offer competitive salaries that help attract and retain talent, putting them at a disadvantage compared to larger companies.

Training/talent type Cost estimate
ML engineer or data scientist (hire or contractor) $90,000–$180,000/year salary range
Advanced AI/ML certification for existing technical staff $3,000–$10,000/person
Cross-functional AI training (non-technical staff working with AI outputs) $500–$1,500/person
External AI advisor or mentor (part-time engagement) $15,000–$50,000/year
Total first-year talent and training cost $110,000–$240,000+

The OECD recommends pooled training programs as a cost-reduction mechanism — sharing training costs through industry associations, sector groups, or regional clusters. This is worth exploring specifically if you’re in a sector with a strong industry association.

What you should do

  • Validate the business case before committing to custom development. The OECD documents that many companies move to Explorer level prematurely and get stuck — experiments that never scale.
  • Start with one tightly scoped use case. The G7 Blueprint is explicit: successful projects begin with tightly defined problems that align with business priorities, such as cost savings, efficiency gains, or product improvement.
  • Consider academic partnerships. Embedding AI talent directly within SMEs through internships, residencies, or collaborative projects with universities is a documented cost-reduction strategy in the OECD research.
  • Plan for 12–24 months before reliable ROI. Custom AI development rarely produces measurable returns in under a year.

Strategy 4: Aim for AI Transformer (Enterprise-Wide Embedding)

What it means

AI is embedded across all major operations and decision-making processes. Infrastructure is unified. In-house expertise exists across functions. The business model itself may depend on AI capabilities.

Real example from the OECD report: a healthcare company in Calgary uses large language models, NLP, and computer vision for clinical note transcription and lab report analysis. A Cambridge biotech built a knowledge graph integrating 50+ data sources for drug discovery.

This level is not realistic for most SMEs in the near term. It requires years of foundation-building across the previous three stages.

Financial cost

At this level, AI is no longer a project cost — it’s an operational cost embedded in the business. Typical annual investment profiles in the OECD research context range from $500,000 to several million dollars depending on sector and scale, including infrastructure, dedicated technical teams, data operations, and compliance.

This is not a starting strategy. You reach it by progressing through the previous three stages.

Training cost

The training model at this level is continuous and embedded. The entire workforce undergoes ongoing AI skills development. The OECD frames this as a culture of continuous learning, not a one-time program.

Budget: typically 2–5% of total payroll annually dedicated to training and skills development, with AI literacy as a core component of every role’s development plan.

The Four Non-Negotiable Foundations (Regardless of Strategy Level)

The OECD and G7 Blueprint identify four enablers that are prerequisites for any level of AI adoption. These apply to you regardless of which strategy above you’re pursuing.

1. Connectivity. AI tools require high-speed, reliable broadband. If your team is distributed or includes remote workers in rural areas, audit your connectivity situation before investing in AI tooling. Fixed download speeds in metropolitan areas are 44% higher than in remote areas (OECD data, 2024).

2. Data readiness. Most companies discover their data is not AI-ready. It’s fragmented, incomplete, or stored in formats that AI tools cannot process. This is not a technical problem you can skip — it’s a prerequisite. Budget time and money for a data audit before serious AI investment.

3. Skills. The OECD survey found 50% of SMEs say employees lack the skills to use AI effectively. Training is consistently the most impactful intervention across all G7 countries surveyed. It is the single highest-ROI investment in AI adoption.

4. Governance. Concerns about harmful content (cited by over 90% of US firms), inaccurate outputs, and legal/copyright issues are reported by the majority of firms. Before deployment at scale, you need a brief but real policy: what is acceptable use, what data is off-limits, and how outputs are reviewed.

What the OECD Says About Attitude vs. Actual Barriers

This is worth reading carefully. The research found that 86% of SMEs report either neutral or favorable attitudes toward generative AI. Attitude is not the primary barrier.

The obstacles are practical: skills, cost, infrastructure, and perceived relevance. Many SMEs in Canada and the UK reported believing that AI simply wasn’t suited to their type of work.

As a mid-manager, this is your most direct challenge. The resistance you’ll encounter from your team is rarely ideological. It’s practical: people don’t know how to use it, they’re worried about their jobs, and they haven’t seen it solve a real problem they have. Address those three things specifically and directly. That’s change management.

A Checklist Before You Start

Before committing budget to any AI adoption strategy, work through these questions. They come directly from the OECD’s recommended company-level assessment framework.

  • [ ] What specific business problem are we trying to solve with AI?
  • [ ] What is our current digital maturity? (Are we already using cloud tools, structured data, modern software?)
  • [ ] What data do we have, and is it clean and accessible?
  • [ ] Who internally will own AI adoption coordination?
  • [ ] What is our acceptable-use policy for AI tools, specifically regarding sensitive or confidential data?
  • [ ] What is our realistic budget for tools and training in year one?
  • [ ] How will we measure whether it’s working?
  • [ ] What’s our plan if productivity temporarily drops during transition?

Summary Table

Strategy Who it’s for Year-1 Tool Cost Year-1 Training Cost Time to ROI
AI Novice Any team, starting out $6K–$10K $8K–$18K 3–6 months
AI Optimiser Teams with some AI use, ready to coordinate $35K–$115K $40K–$100K 6–12 months
AI Explorer Technically capable, data-ready teams $125K–$360K+ $110K–$240K+ 12–24 months
AI Transformer Long-term, multi-year commitment $500K+ Ongoing (2–5% of payroll) 2–4 years

Cost ranges are estimates. They vary significantly by company size, sector, geography, and specific tools chosen.

Instead of conclusions: Don’t Skip the Steps

The taxonomy in this report is not decorative. It exists because companies that try to jump from Novice to Explorer — skipping the Optimiser phase — consistently fail to embed AI into real operations. They run pilots that never scale. They buy tools that nobody uses confidently.

Each stage builds something the next one depends on: Novice builds familiarity. Optimiser builds process and governance. Explorer builds technical depth. Transformer builds organizational identity around AI.

The productivity gains the OECD documents — 4% to 15%+ at the firm level — come from companies that moved through these stages deliberately, not from companies that spent the most money the fastest.

Your people need time to understand what the tools actually do before they can use them well. That understanding doesn’t come from a product demo or a one-hour onboarding session. It comes from repeated, low-stakes practice with real work tasks — which is exactly what each strategy level is designed to provide.

Move at the speed your team can actually absorb. That’s not caution. That’s how adoption works.

 

Sources

Based on: AI Adoption by Small and Medium-Sized Enterprises, OECD Discussion Paper for the G7, December 2025

Companion document: The SME AI Adoption Blueprint, G7 Industry, Digital and Technology Ministerial, December 2025

OECD AI Principles: https://www.oecd.org/en/topics/ai-principles.html

The post AI Adoption for companies (based on OECD data) first appeared on Sorin Mustaca’s blog.

EU Cyber Resilience Act (CRA) – Overview

/in

What is the Cyber Resilience Act – CRA

The Cyber Resilience Act is the first European regulation to set a mandatory minimum level of cyber security for all connected products available on the EU market – something that did not exist before.

The CRA is a regulation from the European Union — formally Regulation (EU) 2024/2847 — but it is likely to be applied soon in other parts of the world, which produce for and sell products in the EU.

It covers both hardware and software products whose intended or foreseeable use involves connection (direct or indirect) to a device or network. That includes things like smartphones, laptops, IoT devices (smart-home cameras, smart fridges, connected toys), embedded systems, routers, industrial control systems, and even software with network connectivity.

Non-commercial open source software products are exempt from the CRA and therefore do not have to fulfill the requirements of the CRA.

Some product categories are excluded because they are already covered by other sector-specific regulation (e.g. certain medical devices, aviation, automotive, defense).

As can be seen, the aim is to increase cybersecurity within the European Union. The new regulation applies in all EU Member States and will be implemented gradually.

Timeline & Legal Effect

The CRA entered into force on 10 December 2024. There is a transition / compliance period: the full requirements become applicable by 11 December 2027 for new products.

Starting 11 June 2026, the Conformity Assessment Bodies can assess the fulfillment of the requirements.

Reporting of vulnerabilities and security incidents starts on 11 September 2026.

*CABs = Conformity Assessment Bodies

Source: BSI

Key Requirements & Obligations

For manufacturers, importers or distributors of in-scope products, CRA demands:

Secure-by-design and secure-by-default

During design and development, implement baseline cybersecurity controls (minimizing attack surface, secure defaults, applying cryptography, access control, integrity protection, etc.).

If you design or manufacture hardware or software intended for the EU market — start including security early: threat modelling, secure defaults, update mechanisms, patch management, SBOM (software-bill-of-materials) for components, documentation.

Lifecycle security

Maintain security across the lifecycle — through production, deployment, maintenance, updates (patches), and eventual decommissioning.

Prepare to collect and maintain documentation of the build, supply chain components, update/maintenance history, and test results for many years.

Vulnerability & incident reporting

If a product becomes subject to a “actively exploited vulnerability” or a “severe security incident”, the manufacturer must report promptly (early warning within 24 h, full notification within 72 h, final report within certain timeframes) via the CRA Single Reporting Platform.

For software vendors — ensure update/patch infrastructure is robust and built-in, and notification processes in place for vulnerabilities.

Documentation & traceability

Maintain technical documentation, data inventories and evidence of security measures for a defined period (often many years) after placing the product on the market.

CE-marking with security

Products that comply must carry the CE-mark, indicating conformity with the CRA’s cybersecurity requirements — similar to CE marking for safety or environmental compliance.

For buyers/customers — expect CE-mark + transparency regarding security posture. Choose vendors who commit to long-term patching and vulnerability response.

Conformity assessments for higher-risk products

While many products (roughly 90%) fall under a “default” tier and can be self-assessed by manufacturers, certain more critical or important product types (e.g. firewalls, security modules, intrusion detection systems, certain embedded systems) may require third-party assessment before being placed on market.

Why It Matters

The CRA establishes a common, EU-wide baseline for cybersecurity of digital products. This helps avoid fragmentation where different member states might otherwise have different rules. It forces manufacturers and vendors to adopt security by default + lifecycle security, rather than treating cybersecurity as an optional afterthought. This helps reduce the attack surface and improves resilience against cyber threats.

It increases transparency for consumers and businesses: when they buy a product with digital elements, they can expect a baseline of security and support — including updates and vulnerability management.

For vendors and developers — in enterprise, embedded, IoT or consumer space — it’s a legal obligation. Non-compliance when required could lead to regulatory consequences, and non-compliant products will not be allowed on the EU market once the deadlines lapse.

 

CRA Product Classification

Criteria & Examples

The CRA divides “products with digital elements (PDEs)” into four classification tiers. Classification drives what conformity assessment, certification, and compliance rigour you must apply.

Category When a product is placed here (criteria / rationale) Typical product examples*
Default Products that are not listed in the “Important” or “Critical” annexes — i.e. no particularly sensitive cybersecurity function or high risks associated with compromise. Many consumer devices & software: smart toys, basic IoT devices, simple smart-home equipment, non-security-critical apps, common consumer electronics.
Important – Class I PDEs that provide a cybersecurity-relevant function (authentication, access control, network access, system functions) but whose compromise would have a moderate risk (less than Class II). Identity management systems / privileged-access software or hardware (e.g. access readers), standalone/embedded browsers, password managers, VPN clients, network management tools, operating systems, microcontrollers/microprocessors with security-related functions, routers/modems/switches.
Important – Class II PDEs whose function involves a significant cybersecurity risk, or whose compromise could have wide or severe impact, especially on many other systems — thus higher criticality than Class I. For these, third-party conformity assessment is mandatory. Firewalls, intrusion detection/prevention systems (IDS/IPS), virtualisation/hypervisor/ container runtime systems, tamper-resistant microprocessors/microcontrollers, industrial-grade network/security systems.
Critical PDEs with cybersecurity-related functionality whose compromise could disrupt or control a large number of other products, critical infrastructure, supply chains or sensitive services. These must either get an EU cybersecurity certificate (per relevant scheme) or undergo strict third-party assessment. Hardware security modules (“security boxes”), smart meter gateways, smartcards / secure-elements, secure cryptoprocessing hardware — i.e. devices central to critical infrastructure, secure identity, secure communication or supply chain security.

* These examples reflect currently published annex examples and guidance. Regulatory technical specification updates (e.g. by the European Commission) may refine or expand the lists.

 

Assessment & conformity requirements per class

Below are examples of software products affected by the Cyber Resilience Act, organized into two tables and classified into the CRA categories:

  • Default Category – non-critical, low inherent risk

  • Important Class I – higher exposure, widely deployed, could be abused at scale

  • Important Class II – products with elevated security relevance, including security software and products in Annex III

  • Critical – core components of cybersecurity, identity, encryption, or essential network infrastructure

These classifications follow the CRA’s conceptual tiers, not an official certification list, because exact classification depends on the manufacturer’s intended use and applicability of Annex III.

Examples of Software Products Classification

Disclaimer: this is my current understanding of products with digital elements (PDEs). There is no official list of categories of products published, or at least I did not find one.

This list was created with help of AI and it is no guarantee to be complete or correct.

 

Software Type Example(s) CRA Category Rationale
CRM Platforms Salesforce, HubSpot, MS Dynamics Default General business software; no direct security function.
Blogging/CMS Platforms WordPress, Ghost, Drupal Default Consumer and enterprise web software; not security-critical by default.
Office Productivity Tools LibreOffice, MS Office Default Widely used but not security components.
Developer Tools IDEs, build systems Important Class I Used in software supply chains; compromise impacts downstream.
Cloud Management Consoles AWS CLI tools, Azure Portal extensions Important Class I Access to infrastructure; security implications.
Antivirus / Endpoint Protection CrowdStrike, Defender, Bitdefender Important Class II Security products explicitly listed under risk-sensitive categories.
EDR/XDR Platforms SentinelOne, Trellix, Microsoft XDR Important Class II Security monitoring and threat response capabilities.
Firewalls (Software-based) pfSense, OPNsense, Cisco, Juniper Important Class II Security enforcement components.
VPN Clients OpenVPN Client, WireGuard clients Important Class II Encryption and secure communications; directly covered.
Identity & Access Software SSO, MFA clients, IdP agents Critical Core identity systems; high systemic impact.
Key Management & Crypto Libraries OpenSSL, libsodium Critical Cryptographic primitives/implementations; part of critical components.
Secure Configuration Agents MDM agents, compliance agents Important Class II Affect system posture and policy enforcement.
Network Monitoring / SIEM Splunk, Elastic, QRadar Important Class II Security event analysis and detection.
Container Security Tools Aqua, Twistlock Important Class II Protect containerized workloads; tied to infrastructure security.

 

Further reading and sources

The post EU Cyber Resilience Act (CRA) – Overview first appeared on Sorin Mustaca’s blog.

NIS2 Fulfillment through TISAX Assessment and ISA6

/in

ENX has released an interesting article about how NIS2 requirements map to TISAX requirements. For this, there is a short introductory article called “TISAX and Cybersecurity in Industry – Expert Analysis Confirms NIS2 Coverage” and

and a full article of 75 pages : https://enx.com/TISAX-NIS2-en.pdf

An analysis conducted within ENX’s expert working groups examined how well a TISAX assessment based on the ISA6 catalog aligns with the requirements of the NIS2 Directive.

The key findings include:

  • All relevant NIS2 requirements are addressed, including risk management, incident response, supply chain security, governance, and technical safeguards.
  • TISAX goes beyond minimum legal requirements, incorporating structured maturity assessments, systematic vulnerability management, and continuous improvement mechanisms.
  • The established three-year assessment cycle is considered appropriate in the context of NIS2.
  • TISAX labels are publicly accessible via the ENX database, enabling transparent verification.
  • Additional national requirements must be addressed separately. This includes, in particular, country-specific reporting obligations to authorities or national CSIRTs. While not part of the TISAX standard, these requirements can be effectively managed using existing TISAX structures.

 

Here is the summary of the PDF above created with NotebookLM (9 pages):

Detailed Briefing Document: NIS2 Fulfillment Through TISAX

Date: October 26, 2023 Prepared for: Key Stakeholders concerned with NIS2 Compliance in the Automotive Industry Subject: Review of the “NIS2 fulfilment through TISAX” Expert Opinion, detailing how TISAX assessments align with NIS2 Directive requirements.

Executive Summary

The automotive industry, through the ENX Association and the ISA requirements catalogue, has proactively addressed cybersecurity for years, culminating in the TISAX assessment standard established in 2017. This expert opinion, published by the ENX Association, concludes that companies with TISAX-compliant sites fully implement the requirements of the NIS2 Directive. The ISA catalogue and TISAX assessments go beyond NIS2 requirements, defining and continuously upholding the “state of the art” in information and cybersecurity for the industry. Independent auditors confirm implementation in a three-year cycle, deemed appropriate even when compared to the two-year cycle for critical infrastructure operators under German law. A common exchange mechanism allows organizations to query TISAX status and, by extension, NIS2 compliance, of partners.

Key Takeaway: Organizations with a valid TISAX label are generally well-prepared for the material requirements of NIS2, with the caveat that they must still manage national reporting requirements in parallel and ensure that their TISAX assessment objectives reflect their overall risk and cover all NIS2-affected sites.

1. Introduction and Overview of NIS2 and TISAX

The NIS2 Directive (EU) 2022/2555 aims to strengthen cyber resilience across the European Union, replacing the NIS1 Directive. It expands the scope of affected organizations, including many in the automotive industry. The automotive industry recognized the need for industry-wide information and cybersecurity and developed the TISAX Assessment standard and its underlying ISA requirements catalogue. The purpose of this analysis is to demonstrate that TISAX assessments, based on ISA6, can be considered proof of compliance with NIS2 requirements.

  • Purpose of Analysis: To assist companies in the automotive industry in assessing whether TISAX compliance covers NIS2 requirements.
  • Scope of Analysis: Focuses exclusively on NIS2 Directive requirements with specific implementation guidelines for companies. It does not provide implementation assistance or confirm a company’s readiness for NIS2 outside of TISAX. Country-specific implementations and additional material requirements are not covered.
  • Target Audience: Experts from companies affected by NIS2 that use or undergo TISAX assessments, and authorities responsible for NIS2 compliance and supervision.

2. TISAX Assessment and Underlying Catalogue of Requirements (ISA6)

TISAX assessments, conducted by independent auditors in a three-year cycle, are based on ISA catalogue version 6 (ISA6). A critical distinction is made between TISAX scope definition and ISO management system certifications:

  • TISAX Assessment Scope: Utilizes a generally defined standard scope, ensuring comparability and a similar level of security across companies. This contrasts with ISO/IEC 27001, where the audited organization defines its ISMS scope. For the conclusions of this document to apply, TISAX Assessment objectives must reflect the company’s overall risk, and all NIS2-affected sites must have corresponding TISAX labels.
  • TISAX Assessment Objectives: Allow for scaling the assessment content based on risk and criticality of information processed (e.g., Confidential, Strictly Confidential, High Availability, Very High Availability, Data, Special Data, Prototype Protection).
  • TISAX Assessment Levels (AL):AL 1: Self-assessment, auditor checks completion, low confidence, not used in TISAX.
  • AL 2: Auditor performs plausibility check of self-assessment, checks evidence, conducts interviews (usually web conference).
  • AL 3: Comprehensive review, auditor verifies documents, conducts planned and unplanned interviews, observes implementation, and considers local conditions. Generally takes place on-site at all locations.
  • If multiple objectives are used, the highest AL is applied to the overall assessment.
  • TISAX Group Assessments (Simplified Group Assessment – SGA): Designed for companies with many locations and a centralized, highly developed ISMS.
  • S-SGA (Sample-based): Main site extensively assessed, sample sites assessed, other sites assessed at one AL lower.
  • R-SGA (Rotating Schedule-based): Main site extensively assessed, other locations assessed at the same AL but distributed over the three-year validity period. Not available for prototype protection objectives.
  • TISAX Control Questions and Requirements:Requirements are categorized (Must, Should, Additional requirements for high protection needs, Additional requirements for very high protection needs, Additional requirements for SGA).
  • “Must” requirements are strict, “Should” allows for justified deviations.
  • Additional requirements are subdivided by protection objectives (Confidentiality (C), Integrity (I), Availability (A)).
  • Individual control questions cannot be excluded as “not applicable”; they must be implemented holistically.
  • Deviations in TISAX Model: TISAX includes a maturity model (six levels, target is “established”) to assess practical implementation. Identified deviations require corrective action plans with defined implementation periods (up to 3, 6, or 9 months). Failure to correct deviations results in a failed audit.
  • Validity Period: TISAX assessments are valid for three years. Companies must continuously implement specified measures, conduct regular internal audits, and report significant changes affecting the ISMS or physical conditions, potentially requiring interim assessments.

3. NIS2 Article 20: Governance and Training

NIS2 Article 20 focuses on the governance body’s responsibility for cybersecurity risk management and their participation in relevant training.

  • NIS2 Article 20 (1): Governing Body’s Role in Risk Management: Requires the governing body to establish and monitor structures for cybersecurity risk management.
  • TISAX Fulfilment: Fully covered by ISA6 controls (1.2.1, 1.2.2, 1.4.1, 1.5.1, 1.5.2, 7.1.1). These controls check for defined ISMS scope, determined requirements, management commissioning and approval of ISMS, communication channels, regular reviews of ISMS effectiveness, defined responsibilities, resource availability, adequate security structure, qualified employees, conflict of interest avoidance, regular risk assessments, risk classification and allocation, security risk handling, compliance verification, independent ISMS reviews, and consideration of regulatory/contractual provisions.
  • Summary: “The requirement that the governing body of an organization has created appropriate structures to implement and monitor the implementation of the cybersecurity risk management measures taken to comply with Article 21 (NIS2 Article 20 (1)) is described by the controls defined in the ISA6 assessment standard and is fully checked for existence and implementation by the responsible auditor within a TISAX assessment.” The three-year TISAX cycle is considered appropriate given NIS2’s risk-based approach.
  • NIS2 Article 20 (2): Training for Governing Body and Relevant Members: Requires regular training for governing body members and other relevant individuals to acquire sufficient knowledge and skills in cybersecurity risk identification, assessment, and management.
  • TISAX Fulfilment: Checked by ISA6 control 2.1.3 (“To what extent is staff made aware of and trained with respect to the risks arising from the handling of information?”). This includes comprehensive training for all employees (including management), an awareness training concept covering relevant areas, consideration of target groups, regular execution, and documentation of participation.
  • Summary: While ISA does not explicitly list “management body” for training, it mandates training for “all employees” and differentiation by “target group,” implicitly covering management. This ensures the requirements of NIS2 Article 20 (2) are met.

4. NIS2 Article 21: Risk Management Measures

NIS2 Article 21 mandates appropriate and proportionate technical, operational, and organizational measures to manage risks to network and information systems.

  • NIS2 Article 21 (1): General Measures for Risk Management: Requires appropriate and proportionate measures to manage risks and minimize incident impact, considering the state of the art and implementation costs.
  • TISAX Fulfilment: Covered by ISA6 controls 1.2.1 (“To what extent is information security managed within the organization?”) and 1.4.1 (“To what extent are information security risks managed?”). These check for defined ISMS scope, determined requirements, existence and regular updating of risk assessments, assignment of risk owners, and action plans for risks.
  • Summary: “The requirements of NIS2 Article 21 (1) are described by the controls defined in the ISA6 assessment standard and are checked for existence and implementation by the auditor responsible during a TISAX assessment.” The TISAX assessment ensures a risk-based approach tailored to the company’s circumstances.
  • NIS2 Article 21 (2) a) – j): Specific Measures: These sub-articles detail specific areas for cybersecurity measures.
  • a) Policies on Risk Analysis and Information System Security: Fully covered by ISA6 controls 1.4.1, 5.2.7, 5.3.1, checking for procedures to identify, assess, and address risks, network management requirements, and information security consideration in new/developed IT systems.
  • b) Incident Handling: Fully covered by ISA6 controls 1.6.1, 1.6.2, checking for definition of reportable events, reporting channels, communication strategies, and incident processing procedures (categorization, qualification, prioritization, response, escalation). “The processes for detection, reporting channels and procedures, classification, processing and escalation (if necessary), go beyond the requirements stipulated in NIS2.”
  • c) Business Continuity, Backup Management, Disaster Recovery, Crisis Management: Fully covered by ISA6 controls 1.6.3, 5.2.8, 5.2.9, checking for crisis management preparedness, IT service continuity planning, and backup/recovery of data and IT services.
  • d) Supply Chain Security: Fully covered by ISA6 controls 1.2.4, 1.3.3, 1.6.1, 1.6.2, 1.6.3, 5.3.3, 6.1.1, 6.1.2. This includes defining responsibilities with external IT service providers, ensuring use of evaluated services, incident reporting and management from external parties, secure removal of information from external services, ensuring information security among contractors and partners, and contractual non-disclosure agreements. “The requirements in the ISA6 assessment standard go beyond the requirements of NIS2 and additionally include, for example, compliance with information security standards beyond the direct providers or service providers.”
  • e) Security in Network and Information Systems Acquisition, Development, and Maintenance (including vulnerability handling): Fully covered by ISA6 controls 1.2.3, 1.2.4, 1.3.4, 5.2.1, 5.2.4, 5.2.5, 5.2.6, 5.3.1, 5.3.2, 5.3.3, 5.3.4. This extensive coverage includes considering information security in projects, responsibilities with external IT service providers, approved software usage, change management, event logging, vulnerability identification and addressing, technical checks of IT systems, security in new/developed IT systems, network service requirements, and information protection in shared external services. “The assessment goes beyond the requirements of NIS2 by considering the return and secure removal of information assets from IT services outside the organization.”
  • f) Policies and Procedures to Assess Effectiveness of Cybersecurity Risk-Management Measures: Fully covered by ISA6 controls 1.2.1, 1.4.1, 1.5.1, 1.5.2, 1.6.2, 5.2.6, checking for regular review of ISMS effectiveness by management, up-to-date risk assessments, regular compliance checks, independent ISMS reviews, continuous improvement based on security events, and regular technical audits of IT systems and services. The three-year cycle is considered appropriate.
  • g) Basic Cyber Hygiene Practices and Cybersecurity Training: Covered by a wide range of ISA6 controls (1.1.1, 2.1.2, 2.1.3, 4.1.3, 4.2.1, 5.1.1, 5.1.2, 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, 5.2.6, 5.2.7, 5.2.8, 5.2.9, 5.3.1, 5.3.2, 5.3.3, 5.3.4). This includes information security policies, contractual obligations for staff, comprehensive training, secure management of user accounts/login info, access rights management, cryptographic procedures, information protection during transfer, change management, separation of environments, malware protection, event logging, vulnerability management, technical audits, network management, continuity planning, backup/recovery, and secure handling of information assets.
  • h) Policies and Procedures Regarding Cryptography and Encryption: Fully covered by ISA6 controls 5.1.1, 5.1.2, checking for adherence to industry standards, technical rules, lifecycle management of cryptographic keys, key sovereignty, and protection of information during transfer (including encryption).
  • i) Human Resources Security, Access Control Policies, and Asset Management: Fully covered by a comprehensive set of ISA6 controls (1.3.1, 1.3.2, 1.3.3, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 3.1.3, 3.1.4, 4.1.1, 4.1.2, 4.1.3, 4.2.1, 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, 5.2.6, 5.2.7, 5.2.8, 5.2.9). This includes identification and classification of information assets, use of approved external IT services, employee qualification for sensitive roles, contractual obligations, training, mobile work regulations, handling of supporting assets, mobile device management, identification means management, user access security, user account/login info management, access rights, change management, separation of environments, malware protection, event logging, vulnerability management, technical audits, network management, continuity planning, and backup/recovery.
  • j) Multi-factor Authentication, Continuous Authentication, Secured Communications, and Emergency Communication Systems: Fully covered by ISA6 controls 1.6.3, 4.1.2, 4.1.3, 5.1.2, 5.2.8. This involves crisis planning for communication, user authentication procedures (including strong authentication/MFA for privileged accounts), secure management of user accounts/login info, protection of information during transfer (secure voice/video/text communication), and continuity planning that includes alternative communication strategies.
  • NIS2 Article 21 (4): Immediate Corrective Measures for Non-Compliance: Requires immediate necessary, appropriate, and proportionate corrective measures upon awareness of non-compliance with Article 21 (2) measures.
  • TISAX Fulfilment: Fully covered by ISA6 controls 1.5.1, 1.5.2, checking for verification of policy observation, regular review of policies/procedures, documented results, regular compliance checks, and initiation/pursuit of corrective measures based on internal and independent reviews. The three-year cycle is deemed appropriate.

5. NIS2 Article 23: Incident Reporting

NIS2 Article 23 outlines requirements for reporting security incidents.

  • NIS2 Article 23 (1): Notification of Significant Security Incidents: Essential and important entities must notify their CSIRT or competent authority without undue delay of significant security incidents. Recipients of services must also be informed immediately. Information enabling cross-border impact determination must be provided.
  • TISAX Fulfilment: Almost fully met by ISA6 controls 1.6.1, 1.6.2. These check for defined reportable events, known reporting mechanisms based on severity, available reporting channels, handling of events by category, knowledge of reporting obligations and contact information, and communication strategies.
  • Summary: “One exception here is the disclosure of cross-border effects, which is not explicitly required within the ISA. It has already been defined here that emergency communication must be expanded to include the specifications from NIS2. Once this extension has been considered, the requirements are fully met.”
  • NIS2 Article 23 (2): Communication of Remedial Actions to Recipients: Entities must promptly communicate to affected recipients any measures or remedial actions they can take in response to a significant cyber threat, and inform them of the threat itself.
  • TISAX Fulfilment: Covered by ISA6 control 1.6.2. This includes categorization, qualification, and prioritization of reported events, appropriate responses, and communication strategies considering target recipients and reporting periods.
  • Summary: “The explicit contact information, reporting channels and languages must be included in the Business Continuity Management (BCM) by the companies following their publication by the EU member states. The auditor cannot guarantee that this information is available, as the information to be included is company-specific and can therefore take a variety of forms.”
  • NIS2 Article 23 (3): Definition of Significant Security Incident: Provides an informative definition (serious disruption or financial/material/immaterial damage).
  • TISAX Fulfilment: Purely informative, no assessable measures.
  • NIS2 Article 23 (4): Reporting Timelines and Content: Specifies detailed reporting timelines (early warning within 24 hours, incident notification within 72 hours, intermediate reports, final report within one month).
  • TISAX Fulfilment: Covered by ISA6 controls 1.6.1, 1.6.2, 1.6.3. These check for defined reportable events, mechanisms based on severity, accessible reporting channels, obligation to report, feedback procedures, categorization/prioritization, maximum response times, escalation, and crisis communication strategy.
  • Summary: “In addition to the knowledge and existence of the necessary reporting channels and deadlines, the ISA standard also requires the establishment of crisis-proof communication. At this point, the requirements of the ISA go beyond the requirements of NIS2.” Similar to 23(2), explicit contact information and channels are company-specific and not directly assessed by TISAX.
  • NIS2 Article 23 (5-11): No explicit demands on affected companies requiring preparatory measures.

6. NIS2 Article 24

  • NIS2 Article 24 (1): No explicit demands on affected companies that require preparatory measures.
  • TISAX Fulfilment: No assessable measures.

7. NIS2 Article 25: European and International Standards

NIS2 Article 25 addresses the application of European and international standards for network and information system security.

  • TISAX Fulfilment: “The requirements of NIS2 Article 25 to use European and international standards and technical specifications for the security of network and information systems to ensure the implementation of the requirements for companies resulting from NIS2 are met by an audit of an organization’s ISMS carried out in accordance with TISAX, as this report demonstrates.” No explicit demands for preparatory measures are made on companies.

8. NIS2 Articles 22, 26-29

  • NIS2 Article 22: Coordinated Risk Assessments for Critical Supply Chains: No specific requirements for companies, not considered further in this report.
  • NIS2 Articles 26-28 (Jurisdiction, Register of Entities, Domain Name Registration Data): No measures to be examined for companies, not considered in this document.
  • NIS2 Article 29: Exchange of Cybersecurity Information: “The requirements of NIS2 Article 29 are not assessed within the TISAX assessment.”

9. Overall Summary and Conclusion

The “NIS2 fulfilment through TISAX” document strongly asserts that TISAX assessments, based on the ISA requirements catalogue, provide comprehensive evidence that companies meet the material requirements of the NIS2 Directive.

  • State of the Art: ISA and TISAX are considered “state of the art” for information and cybersecurity in the automotive industry due to their continuous development by experts, application by thousands of companies, and resulting knowledge gain.
  • Management Responsibility and Risk Management: A TISAX label indicates that the management of an assessed company fulfills the responsibility required in NIS2 Article 20 and has implemented all state-of-the-art risk management measures of Article 21, provided the assessment objectives reflect overall risk and all NIS2-affected sites were included.
  • Audit Cycle: The three-year TISAX audit cycle is deemed appropriate, even compared to the two-year cycle for critical infrastructure operators under German law, due to the continuous monitoring and documentation obligations within the cycle.
  • Preparation for NIS2: Companies with a valid TISAX label are “well positioned to meet the requirements of the NIS2 directive in these areas.”
  • Reporting Requirements: TISAX provides proof of established mechanisms for mandatory reporting to authorities and customers. However, companies are responsible for integrating country-specific additional requirements and verifying them against implemented measures.

In essence, TISAX is presented as a robust framework that aligns with and often exceeds the cybersecurity requirements set forth by NIS2 for the automotive sector.

 

 

The post NIS2 Fulfillment through TISAX Assessment and ISA6 first appeared on Sorin Mustaca’s blog.

Understanding Defense in Depth in IT Security

/in

The recent outage caused by Crowdstrike’s faulty update has create a lot of discussions. I wrote a post on LinkedIn where I asked the readers why are IT professionals using Crowdstrike on some systems that shouldn’t be in need of such protection in the first place.

The answers in various groups were mostly related to:

  • protect everything against everyone
  • assume the worse
  • assume that you are compromised.

I do not agree with such a shallow answer. And this raises a question about Defense in Depth.

Defense in Depth

Defense in Depth is a cybersecurity strategy that employs multiple layers of security controls to protect an organization’s assets and information. This approach is based on the premise that no single security measure is foolproof. By implementing several layers of defense, even if one control fails, others are in place to mitigate risks. The concept is inspired by military defense strategies, where a series of defensive positions are used to delay or prevent an attack.

A common misconception about Defense in Depth is that it requires identical security measures across all layers of an IT environment. In reality, this is neither necessary nor practical. Different layers have different requirements based on their specific functions, vulnerabilities, and the types of threats they are exposed to. Applying the same controls universally can lead to inefficiencies, increased costs, and potential performance issues.

In my opinion, this is what happened in many cases during the Crowdstrike outage: admins installed the EDR solution simply on all available devices, without doing an analysis of the threats they are exposed to. This is called threat modeling, and the first step after identifying the assets to protect is to analyze their threat landscape: this is the set of threats they are potentially exposed to. Once the potential threats are identified, then the appropriate security controls can be defined. But, it is important that the right controls are used based on the risk level of the potential threat. The mistake here is that people try to protect against any potential risk, no matter how improbable it might be. So, it is not worth to protect against every potential risk.

But, this operation is, at least at first sight, expensive, time consuming and very few people know how to do it.

So, what happens in most cases is that people consider to be cheaper to buy additional licenses and accept easily a slight reduction in performance due to the tool monitoring everything (“throw” more hardware on it).

And this might be OK, if everything works perfect all the time. Well, it doesn’t !

If this sounds too theoretical, then let’s have a closer look at various layers where applications run.

  • Running at the Web Application Layer: This layer might need strong authentication mechanisms, input validation, and encryption to protect against web-based attacks such as SQL injection or cross-site scripting (XSS).
  • Running at the Network Layer: Here, firewalls, intrusion detection systems (IDS), and virtual private networks (VPNs) are more appropriate to guard against network-based threats like DDoS attacks or unauthorized access.
  • Running at the Endpoint Layer: Devices such as laptops and mobile phones might require antivirus software, device encryption, and endpoint detection and response (EDR) solutions to prevent malware infections and data breaches.

Each layer of security addresses different risks, and the controls should be tailored to the specific threats and the environment.

For instance, a high-value database containing sensitive customer information might warrant multiple layers of encryption, strict access controls, and regular auditing. In contrast, a low-value, non-critical application might only require basic security measures.

Of course, there are applications having parts that run on more than one layer. When this happens, then you must correctly create the threat model and identify the risks at each layer.

For example, if you have a computer which just displays flights schedules, without having an interaction with the exterior other than retrieving data from an internal webservice, you probably do not need a dedicated endpoint security product for it.

Why? Because you will not allow access to the machine other than the service account for patches and running the required software.

If you’re unsure, and the machine runs Windows, than the default Defender is more than enough.

Create a Threat Model for your endpoints

If you don’t know how to create a threat model for an endpoint (and not only Windows, MacOS and Linux are equally affected), here is a list of potential threats and their mitigations.

Important note:
If you apply correctly the principles of Defense in Depth, you will NEVER all all these potential risks applicable to your devices.

Even if you remotely consider that some or all these risks can occur, do not forget that the Risk is proportional to the Probability of occurrence and Impact effect:

  • Probability of occurrence – what are the chances that the risk actually occurs: Very probably, Probably, Sometimes, Unlikely, Never.
  • Impact effect: Catastrophic, Very high, High, Medium, Low.

Potential Risks on an Endpoint

  • Malware Infections

    • Risk: Viruses, Trojans, ransomware, spyware, and other malicious software can compromise the system.
    • Security Controls:
      • Antivirus/anti-malware software
      • Regular system scans and updates
      • Application whitelisting
      • Sandboxing suspicious files
      • Backup with versioning control (good for ransomware attacks)

  • Unpatched Software

    • Risk: Vulnerabilities in outdated software can be exploited by attackers.
    • Security Controls:
      • Automated patch management systems with rollback functionality
      • Regular software updates
      • Vulnerability scanning tools
      • Centralized patch distribution

  • Unauthorized Access

    • Risk: Unauthorized users may gain access to the endpoint, leading to data breaches or system compromise.
    • Security Controls:
      • Strong password policies
      • Multi-factor authentication (MFA)
      • User account control (UAC)
      • Role-based access controls (RBAC)

  • Data Theft

    • Risk: Sensitive data may be copied, transmitted, or stolen from the endpoint.
    • Security Controls:
      • Full disk encryption (e.g., BitLocker)
      • Data loss prevention (DLP) tools
      • USB port control and removable media encryption
      • Secure backup solutions

  • Physical Theft

    • Risk: The endpoint itself may be physically stolen, leading to loss of data and access to the network.
    • Security Controls:
      • Physical security measures (locks, secure storage)
      • Device tracking and remote wipe capabilities
      • Full disk encryption
      • BIOS/UEFI passwords

  • Drive-by Downloads

    • Risk: Malicious websites may automatically download and install malware without user consent.
    • Security Controls:
      • Web filtering and browser security plugins
      • Regular updates to browsers and plugins
      • Application whitelisting
      • Disabling automatic execution of scripts in browsers

  • Network-based Attacks

    • Risk: Attackers may exploit vulnerabilities in the network to compromise the endpoint.
    • Security Controls:
      • Personal firewall
      • Network segmentation
      • Secure VPN connections
      • Intrusion detection and prevention systems (IDPS)

  • Misconfigured Security Settings

    • Risk: Insecure configurations can leave the endpoint vulnerable to attacks.
    • Security Controls:
      • Regular security audits and compliance checks
      • Hardening guides and best practices (e.g., CIS benchmarks)
      • Group policies for centralized management
      • Security baselines and templates

Potential Human Risks

Phishing Attacks

  • Risk: Users may be tricked into divulging sensitive information or downloading malicious software through deceptive emails or websites.
  • Security Controls:
    • Email filtering with anti-phishing capabilities
    • User awareness training
    • Web filtering and reputation services
    • Multi-factor authentication (MFA)

Insider Threats

  • Risk: Malicious or negligent insiders may intentionally or unintentionally cause harm.
  • Security Controls:
    • User activity monitoring and logging
    • Least privilege principle
    • Endpoint detection and response (EDR)
    • Insider threat detection tools

Instead of conclusion: Balancing Security and Usability

The most critical aspect of Defense in Depth is balancing security and usability.

Over-securing can lead to decreased productivity, increased costs, and user dissatisfaction.

For instance, implementing multi-factor authentication (MFA) at every step might significantly slow down legitimate users, leading to frustration and potential workarounds that can undermine security.

A well-designed Defense in Depth strategy finds the right balance by applying strict controls where necessary and lighter measures where the risk is lower.

The goal is to create a robust security posture that protects against a wide range of threats without overburdening the system or its users.

 

The post Understanding Defense in Depth in IT Security first appeared on Sorin Mustaca on Cybersecurity.

Balancing functionality and privacy concerns in AI-based Endpoint Security solutions

/in

The integration of Artificial Intelligence (AI) in endpoint security has revolutionized the way organizations protect their devices and data.

Ok, let’s take a break here: have you read the article about Artificial Intelligence vs. Machine Learning ?

 

By leveraging AI and machine learning models that analyze user behavior on devices, organizations can detect anomalies and potential security threats more effectively.

However, this advanced approach to endpoint security raises significant privacy concerns, as it necessitates the collection of user activity data, sometimes in real time.

One thing needs to be clear: if you want to do anomaly detection, you need to train your ML model with what “normal” is first – this is called “baseline”. And this means that data needs to be collected from the user.

Now the question remains, how can we reduce the privacy concerns?

This short article explores the privacy challenges I think are associated with using AI models that require user data(behavior), discusses potential solutions, and suggests ways to deploy AI on devices while minimizing privacy concerns.

What are the privacy concerns when data is collected for training an ML model?

Data Collection and Usage


Collecting user data for AI-driven endpoint security involves monitoring and logging user activities on devices.

This process includes:

  • capturing information about the applications used (URLs accessed, CPU usage, memory usage),
  • websites visited and items clicked
  • files accessed
  • applications installed
  • applications started
  • time of login, logout, inactivity
  • webcam usage
  • microphone usage
  • biometrics

This data is essential for creating baselines of normal behavior and identifying deviations that might indicate security threats.

This extensive data collection raises concerns about user privacy, as it creates a comprehensive profile of a user’s digital activities.

AI-based endpoint security solutions can infer or predict sensitive information from non-sensitive forms of data, such as user preferences, interests, or behaviors.

This can enable the systems to provide personalized or customized services or recommendations, but it can also violate the privacy or autonomy of the users or the owners of the devices or networks.

For example, someone’s keyboard typing patterns can be analyzed to deduce their emotional state, which includes emotions such as nervousness, confidence, sadness or anxiety

 

Data Security

Safeguarding the collected user data is critical, as it contains sensitive information about an individual’s online behavior.

The risk of data breaches or unauthorized access to this information poses a significant privacy threat.

Where is this data stored, how long, how is it stored, who has access to it, how is it going to be used/processed and by who, are just a few questions that need to be asked.

GDPR has made clear which are the responsibilities of the controller and processor(s) of the data.

 

Transparency and Consent

A good user experience of a security product means that users will be as unaware as possible that their activity data is being collected for security purposes.

Ensuring transparency and obtaining explicit user consent for data collection is critical. Without clear communication, users may feel their privacy is being violated.

 

Data Retention

Storing user data indefinitely can compound privacy concerns. Organizations should establish clear data retention policies, specifying how long the data will be retained and under what circumstances it will be deleted.

 

User Profiling and Discrimination

The detailed user activity data collected for AI analysis can lead to user profiling, which may be used for purposes beyond cybersecurity, such as targeted advertising.

AI-based endpoint security solutions can make automated decisions or recommendations based on the data they analyze, such as blocking access, flagging anomalies, or prioritizing alerts.

Discriminatory decisions and practices can arise from the insights drawn from user behavior data. However, these decisions or recommendations can be discriminatory, unfair, inaccurate, or biased, if the data or the algorithms are flawed, incomplete, or skewed.

For example, people can be misclassified, misidentified, or judged negatively, and such errors or biases may disproportionately affect certain demographics.

 

Solutions to address privacy concerns

The solutions to address these concerns are actually not new, they are covered pretty good by the GDPR and other privacy laws world-wide.

They are :

Data Minimization

Organizations should adopt a data minimization approach, collecting only the data necessary for security purposes.  This is definitely not as easy as it sounds.

In Security, you usually collect as much as possible, because the more you know about your target, the better it is for the ML model (better detection, less false positives).

However, the Compliance dept. should be involved from the early stages of developing the product in order to control what is being collected.

 

Anonymization

Anonymizing user data can be a privacy-enhancing technique. By removing personally identifiable information from collected data, the risk of individual users being identified is reduced.

This works good when data is collected from many computers, but when the solution works on a single computer, it usually needs time to “learn” the user’s behavior.

There is nothing anonymous there and this is usually OK, as long as this data is not sent to the backend for further processing and analysis.

 

Encryption

Encrypting the data collected for AI analysis ensures that even if a breach occurs, the information remains unreadable and inaccessible to unauthorized parties.

When “cleaned up” data needs to be sent, it is mandatory to send it encrypted and keep it at rest encrypted all the time.

 

Informed consent

Transparently informing users about data collection and obtaining their explicit consent is a fundamental step in addressing privacy concerns.

Users should have the option to opt in or out of data collection at any time. It is mandatory for the ML models to be able to cope without any datasets, because they could disappear at any time.

 

Data deletion

After the data is no longer needed for security analysis, organizations can ideally erase the data, and if this is not possible, then it should remove any direct or indirect associations with individual users.

Balancing Security and Privacy

Balancing AI-based endpoint security and privacy is essential. Organizations can adopt the following strategies to minimize privacy concerns:

  • Implement Strong Privacy Policies

Establish comprehensive privacy policies that clearly define data collection, usage, retention, and disposal procedures. These policies should adhere to legal and regulatory requirements for the region where the users reside (GDPR, CPA, etc.).

This can by itself be a challenging task, because no company is willing to block access to potential customers.

 

  • Regular risk assessment and impact analysis

Conduct periodic risk assessment and impact analysis to ensure that data collection and analysis practices align with privacy policies and legal requirements and correct any deviations promptly.

The audits should be first performed internally, in order to have time to fix any deviations. If an external audit body finds any irregularity, the company can be fined with large sums of money.

 

  • Third-Party Vetting

When using third-party AI solutions, organizations should thoroughly vet the security and privacy practices of these providers.

 

  • Ongoing Monitoring

Continuously monitor the effectiveness of privacy protection measures and adjust them as needed to address emerging privacy concerns.

 

Conclusion

AI-based endpoint security is a powerful tool for protecting devices and data from cyber threats. However, it should not come at the cost of user privacy or well-being.

Organizations must strike a delicate balance by implementing privacy-enhancing measures, obtaining informed consent, and adhering to transparent data collection and usage practices.

 

 

PS: The image of the post was generated using DALL-E.

 

The post Balancing functionality and privacy concerns in AI-based Endpoint Security solutions first appeared on Sorin Mustaca on Cybersecurity.

Strengthening the Security of Embedded Devices

/in

Embedded devices are specialized computing systems designed to perform specific tasks or functions within a larger system. Unlike general-purpose computers, embedded devices are typically integrated into other devices or systems and are dedicated to carrying out a specific set of functions. They are often characterized by their compact size, low power consumption, and optimized performance for their intended application.

Embedded devices can be found in various domains and industries, including consumer electronics, automotive, healthcare, industrial automation, telecommunications, and IoT (Internet of Things). Examples of embedded devices include:

  1. Smartphones and tablets: These devices integrate multiple functionalities such as communication, multimedia, and internet access into a portable form factor.
  2. Home appliances: Devices like refrigerators, washing machines, and thermostats may contain embedded systems that control their operations and offer smart features.
  3. Industrial control systems: Embedded devices are widely used in manufacturing plants and industrial environments to monitor and control processes, machinery, and equipment.
  4. Automotive systems: Embedded devices are essential components in modern vehicles, managing functions such as engine control, entertainment systems, safety features, and navigation.
  5. Medical devices: Embedded systems are utilized in various medical equipment, such as patient monitoring devices, implantable devices, and diagnostic tools.
  6. IoT devices: These are interconnected devices that gather, transmit, and process data. Examples include smart home devices, wearable devices, and environmental sensors.

Embedded devices typically consist of hardware components (such as microprocessors, memory, and sensors) and software (including operating systems, firmware, and application software) tailored to perform specific tasks efficiently. They are designed to operate reliably in often resource-constrained environments and are subject to specific security and safety considerations based on their application domain.

Overall, embedded devices serve as the backbone of numerous technological advancements, enabling automation, connectivity, and enhanced functionality in various sectors.

Embedded devices have become an integral part of our daily lives, powering everything from smartphones and smart home devices to critical infrastructure and industrial systems. However, their proliferation also brings forth significant security concerns. Ensuring the security of embedded devices is of paramount importance to protect against potential vulnerabilities and mitigate the risks of cyber threats. This article explores the key challenges surrounding the security of embedded devices and highlights the measures needed to fortify their defenses.

The Unique Security Challenges:
Embedded devices face several unique security challenges that differentiate them from traditional computing systems:

1. Resource Constraints: Many embedded devices have limited computational power, memory, and energy resources. This poses challenges in implementing robust security mechanisms without impacting the device’s performance or battery life.

2. Long Lifecycles: Embedded devices often have long lifecycles, meaning they remain in operation for extended periods. Ensuring security over such durations necessitates proactive measures, including regular software updates and patch management.

3. Diverse Ecosystems: Embedded devices interact with a diverse range of software and hardware components, creating a complex ecosystem that requires careful consideration of security across all layers, from hardware to firmware and software.

Enhancing Security in Embedded Devices:
To bolster the security of embedded devices, the following measures should be implemented:

1. Secure Booting: Enforcing secure booting mechanisms ensures that only trusted and authenticated software components are loaded during the boot process. This prevents the execution of unauthorized or malicious code, establishing a foundation of trust in the device’s software stack.

2. Code and Data Encryption: Implementing strong encryption algorithms safeguards sensitive data stored on embedded devices, as well as the communication channels they utilize. Encryption helps protect against unauthorized access and data breaches, ensuring the confidentiality and integrity of the device and its data.

3. Robust Authentication: Strong authentication mechanisms, such as multifactor authentication or biometrics, should be employed to verify the identity of users or external systems attempting to access or interact with the device. This prevents unauthorized access and reduces the risk of compromise.

4. Regular Software Updates: Timely and regular software updates are crucial for patching security vulnerabilities and addressing emerging threats. Embedded device manufacturers should provide updates throughout the device’s lifecycle, ensuring that security patches and fixes are deployed promptly.

5. Secure Communications: Implementing secure communication protocols, such as Transport Layer Security (TLS) or Virtual Private Networks (VPNs), protects data transmitted between embedded devices and external systems, safeguarding against interception and tampering.

6. Vulnerability Management: Regular vulnerability assessments and penetration testing should be conducted to identify and address potential weaknesses in embedded devices. This proactive approach helps identify and remediate vulnerabilities before they can be exploited by attackers.

7. Secure flashing: regular software updates don’t bring too much if there are no mechanisms to ensure that the updates are authentic. This mechanisms checks that the delivered updates are signed by the producer of the device and therefor secure to deploy.

We will be addressing in several articles some of these unique challenges they present : secure booting, implementing encryption and authentication, software updates, secure flashing, secure communications, vulnerability management.

 

The post Strengthening the Security of Embedded Devices first appeared on Sorin Mustaca on Cybersecurity.

Preventing Attacks and Securing the Supply Chain in the Security Software Industry

/in

The security software industry plays a vital role in safeguarding sensitive data and protecting digital infrastructure.

However, the industry itself faces a significant threat from supply chain attacks.

Supply chain attacks occur when cybercriminals target vulnerabilities within the supply chain to compromise software or hardware products before they reach the end-users.

By infiltrating the supply chain, attackers can inject malicious code, backdoors, or vulnerabilities, thereby compromising the security of the software.

Such attacks can have far-reaching consequences, as they can compromise the confidentiality, integrity, and availability of critical systems and data.

These attacks have the potential to undermine the integrity and trustworthiness of security software, leading to severe consequences for individuals, organizations, and even nations.

This article examines the damaging impact of supply chain attacks on the security software industry, while also delving into preventive measures and strategies to secure the supply chain.

 

Impact:

  1. Loss of Trust: Supply chain attacks erode trust in security software products and the industry as a whole. When high-profile incidents occur, customers may lose confidence in the ability of software vendors to protect their assets and data.
  2. Financial Loss: The costs associated with supply chain attacks are staggering. Companies suffer significant financial losses due to reputational damage, legal consequences, customer compensation, and the costs of investigating and mitigating the attack.
  3. Weakened Defenses: A compromised security software product can result in weakened defenses for individuals, organizations, and governments, leaving them vulnerable to further cyberattacks. This situation can have severe consequences, particularly when critical infrastructure or national security is at stake.

 

Preventing Attacks:

  1. Enhanced Vendor Due Diligence: Organizations should thoroughly vet and assess the security practices of their software vendors and suppliers. This includes scrutinizing their security measures, incident response plans, and third-party audits.
  2. Secure Development Practices: Implementing secure software development practices, such as code review, vulnerability testing, and penetration testing, can help identify and rectify potential weaknesses in software products.
  3. Strong Authentication and Encryption: Implementing robust authentication mechanisms and encryption protocols helps protect the integrity and confidentiality of software and its supply chain components.
  4. Regular Updates and Patching: Ensuring timely and regular updates and patches are applied to software products and their supply chain components helps address known vulnerabilities and protect against emerging threats.

 

Mitigations:

  1. End-to-End Visibility: Organizations must have comprehensive visibility into their supply chain, including the identification of all suppliers and the ability to monitor their security practices throughout the software development lifecycle.
  2. Supply Chain Risk Assessment: Conducting a thorough risk assessment helps identify potential vulnerabilities and risks within the supply chain. This assessment should encompass all stages, from design to distribution, and involve evaluating suppliers, their security practices, and their access controls.
  3. Supplier Contracts and Agreements: Organizations should establish clear contractual agreements with suppliers that define security requirements, incident response protocols, and breach notification obligations. Regular audits and assessments can help ensure compliance.
  4. Incident Response Planning: Developing and regularly testing an incident response plan specific to supply chain attacks enables organizations to respond swiftly and effectively, mitigating the impact of any potential breach.

 

Supply chain attacks pose a significant threat to the security software industry, compromising the integrity and trustworthiness of software products. The damaging consequences include loss of trust, financial losses, and weakened defenses. However, by implementing preventive measures, such as enhanced vendor due diligence, secure development practices, and regular updates, organizations can bolster their defenses against supply chain attacks. Additionally, securing the supply chain through end-to-end visibility, risk assessments, supplier contracts, and incident response planning.

 

If you want to know how to address Supply Chain issues, you can contact Endpoint Cybersecurity for a free consultation.

Supply Chain Management

 

 

The post Preventing Attacks and Securing the Supply Chain in the Security Software Industry first appeared on Sorin Mustaca on Cybersecurity.