Posts

ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance

/in

This is the part 5 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

 

ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance

 

Chapter 6 — Supplier Relationships

This chapter addresses how the organization manages information security risks arising from third parties — contractors, cooperation partners, and the exchange of sensitive information with external organizations.

Note: Chapter 6 contains no separately titled subchapter. Controls run as 6.1.x.

6.1.1 — To what extent is information security ensured among contractors and cooperation partners?

All contractors and cooperation partners must be subjected to a risk assessment covering information security before engagement. Appropriate security levels must be ensured through contractual clauses. Where there are upstream contractual obligations from the organization’s own clients, those must be passed through to relevant partners. The should-level requires that contractors and cooperation partners are contractually obligated to pass information security requirements down to their own subcontractors, and that reports and documents from these partners are reviewed. For high protection needs, proof must be provided that the supplier’s information security level is adequate for the protection needs of the information being shared — for example, through a certificate, attestation, or internal audit.

Evidence includes supplier contracts containing security clauses, risk assessment records, and for high protection needs, supplier compliance evidence such as TISAX labels, ISO 27001 certificates, or audit reports.

6.1.2 — To what extent is non-disclosure regarding the exchange of information contractually agreed?

Non-disclosure requirements must be identified and fulfilled before sensitive information is passed to any external party. The people responsible for passing information must know when NDAs are required and how to apply them. NDAs must be signed before information is shared. The should-level requires NDA templates that are legally reviewed and kept current, and the NDA itself must cover the parties involved, the type and classification of information, the purpose, the validity period, and what happens upon termination or in case of unauthorized disclosure.

Evidence includes NDA templates, signed NDA records, and documentation showing awareness of NDA requirements among staff responsible for information exchange.

Chapter 7 — Compliance

This chapter addresses the organization’s obligations to comply with external legal, regulatory, and contractual requirements, and to handle personally identifiable data appropriately within its information security framework.

Note: Chapter 7 contains no separately titled subchapter. Controls run as 7.1.x.

7.1.1 — To what extent is compliance with regulatory and contractual provisions ensured?

Legal, regulatory, and contractual provisions relevant to information security must be identified at regular intervals. The landscape changes, and what was compliant last year may not be today. Policies and procedures for compliance with these provisions must be defined, implemented, and communicated to the responsible people. The should-level adds a specific focus on records integrity — the organization must ensure its records are maintained in a way that meets legal and regulatory requirements.

Evidence includes a legal and regulatory requirement register, compliance policies, communication records showing relevant staff awareness, and records management procedures.

7.1.2 — To what extent is the protection of personally identifiable data considered when implementing information security?

When personal data is processed, the legal and contractual information security requirements for that processing must be identified. Regulations for compliance with data protection requirements must be defined within the ISMS. This control is intentionally narrow in scope. It addresses data protection as an element of information security governance, not as a full replacement for GDPR compliance work (which is covered separately in the Data Protection sheet of the ISA).

Evidence includes a documented identification of applicable data protection requirements within the ISMS scope, internal policies referencing those requirements, and any relevant assessments or legal opinions obtained.

Document prepared based on ISA VDA 6.0.3, Information Security sheet. All control descriptions, requirements, and evidence expectations are derived directly from columns H (Control Question), I (Objective), J (Requirements must), K (Requirements should), L (Additional requirements for high protection needs), and M (Additional requirements for very high protection needs).

The post ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security

/in

This is the part 4 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security

Chapter 5 — IT Security / Cyber Security

This is the largest chapter in the Information Security sheet. It covers the technical and operational security measures applied to IT infrastructure, from encryption and network controls to development practices and cloud usage.

5.1 Cryptography

This subchapter addresses the use of cryptographic mechanisms to protect the confidentiality, integrity, and availability of information.

5.1.1 — To what extent is the use of cryptographic procedures managed?

All cryptographic algorithms, protocols, and key lengths used within the organization must meet recognized industry standards for their respective application. This applies across the board: encryption at rest, in transit, for signing, and for hashing. The should-level expects formal technical rules defining encryption requirements by information classification, and a cryptography concept covering algorithm choices, key strengths, key management, and the handling of lost or compromised keys. For high protection needs, key sovereignty requirements must be explicitly determined and fulfilled — particularly relevant when external services process encrypted data and the organization needs assurance that the provider cannot access keys.

Evidence includes a cryptography policy or technical standard, documentation of algorithms and key lengths used, key management procedures, and for high protection needs, documentation of key sovereignty arrangements.

5.1.2 — To what extent is information protected during transfer?

All network services used to transfer information must be identified and documented. Policies governing the use of these services must align with information classification requirements. Protection measures against unauthorized access and tampering during transfer must be implemented. The should-level adds requirements for correct addressing, content or transport encryption matched to classification, and verification that remote access connections meet adequate security standards. For high protection needs, information must be transferred in encrypted form — with documented compensating measures where encryption is not feasible. For very high protection needs, content-level encryption is required, not merely transport-level.

Evidence includes a data transfer policy, a list of approved network services, encryption configurations, and at higher protection levels, evidence of content encryption implementation.

5.2 Operations Security

This subchapter covers the day-to-day security of IT operations: managing changes, separating environments, protecting against malware, logging, handling vulnerabilities, auditing systems, managing networks, and maintaining continuity and backup capabilities.

5.2.1 — To what extent are changes managed?

Any change to the organization, business processes, or IT systems must consider information security requirements. The should-level requires a formal approval procedure for changes, impact assessments, planning and testing for changes affecting security, and documented fallback procedures. For high protection needs, compliance with security requirements must be verified both during and after change implementation.

Evidence includes a change management process, change request and approval records, testing documentation, and for high protection needs, post-implementation security verification records.

5.2.2 — To what extent are development and testing environments separated from operational environments?

Before deciding on separation, a risk assessment of IT systems must determine whether separation into development, test, and production environments is necessary. Where it is, separation must be implemented. The should-level adds more specific requirements: no development tools in production, no real production data in test environments unless appropriately protected, and documented requirements for each environment type.

Evidence includes the risk assessment that informed the separation decision, environment configuration documentation, and access control records showing restricted cross-environment access.

5.2.3 — To what extent are IT systems protected against malware?

Protection requirements against malware must be determined, and both technical and organizational measures must be defined and implemented. The should-level expects unnecessary network services to be disabled, access to remaining services to be restricted, malware protection software to be installed and automatically updated, and received files to be scanned before opening. No additional high or very high requirements apply.

Evidence includes the malware protection policy, configuration records for endpoint protection tools, and update verification records.

5.2.4 — To what extent are event logs recorded and analysed?

Information security requirements for logging must be determined and implemented. Activities of system administrators and privileged users must be logged. Systems must be assessed to determine appropriate log scope and retention. The should-level adds escalation procedures for relevant events, log integrity protection, and adequate retention periods. For high protection needs, contractual logging requirements must be met, and connections and disconnections of external networks — such as remote maintenance sessions — must be logged. For very high protection needs, any access to data of very high classification must be logged to the extent technically feasible and legally permissible.

Evidence includes a logging policy, log retention configuration, log integrity controls, and at higher protection levels, specific log samples or monitoring dashboards showing coverage of required event types.

5.2.5 — To what extent are vulnerabilities identified and addressed?

The organization must actively gather information about technical vulnerabilities affecting its IT systems — from manufacturer advisories, public CVE databases, and internal assessments — and evaluate them for relevance and severity using a structured method such as CVSS. Affected systems must be identified and remediated within an appropriate time. The should-level requires adequate patch management, including testing patches before deployment, implementing risk-minimizing measures while patches are pending, and verifying successful installation.

Evidence includes a vulnerability management procedure, subscription records for vulnerability feeds, patch management records, and evidence of CVSS-based prioritization.

5.2.6 — To what extent are IT systems and services technically checked (system and service audit)?

Technical audits of IT systems and services must be scoped, coordinated with system operators, and recorded in a traceable way. The should-level expects risk-aware planning of audits, regular execution by qualified personnel using appropriate tools, and documentation of findings and remediation. For high protection needs, critical IT systems must have additional audit requirements — such as human penetration testing or risk-driven intervals — defined and applied. For very high protection needs, IT systems and services must be regularly scanned for vulnerabilities, with documented compensating measures for systems that cannot be scanned.

Evidence includes audit planning records, audit reports, remediation tracking, and at higher protection levels, penetration test reports and scheduled scanning records.

5.2.7 — To what extent is the network of the organization managed?

Requirements for network management and segmentation must be determined and implemented. The should-level defines the basis for risk-based segmentation: limiting which IT systems can connect to the network, using appropriate security technologies, and considering performance, trust, and safety criteria. For high protection needs, additional requirements apply: IT systems must be authenticated on the network, management interfaces must be access-restricted, and specific risks — such as wireless access, remote maintenance, and IoT — must be addressed.

Evidence includes a network architecture diagram, segmentation documentation, firewall and access control configurations, and for high protection needs, network authentication records and management interface access controls.

5.2.8 — To what extent is continuity planning for IT services in place?

Critical IT services must be identified and their business impact documented. Requirements and responsibilities for continuity and recovery of those services must be known and fulfilled. The should-level expects identification of critical IT systems, appropriate classification and security measures for those systems, and planning that covers scenarios including DDoS attacks, ransomware, and power failures. For high protection needs, RTO targets must be defined in continuity plans and reflected in SLAs with external service providers. For very high protection needs, continuity plans must be coordinated with external service providers and must support continuance of essential functions with minimal or no operational interruption, including hot standby or rapid failover capabilities.

Evidence includes a business continuity and IT recovery plan, risk impact analysis, RTO and RPO documentation, SLAs with external providers, and for very high protection needs, failover test records and coordinated plans with key providers.

5.2.9 — To what extent is the backup and recovery of data and IT services ensured?

Backup concepts must exist for relevant IT systems, addressing confidentiality, integrity, and availability of backup data. Recovery concepts must also exist for relevant IT services. The should-level requires a comprehensive backup and recovery concept per IT service that accounts for inter-service dependencies and recovery sequencing. For high protection needs, backup and recovery concepts must be methodically reviewed at regular intervals, restore capability must be tested, and RPO and RTO targets must be defined. For very high protection needs, backups must be supplemented with offline procedures, immutable backups, or isolated IAM technology to protect against ransomware scenarios. Restore procedures must be technically tested at regular intervals. Geographical redundancy must be considered.

Evidence includes backup configuration documentation, recovery plans, test records proving restore capability, and for very high protection needs, immutable backup configuration records and geographically redundant storage records.

5.3 System Acquisitions, Requirement Management and Development

This subchapter covers how security is built into IT systems from the start — whether acquired from vendors or built in-house — and how the organization manages its relationships with cloud and external service providers at the technical level.

5.3.1 — To what extent is information security considered in new or further developed IT systems?

Security requirements must be embedded into both development and acquisition processes. This includes security requirements in specification documents, vendor recommendations and best practices, and fail-safe design principles. Security requirements must also be considered throughout the development lifecycle, including testing and deployment. The should-level adds formal requirement specifications referencing security standards. For very high protection needs, purpose-built or significantly customized software must undergo security testing — such as penetration testing — at commissioning, at major changes, and at regular intervals thereafter.

Evidence includes requirement specifications containing security criteria, development lifecycle documentation, and for very high protection needs, penetration test reports.

5.3.2 — To what extent are requirements for network services defined?

Information security requirements for network services must be determined and fulfilled. The should-level expects formal SLAs to document agreed requirements and adequate redundancy to be implemented. For high protection needs, traffic monitoring procedures — such as flow analyses and availability measurements — must be defined and carried out to detect anomalies and verify quality.

Evidence includes a network service requirements document, SLA agreements, and for high protection needs, traffic monitoring reports or dashboards.

5.3.3 — To what extent is the return and secure removal of information assets from external IT services regulated?

When terminating an external IT service, the organization must have a defined and implemented procedure for securely removing or retrieving its information assets. The should-level requires this procedure to be documented, kept current, and contractually embedded with the service provider.

Evidence includes a termination and data retrieval procedure, contracts containing data return and deletion clauses, and records of executed terminations.

5.3.4 — To what extent is information protected in shared external IT services?

In multi-tenant cloud or shared hosting environments, effective logical segregation must prevent other organizations’ users from accessing the organization’s information. The should-level expects the provider’s segregation concept to be documented and regularly reviewed, covering data, functions, software, operating systems, storage, and networking, as well as risk assessments for third-party software running in shared environments.

Evidence includes the cloud or hosting provider’s segregation documentation, contractual guarantees of tenant isolation, and internal review records.

 

The post ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management

/in

This is the part 3 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

 

ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management

Chapter 2 — Human Resources

This chapter addresses the people dimension of information security: how the organization selects staff for sensitive roles, contractually binds them to security obligations, trains and raises awareness among them, and manages the risks associated with working outside the office.

Note: Chapter 2 in ISA 6.0.3 contains only one structural level beneath the chapter header. Controls are numbered in the format 2.1.x but there is no separately titled subchapter 2.1 header. The implicit grouping covers general HR security measures.

2.1.1 — To what extent is the qualification of employees for sensitive work fields ensured?

The organization must identify which roles are sensitive from an information security perspective, define the qualification requirements for those roles, and verify the identity of candidates before hiring. The should-level extends this to personal suitability checks — interviews, reference checks, or more rigorous methods depending on the role’s sensitivity. There are no additional requirements at high or very high protection need levels.

Evidence includes a list or classification of sensitive roles, defined job profiles with security-relevant criteria, and records of identity verification performed during hiring.

2.1.2 — To what extent is all staff contractually bound to comply with information security policies?

Every employee must be under a non-disclosure obligation and must be formally committed to complying with information security policies. The should-level adds an expectation that the NDA extends beyond the employment period, that security aspects are embedded in employment contracts, and that there is a procedure for handling violations.

Evidence includes employment contract templates containing NDA clauses and information security obligations, and any documented procedures for managing breaches of these obligations.

2.1.3 — To what extent is staff made aware of and trained with respect to the risks arising from the handling of information?

All employees must receive training and awareness activities related to information security. The should-level defines a minimum scope for that training: the organization’s information security policy, how to report security events, how to respond to malware, how to handle user accounts and passwords, and physical security measures. Training must be refreshed at regular intervals.

Evidence includes a training concept or awareness program, training records showing which employees completed which modules, and records of the training schedule and frequency.

2.1.4 — To what extent is mobile work regulated?

Working outside defined security zones — home offices, client sites, travel — introduces risks that must be addressed by specific requirements. The must-level requires that the organization has determined and implemented requirements covering secure access to and handling of information in both electronic and physical form during remote work. The should-level adds considerations for travel-specific risks, including measures for travel to security-sensitive countries. For high protection needs, protective measures against overhearing and visual exposure — such as privacy screens and secure communication practices — must be implemented.

Evidence includes a teleworking or remote work security policy, records showing the policy has been communicated to staff, and for high protection needs, documented technical and organizational measures against visual and acoustic compromise.

Chapter 3 — Physical Security

This chapter addresses the physical layer of information security: the security zones where information is processed, the hardware and media that carries it, and the mobile devices used to access it outside secure perimeters.

Note: Like chapter 2, chapter 3 contains no separately titled subchapter. Controls run directly as 3.1.x.

3.1.1 — To what extent are security zones managed to protect information assets?

A security zone concept must exist that maps protection requirements to physical areas — offices, server rooms, delivery zones, reception areas. The concept must define what protective measures apply in each zone, and zones must be demarcated with visible or enforced perimeters. The should-level adds expectations for access rights management procedures, visitor management policies, and rules for using mobile IT devices inside secure zones. For high protection needs, measures against overhearing and visual exposure inside or near sensitive zones must be implemented.

Evidence includes the security zone documentation, access control records, visitor logs, and for high protection needs, records of anti-eavesdropping or visual screening measures.

3.1.2 — Superseded by 1.6.3, 5.2.8, and 5.2.9

This control is no longer active in ISA 6.0.3. Its content has been redistributed into crisis management (1.6.3), IT continuity planning (5.2.8), and backup and recovery (5.2.9). No assessment is performed against 3.1.2 as a standalone control.

3.1.3 — To what extent is the handling of supporting assets managed?

Physical assets that support information processing — servers, workstations, storage media, paper — must have defined requirements covering their entire lifecycle: transport, storage, repair, loss reporting, return, and secure disposal. The should-level is not populated for this control. For high protection needs, supporting assets must be disposed of in accordance with recognized standards — for example, ISO 21964 at Security Level 4 or equivalent — to prevent data recovery from discarded equipment.

Evidence includes a hardware and media lifecycle policy, disposal records, and for high protection needs, certificates of secure destruction.

3.1.4 — To what extent is the handling of mobile IT devices and mobile data storage devices managed?

Mobile devices and removable storage must meet defined security requirements covering encryption, access protection such as PIN or password, and appropriate marking. The should-level adds device registration and user communication about risks. For high protection needs, general encryption of mobile storage devices or the information stored on them is required. Where encryption is not technically feasible, equally effective compensating measures must be implemented.

Evidence includes a mobile device management policy, encryption configuration records, device inventory, and for high protection needs, evidence of encryption enforcement or compensating controls.

Chapter 4 — Identity and Access Management

This chapter covers the mechanisms by which the organization controls who can access what — from physical identification tokens to digital user accounts and the logic for granting or revoking rights.

4.1 Identity Management

This subchapter addresses physical and digital means of identification and the authentication procedures that verify a user’s identity before granting system access.

4.1.1 — To what extent is the use of identification means managed?

Physical and digital identification tokens — keys, access cards, cryptographic tokens, certificates — must be managed across their full lifecycle: creation, issuance, return, revocation, and destruction. Validity periods must be defined and traceability maintained, along with a process for handling lost means. The should-level expects these tokens to be produced only under controlled conditions. For high protection needs, validity periods must be actively limited to an appropriate duration, and a blocking strategy for lost tokens must be both defined and implemented as far as technically possible.

Evidence includes an identification means register, lifecycle management procedures, records of issued and returned tokens, and for high protection needs, proof of validity enforcement and loss response procedures.

4.1.2 — To what extent is the user access to IT services and IT systems secured?

Authentication procedures must be chosen based on a risk assessment that considers the attack surface of each system, including whether systems are directly internet-accessible. State-of-the-art authentication must be applied. The should-level requires strong passwords at minimum and stronger mechanisms for privileged users. For high protection needs, enhanced measures such as continuous session monitoring, automatic logout, and brute force prevention must be implemented based on the risk profile. For very high protection needs, access to data of very high classification must require strong two-factor authentication.

Evidence includes a risk assessment underpinning authentication choices, authentication configuration documentation, and at higher protection levels, records of enhanced access controls and monitoring.

4.1.3 — To what extent are user accounts and login information securely managed and applied?

User accounts must follow a clear lifecycle: creation, modification, and deletion all managed with oversight. Accounts must be unique and personal. Generic or shared accounts must be restricted to cases where traceability is genuinely not needed. Accounts must be disabled immediately when a user leaves or changes role. The should-level adds expectations around minimal default-privilege accounts, disabling of default manufacturer credentials, formal authorization procedures for creating accounts, and regular account reviews.

Evidence includes a user account management procedure, records of account creation and deactivation, and periodic access reviews.

4.2 Access Management

This subchapter addresses how access rights are granted, reviewed, and revoked — and how the organization ensures that rights remain aligned with actual need.

4.2.1 — To what extent are access rights assigned and managed?

Access rights must be managed based on the need-to-know and least privilege principles. The process for requesting, approving, and revoking rights must be defined. Rights must be revoked when no longer needed. The should-level expects role-based access control, with rights assigned to roles rather than individuals where possible, and regular reviews to identify stale or excessive rights. For high protection needs, access rights must be approved by a designated internal information officer. For very high protection needs, data of very high classification must be stored in encrypted form so that even privileged users cannot access it without appropriate authorization, and access rights must be reviewed more frequently.

Evidence includes an access rights management procedure, role definitions, access review records, approval records, and at higher protection levels, encryption configuration and formal information officer sign-off records.

 

The post ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization

/in

This is the part 2 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

 

ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization

 

Chapter 1 — IS Policies and Organization

This chapter establishes the governance foundation of the entire ISMS. It covers formal structures, policies, and management decisions that make information security a deliberate, managed discipline rather than an informal practice. Without a solid chapter 1, everything downstream has no authoritative basis.

1.1 Information Security Policies

This subchapter asks whether the organization has committed its approach to information security in writing and whether that commitment comes from the right level of authority.

1.1.1 — To what extent are information security policies available?

The organization must have at least one formally approved information security policy. This is not a technical document. It is a management-level statement that defines what information security means for the organization, why it matters, what the objectives are, and what roles and responsibilities exist. The policy must be adapted to the organization’s specific context, not copied wholesale from a template.

The must-level requirements demand that the policy exists, that it has been formally released by management, and that it articulates the objectives and significance of information security. The should-level requirements raise the bar: the policy should also reflect the organization’s strategic direction, applicable legal obligations, and contractual requirements. It should state what consequences follow from non-compliance, reference other relevant security policies, and be subject to periodic review. There are no additional requirements at the high or very high protection need levels for this control.

Evidence an auditor will look for: the policy document itself, a visible approval signature or release notation, version history showing periodic reviews, and communication records proving staff awareness.

1.2 Organization of Information Security

This subchapter addresses how information security is structured within the organization — who owns it, who is responsible for what, how it connects to projects, and how external IT service providers fit into the accountability picture.

1.2.1 — To what extent is information security managed within the organization?

The organization must have a functioning ISMS with a defined scope, management endorsement, and monitoring mechanisms that give leadership visibility into the state of information security. Management must have actively commissioned and approved the ISMS. Passive acceptance is not enough.

Evidence includes the ISMS scope statement, documented management approval, and any governance reporting tools or dashboards used by leadership to track security performance.

1.2.2 — To what extent are information security responsibilities organized?

Roles and responsibilities for information security must be defined, documented, and assigned to real, qualified people. Those people must be known within the organization and to relevant external parties. The should-level pushes toward a documented organizational structure covering all relevant security roles. For high protection needs, the control adds a requirement for appropriate separation of duties to prevent conflicts of interest — for example, ensuring the person who configures systems is not the same person auditing them.

Evidence includes role descriptions, organizational charts, and records of qualifications for people in security roles.

1.2.3 — To what extent are information security requirements considered in projects?

All projects, regardless of their nature, must be classified from an information security perspective so that relevant security requirements are identified early. The should-level expects a documented procedure for this classification, risk assessments at project initiation and when changes occur, and documented measures for any identified risks. For high protection needs, those measures must be reviewed regularly throughout the project lifecycle and reassessed whenever the risk picture changes.

Evidence includes a project classification procedure, risk assessment records for projects, and documented security measures tied to specific projects.

1.2.4 — To what extent are the responsibilities between external IT service providers and the own organization defined?

When the organization uses external IT services, it must be clear who is responsible for which security requirements. A shared model — where both parties have responsibilities — must be explicitly defined, not assumed. The should-level requires that configurations are implemented and documented based on security requirements and that responsible staff are adequately trained. For high protection needs, a formal list of all affected external IT services and their responsible providers must exist, the applicability of ISA controls must be verified and documented, service configurations must be included in regular security assessments, and proof must be available that the provider actually implements the agreed security requirements.

Evidence includes contracts or service agreements with security clauses, RACI matrices or responsibility assignment records, and provider compliance documentation.

1.3 Asset Management

This subchapter addresses whether the organization knows what information assets it holds, how they are classified, and whether the tools and external services used to process them are managed with appropriate controls.

1.3.1 — To what extent are information assets identified and recorded?

Information assets — the core data and knowledge that matter to the organization — must be identified and recorded, with a responsible owner assigned. The supporting technical assets that process those information assets must also be inventoried and assigned an owner. The should-level expects a formal catalogue that maps supporting assets to information assets and is reviewed regularly.

Evidence includes an asset inventory or register, assigned ownership records, and review logs for the catalogue.

1.3.2 — To what extent are information assets classified and managed in terms of their protection needs?

The organization must have a consistent classification scheme focused at minimum on confidentiality, and must have applied that scheme to its information assets. Handling requirements must follow from the classification. The should-level encourages the organization to also consider integrity and availability when classifying assets.

Evidence includes the classification scheme documentation, records of classification applied to specific information assets, and handling guidelines tied to each classification level.

1.3.3 — To what extent is it ensured that only evaluated and approved external IT services are used for processing the organization’s information assets?

Before using any external IT service to process organizational information, a risk assessment must be completed and legal, regulatory, and contractual requirements must be considered. The service must be harmonized with the organization’s information security requirements. The should-level expects a formal approval and procurement procedure, a release process tied to protection need, and a documented inventory of approved services. No additional high or very high requirements apply beyond regular checking of approved status.

Evidence includes risk assessment records for external services, approval documentation, a register of approved external IT services, and contract clauses.

1.3.4 — To what extent is it ensured that only evaluated and approved software is used for processing the organization’s information assets?

Software must be approved before installation or use, taking into account licensing, use-case restrictions, conformance to security requirements, and the reputation of the source. Approval must also address the removal of software that is no longer needed or no longer compliant. The should-level adds expectations around managed repositories, protection of those repositories against tampering, and regular review of approvals. For very high protection needs, additional requirements — such as control or monitoring of software usage — must be determined and documented.

Evidence includes a software approval process, a software inventory or repository, records of approvals and periodic reviews, and for very high protection needs, usage monitoring records.

1.4 IS Risk Management

This subchapter addresses the central mechanism that connects threats and vulnerabilities to the organization’s information assets and produces actionable decisions.

1.4.1 — To what extent are information security risks managed?

Risk assessments must happen regularly and in response to events, not only on a fixed annual schedule. Identified risks must be assessed for probability and potential damage, documented, and assigned to a responsible risk owner. The should-level requires a formal risk management procedure, defined criteria for assessing and handling risks, and documented plans with responsible persons. Accepted risks must be explicitly approved by management. No additional high or very high protection need requirements apply.

Evidence includes risk assessment records, a risk register, documented risk treatment decisions, and management approval records for accepted risks.

1.5 Assessments

This subchapter addresses the organization’s obligation to verify that its information security policies and ISMS are actually working, through both internal reviews and independent external assessments.

1.5.1 — To what extent is compliance with information security ensured in procedures and processes?

Policies must be checked for compliance throughout the organization on a regular basis. Deviations must trigger corrective measures, and those measures must be tracked to closure. Compliance with legal and contractual information security requirements must also be verified. The should-level expects a documented plan that defines the scope, schedule, and controls covered by compliance reviews.

Evidence includes compliance review reports, records of corrective actions, and a compliance review schedule or plan.

1.5.2 — To what extent is the ISMS reviewed by an independent authority?

The ISMS must be assessed from outside the team responsible for running it — by an internal audit function, an external auditor, or another body that can provide an objective view. This must happen regularly and whenever fundamental changes occur. Corrective measures arising from such reviews must be tracked. The should-level expects results to be formally reported to management.

Evidence includes internal audit reports or third-party review reports, management reporting records, and corrective action logs.

1.6 Incident and Crisis Management

This subchapter covers the organization’s capacity to detect, respond to, and recover from security incidents and, at a higher scale, from crisis situations that threaten continuity.

1.6.1 — To what extent are information security relevant events or observations reported?

There must be a clear definition of what constitutes a reportable security event, and this definition must be known to employees and relevant stakeholders. The definition must cover personnel-related events, physical security observations, and technical/cyber events. The should-level requires a single point of contact for reporting, multiple reporting channels matched to severity, and formal obligations for employees to report. For very high protection needs, tests and exercises of the reporting process must be conducted regularly.

Evidence includes the event reporting definition and procedure, communication records or training materials proving staff awareness, and for very high protection needs, exercise records.

1.6.2 — To what extent are reported security events managed?

Once an event is reported, it must be processed without undue delay, receive an adequate response, and feed into continuous improvement through lessons learned. The should-level expects events to be categorized by type, qualified by severity, and prioritized. For high protection needs, maximum response times must be defined for each class and priority, and escalation mechanisms must be in place for events not processed within those times. For very high protection needs, event handling across different categories and priorities must be tested regularly, including simulation of rare scenarios and escalation exercises.

Evidence includes a ticketing or event management system showing processing records, defined response time SLAs, escalation procedures, and exercise or simulation records at the appropriate protection level.

1.6.3 — To what extent is the organization prepared to handle crisis situations?

A crisis is a situation where normal incident response is insufficient — for example, a major cyberattack causing infrastructure failure, a pandemic, or a natural disaster. The organization must have a crisis response and recovery plan, defined responsibilities, and appropriately qualified personnel. The should-level adds requirements for methods to detect emerging crises, a procedure to invoke crisis management, and documented strategic priorities for crisis situations. For high protection needs, a set of relevant crisis scenarios must have been identified, covering key personnel unavailability, facility unavailability, and major cyberattacks, with corresponding response plans. For very high protection needs, full crisis exercises and simulations involving all relevant decision-makers must be conducted regularly.

Evidence includes a crisis management plan, documented responsibilities, evidence of tested scenarios, and exercise reports.

 

The post ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization first appeared on Sorin Mustaca – Security & Technology.

TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1)

/in

 

TISAX — the Trusted Information Security Assessment Exchange — or Trusted ISA Exchange – is the automotive industry’s answer to a decades-old problem: every OEM was running its own supplier security questionnaire, and tier-1 and tier-2 suppliers were drowning in redundant audits. ENX Association, backed by the VDA (Verband der Automobilindustrie), formalized the exchange mechanism in 2017.

The result is a scheme where a single audit, conducted by an accredited assessment service provider (ASP), yields a result that any participating OEM can query via the ENX portal — no re-auditing required.

This series of articles is describing the requirements of the ISA and providing some insights.

 

How to get started

1. Download the TISAX Participant Handbook TISAX

This handbook applies to all TISAX processes that you may be part of. It contains all you need to know to run through the TISAX process. The handbook offers some advice on how to deal with the information security requirements at the core of the assessment.

But it does not aim to generally educate you on what you need to do to pass the information security assessment. Yes, you still need someone who actually understands how the controls in the next document.

2. Download the technical backbone of TISAX  – the ISA — Information Security Assessment –  currently at version 6.0.3 from here: workbook . The ISA is published by the VDA as an Excel workbook and serves simultaneously as the questionnaire, the scoring model, and the audit evidence tracker. Understanding its structure is not optional for any organization preparing for a TISAX assessment; it is the map of exactly what an auditor will walk through on-site.

What to do if you are a small company

For a small company, the TISAX assessment can be overwhelmingly complicated and … very expensive.
My advice to all small companies is to have a conversation with your TISAX certified customer which asked you to provide the label about the real needs.

In my experience, you can ask them to give you their Security Self-Assessment for Suppliers document (usually an Excel or PDF document) and you can fill it in.

Of course, you should be compliant to most of the security controls mentioned there.

If you think you are, you can fill in that document and discuss.

If you see clearly that you are not compliant, then try to negotiate down the requirements, focus on those that do not directly apply to the work you are doing for the customer.

If your customer wants to have a long-term working engagement with you (becoming a client) then it will have to make some compromises. Don’t forget that the bigger your company gets, the more important the security controls are.

If you will engage with other customers, in the end it might be that it makes perfect sense to become TISAX certified.

 

Assessment Levels and Label Scopes

Before examining the workbook itself, one distinction shapes everything: the Assessment Level.

  • AL1 is a self-assessment with no on-site verification.
  • AL2 requires a remote audit by an accredited ASP with evidence review and remote interviews.
  • AL3 demands a lot of preparation since it requires ultimately a mandatory on-site audit. Before the on-site audit, there is a phase for submitting evidence and having remote online interviews with key stakeholders. It is suitable for the highest-sensitivity scenarios — handling classified vehicle data, prototypes under embargo, or personal data processed on behalf of an OEM under GDPR data processor obligations.

Most suppliers in the automotive supply chain will be assessed at AL2 or AL3. The label a company requires determines which subset of the ISA they are audited against:Very High Protection Need, High Protection Need, Prototype Protection, or Data Protection .

The ISA workbook is structured to reflect this: it contains sheets for each major assessment domain, and the applicable controls per domain depend on the label scope agreed between the OEM and the supplier.

 

My company offers consulting on how to prepare for a TISAX and ISO27001 audit.

Get in touch with us here: https://www.endpoint-cybersecurity.com/contact/

The Workbook Sheet by Sheet

I will write separate articles about the important sheets: Information Security (part 2) and Data Protection (part 3).

 

Sheet 1 — Cover / Overview

The first sheet is the administrative header of the entire assessment. It captures the organization’s name, the assessment scope (which legal entity, which sites, which processes are in scope), the applicable label(s), and the assessment level. In practice, this sheet is also where the ASP documents the assessment date, the lead assessor’s identity, and the version of the ISA being used.

From an ISMS perspective, this sheet maps directly to the context of the organization requirement in ISO/IEC 27001:2022 (Clause 4). An organization that has already defined its ISMS scope in a formal Scope Statement will find that most of the Cover sheet data is already governed — the TISAX scope and the ISMS scope should be congruent, and any divergence is itself an audit finding waiting to happen.

 

Sheet 2 — Maturity Levels Reference

The ISA uses a six-level maturity scale (0 through 5) derived from the Capability Maturity Model (CMM) concept. Level 0 means the control is absent or completely ineffective. Level 5 means the control is continuously optimized and benchmarked. For a standard AL2 audit, the target threshold is level 3 (“established”) across applicable controls — meaning the process is documented, implemented, and verifiably practiced. AL3 assessments hold the same threshold but with more rigorous evidence scrutiny on-site.

This reference sheet is the normative scoring anchor for the entire workbook. Every self-assessment score entered elsewhere is implicitly a claim against these definitions, and auditors will challenge any score they cannot corroborate with observable evidence.

The ISMS parallel here is ISO 27001:2022 and ISO 27001:2013 Annex A combined with the organization’s Statement of Applicability. Just as the SoA records which controls apply and why, the maturity sheet defines what “implemented” means in quantified terms. Organizations that conflate “we have a policy” (Level 2) with “the policy is consistently followed and verified” (Level 3) routinely discover the gap when the auditor arrives.

Sheet 3 — Information Security (IS)

This is the largest and most foundational sheet in the workbook. It covers the full ISMS domain: organizational security, HR security, physical security, IT and network security, incident management, business continuity, cryptography, and supplier/third-party management. The controls are numbered in the VDA’s own scheme (e.g., 1.1.x, 1.2.x, 5.1.x) and each control row contains a requirement description, a column for the maturity self-assessment score, and columns for comments and evidence references.

The IS sheet is effectively a structured overlay on top of ISO/IEC 27001 Annex A (now restructured in the 2022 edition into four themes: Organizational, People, Physical, and Technological). The coverage is not identical — the ISA adds automotive-specific weight to areas like remote access for manufacturing systems, network segmentation between office and OT environments, and patch management for embedded systems. But the conceptual architecture is the same, and an organization holding an ISO 27001 certification will recognize every clause.

For ISMS practitioners, the critical translation exercise is mapping existing controls documentation (policies, procedures, risk treatment plans) to specific ISA control rows. The ISA does not accept “we are ISO 27001 certified” as a passing score; the auditor will still verify implementation evidence row by row. Certification reduces preparation effort but does not substitute for it.

Sheet 4 — Prototype Protection (PP)

The Prototype Protection sheet addresses a risk specific to the automotive industry: pre-production vehicles, components, and data carry enormous competitive value. Photographs of an unreleased platform at a supplier’s facility have ended up in press publications before launch day more than once. This sheet governs the physical and logical protection of prototype parts and vehicles when they are handled by suppliers — covering receiving and storage, access control to prototype areas, handling of prototype data in digital form (CAD files, test results, specification documents), and obligations when prototypes are transported or loaned.

The PP sheet has no direct ISO 27001 Annex A equivalent, though it draws on physical security principles from that standard. Its closest ISMS relatives are the asset classification and handling controls (A.5.9–A.5.13 in ISO 27001:2022) and the physical security perimeter controls (A.7.1–A.7.4). Organizations that handle prototypes but have not explicitly extended their ISMS asset register to cover physical prototype inventory — and their ISMS physical security controls to cover prototype bays specifically — will find gaps here.

The Prototype Protection label is only triggered when an OEM explicitly requires it in the exchange request. Not every supplier will be assessed on this sheet, but those who are should expect the auditor to physically walk the relevant areas.

Sheet 5 — Data Protection (DP)

The Data Protection sheet was substantially expanded in ISA 6.x to reflect the obligations introduced by GDPR for automotive suppliers acting as data processors on behalf of OEMs. It covers the legal basis for personal data processing, ROPA (Records of Processing Activities) maintenance, data subject rights procedures, DPIA (Data Protection Impact Assessment) processes for high-risk processing, technical and organizational measures (TOMs) as required under GDPR Article 32, data breach notification timelines, and SCCs (Standard Contractual Clauses) for international data transfers.

From an ISMS alignment perspective, this sheet crosses a boundary: it is no longer purely an information security matter but a legal compliance matter rooted in Regulation (EU) 2016/679. ISO 27001 does not fully satisfy the DP sheet — ISO/IEC 27701:2019 (the Privacy Information Management System extension to 27001) is the closest standards-based alignment. Organizations that have implemented 27701 or maintained a structured GDPR compliance program will have significant coverage, but the ISA’s DP sheet is more prescriptive and automotive-context-specific than the generic 27701 controls.

The Data Protection label, like the Prototype Protection label, is triggered selectively. Suppliers who process employee or end-customer personal data on behalf of an OEM — telematics data processors are the clearest example — will routinely be required to achieve it.

Sheet 6 — Results / Summary

The final sheet aggregates the per-control scores from the assessment sheets into domain-level and overall maturity summaries. It typically presents a radar or bar visualization of maturity per domain and flags controls scored below the threshold, which constitute findings. Findings are classified as either major (blocking label issuance) or minor (requiring a remediation plan within a defined timeframe, typically 6–12 months).

For audit management purposes, this sheet is the executive communication artifact. It is what a CISO presents to the board when reporting TISAX readiness, and it is what the ASP uses to structure the final assessment report submitted to ENX. In an ISMS context, this sheet’s function mirrors the management review output required under ISO 27001 Clause 9.3 — a documented evidence of the current state of the security posture, with identified nonconformities and corrective action owners.

 

The Practical Implication

The ISA workbook is not a compliance checklist to be filled in once every three years, even if it is know that this is a common practice among small-medium companies.

It is supposed to be a living snapshot of a security posture. Organizations that treat it as a periodic exercise tend to discover, during reassessment, that improvements logged in the previous cycle were never fully operationalized.

The workbook’s value is highest when it is maintained continuously as a management tool — updated as the threat landscape changes, as new processing activities begin, as infrastructure is modified, and as supply chain relationships evolve.

For companies already operating an ISO 27001-compliant ISMS, the ISA workbook is best understood as the automotive industry’s structured lens on that ISMS: it asks the same fundamental questions about governance, risk, and control, but through the specific context of the VDA’s risk model and the contractual obligations of the automotive supply chain.

Closing the gap between the two is the core of any effective TISAX preparation program.

 

How about doing everything with AI ?

AI can help, but can’t solve the problem for you. Well, you can try, but the results are … well, I better let you test it yourself.
The problem is that you need to run through the AI all your ISMS (all policies, procedures) and compare its content with the controls in ISA.
But this is not everything: you not only need to map policies to controls, you must also provide the right evidence for them. This is very problematic, since no AI at this point in time is able to comprehend the multitude of types of evidence: logs, pictures, powerpoint presentations, xls documents, etc.

I have not seen this working good so far in several AI-powered solutions on the market.

Btw, those solutions are LLMs trained with a lot of context for the respective certification and they are not made to work just for TISAX. That’s why they don’t work good.

 

 

My company offers consulting on how to prepare for a TISAX and ISO27001 audit.

Get in touch with us here: https://www.endpoint-cybersecurity.com/contact/

 

The post TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1) first appeared on Sorin Mustaca – Security & Technology.

How to implement an Information Security Management System (ISMS)

/in

We wrote here https://www.sorinmustaca.com/how-to-nis2-eu-directive/ that the 3rd  step in implementing the requirements of the directive is to establish a cybersecurity framework.

If you haven’t read what a cybersecurity framework means, then you should read article: https://www.sorinmustaca.com/demystifying-cybersecurity-terms-policy-standard-procedure-controls-framework/ .

An ISMS is typically based on the ISO 27001 standard, which provides a framework for establishing, implementing, maintaining, and continually improving information security within an organization.

Establishing a cybersecurity framework is usually achieved together with, or while implementing an Information Security Management System (ISMS) based on a standard like ISO 27001. So, before going to the NIS2 Step 3, I must explain why is it important to have a “good” ISMS.

This article will guide you through the steps to create a solid foundation for the ISMS which uses a cybersecurity framework.

 

Here are the steps you must follow to implement your ISMS:

  1. Get Top Management Support
    • Before you start, synchronize with the top management in order to define company’s goals in this regard. Usually it should be clear, since the company strives to receive a certification like ISO 27001, ISO 16949, TISAX, CSMS, etc..
    • Then secure the commitment and support of senior management by helping them understand the necessary resources and efforts.
    • In all standards that require an ISMS it is imperative to have the commitment of the management because their feedback and support are required in several places along the way.
  2. Scope Definition
    • Define the scope of your ISMS: determine which assets, processes, and locations will be covered by the ISMS.
    • This will help in setting boundaries for your security efforts. Some certifications require an assessment per location and scope, so this needs to be developed properly and in accordance with company’s goals.
  3. Risk Assessment
    • Create policies that help identify and assess information security risks.
    • This involves:
      • How to identifying assets: List all the information assets your organization handles, such as data, hardware, software, and personnel, intellectual property.
      • How to identify threats and vulnerabilities: Determine potential risks and vulnerabilities that could impact your assets.
      • How to assess risks: Analyze the likelihood and potential impact of these risks.
      • How to calculate risk levels: Prioritize risks based on their severity.
  4. Risk Treatment
    • Develop a policy for risk treatment plan:
      • How to implement controls: Select and implement security controls and measures to mitigate identified risks.
      • Document policies and procedures that enforce the creation of security controls.
      • Allocate responsibilities: Assign roles and responsibilities for managing and monitoring security measures.
      • Set risk acceptance criteria: Determine which risks can be accepted, mitigated, or transferred.
  5.  Establish the ISMS Framework
    • Establish the ISMS framework based on ISO 27001:
      • Define information security objectives.
      • Develop an information security policy.
      • Create a risk assessment methodology.
      • Define criteria for risk acceptance.
      • Develop and implement security controls.
  6. Implementation
    • Execute the ISMS based on the established framework:
      • Train employees: Provide information security training to all staff members.
      • Implement security controls: Put in place the technical, administrative, and physical controls identified in your risk treatment plan.
      • Monitor and review: Continuously monitor the effectiveness of your controls and review your risk assessment.
  7. Measurement and Evaluation
    • Regularly measure and evaluate the performance of your ISMS to ensure that it remains effective and aligned with your objectives.
      • Conduct internal audits.
      • Perform security testing (e.g., penetration testing, vulnerability scanning).
      • Analyze security incident data.
  8. Management Review
    • Conduct regular management reviews to assess the ISMS’s performance and effectiveness.
      • Ensure that the ISMS is aligned with the organization’s strategic goals.
      • Make improvements based on review findings.
  9. Continual Improvement
    • Use the results of audits, reviews, and incidents to continually improve the ISMS.
      • Update policies and procedures as needed.
      • Enhance security controls based on new threats and vulnerabilities.
      • Maintain employee awareness and training.
  10. Certification (Optional):
    • If your organization desires ISO 27001 or any other certification, engage an accredited certification body to perform an external audit and certification assessment.
    • Be careful because several certification require a pre-certification or pre-assessment performed either with in-house auditors (internal) or external auditors.
  11. Documentation
    • Maintain detailed documentation of all ISMS activities, including policies, procedures, risk assessments, and audit reports.
    • Maintain a log of all changes in time, because this demonstrates continual improvement and usage.
  12. Training and Awareness
    • Continuously educate and raise awareness among employees regarding information security policies and best practices.
  13. Incident Response and Recovery
    • Develop an incident response plan to address security incidents promptly and effectively.

 

Remember, and make sure that your management remembers as well, that implementing and maintaining an ISMS is an ongoing process. Even if certifications are renewed only after 3 years (usually) it is important that in these 3 years the ISMS is lived.

Regularly update your risk assessments and adapt your security controls to evolving threats and business needs. Continuous improvement is key to the success of your ISMS.

 

The post How to implement an Information Security Management System (ISMS) first appeared on Sorin Mustaca on Cybersecurity.

How-To: NIS2 EU Directive

/in

The NIS2 Directive is a European Union legislative text on cybersecurity that supersedes the first NIS (Network and Information Security) Directive, adopted in July 2016.

NIS vs. NIS2

While the first NIS (Network and Information Security) Directive increased the Member States’ cybersecurity capabilities, its implementation proved difficult, resulting in fragmentation at different levels across the internal market. To respond to the growing threats posed with digitalisation and the surge in cyber-attacks, the Commission has submitted a proposal to replace the NIS Directive and thereby strengthen the security requirements, address the security of supply chains, streamline reporting obligations, and introduce more stringent supervisory measures and stricter enforcement requirements, including harmonised sanctions across the EU.

NIS2 strengthens security requirements in the EU by expanding the NIS scope to more sectors and entities, taking into account

  • the security of supply chains,
  • streamlining reporting obligations,
  • introducing monitoring measures,
  • introducing more stringent enforcement requirements,
  • adding the concept of “management bodies” accountability within companies, and
  • harmonizing and tightening sanctions in all Member States.

To achieve the above mentioned goals, NIS2 requires member states to take a number of measures that forces them to work together:

  • Establish or improve information sharing between member states and a common incident response plan that coordinates with other member state plans
  • Establish a national Computer Emergency Response Team
  • Strengthen cooperation between public and private sector entities

 

In a nutshell, companies can stay compliant with the NIS2 Directive by

  • establishing an effective monitoring system that can detect intrusions, detect suspicious activities, and alert the authorities when necessary
  • developing comprehensive plans that detail how they will respond to an attack and what steps they will take to recover from it.

 

The official website of the EU for the NIS2 Directive has prepared an FAQ with many good questions and answers.

However, what the website is not saying (for good reasons) is how should companies start to prepare for implementing the directive.

 

How to start the compliance path

In order to successfully start implementing the requirements, the following steps should be implemented in this order. We will publish articles about pretty much each of these topics.

 

1.Conduct a gap analysis

Assess your company’s current cybersecurity practices, policies, and infrastructure against the requirements of the NIS2 directive.

Identify any gaps or areas that need improvement to comply with the directive.

Dedicated article:  https://www.sorinmustaca.com/nis2-1-perform-a-gap-analysis/

 

2.Designate a responsible person or team

Appoint an individual or a team responsible for overseeing the implementation of the NIS2 directive within your company. This could be a dedicated cybersecurity team or an existing department with relevant expertise.

Dedicated article: https://www.sorinmustaca.com/nis2-2-designate-a-responsible-person-or-team/

 

3.Establish a cybersecurity framework

Develop or update your company’s cybersecurity framework to align with the NIS2 directive. This framework should include policies, procedures, and technical controls to protect your network and information systems effectively.

Dedicated article: https://www.sorinmustaca.com/nis2-3-establish-a-cybersecurity-framework/

 

4.Perform a risk assessment

Conduct a comprehensive risk assessment of your company’s network and information systems. Identify potential threats, vulnerabilities, and risks that may impact the availability, integrity, and confidentiality of critical systems and data. This assessment will help you prioritize security measures and allocate appropriate resources. Risk management and assessments are an ongoing process. Once one risk assessment is carried out, it is important to schedule regular updates to ensure all steps are maintained.

Dedicated article: https://www.sorinmustaca.com/nis2-perform-a-risk-assessment/

 

5.Implement security measures

Based on the risk assessment findings, implement appropriate security measures to mitigate identified risks. This may include network segmentation, access controls, intrusion detection systems, incident response procedures, encryption, employee training, and regular security updates, among others.

Dedicated article:

 

6.Establish incident response capabilities

Develop an incident response plan and establish procedures for detecting, responding to, and recovering from cybersecurity incidents. Ensure the assigned employees are trained on how to recognize and report security breaches promptly. Business continuity is a very complex topic, which must be planned with a lot of time in advance and it requires extra resources (both human and financial).

Dedicated article:

 

7.Continuously Monitor and review

Implement mechanisms to continuously monitor and assess your network and information systems for potential threats. Regularly review and update your cybersecurity measures to adapt to emerging risks and changes in the threat landscape.

Dedicated article:

 

8. Maintain documentation and records

Keep comprehensive documentation of your cybersecurity measures, risk assessments, incident response activities, and any other relevant information. This documentation will serve as evidence of compliance and may be required for regulatory audits or investigations. A good record might save your company legal and regulatory repercussions in case of a major incident (cyber related or not).

Dedicated article:

 

9.Engage with regulatory authorities

Stay informed about any reporting or notification obligations outlined in the NIS2 directive. Establish communication channels with the relevant regulatory authorities and comply with any reporting requirements or inquiries they may have. NIS2 strives to improve EU-wide communication and sharing of cyber events in order to better prepare answers and reactions. Communication has never been more important than now.

Dedicated article:

 

10. Define KPIs for cybersecurity and measures taken based on them

In order to measure the effectiveness of the cybersecurity, you need to define metrics that allow identifying and quantifying changes. Example of metrics are number of incidents, types of incidents,  how many trainings have been made, how many people were trained, how many pentests were made and how many issues were identified, and many more.

Dedicated article:

 

 

 

The post How-To: NIS2 EU Directive first appeared on Sorin Mustaca on Cybersecurity.

Implementing secure over-the-air (OTA) updates in embedded devices

/in

This is a follow up article related to Secure Booting and Secure Flashing. It is the 5th article related to Strengthening the Security of Embedded Devices

Implementing secure over-the-air (OTA) updates in embedded devices requires careful consideration of various security aspects.

Here are some key steps to implement secure OTA updates:

1. Secure Communication Channel
– Use secure protocols such as HTTPS or MQTT over TLS/SSL to establish an encrypted communication channel between the device and the update server.
– Authenticate the server using certificates to ensure the device is communicating with a trusted source.
– Employ strong encryption algorithms to protect the confidentiality and integrity of the update data during transmission.

2. Code and Firmware Integrity
– Digitally sign the firmware updates using a private key and verify the signature using a corresponding public key on the device.
– Implement mechanisms such as checksums or hash functions to verify the integrity of the received update files.
– Use secure boot techniques to ensure that only trusted and authenticated firmware updates are installed on the device.

3. Access Control and Authorization
– Authenticate and authorize the device before allowing it to download and install updates.
– Implement access control mechanisms to ensure that only authorized devices or users can initiate or perform updates.
– Employ secure user authentication methods such as username/password, certificates, or tokens to validate the device’s identity.

4. Incremental Updates and Rollbacks
– Support incremental updates to reduce the data transfer size and minimize the update time, especially for large firmware files.
– Implement mechanisms to handle update failures or rollbacks in case of errors or compatibility issues during the update process.

5. Secure Storage
– Store the downloaded update files securely on the device to prevent unauthorized access or tampering.
– Use encryption and access control mechanisms to protect the firmware updates from extraction or modification by unauthorized entities.

6. Logging and Auditing
– Maintain logs of OTA update activities, including details such as update versions, timestamps, and device identification.
– Implement auditing mechanisms to track and monitor update processes, detecting any suspicious or unauthorized activities.

7. Regular Security Updates and Patch Management
– Continuously monitor for security vulnerabilities and release patches or updates as needed.
– Implement a robust patch management system to ensure timely deployment of security updates to the embedded devices.

8. Testing and Validation
– Conduct thorough testing and validation of the OTA update process, including functional, security, and compatibility testing.
– Perform vulnerability assessments and penetration testing to identify potential weaknesses in the OTA update implementation.

Last, but not least:

You need to have a secure backend that serves the updates. Make sure that you have configured the server correctly, secure and that it is always updated to the latest version.

 

Follow these best practices to establish a secure OTA update mechanism, ensuring that devices receive timely and secure firmware updates while mitigating the risk of unauthorized access, tampering, or exploitation during the update process.

The post Implementing secure over-the-air (OTA) updates in embedded devices 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.

The Automotive industry’s inadequate approach towards software (in the cars)

/in

Introduction

The automotive industry has witnessed a paradigm shift with the increasing integration of software in vehicles.

Modern cars are no longer just mechanical devices with a motor, wheels and steering; they are now sophisticated machines having dozens of CPUs (called ECU), entire computers, high speed network to connect them (called CAN-bus) and relying on complex highly distributed software systems.

In my opinion, the industry fails to adapt to this new reality and fully embrace the concept of cars as hardware running software has significant consequences.

This may sound contradictory at first, on one side they have these complex systems, on the other side they fail to adapt to this reality.

In this article, I will explore how the automotive industry is not dealing correctly with this transformation and its potential implications.

 

Limited Focus on Software Development and Updates

Traditionally, the automotive industry has primarily focused on hardware design and manufacturing, treating software as a necessary mean to make the hardware work.

This approach results in a lack of emphasis on software development practices and updates capabilities.

While cars are becoming more connected and dependent on software for various functionalities, manufacturers often overlook the importance of continuous software improvements and security updates.

How often do you update the software of your car? Maybe once a year in the best case, usually once every several years or not at all.

It’s not all bad, but think of how many times does Open SSL get updated in a year. Theoretically you should see an update every few months.

 

Insufficient Over-the-Air (OTA) Update Capabilities

Related to updates, Over-the-Air (OTA) updates have gained prominence in the software industry as an efficient means of delivering software fixes, updates, and new features directly to users.

However, the automotive industry has been slow to adopt OTA capabilities on a widespread scale out of their own will.

Limited OTA functionality not only hampers the ability to address software vulnerabilities promptly but also restricts the potential for delivering new features and enhancements to vehicles post-purchase.

Fortunately, there are many initiatives to solve this and even legislation (UNECE R 155 and R 156) that started to make software updates mandatory for releasing new car types.

 

Slow Adoption of Agile SW Development Processes

Agile software development methodologies have become the norm in the software industry due to their flexibility and iterative nature.

However, the automotive industry lags behind in adopting these practices. And this is politically correct formulated.

The OEMs are still working with the V-Model, despite the fact that you hear them talking about sprints, iterations, Scrum, XP programming. All these are actually implemented with small V runs and have little to nothing to do with agility.

The slow pace of development and release cycles in the automotive sector hinders the quick implementation of software fixes and feature enhancements.

This delay not only frustrates customers but also puts their safety at risk by keeping potentially critical issues unresolved for extended periods.

Lack of Consumer Education and Awareness

The general public’s understanding of cars as hardware running software is limited. First when TESLA became an important OEM, the entire world  started to understand how important software is in a car.

Immediately after has the automotive industry started to feel threatened by it and they started to invest more in software, more particularly, in improving the user experience of their cars.

If I make a comparison with the mobile phones in the early 2000, the TESLA is the iPhone while the other OEMs were Nokia and the others. We all know what happened to Nokia because they did not move faster.

Consumers must continue to push the OEMs to enhance the software of their cars, but this is a slow process, because the cars with good software are expensive, and people with money usually don’t look first at the software capabilities of their cars.

 

Inadequate Cybersecurity Measures

As cars become increasingly connected and autonomous, they become vulnerable to cyber threats.

Unfortunately, the automotive industry has been sluggish in implementing robust cybersecurity measures to protect vehicles from potential attacks.

Insufficient attention to software security leaves vehicles open to hacking, which can lead to unauthorized access, data breaches, or even physical harm.

The industry must prioritize cybersecurity and invest in proactive measures to safeguard vehicles and their occupants.

Because cybersecurity is hard to implement, very expensive and requires specialized personnel, no OEM was willing improving their cybersecurity.

This is the reason why the UNECE R155 requires now a Cybersecurity Management System (CSMS) audit in order to allow new vehicle types.

 

If you are an OEM or subcontractor (Tier 1-N) then you may want to know that Endpoint Cybersecurity is offering consulting on how to implement such a CSMS and make it auditable.

Lack of standards

Same as for computers, the IT industry started to exponentially increase only after there were good reasons to use computers. Only after the Internet became main stream have businesses, regular people and families started to buy computers.  So communication or inter-communication was and still is a main factor to buy hardware.

The same is happening with cars: people start to see the need for software in cars and now they start asking for better software. This can only happen if there is a market for software, but to create a market you need standards.

Android Auto and  Apple Car are standards that allow 3rd parties to create apps for the cars, but the offer is extremely small and not really relevant.

In my opinion, only when cars can exchange data either directly (Vehicle to Vehicle communication – V2V) or through some infrastructure (V2I) on a large scale will we see a significant increase in software demand.
Unfortunately, the lack of standards for communication between vehicles is making this process extremely slow.

 

Conclusion

The automotive industry’s failure to fully embrace the concept of cars as hardware running very complex software has far-reaching consequences on the long term.

By neglecting software development, cybersecurity, and collaboration with software experts, OEMs put customer safety and satisfaction at risk. Classical OEMs have started to see too late that better software means more sales and more satisfied customers and reacted too slow to find solutions.

The limited adoption of agile development processes and inadequate OTA update capabilities further hinder progress in this domain.

To address these challenges, the industry must prioritize software as an integral part of vehicle design and manufacturing, invest in cybersecurity measures, foster collaboration with software experts, and educate consumers about the software-driven nature of modern cars.

Only through a comprehensive and proactive approach can the automotive industry truly unlock the potential of cars as hardware running software.

The post The Automotive industry’s inadequate approach towards software (in the cars) first appeared on Sorin Mustaca on Cybersecurity.