Posts

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.

Navigating AI Standards and Regulations

/in

Note: This post is written with a lot of help from AI, used to summarize the standards mentioned below.

 

Artificial intelligence (AI) is reshaping industries, but it also brings new risks.

From security vulnerabilities to compliance challenges, organizations must balance innovation with responsibility.

New standards were created and newer are emerging to guide this effort, most notably ISO/IEC 42001, ISO/IEC 22989, NIST AI RMF and the EU AI Act.

Together, they define how we should understand, manage, and regulate AI.

 

The Standards: ISO/IEC 42001, ISO/IEC 22989, NIST AI Risk Management Framework (AI RMF)

ISO/IEC 22989 focuses on concepts and terminology. By standardizing the language around AI, it ensures consistency in communication between developers, regulators, and policymakers. It provides a shared foundation for technical and strategic discussions, making it easier to align projects and compliance efforts.

 

ISO/IEC 42001 sets the framework for an Artificial Intelligence Management System (AIMS). As if we didn’t have enough Management Systems (ISMS, CSMS, DRMS, etc.), now we have AIMS.

It provides requirements for organizations to govern AI responsibly throughout its lifecycle.

Much like ISO 27001 for information security, this standard enables organizations to implement repeatable processes, assign roles, manage risks, and continuously improve their AI practices.

In short, ISO/IEC 22989 tells us how to talk about AI, while ISO/IEC 42001 tells us how to manage it.

NIST AI Risk Management Framework (AI RMF) is developed by the National Institute of Standards and Technology.  It gives guidance on managing the risks of AI systems: trustworthiness, safety, fairness, explainability, etc.

NIST also works on “crosswalks” linking the AI RMF to international standards like ISO, OECD guidelines, etc.

 

The Regulation: EU AI Act

The EU AI Act goes beyond voluntary standards. It is a regulation with binding legal requirements for AI systems placed on the EU market.

The Act classifies AI systems by risk:

  • Unacceptable risk systems (e.g., manipulative or exploitative applications) are prohibited.
  • High-risk systems (e.g., AI in healthcare, critical infrastructure, recruitment) must meet strict conformity assessments, documentation, and testing requirements.
  • Limited and minimal risk systems face transparency obligations or no specific restrictions.

Unlike ISO standards, which are voluntary, the EU AI Act will be legally enforced. Non-compliance may lead to heavy fines and product bans.

 

Comparing Standards and Regulation

  • ISO/IEC 22989 provides consistent terminology.
  • ISO/IEC 42001 defines organizational governance for AI.
  • NIST AI RMF guidance on managing the risks of AI systems: trustworthiness, safety, fairness, explainability.
  • EU AI Act imposes legally binding obligations at the product and deployment level.

While ISO and NIST standards are process-driven and supportive, the EU AI Act mandates specific outcomes.

Organizations can use ISO/IEC 42001 to establish governance processes that make compliance with the EU AI Act easier, but certification alone does not replace the legal requirements.

U.S. standards tend to be voluntary or guidance-based, not binding across all states or businesses, unlike the EU AI Act. There is no single federal law with comprehensive AI regulation yet;

instead it’s a patchwork of executive orders, agency actions, state laws, and voluntary standards. The U.S. places strong emphasis on risk management frameworks, public-private collaboration, innovation, and aligning with international standards.

In the U.S. there are some more standards on AI like Center for AI Standards and Innovation (CAISI) and various initiatives and plans for AI systems. Also there are some state laws and regulations which require some large AI model developers to publicly disclose safety protocols and report certain kinds of risk or incidents (California SB 53).

 

Key Risks Introduced by AI

  1. Model drift and performance risk — AI systems degrade over time, causing hidden failures.
  2. Bias and discrimination — Training data can produce unfair outcomes, raising legal and ethical issues.
  3. Lack of explainability — Black-box models hinder audits, accountability, and trust.
  4. Data protection risks — Models may leak or memorize personal data, creating privacy concerns.
  5. Security vulnerabilities — Adversarial attacks, poisoning, and prompt injection threaten system integrity.
  6. Supply chain dependency — Reliance on third-party models introduces hidden weaknesses.
  7. Regulatory non-compliance — Misclassifying risk or skipping assessments can result in fines and reputational damage.

How Standards Address These Risks

  • ISO/IEC 22989 ensures clarity in measurement and reporting.
  • ISO/IEC 42001 and NIST AI RMF requires lifecycle controls, risk assessments, monitoring, and continuous improvement.
  • EU AI Act mandates transparency, testing, and conformity assessments tailored to specific use cases.

When combined, these frameworks help organizations create trustworthy AI systems while meeting regulatory demands.

 

The Next Level of Compliance

To reach the “next level” of compliance, organizations must integrate voluntary standards and mandatory regulation into one cohesive program:

  1. Adopt common terminology using ISO/IEC 22989 across all teams.
  2. Implement an AI management system aligned with ISO/IEC 42001.
  3. Map AI products against EU risk categories and prepare compliance checklists.
  4. Generate technical evidence such as model cards, data lineage, and test results.
  5. Automate monitoring and incident response to detect model drift and adversarial attacks.
  6. Integrate privacy engineering to ensure alignment with GDPR.
  7. Secure the AI supply chain by tracking third-party components and models.
  8. Prepare for external audits and conformity assessments, leveraging ISO processes as supporting evidence.

Compliance should not be treated as a static checklist. The future of responsible AI lies in continuous monitoring, automated governance, and embedding compliance into MLOps pipelines.

Conclusions

AI standards and regulations are converging to create a new compliance landscape.

ISO/IEC 22989 provides the vocabulary, ISO/IEC 42001 offers governance, and the EU AI Act enforces legal obligations.

Organizations that align with all three will not only reduce risk but also strengthen trust in their AI systems. The next level of compliance means going beyond certification—building AI practices that are transparent, secure, and continuously monitored.

The EU provides a strong, comprehensive, binding regulatory framework for AI with clear risk categories, prohibited uses, and enforcement.

The U.S. currently relies more on existing laws, executive orders, and sectoral regulation, giving more flexibility but less predictability.

For global players, achieving dual compliance is increasingly necessary. The trend suggests U.S. regulation will become stronger over time, potentially drawing from EU models.

 

The post Navigating AI Standards and Regulations 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.

AI vs. (secure) software developers

/in

I think the entire software development world saw NVIDIA’s CEO saying that the world will stop needing software developers, because they will be replaced by AI.

Well, considering that this comes from the guy who sells the core on which AI is built, is understandable.

But is there any truth to this? Let’s look at some Strengths and Weaknesses of AI in the field of software development, with focus on secure software development.

 

The Strengths of AI in Software Development

AI excels in automating repetitive tasks and processing vast amounts of data quickly. For example, AI-driven tools can:

  • Identify common vulnerabilities such as SQL injection or cross-site scripting (XSS) using pattern recognition.
  • Suggest code refactoring for improved efficiency or readability.
  • Provide automated testing and validation for specific use cases.
  • Generate code snippets that can speed up development, allowing developers to focus on complex, high-level tasks instead of repetitive tasks.
  • Perform static and dynamic code analysis faster than manual reviews, identifying potential issues across large codebases in a fraction of the time.
  • Offer predictive insights by analyzing historical data to anticipate possible security breaches or performance bottlenecks.
  • Facilitate compliance checks by mapping code against security standards and regulatory requirements.

These capabilities make AI invaluable for enhancing productivity and reducing the burden of mundane tasks. However, AI has limitations that highlight the irreplaceable role of skilled developers.

The Weaknesses of AI in Secure Software Development

  1. Lack of context understanding
    AI tools often struggle to grasp the context of a software system. Security vulnerabilities often stem from contextual issues, such as improper assumptions about user behavior or architectural flaws.
    Developers use their domain knowledge and intuition to identify these issues—something AI cannot replicate.
  2. Overreliance on patterns
    AI relies heavily on training data and pattern recognition. This approach can lead to false positives (flagging issues that aren’t real) and false negatives (missing actual vulnerabilities).
    Developers, on the other hand, use critical thinking to assess risks and prioritize fixes.
  3. Lack of creative problem-solving
    Secure software development often requires innovative solutions to unique problems.
    AI lacks the creativity and adaptability of humans, limiting its ability to design custom security measures.
  4. Ethical and legal implications
    AI cannot make ethical decisions or assess the broader implications of its suggestions.
    Developers with security expertise consider regulatory compliance, ethical concerns, and long-term impact when designing secure systems.
  5. Lack of continuous growth
    Unlike developers, whose experience grows continuously through exposure to new challenges, AI systems remain static unless explicitly retrained.
    Developers improve their skills, adapt to emerging threats, and learn from past experiences, ensuring they stay ahead of evolving security risks.
  6. Limited problem-solving scope
    AI knows only what it was trained with. This limitation means it struggles to address new or unconventional problems that fall outside its training data.
    Developers, by contrast, use their ingenuity and evolving expertise to find innovative solutions to emerging threats and challenges.

 

Examples of AI Mistakes

Here are some scenarios where AI is not mature enough, and developers with security skills excel:

  • Misidentifying Threats: An AI tool might flag a harmless API endpoint as a potential security risk due to pattern similarity, while missing a nuanced logic flaw that allows privilege escalation.
  • Overlooking Complex Dependencies: AI might fail to account for security risks in intricate dependency chains or third-party integrations, where a developer’s experience would highlight potential issues.
  • Generic Recommendations: AI might suggest generic fixes that do not align with the specific architecture or threat model of the application, whereas developers tailor solutions to the system’s needs.
  • Failing to Detect Zero-Day Vulnerabilities: AI cannot identify vulnerabilities that do not have a pre-existing pattern in its training data. Developers’ intuition and expertise are critical for detecting these novel threats.
  • Incorrectly Prioritizing Vulnerabilities: AI might prioritize fixing minor issues over addressing critical risks, leading to inefficient resource allocation. Developers can apply risk-based decision-making to prioritize effectively.
  • Overlooking Business Logic Flaws: AI often fails to detect flaws in the business logic that attackers can exploit. These vulnerabilities require a deep understanding of the application’s purpose and workflows, which developers possess.
  • Inappropriate Code Suggestions: AI-generated code snippets may inadvertently introduce vulnerabilities or fail to comply with specific security policies. Developers review and adapt these snippets to ensure secure integration.
  • Old or obsolete training data: AI recommends very often snippets of code based on old APIs, which might no longer exist by the time it is asked to generate some code. Developers will look always at the latest documentation of the API they need.

 

Instead of conclusions

AI is a powerful tool that enhances the capabilities of developers but, as can be seen above, it does not replace them. At least for a long while … 🙂

The ideal approach is a collaborative one, where AI handles repetitive tasks and provides data-driven insights, allowing developers to focus on high-level problem-solving and decision-making.

Organizations should invest in both AI tools and the continuous development of their teams’ security skills.

This balanced approach ensures that the software remains secure, reliable, and resilient against threats.

 

The post AI vs. (secure) software developers 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.

Thoughts on AI and Cybersecurity

/in

Being an CSSLP gives me access to various emails from (ISC)2. One of these announced me that there is a recording of a webinar about AI and Cybersecurity held by Steve Piper from CyberEdge.

Very nice presentation of 1h, and I found out that there is a sequel to that on November 1st.

So, following Steve’s article, I did some research, read a lot and used ChatGPT to summarize some of my findings.

This article explores the multifaceted ways AI is transforming cybersecurity, from threat detection to incident response and beyond. It also looks into What it means actually to use AI in some of these fields. What is the impact on privacy and confidentiality?

Important to keep in mind that any AI must first learn (trained) in order to be able to understand the system and then potentially predict what is happening.

 

  1. Threat Detection

One of the primary applications of AI in cybersecurity is threat detection. Traditional rule-based systems are no longer sufficient to identify and combat sophisticated attacks.

AI-driven technologies, such as machine learning and deep learning, can analyze massive datasets to detect anomalies and potential threats.

Here’s how:

a. Anomaly Detection: AI algorithms can establish a baseline of normal behavior in a network or system. Any deviation from this baseline can trigger an alert, indicating a potential security breach.

b. Behavioral Analysis: AI can analyze user and entity behavior to detect patterns that may indicate malicious activity. This is particularly useful for identifying insider threats.

c. Malware Detection: AI can scan files and code for patterns consistent with known malware or recognize behavioral patterns of malicious software.

We’ll talk more in the future on this topic.

 

  1. Predictive Analysis

AI-driven predictive analysis enhances cybersecurity by identifying potential threats before they become full-blown attacks.

By crunching vast amounts of historical data, AI systems can predict emerging threats, trends, and vulnerabilities. This early warning system allows organizations to preemptively shore up their defenses.

It would have to gather huge amounts of data, crunch them (preprocess, normalize, structure), creating an ML model and then based on the chosen technology train the system.

Here we can think of supervised (pre-categorized data, requiring feature to be defined) and unsupervised learning (non categorized data, basically being restricted to Anomaly detection).

There is a huge warning here, because :

a) such huge amounts of data has to come from somewhere and

b) predictions can be influenced by specially crafted training data, for unsupervised training models.

 

  1. Automation and Orchestration

AI can automate routine cybersecurity tasks and workflows, reducing the workload on human analysts and minimizing response times. AI-driven systems can:

a. Automatically quarantine infected devices or isolate compromised areas of a network to prevent lateral movement by attackers.

b. Investigate and analyze security incidents, rapidly categorizing and prioritizing alerts.

c. Initiate predefined incident response procedures, such as patching vulnerable systems or resetting compromised user accounts.

 

Automation:

Automation involves the use of technology, such as scripts, workflows, or AI-driven systems, to perform routine and repetitive tasks without human intervention. In the context of cybersecurity, automation can significantly improve efficiency and response times by handling various operational and security-related processes automatically. Here’s how it works:

a. Incident Response: When a security incident is detected, automation can trigger predefined actions to contain, investigate, and mitigate the threat. For example, if a system detects a malware infection, an automated response might involve isolating the affected device from the network, blocking the malicious IP address, and initiating a forensic investigation.

b. Vulnerability Patching: Automation can be used to deploy security patches and updates to systems and software as soon as they are released. This reduces the window of vulnerability and helps prevent attacks that target known vulnerabilities.

c. Log Analysis and Alerts: Automation can continuously monitor logs and events from various systems. It can detect and respond to predefined security events, generating alerts or triggering specific actions when unusual or malicious activity is detected.

 

Orchestration:

Orchestration is a broader concept that focuses on integrating and coordinating various security tools, processes, and workflows into a unified and streamlined system. It enables organizations to create end-to-end security workflows by connecting different security solutions and ensuring they work together cohesively. Here’s how it works:

a. Workflow Integration: Orchestration systems allow the creation of predefined security workflows that link multiple tools, such as firewalls, intrusion detection systems, antivirus software, and incident response platforms. For example, when a malware alert is triggered, orchestration can coordinate the response by isolating the affected system, collecting forensic data, and alerting the incident response team.

b. Information Sharing: Orchestration enables the sharing of critical information among security tools. This ensures that all relevant security solutions have access to the latest threat intelligence, allowing for more effective threat detection and mitigation.

 

  1. Phishing Detection

Phishing attacks remain a prevalent threat. AI can help identify phishing attempts by:

a. Analyzing email content and sender behavior to identify suspicious emails.

b. Scanning URLs for malicious domains or suspicious patterns.

c. Inspecting attachments for known malware signatures.

d. Recognizing social engineering techniques and language used in phishing emails.

 

  1. Network Security

AI-driven intrusion detection systems (IDS) and intrusion prevention systems (IPS) monitor network traffic for anomalies and threats.

They can identify and block malicious traffic in real-time, protecting the network from various attacks, including DDoS attacks and data exfiltration.

 

  1. Threat Intelligence

AI can be used to aggregate and analyze threat intelligence from various sources, including open-source feeds, dark web monitoring, and industry-specific data.

This aggregated intelligence can help security teams stay informed about emerging threats and vulnerabilities.

 

  1. Endpoint Security

AI-driven endpoint security solutions provide real-time protection for individual devices.

They can identify and mitigate threats at the device level, even when the device is not connected to the corporate network. This is especially crucial for remote workers and mobile devices.

This raises another red flag for me: complete monitoring of user’s actions on the device. What happens to the data gathered, is the model trained locally on in the cloud? And many other such concerns.

I will write a dedicated post about AI and Privacy very soon.

The post Thoughts on AI and Cybersecurity first appeared on Sorin Mustaca on Cybersecurity.

ChatGPT and automotive cybersecurity #2/2: TISAX certification

/in

This is the 2nd post about Automotive Cybersecurity.

Since I am working these days on CSMS (based on ISO ECE 21434 and TISAX), part of my companies consulting offer for automotive I thought maybe I check what ChatGPT things about them.

 

First post was about CSMS and ISO 21434 and this one is about TISAX.

 

Query:

Tell me about challenges in TISAX certification 

 

ChatGPT:

“TISAX (Trusted Information Security Assessment Exchange) is a security assessment and certification process for automotive suppliers. The certification is used to evaluate and ensure the information security capabilities of companies in the automotive sector.

There are several challenges associated with TISAX certification:

  • Complex requirements: TISAX has extensive and complex security requirements that can be difficult to understand and implement. Companies may struggle to meet these requirements and may need help from experts to achieve certification.
  • Resource constraints: Implementing the security measures required for TISAX certification can be resource-intensive and time-consuming. This can be especially challenging for small or medium-sized businesses.
  • Technical difficulties: Companies may face technical challenges in implementing the necessary security controls, particularly if their existing systems are not well-suited to the TISAX requirements.
  • Cost: The cost of TISAX certification can be significant, and this may be a challenge for companies with limited budgets.
  • Maintenance: TISAX certification must be maintained, and companies must continually evaluate and improve their security controls to stay certified. This can be a challenge, as the threat landscape is constantly evolving and new risks emerge.

Overall, TISAX certification requires a substantial investment of time, resources, and expertise, but it is considered an important aspect of information security for companies operating in the automotive sector.”

 

So, I have to say that this impressed me a bit …

I have always difficulties explaining to my customers why is it so hard to pass the TISAX audit.

It is all true, and actually it is quite a challenge to get companies to commit to a long term cooperation with a consulting company, which can help them understand the requirements and teach them how to apply them.

 

Conclusion: 

I will get back to ChatGPT from time to time and try to get such short descriptions for various things I need.

The post ChatGPT and automotive cybersecurity #2/2: TISAX certification first appeared on Sorin Mustaca on Cybersecurity.