Risikobasierte App-Kategorien: Prototypen, interne Tools und externe Produkte
Stellen Sie sich vor, Sie haben 50 Anwendungen in Ihrem Unternehmen. Eine davon ist ein Prototyp, den ein Entwickler in zwei Tagen gebaut hat, um eine Idee zu testen. Eine andere ist ein internes Tool, das die Buchhaltung automatisiert. Und eine dritte ist Ihre Kunden-App, die täglich Tausende von Zahlungen verarbeitet. Alle drei laufen auf denselben Servern. Aber wenn etwas schiefgeht, wie viel Aufwand sollten Sie in jede investieren? Die Antwort ist nicht gleich. Und genau hier kommt die risikobasierte Kategorisierung ins Spiel.
Warum nicht alle Apps gleich behandeln?
Viele Unternehmen behandeln alle Anwendungen gleich - egal, ob sie nur für zwei Mitarbeiter gedacht sind oder von Millionen Kunden genutzt werden. Das ist wie ein Sicherheitsnetz zu haben, das genauso dick ist wie ein Seil, das einen Lastwagen hält. Es kostet viel Geld, ist überflüssig bei manchen und reicht bei anderen nicht aus. Die risikobasierte Kategorisierung sagt: Investieren Sie dort, wo es wirklich zählt. Sie teilt Apps in drei Gruppen ein: Prototypen, interne Tools und externe Produkte. Jede hat ein anderes Risikoprofil. Und je höher das Risiko, desto mehr Ressourcen - Security-Checks, Tests, Monitoring - bekommen sie. Laut dem Wiz.io-Bericht 2024 bekommen externe Produkte 65 bis 80 % aller Sicherheitsressourcen - obwohl sie nur 15 bis 25 % der gesamten App-Landschaft ausmachen. Warum? Weil sie öffentlich zugänglich sind, mit sensiblen Daten arbeiten und bei Ausfall sofort Geld verlieren. Ein Prototyp? Der kann ein paar Tage offline sein. Kein Problem.Wie wird ein Risiko gemessen?
Es geht nicht um Bauchgefühl. Es geht um klare Kriterien. Drei Dimensionen bestimmen das Risiko:- Exposition: Wie viele Nutzer haben Zugriff? Prototypen: unter 10. Interne Tools: 10 bis 500. Externe Produkte: Tausende - oft ohne Anmeldung.
- Datensensitivität: Welche Daten verarbeitet die App? Nach NIST SP 800-53: Niedrig (Prototypen), Mittel (interne Tools), Hoch (externe Produkte). Ein Tool, das Gehaltsdaten speichert, ist kein Prototyp - egal, wie klein es ist.
- Unternehmenskritikalität: Wie lange darf die App ausfallen? Prototypen: beliebig. Interne Tools: 4 bis 24 Stunden. Externe Produkte: unter 4 Stunden - sonst verlieren Sie Kunden und Geld.
Was passiert, wenn ein Prototyp zur Produkt-App wird?
Das ist der größte Fehler, den Unternehmen machen. Ein Entwickler baut ein Tool, um die Lieferzeit von Bestellungen zu testen. Es läuft auf einem Testserver. Kein Passwortschutz. Keine Logging. Keine Firewall-Regeln. Alles klar - es ist nur ein Prototyp. Zwei Wochen später ist es live. Die Verkaufsabteilung will es nutzen. Der Support ruft an: „Warum kann ich nicht bezahlen?“ Jetzt ist es kein Prototyp mehr. Es ist eine kritische Anwendung. Und es hat 14 kritische Sicherheitslücken. Keiner hat sie gesehen. Weil niemand dachte, dass es wichtig ist. Laut Apiiro’s 2024-Umfrage waren 63 % aller Sicherheitsvorfälle auf solche falschen Klassifizierungen zurückzuführen. Und in Startups verursachten solche Übergänge 17,3 % aller Sicherheitsvorfälle - laut dem SaaS Security Incident Report 2024. Ein echter Fall von Reddit: Ein Salesforce-Integrationstool, das als „internes Tool“ eingestuft war, hatte Admin-Rechte. Es wurde gehackt. 2,1 Millionen Dollar verloren. 87 % der 142 Antwortenden auf dem Thread sagten: „Das ist bei uns auch passiert.“Warum reicht statische Klassifizierung nicht mehr
Das alte Modell - Prototyp, intern, extern - ist zu einfach geworden. Heute arbeiten Apps in Microservices, Containern, APIs. Ein einzelnes Tool besteht aus 20 kleinen Diensten. Welcher davon ist „extern“? Welcher „intern“? Der, der die Zahlung verarbeitet? Oder der, der den Benutzernamen speichert? Beide sind wichtig. Aber nur einer ist öffentlich. Und dann gibt es die Lieferkette. Dr. Jane Kim, ehemalige CISO von Microsoft, sagte es klar: „Ein niedrigriskantes internes Tool kann eine kompromittierte Bibliothek nutzen - und damit eine externe App angreifen.“ Das ist kein Theorie. Das war der XZ Utils-Backdoor-Vorfall 2024, der über 300 Millionen Systeme traf. Gartner sagt: 78 % der Unternehmen mit statischer Klassifizierung haben kritische Schwachstellen in internen Tools übersehen - die später als Sprungbrett gegen externe Produkte genutzt wurden. Die Lösung? Dynamische Risikobewertung. Nicht einmal pro Jahr. Nicht einmal pro Quartal. In Echtzeit. Palo Alto Networks hat im Januar 2025 eine neue Funktion in Cortex XDR veröffentlicht: Die App-Kategorie ändert sich automatisch, wenn sich das Nutzerverhalten ändert. Wenn ein Prototyp plötzlich 1.000 Nutzer pro Tag hat - wird es automatisch als „extern“ eingestuft. Kein Mensch muss es manuell ändern. Und das reduziert Fehlklassifizierungen um 67 %.
Wie fängt man an?
Sie brauchen keine teure Software, um anzufangen. Aber Sie brauchen klare Regeln.- Erstellen Sie eine Risikomatrix: Farben helfen. Grün für Prototypen, Gelb für interne Tools, Rot für externe Produkte.
- Definieren Sie Kriterien: Wer entscheidet, ob eine App „extern“ ist? Ein Sicherheitsteam? Ein Architekt? Wer trägt die Verantwortung?
- Verknüpfen Sie mit Tools: Nutzen Sie AWS Config oder Lumigo, um automatisch alle Apps zu entdecken. Nutzen Sie BigID oder Varonis, um Datenklassifizierung zu automatisieren.
- Integrieren Sie in CI/CD: SAST-Tools wie Checkmarx oder Snyk müssen bei jedem Build prüfen - aber nur nach den Regeln Ihrer Kategorie. Ein Prototyp braucht keine Penetrationstests. Ein externes Produkt braucht sie.
Was kostet das?
Die Kosten sind nicht in der Software. Die Kosten sind in der Unklarheit. Ein externes Produkt mit voller OWASP-Konformität kostet etwa 40.000 bis 80.000 US-Dollar pro Jahr an Sicherheitsressourcen. Ein internes Tool: 5.000 bis 12.000. Ein Prototyp: 800 bis 1.500. Wenn Sie alle gleich behandeln - zahlen Sie 40.000 für jeden. Das sind 1,6 Millionen Dollar pro Jahr für 40 Apps. Mit risikobasierter Kategorisierung: 600.000. Das ist eine Einsparung von 1 Million Dollar. Und gleichzeitig sind Sie sicherer. Die globale Marktgröße für Anwendungssicherheitsmanagement liegt 2024 bei 12,3 Milliarden US-Dollar - und wächst um 18,7 % pro Jahr. 68 % der Unternehmen nutzen bereits risikobasierte Kategorisierung. Bei kleinen Unternehmen ist es noch selten - 29 % - weil sie denken, es sei zu komplex. Aber das ist der falsche Blickwinkel. Es ist nicht komplex. Es ist einfach: Machen Sie es nicht schwerer, als es ist.Regulierung zwingt zum Handeln
Die SEC hat 2024 neue Regeln für Cybersecurity-Disclosures eingeführt. Unternehmen müssen jetzt genau sagen, wie sie Risiken steuern. Die EU-Cyber Resilience Act (CRA) ab Oktober 2024 verlangt: „Sicherheitsmaßnahmen müssen proportional zur Exposition der Anwendung sein.“ Das heißt: Wenn Sie keine risikobasierte Kategorisierung haben, erfüllen Sie die Gesetze nicht. Das ist kein Vorschlag. Das ist Pflicht. NIST CSF 2.0 (Februar 2024) und die FFIEC-Richtlinien für Banken (2024) fordern dasselbe. In der Gesundheitsbranche muss nach HIPAA jeder Zugriff auf Patientendaten kontrolliert werden - egal, ob die App intern oder extern ist. Aber die Risikostufe ändert sich.
Was kommt als Nächstes?
Die Zukunft ist nicht mehr statisch. Sie ist adaptiv. OWASP arbeitet an „Context-Aware Risk Scoring“ - ein System, das nicht nur die App, sondern auch die Umgebung, die verwendeten Bibliotheken, die aktuelle Bedrohungslage und die Nutzeraktivität berücksichtigt. Und die NTIA plant ab 2025, dass jede Software-Bill-of-Materials (SBOM) - also die Liste aller verwendeten Komponenten - auch eine Risikokategorie enthalten muss. Für alle Bundesaufträge in den USA. Das bedeutet: In zwei Jahren wird es kein Unternehmen mehr geben, das sagt: „Wir haben das nicht gemacht.“ Weil es nicht mehr optional ist.Was tun Sie jetzt?
1. Listen Sie alle Ihre Anwendungen auf. Nicht nur die, die Sie kennen. Sondern alle. Nutzen Sie Ihre Cloud-Tools, um automatisch alle laufenden Dienste zu finden. 2. Wenden Sie die drei Kriterien an. Exposition. Daten. Kritikalität. Geben Sie jeder App einen Risikowert - 1 bis 10. 3. Ordnen Sie sie ein. Prototyp (1-3), intern (4-6), extern (7-10). 4. Definieren Sie, was für jede Kategorie nötig ist. Welche Tests? Welche Scans? Welche Monitoring-Regeln? Schreiben Sie es auf. Teilen Sie es mit dem Team. 5. Setzen Sie einen Monitor ein. Wie oft wird eine App genutzt? Hat sie neue Daten bekommen? Hat sie neue Nutzer? Wenn ja - prüfen Sie, ob die Kategorie noch stimmt. Einmal pro Woche. Oder automatisch mit einem Tool. Sie brauchen keine perfekte Lösung. Sie brauchen eine, die funktioniert. Und die Sie nicht ignorieren.Frequently Asked Questions
Was ist der Unterschied zwischen einem Prototyp und einem internen Tool?
Ein Prototyp ist eine experimentelle Anwendung, die nur für die Ideenprüfung gedacht ist - meist mit weniger als 10 Nutzern, ohne Authentifizierung und mit nicht-sensiblen Daten. Ein internes Tool wird von Mitarbeitern regelmäßig genutzt, hat Zugriff auf sensible Daten wie Gehalts- oder Kundendaten und muss innerhalb von 24 Stunden wiederhergestellt werden können. Der Unterschied liegt nicht in der Größe, sondern in der Nutzung, den Daten und den Auswirkungen bei Ausfall.
Warum brauchen externe Produkte mehr Sicherheit als interne Tools?
Externe Produkte sind öffentlich zugänglich - jeder kann sie angreifen. Sie verarbeiten oft persönliche, finanzielle oder gesundheitsbezogene Daten. Ein Ausfall kostet Kunden, Umsatz und Vertrauen. Interne Tools sind nur für Mitarbeiter da, haben meist Zugriffskontrollen und werden nicht von externen Angreifern direkt angesteuert. Das macht sie weniger anfällig - aber nicht ungefährlich. Deshalb brauchen sie weniger Sicherheit, aber nicht keine.
Wie erkenne ich, ob ein internes Tool zu einem externen Produkt geworden ist?
Wenn es plötzlich von Kunden oder externen Partnern genutzt wird, wenn es sensible Daten verarbeitet, die nicht mehr nur intern sind, oder wenn ein Ausfall direkte finanzielle Folgen hat - dann ist es kein internes Tool mehr. Nutzen Sie Tools wie AWS Config oder Lumigo, um automatisch Nutzungsmuster zu erkennen. Wenn eine App in einer Woche von 5 auf 1.000 Nutzer wächst - ändern Sie die Kategorie. Sofort.
Kann ich das mit kostenlosen Tools machen?
Ja. Sie brauchen keine teure Software, um anzufangen. Nutzen Sie OWASPs kostenlose Risikomatrix-Vorlage, erstellen Sie eine einfache Tabelle in Excel oder Google Sheets, und definieren Sie klare Regeln. Die teuren Tools wie Snyk oder Checkmarx helfen bei der Automatisierung - aber nicht bei der Denkweise. Die Denkweise ist das Wichtigste.
Was passiert, wenn ich eine App falsch eingeordnet habe?
Sie erhöhen das Risiko eines Sicherheitsvorfalls. Ein Prototyp, der als sicher gilt, aber sensible Daten speichert, wird nie gescannt - und wird zum Einfallstor. Ein externes Produkt, das als intern gilt, wird nicht auf OWASP-Konformität geprüft - und kann leicht gehackt werden. Die Folgen: Datenverlust, Geldstrafen, Reputationsschaden. Die Lösung: Regelmäßige Überprüfungen. Mindestens einmal pro Quartal. Besser: automatisch.
Ist das nur für große Unternehmen?
Nein. Kleine Unternehmen sind sogar anfälliger, weil sie weniger Ressourcen haben. Wenn Sie nur drei Apps haben - und eine davon ist Ihre Kunden-App - dann ist es noch wichtiger, sie richtig zu schützen. Sie brauchen nicht 50 Tools. Sie brauchen eine klare Regel: „Was ist kritisch?“ Und dann konzentrieren Sie sich darauf. Das ist risikobasierte Sicherheit - und sie ist für jedes Unternehmen relevant.
Herbert Finkernagel
Dezember 17, 2025 AT 13:52Die ganze Diskussion ist ein klassischer Fall von Overengineering. Sicherheit ist kein Luxus, aber diese 78 OWASP-Anforderungen für jedes externe Produkt sind reiner Aktionismus. Die meisten Unternehmen haben nicht mal eine funktionierende Firewall, und jetzt soll man 80 Stunden pro Jahr in eine App stecken, die von 200 Leuten genutzt wird? Die Realität sieht anders aus: 90 % der Angriffe passieren über veraltete Bibliotheken, nicht über fehlende Authentifizierung. Warum nicht erstmal die Basics abdecken, bevor man sich in Kategorien verliert?
Timon Ostertun
Dezember 18, 2025 AT 09:33Wer sagt dass Prototypen unbedenklich sind? Ich hab mal ein Tool gebaut um die Lagerbestände zu checken - war ein Prototyp. Zwei Monate später war es in der Produktion und hat die gesamte Buchhaltung abgeschossen. Kein Monitoring. Kein Backup. Keine Auth. Und jetzt zahlt das Unternehmen 140.000 Euro für Datenwiederherstellung. Risikobasierte Klassifizierung ist nicht komplex. Es ist nur bequem zu ignorieren bis es zu spät ist
Markus Paul
Dezember 18, 2025 AT 09:49Die Kategorisierung ist eine Illusion. Alles ist Netzwerk. Alles ist API. Alles ist Abhängigkeit. Ein Prototyp, der auf einem Container läuft, ist kein Prototyp mehr. Er ist ein Knoten. Ein Glied in einer Kette. Und die Kette bricht am schwächsten Glied. Die Frage ist nicht: Was ist extern? Sondern: Was ist verletzbar? Und das ändert sich ständig. Die Lösung ist nicht mehr Kategorien. Sondern Resilienz.
Stefanie Barigand
Dezember 18, 2025 AT 10:36Das ist typisch deutsch: Alles überdenken, alles dokumentieren, alles standardisieren. Und trotzdem bleibt Deutschland das Land, das am häufigsten von Ransomware angegriffen wird. Warum? Weil man denkt, man könnte Sicherheit durch Prozesse erzwingen. Aber Sicherheit ist Kultur. Und deutsche Unternehmen haben keine Sicherheitskultur. Sie haben eine Bürokratiekultur. Und die ist tödlich. Wer das nicht versteht, soll lieber bleiben wie er ist.
Hayden Kjelleren
Dezember 19, 2025 AT 05:21Ich hab nur eine App. Sie ist kritisch. Sie ist extern. Sie ist meine Lebensgrundlage. Ich hab keine Zeit für Kategorien. Ich hab nur eine Regel: Alles, was nicht auf 100 % funktioniert, ist ein Risiko. Und ich schütze es. Punkt.