Sorin Mustaca's blog

EU Cyber Resilience Act (CRA) – Overview

Sorin Mustaca — Thu, 11 Dec 2025 08:00:57 +0000

Contents

What is the Cyber Resilience Act – CRA

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

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

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

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

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

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

Timeline & Legal Effect

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

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

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

*CABs = Conformity Assessment Bodies

Source: BSI

Key Requirements & Obligations

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

Secure-by-design and secure-by-default

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

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

Lifecycle security

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

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

Vulnerability & incident reporting

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

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

Documentation & traceability

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

CE-marking with security

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

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

Conformity assessments for higher-risk products

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

Why It Matters

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

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

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

CRA Product Classification

Criteria & Examples

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

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

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

Assessment & conformity requirements per class

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

Default Category – non-critical, low inherent risk
Important Class I – higher exposure, widely deployed, could be abused at scale
Important Class II – products with elevated security relevance, including security software and products in Annex III
Critical – core components of cybersecurity, identity, encryption, or essential network infrastructure

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

Examples of Software Products Classification

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

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

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

From Idea to Proof of Concept to MVP – 3 article series

Sorin Mustaca — Tue, 09 Dec 2025 08:00:28 +0000

This is a a developer focused guide in three parts to evolving code, architecture, and processes with the purpose of turning a raw concept into a usable product. This process is one of the hardest parts of software development.

Teams often jump into implementation too early, or they build something polished before testing whether the underlying assumptions hold.

A structured flow—Idea → Proof of Concept (POC) → Minimum Viable Product (MVP)—keeps this journey predictable and reduces waste.

Each stage exists for a specific reason, and each stage demands a different mindset about code quality, design rigor, and security.
For developers, this is also a shift in how code is written, reused, refactored, and prepared for production.
This article explains the journey from the perspective of engineering teams, with practical backend and frontend examples and a clear separation of security activities.

Contents

The Idea

A raw concept describing a problem and a possible technical direction. It has no validated assumptions.

At this point, teams focus on understanding why the problem matters and what a potential solution could look like. No production-ready code exists yet.

Read the full article: From Idea to Proof of Concept to MVP: The Idea stage (1/3)

The Proof of Concept (POC)

A disposable implementation created to validate one or two critical assumptions. The focus is feasibility, not quality.

The POC answers narrow engineering questions such as: Can this API be used to implement the idea? or Can the frontend render this interaction reliably?

Code is expected to be thrown away or heavily rewritten later.

Read the full article: From Idea to Proof of Concept to MVP: The POC stage (2/3) .

The Minimum Viable Product (MVP)

A functional, small-scope product that solves a real user need with the minimum set of features.

Unlike a POC, the MVP requires maintainable code, basic architecture, observability, initial security measures, and repeatable engineering processes.

It is the first version that can be deployed and measured with real users.

Read the full article: From Idea to Proof of Concept to MVP: The Minimum Viable Product – MVP (3/3)

The post From Idea to Proof of Concept to MVP – 3 article series first appeared on Sorin Mustaca's blog.

From Idea to Proof of Concept to MVP: The Minimum Viable Product – MVP (3/3)

Sorin Mustaca — Mon, 08 Dec 2025 08:00:17 +0000

We continue the series of 3 articles with the second one, about the Minimum Viable Product (MVP).

Here is the first article in the series, From Idea to Proof of Concept to MVP: The Idea stage (1/3) and the second article, the From Idea to Proof of Concept to MVP: The POC stage (2/3) .

Contents

3. The Minimum Viable Product (MVP)

Once the team has validated feasibility, the work shifts to building a usable, reliable product with a minimal but complete set of features.
The MVP is the first version that serves real users and collects real feedback.

Code quality, architecture, and processes now matter because the MVP becomes the foundation for all future iterations.

Purpose and Scope

The MVP implements the core value with enough stability, scalability, and security to run in production.
It does not include every possible feature—only the essentials—but it must be well-engineered.

Inputs and Outputs

Inputs include the validated POC, UX designs, refined requirements, and mandatory security needs.
Outputs include a deployable product, operational metrics, user feedback, and a backlog for enhancements.

Actors

The full engineering team is involved: backend, frontend, QA, DevOps, Security, UX, Product, and Operations.
Cross-team communication becomes essential, because making the MVP stable requires alignment across all disciplines.

Engineering Expectations at This Stage

Code Quality and Reuse

Developers now take the core logic from the POC and turn it into production-ready modules.
This involves consistent naming, clear responsibilities, robust error handling, schema validation, and test coverage.
The team extracts reusable libraries, shared components, or service interfaces to avoid future duplication.
The MVP becomes the beginning of a long-term codebase.

Required Technical Changes

Transform API drafts into versioned, documented REST or GraphQL interfaces.
Move throwaway scripts into properly structured modules or services.
Add input validation, sanitization, and schema enforcement.
Introduce unit tests, integration tests, and E2E tests.
Replace temporary mock data with real data pipelines.
Add observability: logs, metrics, traces, dashboards.
Integrate with continuous delivery pipelines.

Process Evolution

The team adopts formal processes:

CI/CD, code reviews with defined guidelines, branching strategies, automated testing, deployment checklists, and observability standards.
Documentation becomes mandatory because the product is no longer experimental.

Backend Example

The recommendation engine becomes now a stable service.
The POC endpoint turns into a versioned API with full request validation, structured logging, retry logic, error mapping, and test coverage.
The integration with the ML service now uses proper authentication, rate limiting, and timeouts.
Monitoring dashboards track latency, throughput, and error rates.

Frontend Example

The rough POC component becomes part of the application’s design system.
It uses reusable UI components, handles loading and error states gracefully, and integrates with the global state store.
Unit tests confirm component behavior, tests validate the full user flow.
Telemetry captures user interactions so the team can validate assumptions after launch.

Security

Security now moves from conceptual and experimental checks to real, enforceable controls.
This includes:

Authentication and authorization integration
Input validation and output encoding
Protection against injection vulnerabilities
HTTPS enforcement and secure cookie settings
Audit logging
Secrets management
Data-handling guarantees for sensitive information

The MVP does not need every advanced security feature, but it must meet the minimum standards required for production—especially if it processes personal or regulated data.

Here is the first article in the series, From Idea to Proof of Concept to MVP: The Idea stage (1/3) and the second article, the From Idea to Proof of Concept to MVP: The POC stage (2/3) .

The post From Idea to Proof of Concept to MVP: The Minimum Viable Product – MVP (3/3) first appeared on Sorin Mustaca's blog.

From Idea to Proof of Concept to MVP: The POC stage (2/3)

Sorin Mustaca — Fri, 05 Dec 2025 08:00:15 +0000

We continue the series of 3 articles with the second one, about the Proof of Concept (POC).

Here is the first article in the series, From Idea to Proof of Concept to MVP: The Idea stage (1/3) .

Contents

2. The Proof of Concept (POC)

The POC is where the team tests a specific risky assumption that could make or break the idea.
The aim is not to build a usable product but to verify that a key technical, architectural, or data-processing challenge is solvable.

POC code is intentionally imperfect. It moves fast and cuts corners. However, it should still be written in a way that reduces friction when extracting reusable parts for the MVP.

What Defines a POC

A POC is short-lived and narrowly focused. It often tests only one or two questions:
Can we integrate with this external system?
Can this algorithm scale?
Can the frontend render a dynamic timeline with the required performance?

The purpose is to generate a clear yes/no answer, not to produce a polished outcome.

Inputs and Outputs

Inputs include the problem statement and hypothesis defined in the idea stage.
Outputs include a working demonstration, documentation of findings, architectural constraints, and a clear decision: continue, pivot, or stop.

Actors

Developers implement the experiment.
Tech leads help evaluate results.
QA may help with validation but does not perform full product testing.
Security engineers review risks that appear during the experiment.

Engineering Expectations at This Stage

Code and Reuse

POC code is disposable, but that does not mean it should be sloppy. Developers should write code that can be extracted later without major re-architecture. This typically means:

Avoid hardcoded credentials, external URLs, or secrets.
Organize files in a simple but meaningful structure.
Implement the core logic in isolated modules instead of burying it inside an ad-hoc script.
Use interfaces or adapters to make future dependency injection easier.

The mindset should be: “This code may be thrown away, but if it works well, we want to reuse pieces of it.”

What Must Change Later

Before integrating POC code into the MVP, the team will need to refactor it: add error handling, consistent logging, tests, and proper abstractions.
In other words, the POC shows the core idea works, but the MVP requires turning this into real engineering.

Process Evolution

The POC often introduces small process steps such as:

Lightweight code reviews
A temporary branch in the repository
Simple build scripts to allow teammates to run the demonstration

This is still not production engineering. CI/CD pipelines and test automation usually come only at the MVP stage.

Backend Example

Suppose the team is building a new recommendation engine.
The backend POC might implement a single endpoint that forwards a request to an external ML service and measures latency and response quality.
Logging might be minimal, validation might be non-existent, and error handling might be crude—but the team learns whether the external ML service meets the performance requirements.

Frontend Example

A frontend POC might involve building a rough React component that displays personalized recommendations using mock data.
The component may not follow the design system, may not handle loading states cleanly, and may ignore error cases.
The goal is to check whether the UI interaction model feels intuitive and whether the state updates behave as expected.

Security

Security engineers examine how the POC handles sensitive data, even if the handling is mocked.
They validate risky paths such as authentication flows, data transformation logic, or external integrations.
The POC must identify whether the solution will require additional compliance measures, encrypted storage, or stricter authentication schemes.
This becomes a mandatory input for the MVP.

The post From Idea to Proof of Concept to MVP: The POC stage (2/3) first appeared on Sorin Mustaca's blog.

From Idea to Proof of Concept to MVP: The Idea stage (1/3)

Sorin Mustaca — Tue, 02 Dec 2025 08:00:15 +0000

Contents

Teams often jump into implementation too early, or they build something polished before testing whether the underlying assumptions hold.

A structured flow—Idea → Proof of Concept (POC) → Minimum Viable Product (MVP)—keeps this journey predictable and reduces waste.

1. The Idea Stage

The idea stage is where the team defines the problem and shapes the first version of the solution direction. The discussion is broad, and uncertainty is still high.

At this point the team is not writing code in any meaningful sense, but rather exploring possibilities, boundaries (technological, legal, usability related), and early risks.

The goal here is not to “design the whole system”. The goal is to understand whether the idea is worth testing and whether the technical foundation appears feasible. This prevents teams from sinking time into something that cannot work or is not worth the investment.

What Makes This Stage Unique

The idea stage is low-cost, low-risk, and exploratory. Developers participate mainly by assessing feasibility, identifying potential architectural constraints, and sketching which components might be reused later. The conversation stays intentionally shallow. Nothing should be implemented that the team cannot abandon without regret.

Inputs and Outputs

Inputs include the product need, early UX sketches, discussions about the problem, and high-level constraints such as data privacy, integration requirements, or performance expectations.
Outputs include a defined problem statement, a preliminary solution outline, and a clear hypothesis that the POC must validate.

Actors

Product managers frame the problem. Engineering leads assess feasibility. UX designers shape initial user interactions. Security architects provide early warnings about potential data-handling or compliance pitfalls.

Engineering Expectations at This Stage

Code and Architecture

No production code is written. If developers create anything, it is lightweight and disposable:
simple mock APIs written in Postman collections, small HTML/JS mockups, or rough OpenAPI drafts.
Nothing created at this stage is meant to be reused directly, but these drafts help teams align on concepts.

However, developers should already think about potential reuse paths.
For instance, if the solution will likely need a shared data-access layer or a reusable front-end state-management module, this is the time to name those opportunities—even if nothing is implemented.

Process Implications

The team documents assumptions, potential dependencies, and cases where reuse might save time later.
There is no review process, no CI pipeline changes, and no branching strategy decisions.
This remains a design and exploration stage.

Backend Example

A backend developer might sketch a future architecture in AWS or draft a sequence diagram showing how the system would communicate with an external payment service.
They might explore the integration constraints by reading documentation and checking rate limits, but no or very little code is produced.

Frontend Example

A frontend developer might draft wireframes and map out how new UI states could fit into existing structures.
They might also check whether existing UI components can be repurposed to avoid re-inventing layout patterns later.

Security and Privacy

Security work is limited to conceptual analysis. No real data is supposed to be used in this stage, so privacy concerns should not exist.
Security architects identify which data categories will be processed, assess whether regulatory frameworks apply, and highlight technical constraints that must be tested in the POC.
No security implementation takes place at this stage, but early awareness helps avoid blind spots later.

Here is the article of the next step: Proof of Concept: https://www.sorinmustaca.com/from-idea-to-proof-of-concept-to-mvp-the-poc-stage-2-3/

The post From Idea to Proof of Concept to MVP: The Idea stage (1/3) first appeared on Sorin Mustaca's blog.

Scrum, Kanban, and Scrumban: A Practical Comparison for Developers (Podcast)

Sorin Mustaca — Wed, 19 Nov 2025 14:49:59 +0000

https://www.sorinmustaca.com/wp-content/uploads/2025/11/mp3.mp3

If you work in software development, you are most probably using one of the well known Agile methodologies like Scrum, Kanban or Scrumban.

But if you are using one of them, for example Scrum, and you feel that you need so

When a software team considers moving from Scrum to Kanban or Scrumban, the biggest question from developers is usually simple: How will my daily work change? This developer‑focused article explains what each method means in practice, how work will feel, and how team behavior shifts in real situations.

Work in Scrum

Scrum creates a fixed rhythm. Developers start each sprint with a clear list of tasks. The goal is to finish what was planned before the sprint ends. This gives structure and focus. You know what you should work on next week because the team committed to it.

In daily life, this means:

You pick work from the sprint backlog, not from the entire backlog. The sprint backlog has been prioritized by the product owner or product manager in advance
You try to avoid starting new items late in the sprint.
Unexpected work is disruptive and often pushed to the next sprint.
Meetings create predictable checkpoints, but sometimes feel heavy.

Example

If a critical bug shows up, the team must discuss whether to break the sprint. This affects the sprint goal and the commitment. It adds friction, especially when priorities shift often.

Work in Kanban

Kanban removes sprint boundaries, so developers operate in a continuous flow. Instead of committing to two weeks of work, you focus on finishing what’s currently in progress. New tasks can enter the board when the team has capacity.

WIP limits become the main tool controlling how much work the team handles at once. These limits reduce context switching and force developers to finish work before starting new items.

In daily work, this means:

You take the next item only when you are below the WIP limit.
If the team is stuck, you help clear bottlenecks instead of grabbing a new task.
Critical issues can be added immediately without waiting for a new cycle.
Planning happens lightly and continuously.

Example

If a new high‑priority issue comes in, the team checks WIP limits. If the WIP is full, someone must finish or unblock an in‑progress task first. This keeps flow healthy and prevents piling up half‑done work.

Work in Scrumban

Scrumban mixes flow with structure. Developers get more flexibility than in Scrum, without the complete free-form nature of Kanban.

Teams often keep periodic planning and reviews, but they remove the strict sprint commitment. Work flows continuously, and developers use WIP limits, pull-based work, and flow metrics.

In daily work, this means:

You still meet for planning, but it’s on-demand, not tied to sprint cycles.
The backlog is always prioritized, so you pull the most important item when you have capacity.
You can integrate urgent work without disrupting a sprint.
Ceremonies exist but are shorter and more focused.

Example

If the backlog starts getting thin, the team schedules a planning session. Developers pull new items when needed. A sudden bug fix can be added to the board right away, without worrying about breaking a sprint.

Detailed Developer-Centric Changes

How Task Selection Changes

Scrum: You choose tasks from the sprint commitment.
Kanban: You choose tasks from a prioritized queue when capacity frees up.
Scrumban: Similar to Kanban, but with optional planning cycles.

Impact on Context Switching

Scrum: Late-sprint pressure can cause multitasking to hit commitments.
Kanban: WIP limits reduce multitasking and shorten cycle time.
Scrumban: Uses WIP like Kanban but keeps some Scrum structure.

Handling Urgent Work

Scrum: Difficult; requires negotiation and re-planning.
Kanban: Easy; just add and pull when possible.
Scrumban: Easy; urgent items flow in naturally.

Developer Autonomy

Scrum: Guided by sprint goals and commitments.
Kanban: High autonomy; developers pull work as the system allows.
Scrumban: Moderate autonomy; structured but flexible.

Planning Overhead

Scrum: Higher; sprint planning can be long.
Kanban: Low; small continuous discussions.
Scrumban: Medium; planning is lighter and triggered by need.

How Your Daily Routine Might Change

Your Day in Scrum

Daily Stand-up: You report status and discuss sprint goals.
You work on the next item in the sprint backlog.
You avoid switching tasks because sprint pressure is high.
Near sprint end, the team pushes to finish committed items.

Your Day in Kanban

Daily Stand-up (optional): You discuss blockers and flow.
You check WIP limits and pull work only when capacity exists.
You focus on finishing work before starting new items.
You may help unblock others instead of taking new tasks.

Your Day in Scrumban

Daily Stand-up: Short check on flow and priorities.
You pull the next high‑priority task when ready.
You follow WIP limits but keep some structure from Scrum.
Planning happens when backlog runs low, not every two weeks.

Which Model Fits Developers Best?

Scrum works well if:

You want predictable cycles.
You value structured goals.
Your work is mostly planned and stable.

Kanban works well if:

Your team gets frequent interrupts (bugs, support issues).
You want less ceremony and faster delivery.
You prefer focusing on flow instead of commitments.

Scrumban works well if:

You like parts of Scrum but want more flexibility.
You want flow improvements without losing structure.
Your work mix includes both planned projects and unpredictable tasks.

The post Scrum, Kanban, and Scrumban: A Practical Comparison for Developers (Podcast) first appeared on Sorin Mustaca's blog.

Delivering often in small increments with Scrum

Sorin Mustaca — Mon, 27 Oct 2025 07:30:39 +0000

Agile software development, particularly using Scrum, has revolutionized the way software is built and delivered.

At its core, Agile embraces iterative and incremental development, a stark contrast to traditional “waterfall” methodologies.

The primary objective is to deliver working software frequently and in small increments, ensuring continuous feedback, adaptability, and rapid value delivery.

However, we know from experience that this is not always the case, and if you have worked long enough in the software development industry, you know that usually, it is not the case.

I wrote before about this and the articles were well read (on LinkedIn), but I still see the need to summarize those articles:

Guide for delivering frequently software features that matter (series) #1/2: the Pillars of successful frequent delivery

Guide for delivering frequently software features that matter (series) #2/2: Challenges and the path forward

Contents

Key principles and practices

In order to frequently deliver small-increment you need to implement several key principles and practices:

Decomposition and User Stories

Break down large features or requirements into smaller, manageable user stories.
A well-formed user story describes a desired functionality from the perspective of an end-user, following the format: “As a [type of user], I want [some goal] so that [some reason].”
These stories are then estimated and prioritized.

Time-boxed Sprints

Scrum operates in short, fixed-length iterations called “sprints,” typically 2-4 weeks long.
Each sprint has a specific goal and a defined set of user stories to be completed.
The time-box ensures a consistent rhythm of delivery and prevents scope creep within an iteration.

Definition of Done (DoD)

A clear and shared “Definition of Done” is crucial.
This defines the criteria that a user story must meet to be considered complete, including coding, testing, documentation, and integration.
This ensures quality and prevents partially finished work from accumulating.

Cross-functional Teams

Scrum teams are self-organizing and cross-functional, meaning they possess all the skills necessary to take a user story from conception to delivery.
This reduces dependencies and streamlines the development process.

Frequent Feedback Loops

Scrum incorporates several built-in feedback loops:

Daily Scrums: Short daily meetings where the team synchronizes, discusses progress, and identifies impediments.
Sprint Demo: At the end of each sprint, the team demonstrates the “potentially shippable increment” to stakeholders, gathering feedback for future sprints.
Sprint Retrospectives: The team reflects on the past sprint to identify what went well, what could be improved, and creates actionable plans for the next sprint.

Prioritization and Backlog Refinement

The Product Owner is responsible for maintaining and prioritizing the Product Backlog, a living list of all desired features.
Regular “backlog refinement” sessions ensure that upcoming user stories are well-understood, estimated, and ready for development.

Now, if you think that by doing this solves all your problems, well, you are not entirely wrong, but also not entirely right.

As with any methodology, there are challenges.

Challenges and Solutions

Large, Undifferentiated Requirements

Stakeholders often present high-level, monolithic requirements that are difficult to break down into small, shippable increments. This can lead to long development cycles and delayed feedback.

Solutions

Invest in User Story Mapping: Collaboratively map out the user’s journey and identify smaller, deliverable “slices” of functionality.
Employ techniques like “Splitting User Stories”: Learn patterns and techniques to effectively break down large stories into smaller, valuable pieces (e.g., by workflow steps, by data type, by role).
Product Owner Focus: The Product Owner plays a critical role in collaborating with stakeholders to refine and decompose requirements, ensuring they are “INVEST” (Independent, Negotiable, Valuable, Estimable, Small, Testable)

Technical Debt and Integration Issues

Rapid delivery can sometimes lead to accumulating technical debt (shortcuts taken for speed) and integration headaches if not managed carefully.

This can slow down future development and make small increments harder to achieve.

Solutions

Prioritize Technical Excellence: Bake in time for refactoring, code quality, and automated testing within each sprint. The Definition of Done should include these aspects.
Continuous Integration and Continuous Delivery (CI/CD): Implement robust CI/CD pipelines to automate builds, tests, and deployments, ensuring that the software is always in a releasable state.
Pair Programming and Code Reviews: collaborative development and peer review usually catch issues early and maintain code quality, but they also slow down delivery. Use with care.

Lack of Clear Prioritization

Without a clear and stable Product Backlog and a Product Owner empowered to make decisions, teams can struggle with shifting priorities, leading to wasted effort and delayed delivery.

Solutions

Empower the Product Owner: Ensure the Product Owner has the authority and understanding to prioritize the Product Backlog effectively, balancing business value, risk, and dependencies.
Regular Backlog Refinement: Conduct frequent and collaborative backlog refinement sessions to ensure upcoming stories are well-understood and ready for development.
Transparency: Make the Product Backlog visible and accessible to everyone, fostering understanding and aligning expectations.

External Dependencies and Silos

In larger organizations, external dependencies (e.g., other teams, external vendors, compliance departments) or internal silos can hinder a team’s ability to deliver independently and frequently.

Solutions

Active Stakeholder Management: The Product Owner and Scrum Master should proactively identify and manage external dependencies, facilitating communication and coordination.
Cross-team Collaboration: Encourage regular communication and collaboration between teams, potentially through “Scrum of Scrums” or other scaling frameworks if applicable.
Shift to a “Value Stream” Mindset: Focus on optimizing the flow of value across the entire organization, identifying and removing bottlenecks that span multiple teams or departments.

The post Delivering often in small increments with Scrum first appeared on Sorin Mustaca's blog.

Navigating AI Standards and Regulations

Sorin Mustaca — Wed, 01 Oct 2025 07:00:50 +0000

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

Model drift and performance risk — AI systems degrade over time, causing hidden failures.
Bias and discrimination — Training data can produce unfair outcomes, raising legal and ethical issues.
Lack of explainability — Black-box models hinder audits, accountability, and trust.
Data protection risks — Models may leak or memorize personal data, creating privacy concerns.
Security vulnerabilities — Adversarial attacks, poisoning, and prompt injection threaten system integrity.
Supply chain dependency — Reliance on third-party models introduces hidden weaknesses.
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:

Adopt common terminology using ISO/IEC 22989 across all teams.
Implement an AI management system aligned with ISO/IEC 42001.
Map AI products against EU risk categories and prepare compliance checklists.
Generate technical evidence such as model cards, data lineage, and test results.
Automate monitoring and incident response to detect model drift and adversarial attacks.
Integrate privacy engineering to ensure alignment with GDPR.
Secure the AI supply chain by tracking third-party components and models.
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.

Policy vs Standard vs Procedure: why, what, how

Sorin Mustaca — Wed, 03 Sep 2025 16:10:42 +0000

Ever wondered what the differences between these terms are?

We use them in GRC very often, but we rarely think what they mean. This creates in time some stretching of these concepts, meaning that their meanings overlap to a certain degree.

A Policy is a high-level, mandatory statement of principles and intent.

A Standard is a mandatory, specific requirement that defines what is needed to comply with a policy.

A Procedure is a detailed, step-by-step set of instructions on how to implement a standard or fulfill a policy.

Policies set goals, standards define the required outcomes, and procedures provide the detailed roadmap to achieve them, forming a hierarchical structure within an organization.

Policy

What is it

A high-level, broad statement of principles, intent, or requirements designed to guide decisions and achieve outcomes.

Purpose

To establish strategic goals, the intent, to support an organization’s mission, comply with laws, or minimize risk.

Answers

Describes the Why must something be done.

Mandatory

Yes, policies are mandatory and define why must something be done. Because of their generic nature of defining the need and not the implementation, they rarely change and are not negotiable.

Example

An IT Security Policy that states the organization will protect sensitive data from unauthorized access.

Standard

What is it

A mandatory, specific technical requirement or rule that provides concrete, measurable details for policy compliance.

Purpose

To provide the specific rules, metrics, and technical configurations necessary to make policies meaningful and effective.

Answers

Describes the What must be done to implement the policy.

Mandatory

Yes, standards are mandatory and define specific configurations, timelines, or processes. Because of their specific nature of describing the implementation, they can change because of the dynamic of the specific industry.

Example

An IT Security Standard for Encryption data that is required by a Policy that states that the organization will protect sensitive data from unauthorized access. The standard will define what encryption algorithm will be used, when to use it, what kind of data should be encrypted and who is responsible for implementing it.

Procedure

What is it

A detailed, step-by-step set of instructions outlining the specific actions to be performed to implement a standard or policy.

Purpose

To provide clear, actionable guidance on how to execute a task and to ensure consistent, repeatable measurable results. It also defines Who should do something and When.

Answers

Describes the How must something be done that is defined by the standard or directly by the policy.

Mandatory

Yes, procedures are mandatory and specify the exact steps an employee must follow. Because they define detailed requirements on how to implement a standard or policy, they change as needed.

Example

A step-by-step instruction set on how to encrypt data in a database, a hard drive, emails and other types of information.

How They Work Together (Hierarchically)

Policy (The Goal): The high-level statement of intent, like an IT security policy.
Standard (The Rule): The specific requirements that support the policy, such as password complexity standards.
Procedure (The Steps): The detailed instructions on how to follow the standard, like the steps to change a password.

This top-down structure ensures that policies are actionable and that goals are met through consistent, documented processes.

What about Guidelines?

Guidelines: are at the bottom, offering recommended and flexible support for the entire framework. They are optional and usually accompany procedures and standards.

NIST Computer Security Resource Center’s Glossary
ISACA’s Glossary
International Organization for Standardization (ISO) framework-specific glossaries.

The post Policy vs Standard vs Procedure: why, what, how first appeared on Sorin Mustaca's blog.

Comparing Annex A in ISO/IEC 27001:2013 vs. ISO/IEC 27001:2022

Sorin Mustaca — Tue, 02 Sep 2025 07:00:34 +0000

I wrote ages ago this article, where I compared briefly the Annex A in the two versions of the standard: https://www.sorinmustaca.com/annex-a-of-iso-27001-2022-explained/

But, I feel that there is still need to detail a bit the changes, especially that now more and more business are forced to re-audit for the newer standard.

Overview of Annex A

Each of these categories encompasses a set of controls designed to address specific aspects of information security management within an organization. These categories encompass policies, procedures, and technical and organizational measures designed to safeguard critical assets, prevent unauthorized access, and mitigate security threats.

The primary purpose of Annex A controls is to guide organizations in selecting appropriate security measures based on their specific context and identified risks. They are not mandatory requirements but serve as best practices for information security management.

Many auditors or practitioners are recommending to not focus exclusively on these controls, because they will not help you in the end to pass the audit. I agree, to not rely exclusively on them, but only to use them as a starting point.

2013 edition:
- 114 controls
- Grouped in 14 control domains (e.g., A.5 Information Security Policies, A.6 Organization of Information Security, etc.).
- Numbering is A.x.y.z.
2022 edition:
- 93 controls (reduced by consolidation, merging, and restructuring).
- Grouped in 4 control themes:
  - Organizational (37 controls)
  - People (8 controls)
  - Physical (14 controls)
  - Technological (34 controls)
- Numbering is A.5–A.8 only, reflecting the 4 control themes.

New Controls Introduced in 2022

ISO/IEC 27001:2022 introduced 11 new controls to address modern risks. Each expands the ISMS scope to include practices that were not explicitly covered in the 2013 edition.

I personally love this addition, because now the standard is in sync with the reality out there. I especially love the A.8.28 Secure Coding, which has been far too long ignored, despite the evidence that all major exploits have been caused by not respecting secure coding standards.

A.5.7 Threat Intelligence
- Requires collection and analysis of threat intelligence.
- Sources: security vendors, government advisories, industry ISACs, internal incident data.
- Outcome: anticipate and defend against emerging attack methods.
A.5.23 Information Security for Use of Cloud Services
- Establishes rules for assessing and managing cloud providers.
- Covers due diligence, contracts, data residency, shared responsibility.
- Goal: ensure cloud adoption is secure and consistent.
A.5.30 ICT Readiness for Business Continuity
- Ensures IT and communications systems are resilient to disruptions.
- Focus: backup, recovery testing, failover, disaster readiness.
- Bridges ISMS with business continuity (ISO 22301).
A.7.4 Physical Security Monitoring
- Monitoring of physical facilities using CCTV, access logs, alarms, motion sensors.
- Detects unauthorized access and environmental hazards.
- Complements access restriction controls.
A.8.9 Configuration Management
- Requires baseline configurations for systems and software.
- Covers patching, secure hardening, prevention of unauthorized changes.
- Reduces risks from misconfigurations.
A.8.10 Information Deletion
- Secure and verified erasure of data when no longer needed.
- Applies to disks, mobile devices, cloud storage, and backups.
- Prevents data recovery by unauthorized parties.
A.8.11 Data Masking
- Techniques to obscure sensitive information.
- Useful in non-production environments and analytics.
- Supports privacy requirements (GDPR, HIPAA, etc.).
A.8.12 Data Leakage Prevention (DLP)
- Deployment of technical and procedural measures to prevent data leaks.
- Examples: DLP software, email scanning, outbound traffic filtering.
- Helps against insider threats and accidental data loss.
A.8.16 Monitoring Activities
- Expands on logging to include continuous monitoring of systems and networks.
- Goal: real-time detection of anomalies and policy violations.
- Supports SOC operations and incident response.
A.8.23 Web Filtering

Restricts or blocks access to malicious or inappropriate websites.
Prevents phishing, malware, and unauthorized browsing.
Often implemented via secure DNS or proxy gateways.

A.8.28 Secure Coding

Mandates secure software development practices.
Includes developer training, code review, automated scanning, use of vetted libraries.
Supports DevSecOps integration and early vulnerability prevention.

Merged Controls

Some 2013 controls were consolidated to reduce duplication:

Logging and monitoring (A.12.4.1–A.12.4.3, 2013) merged into A.8.15 & A.8.16 (2022).
Cryptographic controls (A.10.1.1, A.10.1.2, 2013) merged into A.8.24 (2022).
Access management controls consolidated into A.5.15–A.5.18 (2022).

Removed / Reorganized Controls

No controls were truly eliminated; instead, they were rephrased or merged.

Example: Removal of assets (A.11.2.7, 2013) became part of Return of assets (A.5.9, 2022).
Teleworking and mobile device policies combined under broader organizational controls.

Attributes in Annex A (2022)

A new classification model (“attributes”) was introduced to tag each control.

Categories include:

Control type: Preventive, Detective, Corrective
Security properties: Confidentiality, Integrity, Availability
Cybersecurity concepts: Identify, Protect, Detect, Respond, Recover (aligned with NIST CSF)
Operational capabilities: Governance, Asset management, Identity, Resilience, etc.
Security domains: Align with organizational, people, physical, technological

Why Attributes Matter

This enables flexible mapping to frameworks like NIST, CIS, and especially TISAX.

They make ISO 27001 more practical and flexible.
Help you cross-map ISO 27001 controls to:
- NIST CSF (via cybersecurity concepts)
- CIA triad (via security properties)
- Defense-in-depth planning (via control type)
Useful for gap analysis: you can check whether your ISMS is too prevention-heavy and weak on detection or recovery.
Improve communication with stakeholders: executives, auditors, regulators, or IT operations can each view controls in the lens that matters most to them.

In simple words: Attributes are like tags in a library. They don’t change the book (control), but they let you find it faster depending on whether you search by topic, author, or year.

Since TISAX is my favorite certification (ok, ok, it is a label, but bare with me here) I need to point to the column P. “Reference to other standards”, where this cateogry has been used several times.

Reference “3.1.10” in Cell P50 from the ISA-VDA-6.0.3:

3 -> Cybersecurity Concept

1 -> Detect

10 -> Control Identifier

This ia a Mapping between control A.8.15 (=Logging) und Cybersecurity Concept: Detect von NIST CSF :

Identifier   Control_Code   Title
3.1.1 A.7. X Employee event reporting
3.1.2 A.7. X Information security event reporting
3.1.3 A.5.24 Information security incident planning/prep
3.1.4 A.5.25 Assessment & decision on info security events
3.1.5 A.5.26 Response to information security incidents
3.1.6 A.5.27 Learning from information security incidents
3.1.7 A.7.4 Physical security monitoring
3.1.8 A.8.12 Data leakage prevention
3.1.9 A.8.16 Monitoring activities
3.1.10 A.8.15 Logging

A.8.15 Logging -> mapping -> Cybersecurity Concept: Detect

This is useful for aligning ISO/IEC 27001 with NIST CSF, TISAX, ISA/IEC 62443, and others .

I think there is a lot more to write about them, perhaps in another article.

Summary

2013 Control (Domain)	2022 Control (Theme)	Notes
A.5.1.1 Information security policy	A.5.1 Policies for information security	Mostly unchanged
A.5.1.2 Review of policies	A.5.1 Policies for information security	Merged
A.6.1.1 Roles and responsibilities	A.5.2 Information security roles and responsibilities	Direct
A.6.1.2 Segregation of duties	A.5.3 Segregation of duties	Direct
A.6.1.3 Contact with authorities	A.5.4 Contact with authorities	Direct
A.6.1.4 Contact with special interest groups	A.5.5 Contact with special interest groups	Direct
A.6.1.5 Project management	A.5.8 Information security in project management	Expanded
A.6.2.1 Mobile device policy	A.6.2.1 (2013) merged → A.6.2 (2022 People theme)	Consolidated
A.6.2.2 Teleworking	A.5.10 Acceptable use of information and other assets + A.5.11 Return of assets	Reorganized
A.7.1.1 Screening	A.6.1 Screening	Direct
A.7.1.2 Terms of employment	A.6.2 Terms of employment	Direct
A.7.2.1 Management responsibilities	A.6.3 Management responsibilities	Direct
A.7.2.2 Information security awareness, education, and training	A.6.4 Information security awareness, education, and training	Direct
A.7.2.3 Disciplinary process	A.6.5 Disciplinary process	Direct
A.7.3 Termination/responsibilities	A.5.9 Return of assets	Consolidated
A.8.1.1 Inventory of assets	A.5.9 Inventory of information and other assets	Direct
A.8.1.2 Ownership of assets	A.5.9 Inventory of information and other assets	Consolidated
A.8.1.3 Acceptable use of assets	A.5.10 Acceptable use of information and other assets	Direct
A.8.1.4 Return of assets	A.5.11 Return of assets	Direct
A.8.2.1 Classification of information	A.5.12 Classification of information	Direct
A.8.2.2 Labeling of information	A.5.13 Labelling of information	Direct
A.8.2.3 Handling of assets	A.5.14 Handling of information	Direct
A.8.3.1 Management of removable media	A.8.10 Information deletion	Merged/expanded
A.8.3.2 Disposal of media	A.8.10 Information deletion	Direct
A.8.3.3 Physical media transfer	A.5.14 Handling of information	Consolidated
A.9.1.1 Access control policy	A.5.15 Access control	Direct
A.9.1.2 Access to networks and services	A.5.16 Access to network and network services	Direct
A.9.2.x User access management (all)	A.5.17–A.5.18	Consolidated
A.9.3 User responsibilities	A.5.18 Access rights	Direct
A.9.4 System and application access	A.5.19–A.5.22	Expanded
A.10.1.1 Policy on cryptographic controls	A.8.24 Use of cryptography	Direct
A.10.1.2 Key management	A.8.25 Key management	Direct
A.11.x Physical and environmental controls	A.7.1–A.7.4	Simplified/merged
A.12.1.x Operational procedures	A.8.1–A.8.8	Direct
A.12.4.1–A.12.4.3 Logging & monitoring	A.8.15–A.8.16 Monitoring activities	Merged
A.12.5.x Control of operational software	A.8.7–A.8.9	Consolidated
A.12.6.x Technical vulnerability mgmt.	A.8.8 Management of technical vulnerabilities	Direct
A.13.1.x Network security controls	A.8.20 Network security	Direct
A.13.2.x Information transfer	A.5.14 Handling of information	Consolidated
A.14.1.x Security requirements for IS	A.8.26 Application security requirements	Direct
A.14.2.1 Secure development policy	A.8.28 Secure coding	Expanded
A.14.2.5 Secure system engineering	A.8.27 Secure system architecture and engineering principles	Direct
A.15.1 Supplier security	A.5.19 Supplier relationships	Direct
A.15.2 Supplier service delivery mgmt.	A.5.20–A.5.21	Consolidated
A.16.1.x Incident mgmt.	A.5.25–A.5.27	Direct
A.17.1 Business continuity planning	A.5.29 ICT readiness for business continuity	Expanded
A.18.1 Compliance with legal	A.5.32 Compliance obligations	Direct
A.18.2 Information security reviews	A.5.33 Independent review of information security	Direct

Conclusions

The shift from ISO/IEC 27001:2013 to ISO/IEC 27001:2022 is less about reducing the number of controls and more about modernizing and simplifying them.

While the 2013 version spread 114 controls across 14 domains, the 2022 edition organizes 93 controls into just four clear themes. This makes the standard easier to understand and apply.

The addition of 11 new controls shows how the standard has kept pace with today’s security challenges: cloud services, secure coding, threat intelligence, data leakage prevention, and stronger monitoring.

At the same time, many older controls were merged or rephrased, removing overlaps and making the framework more practical.

Perhaps the biggest improvement is the introduction of attributes. These tags let organizations view the controls through different lenses — confidentiality, integrity, availability, NIST CSF functions, or operational capabilities. That flexibility makes it much easier to map ISO 27001 to other frameworks and compliance requirements.
For organizations, the transition means more than just updating documentation. It is an opportunity to strengthen governance, align with modern practices, and close gaps in areas that were not well covered before, such as cloud and DevSecOps.

The post Comparing Annex A in ISO/IEC 27001:2013 vs. ISO/IEC 27001:2022 first appeared on Sorin Mustaca's blog.

NIS2 Fulfillment through TISAX Assessment and ISA6

Sorin Mustaca — Thu, 31 Jul 2025 15:44:39 +0000

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.

Guide for delivering frequently software features that matter (series) #2/2: Challenges and the path forward

Sorin Mustaca — Fri, 30 May 2025 14:52:38 +0000

Click below for the podcast version (AI generated):

https://www.sorinmustaca.com/wp-content/uploads/2025/05/Guide-for-delivering-2.mp3

Challenges that stop teams to deliver and how to solve them

Objection 1: “Our features are too complex for short sprints”

This is the most common objection I hear, and it reveals a fundamental misunderstanding. The solution isn’t longer sprints or more sprints — it’s better feature decomposition.

Take an e-commerce checkout flow. Instead of trying to build the entire process in one Sprint, break it down: first, just shopping cart management; next, shipping information; then payment processing; finally, order confirmation.

Each piece provides immediate value and teaches you something about user behavior.

The key insight? Users will happily use a partial feature if it solves a real problem for them. Of course, some things can be used, some others don’t.

In the above example, it makes no sense to allow ordering without being able to pay or to enter a delivery address.

It’s important to apply common sense and decompose features in such a way that they provide some value to the user or stakeholder.

Another aspect here is that sometimes you maybe don’t deliver the feature to the users, but you accumulate a few deliverables and then you ship them together, when it makes sense.

The key take out is: there is no receipt for how small or big the features should be in order to allow delivery. Try to decompose them and use common sense when to deliver them: individually or in sets.

Objection 2: “We can’t maintain quality at this pace”

Quality isn’t something you add at the end—it’s built into every step. The teams with the highest delivery frequency actually have the fewest quality issues because they’ve automated their quality checks and made them part of their daily workflow.

But this has a mandatory requirement the fact that automation is there.

If you postpone automation you run eventually in technical debt, which is more expensive to implement later.

Objection 3: “Our stakeholders don’t understand this approach” or “they don’t know what they want”

Stakeholder education is crucial. They need to understand that their active participation is what makes frequent delivery valuable. Regular “show and tell” sessions where stakeholders can actually use the software create enthusiasm and provide immediate feedback.

One technique that works well: frame frequent delivery as risk reduction. Instead of betting everything on a big release, you’re placing smaller, safer bets that can be adjusted based on market response.

Ask for feedback about you delivered and what you plan to deliver. You will see that even if the stakeholders don’t know exactly what they want, they will find it easier to provide feedback or corrections to your plans.

Advanced strategies for teams

Release planning without rigidity

While Scrum focuses on Sprint-level planning, successful teams also think several Sprints ahead. I use story mapping to visualize how features relate to user workflows, which helps identify what should be delivered together versus what can stand alone.

Think of it as planning a road trip—you know your major destinations but remain flexible about the exact route based on what you discover along the way.

Manage dependencies

Dependencies kill delivery predictability. The best teams minimize them through smart architecture choices (like microservices) and careful Sprint planning. When dependencies exist, make them visible through dependency boards that show how different teams’ work interconnects.

Define and collect metrics that actually matter

Velocity is useful for Sprint planning, but business metrics tell the real story.

Did you receive any feedback or complains from customers/users/stakeholders?
How quickly can you respond to customer requests?
How often do users engage with new features?
How many bugs did you have in the last delivery?
Were the features delivered used?

These metrics ensure frequent delivery, which translates to business success.

Building the culture that makes it work

Creating psychological safety

Frequent delivery requires teams to take risks and experiment. This only works when people feel safe to voice concerns, make and admit mistakes.

The goal is not to make mistakes, but to be aware that they might occur and react accordingly.

In my retrospectives, I focus on systems and processes, not individual performance.

When problems arise, we ask “how do we prevent this?” not “who caused this?”

Yes, sometimes it is needed to get direct feedback, but in general, I try to focus this feedback on me and less on other team members.

Real customer collaboration

The Agile Manifesto’s emphasis on customer collaboration isn’t just philosophy—it’s practical necessity.

Whenever possible and feasible, try to involve actual end users in sprint reviews, not just business stakeholders. Their feedback often reveals usability issues that internal teams miss.

Implement user analytics directly in your application to provide continuous insight into how people actually use your software.

Instead of conclusions

Mastering frequent delivery is a journey, not a destination.

The teams I’ve worked with who succeed share three characteristics:

They embrace change as opportunity,
They prioritize working software over comprehensive documentation (who doesn’t ?), and
They value collaboration over rigid processes.

Start with the fundamentals—reliable Sprint execution and solid engineering practices—then layer on advanced techniques as your team matures.

The goal isn’t perfection; it’s continuous progress toward more effective value delivery.

Organizations that master frequent delivery gain significant competitive advantage. They respond quickly to market changes, incorporate user feedback rapidly, and create more engaging work environments where team members see the immediate impact of their efforts.

Your journey starts with the next Sprint. Focus on delivering something valuable to users, measure their response, and use that learning to make the next Sprint even better.

That’s the path to software that actually matters.

The post Guide for delivering frequently software features that matter (series) #2/2: Challenges and the path forward first appeared on Sorin Mustaca's blog.

Guide for delivering frequently software features that matter (series) #1/2: the Pillars of successful frequent delivery

Sorin Mustaca — Wed, 28 May 2025 15:21:33 +0000

Click below for the podcast version (AI generated):

https://www.sorinmustaca.com/wp-content/uploads/2025/05/guide-for-delivering-1.mp3

Guide for delivering frequently software features that matter: the three Pillars of successful frequent delivery

If you’re a software engineer older than 30 years, then you definitely have worked following a non-agile methodology.

Those methodologies are based on a fixed structure, a lot of planning, and hope that everything will go as planned. And they never worked

Small bets, less risk

After helping many teams transform their delivery approach over the past 2 decades, I’ve learned that the most successful software projects share one trait: they deliver working software early and often. Think of it like learning to cook—you taste as you go rather than waiting until the entire meal is prepared to discover it needs salt – or to discover that it has too much salt.

Scrum’s power lies in its ability to turn software development from a high-stakes gamble into a series of small, manageable bets. It basically lowers the risk of creating something that is a failure before it is even released.

Instead of spending months building features that might miss the mark, you deliver value every 2 weeks and course-correct based on real user/stakeholder feedback.

The Three Pillars of successful frequent delivery

1. Sprint Planning that actually delivers value

Here’s where most teams go wrong: they focus on completing tasks instead of delivering outcomes.

In my experience, the magic question that transforms Sprint planning is: “What could we deliver to users at the end of this Sprint that would make them say ‘this is useful’?”

Or maybe, if you’re not that far, think in terms of: what do we have to do in order to be able to have something to show to customers/users/stakeholders?

This shift in thinking leads to what I call “vertical slicing”—delivering complete, end-to-end functionality rather than building in horizontal layers.

Think of instead of spending a sprint on “database framework,” you deliver a complete feature like “user login” that touches database, business logic, and user interface.

Or, instead of having a “GUI framework”, implement a GUI element and make it testable. You will still need to put the base of the GUI framework, but you will likely (or hopefully) implement only those elements needed to deliver that one element.

2. Your Definition of Done (DoD) is your safety net

The Definition of Done isn’t bureaucracy—it’s your insurance policy against the dreaded “90% complete” syndrome. I’ve seen too many teams rush to demo features that weren’t actually ready for users, creating technical debt that haunts them for months.

A solid Definition of Done includes peer reviews, automated tests, security checks, performance validation, and sometimes stakeholder approval.

Think of it as your quality gateway: nothing passes through unless it meets production standards.

3. What enables speed

CI/CD

Continuous Integration isn’t just a nice-to-have—it’s the foundation that makes frequent delivery possible. When code is integrated and tested multiple times, you eliminate the integration nightmares that plague traditional development.

Anything that is manual, especially testing, takes more time on the long run. And in software development you are running a multi stage marathon. Invest in automated End-To-End testing and you invest the time once, not every release cycle.

Main branch development

The teams who excel at frequent delivery have embraced “trunk-based development” where everyone works from the main branch. This forces smaller, more frequent commits and prevents the merge conflicts that can derail Sprint goals.

You might say that this is not always possible – and I even agree. Sometimes you need to branch in order to allow parallel development of larger features, which you don’t want to deliver step-by-step. While I don’t like this approach, I understand that sometimes it makes sense.

But, even in such cases, you can apply the same strategy on the parallel branch: make many small commits so that you can release often and test often.

I’ll stop here for now, but as you can see, there are many challenges that stop teams from releasing often.

I’ll address this in the next article from this series.

The post Guide for delivering frequently software features that matter (series) #1/2: the Pillars of successful frequent delivery first appeared on Sorin Mustaca's blog.

Time for demystifying “failure is the key to success”

Sorin Mustaca — Thu, 03 Apr 2025 14:12:03 +0000

Time for some other type of posts, not related to what I usually write about. But it bothers me to see so many “shiny” posts on Linkedin, when I know for sure that the reality is so much different than what they write there.

So, time to demystify a bit this topic.

This is a follow-up of the post Beyond “Move Fast and Fail Fast”: Balancing Speed, Security, and … Sanity in Software Development (with Podcast).

Failure is the key to success ?

I’ve been seeing a lot of news and articles, especially on LinkedIn, about this whole “failure is the key to success” and “fail fast” mantras that are constantly being thrown around, especially in the tech world.

You see all these founders and CEOs talking about their past flops like … they’re badges of honor.

While I understand that it is kind of cool to write about failures when you are finally successful, I can’t ignore the feeling that they’re glossing over the actual sting of it all.

Honestly, who wants to fail?

Nobody !

Nobody I know, me included, starts a project, pours their heart and soul, and probably a good chunk of money into it, hoping it all crashes and burns.

That’s just not how it works. Really, it is not !

We all dream of the big win, the thing that takes off and makes a real difference.

I’ve had my share of stumbles, projects that never quite got off the ground, ideas that looked brilliant on paper but just didn’t resonate with anyone else and big projects that just failed at some point.

And let me tell you, each one of those felt like what they were: failures.

There’s the initial disappointment, of course, that sinking feeling when you realize things aren’t going the way you planned. But then comes the self-doubt, the questioning of your own abilities, and maybe even a bit of embarrassment.

It’s not a pleasant experience, no matter how you try to spin it. Trying to sell it is a “good, positive experience” just isn’t right.

I can unterstand that after you are very successful, you can look back with nostalgy and talk about past failures. But honestly, how many entrepreneurs out there can really say that they had the big hit and success, so that they can be able to do that? Very, very few.

What comes after

In time, you come to realize, though, is that the real value in those less-than-successful ventures wasn’t the failure itself, but what came after.

It was the post-mortem, the digging into what went wrong:

Was it a flawed concept from the start?
Did we misjudge the market?
Were there technical hurdles we couldn’t overcome?
Or maybe, did I or we make some crucial mistakes along the way in how I or we approached things?

Those moments of reflection, those sometimes painful analyses, are where the real learning happens.

It’s not the failure that magically makes you smarter; it’s the effort you put into understanding why it happened.

It’s about picking apart the pieces, figuring out what you could have done differently, and making a conscious effort not to repeat those same missteps next time.

All that remains after this is that you just struggle to continue and to continue slowly to be better.

Are failures opportunities in disguise?

Don’t get me wrong: while I don’t think failure is something to strive for, or something we should pretend is a joyous occasion, I do believe it’s an inevitable part of the journey.

And maybe, just maybe, those moments of falling short are actually opportunities in disguise. But usually they are just that – failures.

They force us to take a hard look at ourselves and our work, and if we’re able and willing to do that, they can ultimately guide us towards a better path.

So, those who out there who It’s not about celebrating the failure, but about honoring the lessons learned in its wake. And that, I think, is the real truth of it all.

PS: What do you think of those “ex-Google”, “ex-Facebook” and other ex-es ? Aren’t they also a form of failures ?

Instead of conclusions

I asked an AI to give me some examples of entrepreneurs who failed multiple times big and then succeeded:

Steve Jobs: As mentioned before, he was famously fired from Apple, the very company he co-founded. His subsequent venture, NeXT, struggled in the market, although the technology developed there was instrumental in his eventual return to Apple and the innovations that followed. Even upon his return, Apple had its share of less successful products before the iPod, iPhone, and iPad revolutionized the industry.
James Dyson: While not strictly software, his journey in developing the bagless vacuum cleaner involved an astounding 5,126 failed prototypes over 15 years. This relentless pursuit of a technological innovation despite repeated setbacks is a powerful example of perseverance in the tech-adjacent hardware world.
Evan Williams: Before co-founding Twitter, Evan Williams was involved in a podcasting platform called Odeo. This venture struggled to gain traction, especially after Apple launched iTunes with podcast support. However, the experience and some of the ideas from Odeo eventually led to the creation of Twitter, a massively successful social media platform.
Richard Branson: While known for ventures across various industries, Branson’s Virgin Group has had its share of failures in the tech and related sectors. For example, Virgin Digital, his attempt to compete with iTunes, didn’t achieve lasting success. Virgin Cars, an online car retailer, also closed down after a few years.
Bill Gates: Before co-founding the tech giant Microsoft, Bill Gates and Paul Allen had an early business venture called Traf-O-Data. This company aimed to process and analyze traffic data, but it ultimately failed. The lessons they learned from this early experience, however, likely contributed to their later success with Microsoft.

The post Time for demystifying “failure is the key to success” first appeared on Sorin Mustaca's blog.

Beyond “Move Fast and Fail Fast”: Balancing Speed, Security, and … Sanity in Software Development (with Podcast)

Sorin Mustaca — Mon, 03 Mar 2025 18:34:32 +0000

https://www.sorinmustaca.com/wp-content/uploads/2025/03/Beyond_Move_Fast_and_Fail_Fast.mp3

Move fast and fail fast

In software development, the mantra “move fast and fail fast” has become both a rallying cry and a source of considerable debate.

It champions rapid iteration, prioritizing speed and output, often at the perceived expense of meticulous planning and architectural foresight. This approach, deeply intertwined with the principles of agile development, presents a stark contrast to the traditional model of lengthy planning cycles, rigorous architecture design, and a focus on minimizing risk through exhaustive preparation.

Fail fast

The allure of “fast” is undeniable. In today’s competitive market, speed to market can be the difference between success and failure. Rapid prototyping allows for early user feedback, facilitating continuous improvement and ensuring the product aligns with real-world needs. In essence, it’s about validating hypotheses quickly and pivoting when necessary. This iterative approach, inherent in agile methodologies, fosters a culture of adaptability and responsiveness, crucial in environments where change is the only constant.

So, “fail fast” refers mostly to a fast validation of the MVP (minimum viable product) and drop it if the results are unsatisfactory. This is, in general, very good because it is an optimal usage of resources.

Speed vs. Integrity

However, the emphasis on speed can raise legitimate concerns, particularly regarding security and long-term architectural integrity.

The fear is that a “move fast” mentality might lead to shortcuts, neglecting essential security considerations and creating a foundation prone to technical debt.

This is where the misconception often lies: “fast” in this context does not necessitate “insecure” or “bad.” Rather, it implies a prioritization of development output, which can, and should, be balanced with robust security practices and a forward-thinking architectural vision.

But, how can this forward-thinking be achieved, when the team is focused mostly on delivering value to validate with customers the assumptions made?

The key lies in understanding that agile development, when implemented effectively, incorporates security and architecture as an integral part of the process.

Concepts like “shift left security” emphasize integrating security considerations early in the development lifecycle, rather than as an afterthought.

Automated security testing, continuous integration/continuous deployment (CI/CD) pipelines with security gates, and regular security audits can be woven into the fabric of rapid development, ensuring that speed does not compromise security.

Validating early in the process means also that the not only the product is proven to meet the expectations, but also the architecture it is built upon.

The traditional approach

On the other hand, the traditional approach, with its emphasis on extensive planning and architecture, offers the perceived stability of a well-defined blueprint.

However, this approach carries its own risks. The extended planning phase can lead to delays, rendering the final product obsolete by the time it reaches the market. Moreover, the rigid nature of pre-defined architectures can hinder adaptability, making it difficult to respond to unexpected changes in user needs or market dynamics. The risk of “failing due to delays and lack of adaptation” is a real threat in fast-paced environments.

The modern software developer must navigate this tension, finding a balance between speed and stability. This involves adopting a pragmatic approach, leveraging the benefits of agile methodologies while mitigating the associated risks.

This can involve:

Establishing clear security guidelines and incorporating them into the development process. Having a SSDLC is mandatory when having to deliver fast.
Prioritizing a modular and adaptable architecture that can evolve with changing requirements. Modules should be possible to be implemented quickly and dropped without a lot of pain if they prove to be unsuccessful.
Implementing robust testing and monitoring to identify and address issues early on. A CI/CD pipeline will allow the team to focus more on delivering new features than testing and integrating all the time.
Fostering a culture of continuous learning and improvement, where developers are encouraged to experiment and innovate, while also being accountable for security and quality.
Utilizing threat modeling and risk assessment early in the design process. Threat modeling contains a risk assessment, which when done properly will prevent major issues later.

Instead of Conclusions: my experience

Ultimately, the most effective approach is not about choosing between “fast” and “slow,” but about finding the right cadence of delivering value for each specific project .

The goal is to deliver constantly small pieces of code that bring value while avoiding failure altogether. If deliverables are constantly validated, a failure can only be of a small deliverable increment, which can be either quickly improved, completely removed or entirely replaced with something else.

Important is to learn from it quickly and adapt, ensuring that software development remains a dynamic and evolving process.

When I run a project, I define the goal and the high level path to achieve that goal. Sometimes this path is clear, sometimes many experiments are needed, and some will fail, some will succeed.

The post Beyond “Move Fast and Fail Fast”: Balancing Speed, Security, and … Sanity in Software Development (with Podcast) first appeared on Sorin Mustaca's blog.

Project management with Scrum (with Podcast)

Sorin Mustaca — Fri, 14 Feb 2025 08:15:45 +0000

https://www.sorinmustaca.com/wp-content/uploads/2025/02/Project_Project_management_with_Scrum.mp3

They can’t mix, can they?

Seems like a contradiction to talk about classical project management and the best agile software development methodology ?

But let me ask you this: ever feel like traditional project management is great for mapping out the big picture but falls short when it comes to the nitty-gritty of execution?

And conversely, while Scrum is fantastic for rapid iteration and delivering value quickly, it sometimes lacks that long-term strategic view?

If you feel this, then you’re not alone!

Yes, they can mix

Let’s talk about how to get the best of both worlds when managing projects: having a solid long-term plan and the flexibility to adapt and deliver quickly.

Sometimes it feels like traditional project management is great for the big picture but not so hot on the details, right?

And Scrum is awesome for getting stuff done in short bursts, but can sometimes lose sight of the overall direction.

Turns out, a lot of teams are finding a sweet spot by mixing these two. Think of it like having a good map for your road trip and a sturdy vehicle to handle any bumps along the way.

So, what does each approach bring to the party?

Classical Project Management: The Grand Plan

Imagine classical project management as your strategic guide. It’s all about figuring out the project’s scope, setting those long-term goals, marking important milestones, and creating a project plan.

We’re talking budget, resources, timeline – the whole thing.

It’s about answering the big questions:

What are we trying to do?
When does it need to be finished?
How much will it cost?
Who’s in charge of what?

This is great for having a clear vision and a roadmap. It helps everyone stay on the same page and lets you track progress.

The tricky part? Sometimes those detailed plans can go out of date pretty fast. Because things change, right?

Scrum: Getting Things Done

Now, Scrum is your agile friend. It’s built for doing things in short bursts, perfect for navigating the twists and turns of, well, pretty much any project.

You break the project into smaller chunks – sprints – usually 2 weeks long. Each sprint has specific goals, and the team works together to deliver something useful by the end.

Scrum is all about talking to each other a lot, having quick daily meetings, and checking in regularly. It’s about being flexible and delivering value bit by bit.

Scrum is great at handling feedback, adding new stuff, and showing real results quickly.

The thing is, on its own, Scrum might need that long-term direction that classical project management provides.

The Perfect Mix: Working Together, Delivering Fast

The magic happens when you put these two together:

You use classical project management to set the long-term vision, make the initial plan, and decide where you’re going. This gives you a good map.
Use Scrum to actually get there, one sprint at a time. Scrum becomes your engine for delivering value along the route laid out by classical project management.

Here’s a simple way to think about it:

Big Picture: Classical project management sets the overall project scope, goals, and timeline. Everyone knows what the target is.
Breaking it Down: The project gets broken down into smaller pieces, often using the classical project management approach. This makes the work manageable.
Sprint Time: The Scrum team takes a chunk of work and plans it out for a sprint. They figure out what they can realistically do in that time.
Daily Check-ins: The team has quick daily meetings to talk about progress, any problems, and adjust as needed. Keeps everyone in sync.
Show and Tell: At the end of each sprint, the team shows what they’ve built and gets feedback. This feedback helps plan future sprints.
Getting Better: Regular team meetings let everyone think about how they’re working and find ways to improve.

So, by mixing classical project management and Scrum, you get the best of both worlds. You have a clear long-term plan and the flexibility to adapt and deliver quickly. It’s a great way to work together, deliver fast, and make sure projects stay on track while being able to handle whatever comes up.

The post Project management with Scrum (with Podcast) first appeared on Sorin Mustaca's blog.

Comparing “Records of Processing Activities” (ROPA) and “Data Protection Impact Assessments” (DPIA) (with Podcast)

Sorin Mustaca — Wed, 05 Feb 2025 09:38:31 +0000

Understanding ROPA and DPIA: Key GDPR Concepts for Tech Companies

Podcast of this article:

https://www.sorinmustaca.com/wp-content/uploads/2025/02/ROPA-DPIA_Chapter_0.mp3

Contents

Let’s explore two essential components of GDPR compliance: Records of Processing Activities (ROPA) and Data Protection Impact Assessments (DPIA).

ROPA provides a comprehensive overview of your data handling, while DPIA focuses on assessing and mitigating risks for specific, higher-risk activities.

Records of Processing Activities (ROPA): Your Company’s Data Map

Think of ROPA as your company’s data map. It documents every step of the data journey, from collection to deletion.

It’s about what data you collect, including why, how, and with whom you share it.

A well-maintained ROPA is crucial for demonstrating GDPR compliance and building trust with your users.

What ROPA Covers

Purposes of Processing: Be specific! Instead of “marketing,” say “personalized email marketing based on user browsing history” or “improving product recommendations based on user purchase data.”
Categories of Data Subjects: Identify who the data relates to (e.g., customers, employees, website visitors, app users).
Categories of Personal Data: List the types of data you process (e.g., name, email address, IP address, location data, browsing history, biometric data).
Recipients of Personal Data: Specify who you share data with (e.g., cloud storage providers, marketing agencies, analytics platforms, law enforcement). Include both internal and external recipients.
Transfers to Third Countries: If you transfer data outside the EU, document the safeguards in place (e.g., adequacy decisions, standard contractual clauses).
Data Retention Periods: Specify how long you keep different types of data. This should be based on legal requirements and business needs.
Technical and Organizational Security Measures: Briefly describe the security measures you have in place to protect the data (e.g., encryption, access controls, data masking).

ROPA Examples for Tech Companies

Social Media Platform: A social media platform’s ROPA would detail processing activities related to user profiles, posts, photos, friend connections, messaging, targeted advertising, and data analytics. It would specify data categories (e.g., profile information, IP address, location data, browsing history), purposes (e.g., personalized content delivery, targeted advertising, platform improvement), and recipients (e.g., advertising partners, analytics providers).
SaaS Provider: A SaaS provider’s ROPA would document processing related to user account management, data storage, application usage tracking, customer support interactions, and billing. It would include details about data categories (e.g., user credentials, company data, usage logs), purposes (e.g., providing the service, improving performance, customer support), and recipients (e.g., cloud hosting providers, payment processors).
Mobile App Developer: A mobile app developer’s ROPA would cover data processing within the app, such as collecting user location data for personalized recommendations, accessing contacts for social features, or tracking in-app purchases. It would detail the data categories (e.g., location, contacts, purchase history), purposes (e.g., personalized recommendations, social features, in-app advertising), and recipients (e.g., location services providers, advertising networks).

Data Protection Impact Assessments (DPIA): Proactive Risk Management

A DPIA is a more in-depth analysis triggered by specific processing activities that pose a high risk to individuals.

With the DPIA you’re identifying risks, and also finding ways to mitigate them and demonstrating that you’ve considered data protection all the way.

What DPIA Covers

Description of the Processing Operations: Clearly explain the planned processing, including the purposes, data categories, and processing methods.
Necessity and Proportionality: Justify why the processing is necessary and proportionate to the intended purpose. Are there less intrusive ways to achieve the same goal?
Assessment of Risks to Individuals: Identify potential risks to individuals’ rights and freedoms, such as identity theft, discrimination, loss of control over their data, or reputational damage. Consider the likelihood and severity of these risks.
Measures to Address the Risks: Describe the measures you will implement to mitigate the identified risks. This might include technical measures (e.g., encryption, anonymization), organizational measures (e.g., access controls, data minimization policies), and legal measures (e.g., data processing agreements).
Consultation with Data Protection Authorities (DPA): In some cases, you may need to consult with your local DPA before carrying out high-risk processing.

DPIA Examples for Tech Companies

Facial Recognition Software: A company developing facial recognition software for security purposes would need a DPIA. The DPIA would assess risks related to accuracy, bias, potential for misuse, and impact on individuals’ privacy and freedom of movement. Mitigation measures might include strict access controls, data anonymization techniques, and clear guidelines for use.
AI-Powered Recommendation Engine: A company launching a new AI-powered personalized recommendation engine that analyzes large volumes of user data would require a DPIA. The DPIA would analyze the risks of profiling, discrimination, and loss of privacy. Mitigation measures could include data minimization, differential privacy techniques, and user consent mechanisms.
Biometric Authentication: A company implementing large-scale biometric authentication for access control would need a DPIA. The DPIA would evaluate the risks of data breaches, identity theft, and potential misuse of biometric data. Mitigation measures could include secure storage of biometric data, multi-factor authentication, and strict access controls.

ROPA and DPIA: Similarities and Differences

ROPA and DPIA are like two sides of the same coin – both essential for responsible data handling under GDPR. They work together to ensure your data processing is transparent, accountable, and respects individuals’ privacy.

Similarities

GDPR Compliance:
- Both ROPA and DPIA are mandated by the GDPR (Articles 30 and 35, respectively).
- They’re not optional; they’re legal requirements for many organizations.
Focus on Data Protection:
- At their core, both aim to protect individuals’ rights and freedoms related to their personal data.
- They promote a privacy-first approach to data processing.
Documentation is Key:
- Both require thorough documentation.
- ROPA is the documented record of your processing activities, and DPIA results in a documented risk assessment report.
- Good record-keeping is crucial for demonstrating compliance.
Accountability:
- Both contribute to demonstrating accountability.
- By maintaining a ROPA and conducting DPIAs, you show that you’re taking data protection seriously and actively managing risks.

Differences

Scope:
- ROPA covers all your data processing activities,
- DPIA focuses on specific, high-risk processing activities.
- Think of ROPA as the big picture and DPIA as a focused close-up.
Purpose:
- ROPA’s primary purpose is to document and provide transparency about all your data processing.
- DPIA’s main goal is to assess and mitigate the risks of particular processing activities that are likely to be high-risk.
Requirement:
- ROPA is a general requirement for most organizations (especially those with over 250 employees or those processing sensitive data).
- DPIA is only required when processing activities are likely to result in a high risk to individuals’ rights and freedoms. It’s triggered by specific circumstances.
Outcome:
- ROPA produces a comprehensive record of your processing activities.
- DPIA results in a risk assessment report outlining potential risks and the measures you’ll take to mitigate them.
- One is a detailed inventory, the other a focused risk analysis.
Timing:
- ROPA is an ongoing requirement – you need to keep it updated as your processing activities change.
- DPIA is conducted for specific projects or plans before they are implemented. It is a point-in-time assessment.

In a nutshell:

ROPA is your ongoing data processing inventory, demonstrating your overall approach to data protection.
DPIA is a targeted risk assessment for specific, potentially high-risk projects, ensuring you’ve considered and addressed privacy concerns before they become a problem.
Both are essential tools in your GDPR compliance toolkit.

The post Comparing “Records of Processing Activities” (ROPA) and “Data Protection Impact Assessments” (DPIA) (with Podcast) first appeared on Sorin Mustaca's blog.

AI vs. (secure) software developers

Sorin Mustaca — Thu, 12 Dec 2024 07:00:45 +0000

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

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.
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.
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.
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.
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.
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's blog.

Accelerating feature delivery in software development

Sorin Mustaca — Sat, 16 Nov 2024 08:07:21 +0000

My company develops security products for all major operating systems. We work with startups and with big companies, all striving to develop features (functional and non-functional) as fast and as good as possible.

While on the first view this seems like a contradiction, there are actually ways of implementing exactly this.

For security software development teams aiming to deliver features more frequently, streamlined processes and efficient workflows are essential.

You guessed, the keywords are agile methods with the related activities such as automated testing, strategic prioritization, agile delivery, efficient workflows, regular and early feedback.

Below are several approaches that emphasize frequent and reliable delivery.

Define requirements with speed in mind

Clear, concise requirements set a strong foundation for quick delivery. Ensuring each feature has straightforward objectives and well-defined acceptance criteria reduces delays caused by back-and-forth clarifications. For security-focused teams, requirements should include key security considerations without overloading the development process. By clarifying expectations from the start, developers can stay on track, avoiding unnecessary revisions and accelerating overall delivery. This being said, also do not change the direction too often (called Pivoting). If you don’t allow feature to “sit”, the product will never reach maturity.

Setup incremental, agile delivery

Breaking down feature development into small, manageable increments supports faster delivery. Rather than waiting for a full release, an incremental approach allows developers to deliver small updates frequently. This Agile-inspired method brings quick wins, shortens feedback cycles, and lets teams adjust direction as needed based on real-world usage. Incremental delivery ensures that new functionality reaches users sooner, making the product more responsive to changing needs.

Optimize for efficiency

Security doesn’t have to slow down delivery. By embedding secure coding practices into the team’s daily workflows, developers can build security right into each feature rather than adding it at the end. Code reviews focused on security can be streamlined with checklists or automated tools, keeping the process efficient. This “security-first” mindset ensures that features remain secure while minimizing delays, as there’s no need for last-minute security fixes.

Invest in CI/CD

Automated testing is key to quick, reliable feature deployment. Automated tests that cover basic functionality and security requirements provide instant feedback, allowing developers to identify and address issues faster. Implementing continuous integration (CI) tools that automatically trigger these tests during development helps the team validate new features on the go. By automating tests, the team gains more time for development and can release updates with minimal manual intervention.

Integrating DevSecOps practices into the development pipeline enables seamless security without slowing down delivery. Automated security checks within the CI/CD pipeline provide fast, reliable security validations, allowing developers to address issues before deployment. This approach keeps the pipeline moving smoothly, as security checks become an integrated part of the process, rather than an additional step that slows down delivery.

Encourage collaborative and efficient workflow

Encourage open communication between developers, security teams, and testers to streamline workflows. Collaborative sessions for discussing roadblocks or coordinating on shared goals help prevent bottlenecks. An open environment where team members share updates and resolve issues collectively accelerates progress by addressing concerns in real time. By emphasizing collaboration, teams can work faster, catching potential blockers early and adapting quickly to new requirements.

Use regular retrospectives to identify and remove delivery obstacles

Post-release retrospectives focused on delivery efficiency help identify and eliminate roadblocks. By analyzing each release or sprint for delays and other issues, teams can identify specific pain points in the development or deployment process. These retrospective sessions allow the team to adjust practices and improve their ability to deliver quickly, refining the workflow with each iteration.

The post Accelerating feature delivery in software development first appeared on Sorin Mustaca's blog.

Understanding NIS2 and DORA: What executives need to know

Sorin Mustaca — Fri, 25 Oct 2024 06:14:42 +0000

Contents

These days businesses are subject to increasing regulatory scrutiny, particularly regarding cybersecurity and operational resilience.

Two significant EU regulations, NIS2 (Network and Information Systems Directive 2) and DORA (Digital Operational Resilience Act), outline mandatory requirements for organizations. Failure to comply can result in severe penalties. It is essential for executives to understand how these regulations impact their operations, including supply chain security and potential fines for non-compliance.

What is NIS2?

We wrote extensively about NIS2, so we will add here only an executive summary (obviously ).

NIS2 is the successor to the Network and Information Systems Directive (NIS1) and seeks to enhance the cybersecurity posture of essential and important entities across the EU. The revised directive expands its scope and introduces stricter obligations, focusing on improving risk management, incident response, and resilience across sectors that provide critical services to society.

Applicability

It applies to Essential and Important entities:

Essential entities: Sectors like energy, transport, banking, financial market infrastructures, healthcare, and digital infrastructure.
Important entities: Sectors like waste management, food supply, postal and courier services, and social media platforms.

NIS2 extends beyond large organizations, requiring medium and large-sized businesses in these sectors to comply with the directive’s provisions.

Key Requirements

Risk management and incident response: Organizations must implement comprehensive security measures that cover organizational, technical, and human resource elements to manage and respond to cybersecurity risks.
Supply chain security: The regulation mandates that organizations address supply chain risks and ensure that third-party suppliers meet the necessary cybersecurity standards.
Incident reporting: Incidents with significant impact must be reported to competent authorities within 24 hours of detection.
Cross-border cooperation: Entities must cooperate with national and EU authorities for threat intelligence sharing and coordinated incident responses.

Is it mandatory?

Yes, NIS2 is mandatory for organizations operating within the scope of the directive across the EU. Public and private entities that fall under essential and important sectors are required to comply.

Penalties

The penalties under NIS2 are severe, with a tiered system based on the entity’s classification (essential or important):

For essential entities, the fines can be up to €10 million or 2% of the company’s total global annual turnover, whichever is higher.
For important entities, fines can reach €7 million or 1.4% of the total global annual turnover, whichever is higher.

In addition to financial penalties, non-compliance can lead to regulatory actions, including audits, corrective measures, or even suspension of operations in critical cases.

What is DORA?

The Digital Operational Resilience Act (DORA) is an EU regulation that focuses on ensuring that financial institutions and their critical ICT providers maintain robust operational resilience against cyber threats and ICT-related disruptions. DORA forms part of the EU Digital Finance Strategy and aims to harmonize ICT risk management across the financial sector.

Applicability

DORA applies to a wide range of financial institutions and ICT service providers, including:

Financial institutions: Banks, investment firms, insurance companies, payment service providers, crypto-asset service providers, and trading venues.
ICT third-party providers: Providers of essential IT services, such as cloud services, data management, and software providers, that work with financial institutions.

Key Requirements

ICT Risk Management Framework: Organizations must establish and maintain effective risk management frameworks that cover ICT-related risks. These frameworks must include regular risk assessments, incident detection mechanisms, and recovery plans.
Incident reporting: Organizations are required to report major ICT-related incidents to authorities, usually within a short time frame. The reporting should include root cause analysis and the steps taken to mitigate the impact.
Third-party oversight: DORA mandates stringent oversight of third-party ICT service providers. Contracts must include terms regarding business continuity, security, and regular audits.
Resilience testing: Financial institutions are required to conduct regular testing, including penetration testing, to assess their operational resilience.

Is it mandatory?

Yes, DORA is mandatory for all financial institutions and critical ICT service providers operating in the EU. The regulation ensures that financial systems remain operationally resilient in the face of disruptions, especially those stemming from cyberattacks.

Penalties

Non-compliance with DORA carries significant financial penalties. The fines and sanctions depend on the severity and impact of the breach. As of recent updates, penalties for non-compliance can be up to:

€2.5 million or 1% of the total annual global turnover of the organization.

Additionally, regulators may impose restrictions on operations, remove licenses, or mandate corrective actions to address vulnerabilities.

Comparison: NIS2 vs. DORA

Aspect	NIS2	DORA
Scope	Critical sectors across industries	Financial sector and ICT suppliers
Application	Public and private sector organizations	Financial institutions and critical ICT service providers
Key Focus	Cybersecurity, incident response, risk management	Operational resilience, ICT risk management
Incident Reporting	24 hours for notification	Strict timelines, specific to ICT incidents
Third-Party Requirements	Supply chain security is critical	Strong emphasis on ICT third-party providers
Penalties	Up to €10 million or 2% of global turnover (essential entities), €7 million or 1.4% of global turnover (important entities)	Up to €2.5 million or 1% of global turnover
Risk Management	Risk management policies are mandatory	ICT risk management framework required
Sector-Specific	Broader range of sectors	Financial sector-specific
Testing	No mandatory testing	Regular penetration testing required
Cross-border Cooperation	Required between member states	Required between financial supervisory authorities

Financial institutions: DORA or NIS2 or both?

Financial institutions can be classified as essential or important entities under the NIS2 Directive, especially given their critical role in the economy.

As a result, they can be subject to the obligations of both NIS2 and DORA.

Under NIS2, essential and important entities include sectors that are vital for societal and economic stability, such as banking and financial market infrastructures. Financial institutions providing services like payment systems, credit services, and investment can fall under these categories. Therefore, financial institutions that meet the size and significance criteria of NIS2 must comply with its cybersecurity requirements. This includes risk management, incident reporting, and securing supply chains.
Under DORA, financial institutions are specifically regulated to ensure their digital operational resilience against ICT-related risks. This regulation addresses the entire financial sector and its critical ICT service providers.

In essence, a financial institution can fall under both NIS2 and DORA due to its dual roles in providing essential services and requiring robust cybersecurity and operational resilience measures.

Non-compliance with either can lead to significant penalties.

Thus, financial institutions must ensure they meet the demands of both regulations to manage risks across cybersecurity and operational resilience

Conclusion

Both NIS2 and DORA are essential frameworks designed to enhance cybersecurity and operational resilience within the EU.

While NIS2 covers a broad range of critical sectors, DORA is highly specialized for the financial industry.

For CEOs and CxOs, understanding the nuances of each regulation is key to ensuring compliance, particularly when considering the supply chain and third-party providers.

The penalties for non-compliance can be significant, including steep fines and operational restrictions, making it essential to prioritize robust cybersecurity and resilience strategies across the organization.

How-To create Security User Stories

Sorin Mustaca — Sat, 19 Oct 2024 07:01:09 +0000

In the previous article, we explored how Scrum enables teams to add security to the backlog and prioritize it based on risk.

Incorporating security into the SDLC ensures that security is not an afterthought but an integral part of the development process.

Security User Stories are specific, actionable items that articulate the security needs of the software in the same way functional requirements are handled.

Writing Security User Stories complements this process by providing clear, actionable security requirements that can be integrated into each sprint.

By treating security stories with the same importance as functional stories, developers can ensure that the software they build is not only feature-complete but also secure.

What are Security User Stories?

Security User Stories are descriptions of security requirements written from the perspective of the user or the system. They focus on specific security needs, ensuring that the software not only meets functional requirements but also protects against potential vulnerabilities. Just like traditional user stories that describe a feature or function, security stories express how the system should behave securely.

A typical Security User Story follows the same format as a regular user story:

As a [role], I want [goal], so that [benefit].

For example, a Security User Story for web development might look like this:

“As a user, I want my session to expire after 15 minutes of inactivity, so that my account is protected from unauthorized access.”

Why are Security User Stories Needed?

Security is often treated as an afterthought, addressed late in the development process or after an incident occurs. This reactive approach leads to vulnerabilities, increased technical debt, and costly security fixes post-release. Security User Stories shift this paradigm by making security an integral part of the development process from the outset. They are necessary for several reasons:

Proactive Security Integration: By incorporating security needs into the backlog from the start, you ensure that security considerations are addressed in each sprint, reducing the risk of vulnerabilities later on.
Clear Requirements for Developers: Security User Stories provide clear, actionable security requirements, helping developers understand exactly what is expected to make the software secure.
Accountability: Writing security stories holds the development team accountable for implementing security features and allows for better tracking of security tasks within the development cycle.
Risk Mitigation: When security is considered early in the SDLC, potential security issues are identified and addressed before they become significant risks. This aligns with the concept of “Shift Left” security, where security is integrated into earlier stages of the development process.

How to Use Security User Stories

Security User Stories should be written as part of the Product Backlog and prioritized based on the level of risk or impact. Here’s how to use them effectively:

Collaboration with Security Experts: Work with security professionals to identify potential threats and risks specific to the application or platform. They can help create and refine security user stories based on threat modeling and vulnerability assessments.
Define Acceptance Criteria: Each Security User Story should have clear, testable acceptance criteria. These criteria define when the story is considered complete and what tests should be performed to verify the security requirement has been met.
Prioritize Based on Risk: Security User Stories should be prioritized just like functional features, based on their importance. Stories that address high-risk vulnerabilities, such as authentication or encryption, should be prioritized early in the development cycle.
Regular Review and Updates: Security is an evolving field. As new threats emerge, Security User Stories should be reviewed and updated to address the latest vulnerabilities. Regular threat assessments help ensure the backlog remains current.

Examples of Security User Stories Across Different Platforms

1. Web Application Development

Web applications face numerous security threats, from SQL injection to Cross-Site Scripting (XSS). Below are examples of Security User Stories that address common web application security issues:

“As a user, I want my password to be stored securely using a strong hashing algorithm like bcrypt, so that my account is protected from unauthorized access.”
“As a system, I want to validate all user inputs server-side to prevent injection attacks.”
“As a system, I must use HTTPS for all data transmitted between the client and the server, to ensure data confidentiality.”
“As a user, I want to be logged out after 15 minutes of inactivity, so that my session cannot be hijacked.”

2. Windows Software Development

Windows software may face risks such as privilege escalation or malicious code execution. Security User Stories for Windows development could include:

“As a user, I want my application to run with the minimum necessary privileges, so that the system is protected from privilege escalation attacks.”
“As a system administrator, I want all logs to be stored securely and be tamper-proof, so that I can audit user activities reliably.”
“As a developer, I want the application to verify all digital signatures before executing code, to ensure the code has not been tampered with.”
“As a system, I want to enforce Data Execution Prevention (DEP) to prevent malicious code from executing in the memory.”

3. Android App Development

Mobile applications, particularly Android apps, face unique security challenges, such as improper storage of sensitive information and unauthorized access to device features. Examples of Android-related Security User Stories include:

“As a user, I want my sensitive data (e.g., passwords, payment information) to be encrypted using the Android Keystore system, so that my data is safe even if the device is compromised.”
“As a developer, I want the app to request only the necessary permissions, so that the user’s privacy is respected.”
“As a user, I want to be required to authenticate using biometrics before making sensitive changes, such as resetting my password, to ensure the security of my account.”
“As a system, I want to securely store session tokens and prevent them from being accessible via insecure storage mechanisms (e.g., SharedPreferences).”

4. iOS App Development

iOS apps must adhere to strict privacy and security guidelines, and improper handling of user data can lead to severe breaches. Below are Security User Stories specific to iOS development:

“As a user, I want all sensitive information (e.g., authentication tokens) to be stored in the iOS Keychain, so that my data is protected from unauthorized access.”
“As a system, I want to ensure that network communication is secured using TLS 1.2 or above, to protect against man-in-the-middle attacks.”
“As a user, I want to enable Face ID for sensitive transactions (e.g., payments), to ensure that unauthorized users cannot perform critical actions.”
“As a developer, I want to implement App Transport Security (ATS) to ensure all connections are encrypted.”

Conclusion

Security User Stories are a powerful tool for developers to integrate security into their development process. By writing clear, actionable stories with defined acceptance criteria, development teams can proactively address security risks while ensuring that they meet functional requirements.

Whether you’re building a web app, Windows software, or mobile applications for Android or iOS, incorporating Security User Stories into the backlog ensures that security remains a priority throughout the SDLC.

With this approach, developers can create secure, reliable software that meets the needs of both the business and the users.

The post How-To create Security User Stories first appeared on Sorin Mustaca's blog.

Bitcoin fraud through (hacked?) WordPress installations

Sorin Mustaca — Fri, 18 Oct 2024 16:00:44 +0000

I don’t usually write anymore about phishing attempts, but this one draw my attention due to large amount of emails and to variety of websites being used.

Of course, I would not write “massive” if I would have received 1-10, but I receive about 10 a day. Fortunately, almost all go to Spam folder. Gmail is doing a good job!

Let’s have a look:

Subject:
- is always “Login Details”
- has a prefix, marked with [], usually the name of the website or some slogan of the targeted website.
Body:
- starts with “Username: the target phishing website, where the user needs to go to reset the password. Looks similar to the one targetted
- a random very large amount of USD, followed by one or more of “BTC pdu diq”.
- Contains a password reset link in the format:
  https://[valid domain]/wp-login.php?action=rp&key=[key]&login=[username].
- The username is the phishing website mentioned above
- The structure mimics the real WordPress password reset URLs, using the action=rp parameter and a legitimate reset key, making it seem genuine.
- Domain Mismatch: The reset links use real, but unrelated domains. These are not associated with the recipient in any way.
- The email does not match any WordPress installation the recipient is associated with, which is a critical red flag.

I verified a couple of targeted domains to see if they are compromised, but they did not appear to be so anymore.

This step gives the user the legitimity I guess… But why would a user who has nothing to do with the domain targeted would actually click?

Funny fact:

All those keys have a time to live of probably 24h or less, so by the time they get in an inbox, they are very likely to be expired.

The phishing website:

It is always a bitcoin mining account. To convince the user to click, it displays a large amount of money.

Since I was anyway in a sandbox, I said that I have nothing to lose if I continue.

So, the next thing is Figure 2

Figure 1: Continue

Figure 2: Sence of emergency: click now or you lose so much money!

The final screen is very strange: it shows a continuously increasing counter, and a lot of random numbers.

Looking at the source code, it is indeed random..

Figure 3: Randomness

I thought that the site is damaged by my sandbox and I forgot about it while writing this article.

After a few minutes, the screen changes and I was asked to “talk” to a payment manager if I want to be paid.

It looks and feels like a bot, because all it does is to ask me for a bank account.

The trick is: If you want the $92K then you must pay a fee of 0.12%.

Final thing… Register to a convertor website to purchase the 64$ into BTC and transfer them to the fraudster.

Conclusion:
I don’t get it.. Who would go through so much trouble to reach this point?

I guess that one must be desperate enough to want the $92K in order to pay the 64$.

The post Bitcoin fraud through (hacked?) WordPress installations first appeared on Sorin Mustaca's blog.

Delivering secure software in an agile way

Sorin Mustaca — Wed, 09 Oct 2024 06:30:04 +0000

Contents

Agile Software Development: Why It’s Better

Traditional development methodologies, such as the Waterfall model, struggle to keep up with the need for quick iterations, frequent releases, and adaptability to changing requirements.

Agile software development addresses these challenges by emphasizing flexibility, collaboration, and continuous delivery. Agile methodologies break down the development process into smaller, manageable chunks, allowing teams to rapidly deliver working software while remaining responsive to feedback and changes.

Among the various Agile frameworks, Scrum stands out as one of the most widely adopted and effective methods for managing software development. It provides a simple, yet powerful framework, that helps teams continuously deliver high-quality products, adapt to dynamic customer needs.

Using Scrum for software development

Scrum is a lightweight agile framework designed to manage complex product development through iterative and incremental processes. It focuses on delivering working software in short cycles known as Sprints and emphasizes collaboration, accountability, and continuous improvement. This structure makes Scrum particularly well-suited for dynamic environments like software development, where requirements often change throughout the project lifecycle.

Scrum offers several key advantages that make it ideal for software development:

Rapid Iteration and Feedback: Scrum’s short sprints allow teams to deliver working software frequently, which gives stakeholders the chance to review progress, provide feedback, and make necessary adjustments after each sprint.
Adaptability to Change: In Scrum, the Product Backlog is continuously updated and reprioritized, enabling teams to adapt to changing business needs or customer demands without disrupting the overall workflow.
Focus on Delivering Value: Scrum emphasizes delivering the highest business value early by prioritizing the most critical features. This ensures that the product development effort aligns with the business objectives.
Cross-Functional Teams and Collaboration: Scrum fosters collaboration between cross-functional teams, which enables them to tackle complex problems and deliver complete product increments without relying on external resources.
Simplicity and Structure: Scrum’s structured roles, artifacts, and ceremonies create a clear framework for managing work, making it easier for teams to stay organized, focused, and accountable.

With these features, Scrum empowers software development teams to build high-quality products faster and with greater alignment to customer needs. The framework’s flexibility and focus on delivering continuous value make it the ideal choice for modern software development.

Non-Functional features in Scrum

Non-functional features, or non-functional requirements (NFRs), refer to critical system attributes like security, usability, and resource consumption that ensure the software performs optimally and meets quality standards. Unlike functional features, which are visible to users, non-functional features define how the system behaves under specific conditions and are essential to the system’s overall success.

Examples of Non-Functional Features

Security: Protecting the system from unauthorized access and vulnerabilities.
Usability: Ensuring that the system is user-friendly and easy to navigate.
Resource Consumption: Optimizing the system’s use of resources, such as memory, CPU, and bandwidth, to ensure efficient operation.

Though non-functional features are not always visible to users, they are crucial to the long-term stability and security of the product. Managing these features properly within the Scrum process is essential to ensure the product meets both user and business expectations.

Incorporating Non-Functional Features in the Scrum Backlog

Non-functional features can be added to the Product Backlog similarly to functional ones, ensuring that they are prioritized, addressed, and tested throughout the development cycle.

Here’s how:

Create explicit user stories for non-functional features

Define clear user stories for non-functional aspects like security or performance. For instance:

- “As a user, I want my personal data to be encrypted, ensuring my privacy and security.”
- “As a system administrator, I want the application to scale seamlessly for up to 10,000 concurrent users.”
  For security in particular, these user stories are usually called “security user stories”.
Prioritize based on business impact
Work with stakeholders and the Product Owner to prioritize non-functional features that have the greatest impact on the system’s overall performance and security.
Define Acceptance Criteria
Ensure that non-functional user stories include measurable acceptance criteria, such as performance benchmarks or security requirements, so they can be properly tested.
Integrate NFRs into the Definition of Done
Non-functional features should be part of the team’s Definition of Done (DoD), ensuring that each sprint delivers not only functional but also secure, performant, and stable increments.
Define a certain ratio between functional and non-functional requirements in the backlog
Ensure that the non-functional user stories like security user stories have always a reserved space in the backlog. For example, you can have 60% functional u.s., 20% non-functional u.s., 20% bug fixes u.s.

Security in Software Development

Security is one of the most critical non-functional features in software development. It involves protecting systems, data, and users from potential cyber threats and vulnerabilities.

As software becomes more complex, the attack surface increases, making robust security measures essential.

Failing to integrate security into the development process can lead to severe consequences such as data breaches, loss of customer trust, and regulatory penalties.

The challenge of adding security user stories to the backlog

One of the main challenges of integrating security into the Scrum backlog is that security requirements are often non-functional and may not be directly tied to a specific feature.

Security is also a broad area, encompassing various elements (authentication, encryption, vulnerability management), which can make it difficult for the Product Owner to prioritize and create detailed security user stories.

Another challenge is balancing security tasks with feature development. Development teams (especially the product owner) may be tempted to focus on customer-facing features, leaving security tasks to the end, which increases the risk of vulnerabilities slipping through.

How to add security to the Scrum backlog

1. Create security user stories

Translate security requirements into actionable user stories that fit into the Scrum process. These stories should describe the security needs from a user’s perspective. Examples include:

“As a user, I want my password to be hashed and stored securely, ensuring the safety of my account.”
“As a system administrator, I want the application to implement multi-factor authentication for increased security.”

By creating security user stories, the development team can directly address specific security needs in each sprint.

2. Prioritize security based on risk

Work with security experts and stakeholders to prioritize security tasks based on the potential risk they mitigate. Security stories that address high-risk areas, such as vulnerabilities in authentication or data handling, should be prioritized over less critical tasks.

3. Define clear acceptance criteria for security stories

Ensure that each security user story has measurable acceptance criteria. These criteria should be specific and testable, such as:

“Passwords must be hashed using a minimum of SHA-256 encryption.”
“The system must reject any user input that contains SQL injection attempts.”

Clear acceptance criteria help the development team understand what is required to achieve “done” for a security story.

4. Integrate security into the Definition of Done

Security tasks should be part of the Definition of Done for every sprint. This ensures that security checks, such as code reviews and penetration testing, are performed before a feature is considered complete. By making security a core part of the development process, teams can prevent security from being treated as an afterthought.

5. Conduct Security Spikes

If security requirements are complex, consider using spikes to explore potential solutions or gather more information. For example, a spike could involve researching encryption libraries or conducting a security audit to identify vulnerabilities. Spikes help teams plan and implement security features more effectively in future sprints.

6. Regularly Review and Update Security Stories

As security threats evolve, new vulnerabilities may emerge that need to be addressed. Regularly review and update the backlog to ensure that the most current security threats are covered. This could involve adding new security stories or reprioritizing existing ones based on changing risk assessments.

7. Define a fixed ratio for security user stories

As mentioned above for non-functional requirements, it is usually a very good practice to have fixed percentages of non-functional user stories. Since security user stories are non-functional user stories, you can enforce this way that security topics don’t get forgotten.

Conclusions

Agile development provides the flexibility and adaptability needed to keep up with today’s dynamic software environments, and Scrum stands out as probably the best framework for delivering software quickly while ensuring continuous feedback and improvement.

By incorporating both functional and non-functional features into the Scrum backlog, teams can ensure that they are delivering a product that is not only feature-rich but also secure, performant, and user-friendly.

Security, in particular, is an essential non-functional requirement that must be treated as a priority throughout the development lifecycle. By integrating security user stories into the backlog, prioritizing based on risk, and ensuring security is part of the Definition of Done, software development teams can create resilient, secure systems without sacrificing agility or speed.

The post Delivering secure software in an agile way first appeared on Sorin Mustaca's blog.

Understanding Defense in Depth in IT Security

Sorin Mustaca — Tue, 13 Aug 2024 08:00:16 +0000

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

The answers in various groups were mostly related to:

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

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

Defense in Depth

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Create a Threat Model for your endpoints

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

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

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

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

Potential Risks on an Endpoint

Malware Infections
- Risk: Viruses, Trojans, ransomware, spyware, and other malicious software can compromise the system.
- Security Controls:
  - Antivirus/anti-malware software
  - Regular system scans and updates
  - Application whitelisting
  - Sandboxing suspicious files
  - Backup with versioning control (good for ransomware attacks)
Unpatched Software
- Risk: Vulnerabilities in outdated software can be exploited by attackers.
- Security Controls:
  - Automated patch management systems with rollback functionality
  - Regular software updates
  - Vulnerability scanning tools
  - Centralized patch distribution
Unauthorized Access
- Risk: Unauthorized users may gain access to the endpoint, leading to data breaches or system compromise.
- Security Controls:
  - Strong password policies
  - Multi-factor authentication (MFA)
  - User account control (UAC)
  - Role-based access controls (RBAC)
Data Theft
- Risk: Sensitive data may be copied, transmitted, or stolen from the endpoint.
- Security Controls:
  - Full disk encryption (e.g., BitLocker)
  - Data loss prevention (DLP) tools
  - USB port control and removable media encryption
  - Secure backup solutions
Physical Theft
- Risk: The endpoint itself may be physically stolen, leading to loss of data and access to the network.
- Security Controls:
  - Physical security measures (locks, secure storage)
  - Device tracking and remote wipe capabilities
  - Full disk encryption
  - BIOS/UEFI passwords

Drive-by Downloads
- Risk: Malicious websites may automatically download and install malware without user consent.
- Security Controls:
  - Web filtering and browser security plugins
  - Regular updates to browsers and plugins
  - Application whitelisting
  - Disabling automatic execution of scripts in browsers
Network-based Attacks
- Risk: Attackers may exploit vulnerabilities in the network to compromise the endpoint.
- Security Controls:
  - Personal firewall
  - Network segmentation
  - Secure VPN connections
  - Intrusion detection and prevention systems (IDPS)
Misconfigured Security Settings
- Risk: Insecure configurations can leave the endpoint vulnerable to attacks.
- Security Controls:
  - Regular security audits and compliance checks
  - Hardening guides and best practices (e.g., CIS benchmarks)
  - Group policies for centralized management
  - Security baselines and templates

Potential Human Risks

Phishing Attacks

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

Insider Threats

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

Instead of conclusion: Balancing Security and Usability

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

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

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

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

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

The post Understanding Defense in Depth in IT Security first appeared on Sorin Mustaca's blog.

ISO 27001:2022 and TISAX: overlaps and differences

Sorin Mustaca — Wed, 03 Jul 2024 17:44:17 +0000

Contents

Introduction

ISO 27001:2022 and TISAX VDA ISA 6.0 are two prominent standards in the realm of information security management, particularly within the automotive industry. While ISO 27001 provides a global framework for establishing, implementing, maintaining, and continually improving an information security management system (ISMS), TISAX (Trusted Information Security Assessment Exchange), based on the VDA ISA (Information Security Assessment) framework, is tailored to meet the specific needs of the automotive sector.

This article delves into the nuances of these two standards, highlighting their overlaps, the ways in which TISAX leverages ISO 27001, and the distinct features that set TISAX apart.

Overview of ISO 27001:2022

ISO 27001:2022 is the latest revision of the internationally recognized standard for information security management. It provides a comprehensive approach to managing sensitive company information so that it remains secure. This involves a risk management process, which includes people, processes, and IT systems by applying a risk management process.

Key Features of ISO 27001:2022

Risk-Based Approach: Emphasizes the identification and management of risks through a continuous improvement process.
Annex A Controls: Contains 93 controls categorized under four themes: Organizational, People, Physical, and Technological.
PDCA Cycle: The Plan-Do-Check-Act cycle is integral for continuous improvement.
Context of the Organization: Requires understanding of internal and external factors impacting information security.
Leadership Commitment: Highlights the importance of top management’s involvement in the ISMS.

Overview of TISAX VDA ISA 6.0

TISAX, a standard specific to the automotive industry, is based on the VDA ISA (Verband der Automobilindustrie Information Security Assessment) catalog. TISAX ensures that automotive manufacturers and suppliers meet strict information security requirements to protect sensitive information.

Key Features of TISAX VDA ISA 6.0

Sector-Specific: Tailored specifically for the automotive industry.
VDA ISA Catalog: Based on the VDA ISA framework, which is a detailed checklist of requirements and controls. It is split in several areas of interest:
- Information security – containing everything that belongs to an ISMS
  - IS Policies and Organization
  - Information Security Policies
  - Organization of Information Security
  - Asset Management
  - IS Risk Management
  - Assessments
  - Incident and Crisis Management
  - Human Resources
  - Physical Security
  - Identity and Access Management
  - Identity Management
  - Access Management
  - IT Security / Cyber Security
  - Cryptography
  - Operations Security
  - System acquisitions, requirement management and development
  - Supplier Relationships
  - Compliance
- Prototype Protection – focused on physical and cyber protection of prototypes
- Data Protection – focused on policies for protecting privacy and secrets
Assessment Levels: Comprises different levels of assessment depending on the type of information and its criticality.
Labeling System: Provides a TISAX label indicating compliance, which can be shared with partners within the automotive ecosystem.
Focus on KPIs: VDA ISA provides a large set of examples on how to measure certain controls effectively.

Overlaps between ISO 27001:2022 and TISAX VDA ISA 6.0

While TISAX and ISO 27001 serve different purposes, they share several common elements. TISAX leverages the fundamental principles of ISO 27001, creating a robust framework that is both comprehensive and specific to the automotive sector.

In the VDA ISA 6.x (and previous) there are the columns “Reference to other standards” (column P) and “Reference to implementation guidance” (column Q) which point to known standards. Of course, there is no coincidence that the most reference standard is the ISO 27001 in both versions 2022 and 2013.

In the guidance we usually see reference to the Annex A of the ISO 27001 standard (both versions).

In the column W there is “Further information” containing explanations of what can be described by the respective control.

Risk Management

Both ISO 27001 and TISAX emphasize a risk-based approach to information security. ISO 27001 mandates a formal risk assessment process, while TISAX incorporates this through the VDA ISA requirements, ensuring that organizations identify and manage risks relevant to the automotive industry.

Control Objectives and Controls

ISO 27001:2022 and TISAX VDA ISA 6.0 share a common structure in terms of control objectives and specific controls. Many of the controls listed in Annex A of ISO 27001 are reflected in the VDA ISA catalog, ensuring a comprehensive approach to securing information.

While this is a common trait shared by the standards, the TISAX is making use of other standards than ISO 27001: NIST, BSI other ISO standards.

Continuous Improvement

Both standards advocate for continuous improvement. ISO 27001’s PDCA cycle and TISAX’s periodic reassessment and updating of security measures ensure that organizations continually enhance their security posture in response to evolving threats.

TISAX VDA ISA has a sheet called “Maturity Levels” containing descriptions of the Maturity Levels 0 to 5.

Documentation and Record-Keeping

ISO 27001 requires detailed documentation of the ISMS, including risk assessments, policies, and procedures. TISAX also mandates thorough documentation as part of its assessment criteria, ensuring that organizations maintain a clear record of their security practices.

Third-Party Management/Suppliers Relationships

Third-party risk management is a critical component in both standards. ISO 27001 includes controls for managing supplier relationships and ensuring their compliance with information security requirements. Similarly, TISAX places a strong emphasis on securing information exchanged with suppliers and partners, crucial for maintaining the integrity of the automotive supply chain.

Differences between ISO 27001:2022 and TISAX VDA ISA 6.0

Despite their overlaps, ISO 27001 and TISAX have several distinctions, reflecting their different scopes and target audiences.

Industry Focus

ISO 27001 is a generic standard applicable to any organization, regardless of its sector. TISAX, however, is designed specifically for the automotive industry, addressing unique challenges such as the secure exchange of data between manufacturers and suppliers.

Assessment Process

ISO 27001 involves a formal certification process conducted by accredited bodies, leading to ISO 27001 certification. TISAX, on the other hand, employs a mutual assessment model where organizations are assessed by ENX approved audit providers, and successful assessments result in a TISAX label. This label can then be shared with other automotive industry stakeholders, facilitating trust and compliance.

Control Specificity

While ISO 27001 provides a broad framework of controls applicable to various industries, TISAX’s controls are highly specific to the automotive sector. The VDA ISA catalog includes detailed requirements for protecting manufacturing data, ensuring compliance with industry-specific regulations, and safeguarding automotive intellectual property.

Levels of Assessment

TISAX introduces different levels of assessment (Basic(Must and Should), High, and Very High) depending on the sensitivity and criticality of the information being protected. ISO 27001 does not have a tiered assessment system but rather a uniform certification standard.

Focus Areas

TISAX places significant emphasis on physical security, secure development of automotive products, and compliance with industry-specific legal requirements. ISO 27001, while comprehensive, does not delve into sector-specific issues with the same level of detail.

Commercial vs Open standards

ISO 27001 is an open international standard governed by the Internation Standards Organisation (ISO). The TISAX trademark is owned by the organization ENX, formed by many OEMs in automotive sector.

Implementation of TISAX Using ISO 27001

TISAX leverages ISO 27001’s framework to build a robust and industry-specific information security system. Many organizations begin with ISO 27001 certification and then adapt their ISMS to meet the additional requirements of TISAX.

Integration of Standards

Foundation in ISO 27001: Organizations often establish a basic ISMS in accordance with ISO 27001. This includes conducting risk assessments, implementing controls, and ensuring continuous improvement.
Customization to TISAX Requirements: Once the foundational ISMS is in place, organizations tailor it to meet TISAX requirements, which may involve additional controls specific to automotive data security and third-party management.
Assessment and Labeling: Organizations undergo a TISAX assessment conducted by an approved audit provider. Successful completion results in the issuance of a TISAX label, demonstrating compliance with industry-specific security requirements.

Benefits of Integration

Integrating ISO 27001 with TISAX offers several benefits:

Streamlined Compliance: Simplifies the process of meeting both generic and sector-specific security requirements.
Enhanced Trust: The TISAX label, backed by ISO 27001’s rigorous framework, enhances trust among automotive industry partners.
Cost Efficiency: Leveraging ISO 27001 as a foundation reduces duplication of effort and resources in implementing security measures.

Conclusion

ISO 27001:2022 and TISAX VDA ISA 6.0 represent critical standards for information security, particularly within the automotive sector. While they share common principles such as risk management and continuous improvement, TISAX’s industry-specific focus and detailed requirements for automotive set it apart. By leveraging the robust framework of ISO 27001, organizations can start to effectively implement TISAX, ensuring comprehensive protection of sensitive automotive data and fostering trust within the industry.

Understanding the connections between these standards and their unique requirements is very important for organizations aiming to achieve a high level of information security and compliance.

The post ISO 27001:2022 and TISAX: overlaps and differences first appeared on Sorin Mustaca's blog.

Understanding the SOC 2 Certification

Sorin Mustaca — Tue, 21 May 2024 12:30:32 +0000

Contents

Introduction

SOC 2 (Service Organization Control 2) certification is a framework designed by the American Institute of CPAs (AICPA) to help organizations manage customer data based on five Trust Service Criteria: , confidentiality,processing integrity, availability, security and privacy. This certification is crucial for service organizations that store or process customer data in the cloud.

Comparison of Various SOC Certification Versions

SOC 1 (Service Organization Control 1)

Focus: SOC 1 is centered around internal control over financial reporting. It is particularly relevant for service organizations that impact their clients’ financial statements.
Users: Primarily used by financial auditors and companies that outsource services impacting financial operations.
Types: There are two types of SOC 1 reports:
- Type I: Assesses the suitability of the design of controls at a specific point in time.
- Type II: Examines the effectiveness of controls over a defined period.

SOC 2 (Service Organization Control 2)

Focus: SOC 2 addresses controls relevant to security, availability, processing integrity, confidentiality, or privacy, based on the AICPA’s Trust Services Criteria.
Users: Useful for management, customers, regulators, and other stakeholders concerned with information security and privacy.
Types: Like SOC 1, SOC 2 also offers Type I and Type II reports, focusing either on the design of controls at a point in time or their effectiveness over time.

Note: There is also SOC 3, but it is out of scope of this article.

Who Should Certify?

SOC 2 certification is essential for any organization that handles customer data, particularly cloud service providers, SaaS companies, and data centers.

It’s also relevant for companies in healthcare, finance, and other sectors where data security is paramount.

Why Certify?

Organizations pursue SOC 2 certification to demonstrate their commitment to data security, build customer trust, and comply with industry regulations. It also helps them stand out in competitive markets and avoid the financial and reputational damage associated with data breaches.

What Is Certified?

SOC 2 certification verifies that an organization adheres to robust information security policies and procedures. The certification evaluates five trust service criteria:

Security: Protection of system resources against unauthorized access.
Availability: Accessibility of the system as agreed upon.
Processing Integrity: System processing is complete, valid, accurate, timely, and authorized.
Confidentiality: Protection of confidential information.
Privacy: Collection, use, retention, and disposal of personal information is in line with the organization’s privacy notice.

While some security frameworks like ISO 27001, PCI DSS, TISAX, HIPAA have rigid requirements, SOC 2 considers that controls are unique to every organization.

Each company designs its own controls to comply with its Trust Services Criteria.

An independent auditor is then brought in to verify whether the company’s controls satisfy SOC 2 requirements.

After the audit, the auditor writes a report about how well the company’s systems and processes comply with SOC 2.

Every organization that completes a SOC 2 audit receives a report, regardless of whether they passed the audit.

There are two types of SOC 2 reports:

SOC 2 Type I reports evaluate a company’s controls at a single point in time. It answers the question: are the security controls designed properly?
SOC 2 Type II reports assess how those controls function over a period of time, generally 3-12 months. It answers the question: do the security controls a company has in place function as intended?

To choose between the two, consider your goals, cost, and timeline constraints.

A Type I report can be faster to achieve, but a Type II report offers greater assurance to your customers.

Topics Verified in SOC 2 Certification

1. Security

The Security Criteria are also known as the Common Criteria. They prove that a service organization’s systems and control environment are protected against unauthorized access and other risks.

Security is the only Trust Services Criteria required for every SOC 2 audit. The other criteria can be added to your report scope if your organization chooses, but they are not required to achieve SOC 2 compliance.

These are the security criteria needed for SOC 2:

CC1 — Control environment
Does the organization value integrity and security?
CC2 — Communication and Information
Are policies and procedures in place to ensure security? Are they communicated well to both internal and external partners?
CC3 — Risk Assessment
Does the organization analyze risk and monitor how changes impact that risk?
CC4 — Monitoring Controls
Does the organization monitor, evaluate, and communicate the effectiveness of its controls?
CC5 — Control Activities
Are the proper controls, processes, and technologies in place to reduce risk?
CC6 – Logical and Physical Access Controls
Does the organization encrypt data? Does it control who can access data and restrict physical access to servers?
CC7 – System Operations
Are systems monitored to ensure they function properly? Are incident response and disaster recovery plans in place?
CC8 – Change Management
Are material changes to systems properly tested and approved beforehand?
CC9 – Risk Mitigation
Does the organization mitigate risk through proper business processes and vendor management?

Implementation: Organizations must establish and maintain a set of security controls to protect against unauthorized access. This includes firewalls, encryption, access controls, and intrusion detection systems.

Audit: Auditors examine security policies, test the effectiveness of security controls, and review incident response plans.

Responsibility: Chief Information Security Officers (CISOs) and IT security teams are typically responsible for implementing and maintaining these controls.

2. Availability

Implementation: Ensuring systems are available involves implementing redundancy, disaster recovery plans, and maintaining system performance monitoring.

Audit: Auditors assess the organization’s ability to meet service level agreements (SLAs) and review backup and recovery procedures.

Responsibility: IT operations teams and service managers oversee availability aspects.

3. Processing Integrity

Implementation: Organizations must ensure that data processing is accurate and complete. This includes validating input data, processing logic, and output accuracy.

Audit: Auditors review data processing controls, check for errors, and validate processing integrity.

Responsibility: Data quality teams and IT personnel are responsible for maintaining processing integrity.

4. Confidentiality

Implementation: Protecting confidential information involves data encryption, access controls, and secure storage solutions.

Audit: Auditors evaluate the measures in place to protect confidential data and check compliance with confidentiality agreements.

Responsibility: Data protection officers (DPOs) and compliance teams handle confidentiality matters.

5. Privacy

Implementation: Organizations must adhere to privacy policies that govern the collection, use, and disposal of personal data. This involves data anonymization and consent management.

Audit: Auditors examine privacy policies, consent forms, and data handling procedures to ensure compliance with relevant privacy laws.

Responsibility: Privacy officers and legal teams are responsible for privacy compliance.

Conclusion

SOC 2 certification is a comprehensive framework that ensures organizations adhere to best practices in data security and management.

By certifying under SOC 2, organizations can demonstrate their commitment to protecting customer data, comply with regulatory requirements, and gain a competitive edge in the market.

Implementing and maintaining SOC 2 controls requires collaboration across various teams, including IT, security, operations, and legal departments, to ensure continuous compliance and security.

The post Understanding the SOC 2 Certification first appeared on Sorin Mustaca's blog.

Introduction to CISA’s Secure by Design Initiative

Sorin Mustaca — Thu, 16 May 2024 10:05:05 +0000

Contents

What is Secure by Design?

Secure by Design products are those where the security of the customers is a core business requirement, not just a technical feature. Secure by Design principles should be implemented during the design phase of a product’s development lifecycle to dramatically reduce the number of exploitable flaws before they are introduced to the market for broad use or consumption. Products should be secure to use out of the box, with secure configurations enabled by default and security features such as multi-factor authentication (MFA), logging, and single sign on (SSO) available at no additional cost. (Source)

Secure by Design is an initiative by the Cybersecurity and Infrastructure Security Agency (CISA) aimed at integrating cybersecurity practices into the design and development phases of technology products and systems. The goal is to ensure that security is considered a fundamental element from the outset, rather than an afterthought. This approach helps in reducing vulnerabilities and enhancing the resilience of systems against evolving cyber threats.

Sounds familiar?

Yes, because we know for the past 20 years or more the Microsoft initiative: Secure by design – Secure by default – Secure operations

Who Should Be Interested?

This initiative is crucial for software developers, system designers, engineers, and manufacturers involved in creating and deploying digital solutions. It is also vital for policy makers and business leaders who oversee the management and governance of cybersecurity risks in their organizations.

Why Is It Important?

Incorporating cybersecurity measures early in the design process can significantly mitigate risks, reduce costs associated with addressing security flaws after deployment, and improve consumer trust. Secure by Design supports not only the protection of individual products but also the overall security posture of national infrastructure and business ecosystems.

Focus of the Initiative

The primary focus of the Secure by Design initiative is to create a systematic, standardized approach to cybersecurity, ensuring that every phase of technology development includes security as a core component. This involves collaborative efforts among stakeholders to adopt best practices that promote security from the initial stages of product and system development.

Topics Covered by the Initiative

Development and Implementation of Security Practices

Guidelines for integrating security into software development life cycles (SDLC).
Establishment of security benchmarks and standards for new technologies.

Stakeholder Collaboration

Engagement with private sector, academia, and international bodies to harmonize security standards.
Public-private partnerships to advance security innovations and solutions.

Regulatory Compliance and Risk Management

Frameworks for compliance with emerging laws and standards in cybersecurity.
Strategies for risk assessment and management integrated into the design process.

Implementation and Auditing

How to Implement

Create a Secure Software Development Lifecycle with security protocols and checklists tailored to each stage of the design and development processes.
Incorporate automated security testing tools to assess vulnerabilities during the development phase.
Continuous monitoring and updating of security measures as part of ongoing maintenance.

Auditing

Regular security audits conducted by internal or third-party auditors to ensure adherence to established standards.
Use of automated auditing tools to provide ongoing assessments of security posture.

Responsibility and Governance

Who Is Responsible?

Chief Information Security Officers (CISOs) and IT managers are primarily responsible for overseeing the implementation of Secure by Design principles.
Developers, engineers, and product managers are accountable for incorporating these principles into their workflows and outputs.

Governance

Establishment of a governance structure to enforce security standards and practices.
Regular reviews and updates to security policies to align with technological advancements and threat landscapes.

Conclusion and further steps

CISA’s Secure by Design initiative represents a proactive shift in cybersecurity strategy, emphasizing the importance of integrating security at the foundational level of technology development. By fostering a collaborative environment among all stakeholders, it aims to standardize and strengthen cybersecurity practices across industries, thereby enhancing the security and resilience of digital infrastructures and systems.

CISA’s Secure by Design Alert Series

highlights the prevalence of widely known and documented vulnerabilities, with available and effective mitigations, that have not been eliminated. Alerts are released in response to threat actor activity, but further demonstrate how secure by design software development can help reasonably protect against malicious cyber actors successfully exploiting predictable and well-known vulnerabilities.

Check here their page for Alerts: https://www.cisa.gov/securebydesign/alerts

Secure by Design Blogs

Learn what’s top of mind at CISA and our efforts to help make technology products secure by design.

https://www.cisa.gov/securebydesign/blogs

The post Introduction to CISA’s Secure by Design Initiative first appeared on Sorin Mustaca's blog.

Implementing ISO 27001:2022 Annex A.18 – Compliance

Sorin Mustaca — Fri, 26 Apr 2024 07:49:50 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we end the series with ISO 27001:2022 Annex A.18, “Compliance”, which addresses the importance of ensuring that organizations comply with relevant laws, regulations, contractual agreements, and other requirements related to information security. This annex focuses on ensuring that the organization identifies and adheres to all applicable legal, statutory, regulatory, and contractual requirements regarding information security and the requirements of the ISMS itself.

Contents
Toggle

Understanding the Importance of Compliance
Key Controls in Annex A.18:
Practical Implementation of Annex A.18
Legal and Regulatory Compliance Assessment
Contractual Compliance Management
Risk Management and Compliance Monitoring
More examples
Auditing Annex A.18 Implementation
Conclusion

Understanding the Importance of Compliance

Annex A.18 is divided into several controls designed to help organizations manage and demonstrate compliance with various information security requirements.

These controls aim to prevent breaches of legal, statutory, regulatory, or contractual obligations related to information security and the security requirements of the organization.

Compliance with legal, regulatory, and contractual requirements is essential for organizations to maintain the confidentiality, integrity, and availability of information assets and mitigate legal and regulatory risks.

Annex A.18 emphasizes several key aspects:

Legal and Regulatory Requirements: Identifying and understanding applicable laws, regulations, and industry standards related to information security.
Contractual Obligations: Ensuring compliance with contractual agreements, service level agreements (SLAs), and data protection agreements with customers, partners, and suppliers.
Risk Management: Assessing and mitigating legal and regulatory risks associated with non-compliance, including financial penalties, legal liabilities, and damage to reputation.

Key Controls in Annex A.18:

A.18.1.1 Identification of Applicable Legislation and Contractual Requirements: Identify all relevant requirements that the organization must comply with.
A.18.1.2 Intellectual Property Rights (IPR): Ensure protection of IPR, covering software, information content, and patents.
A.18.1.3 Protection of Records: Securely manage records in accordance with legal, regulatory, and contractual requirements.
A.18.1.4 Privacy and Protection of Personally Identifiable Information: Ensure the protection of personal information as per privacy laws and other requirements.
A.18.1.5 Regulation of Cryptographic Controls: Use cryptographic controls as required by legislation, regulations, and agreements.

Practical Implementation of Annex A.18

Legal and Regulatory Compliance Assessment

Practical Examples

Regulatory Mapping: Identify and map relevant legal and regulatory requirements, such as data protection laws (e.g., GDPR, CCPA), industry standards (e.g., PCI DSS, HIPAA), and sector-specific regulations (e.g., SOX for financial services).
Compliance Assessment: Conduct compliance assessments to evaluate the organization’s adherence to legal and regulatory requirements, including data protection principles, security controls, and breach notification obligations.

Contractual Compliance Management

Practical Examples

Contract Review: Review contractual agreements, SLAs, and data processing agreements to identify information security requirements, confidentiality obligations, data protection clauses, and compliance obligations.
Compliance Monitoring: Monitor compliance with contractual agreements by tracking performance metrics, service levels, and adherence to contractual terms and conditions.

Risk Management and Compliance Monitoring

Practical Examples

Risk Assessment: Assess legal and regulatory risks associated with non-compliance, including financial penalties, legal liabilities, and reputational damage, and implement measures to mitigate these risks.
Compliance Monitoring: Establish processes for ongoing compliance monitoring, including periodic reviews, audits, and assessments to ensure adherence to legal, regulatory, and contractual requirements.

We know Compliance is hard, so here are some more examples:

More examples

Compliance Framework Development
- Example: A multinational corporation needs to comply with the GDPR for its operations in Europe and the CCPA for those in California.
- Implementation: Establish a compliance framework that identifies all applicable legal and regulatory requirements for each region of operation. Maintain a database of these requirements and update it as laws evolve.
Training and Awareness
- Example: An organization handling sensitive patient data under HIPAA must ensure that all employees are aware of the requirements.
- Implementation: Develop ongoing training programs and workshops to educate employees about their responsibilities under relevant laws and how these impact their day-to-day operations.
Auditing and Monitoring
- Example: A financial services firm regularly audits its data handling practices to ensure compliance with the Sarbanes-Oxley Act.
- Implementation: Implement a schedule for regular audits, both internal and external, to assess compliance with legal and contractual obligations. Use automated tools to monitor compliance continuously.
Handling Intellectual Property
- Example: A software development company uses proprietary code that needs to be protected under copyright laws.
- Implementation: Implement IPR controls, including secure storage, access controls, and regular audits of IPR usage and adherence to licensing agreements.
Privacy Management
- Example: A retail company collects customer data and needs to comply with privacy laws in multiple jurisdictions.
- Implementation: Deploy a privacy management solution that helps in classifying, managing, and protecting personal data in compliance with all applicable privacy laws.

Auditing Annex A.18 Implementation

The audit process for ISO 27001:2022’s Annex A.18 involves verifying that the organization has effectively implemented the controls to meet compliance requirements. The audit typically includes:

Document Review: Review policies, procedures, compliance records, training records, audit reports, and any actions taken on previous audit findings.
Interviews: Discuss with management and staff to assess their understanding and implementation of compliance controls.
Observation: Observe processes and controls in operation to verify that they function as intended.
Compliance Verification: Check compliance with specific legal, regulatory, and contractual requirements through evidence collection and analysis.
Report Findings: Provide a detailed report of the audit findings with recommendations for improvement if any non-conformities are found.

Conclusion

Effective implementation of ISO 27001:2022 Annex A.18 ensures that an organization not only meets its legal and contractual obligations but also demonstrates a commitment to comprehensive information security management.

By establishing a structured compliance program and conducting thorough audits, organizations can maintain high standards of information security and build trust with stakeholders.

The post Implementing ISO 27001:2022 Annex A.18 – Compliance first appeared on Sorin Mustaca's blog.

Maping NIS2 requirements to the ISO 27001:2022 framework

Sorin Mustaca — Thu, 25 Apr 2024 07:15:51 +0000

We described here the process needed to perform a gap analysis for NIS2, but we did not add the details on how to approach this.

This article references on the ISO27001:2022 series, especially on the description of the Annex A controls. Make sure you are familiar with the ISO 27oo1:2022 requirements and the with the Annex A.

Contents

Introduction

The NIS2 Directive, aimed at strengthening network and information system security across the European Union, necessitates a thorough alignment with the latest iteration of the ISO 27001 standard, which was updated in 2022. This article explores a comprehensive methodology for conducting a gap analysis to ensure compliance with NIS2 using the framework provided by ISO 27001:2022.

Understand NIS2 Requirements

The NIS2 Directive expands upon its predecessor by setting stringent cybersecurity and resilience measures for essential and important entities across various sectors. Its key focus areas include incident response, supply chain security, and the security of network and information systems. These areas are critical in maintaining the integrity and availability of services that are vital to the internal market and public welfare.

The NIS2 Directive does not prescribe a specific set of controls for the affected companies.

Rather, it states that they should adopt measures that are appropriate to their specific risk profile, considering factors such as:

The state of the art in cybersecurity
The potential impact of incidents on their services
The costs of implementing the measures
The proportionality between the measures and the risks

The directive also refers to existing standards, guidelines, and best practices that can help entities to choose suitable controls.

For example, it mentions:

The NIST Cybersecurity Framework
The ENISA Good Practices for Security of Internet of Things
The ETSI Technical Specification on Critical Security Controls for Effective Cyber Defense

Read here our collection of articles about the NIS2 directive.

Overview of ISO 27001:2022

ISO 27001:2022 establishes requirements for an Information Security Management System (ISMS), providing a systematic approach to managing sensitive company information so that it remains secure.

It includes people, processes, and IT systems by applying a risk management process and clearly defines information security control requirements in its Annex A .

Similarities

Despite the differences in scope, objectives, requirements and controls, there are some similarities between the NIS2 Directive and the ISO 27001:2022 standard.

Here are the most evident similarities :

Risk management: Both frameworks are based on the concept of risk management, which involves identifying, analyzing, evaluating, and treating the information security risks that affect the organization or the service.
Involvement and commitment of top management: Both frameworks require the involvement and commitment of top management, who are responsible for ensuring that the appropriate resources, roles and responsibilities are allocated to support the implementation and maintenance of the measures.
Importance of continuous improvement: Both frameworks emphasize the importance of continuous improvement, which involves monitoring, measuring, reviewing, and updating the measures to ensure they remain effective and relevant in a changing environment.
Cooperation and information sharing: Both frameworks encourage cooperation and information sharing among relevant stakeholders, such as authorities, regulators, customers, suppliers, and peers, to enhance the overall level of cybersecurity.

Mapping NIS2 to ISO27001:2022 requirements

The mapping begins with identifying the specific NIS2 requirements that are applicable to the organization.

Step 1: Identify NIS2 requirements

1. Scope of Application

Expansion of Affected Entities: NIS2 extends its requirements beyond the sectors covered by the original NIS Directive, including essential and important entities across various sectors such as energy, transport, health, and digital services.

2. Risk Management Measures

Comprehensive Security Requirements: Entities are required to implement appropriate technical and organizational measures to manage the risks posed to the security of network and information systems, including measures for incident handling, business continuity, and supply chain security.

3. Incident Response and Reporting

Incident Reporting Obligations: NIS2 mandates strict incident reporting requirements, where entities must notify relevant national authorities about significant cybersecurity incidents with potentially severe operational impacts, within a short timeframe.

4. Supply Chain Security

Security of Supply Chains and Supplier Relationships: Entities need to address cybersecurity risks not only within their own operations but also across their supply chains, ensuring that suppliers meet security requirements to protect against potential vulnerabilities and threats.

5. Interoperability and Cooperation

Enhanced Cooperation Among States: NIS2 emphasizes improved information sharing and coordinated response among EU member states, with mechanisms for cross-border collaboration in cybersecurity threat detection, response, and recovery.

6. Security and Network Systems

Strengthening of Security Practices: Detailed requirements on securing network and information systems, ensuring the integrity, availability, and confidentiality of services, particularly in critical infrastructure sectors.

7. Regulatory Oversight and Compliance

Increased Enforcement Powers: Regulatory authorities are granted more significant powers to enforce the Directive, including the ability to conduct audits, review compliance, and impose sanctions on entities failing to meet the cybersecurity requirements.

8. Financial Penalties

Penalties for Non-Compliance: NIS2 introduces substantial financial penalties for non-compliance, aimed at ensuring that entities take their cybersecurity obligations seriously.

9. Cybersecurity Measures Specificity

Detailed Guidelines and Standards: The Directive encourages the use of established standards and specifications to fulfill the required security measures, promoting best practices in cybersecurity management.

This step involves a detailed review of NIS2, focusing on the obligations that directly impact the organizational processes and security measures.

Step 2: Map requirements to the ISO 27001:2022 chapters

The next step is to map relevant chapters and controls in ISO 27001:2022 to these NIS2 requirements:

Chapter 4 (Context of the Organization) -> NIS2 1,4,5
- Understand external and internal issues that affect the ISMS, aligning with NIS2’s broader security requirements.
- Identify if the company is falling into the two entity categories: Important and Essential.
- An important step is also to identify and assess all external suppliers.
Chapter 5 (Leadership) -> NIS2 1,5,8
- Ensures management’s commitment to the ISMS, mirroring NIS2’s emphasis on leadership and governance in cybersecurity.
Chapter 6 (Planning) -> NIS2 2,3,4,6
- Address the assessment and treatment of information security risks, a core component of proactive compliance under NIS2.
- Conduct a risk assessment to identify threats, vulnerabilities, and impacts on information assets.
- Develop a risk treatment plans to address identified risks, including mitigation, transfer, or acceptance.
Chapter 7 (Support) -> 5,7,9
- Provide the framework for managing resources and operational planning,
- Establish communication channels for reporting security incidents and seeking guidance on information security matters.
Chapter 8 (Operation) -> NIS2 2,3,4,6
- Provide the framework for managing resources and operational planning, establishes incident response and business continuity plans to mitigate the impact of security incidents and disruptions, crucial for implementing the technical and organizational measures required by NIS2.
Chapter 9 (Performance Evaluation) -> NIS2 8,9
- Assess the performance of the ISMS, helping to ensure continuous improvement in line with NIS2’s dynamic compliance landscape.

Disclaimer:
This mapping is author’s own interpretation based on his personal opinion and understanding of the requirements. It is not the only possible interpretation and it is most probably not the best one available.

Conclusion

By mapping NIS2 requirements to the structured framework provided by ISO 27001:2022, organizations can not only ensure compliance but also strengthen their overall security posture.

It is important to understand that this alignment is not a one-time effort but a continuous process of adaptation and improvement, reflecting the dynamic nature of cybersecurity threats and regulatory requirements.

As such, organizations should focus on regular reviews and updates to their ISMS, ensuring that it remains robust, responsive, and compliant.

The post Maping NIS2 requirements to the ISO 27001:2022 framework first appeared on Sorin Mustaca's blog.

Implementing ISO 27001:2022 Annex A.17 – Information Security Aspects of Business Continuity Management

Sorin Mustaca — Wed, 24 Apr 2024 07:33:33 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.17, “Information Security Aspects of Business Continuity Management” is crucial for organizations to ensure the resilience of their information security management systems (ISMS) in the face of disruptive events.

This annex provides guidelines for integrating information security into business continuity management processes to minimize the impact of disruptions and ensure the continuity of critical business operations.

Contents
Toggle

Understanding the Importance of Business Continuity Management
Key Controls in Annex A.17:
Practical Implementation of Annex A.17
Auditing Annex A.17 Implementation

Understanding the Importance of Business Continuity Management

Annex A.17 of ISO 27001:2022 outlines the controls necessary to ensure that information security is an integral part of the organization’s business continuity management. The annex emphasizes the need to prepare for, respond to, and recover from incidents that can impact the availability of critical information assets.

Business continuity management (BCM) is essential for organizations to prepare for and respond to disruptions that could affect their ability to deliver products and services.

Annex A.17 emphasizes several key aspects:

Risk Assessment: Identifying and assessing risks that could disrupt business operations and impact information security.
Business Impact Analysis: Evaluating the potential consequences of disruptions on critical business processes and information assets.
Business Continuity Planning: Developing and implementing strategies and procedures to maintain essential functions during and after disruptive events.
Testing and Exercise: Conducting regular testing and exercises to validate the effectiveness of business continuity plans and improve response capabilities.

Key Controls in Annex A.17:

A.17.1 Information Security Continuity: Ensure that information security continuity is embedded within the organization’s overall business continuity management systems.
A.17.2 Redundancies: Implement redundancy measures to ensure availability of information processing facilities.

Practical Implementation of Annex A.17

Risk Assessment and Business Impact Analysis (BIA):
- Example: An e-commerce company assesses the impact of a server downtime on its operations. The BIA shows significant revenue loss for each hour of downtime.
- Implementation: Develop and implement continuity strategies based on the results of BIA. This includes identifying critical systems and processes and the extent of their protection.
Establishing Redundancy and Resilience:
- Example: A financial institution uses multiple data centers in geographically diverse locations to ensure data availability even in the case of a natural disaster.
- Implementation: Invest in redundant hardware, failover systems, and data mirroring techniques to ensure continuous service and data availability.
Developing and Implementing Business Continuity Plans:
- Example: A healthcare provider ensures that all critical patient information systems have backups and are capable of being restored quickly in any emergency.
- Implementation: Prepare detailed business continuity plans that include recovery objectives, strategies, and employee responsibilities. Regularly train staff on their roles during a disruption.
Testing and Exercises:
- Example: A technology firm conducts bi-annual drills to simulate different scenarios including cyber-attacks and power failures.
- Implementation: Regular testing and rehearsal of business continuity plans to evaluate their effectiveness and make necessary adjustments.
Embedding Information Security into Business Continuity:
- Example: Incorporate cybersecurity measures into the business continuity plans of an online retailer to protect against data breaches during disruptions.
- Implementation: Ensure that information security practices are maintained during a disruption, including access controls, encryption, and secure communication channels.

Auditing Annex A.17 Implementation

The audit of ISO 27001:2022’s Annex A.17 focuses on verifying that the business continuity plans and controls are in place, effective, and in alignment with the organization’s overall security policies. The audit process typically involves the following steps:

Documentation Review: Auditors review all relevant documentation including the business impact analysis, risk assessments, continuity plans, and previous audit reports.
Interviews: Conduct interviews with key personnel involved in business continuity management to assess their understanding and implementation of the policies.
Observation and Testing: Direct observation of drills and testing processes, and reviewing logs and records to verify that procedures are regularly executed and monitored.
Report Findings and Recommendations: Provide a detailed report of findings with any non-conformities and suggest corrective actions.

Conclusion

Implementing Annex A.17 of ISO 27001:2022 effectively ensures that an organization can protect its critical information assets during disruptions. By following structured implementation and regular audits, organizations can not only comply with ISO 27001 but also enhance their resilience against unforeseen events, thereby safeguarding their operations and reputation in the long term.

The post Implementing ISO 27001:2022 Annex A.17 – Information Security Aspects of Business Continuity Management first appeared on Sorin Mustaca's blog.

Implementing ISO 27001:2022 Annex A.16 – Information Security Incident Management

Sorin Mustaca — Mon, 22 Apr 2024 07:21:47 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.16, “Information Security Incident Management” is crucial for organizations to effectively detect, respond to, and recover from security incidents. This annex provides guidelines for establishing an incident management process to minimize the impact of security breaches and ensure the continuity of business operations.

Contents
Toggle

Understanding the Importance of Information Security Incident Management
Implementing Annex A.16 in Practice
Establishing Incident Management Procedures
Incident Response and Containment
Incident Analysis and Recovery
Audit of Compliance with Annex A.16
Conclusion

Understanding the Importance of Information Security Incident Management

Incident management is a fundamental aspect of information security, helping organizations mitigate the impact of security incidents and protect sensitive information assets. Annex A.16 emphasizes several key aspects:

Timely Response: Promptly detecting and responding to security incidents minimizes their impact on operations and prevents further damage.
Containment and Recovery: Implementing effective containment and recovery measures helps restore affected systems and data to normal operations.
Continuous Improvement: Regularly reviewing and updating incident management procedures ensures their effectiveness and alignment with evolving threats and technologies.

Implementing Annex A.16 in Practice

Establishing Incident Management Procedures

Practical Examples:

Incident Identification: Implement mechanisms to detect and identify security incidents, such as intrusion detection systems (IDS), security information and event management (SIEM) systems, and user reporting mechanisms.
Incident Classification: Define criteria for classifying incidents based on severity, impact, and urgency to prioritize response efforts effectively.
Incident Response Team: Establish an incident response team comprising key personnel responsible for coordinating and executing incident response activities.

Incident Response and Containment

Practical Examples

Response Plan: Develop incident response plans outlining roles, responsibilities, and actions to be taken during security incidents, including containment, eradication, recovery, and communication procedures.
Containment Measures: Implement measures to contain and mitigate the impact of security incidents, such as isolating affected systems, disabling compromised accounts, or blocking malicious traffic.
Evidence Preservation: Preserve evidence related to security incidents for forensic analysis and investigation purposes, ensuring the integrity and admissibility of evidence.

Incident Analysis and Recovery

Practical Examples

Root Cause Analysis: Conduct root cause analysis to identify the underlying causes of security incidents and implement corrective actions to prevent recurrence.
System Restoration: Restore affected systems and data to normal operations following security incidents, using backup and recovery procedures to minimize downtime and data loss.
Communication: Communicate with stakeholders, including senior management, employees, customers, and regulatory authorities, regarding the nature and impact of security incidents and steps taken for resolution.

Audit of Compliance with Annex A.16

Auditing compliance with Annex A.16 involves assessing the effectiveness of incident management procedures and practices. The audit process typically includes:

Audit Preparation: Gathering documentation related to incident management procedures, incident response plans, and incident logs.
On-site Audit: Assessing implementation of incident management controls through interviews, document reviews, and observations of incident response activities.
Audit Findings: Analyzing audit findings and identifying areas of non-compliance or improvement opportunities.
Reporting: Documenting audit results and providing recommendations for corrective actions to address identified issues.
Follow-up: Monitoring implementation of corrective actions and conducting follow-up audits to verify compliance.

Conclusion

ISO 27001:2022 Annex A.16 underscores the importance of establishing robust incident management procedures to effectively respond to security incidents and minimize their impact on business operations. By implementing incident identification, response, containment, and recovery measures, organizations can enhance their resilience to security threats and ensure the continuity of critical business functions. Regular audits help assess compliance with Annex A.16 requirements and drive continuous improvement in incident management practices, enabling organizations to adapt to evolving security challenges effectively. Prioritizing information security incident management is essential for organizations seeking to protect sensitive information assets and maintain trust and confidence in their operations.

The post Implementing ISO 27001:2022 Annex A.16 – Information Security Incident Management first appeared on Sorin Mustaca's blog.

NIS-2: 10 common misconceptions about the regulation

Sorin Mustaca — Fri, 19 Apr 2024 07:16:42 +0000

We wrote here about NIS2 and we will continue to add more content about it.

Because we are getting closer to October 17th, many people are getting more and more nervous about NIS2.

Despite its significance, there are numerous misconceptions and misinterpretations circulating about the scope and implications of this regulation.

This article aims to clarify some of the misconceptions, which I collected mostly from LinkedIn and articles about NIS-2.

Note:

“NIS2” and “NIS-2” are exactly the same thing. I am using both in this article only because of SEO.

Contents

1. NIS2 starts being applied in the EU starting 17.10.2024

Truth is that the regulation is already applicable in the EU since it was approved. This deadline applies to the individual countries of the EU to convert and apply the NIS2 requirements in local laws.

If national authorities fail to properly implement EU laws, the Commission may launch a formal infringement procedure against the country in question. If the issue is still not settled, the Commission may eventually refer the case to the Court of Justice of the European Union.

2. Limited scope of application

Contrary to the belief that NIS-2 only applies to large tech companies, the directive significantly broadens its scope compared to its predecessor, NIS.

NIS-2 extends beyond just critical infrastructure sectors like energy and transport, encompassing a wide array of sectors such as digital services, public administration, and healthcare.

It mandates a security and incident reporting framework that applies to both Essential and Important Entities, significantly expanding the list of sectors and services affected.

3. NIS-2 Is Just About Cybersecurity

While cybersecurity is a core component, NIS-2 is not merely about preventing cyberattacks. The directive emphasizes a comprehensive approach to security, which includes resilience against a wide range of threats.

This includes but it is not limited to:

supply chain security,
incident response, and
crisis management.

It establishes a baseline for security measures and incident notifications that entities must adhere to, ensuring a uniform level of security across member states.

4. NIS-2 compliance is the same across all EU countries

Although NIS-2 sets a framework for cybersecurity across the EU, member states have some flexibility in implementation. This means that there can be variations in how directives are enforced from one country to another, depending on local laws and regulations.

Companies operating across multiple jurisdictions need to be aware of and comply with local variations to ensure full compliance.

5. Heavy penalties are the main compliance driver

While it is true that NIS-2 can impose hefty fines for non-compliance, focusing solely on penalties misses the broader objective of the directive.

NIS-2 is designed to cultivate a culture of security and resilience. It encourages entities to proactively manage their cybersecurity risks and to collaborate with national authorities.

This cooperative approach is fundamental to enhancing the overall cybersecurity posture of the EU.

6. NIS-2 does not affect third-party suppliers

NIS-2 places explicit requirements on the security practices of third-party suppliers. Entities covered under the directive are required to ensure that their supply chains are secure.

This includes mandatory risk assessments and incident reporting requirements that extend to service providers, reflecting an understanding that security is only as strong as the weakest link in the supply chain.

7. NIS-2 contains rules for AI, IoT, Industry 4.0.

NIS-2 sets a framework for cybersecurity and it does not address anything in particular. However, the rules described can be very well applied to companies in the fields like those mentioned that fall under the regulation applicability.

The companies active in Digital Infrastructure Services (Internet Nodes, DNS Service Providers, TLD Registries, Cloud Providers, Data Centers, Content Delivery Networks, Trust Services, Communication Networks, Communication Services ) and in

ICT Service Management (B2B only) (Managed Services (IT, Networks/Infrastructure, Applications), Managed Security Services (Risk and Cyber Security) ) are potentially directly affected by the regulation. However, there are clear criteria about which companies are affected.

8. Any company with activity in the domains marked as Important and Essential is affected by NIS-2

Although the domains are under the NIS-2 regulation, a company is affected if it meets the criteria:

Essential Entities (EE):
- at least 250 employees and
- 50 Mil € revenue
Important Entities (IE):
- at least 50 employees and
- 10 Mil € revenue

If a company doesn’t have these characteristics, then, in general, it is not affected by the regulation directly. It is highly recommended that even in such cases the companies follow the regulation’s requirements, since it will increase their resilience against cyber attacks.

However, an entity may still be considered “essential” or “important” even if it does not meet the size criteria, in specific cases such as when it is the sole provider of a critical service for societal or economic activity in a Member State.

9. All affected companies must certify for NIS-2

A the time of writing this post there is no certification for NIS-2. This might change in the future, especially when because we don’t know at this time how the regulation will be implemented in each of the EU member states.

There are consulting companies that sell consulting services and guarantee that a company will get the “NIS-2 certification” if they bus their services. While buying consulting is in general a good thing, the only thing that can be obtained is help in meeting the requirements of the regulation.

I recommend to stay away from offers that promise things that don’t exist.

10. Companies can buy software/hardware products to become conform with NIS-2

Although conformity is sometimes made easier by using specialized software and hardware products, there is no requirement or recommendation to purchase anything.

Some security providers and consulting companies are offering On The Shelf (OTS) products that promise immediate conformity with NIS-2 (or guarantee obtaining a “certification” – see point 9 above).

If you look at the series of articles in the NIS2 area of this website, you will see that actually quite a lot of steps involve an ISMS, a cybersecurity framework, cybersecurity products and so on.

These can be implemented with commercial or open source products, but there is still need to know where and how to install them in order to become conform.

I can very well imagine that there will be soon commercial offerings with sets of templates for implementing the NIS-2 requirements, just like there are with ISO 27001, TISAX and other certifications.

The post NIS-2: 10 common misconceptions about the regulation first appeared on Sorin Mustaca's blog.

Implementing ISO 27001:2022 Annex A.15 – Supplier Relationships

Sorin Mustaca — Wed, 17 Apr 2024 07:57:23 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.15, “Supplier Relationships”, which is crucial for organizations in order to ensure the security of information assets shared with external suppliers. This annex provides guidelines for managing supplier relationships effectively to mitigate risks and maintain information security.

From an IT security perspective, suppliers are external entities or third-party organizations that provide goods, services, or resources to support an organization’s operations.

These suppliers often play a critical role in the organization’s IT infrastructure, providing hardware, software, cloud services, and other technology solutions.

Suppliers may also have access to sensitive information, systems, or networks of the organization, making them potential security risks.

Therefore, managing supplier relationships is essential for ensuring the security of information assets and mitigating risks associated with third-party access.

Contents
Toggle

Understanding the Importance of Supplier Relationships
Implementing Annex A.15 in Practice
Supplier Selection and Evaluation
Contractual Agreements
Monitoring and Review
Audit of Compliance with Annex A.15
Conclusion

Understanding the Importance of Supplier Relationships

Supplier relationships play a vital role in the overall information security posture of organizations. Annex A.15 emphasizes several key aspects:

Risk Management: Assessing and managing risks associated with suppliers who have access to sensitive information.
Contractual Agreements: Establishing clear contractual agreements that define security responsibilities and obligations.
Monitoring and Review: Continuously monitoring supplier performance and adherence to security requirements.

Implementing Annex A.15 in Practice

Supplier Selection and Evaluation

Practical Examples:

Risk Assessment: Conduct thorough risk assessments of potential suppliers to evaluate their security controls, practices, and potential risks to information assets.
Due Diligence: Perform due diligence checks, such as reviewing security certifications, conducting site visits, and requesting security documentation from suppliers.
Security Requirements: Clearly communicate security requirements to suppliers during the selection process, including data protection measures, access controls, and incident response capabilities.

Contractual Agreements

Practical Examples:

Security Clauses: Include specific security clauses in contracts that outline security requirements, confidentiality obligations, data protection measures, and compliance with relevant regulations.
Data Protection: Address data protection requirements, including data handling procedures, data encryption, and secure transmission methods.
Service Level Agreements (SLAs): Define SLAs for security-related metrics, such as incident response times, availability guarantees, and security incident notification procedures.

Monitoring and Review

Practical Examples:

Ongoing Assessment: Continuously monitor supplier performance and security practices to ensure compliance with contractual agreements and security requirements.
Audits and Reviews: Conduct periodic audits and reviews of supplier security controls, practices, and compliance with contractual obligations.
Incident Response: Establish procedures for managing security incidents involving suppliers, including incident reporting, investigation, and remediation.

Audit of Compliance with Annex A.15

Auditing compliance with Annex A.15 involves assessing the effectiveness of supplier relationship management practices. The audit process typically includes:

Audit Preparation: Gather documentation related to supplier relationships, contracts, and security controls.
On-site Audit: Assess implementation of supplier management controls through interviews, document reviews, and observations.
Audit Findings: Analyze audit findings and identify areas of non-compliance or improvement opportunities.
Reporting: Document audit results and provide recommendations for corrective actions to address identified issues.
Follow-up: Monitor implementation of corrective actions and conduct follow-up audits to verify compliance.

Conclusion

ISO 27001:2022 Annex A.15 emphasizes the importance of effectively managing supplier relationships to protect information assets and mitigate risks. By implementing robust supplier management practices, organizations can ensure compliance with security requirements, maintain confidentiality, integrity, and availability of sensitive information, and enhance overall information security posture. Regular audits help assess compliance with Annex A.15 requirements and drive continuous improvement in supplier relationship management processes.

The post Implementing ISO 27001:2022 Annex A.15 – Supplier Relationships first appeared on Sorin Mustaca's blog.

Google Ads for Bitbucket.org – malvertising at its best (Updated)

Sorin Mustaca — Wed, 17 Apr 2024 07:38:23 +0000

Contents

What is it?

Malvertising : Malware delivered through Advertising. These corrupted ads are designed to appear legitimate but they may serve malicious code, which can infect a user’s device simply through viewing or clicking on the ad. Malvertising exploits the expansive reach and complex supply chains of online advertising networks, enabling attackers to deliver malware to a broad audience without direct interaction.

This type of cyber attack can lead to data breaches, identity theft, and other significant security risks. Awareness and advanced security measures are crucial in protecting against malvertising threats.

Bitbucket malvertising

If you search in Google the word “Bitbucket”, you get a screen like the one below.

If you click on the first link, which is marked as “Sponsored”, you will be redirected to a website, which is 99.99% identical to the bitbucket.org.

What’s the catch?

The are a few things on the page that are wrong:

1.Malicious software

The kit that you download is malicious: https://www.virustotal.com/gui/file/9a2268162982113c12d163b1377dc4e72c93f91e26bd511d16c1b705262ca03c?nocache=1

At the moment when I reanalyzed it, only 3 AVs detected it: ESET, Sophos and Jiangmin.

2. Unknown advertiser (not Atlassian)

The ad is not from Atlassian, but from someone in Pakistan:

I reported it to Google as malware.

3. Foreign code inserted

If you look at the source of the fake page, you see code and comments in Russian. The translation shows some innocent log messages. It appears that the developers had some problems with the server response.

….

success: function(response) {
console.log(“Ответ сервера: “, response);
// alert(“Клик зарегистрирован!”);
},
error: function(xhr, status, error) {
// Обработка ошибок при отправке запроса
// console.error(“Ошибка: “, error);
alert(“Произошла ошибка при регистрации клика.”);
…

4. Very fresh domain

The domain was registered a few weeks ago.

Conclusion

Don’t just click: Never search for a domain by entering the name in the search engine. Just type the domain you see advertised. In our case, as can be seen in the screenshot, the domain would be bitbucket.org.
Use Ad Blockers: Installing reputable ad blocking software can help prevent malvertisements from loading. This is one of the simplest and most effective measures to reduce the risk of accidental clicks on malicious ads.
Use security solutions: Utilize endpoint security solutions that include features like real-time scanning, behavior analysis, and threat detection. These tools can identify and neutralize malicious activities originating from ads.
Use Secure Browsing Tools: Tools that offer secure browsing options, such as VPNs and security-focused browsers, can provide additional layers of protection by encrypting data and blocking malicious sites.

Update

Google rejected 3 requests to stop the ads with the following mail:

Dear Sorin,

We’re writing to let you know that we reviewed your report (ID 8-9421000036524).

Here's what we found

We decided not to take this ad down. We found that the ad doesn’t go against Google’s policies, which prohibit certain content and practices that we believe to be harmful to users and the overall online ecosystem.

(If you have additional information that might help us reverse this decision, you can let us know by reporting this ad again within six months, or you can learn about your other options to dispute this decision.)

However, minutes later after receiving the rejected, the ad has been removed and the domain suddenly disappeared!

Shame on you Google!

The post Google Ads for Bitbucket.org – malvertising at its best (Updated) first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.14 – System Acquisition, Development, and Maintenance

Sorin Mustaca — Mon, 15 Apr 2024 09:00:04 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.14, “System Acquisition, Development, and Maintenance”, which addresses the importance of ensuring the security of information systems throughout their lifecycle, from acquisition and development to maintenance and disposal. This annex provides guidelines for implementing controls to manage the security of information systems and software applications.

Contents

Importance of System Acquisition, Development, and Maintenance

System acquisition, development, and maintenance are critical stages in the lifecycle of information systems and software applications. Annex A.14 underscores this importance by:

Security by Design: Integrating security considerations into the acquisition, development, and maintenance processes helps identify and mitigate security risks early in the lifecycle, reducing the likelihood of vulnerabilities and security incidents.
Secure Development Practices: Implementing secure coding practices, testing methodologies, and vulnerability management processes helps ensure the integrity, confidentiality, and availability of software applications and systems.
Change Management: Managing changes to information systems and software in a controlled manner helps prevent unauthorized modifications, configuration errors, and disruptions to services.

Implementing Annex A.14 in Practice

To effectively implement Annex A.14, organizations can follow these practical steps:

Security Requirements Analysis: Conduct a security requirements analysis during the system acquisition phase to identify security requirements and considerations for information systems and software applications.
Example: Include security requirements such as authentication mechanisms, access controls, encryption, and audit logging in the procurement specifications for new information systems or software applications.
Secure Development Practices: Adopt secure coding guidelines, frameworks, and best practices during the development phase to minimize the risk of security vulnerabilities and weaknesses in software applications.
Example: Implement input validation, output encoding, and proper error handling to mitigate common vulnerabilities such as cross-site scripting (XSS), SQL injection, and buffer overflows in web applications.
Vulnerability Management: Implement vulnerability scanning, penetration testing, and code reviews to identify and remediate security vulnerabilities and weaknesses in information systems and software applications.
Example: Conduct regular vulnerability scans and penetration tests of network infrastructure, web applications, and databases to identify security vulnerabilities and prioritize remediation efforts.
Change Control: Establish change management procedures to control and document changes to information systems and software applications in a controlled and auditable manner.
Example: Implement a change management system to track and manage changes to software code, configurations, and configurations, ensuring that changes are reviewed, approved, and tested before deployment.
Patch Management: Implement patch management processes to identify, assess, and apply security patches and updates to information systems and software applications in a timely manner.
Example: Establish a patch management schedule to regularly assess and apply security patches and updates to operating systems, software applications, and firmware to mitigate security vulnerabilities and risks.

Audit of Compliance with Annex A.14

Auditing compliance with Annex A.14 is essential for evaluating an organization’s adherence to system acquisition, development, and maintenance requirements. Here’s how the audit process typically unfolds:

Audit Preparation: Gather documentation related to system acquisition, development, and maintenance policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Conduct on-site visits to assess implementation of system acquisition, development, and maintenance controls. Review documentation, inspect development environments, and observe change management practices. Use checklists or assessment tools to evaluate compliance.
Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in system acquisition, development, and maintenance implementation.
Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusion

ISO 27001:2022 Annex A.14 emphasizes the importance of ensuring the security of information systems throughout their lifecycle. By implementing controls and best practices for system acquisition, development, and maintenance, organizations can minimize security risks, vulnerabilities, and incidents. Regular audits help assess compliance with Annex A.14 requirements and drive continuous improvement in system security practices.

The post Understanding ISO 27001:2022 Annex A.14 – System Acquisition, Development, and Maintenance first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.13 – Communications Security

Sorin Mustaca — Fri, 12 Apr 2024 11:00:34 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.13, “Communications Security”, which addresses the importance of securing information during its transmission over communication networks.

This annex provides guidelines for implementing controls to protect the confidentiality, integrity, and availability of information exchanged between parties.

Contents

Importance of Communications Security

Communications security is crucial for safeguarding sensitive information transmitted over communication channels, such as networks, internet connections, and wireless technologies. Annex A.13 underscores this importance by:

Confidentiality: Encrypting communications prevents unauthorized parties from intercepting and eavesdropping on sensitive information transmitted over unsecured networks.
Integrity: Implementing integrity checks and digital signatures ensures that transmitted data remains intact and unaltered during transit, protecting against tampering and unauthorized modifications.
Availability: Securing communication channels helps maintain the availability of information services and prevents disruptions caused by network attacks, denial-of-service (DoS) attacks, or transmission errors.

Implementing Annex A.13 in Practice

To effectively implement Annex A.13, organizations can follow these practical steps:

Encryption: Encrypt data transmitted over insecure communication channels using encryption protocols such as Transport Layer Security (TLS), Secure Sockets Layer (SSL), or Virtual Private Network (VPN) tunnels.Example: Configure email servers to use TLS encryption for encrypting emails in transit between email clients and servers, preventing eavesdropping on email communications.
Digital Signatures: Use digital signatures to verify the authenticity and integrity of transmitted data and messages. Implement digital signature algorithms and certificate authorities to ensure the validity of signatures.Example: Digitally sign electronic documents, such as contracts or reports, using a digital signature certificate issued by a trusted certificate authority to verify the authenticity and integrity of the documents.
Secure Protocols: Use secure communication protocols and standards, such as Secure Shell (SSH), Hypertext Transfer Protocol Secure (HTTPS), and Internet Protocol Security (IPsec), to protect data transmitted over networks.Example: Configure web servers to use HTTPS protocol for secure transmission of sensitive information, such as login credentials or financial transactions, over the internet.
Access Controls: Implement access controls to restrict access to communication channels and network resources to authorized users only. Use strong authentication mechanisms to verify the identity of users accessing network services.Example: Configure network routers and firewalls to enforce access control lists (ACLs) restricting inbound and outbound traffic based on source and destination IP addresses, ports, and protocols.
Monitoring and Logging: Deploy monitoring and logging mechanisms to track communication activities, detect anomalies, and identify potential security incidents or unauthorized access attempts.Example: Set up network intrusion detection systems (NIDS) or intrusion prevention systems (IPS) to monitor network traffic for suspicious behavior, such as port scans or packet sniffing attempts.

Audit of Compliance with Annex A.13

Auditing compliance with Annex A.13 is essential for evaluating an organization’s adherence to communications security requirements. Here’s how the audit process typically unfolds:

Audit Preparation: Gather documentation related to communications security policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Conduct on-site visits to assess implementation of communications security controls. Review documentation, inspect network configurations, and observe communication practices. Use checklists or assessment tools to evaluate compliance.
Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in communications security implementation.
Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusion

ISO 27001:2022 Annex A.13 emphasizes the importance of communications security in protecting sensitive information transmitted over communication networks. By implementing robust controls and measures to encrypt data, verify authenticity, and enforce access controls, organizations can mitigate risks and safeguard against unauthorized access or interception of communications. Regular audits help assess compliance with Annex A.13 requirements and drive continuous improvement in communications security practices.

The post Understanding ISO 27001:2022 Annex A.13 – Communications Security first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.12 – Operations Security

Sorin Mustaca — Thu, 11 Apr 2024 09:09:40 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.12, “Operations Security”, which focuses on ensuring secure operations of information systems and assets. This annex provides guidelines for implementing controls to manage day-to-day operations, protect against security incidents, and maintain the integrity, availability, and confidentiality of information assets.

Contents

Importance of Operations Security

Operations security is critical for maintaining the effectiveness and resilience of information systems and assets. Annex A.12 underscores this importance by:

Risk Management: Implementing operational controls helps identify, assess, and mitigate risks to information assets, ensuring business continuity and protecting against security incidents.
Incident Response: Establishing incident response procedures enables organizations to detect, respond to, and recover from security incidents effectively, minimizing the impact on operations and data integrity.
Change Management: Managing changes to information systems and assets in a controlled manner helps prevent unauthorized modifications, configuration errors, and disruptions to services.

Implementing Annex A.12 in Practice

To effectively implement Annex A.12, organizations can follow these practical steps:

Risk Assessment: Conduct regular risk assessments to identify potential threats, vulnerabilities, and risks to information assets. Assess the likelihood and impact of identified risks to prioritize mitigation efforts.Example: Perform a comprehensive risk assessment of IT systems, networks, and applications to identify vulnerabilities, such as outdated software or misconfigured settings, that could expose assets to security threats.
Incident Management: Establish incident response procedures to define roles, responsibilities, and actions to be taken in the event of a security incident. Develop incident response plans, escalation procedures, and communication protocols.Example: Develop an incident response playbook outlining steps to be followed in case of a security breach, including incident detection, containment, eradication, recovery, and post-incident analysis.
Monitoring and Logging: Implement monitoring and logging mechanisms to track user activities, detect anomalies, and identify potential security incidents. Collect and analyze log data from information systems, networks, and security devices.Example: Deploy security information and event management (SIEM) systems to aggregate and correlate log data from various sources, enabling real-time monitoring, alerting, and analysis of security events.
Change Control: Establish change management procedures to control and document changes to information systems, applications, configurations, and infrastructure. Define change request processes, approval workflows, and testing requirements.Example: Implement a change management system to track and manage changes to IT assets, including software updates, patches, configuration changes, and infrastructure modifications, following a structured change control process.
Backup and Recovery: Implement backup and recovery procedures to protect against data loss, corruption, and unauthorized access. Regularly back up critical data and systems, and test backup restoration procedures.Example: Configure automated backup schedules for critical databases, files, and systems, ensuring that backup copies are stored securely and can be restored in the event of data loss or system failure.
Protection against malware: Implement detection, prevention and recovery controls to protect against malware, combined with appropriate user awareness training.

Audit of Compliance with Annex A.12

Auditing compliance with Annex A.12 is essential for evaluating an organization’s adherence to operational security requirements. Here’s how the audit process typically unfolds:

Audit Preparation: Gather documentation related to operational security policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Conduct on-site visits to assess implementation of operational security controls. Review documentation, interview personnel, and observe operational practices. Use checklists or assessment tools to evaluate compliance.
Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in operational security implementation.
Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusion

ISO 27001:2022 Annex A.12 emphasizes the importance of operational security in maintaining the effectiveness, resilience, and integrity of information systems and assets. By implementing robust controls and procedures for risk management, incident response, change control, and backup and recovery, organizations can mitigate risks, protect against security incidents, and ensure business continuity. Regular audits help assess compliance with Annex A.12 requirements and drive continuous improvement in operational security practices.

The post Understanding ISO 27001:2022 Annex A.12 – Operations Security first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.11 – Physical and Environmental Security

Sorin Mustaca — Mon, 08 Apr 2024 07:44:42 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.11, “Physical and Environmental Security”, which addresses the importance of protecting physical assets, facilities, and infrastructure that house information systems and assets. This annex provides guidelines for implementing controls to safeguard against unauthorized access, damage, or interference to physical assets and environmental conditions.

Contents

Importance of Physical and Environmental Security

Physical and environmental security measures are critical for ensuring the integrity, availability, and confidentiality of information assets. Annex A.11 underscores this importance by:

Preventing Unauthorized Access: Implementing physical access controls helps prevent unauthorized individuals from gaining physical access to sensitive areas, equipment, and facilities.
Protecting Against Threats: Securing facilities against threats such as theft, vandalism, natural disasters, and environmental hazards mitigates risks to information assets and business continuity.
Maintaining Operational Continuity: Ensuring the availability of critical infrastructure, such as power, cooling, and environmental controls, is essential for maintaining uninterrupted operations of information systems and services.

Implementing Annex A.11 in Practice

To effectively implement Annex A.11, organizations can follow these practical steps:

Physical Access Controls: Implement access control mechanisms, such as locks, access cards, biometric systems, and security guards, to restrict access to physical facilities, server rooms, and sensitive areas.
Example: Install access card readers at entry points to data centers and server rooms, requiring authorized personnel to swipe their access cards for entry.
Perimeter Security: Secure the perimeter of facilities with physical barriers, fencing, gates, and surveillance cameras to deter unauthorized access and monitor perimeter activities.
Example: Install perimeter fencing around the organization’s premises, equipped with motion sensors and surveillance cameras to detect and deter intruders.
Security Lighting: Install adequate lighting around facilities, parking lots, and entry points to deter intruders and enhance visibility for security personnel and surveillance cameras.
Example: Install motion-activated lights around the perimeter of buildings and parking areas to illuminate dark areas when motion is detected.
Environmental Controls: Implement environmental controls, such as temperature control systems, fire suppression systems, and humidity monitors, to maintain optimal conditions for information systems and equipment.
Example: Install HVAC (Heating, Ventilation, and Air Conditioning) systems equipped with temperature and humidity sensors to regulate environmental conditions in server rooms and data centers.
Monitoring and Surveillance: Deploy surveillance cameras, alarm systems, and intrusion detection sensors to monitor facilities, detect unauthorized access attempts, and trigger alerts in case of security breaches.
Example: Install surveillance cameras at key locations within facilities, integrated with motion detection and remote monitoring capabilities to detect and respond to security incidents in real-time.

Audit of Compliance with Annex A.11

Auditing compliance with Annex A.11 is essential for evaluating an organization’s adherence to physical and environmental security requirements. Here’s how the audit process typically unfolds:

Audit Preparation: Gather documentation related to physical and environmental security policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Conduct on-site visits to assess implementation of physical and environmental security controls. Review documentation, inspect facilities, and observe security measures in action. Use checklists or assessment tools to evaluate compliance.
Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in physical and environmental security implementation.
Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusion

ISO 27001:2022 Annex A.11 emphasizes the importance of physical and environmental security in protecting information assets and ensuring business continuity. By implementing robust controls and measures to secure physical facilities, infrastructure, and environmental conditions, organizations can mitigate risks and safeguard against unauthorized access, damage, or interference. Regular audits help assess compliance with Annex A.11 requirements and drive continuous improvement in physical and environmental security practices.

The post Understanding ISO 27001:2022 Annex A.11 – Physical and Environmental Security first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.10 – Cryptography

Sorin Mustaca — Thu, 04 Apr 2024 07:09:24 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.10, “Cryptography”, which plays a vital role in ensuring the confidentiality, integrity, and authenticity of sensitive information.

This annex provides guidelines for implementing cryptographic controls to protect data assets from unauthorized access, manipulation, and disclosure.

Contents

Importance of Cryptography

Cryptography is essential for securing data in transit, at rest, and in use. Annex A.10 underscores this importance by:

Confidentiality: Encrypting data using cryptographic algorithms prevents unauthorized parties from accessing sensitive information.
Integrity: Cryptographic hash functions help ensure the integrity of data by detecting any unauthorized alterations or tampering.
Authenticity: Digital signatures and cryptographic certificates verify the authenticity of messages and the identity of parties involved in communication.

Implementing Annex A.10 in Practice

To effectively implement Annex A.10, organizations can follow these practical steps:

Data Encryption: Identify sensitive data assets that require encryption, such as personally identifiable information (PII), financial records, or intellectual property. Implement encryption mechanisms to protect data both in transit and at rest.Example: Use Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocols to encrypt data transmitted over the internet, such as web traffic or email communications.
Key Management: Establish key management procedures for generating, storing, distributing, and revoking cryptographic keys. Ensure that keys are protected from unauthorized access and securely stored.Example: Implement a key management system to generate and store cryptographic keys securely, enforce access controls, and rotate keys periodically to enhance security.
Digital Signatures: Use digital signatures to authenticate the origin and integrity of electronic documents, messages, or transactions. Implement digital signature algorithms and certificate authorities to verify signatures and ensure their validity.Example: Digitally sign important documents, such as contracts or legal agreements, using a digital signature certificate issued by a trusted certificate authority.
Hash Functions: Apply cryptographic hash functions to generate unique fingerprints or checksums for data integrity verification. Use hash algorithms such as SHA-256 or SHA-3 to compute hashes of data and compare them to verify integrity.Example: Calculate the hash value of files or documents before transmission or storage and compare it to the hash value generated at the destination to ensure data integrity.
Cryptographic Controls: Implement additional cryptographic controls, such as message authentication codes (MACs), key derivation functions (KDFs), or random number generators (RNGs), to enhance security and protect against cryptographic attacks.Example: Use HMAC (Hash-based Message Authentication Code) to verify the integrity and authenticity of messages transmitted over insecure channels, such as public networks.

Audit of Compliance with Annex A.10

Auditing compliance with Annex A.10 is essential for evaluating an organization’s adherence to cryptographic controls. Here’s how the audit process typically unfolds:

Audit Preparation: Gather documentation related to cryptographic policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Conduct on-site visits to assess implementation of cryptographic controls. Review documentation, interview personnel, and observe cryptographic practices. Use checklists or assessment tools to evaluate compliance.
Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in cryptographic implementation.
Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusion

ISO 27001:2022 Annex A.10 highlights the importance of cryptography in protecting sensitive information and ensuring data security. By implementing robust cryptographic controls, organizations can safeguard data confidentiality, integrity, and authenticity against unauthorized access and manipulation. Regular audits help assess compliance with Annex A.10 requirements and drive continuous improvement in cryptographic practices.

The post Understanding ISO 27001:2022 Annex A.10 – Cryptography first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.9 – Access Control

Sorin Mustaca — Mon, 01 Apr 2024 07:00:44 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.9, “Access Control”.

Access control is a fundamental component of information security management systems (ISMS).

It provides guidelines for implementing controls to ensure that only authorized individuals have access to information assets and resources.

Contents

Importance of Access Control

Access control is crucial for protecting sensitive information, preventing unauthorized access, and maintaining the confidentiality, integrity, and availability of organizational assets. Annex A.9 underscores this importance by:

Protecting Information Assets: Implementing access controls helps safeguard sensitive data, intellectual property, and critical systems from unauthorized disclosure, modification, or destruction.
Enforcing Least Privilege: Access control mechanisms ensure that individuals have access only to the resources and information necessary to perform their job responsibilities, minimizing the risk of misuse or abuse.
Mitigating Insider Threats: Controls such as user authentication, authorization, and auditing help detect and deter insider threats, including malicious activities by employees, contractors, or third-party users.

Implementing Annex A.9 in Practice

To effectively implement Annex A.9, organizations can follow these practical steps:

Access Control Policy: Develop an access control policy that defines the principles, rules, and procedures governing access to information assets and resources. The policy should outline requirements for user authentication, authorization, access provisioning, and access revocation.Example: Define a password policy specifying requirements for password complexity, expiration, and reuse to strengthen authentication controls.
User Authentication: Implement robust authentication mechanisms to verify the identity of users accessing organizational systems and resources. This may include passwords, biometric authentication, multi-factor authentication (MFA), or single sign-on (SSO) solutions.Example: Deploy MFA solutions requiring users to authenticate using a combination of passwords and one-time passcodes sent to their mobile devices for accessing sensitive systems.
Authorization Controls: Define access control lists (ACLs), roles, and permissions to determine the level of access granted to users based on their roles, responsibilities, and organizational hierarchy.Example: Assign roles such as “administrator,” “manager,” and “user” with corresponding access rights and permissions to resources based on job responsibilities.
Access Provisioning and Revocation: Establish procedures for provisioning access to new users and revoking access for departing employees, contractors, or third-party users in a timely manner.Example: Develop an access request and approval process where users submit access requests, which are reviewed and approved by authorized personnel before access is provisioned.
Monitoring and Auditing: Implement logging and auditing mechanisms to track user activities, monitor access attempts, and detect unauthorized access or suspicious behavior.Example: Configure audit logs to record user login attempts, access permissions changes, and unauthorized access attempts for review and analysis.

Audit of Compliance with Annex A.9

Auditing compliance with Annex A.9 is essential for evaluating an organization’s adherence to access control requirements. Here’s how the audit process typically unfolds:

Audit Preparation: Gather documentation related to access control policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Conduct on-site visits to assess implementation of access control controls. Review documentation, interview personnel, and observe access control practices. Use checklists or assessment tools to evaluate compliance.
Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in access control implementation.
Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusions

ISO 27001:2022 Annex A.9 emphasizes the importance of access control in protecting information assets and mitigating security risks. By implementing robust access control mechanisms, organizations can prevent unauthorized access, enforce least privilege, and safeguard sensitive information. Regular audits help assess compliance with Annex A.9 requirements and drive continuous improvement in access control practices. Prioritizing access control is essential for organizations seeking to maintain the confidentiality, integrity, and availability of their information assets in an increasingly interconnected and digital world.

The post Understanding ISO 27001:2022 Annex A.9 – Access Control first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.8 – Asset Management

Sorin Mustaca — Tue, 26 Mar 2024 09:30:05 +0000

ISO 27001:2022 Annex A.8, “Asset Management,” addresses the importance of identifying, classifying, and managing information assets within an organization. This annex emphasizes the need for organizations to establish processes for inventorying assets, assessing their value, and implementing appropriate controls to protect them. In this technical educational article, we’ll explore how to implement Annex A.8 in practice, highlight its significance, and discuss the audit process for assessing compliance.

Contents

What is an Asset ?

In the context of ISO 27001:2022, an asset refers to anything that has value to an organization and needs to be protected.

This includes not only tangible assets such as

Physical assets:
- hardware and equipment
- buildings
- vehicles
People
- Employees
- Customers
- Suppliers
Software
Intangible
- Data
- Intellectual property
- Proprietary information
- Reputation
- Market Share

ISO 27001:2022 recognizes that assets come in various forms and play a crucial role in achieving an organization’s objectives.

What makes an asset worth to be added to the list?

Here are some key points to consider regarding assets in the context of ISO 27001:2022:

Identification: Organizations need to identify and inventory all their assets, including both tangible and intangible ones. This involves understanding what assets the organization possesses, where they are located, and who has ownership or responsibility for them. If this can be done, then the asset is worth enough to be considered to be managed.
Classification: Assets should be classified based on their value, sensitivity, and criticality to the organization. This classification helps prioritize protection efforts and allocate resources effectively. For example, sensitive customer data may be classified as high-value assets requiring stringent security measures. If an asset is classified with a category that makes it important for the company, then it should be definitely managed.
Risk Management: Assets are subject to various risks, including cybersecurity threats, natural disasters, and human error. Organizations need to conduct risk assessments to identify and mitigate threats to their assets effectively. This involves evaluating the likelihood and potential impact of risks and implementing controls to reduce risk to an acceptable level.
Protection: Based on the risk assessment for an asset, organizations must implement appropriate controls to protect their assets from unauthorized access, disclosure, alteration, or destruction. This includes measures such as access controls, encryption, backup procedures, and physical security measures. Based on the measures identified, an asset can be quite expensive to be protected, but losing it or damaging it might prove to be even more expensive.

Importance of Asset Management

Effective asset management is crucial for organizations to safeguard their information assets, optimize resource allocation, and mitigate risks. Annex A.8 underscores this importance by:

Risk Reduction: Identifying and classifying information assets helps organizations prioritize security measures and allocate resources effectively to mitigate risks.
Compliance: Maintaining an accurate inventory of assets and implementing appropriate controls ensures compliance with regulatory requirements and industry standards.
Cost Savings: Efficient asset management practices enable organizations to optimize resource utilization and avoid unnecessary expenses associated with redundant or underutilized assets.

Implementing Annex A.8 in Practice

To effectively implement Annex A.8, organizations can follow these practical steps:

Asset Identification: Begin by identifying all information assets within the organization, including hardware, software, data, and intellectual property. Establish criteria for identifying assets, such as ownership, criticality, and sensitivity.Example: Develop an asset inventory list categorizing assets based on their type, location, owner, and importance to business operations.
Asset Classification: Classify information assets based on their value, sensitivity, and criticality to the organization. Define classification levels or categories to differentiate between assets requiring different levels of protection.Example: Classify data assets as public, internal use only, confidential, or restricted based on their sensitivity and impact on the organization if compromised.
Asset Ownership: Assign ownership responsibilities for each information asset to designated individuals or departments within the organization. Clearly define roles and responsibilities for managing and protecting assigned assets.Example: Assign data ownership responsibilities to business units or functional departments responsible for creating, accessing, or managing specific types of data.
Risk Assessment: Conduct risk assessments to identify threats, vulnerabilities, and potential impacts on information assets. Assess the likelihood and impact of potential risks to prioritize mitigation efforts.Example: Perform a vulnerability assessment to identify weaknesses in IT systems and applications that could expose information assets to security threats.
Control Implementation: Implement appropriate controls to protect information assets from unauthorized access, disclosure, alteration, or destruction. Select controls based on the results of risk assessments and compliance requirements.Example: Implement access control mechanisms, such as user authentication, role-based access control (RBAC), and encryption, to safeguard sensitive information assets from unauthorized access.

Audit of Compliance with Annex A.8

Auditing compliance with Annex A.8 is essential for evaluating an organization’s adherence to asset management requirements. Here’s how the audit process typically unfolds:

Audit Preparation: The organization gathers documentation related to asset management policies, procedures, and controls. An audit team is appointed to facilitate the audit process.
Audit Planning: The audit team defines the audit scope, objectives, and criteria. They develop an audit plan outlining the audit activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Auditors conduct on-site visits to assess the implementation of asset management controls. They review documentation, interview personnel, and observe asset management practices in action. Auditors may use checklists or standardized assessment tools to evaluate compliance.
Audit Findings: After the on-site audit, auditors analyze their findings and identify areas of non-compliance or improvement opportunities. They document their observations, including strengths and weaknesses in the organization’s approach to asset management.
Reporting: Auditors prepare an audit report summarizing their findings, conclusions, and recommendations for corrective actions. The report is shared with senior management and relevant stakeholders for review and action.
Follow-up: Management addresses audit findings by implementing corrective actions and improvements as recommended. Follow-up audits may be conducted to verify the effectiveness of corrective measures and ensure ongoing compliance with Annex A.8 requirements.

Conclusions

ISO 27001:2022 Annex A.8 highlights the importance of asset management in safeguarding information assets and mitigating risks. By implementing robust processes for identifying, classifying, and managing information assets, organizations can optimize resource allocation, ensure compliance, and enhance their security posture. Regular audits help assess compliance with Annex A.8 requirements and drive continuous improvement in asset management practices. Prioritizing asset management is essential for organizations seeking to protect their valuable information assets and maintain trust in their operations.

The post Understanding ISO 27001:2022 Annex A.8 – Asset Management first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.7 – Human Resource Security

Sorin Mustaca — Fri, 22 Mar 2024 08:59:26 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.7, “Human Resource Security”.

Contents

These controls address the critical role that personnel play in information security within an organization. This annex emphasizes the need for organizations to implement measures to ensure that employees, contractors, and third-party users understand their roles and responsibilities in safeguarding sensitive information. In this technical educational article, we’ll explore how to implement Annex A.7 in practice, highlight the importance of human resource security, and discuss common challenges in its implementation.

Importance of Human Resource Security

Human resource security is integral to the overall effectiveness of an organization’s information security program. Annex A.7 addresses this importance by:

Establishing Trust: Ensuring that individuals with access to sensitive information are trustworthy and have undergone appropriate background checks and screening processes.
Minimizing Insider Threats: Implementing measures to mitigate the risk of insider threats, including unauthorized access, data breaches, and malicious activities by employees or contractors.
Enforcing Compliance: Ensuring that personnel are aware of and adhere to information security policies, procedures, and guidelines, thereby maintaining compliance with regulatory requirements and industry standards.

From experience, organizations often face challenges in effectively implementing human resource security measures due to:

Lack of Awareness: Employees may not fully understand their roles and responsibilities in maintaining information security, leading to inadvertent security breaches.
Insider Threats: Malicious activities by disgruntled employees, contractors, or third-party users pose significant risks to information security.
Employee Turnover: High employee turnover rates can make it challenging to manage access privileges and ensure the timely revocation of access for departing employees.
Compliance Complexity: Compliance with human resource security requirements, such as background checks and confidentiality agreements, can be complex and resource-intensive for organizations.

Implementing Annex A.7 in Practice

To effectively implement Annex A.7, organizations can follow these practical steps:

Screening and Selection: Establish robust screening and selection processes for hiring employees, contractors, and third-party users. Conduct background checks, reference checks, and verification of qualifications to ensure the integrity and trustworthiness of individuals joining the organization.Example: Implement a thorough background screening process that includes criminal background checks, employment history verification, and reference checks for all new hires.
Training and Awareness: Provide comprehensive training and awareness programs to educate personnel about their roles and responsibilities in maintaining information security. Ensure that employees understand the importance of safeguarding sensitive information and the consequences of non-compliance.Example: Conduct regular cybersecurity awareness training sessions covering topics such as phishing awareness, password hygiene, social engineering tactics, and incident reporting procedures.
Access Control: Implement robust access control mechanisms to restrict access to sensitive information based on the principle of least privilege. Define clear roles and responsibilities for granting, revoking, and reviewing access permissions.Example: Implement role-based access control (RBAC) to assign access rights to employees based on their job responsibilities and organizational roles. Regularly review and update access permissions to ensure alignment with personnel changes.
Confidentiality Agreements: Require employees, contractors, and third-party users to sign confidentiality agreements or non-disclosure agreements (NDAs) outlining their obligations to protect confidential information and intellectual property.Example: Develop standard confidentiality agreements that clearly define the types of information considered confidential, the obligations of the parties involved, and the consequences of breaches of confidentiality.
Exit Procedures: Implement formal exit procedures to manage the departure of employees, contractors, and third-party users. Revoke access privileges, collect company-owned devices, and conduct exit interviews to ensure a smooth transition and mitigate the risk of data breaches.Example: Develop an exit checklist outlining the steps to be followed when an employee or contractor leaves the organization, including revoking access to systems and data, collecting company-owned assets, and conducting knowledge transfer sessions.

Audit of Compliance with Annex A.7

Auditing human resource security is essential for evaluating an organization’s compliance with Annex A.7 requirements. Here’s how the audit process typically unfolds:

Audit Preparation: The organization gathers documentation related to human resource security policies, procedures, and controls. An audit team is appointed to facilitate the audit process.
Audit Planning: The audit team defines the audit scope, objectives, and criteria. They develop an audit plan outlining the audit activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Auditors conduct on-site visits to assess the implementation of human resource security controls. They review documentation, interview personnel, and observe security practices in action. Auditors may use checklists or standardized assessment tools to evaluate compliance.
Audit Findings: After the on-site audit, auditors analyze their findings and identify areas of non-compliance or improvement opportunities. They document their observations, including strengths and weaknesses in the organization’s approach to human resource security.
Reporting: Auditors prepare an audit report summarizing their findings, conclusions, and recommendations for corrective actions. The report is shared with senior management and relevant stakeholders for review and action.
Follow-up: Management addresses audit findings by implementing corrective actions and improvements as recommended. Follow-up audits may be conducted to verify the effectiveness of corrective measures and ensure ongoing compliance with Annex A.7 requirements.

Conclusions

By implementing robust screening processes, training programs, access controls, and exit procedures, organizations can mitigate insider threats and ensure compliance with regulatory requirements.

Regular audits help assess compliance with Annex A.7 requirements and identify areas for improvement in human resource security practices.

Despite challenges, prioritizing human resource security is essential for safeguarding sensitive information and maintaining trust in organizational operations.

The post Understanding ISO 27001:2022 Annex A.7 – Human Resource Security first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.6 – Organization of Information Security

Sorin Mustaca — Wed, 20 Mar 2024 09:44:53 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

We start today with ISO 27001:2022 Annex A.6, “Organization of Information Security”, which outlines requirements for establishing an effective management framework to govern information security within an organization. This annex emphasizes the importance of defining roles, responsibilities, and processes to ensure the confidentiality, integrity, and availability of information assets.

In this technical educational article, we’ll explore how to implement Annex A.6 in practice and elucidate the audit process for assessing compliance.

Contents
Toggle

Importance of Organization of Information Security
Implementing Annex A.6 in Practice
Auditing Compliance with Annex A.6
Conclusion

Importance of Organization of Information Security

A well-organized approach to information security is essential for maintaining the confidentiality, integrity, and availability of organizational assets. Annex A.6 helps organizations achieve this by:

Defining Responsibilities: Clearly delineating roles and responsibilities ensures accountability for information security tasks across the organization.
Establishing Processes: Formalizing processes for risk management, incident response, and access control streamlines security operations and enhances responsiveness to security incidents.
Ensuring Compliance: Implementing a structured framework for information security governance helps organizations meet regulatory and compliance requirements.

Implementing Annex A.6 in Practice

To effectively implement Annex A.6, organizations can follow these practical steps:

Define Information Security Roles and Responsibilities: Identify key stakeholders responsible for information security governance, including senior management, IT personnel, data owners, and end-users. Clearly define their roles and responsibilities in safeguarding information assets.Example: Establish a Security Steering Committee comprising senior management representatives and department heads to oversee information security initiatives and decision-making.
Develop Information Security Policies and Procedures: Create comprehensive policies and procedures covering areas such as access control, risk management, incident response, and asset management. Ensure alignment with organizational objectives and regulatory requirements.Example: Develop an Incident Response Plan outlining the steps to be followed in the event of a security incident, including incident detection, containment, eradication, and recovery.
Implement Security Controls: Deploy technical and administrative controls to mitigate security risks and protect information assets. These controls may include firewalls, intrusion detection systems, encryption mechanisms, and user access controls.Example: Implement role-based access control (RBAC) to restrict access to sensitive information based on users’ roles and responsibilities within the organization.
Provide Training and Awareness Programs: Educate employees about their roles in maintaining information security and raise awareness about common security threats and best practices. Conduct regular training sessions and awareness campaigns to reinforce security protocols.Example: Offer cybersecurity awareness training to employees covering topics such as phishing awareness, password hygiene, and social engineering tactics.
Establish Security Incident Management Procedures: Develop procedures for reporting, investigating, and responding to security incidents promptly. Define escalation paths and communication channels to ensure swift resolution of incidents.Example: Establish a Security Incident Response Team (SIRT) tasked with coordinating incident response efforts, conducting forensic investigations, and implementing remediation measures.

Auditing Compliance with Annex A.6

Audits play a crucial role in evaluating an organization’s compliance with Annex A.6 requirements. Here’s how the audit process typically unfolds:

Audit Preparation: The organization gathers documentation related to information security policies, procedures, and controls. An audit team is appointed to facilitate the audit process.
Audit Planning: The audit team defines the audit scope, objectives, and criteria. They develop an audit plan outlining the audit activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Auditors conduct on-site visits to assess the implementation of information security controls. They review documentation, interview personnel, and observe security practices in action. Auditors may use checklists or standardized assessment tools to evaluate compliance.
Audit Findings: After the on-site audit, auditors analyze their findings and identify areas of non-compliance or improvement opportunities. They document their observations, including strengths and weaknesses in the organization’s approach to information security.
Reporting: Auditors prepare an audit report summarizing their findings, conclusions, and recommendations for corrective actions. The report is shared with senior management and relevant stakeholders for review and action.
Follow-up: Management addresses audit findings by implementing corrective actions and improvements as recommended. Follow-up audits may be conducted to verify the effectiveness of corrective measures and ensure ongoing compliance with Annex A.6 requirements.

Conclusion

ISO 27001:2022 Annex A.6 underscores the importance of establishing a structured framework for organizing information security within an organization.

By following best practices for defining roles, responsibilities, processes, and controls, organizations can strengthen their security posture and mitigate risks effectively. Regular audits help assess compliance with Annex A.6 requirements and drive continuous improvement in information security governance.

The post Understanding ISO 27001:2022 Annex A.6 – Organization of Information Security first appeared on Sorin Mustaca's blog.

Understanding ISO 27001:2022 Annex A.5 – Information Security Policies

Sorin Mustaca — Mon, 18 Mar 2024 08:45:32 +0000

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

We start today with A.5. Information Security Policies.

Contents

Importance of Information Security Policies

Information security policies are crucial components of any organization’s cybersecurity framework. They provide guidelines and principles for safeguarding sensitive information, ensuring compliance with regulations, and mitigating risks.

ISO 27001:2022 Annex A.5 specifically addresses the establishment, implementation, and maintenance of information security policies within an organization. In this article, we’ll delve into the practical aspects of implementing Annex A.5 and how audits are conducted to assess compliance.

Information security policies serve as the foundation for an organization’s security posture. They outline the rules, responsibilities, and procedures for protecting data assets and managing security incidents. A well-defined set of policies helps in:

Clarifying Expectations: Employees understand their roles and responsibilities concerning information security.
Standardizing Practices: Consistent guidelines ensure uniformity in security measures across departments and functions.
Mitigating Risks: Policies help identify and address potential security threats before they escalate into breaches.
Compliance Requirements: Policies ensure adherence to legal, regulatory, and industry-specific compliance standards.

Implementing Annex A.5 in Practice

To effectively implement Annex A.5, organizations can follow these practical steps:

Policy Development: Begin by identifying the scope and objectives of the information security policies. Engage stakeholders from various departments to gather input and ensure alignment with business goals. Develop comprehensive policies covering areas such as access control, data protection, incident response, and risk management.Example: Develop an Acceptable Use Policy (AUP) outlining acceptable and prohibited uses of company IT resources, including email, internet usage, and software installations.
Approval and Communication: Once policies are drafted, obtain approval from senior management or the designated authority. Communicate the policies to all employees through training sessions, employee handbooks, or intranet portals. Ensure understanding and acceptance of the policies across the organization.Example: Conduct training sessions on the AUP to educate employees about acceptable use practices and consequences of policy violations.
Implementation and Enforcement: Translate policy requirements into actionable measures. Implement security controls, procedures, and guidelines to enforce policy compliance. Assign responsibilities to designated individuals or teams for monitoring and enforcing adherence to policies.Example: Implement access control mechanisms such as user authentication and role-based access to enforce the AUP’s guidelines on accessing sensitive data.
Review and Update: Regularly review and update information security policies to reflect changes in technology, business processes, or regulatory requirements. Solicit feedback from stakeholders and conduct periodic audits to assess policy effectiveness and identify areas for improvement.Example: Conduct annual reviews of the AUP to incorporate changes in technology trends and emerging security threats.

Auditing Compliance with Annex A.5

Audits play a vital role in evaluating an organization’s adherence to Annex A.5 requirements. Here’s how the audit process typically unfolds:

Preparation: Prior to the audit, the organization prepares by gathering relevant documentation, such as information security policies, procedures, and records of past audits. A designated audit team may be appointed to facilitate the audit process.
Audit Planning: The audit team defines the scope, objectives, and criteria for the audit. They develop an audit plan outlining the audit activities, timelines, and responsibilities of auditors and auditees.
On-site Audit: Auditors conduct on-site visits to assess the implementation of information security policies. They review documentation, interview personnel, and observe security practices in action. Auditors may use checklists or standardized assessment tools to evaluate compliance.
Audit Findings: After the on-site audit, auditors analyze their findings and identify areas of non-compliance or improvement opportunities. They document their observations, including strengths and weaknesses in policy implementation.
Reporting: Auditors prepare an audit report detailing their findings, conclusions, and recommendations for corrective actions. The report is shared with senior management and relevant stakeholders for review and action.
Follow-up: Management addresses audit findings by implementing corrective actions and improvements as recommended. Follow-up audits may be conducted to verify the effectiveness of corrective measures and ensure ongoing compliance with Annex A.5 requirements.

The post Understanding ISO 27001:2022 Annex A.5 – Information Security Policies first appeared on Sorin Mustaca's blog.

Annex A of ISO 27001:2022 explained and tips to prepare for an audit

Sorin Mustaca — Mon, 11 Mar 2024 08:00:09 +0000

We wrote in the previous article ISO 27001:2022: chapter by chapter description about ISO 27001:2022 Annex A.

Annex A of ISO 27001:2022 is a vital component of the standard, outlining a comprehensive set of controls that organizations can implement to mitigate information security risks effectively.

These controls cover a wide range of areas, including physical security, human resources, access control, and cryptography.

In this article, we go in each category of the Annex A controls, explore practical implementation strategies, and discuss auditing methodologies to ensure compliance and effectiveness.

This article just describes the categories and the strategies for implementation, the next articles will address each category and its controls in details.

Understanding Annex A Controls

Annex A of ISO 27001:2022 contains 14 control categories with a total of 93 controls, each addressing specific aspects of information security management.

Annex A of ISO 27001:2013 contains 14 control categories with a total of 114 controls, each addressing specific aspects of information security management.

Compared to the 2013 version, ISO 27001:2022 streamlines Annex A. The number of controls is reduced from 114 to 93, with 11 new additions reflecting evolving security threats.

IMPORTANT: Annex A in the versions 2022 vs 2013

The Annex A controls in the ISO 27001:2002 is massively reduced to examples for chapters 5 to 8. We consider this as not enough, and for this reason we will revert to using the Annex A from ISO 27001:2013.

In the 2013 version we can see the recommended controls for chapters 5 to 18 because they are more relevant by being more specific.

#	Annex Chapter number	Annex A chapter name	Controls in v. 2022	Chapter name	Controls in v. 2013
1	5	Organizational controls	37	IS Policies	2
2	6	People controls	8	Organization of IS	7
3	7	Physical controls	14	HR	6
4	8	Technological controls	34	Asset Management	10
5	9			Access Control	14
6	10			Cryptography	2
7	11			Physical and environmental security	15
8	12			Operations security	14
9	13			Communications security	7
10	14			System acquisition, development and maintenance	13
11	15			Supplier relationships	5
12	16			Information security incident management	7
13	17			Information security aspects of business continuity management	4
14	18			Compliance	8
		TOTAL	93		114

For the remaining of the article series, we will address the chapters as described in ISO 27001:2013 but we will name them ISO 27001:2022 for better searching.

However, we will mention always deltas between versions 2013 and 2022.

The 2022 revision of ISO 27001 restructured Annex A controls into four main categories:

Main Categories of ISO 27001:2022 Controls

1. Organizational Security

This category focuses on establishing the organizational framework and governance structure necessary to manage information security effectively. It encompasses policies, procedures, and responsibilities for safeguarding information assets and ensuring compliance with regulatory requirements.

Sub-Categories:

Information Security Policies (A.5)
Organization of Information Security (A.6)
Human Resource Security (A.7)
Asset Management (A.8)

2. Technical Security

This category addresses the technical aspects of information security, including access control, cryptography, and secure system development and maintenance. It involves implementing controls and measures to protect information assets from unauthorized access, alteration, or disclosure.

Sub-Categories:

Access Control (A.9)
Cryptography (A.10)
Physical and Environmental Security (A.11)
Operations Security (A.12)
Communications Security (A.13)
System Acquisition, Development, and Maintenance (A.14)

3. External Relationships

This category focuses on managing security risks associated with external relationships, such as third-party suppliers and service providers. It involves assessing and monitoring the security posture of external parties and establishing contractual agreements to ensure compliance and data protection.

Sub-Categories:

Supplier Relationships (A.15)

4. Incident Management and Continuity Planning

This category addresses preparedness and response to security incidents, as well as ensuring business continuity in the event of disruptions. It involves developing incident response plans, conducting drills, and implementing measures to minimize the impact of incidents on business operations.

Sub-Categories:

Information Security Incident Management (A.16)
Information Security Continuity (A.17)
Compliance (A.18)

By categorizing the controls into these main categories, organizations can better understand the holistic approach required to manage information security effectively. Each category addresses specific aspects of security management, ensuring comprehensive coverage and alignment with ISO 27001:2022 requirements.

Implementation in Practice

Implementing Annex A controls requires a systematic approach tailored to the organization’s unique needs and risk profile.

Organizations should start by conducting a gap analysis and a comprehensive risk assessment to identify vulnerabilities and prioritize control implementation.

Based on the assessment findings, organizations can develop action plans to address gaps and deploy appropriate controls across different layers of their information systems.

For example,

implementing access control measures may involve defining user roles and privileges, implementing authentication mechanisms, and enforcing least privilege principles.
deploying encryption controls may require selecting suitable encryption algorithms, managing encryption keys, and implementing secure transmission protocols.

While Annex A offers a rich library of controls, remember, it’s not a one-size-fits-all approach. Organizations should conduct a risk assessment to identify their specific vulnerabilities and choose the most relevant controls.

Remember:

Risk-Based Approach: Always prioritize controls that address the most significant information security risks identified in your organization.
Documentation: Document the implemented controls and how they address identified risks. This is crucial for audit purposes.
Continuous Improvement: Regularly review the effectiveness of your controls and update them as needed to adapt to evolving threats and organizational changes.

Conduct site visits to assess physical security measures, review access logs, and verify compliance with environmental control standards.

8. Operations Security (A.12)

Implementation
Develop procedures for system backups, change management, and incident response.

Audit
Review operational procedures, assess the effectiveness of malware protection, and analyze incident response plans.

9. Communications Security (A.13)

Implementation
Secure communication channels, implement encryption protocols, and establish procedures for remote access.

Audit
Review network configurations, assess the strength of encryption protocols, and analyze network logs for suspicious activities.

10. System Acquisition, Development, and Maintenance (A.14)

Implementation
Define secure coding practices, conduct security assessments, and implement change management procedures.

Audit
Review software development policies, assess code review and testing processes, and analyze change management records.

11. Supplier Relationships (A.15)

Implementation
Assess supplier security posture, establish contractual agreements, and monitor supplier performance.

Audit
Review supplier contracts, assess supplier assessment processes, and verify compliance with contractual security requirements.

12. Information Security Incident Management (A.16)

Implementation
Develop an incident response plan, define roles and responsibilities, and conduct regular drills.

Audit
Review the incident response plan, assess incident detection and response procedures, and analyze incident reports.

13. Information Security Continuity (A.17)

Implementation
Develop a business continuity plan, implement backup and recovery procedures, and conduct regular tests.

Audit
Review the business continuity plan, assess backup and recovery procedures, and analyze test results.

14. Compliance (A.18)

Implementation
Identify applicable regulations, develop policies and procedures, and conduct regular audits.

Audit
Review compliance documentation, assess compliance monitoring processes, and verify compliance with regulatory requirements.

Next article:

We analyze each of the categories of the Annex A ISO 27001:2022.

The post Annex A of ISO 27001:2022 explained and tips to prepare for an audit first appeared on Sorin Mustaca's blog.

ISO 27001:2022: chapter by chapter description

Sorin Mustaca — Fri, 01 Mar 2024 08:00:07 +0000

I’ve been asked many times by customers, especially those in automotive industry, who deal with the TISAX certification, which is based on ISO 27001, if I can make them a summary of the ISO 27001 standard.

It turns out that there has been a while since I read it, I think it was somewhere in 2016. That was the ISO 27001:2013 and in the meanwhile, the version 2022 was released.

So, let’s start with the delta between 2013 and 2022 and then we will focus on each chapter. For each chapter, we summary explain the goal, the actions required to implement the requirement and the implementation of the controls.

What’s New in ISO 27001:2022

The October 2022 revision of ISO 27001 incorporates several updates and enhancements compared to the previous 2013 version. The changes were mostly cosmetic and include restructuring and refining existing requirements.

The biggest change is Annex A which specific controls derived from ISO 27002:2022.

One significant change is the increased emphasis on the context of the organization, requiring organizations to conduct more comprehensive assessments of internal and external factors that impact information security.

The Annex A controls have been restructured and consolidated to reflect current security challenges and to reflect more modern risks and their associated controls.

Additionally, there is a greater focus on leadership involvement and accountability, with explicit requirements for top management to demonstrate active participation in setting information security objectives and promoting a culture of security awareness.

Implement security controls based on the results of the risk assessment and risk treatment plans.
Monitor and review security controls regularly to ensure effectiveness and compliance with policies and procedures.
Establish incident response and business continuity plans to mitigate the impact of security incidents and disruptions.

Implementation

Automate routine security tasks where possible to streamline operations and improve efficiency. Conduct regular audits and assessments to verify compliance with security policies and procedures. Continuously improve security controls based on lessons learned from security incidents and emerging threats.

Chapter 9: Performance Evaluation

Goal: Monitor, measure, analyze, and evaluate the performance of the ISMS to ensure its effectiveness and continual improvement.

Actions:

Define key performance indicators (KPIs) to measure the effectiveness of information security controls.
Conduct internal audits and management reviews to assess compliance with ISO 27001 requirements and identify areas for improvement.
Implement corrective and preventive actions to address non-conformities and enhance the performance of the ISMS.

Implementation: Establish a performance monitoring and reporting framework to track progress against established KPIs. Use data-driven insights to identify trends, patterns, and areas for improvement. Engage stakeholders in regular reviews and discussions to foster a culture of continual improvement.

Chapter 10: Improvement

Goal: Take corrective and preventive actions to address non-conformities, enhance the effectiveness of the ISMS, and achieve continual improvement.

Actions:

Implement corrective actions to address non-conformities identified during audits, assessments, or incident investigations.
Identify opportunities for preventive actions to mitigate potential risks and prevent recurrence of security incidents.
Document lessons learned and best practices to inform future decision-making and enhance the maturity of the ISMS.

Implementation: Establish a formal process for documenting and tracking corrective and preventive actions. Encourage proactive identification and resolution of issues to prevent their escalation. Foster a culture of innovation and collaboration to drive continual improvement across the organization.

What’s next?

We will focus in one of the next articles on Annex A of ISO 27001:2022.

The information security controls listed in Table A.1 are directly derived from and aligned with those listed in ISO/IEC 27002:2022, Clauses 5 to 8, and shall be used in context with 6.1.3. Information security risk treatment.

The post ISO 27001:2022: chapter by chapter description first appeared on Sorin Mustaca's blog.

The ISO 27000 family of protocols and their role in cybersecurity

Sorin Mustaca — Wed, 28 Feb 2024 10:55:16 +0000

The ISO 27000 family of protocols represent a series of standards developed by the International Organization for Standardization (ISO) to address various aspects of information security management. These standards provide a framework for organizations to establish, implement, maintain, and continually improve their information security management systems (ISMS). Each standard within the ISO 27000 family serves a specific purpose and contributes to the overall cybersecurity posture of an organization.

The highlight of the set is 27001 specifying the requirements necessary to implement, maintain and manage an ISMS, within the process of continuous improvement known as PDCA, an acronym for Plan-Do-Check-Act, in relation to the planning, doing, verifying and acting phases.

On the other hand, 27002, is a set of 114 controls, grouped into 14 domains, which aim to facilitate good practices in relation to the management of the ISMS.

Note that the titles written in Italic are industry sector specific.

ISO 27000: Overview and vocabulary

ISO 27000 provides the overview of information security management systems (ISMS). It also provides terms and definitions commonly used in the ISMS family of standards. It is applicable to all types and sizes of organization (e.g. commercial enterprises, government agencies, not-for-profit organizations).

ISO 27001: Information Security Management Systems (ISMS)

ISO 27001 is the cornerstone of the ISO 27000 family, focusing on the establishment, implementation, maintenance, and continual improvement of an ISMS. It provides a systematic approach for identifying, assessing, and managing information security risks, ensuring the confidentiality, integrity, and availability of sensitive information. ISO 27001 helps organizations align their information security practices with business objectives, regulatory requirements, and best practices in the industry.

ISO 27002: Code of Practice for Information Security Controls

ISO 27002 complements ISO 27001 by providing guidance on the selection, implementation, and management of information security controls. It offers a comprehensive set of best practices and security controls organized into categories such as information security policies, organization of information security, human resource security, and asset management. ISO 27002 helps organizations tailor their security controls to specific risks and operational requirements, enhancing the effectiveness of their ISMS.

ISO 27003: Guidelines for the Implementation of an ISMS

ISO 27003 provides guidance on the implementation of an ISMS based on the principles and requirements outlined in ISO 27001. It offers practical recommendations for planning, executing, monitoring, and improving the implementation process, helping organizations navigate the complexities of establishing a robust ISMS. ISO 27003 assists organizations in defining project objectives, roles and responsibilities, and implementation milestones to ensure a successful ISMS deployment.

ISO 27004: Information Security Management Measurement

ISO 27004 focuses on the measurement and monitoring of information security performance within an organization. It provides guidance on defining, implementing, and evaluating key performance indicators (KPIs) and metrics to assess the effectiveness of security controls and the overall ISMS. ISO 27004 enables organizations to gather actionable insights into their information security posture, identify areas for improvement, and demonstrate the value of their security investments to stakeholders.

ISO 27005: Information Security Risk Management

ISO 27005 provides guidelines for conducting risk assessments and managing information security risks effectively. It offers a systematic approach for identifying, analyzing, evaluating, and treating information security risks based on organizational objectives, context, and risk tolerance. ISO 27005 helps organizations prioritize risk mitigation efforts, allocate resources efficiently, and make informed decisions to protect their information assets from potential threats.

ISO 27006: Requirements for ISMS Certification

ISO 27006 specifies requirements for organizations seeking certification of their ISMS against ISO 27001. It outlines the criteria for certification bodies to assess the conformity of an organization’s ISMS with the requirements of ISO 27001 and ensure impartiality, competence, and consistency in the certification process. ISO 27006 provides assurance to stakeholders that an organization’s ISMS meets internationally recognized standards for information security management.

ISO 27007: Guidelines for Information Security Management Systems Auditing

ISO 27007 provides guidelines for auditing information security management systems (ISMS) based on the requirements specified in ISO 27001. It offers recommendations for planning, conducting, and reporting ISMS audits to ensure their effectiveness and compliance with ISO 27001 standards. ISO 27007 helps organizations evaluate the performance of their ISMS, identify areas for improvement, and demonstrate conformance with regulatory requirements and industry best practices. This standard is crucial for ensuring the integrity and reliability of ISMS audits, providing assurance to stakeholders about the effectiveness of information security controls.

ISO 27008: Guidelines for Auditors on Information Security Controls

ISO 27008 provides guidance to auditors on assessing the effectiveness of information security controls within an organization. It offers a framework for evaluating the design, implementation, and operation of security controls based on established criteria and best practices. ISO 27008 helps auditors ensure the adequacy and appropriateness of security controls in mitigating information security risks and safeguarding sensitive information assets. By following the guidelines outlined in ISO 27008, auditors can provide valuable insights and recommendations to organizations for strengthening their information security posture.

ISO 27009: Sector-specific Application of ISO 27001

ISO 27009 provides guidance on the sector-specific application of ISO 27001 for organizations operating in specialized industries or sectors. It offers recommendations for tailoring the requirements of ISO 27001 to meet the unique needs, challenges, and regulatory requirements of specific sectors such as healthcare, finance, telecommunications, and government. ISO 27009 helps organizations enhance the relevance and effectiveness of their ISMS by addressing sector-specific risks and compliance obligations. By aligning with ISO 27009 guidelines, organizations can streamline the implementation of ISO 27001 and achieve greater consistency in information security management across sectors.

ISO 27010: Information Security Management for Inter-sector and Inter-organizational Communications

ISO 27010 provides guidelines for managing information security in inter-sector and inter-organizational communications. It offers recommendations for establishing secure communication channels, sharing sensitive information, and collaborating with external partners, suppliers, and stakeholders. ISO 27010 helps organizations mitigate the risks associated with exchanging information across different sectors and jurisdictions, ensuring confidentiality, integrity, and availability throughout the communication process. By adhering to ISO 27010 guidelines, organizations can enhance trust, transparency, and security in their inter-organizational relationships and collaborations.

ISO 27011: Information Security Management Guidelines for Telecommunications Organizations

ISO 27011 offers guidelines for implementing information security management systems (ISMS) in telecommunications organizations. It provides recommendations for addressing sector-specific risks, threats, and regulatory requirements related to information security in the telecommunications industry. ISO 27011 helps telecommunications organizations enhance the resilience of their networks, systems, and services against cyber threats, ensuring the confidentiality, integrity, and availability of critical communications infrastructure. By following ISO 27011 guidelines, telecommunications organizations can strengthen their security posture, build customer trust, and maintain compliance with industry standards and regulations.

ISO 27012: Guidelines for Cybersecurity

ISO 27012 provides guidelines for managing cybersecurity risks within organizations. It offers recommendations for establishing cybersecurity policies, procedures, and controls to protect against cyber threats and vulnerabilities. ISO 27012 helps organizations develop a proactive approach to cybersecurity, focusing on prevention, detection, and response to cyber incidents. By aligning with ISO 27012 guidelines, organizations can enhance their resilience against evolving cyber threats, minimize the impact of security breaches, and safeguard sensitive information assets. ISO 27012 also promotes collaboration and information sharing among stakeholders to strengthen cybersecurity capabilities and mitigate common threats across sectors.

ISO 27012: Guidelines for Cybersecurity Information Sharing

ISO 27012 provides guidelines for organizations to establish frameworks for sharing cybersecurity information effectively. It offers recommendations for developing policies, procedures, and technical mechanisms to facilitate the exchange of threat intelligence and incident data among stakeholders. ISO 27012 aims to improve situational awareness, enhance threat detection and response capabilities, and foster collaboration within the cybersecurity community. By adhering to ISO 27012 guidelines, organizations can strengthen their cybersecurity posture, mitigate emerging threats, and contribute to a more resilient and secure cyber ecosystem.

ISO 27013: Guidance on the Integration and Implementation of ISMS with ISO 20000-1

ISO 27013 offers guidance on integrating and implementing an Information Security Management System (ISMS) with the requirements of ISO 20000-1, which focuses on IT service management. It provides recommendations for aligning information security practices with service management processes, ensuring consistency and effectiveness in managing IT services and information security risks. ISO 27013 helps organizations enhance the synergy between their ISMS and IT service management initiatives, resulting in improved service delivery, risk management, and customer satisfaction.

ISO 27014: Governance of Information Security

ISO 27014 provides guidance on establishing and maintaining effective governance structures for information security management within organizations. It offers recommendations for defining roles, responsibilities, and decision-making processes related to information security governance, ensuring accountability and oversight at all levels of the organization. ISO 27014 helps organizations establish a culture of security, align information security practices with business objectives, and promote continuous improvement in information security governance. By adhering to ISO 27014 guidelines, organizations can enhance their resilience against cyber threats, improve regulatory compliance, and build trust with stakeholders.

ISO 27015: Information Security Management for Financial Services

ISO 27015 offers guidance on implementing information security management systems (ISMS) in the financial services sector.

ISO 27016: Information Security Management for the Banking and Financial Services Sector

ISO 27016 provides guidance on implementing information security management systems (ISMS) specifically tailored to the banking and financial services sector.

ISO 27017: Cloud Services Security

ISO 27017 provides guidelines for implementing information security controls in cloud computing environments. It offers recommendations for cloud service providers and cloud customers to address security risks associated with cloud services, including data confidentiality, integrity, and availability. ISO 27017 helps organizations establish trust in cloud computing by addressing common security concerns and ensuring compliance with regulatory requirements. By following ISO 27017 guidelines, organizations can enhance the security of their cloud-based systems and data, mitigate risks associated with cloud adoption, and realize the benefits of cloud computing securely.

ISO 27018: Protection of Personally Identifiable Information (PII) in Public Clouds

ISO 27018 focuses on the protection of personally identifiable information (PII) in public cloud environments. It provides guidelines for cloud service providers to implement measures for protecting PII and ensuring privacy compliance in cloud-based services. ISO 27018 helps organizations address privacy concerns associated with cloud computing, establish trust with customers, and demonstrate compliance with data protection regulations. By adhering to ISO 27018 guidelines, cloud service providers can enhance transparency, accountability, and control over PII processing activities, thereby improving customer confidence and satisfaction in cloud services.

ISO 27019: Information security controls for the energy utility industry

ISO 27019 provides guidance based on ISO/IEC 27002:2013 applied to process control systems used by the energy utility industry for controlling and monitoring the production or generation, transmission, storage and distribution of electric power, gas, oil and heat, and for the control of associated supporting processes.

Interplay and Importance in Cybersecurity

The ISO 27000 family of protocols works together synergistically to provide a holistic approach to information security management.

The importance of these standards in cybersecurity cannot be overstated. By adopting the ISO 27000 family of protocols, organizations can strengthen their resilience against evolving cyber threats, enhance their regulatory compliance, and build trust with customers, partners, and regulators.

These standards promote a risk-based approach to information security, enabling organizations to identify and mitigate potential risks proactively, rather than reactively.

Overall, the ISO 27000 family of protocols plays a critical role in elevating cybersecurity practices and promoting a culture of security and resilience in organizations worldwide.

Additional resources

https://www.iso.org/search.html?q=27000
https://standards.iso.org./ittf/PubliclyAvailableStandards/ – List of publicly available standards : ISO 27000:2018 is free.
https://blog.grclab.com/p/the-iso-27000-family-of-standards
https://www.youtube.com/watch?app=desktop&v=7PscOoWtR7g&ab_channel=TheGRCLab

The post The ISO 27000 family of protocols and their role in cybersecurity first appeared on Sorin Mustaca's blog.

Risk Assessment of AWS services used in building a resilient Web App on AWS

Sorin Mustaca — Thu, 08 Feb 2024 08:00:36 +0000

We wrote here in the article “Building Resilient Web Applications on AWS: A Comprehensive Approach to Security” how to use certain AWS services to implement a resilient web based application.

The services mentioned require also a brief analysis in respect to Security, Confidentiality, Integrity, Availability and Privacy.

CloudTrail

AWS CloudTrail records API calls and creates log files, providing visibility into user activity, resource changes, and actions taken within your AWS account.

Risk Assessment

Security: Unauthorized modifications to CloudTrail settings or log tampering.
Confidentiality: Exposure of sensitive log data.
Integrity: Unauthorized access to CloudTrail logs.
Availability: Disruptions in CloudTrail could impact auditability.

Mitigation

Implement access controls, enable log file integrity validation, regularly review logs, and use redundant log storage.

Privacy

Data Collection: CloudTrail logs AWS account activity, potentially containing sensitive information.
Data Storage: Logs include API calls and identity details, stored securely by AWS.
Data Retention: AWS retains logs for a limited time and may use aggregated data for service improvement.

CloudWatch

CloudWatch is a monitoring service that provides real-time insights into AWS resources and applications, helping you respond quickly to events or changes in your environment.

Risk Assessment

Security: Unauthorized access to CloudWatch data.
Confidentiality: Exposure of sensitive monitoring data.
Integrity: Unauthorized modifications to monitoring configurations.
Availability: Relies on underlying infrastructure; disruptions may impact real-time monitoring.

Mitigation

Implement access controls, encrypt sensitive data, conduct regular audits, and employ redundancy for critical components.

Privacy

Data Collection: CloudWatch collects and monitors performance and operational data.
Data Storage: Metric data and configurations are stored securely by AWS.
Data Retention: AWS retains metric data for a limited time and may use aggregated data for service improvement.

AWS IAM

IAM is AWS’ cloud-based identity and access management service, providing authentication and authorization for users and devices.

Risk Assessment

Security: Unauthorized access to user accounts or directory configurations.
Confidentiality: Exposure of sensitive identity information.
Integrity: Unauthorized modifications to user attributes or directory settings.
Availability: Downtime impacting authentication and access control.

Mitigation

Implement multi-factor authentication, strong password policies, regular security audits.

Privacy

Data Collection: AWS IAM collects and manages user authentication and authorization data.
Data Storage: User identities, permissions, and access policies are stored securely by AWS.
Data Retention: AWS retains user data for service functionality and may use aggregated data for service improvement, but individual user data is not disclosed externally.

AWS Fargate

AWS Fargate is a serverless compute engine for containers that lets you run containers without managing the underlying infrastructure.

Risk Assessment

Security: Unauthorized access to containerized applications.
Confidentiality: Exposure of sensitive container configurations.
Integrity: Unauthorized modifications to container environments.
Availability: Downtime impacting containerized application execution.

Mitigation

Implement access controls, encrypt container data, conduct regular security scans, and deploy in a redundant and scalable manner.

Privacy

Data Collection: Fargate processes and manages containerized applications.
Data Storage: Task and container configurations are stored securely by AWS.
Data Retention: AWS retains task and container data for a limited time and may use aggregated data for service improvement.

AWS WAF (Web Application Firewall)

AWS WAF is a web application firewall that helps protect web applications from common web exploits, such as SQL injection, cross-site scripting (XSS), and other malicious attacks.

It allows users to create custom rules or use managed rule sets to filter and block malicious traffic before it reaches applications.

Risk Assessment

Security: Unauthorized access to WAF configurations, potential bypassing of WAF rules by sophisticated attackers.
Confidentiality: Exposure of sensitive application data due to successful attacks.
Integrity: Unauthorized modifications to WAF rules or configurations.
Availability: Downtime or service disruption due to misconfigurations or overwhelming attacks.

Mitigation

Implement strong access controls, regularly update and fine-tune WAF rules, use managed rule sets, enable logging for analysis, and deploy redundant WAF instances for increased availability and load distribution.

Privacy

Data Collection: WAF collects logs containing information about incoming requests, potential threats, and blocked requests for security analysis.
Data Storage: Logs may include IP addresses and request details but are retained for a limited time, following AWS data retention policies.
Data Retention: AWS may use aggregated and anonymized data for improving the service but doesn’t share identifiable customer information.

AWS Lambda

A serverless stack based on AWS Lambda allows developers to build and deploy applications without managing servers, handling scalability automatically.

Risk Assessment

Security: Unauthorized access to serverless functions and configurations.
Confidentiality: Exposure of sensitive code and data processed by Lambdas.
Integrity: Unauthorized modifications to serverless function code.
Availability: Downtime impacting serverless function execution.

Mitigation

Implement access controls, encrypt sensitive data, conduct regular security scans, deploy in a redundant manner, and monitor for anomalies.

Privacy

Data Collection: Lambda functions process and execute code, potentially handling sensitive data.
Data Storage: Function configurations and logs may include details about processed data.
Data Retention: AWS retains logs for a limited time and may use aggregated data for service improvement.

AWS Secrets Manager

AWS Secrets Manager helps you protect access to your applications, services, and IT resources without upfront investment and on-going maintenance costs.

Risk Assessment

Security: Unauthorized access to stored secrets.
Confidentiality: Exposure of sensitive credentials and configuration details.
Integrity: Unauthorized modifications to stored secrets.
Availability: Downtime impacting applications relying on stored secrets.

Mitigation

Implement access controls, regularly rotate secrets, encrypt stored secrets, conduct regular audits, and use redundant Secrets Manager configurations.

Privacy

Data Collection: Secrets Manager stores sensitive configuration and credential data.
Data Storage: Secret configurations and access logs may include details about stored data.
Data Retention: AWS retains access logs for a limited time and may use aggregated data for service improvement.

CloudFront

Amazon CloudFront is a content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds.

It integrates with other Amazon Web Services products to give developers and businesses an easy way to distribute content to end-users.

Risk Assessment

Security: Unauthorized access to cached content or configurations, potential for content tampering during distribution.
Confidentiality: Exposure of sensitive content during distribution.
Integrity: Unauthorized modifications to distribution settings or cached content.
Availability: Downtime impacting content delivery due to misconfigurations or attacks.

Privacy

Data Collection: CloudFront collects logs that include IP addresses, user-agents, and request details for analytics and troubleshooting.
Data Storage: Logs may contain user-related information, but Amazon retains them for a limited period and follows privacy regulations.
Data Retention: Amazon may share aggregated and anonymized data for service improvement but doesn’t disclose individual customer data.

AWS S3

Amazon S3 is a scalable object storage service designed to store and retrieve any amount of data at any time.

Risk Assessment

Security: Unauthorized access to stored objects or bucket configurations.
Confidentiality: Exposure of sensitive data stored in S3.
Integrity: Unauthorized modifications to stored objects.
Availability: Downtime impacting data storage and retrieval.

Mitigation

Implement access controls, encrypt data at rest, conduct regular audits, use versioning, and deploy redundant S3 configurations.

Privacy

Data Collection: S3 stores object data, potentially including sensitive information.
Data Storage: Bucket configurations and access logs may include details about stored data.
Data Retention: AWS retains access logs for a limited time and may use aggregated data for service improvement.

EC2 (Elastic Compute Cloud)

AWS EC2 provides resizable compute capacity in the cloud, allowing users to run virtual servers for various applications and workloads.

Risk Assessment

Security: Unauthorized access to EC2 instances.
Confidentiality: Exposure of sensitive data processed by EC2 instances.
Integrity: Unauthorized modifications to instance configurations.
Availability: Downtime impacting applications hosted on EC2.

Mitigation

Implement access controls, regularly patch and update instances, encrypt sensitive data, deploy in a redundant manner, and use Auto Scaling for increased availability.

Privacy

Data Collection: EC2 instances may process and store data, potentially including sensitive information.
Data Storage: Instance configurations and logs may contain details about processed data.
Data Retention: AWS retains logs for a limited time and may use aggregated data for service improvement.

The post Risk Assessment of AWS services used in building a resilient Web App on AWS first appeared on Sorin Mustaca's blog.

Building Resilient Web Applications on AWS: A Comprehensive Approach to Security

Sorin Mustaca — Mon, 29 Jan 2024 11:18:11 +0000

Contents

I have been asked by friends and customers what is the best way to implement a web based application with minimum costs and good security. Of course, the best way is to define exactly what you want to achieve and let professionals do it, while keeping an eye on the Secure Software Development Lifecycle.

But, this article is not about SSDLC, it is about how to start web application development having also security as a top priority. Securing a classical web application involves a multi-layered approach, addressing the presentation, business logic, and database layers.

Most important thing to keep in mind when engaging into such an enterprise is: don’t try to do everything by yourself – use existing tools and services, which come with a more than decent security built-in.

This article explores how to architect a secure web application on AWS, but it can be applied very well to other cloud based services provider, and conduct a thorough risk assessment at each level.

A good security approach is to practice defense in depth, meaning that you should check and validate the security of the components used as well. This means that we need to perform at least a high-level risk assessment of these components as well.

Securing the Presentation Layer

At the forefront of user interaction, the presentation layer demands robust security measures. Amazon CloudFront serves as a reliable content delivery network, ensuring low latency and protection against DDoS attacks.

AWS Identity and Access Management (IAM) steps in to control access to resources at this layer, while AWS Web Application Firewall (WAF) safeguards against common web exploits and secures APIs.

The Presentation layer hosts the UI of the application, typically a website written in HTML5 or a combination of HTML, php, JS, or some high level programming languages that can produce HTML as output.

Such web UIs must be uploaded on a AWS S3 bucket read accessible to everyone and then configure the CloudFront to distribute it.

Risk Assessment at the Presentation Layer

Regularly review and adjust IAM policies to mitigate the risk of unauthorized access.
Conduct penetration testing on the web application to identify and address vulnerabilities.
Monitor CloudFront logs for unusual patterns indicative of a security threat.
Make sure nobody has unrestricted access to your S3 bucket hosting the web content

Security practices

If you collect data, make sure it is encrypted using AWS Secrets Manager;
Do not encrypt using your own keys, hardcoded in your application.
Do not invent yourself some “encryption” mechanism, which in the end is just an obfuscation.

Securing the Business Logic Layer

The business logic layer is the heart of a web application, where critical processes take place. Containerizing application logic using AWS Elastic Container Service (ECS) or AWS Fargate ensures enhanced isolation.

AWS Lambda, offering serverless computing, executes sensitive business logic securely. AWS Secrets Manager manages and rotates sensitive API keys and tokens.

Risk Assessment at the Business Logic Layer

– Regularly audit and review AWS Lambda functions to maintain the security of business logic.
– Conduct static and dynamic code analysis to identify vulnerabilities in the application logic.
– Implement AWS CloudWatch for real-time monitoring and alerting on anomalous Lambda function behavior.

Securing the Database Level

The database, housing crucial data, requires robust security measures. Amazon RDS provides secure and scalable relational databases with automatic backups and encryption.

Fine-grained access control through IAM roles and policies is essential for secure database access. AWS Key Management Service (KMS) handles encryption of data at rest within the database.

Risk Assessment at the Database Level

– Regularly audit and review database access controls and IAM roles to prevent unauthorized access.
– Implement automated vulnerability scanning tools for the database to identify potential weaknesses.
– Set up AWS CloudTrail to log and monitor all database-related API activity.

Continuous Monitoring and Response

Ensuring the ongoing security of a web application involves continuous monitoring and a robust incident response plan. AWS Security Hub acts as a centralized monitoring tool, while AWS Config rules automate the assessment and remediation of non-compliance.

An incident response plan with specific procedures for each layer of the web application architecture ensures a swift and effective response to security incidents.

In the next post: risk assessment for the Amazon services used in this article:

AWS IAM
AWS Elastic Container Service (ECS)
AWS Fargate
AWS Key Management Service (KMS)
AWS Lambda
AWS CloudTrail
AWS Secrets Manager
AWS CloudFront
AWS S3

Conclusion

By adopting a comprehensive security strategy across the presentation layer, business logic, and database levels, small organizations can build resilient and cost aware web applications on the AWS platform.

This approach, coupled with regular risk assessments, establishes a solid foundation for web application security, safeguarding against common cybersecurity threats.

The post Building Resilient Web Applications on AWS: A Comprehensive Approach to Security first appeared on Sorin Mustaca's blog.

TISAX: new Catalogue ISA v6 available

Sorin Mustaca — Sun, 17 Dec 2023 12:27:01 +0000

This post is more for me to quicker find the details.

Source: ISA Version 6 Now Available · ENX Portal

Here is a summary

ISA 6: The latest version of the ISA catalogue, published in October 2023, with many changes and improvements to address the challenges and needs of the industry.Download here.
Key changes in ISA 6: New and revised controls to strengthen protection, detection, response, recovery, and service continuity against cyber attacks, especially ransomware; new translations and references to other standards; more guidance and examples for implementation; updated data protection catalogue; removal of legacy structure and requirements.
Transition to ISA 6: A redline version of ISA 6 is available for download; the effective date for ISA 6 in TISAX is April 1st 2024; the transition rules are the same as in previous changes. Download here.

More details

ISA 6 comes with a large set of changes and improvements that are detailed in this posting. Most notably

Changes with more focus on IT- and OT availability of production suppliers,
Leading language is now English, multiple translations planned,
Addition of further implementation guidance,
Completely revised data protection catalogue,
New references to ISO/IEC 27001:2022 and NIST Cyber Security Framework Version 1.1, and
Further continuous improvement and maintenance.

When does v6 start to be used?

New TISAX Assessment Proceedings ordered until March 31st, 2024, will be conducted using ISA version 5.
New TISAX Assessment Proceedings ordered from April 1st, 2024, will be conducted using ISA version 6.
Assessment activities related to an existing assessment such as corrective action plan assessments, follow-ups or scope extensions will be conducted using the same version as the original assessment.

Resilience

The working group has ensured that all requirements in ISA/IEC 62443-2-1 are covered by ISA and that all controls from ISA chapter 5 are applicable. As an outcome, all relevant control questions in ISA now mapped to ISA/IEC 62443-2-1 and a few minor changes in requirements to perfectly align with the standard have been made. Additionally, the Working Group ISA has reworked key sections of the ISA that are vital to prevent the attacks. This includes a completely new control, 1.3.4, that requires the secure management of software on clients as well as added requirements in 5.2.6 and 5.3.1

Detection

The new control 1.6.1 is designed to ensure that it is clear what needs to be reported and that appropriate reporting mechanisms are established.

The text also mentions that recognizing that attacks cannot be successfully prevented holistically, an approach to minimizing the impact of a successful attack is needed.

Response

The new version of ISA, ISA 6, has introduced several new controls and requirements to minimize the impact of a successful attack and ensure an effective and timely recovery.

Control 1.6.2 is designed to ensure that security incidents are handled in an orderly, timely and professional manner and the organization has the chance to detect patterns of sophisticated attacks which are detected as isolated incidents.
Control 5.2.8 addresses service-continuity planning, including fallback modes of operation to keep key business processes running while relevant IT infrastructure is unavailable.
Control 1.6.3 is dedicated to ensuring that an organization is sufficiently prepared to deal with a crisis.

Recovery

The new control 5.2.9 is designed to prepare an organization to recover from a successful attack on IT Systems and Services by having a solid backup and recovery concept.

In total, six completely new control questions along with new requirements to existing controls have been introduced.

Two ISA 5 controls for incident (1.6.1) and crisis (3.1.2) become obsolete and therefore no longer in ISA 6.

Recovery is necessary to limit the impact of a successful attack, regardless of whether the attack has escalated to a crisis or only affected isolated IT systems and business processes.

The post TISAX: new Catalogue ISA v6 available first appeared on Sorin Mustaca's blog.

Sorin Mustaca's blog

EU Cyber Resilience Act (CRA) – Overview

What is the Cyber Resilience Act – CRA

Timeline & Legal Effect

Key Requirements & Obligations

Why It Matters

CRA Product Classification

Criteria & Examples

Assessment & conformity requirements per class

Examples of Software Products Classification

Further reading and sources

From Idea to Proof of Concept to MVP – 3 article series

The Idea

The Proof of Concept (POC)

The Minimum Viable Product (MVP)

From Idea to Proof of Concept to MVP: The Minimum Viable Product – MVP (3/3)

3. The Minimum Viable Product (MVP)

Purpose and Scope

Inputs and Outputs

Actors

Engineering Expectations at This Stage

Code Quality and Reuse

Required Technical Changes

Process Evolution

Backend Example

Frontend Example

Security

From Idea to Proof of Concept to MVP: The POC stage (2/3)

2. The Proof of Concept (POC)

What Defines a POC

Inputs and Outputs

Actors

Engineering Expectations at This Stage

Code and Reuse

What Must Change Later

Process Evolution

Backend Example

Frontend Example

Security

From Idea to Proof of Concept to MVP: The Idea stage (1/3)

1. The Idea Stage

What Makes This Stage Unique

Inputs and Outputs

Actors

Engineering Expectations at This Stage

Code and Architecture

Process Implications

Backend Example

Frontend Example

Security and Privacy

Scrum, Kanban, and Scrumban: A Practical Comparison for Developers (Podcast)

Work in Scrum

Example

Work in Kanban

Example

Work in Scrumban

Example

Detailed Developer-Centric Changes

How Task Selection Changes

Impact on Context Switching

Handling Urgent Work

Developer Autonomy

Planning Overhead

How Your Daily Routine Might Change

Your Day in Scrum

Your Day in Kanban

Your Day in Scrumban

Which Model Fits Developers Best?

Scrum works well if:

Kanban works well if:

Scrumban works well if:

Delivering often in small increments with Scrum

Key principles and practices

Decomposition and User Stories

Time-boxed Sprints

Definition of Done (DoD)

Cross-functional Teams

Frequent Feedback Loops

Prioritization and Backlog Refinement

Challenges and Solutions