Predictions are fun, but they rarely turn out the way we expect. So, rather than speculating about what might happen, let’s examine what shaped AppSec and the Cybersecurity industry in 2025 and what is likely to keep us busy in 2026. This is my personal point of view, which is strongly influenced by my focus on application security and the associated compliance challenges.
Architecture Complexity: Cloud, APIs, LLMs and Agents
The complexity of modern application environments increased again in 2025. With cloud-native services, expanding API ecosystems and AI embedded in everything from internal tools to customer-facing systems, it has become increasingly challenging to keep pace. We try to develop a better understanding of worthwhile use cases and AI integrations while we continue to explore the ‚alien tool‘ (Andrej Karpathy) of LLM technology, still wondering whether Prompt Injection is a feature or a vulnerability. But autonomous agents and the MCP stack are already introducing additional layers of automation and security concerns. Developers, with the help of AI, are moving fast and occasionally break things. Unfortunately, security practices have not fully adapted and remain an afterthought. Efforts to retrofit ’security by design‘ into these fast-moving environments are ongoing. Managing security across multi-cloud and API-centric architectures, with the added complexity of AI, and the access to backend systems and large datasets it provides, is a significant challenge, even for well known market players. In 2026, we can expect this complexity to persist. Perhaps focusing on better visibility, not blindly trusting every new technology and improving integration and communication between architecture and security will help tackle it, until tools improve and security processes mature. Also we should not forget to keep in mind all our basic security practices (after all, AI is just software, isn’t it?) and the good guidance that is already availablefrom different sources. So what can possibly go wrong?
Regulatory pressure in the EU (CRA, NIS-2 and the AI Act)
Throughout 2025, regulatory momentum continued to build, particularly within the EU. The NIS-2 Directive, in effect since 2024, introduced stricter cybersecurity governance requirements for essential sectors finally also in Germany, while the Cyber Resilience Act (CRA) set out baseline security expectations for digital products. NIS2 targets a significant number of organizations in EU and Germany deemed relevant in terms of size or sector (plus special ‚essential‘ cases). The CRA is a product regulation that will have a severe impact on a wide range of products with digital elements on the EU market, including IoT devices, desktop and mobile apps. It will also affect open-source projects with a commercial background, although „pure“““ open-source projects remain exempt. Meanwhile, the EU AI Act, which is set to come into full effect in 2026, will impose significant obligations on providers and deployers of high-risk AI systems (and transparency obligations on others). Application and product security are central to all of these regulations. They can be used as business cases to advocate for better application security, but AppSec teams also need to take compliance with these regulations on their roadmap.
Open-source supply chain issues are nothing new, but the sophistication of the impact and maturity of the attacks are increasing. Automated, AI-driven attacks, such as Shai Hulud, provide an indication of what might be to come. By November 2025, Shai-Hulud 2.0 had compromised 796 NPM packages (with over 20 million weekly downloads) in order to steal credentials from developers and CI/CD environments. Shortly afterwards, a critical vulnerability in the React framework, dubbed ‚React2Shell‚ was exploited on a large scale by both opportunistic cybercriminals and state-linked espionage groups within days of its disclosure. Although the adoption of SBOMs and improved dependency controls has increased and tools are readily available, the overall threat level remains high. As an industry, we have started to adopt processes and tools to mitigate the increased risks, but we are far from having them under control.
Developer Velocity vs. Security Debt (or: Vibe Coding)
In 2025, AI tools are used daily by nearly 50% of developer to increase productivity (- maybe not in every scenario, and with a bit of decreasing confidence in the tools). The definition of ‚developer productivity‘ remains vague but AI now generates 41% of code or even more. Vibe coding, whereby developers use AI prompts to iterate code until something functional emerges, becomes more common. However, this workflow often prioritises functionality over security, leading to vulnerabilities or insecure defaults being introduced. The number of CVEs surpassed 48,000 in 2025, a 20% increase from the year before, indicating that software security quality remains a systemic challenge. Developers may accept code suggestions without fully understanding them, resulting in inadequate oversight of the actual functionality of the code and a ‚shaky foundations‘, as even Cursor’s CEO warned. Therefore, despite AI being deployed for vulnerability detection and automated code fixes (potentially introducing new issues), developer training and the establishment of a sustainable security culture remain essential (excluding, perhaps, phishing training). In terms of development culture, security should enable, rather than control, but it must keep up with the increased development speed through scaling, automation, and prioritization.
AI changing both attack and defense
AI continues to be integrated into security processes. Workflow automation tools are entering the security space, but AppSec SOAR and ASPM has yet to be established. AI oriented use cases such as automatic fixes for vulnerabilities, ticket enrichment and AI-supported vulnerability triage, as well as support for manual processes such as threat modelling, are continuously being explored. AI-assisted systems aim to help teams prioritize vulnerabilities based on real exploit risk, correlate code and runtime data for richer context and filter out false positives to reduce alert fatigue. However, AI assisted software vulnerability management tools that live up to the high expectations have not yet fully arrived. Automated penetration testing tools are improving, but attackers are also using AI as a weapon. More sophisticated phishing campaigns continue to erode user trust and prompt changes to IAM mechanisms (MFA, of course, and Passkeys). Threat actors have weaponized AI to scale up their campaigns, using generative AI to automate malware development, produce convincing phishing lures and generate increasingly convincing deepfake content for social engineering attacks. This ‚AI augmentation‘ of attacks enables even less-skilled adversaries to carry out sophisticated operations by letting AI handle the heavy lifting, from writing exploit code to solving problems on the fly. The time it takes attackers to exploit vulnerabilities before patches are available has shortened once again, falling into the negative at -1 day.
So, amidst all these slightly unpredictable and rapidly changing events, what’s next? I suppose, it will be a continuation and intensification of what we’ve already seen. Organizations have to manage ever-growing volumes of security-relevant data, including architectural diagrams, threat models, cloud configurations, runtime telemetry, compliance artifacts and AI outputs. At the same time, AI is beginning to actively and independently steer processes, even though we do not yet fully understand the risks involved. Opportunity lies in integrating knowledge silos more effectively to provide a clearer view and analysis of relevant risks to focus on. The common thread — and threat — is, however, complexity: in terms of technology, regulation and adversaries. We must all navigate an environment in which complex, rapidly changing architectures and technologies require constant attention. We must avoid failure while moving forward at an ever-increasing speed. Let’s work together to maintain balance and stay in control.
Der Klimawandel ist eine der größten Herausforderungen unserer Zeit und beeinflusst alle Aspekte des gesellschaftlichen und wirtschaftlichen Lebens. Um den Auswirkungen des Klimawandels gerecht zu werden und eine nachhaltige Entwicklung zu fördern, werden zunehmend Managementsysteme angepasst. Insbesondere die international anerkannten Normen ISO 9001 (Qualitätsmanagement) und ISO 27001 (Informationssicherheitsmanagement) haben begonnen, den Klimawandel in ihre Anforderungen zu integrieren. Dies spiegelt sich konkret in den Kapiteln 4.1 und 4.2 dieser Normen wider, die kürzlich überarbeitet wurden.
Die ISO 9001 und der Klimawandel
Die ISO 9001-Norm, die weltweit als Standard für Qualitätsmanagementsysteme gilt, wurde dahingehend erweitert, dass der Klimawandel und seine Auswirkungen stärker berücksichtigt werden. Die überarbeitete Fassung von Kapitel 4.1 fordert nun, dass Organisationen bei der Bestimmung ihres internen und externen Kontextes auch die Auswirkungen des Klimawandels berücksichtigen. Dies bedeutet, dass Unternehmen:
Umweltfaktoren analysieren müssen, die die Qualität ihrer Produkte und Dienstleistungen beeinflussen könnten, wie extreme Wetterereignisse oder Veränderungen der Ressourcenzugänglichkeit
Risikobewertungen hinsichtlich des Klimawandels durchführen, um mögliche Störungen in der Lieferkette oder Produktionsprozesse zu identifizieren und zu mitigieren
Strategische Maßnahmen entwickeln, um die Resilienz ihres Qualitätsmanagementsystems gegen klimabedingte Risiken zu stärken
Kapitel 4.2 wurde dahingehend angepasst, dass Organisationen nun die Erwartungen und Anforderungen ihrer interessierten Parteien im Kontext des Klimawandels berücksichtigen müssen. Dies beinhaltet:
Erwartungen von Kunden und Lieferanten hinsichtlich nachhaltiger und klimafreundlicher Produkte und Prozesse bestimmen
Regulatorische Anforderungen in Bezug auf Umwelt- und Klimaschutzmaßnahmen erfüllen
Die ISO 27001 und der Klimawandel
Auch die ISO 27001-Norm, die als Standard für Informationssicherheitsmanagementsysteme dient, wurde um Aspekte des Klimawandels erweitert. In der aktualisierten Version von Kapitel 4.1 müssen Organisationen nun auch klimabedingte Faktoren in ihren Kontextanalysen berücksichtigen. Dies bedeutet, dass:
Klimainduzierte Risiken für die Informationssicherheit, wie z.B. durch Naturkatastrophen verursachte Ausfälle von Rechenzentren oder Kommunikationsinfrastrukturen, identifiziert und bewertet werden müssen.
Maßnahmen zur Erhöhung der Resilienz gegenüber klimabedingten Bedrohungen, wie Backup-Systeme und redundante Kommunikationswege, implementiert werden sollten.
Kapitel 4.2 der ISO 27001 wurde so erweitert, dass Organisationen auch die klimabezogenen Erwartungen und Anforderungen ihrer Stakeholder berücksichtigen müssen. Dies beinhaltet:
Anforderungen von Kunden und Partnern hinsichtlich der Sicherstellung der Informationssicherheit unter klimatischen Extrembedingungen.
Regulatorische Vorgaben und Compliance-Anforderungen im Kontext von Klimarisiken und Informationssicherheit.
Erwartungen der Gesellschaft bezüglich der Nachhaltigkeit und Klimaschutzmaßnahmen von Unternehmen im Bereich der Informationssicherheit.
Fazit
Die Integration des Klimawandels in die Managementsysteme ISO 9001 und ISO 27001 stellt einen bedeutenden Schritt dar, um den Herausforderungen des Klimawandels auf organisatorischer Ebene zu begegnen. Die Anpassungen in den Kapiteln 4.1 und 4.2 dieser Normen verdeutlichen die Notwendigkeit, Klimarisiken und -chancen systematisch zu identifizieren und in die strategischen Planungen und operativen Prozesse zu integrieren. Unternehmen, die diese Anpassungen proaktiv umsetzen, positionieren sich nicht nur besser in einem sich verändernden globalen Umfeld, sondern tragen auch aktiv zu einer nachhaltigeren und widerstandsfähigeren Wirtschaft bei. Unsere Experten helfen Ihnen gerne weiter und stehen für offene Fragen jederzeit zur Verfügung. Durch unsere jahrelange Erfahrung aus verschiedenen Branchen helfen wir Ihnen nicht nur bei aktuellen Problemen, sondern sorgen für ein nachhaltig hohes Sicherheitsniveau in Ihrem Unternehmen.
In der heutigen digitalen Welt, in der Daten eine zunehmend wichtige Rolle spielen, sind Informationssicherheit und Datenschutz für Organisationen von entscheidender Bedeutung. Zwei der wichtigsten Rahmenwerke, die Organisationen dabei unterstützen, ihre Informationssicherheitspraktiken zu verbessern und das Vertrauen ihrer Kunden zu gewinnen, sind die ISO 27001 und SOC 2. Obwohl beide Rahmenwerke darauf abzielen, die Sicherheit von Informationen zu gewährleisten, unterscheiden sie sich in einigen wichtigen Aspekten. Im folgenden Artikel werden beide Standards zunächst kurz beschrieben, um im Anschluss die Gemeinsamkeiten sowie die Unterschiede darzustellen.
Die ISO 27001:2022
Ein Informationssicherheitsmanagementsystem (ISMS) trägt signifikant dazu bei, Cyberangriffe abzuwehren, und wirkt unterstützend bei der Verhinderung von Datendiebstahl. Die Norm definiert einen Rahmen für die Einrichtung, Umsetzung, Aufrechterhaltung und kontinuierliche Verbesserung eines ISMS. Mit der Zertifizierung nach ISO 27001 haben Unternehmen und Organisationen die Möglichkeit, Risiken in der Informationssicherheit zu senken und das Vertrauen ihrer Kunden sowie Stakeholder zu stärken. Im Vordergrund der ISO 27001 steht der Schutz der Vertraulichkeit sowie die Integrität und Verfügbarkeit von Informationen in Organisationen und Unternehmen.
Die ISO 27001 wurde zuletzt 2022 aktualisiert und an die aktuellen Entwicklungen der Unternehmen bezüglich Informationssicherheit angepasst. Das Grundgerüst der Norm ist die sogenannte Harmonized Structure, welche aus zehn Kapiteln besteht. Die ersten drei Kapitel führen dabei allgemein in das Thema ein und verweisen für ein besseres Verständnis auf andere Normen. Die Anforderungen in den Kapiteln vier bis zehn müssen umgesetzt werden, um die Zertifizierung zu erreichen. Darüber hinaus umfasst der Anhang der ISO 27001:2022 93 Controls, die dazu beitragen, die Informationssicherheit zu verbessern. Diese Controls sind in die folgenden vier Kategorien unterteilt:
Organisatorische Controls
Personenbezogene Controls
Physische Controls
Technologische Controls
SOC 2
SOC 2 (Service Organization Control 2) ist ein Prüfungsstandard, welcher von der American Institute of Certified Public Accountants (AICPA) entwickelt wurde. Dieser basiert auf einer Reihe von Prinzipien, die als Trust Service Criteria (TSC) bezeichnet werden. Diese Prinzipien dienen als Grundlage für die Prüfung und Bewertung von Dienstleistern. Die fünf TSC umfassen die Sicherheit, die Verfügbarkeit, die Verarbeitungsintegrität, die Vertraulichkeit sowie die Datenschutzaspekte von Dienstleistungen in einer Cloud. Damit Unternehmen die Einhaltung der TSC nachweisen können, muss eine umfassende Prüfung durch einen unabhängigen Wirtschaftsprüfer durchgeführt werden. Der SOC 2-Bericht, der aus dieser Prüfung resultiert, enthält typischerweise:
Eine Beschreibung des Dienstleisters und des Umfangs der geprüften Services
Eine Erklärung zur Einhaltung der TSC und der zugrunde liegenden Kontrollen
Eine Bewertung der Wirksamkeit der implementierten Kontrollen
Empfehlungen zur Verbesserung der Sicherheits- und Compliancemaßnahmen
Diese Prüfungsnorm ist besonders relevant für Technologieunternehmen und Dienstleister, die Services anbieten, bei denen Datenschutz und Datensicherheit von entscheidender Bedeutung sind.
Gemeinsamkeiten
Fokus auf Informationssicherheit: Sowohl die ISO 27001 als auch SOC 2 konzentrieren sich darauf, die Sicherheit von Informationen zu gewährleisten, einschließlich Vertraulichkeit, Integrität und Verfügbarkeit. Risikomanagement: Beide Rahmenwerke verwenden einen risikobasierten Ansatz, bei dem Organisationen Risiken identifizieren, bewerten und behandeln, um ihre Informationssicherheitsziele zu erreichen. Kontinuierliche Verbesserung: Die ISO 27001 und SOC 2 legen Wert auf eine kontinuierliche Verbesserung. Organisationen müssen ihre Sicherheitspraktiken regelmäßig überprüfen und aktualisieren, um mit den sich ständig verändernden Bedrohungen und Anforderungen Schritt zu halten. Transparenz und Vertrauen: Beide Rahmenwerke bieten Organisationen die Möglichkeit, ihren Kunden und anderen Stakeholdern Transparenz und Vertrauen in ihre Informationssicherheitspraktiken zu vermitteln, indem sie sich Zertifizierungen oder Prüfberichte vorlegen lassen.
Unterschiede
Nachweis: Ein wesentlicher Unterschied zwischen ISO 27001 und SOC 2 liegt in der Art der Bewertung. ISO 27001 ist eine Zertifizierungsnorm, bei der Organisationen eine formelle Zertifizierung erhalten können, wenn sie die Anforderungen der Norm erfüllen. SOC 2 hingegen ist ein Rahmenwerk, das auf Prinzipien basiert, die von einem unabhängigen Prüfer bewertet werden. Organisationen erhalten keinen offiziellen „SOC 2-Zertifizierungsstatus“, sondern einen Prüfbericht, der ihre Einhaltung der Prinzipien bestätigt. Zielgruppe: Die ISO 27001 richtet sich an Organisationen jeder Größe, Branche und Art, die ihre Informationssicherheitspraktiken verbessern möchten. SOC 2 ist speziell auf Technologieunternehmen und Dienstleister ausgerichtet, die Services erbringen, bei denen Datenschutz und Datensicherheit von entscheidender Bedeutung sind. Markt: In Ländern wie den USA, Kanada und Großbritannien, in denen Technologieunternehmen und Cloud-Dienste eine bedeutende Rolle spielen, ist die Nachfrage nach SOC 2-Zertifizierung tendenziell höher. Dies liegt daran, dass SOC 2 speziell auf Dienstleister in der Technologiebranche ausgerichtet ist und die Sicherheit von Kundendaten in Cloud- und IT-Diensten betont. In vielen europäischen Ländern, einschließlich Deutschland, Schweiz und Skandinavien, wird häufiger nach ISO 27001 zertifiziert. Dies liegt teilweise daran, dass ISO 27001 ein international anerkannter Standard ist und von vielen Organisationen als grundlegendes Element ihres Informationssicherheitsmanagements betrachtet wird. Darüber hinaus sind die Datenschutzanforderungen in Europa oft strenger, was die ISO 27001-Zertifizierung als Mittel zur Demonstration der Einhaltung dieser Anforderungen attraktiv macht. Umfang: Die ISO 27001 ist weitreichender und umfasst alle Aspekte des Informationssicherheitsmanagements, einschließlich physischer Sicherheit, Personalmanagement und Compliance. SOC 2 konzentriert sich speziell auf Sicherheits-, Verfügbarkeits-, Integritäts-, Vertraulichkeits- sowie Datenschutzaspekte, die im Zusammenhang mit den Systemen und Dienstleistungen eines Unternehmens stehen. Anforderungen: Die Anforderungen der beiden Rahmenwerke unterscheiden sich in ihrer Spezifität und Tiefe. Die ISO 27001 ist bekannt für ihre allgemeinen Anforderungen, die Organisationen dennoch flexibel an ihre individuellen Bedürfnisse anpassen können. SOC 2 hingegen definiert spezifische Prinzipien und Kriterien, die Organisationen erfüllen müssen, um die Bewertung erfolgreich zu bestehen.
Fazit
Zusammenfassend sind sowohl die ISO 27001:2022 als auch SOC 2 wertvolle Rahmenwerke für Unternehmen, um ihre Informationssicherheitspraktiken zu verbessern und das Vertrauen ihrer Kunden zu stärken. Die Wahl zwischen beiden Standards hängt von den spezifischen Anforderungen, Zielen und der Branche einer Organisation ab. Einige Unternehmen können sich dafür entscheiden beide Rahmenwerke zu implementieren, um eine umfassende Sicherheitsstrategie zu gewährleisten. Unsere Experten helfen Ihnen gerne weiter und stehen für offene Fragen jederzeit zur Verfügung. Durch unsere jahrelange Erfahrung in verschiedenen Branchen helfen wir Ihnen nicht nur bei aktuellen Problemen, sondern sorgen für ein nachhaltig hohes Sicherheitsniveau in Ihrem Unternehmen.
Die Europäische Union hat eine überarbeitete Version ihrer Richtlinie zur Netz- und Informationssicherheit (NIS-2) verabschiedet, die Unternehmen dazu verpflichtet, ihre digitalen Systeme und Dienste besser zu schützen. Der deutsche Gesetzgeber muss daher bis zum 17. Oktober 2024 diese Richtlinie in den deutschen Rechtsrahmen einbinden. Aufgrund zunehmender Cyberbedrohungen und dem stetig wachsenden Risiko von Cyberangriffen auf kritische Infrastrukturen ist diese Aktualisierung notwendig. Im Folgenden werden die wichtigsten Anforderungen der NIS-2 Richtlinie erläutert. Im Anschluss wird dargestellt, welche Maßnahmen die betroffenen Unternehmen umsetzen müssen.
Die NIS-2-Richtlinie
Die NIS-2-Richtlinie erweitert den Anwendungsbereich auf eine Vielzahl unterschiedlicher Unternehmen und Dienstleistungsanbietern. Sowohl Unternehmen im Bereich der kritischen Infrastrukturen als auch digitale Dienstleister wie Cloud-Computing-Anbieter fallen unter diese Richtlinie. Die folgenden 18 verschiedenen Industrie- und Dienstleistungssektoren fallen in den Geltungsbereich, sofern sie mehr als 50 Mitarbeiter haben und einen Jahresumsatz von mindestens 10 Mio. € erwirtschaften:
Unternehmen, die gegen die Bestimmungen von NIS-2 verstoßen, können mit finanziellen Sanktionen belegt werden. Es ist daher entscheidend, dass Unternehmen die Anforderungen der Richtlinie ernst nehmen und angemessene Maßnahmen ergreifen, um die Sicherheit ihrer digitalen Infrastruktur zu gewährleisten.
Anforderungen an Betreiber kritischer Infrastrukturen
Betreiber kritischer Infrastrukturen müssen eine Reihe von Sicherheitsanforderungen erfüllen, um ein hohes Sicherheitsniveau zu erreichen. Die genauen Anforderungen können je nach nationaler Umsetzung der Richtlinie und der Art des Unternehmens variieren. Die folgenden Anforderungen sind jedoch unerlässlich und es wird Zeit brauchen, diese umzusetzen. Zu beachten ist hierbei die begrenzte Anzahl an Know-how Trägern, wodurch es besonders im dritten und vierten Quartal 2024 zu Engpässen kommen kann. Wer später nicht in Zeitdruck geraten möchte, nimmt die folgenden Themen besser schon heute auf die Agenda. Im ersten Schritt sollten betroffene Unternehmen ihre aktuellen Sicherheitsmaßnahmen und -richtlinien überprüfen, um sicherzustellen, dass sie den Anforderungen von NIS-2 entsprechen. Gegebenenfalls müssen die Prozesse aktualisiert oder erweitert werden, um den neuen Anforderungen gerecht zu werden. Im nächsten Schritt ist es unerlässlich eine Risikobewertung durchzuführen, denn diese identifiziert die Schwachstellen in den digitalen Systemen und Diensten eines Unternehmens. Basierend auf der Risikobewertung können geeignete Sicherheitsmaßnahmen entwickelt und implementiert werden. Eine Besonderheit bei NIS-2 ist, dass Geschäftsführer bzw. Vorstände die Umsetzung überwachen müssen und für eventuelle Verstöße des Unternehmens nach nationalem Recht haftbar gemacht werden können. Neben den Anforderungen an die Cybersecurity Governance, ist die Prävention ein ebenfalls entscheidender Faktor. Hierbei müssen Unternehmen angemessene technische und organisatorische Maßnahmen (TOM) nach dem “Stand der Technik” ergreifen, um die Sicherheit ihrer Netz- und Informationssysteme zu gewährleisten. Die Unternehmen können zur Orientierung beispielsweise auf die ISO 27001:2022 zurückgreifen. Die Anforderungen an das Business Continuity Management (BCM) sind in NIS-2 konkret beschrieben. Für ein konformes BCM sind Maßnahmen zur Aufrechterhaltung des Geschäftsbetriebs notwendig, wozu beispielsweise das Backup-Management, das Krisenmanagement oder das Recoverymanagement gehören. Darüber hinaus ist die Sicherheit in den Lieferketten zu gewährleisten. Dies bedeutet, dass sowohl die Netz- und Informationssicherheitssysteme als auch deren physische Umwelt zu berücksichtigen sind. Zu beachten sind die hieraus entstehenden Folgen für Unternehmen, die lediglich als Lieferanten tätig sind, also nicht direkt der Regulierung unterliegen. Die Folge für beispielsweise IT-Dienstleister und andere Zulieferer ist, dass sie Lieferantenaudits unterzogen werden, in denen die Robustheit ihrer Informationstechnik geprüft wird. Ebenfalls unerlässlich ist ein klar definierter Incident Response Plan, um im Falle eines Sicherheitsvorfalls schnell und angemessen reagieren zu können. Unternehmen sollten sicherstellen, dass alle relevanten Mitarbeiter mit dem Plan vertraut sind und regelmäßige Übungen durchführen, um die Wirksamkeit des Plans zu testen. Hinzu kommt, dass Unternehmen dazu verpflichtet sind, ernsthafte Sicherheitsvorfälle den nationalen Behörden zu melden. Dies umfasst nicht nur tatsächliche Angriffe, sondern auch Versuche von Cyberangriffen oder andere sicherheitsrelevante Ereignisse, die Auswirkungen auf ihre Dienste haben könnten. Eine Frühwarnung muss binnen 24 Stunden und die tatsächliche Meldung des Sicherheitsvorfalls spätestens innerhalb von 72 Stunden an die zuständigen Behörden übermittelt werden. Als „erheblich“ wird ein Sicherheitsvorfall eingestuft, wenn er zu schwerwiegenden Betriebsstörungen der Dienste oder zu finanziellen Verlusten für die betroffene Einrichtung führt oder führen kann. Gleiches gilt, wenn eine natürliche oder juristische Person durch einen solchen Vorfall erheblichen materiellen oder immateriellen Schaden erfährt oder erfahren könnte.
Fazit
Insgesamt erfordert die Umsetzung der NIS-2-Richtlinie ein proaktives und ganzheitliches Herangehen an das Thema Cybersicherheit. Unternehmen, die die Anforderungen der Richtlinie erfüllen und ihre digitalen Systeme und Dienste effektiv schützen, können nicht nur das Vertrauen ihrer Kunden stärken, sondern auch das Risiko von schwerwiegenden Cyberangriffen minimieren. Unternehmen, welche sich bereits mit dem IT-Sicherheitsgesetz 2.0 auseinandergesetzt haben, werden in den Anforderungen aus NIS 2 wenig neues entdecken. Die nicht unerhebliche Ausweitung des Anwendungsbereichs wird jedoch dazu führen, dass viele Unternehmen, die bisher nicht betroffen waren, sich frühzeitig mit der Umsetzung der geforderten Maßnahmen auseinandersetzen müssen. Für ein besseres Verständnis der Richtlinie und deren Umsetzung bietet sich eine externe Beratung an. Diese unterstützt Sie bei der Umsetzung der geforderten Maßnahmen und hilft der Geschäftsführung die Haftungsrisiken zu minimieren. Unsere Experten helfen Ihnen gerne weiter und stehen für offene Fragen jederzeit zur Verfügung. Durch unsere jahrelange Erfahrung aus verschiedenen Branchen helfen wir Ihnen nicht nur bei aktuellen Problemen, sondern sorgen für ein nachhaltig hohes Sicherheitsniveau in Ihrem Unternehmen.
A good security team is implicitly present in a multitude of aspects in an organization and its culture. However, often we see security teams proposing security requirements without taking care or even encouraging proper implementation of the proposed security concepts and requirements. But if security teams consider themselves as a mere function that is just setting the guardrails without business or users in mind, they will be reduced to that and will have no long-lasting effect on the overall security of an organization.
In traditional organizations, security teams often start with compliance, mainly defining standards, policies, and processes and expecting everyone to adhere to those. In smaller organizations, security activities might start on a technical level, trying to follow general best practices and avoiding issues in operation (incidents) that might result from a lack of secure configuration. In both cases, teams usually lack the perception of end-users who do not understand security well. Therefore security teams do not see the need to guide employees through a proper implementation and adoption of the proposed security best practices and requirements – leading to either frustration or ignorance on the part of the users. This neglect is to a degree understandable – a security specialist or sysadmin is not a project manager, nor can they be put in a spot where they must shoulder all the security responsibility for everyone else. In addition, the role of a security function can be severely limited by the amount of how much a business is willing to spend for its security capabilities. However, a security team not driving any projects and not feeling responsible for the actual state of security in an organization across all layers will likely fail in creating anything more than security on paper.
To form a successful security team, it is important to understand that security is more than a function. It is a living organism; it is water; it is a meme – it is whatever creeps into and influences every process, every design, every product of the organization increasing its resiliency in the best case – and what stays a bunch of documents no one wants to read and cumbersome processes no one wants to follow in the worst case.
Luckily, in recent years, certain areas of security – and especially product security – have transformed from a compliance role into an enabler role. The necessity of connecting security activities to business goals and thinking about user adoption has become more important. Their mission: Enable business to make business, to stay afloat by preventing hacks and incidents, and help product teams to deliver secure by default products with a reasonable effort which their users can use without getting frustrated by security processes. A good security team will look for ways to optimize processes and achieve security and compliance without spending endless time and resources on it. One key sentence formulated in CISA’s “Security by Design” principles is that (software) manufacturers should take responsibility for customer security outcomes. This, we believe, is the key sentence for a successful product security program and potentially even for a whole enterprise security program in general. What it means is simple: Feel responsible for implementation and not just formulation or configuration of good security practice. Feel responsible for the outcome – that includes bad user passwords, insecure authentication choices, careless sharing of profile information, post-it notes with passwords on the computer screen, etc. Take ownership of these issues and consider and prevent them before they happen. The work of a good security team may start with the decision on adequate security controls, followed by implementation or configuration, but it does not end there. A security team needs to ensure the user is made aware of the implications of their security-related decisions, grasp the reasons why security processes benefit the company, and encourage decisions that will protect the user – internal or external – of a company’s products and services.
If we widen the perception of “user” a bit, we can take the sentence from the CISA paper as a key attitude also toward an organization’s employees: A security team should feel responsible for the phishing rates, for the hardcoded passwords, and that users might avoid your security tools because they are so difficult to use and no one ever cared to do a proper rollout or onboarding. If people don’t talk to you about security concerns because they are afraid you will cause them more work without resolving their concern, you are ultimately failing as a security team.
In the same way that product security is moving to an enabling culture and the clear understanding of shared responsibility, traditional enterprise security needs to move to care about implementation and culture. It is no secret that there usually is a big compliance gap: A company has their ISO 27001 / TISAX / NIST, etc., audit done, but the experts inside know that the technical security level is still lacking, and good security practices are limited to a small scope of the systems and processes. Documents and process definitions exist but they are not followed, and if they are followed, their outcome does not really contribute to a better security posture of the enterprise. This is what we see as the most dangerous form of a compliance gap: Not the gap between documents that an auditor requires and which a company might or might not have, but the gap that exists between the compliance stated on paper and the actual security of a company’s systems and processes. This is the gap that matters when you are talking about security and this gap might not even be properly reflected in your risk management activities, which are usually based on paper and checklists as well. And ultimately, this is a dangerous gap between a security team and its users. The paper is just a transport mechanism. If the ideas and concepts formulated in the security team fail to reach the company’s workforce, then there is no communication, and no actual security improvement will be achieved.
Coming back to the title of this paper, the Doorman Fallacy. The Doorman Fallacy, as mentioned by Rory Sutherland, is this:
Business, technology and, to a great extent, government have spent the last several decades engaged in an unrelenting quest for measurable gains in efficiency. However, what they have never asked, is whether people like efficiency as much as economic theory believes they do.
The ‘doorman fallacy’, as I call it, is what happens when your strategy becomes synonymous with cost-saving and efficiency; first you define a hotel doorman’s role as ‘opening the door’, then you replace his role with an automatic door-opening mechanism.
The problem arises because opening the door is only the notional role of a doorman; his other, less definable sources of value lie in a multiplicity of other functions, in addition to door-opening: taxi-hailing, security, vagrant discouragement, customer recognition, as well as in signalling the status of the hotel. The doorman may actually increase what you can charge for a night’s stay in your hotel.
Alchemy: The Dark Art and Curious Science of Creating Magic in Brands, Business and Life, Rory Sutherland, p. 126 f.
The Doorman fallacy is not only relevant from a business perspective (e.g. a company investing in tools to save costs on it’s security team); it is also relevant from a security team’s perspective. A good security team is like the doorman in a hotel: They guard people on their journey to use the hotel’s services. They recognize customer needs, are helpful, provide useful guidance and pathways. They need to be concerned about the end-to-end service the Hotel provides. Their notional function might be to take care of systems, policies, or standards or do proper system configuration. But if they stop there, they are not only missing out on opportunities to show the value of their work but run into the danger that they will never have a real impact on the security of their organization. Taking care of the end-to-end process, security can become a business advantage instead of a mere cost driver. If a security team and the organization start to understand that the security team’s work is not only about formulating requirements, documenting and following processes, but that they are part of a business context and that their users matter – then we will see significant improvements in the security of an organization, the breaking of “security silos” and the start of a real security culture with security as a doorman and its own, valuable contributions to the business.
Wie bereits im ersten Teil erläutert werden durch den neuen Aufbau der Controls die Attribute stärker spezifiziert und die Notwendigkeit stärker hervorgehoben. Des Weiteren wurden die neuen organisatorischen sowie physischen Controls erläutert. Der zweite Teil befasst sich mit den neuen technologischen Controls.
8.9 Konfigurationsmanagement
Das Control Konfigurationsmanagement fordert, dass die Unternehmen den gesamten Zyklus der Sicherheitskonfiguration für die Technologie der Organisation verwaltet, um ein angemessenes Sicherheitsniveau zu gewährleisten und unautorisierte Änderungen zu vermeiden. Dies beinhaltet die Definition, Implementierung, Überwachung und Überprüfung der Konfiguration. Neben der Richtlinie für das Konfigurationsmanagement soll zusätzlich ein Prozess für die Überprüfung sowie die Genehmigung von Sicherheitskonfigurationen und Prozessen erstellt werden.
8.10 Löschung von Informationen
Dieses Control beinhaltet die Anforderungen zur Datenspeicherung im Hinblick auf DSGVO. Darüber hinaus sollen Informationen, die in Informationssystemen, Geräten oder auf anderen Speichermedien gespeichert sind, gelöscht werden, sobald diese nicht mehr benötigt werden. Daher sollen die Unternehmen einen Prozess einrichten, der zum einen festlegt, welche Daten zu welchem Zeitpunkt gelöscht werden müssen, und zum anderen die Verantwortlichkeiten und Methoden für die Löschung definiert. Zudem sollte eine Richtlinie zur Informationsvernichtung erstellt und innerhalb des Unternehmens kommuniziert werden.
8.11 Datenmaskierung
Bei der Datenmaskierung geht es zusammengefasst um die Beschränkung, Anonymisierung sowie Pseudonymisierung von Daten. Das Control verlangt von den Unternehmen mit Hilfe der Datenmaskierung die Offenlegung sensibler Informationen zu begrenzen. Damit sind in erster Linie personenbezogene Daten gemeint, da diese durch Datenschutzbestimmungen stark reguliert werden. Zusätzlich können auch andere Kategorien sensibler Daten einbezogen werden. Die Datenmaskierung sollte in Übereinstimmung mit der themenspezifischen Richtlinie der Organisation zur Zugriffskontrolle sowie den geschäftlichen Anforderungen unter Berücksichtigung der geltenden Rechtsvorschriften erfolgen.
Die Erstellung einer Informationsschutzpolitik ist zwar nach der Norm optional, allerdings sollen durch das Unternehmen Prozesse eingerichtet werden, die festlegen, welche Daten maskiert werden müssen, wer auf welche Art von Daten zugreifen darf und welche Methoden zur Maskierung der Daten verwendet werden.
8.12 Verhinderung von Datenverlusten
Hierbei wird von den Unternehmen verlangt, dass verschiedene Maßnahmen festgelegt werden, die Datenlecks verhindern sollen, um die unbefugte Offenlegung sensibler Informationen zu verhindern. Zusätzlich sollen durch diese Sicherheitsmaßnahmen solche Vorfälle frühzeitig erkannt werden. Die Maßnahmen sollen auf Systeme, Netzwerke und alle anderen Geräte angewendet werden, die sensible Informationen verarbeiten, speichern oder übertragen.
In der Umsetzung bedeutet dies für die Unternehmen, dass Prozesse eingerichtet werden müssen, die die Sensibilität der Daten bestimmen, die Risiken verschiedener Technologien bewerten und Kanäle mit dem Potenzial für Datenlecks überwachen und festlegen. Ziel der Prozesse soll es sein die Offenlegung sensibler Daten zu verhindern. Eine zusätzliche Informationsschutzpolitik ist für dieses Control nicht zwingend erforderlich.
8.16 Überwachungstätigkeiten
Dieses Control verlangt, die Systeme des Unternehmens sowie abweichende Aktivitäten proaktiv zu überwachen, um diese frühzeitig zu erkennen und gegebenenfalls entsprechend auf den Vorfall zu reagieren. Durch die geeigneten Maßnahmen sollen potenzielle Informationssicherheitsvorfälle besser erkannt und bewertet werden.
Für eine konforme Dokumentation ist eine Protokollierungs- und Überwachungsrichtlinie notwendig. Zudem ist ein Prozess erforderlich, der festlegt welche Systeme überwacht werden und wer für die Überwachung Zuständig ist. Des Weiteren müssen Methoden für die Überwachung, die Erstellung sowie die Meldung von Ereignissen und Vorfällen bestimmt werden.
8.23 Web-Filterung
In diesem Control sollen Maßnahme festgelegt werden, die den Zugriff zu gefährlichen Webseiten verhindern, die Malware verbreiten oder aber unbefugt Daten auslesen. Daher muss das Unternehmen die Zugriffsrechte der Mitarbeiter verwalten, um die Systeme und Vermögenswerte zu schützen. Auf diese Weise kann verhindert werden, dass die Systeme kompromittiert und Illegale Inhalte aus dem Internet verwendet werden.
Die Erstellung einer Netzwerksicherheitspolitik ist dem Unternehmen selbst überlassen. Dennoch sollen Prozesse eingerichtet werden, welche die nicht erlaubten Webseiten sowie die notwendigen Web-Filter-Tools, inklusive des Überprüfungszeitraums, bestimmen.
8.28 Sichere Kodierung
Bei der Softwareentwicklung sollten die Grundsätze der sicheren Kodierung angewandt werden, um Sicherheitsschwachstellen in der Software zu verringern. Dies umfasst sowohl die Aktivitäten vor der Kodierung als auch während und danach.
Hierfür ist auch eine Richtlinie für die sichere Entwicklung und die sichere Kodierung notwendig. Zudem muss ein Prozess zur Definition der Mindestanforderungen an die sichere Kodierung eingerichtet werden, welcher sowohl für die interne als auch die externe Softwareentwicklung gilt. Darüber hinaus müssen Verfahren zur Überwachung neu auftretender Bedrohungen, zur Beratung über sichere Kodierung und zur Entscheidung über die verwendeten externen Tools und Bibliotheken festgelegt werden.
Fazit
Abschließend muss berücksichtigt werden, dass lediglich vier Controls inhaltlich komplett identisch geblieben sind. Dies hat zur Folge, dass es nicht ausreicht die neuen Controls in das Risikomanagement und die SoA (Statement of Applicability) einzupflegen sowie zu bewerten. Die Anforderungen bei bestehenden oder zusammengefassten Controls wurden zum einen spezifiziert und zum anderen hinzugefügt. Daraus resultierend stehen Unternehmen vor der großen Herausforderung über 800 neue oder geänderte Anforderungen umzusetzen. Darüber hinaus ist zu beachten, dass die tatsächlichen Auswirkungen der Revision auf Unternehmen von verschiedenen Faktoren abhängig sind. Daher wird empfohlen, sich mit einem Experten für Informationssicherheit Verbindung zu setzen, um die genauen Auswirkungen der ISO 27001:2022 auf Ihr Unternehmen zu ermitteln und geeignete Maßnahmen umzusetzen.
