Als Ex-ISP Aktivist kenne ich die Überlegungen die man so anstellt zwischen Datenschutz und effektivem Abuse Management. Als guter Net-Citizen möchte man auf die Beschwerden (wegen Spams, Wurmschleudern, Scans, Hackangriffe oder Fehlkonfiguration) an das Abuse-Team natürlich eingehen. Gleichzeitig gibt es Bedenken, welche Daten gespeichert und weitergegeben werden können. Schon alleine die Frage ob man eine Beschwerde von einem unbekannten verifizieren kann hängt im wesentlichen von den geführten Logs ab.
In Deutschland ist der Datenschutz hier zum Glück sehr kleinlich: Keine Speicherung von personenbezogenen Daten ohne Gründe aus den Bereichen Abrechnung oder Betrieb. Die Auslegung, was nun technisch notwendig ist bereitet nicht nur den Abuse Teams der Provider Probleme.
Und die Strafverfolgung kommt hier als Grund nicht vor. So gesehen ist eine Regulierung in diesem Bereich überfällig, um die unklare Situation zu entschärfen. Jedoch schießt die Innenminister Konferenz mit ihrer Forderung nach Speicherung für ein Jahr über das Ziel hinaus: das belastet nicht nur die Infrastruktur, sondern das führt auch zu Datenansammlungen die (wie alle Datenansammlungen) missbraucht werden.
Dazu kommt dann noch die Entwicklung der letzten Jahre, dass dank Überwachungsverordnung (und Kontenabrufverfahren und und und) die Datensammelwut des Staates enorm zugenommen hat. Für das Bürger-Mining wollen die ISPs nun wirklich nicht sammeln.
In Deutschland ist der Datenschutz hier zum Glück sehr kleinlich: Keine Speicherung von personenbezogenen Daten ohne Gründe aus den Bereichen Abrechnung oder Betrieb. Die Auslegung, was nun technisch notwendig ist bereitet nicht nur den Abuse Teams der Provider Probleme.
Und die Strafverfolgung kommt hier als Grund nicht vor. So gesehen ist eine Regulierung in diesem Bereich überfällig, um die unklare Situation zu entschärfen. Jedoch schießt die Innenminister Konferenz mit ihrer Forderung nach Speicherung für ein Jahr über das Ziel hinaus: das belastet nicht nur die Infrastruktur, sondern das führt auch zu Datenansammlungen die (wie alle Datenansammlungen) missbraucht werden.
Dazu kommt dann noch die Entwicklung der letzten Jahre, dass dank Überwachungsverordnung (und Kontenabrufverfahren und und und) die Datensammelwut des Staates enorm zugenommen hat. Für das Bürger-Mining wollen die ISPs nun wirklich nicht sammeln.
(Seite 1 von 1, insgesamt 1 Einträge)
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-08(a)eckenfels.net
Read More
Suche
Kategorien
Umfrage
Inhouse Coding?
Archive
Archive
Blog abonnieren
Blogsphere
Letzten Monat...
So, 16.11.2008 Security Checklisten (Einfacher durch SCAP)
Das Hardening von Rechnern besteht typischerweise aus einer Abarbeitung von Checklisten. Ebenso gibt es jede Menge verbindlicher Standards und Security Profile, die eine gewisse Konfiguration von Rechnern voraussetzen. In der Vergangenheit waren diese Arbeiten immer mit handgestrickten Scripten oder kommerziellen Produkten verbunden.
Dank der Amerikanischen Cyber Terror Angst werden aber durch diverse Behörden und Regierungsnahe Stellen immer wieder sehr nützliche Innovationen vorangetrieben. Einiges läuft dort inzwischen unter dem Information Security Automation Program:
OVAL ist eine XML Sprache zur Beschreibung von Platform Checks. Mit einem OVAL Interpreter können diese ausgeführt werden, und die entsprechenden Reports helfen somit bei der Systemadministration. Neben der OVAL Language gibt es auch das OVAL Repository das eine Reihe von Prüfungen (Vulnerabilities, Patches, Inventory) frei anbietet. Neben der Referenzimplementierung des OVAL Interpreters werden auch noch weitere Open Source Projekte entsprechende Tools anbieten. So zum Beispiel OpenVAS 2.0 Beta.
Neben OVAL das auf die Systemtechnische Seite von Security Empfehlungen eingeht gibt es noch das XCCDF (The Extensible Configuration Checklist Description) Format. Schwerpunkt hier ist es die ganzen Punkte einer Checkliste formalisiert darzustellen. Unterstützt werden dabei sowohl Profile (Subsets von Controls) als auch die Integration von automatisierten Checks (z.B. mittels OVAL).
In dem Umfeld gibt es eine ganze Reihe Protokollen:CVE - Die öffentliche Software Schwachstellen DatenbankCCE - Configuration ItemsCPE - PlatformenCME - MalwareCWE - Software Weakness undCAPEC - AngriffsmusterBesonders CVE ist dabei sehr weit verbreitet, da es die Unzahl vor Hersteller und Distributoren spezifische Codes vereinheitlicht hat. Diese Notwendigkeit ist insbesondere im Linux Umfeld entstanden, da jeder Distribution ihr eigenes Süppchen gekocht hat. Aber auch die Vereinheitlichung der anderen Dimensionen der Klassifizierung von Schwachstellen macht das Leben eines Systemadministrators oder Security Officers einfacher.
Sa, 08.11.2008 Hash Funktionen
Es gibt Neuigkeiten im Bereich Kryptographie, insbesondere im Bereich der sicheren Hash Funktionen: Halloween war Einreichungsschluss beim NIST Wettbewerb "NIST hash competition" der unter dem Namen SHA-3 einen würdigen Nachfolger für die in Verruf geratenen Hash Algorithmen SHA-1 und MD5 sucht. Es gibt noch keine offiziellen Ergebnisse, aber eine inoffizielle Bewertung im SHA-3 Zoo Wiki der TU-Graz.
Außerdem hat NIST eine neue Revision des Secure Hash Standards (SHS) in FIPS 180-3 (PDF) veröffentlicht. Hier werden die folgenden fünf Algorithmen definiert: SHA-1, SHA-224, SHA-256, SHA-384 und SHA-512. Auf die bekanntgewordenen Angriffe gegen SHA-1 geht die FIPS Publikation allerdings nicht ein, die Sicherheitsbewertungen wurden aber entfernt, damit diese in Special Publications schneller aktualisiert werden können.
(Via D-kriptik Blog)
Top Referers
www.google.de (11)
blogs.seekport.de (10)
www.google.com (5)
www.google.ch (3)
search.live.com (2)
www.keywordspy.com (2)
eckenfels.net (1)
www.google.at (1)
blogs.seekport.de (10)
www.google.com (5)
www.google.ch (3)
search.live.com (2)
www.keywordspy.com (2)
eckenfels.net (1)
www.google.at (1)

Kommentare