Datenschutz bei der Signalisierung nach RFC 3325

  • Dieser Beitrag bassiert auf zwei Threads [1] [2] die vom Betreff nicht eindeutig auf das Problem hinweisen (Danke Ulf).

    Bei einem abgehenden Problem wird von der Starface der Name über das SIP Protokoll übertragen:
    P-Preferred-Indentity: "Starface Benutzer" <sip: +000000000000@starface.de>

    Das bedeutet:
    * bei jedem ausgehenden Gespräch wird der Starface Benutzer Name übertragen
    * bei jedem ausgehenden Gespräch wird die Firma und der Name übertragen wenn der Kontakt von der Starface aufgelöst werden kann*
    * bei jedem iFMC Call wird die Firma und der Name übertragen wenn der Kontakt von der Starface aufgelöst werden kann*

    * hier sehe ich das größte Problem, die Nummer wird einem Name zugeordnet der unter Umständen nicht veröffentlich werden möchte (Arzt, Anwalt, ...) und dann per SIP in die "Welt" übertragen.

    Daniel hat das hier [3] noch einmal super zusammengefasst.

    Ich überschreibe den Namen jetzt immer mit SetCaller(), das hat bei nur iFMC Benutzer den Nachteil das die Mail mit den verpassten Anrufen mein "Ersatzname" anzeigen.


    [1] https://support.starface.de/forum/showthre…externe-Leitung
    [2] https://support.starface.de/forum/showthre…me-quot-gt-iFMC
    [3] https://support.starface.de/forum/showthre…ull=1#post35569

    Edit:
    Im laufe dieses Threads kam immer wieder der Hinweis auf das es KEIN Starface Problem ist sondern die Ursache im SIP bzw. der RFC Spezifizierung liegt.
    Ich möchte deutlich darauf hinweisen das die Starface nichts falsch macht, es gibt kein generelles Sicherheitsproblem!
    Details bitte diesem Thread entnehmen.

    Grüße
    slu

    ---
    Ich bin kein Starface Partner - zufriedener Starface Anwender seit Anfang 2008.

    Meine Module: Einfache Community Blacklist

    Edited 2 times, last by slu: Hinweis das es kein Starface Sicherheitsproblem ist. (February 25, 2018 at 6:09 PM).

  • slu: Ich habe das Thema aufmerksam und interessiert verfolgt und Deine absolut berechtigten Fragezeichen nachvollziehen können - Danke, dass Du das nochmal aufgewärmt hast. Leider war mir die Tragweite zunächst gar nicht soooo klar (hatte mich ehrlicherweise mit diesem Punkt mal nicht gleich so beschäftigt, wie man es wohl tun müsste - ich befürchte, dass das Andere ebenso vernachlässigen oder genauer gesagt: übersehen).

    Ich würde mich durchaus den Gedanken an eine datenschutzrechtliche (mind.) "Grenzwertigkeit" anschliessen - das ist eine wahrhaftig doofe Lücke. Wenn ein Stopfen des Problemes so einfach zu realisieren ist, sollte man das natürlich in ein Modul packen (werde ich wohl exakt genau so tun). Der Punkt Namensanzeige im Mail des IFMC-Nutzers ist dann natürlich "unschön" aber das kleinere Problem.

    Was steht denn dort drin, wenn jemand "Anonym" telefoniert ... hoffentlich nicht auch der Benutzername?

  • Die beschriebenen Beobachtungen sind kein allgemeines Problem der STARFACE. Es handelt sich hierbei um Einstellungen des konkreten Providerprofils und können auch dort geändert werden.

    Ich habe gerade einen Test mit einem QSC IPfonie Extended gemacht. Fromuser leer, Contact auf "Erste Nummer", Wählformat-Typ auf RFC3323 – gegentetestet mit tcpdump.
    In den Headern sind keine personenbezogenen Daten außer der Rufnummer. Und dass die bei einem Gespräch übertragen wird ist wenig überraschend ;)

  • Hallo Fabian,
    Ich habe das default "Sipcall business (CH)" (geliefert von Starface) in Gebrauch und die Konfiguration ist hier dieselbe wie du erwähnt hast. Leitung mit CLIP no Screening und keine spezielle Konfiguration. Alles Defaulteinstellungen.
    Allerdings wird bei mir definitiv der Starface Name in From: und P-Prefered-Identity: mitgeliefert. Auch per tcpdump auf der Starface (Cloud) und auf dem Firewall mit einem Trace nachgeprüft.
    Wo könnte das "Problem" trotzdem liegen?
    Daniel

  • Die beschriebenen Beobachtungen sind kein allgemeines Problem der STARFACE. Es handelt sich hierbei um Einstellungen des konkreten Providerprofils und können auch dort geändert werden.

    Ich habe gerade einen Test mit einem QSC IPfonie Extended gemacht. Fromuser leer, Contact auf "Erste Nummer", Wählformat-Typ auf RFC3323 – gegentetestet mit tcpdump.
    In den Headern sind keine personenbezogenen Daten außer der Rufnummer. Und dass die bei einem Gespräch übertragen wird ist wenig überraschend ;)

    Dann sollte STARFACE alle Provider aktiv angehen, die auf siptrunk.de gelistet sind und die entsprechende Konfiguration im Profil verlangen um die Zertifizierung für siptrunk.de zu behalten.

    Gruss
    Thomas

    hertli ¦ IT
    hertli Informatik+Treuhand

    eMail: mail ( a t ) hertli.ch
    Internet: https://www.hertli.ch

    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Hallo Fabian,
    Ich habe das default "Sipcall business (CH)" (geliefert von Starface) in Gebrauch und die Konfiguration ist hier dieselbe wie du erwähnt hast. Leitung mit CLIP no Screening und keine spezielle Konfiguration. Alles Defaulteinstellungen.
    Allerdings wird bei mir definitiv der Starface Name in From: und P-Prefered-Identity: mitgeliefert. Auch per tcpdump auf der Starface (Cloud) und auf dem Firewall mit einem Trace nachgeprüft.
    Wo könnte das "Problem" trotzdem liegen?
    Daniel

    Am Wählformat-Typ vielleicht? Dieser bestimmt, welche konkreten Einstellungen in Bezug auf Header und deren Zusammensetzung gewählt werden.

  • Am Wählformat-Typ vielleicht? Dieser bestimmt, welche konkreten Einstellungen in Bezug auf Header und deren Zusammensetzung gewählt werden.

    Unten ein Screenshot beider Profile.
    Ich sehe eigentlich nur zwei (markierte) Bereiche die möglicherweise einen Einfluss hätten, kann das dann aber nicht nachvollziehen.

    24-02-_2018_14-22-48.jpg

    24-02-_2018_14-22-48-1.jpg

    Starface Support meint übrigens dass sie mich nicht mehr unterstützen könnten wenn ich am Sipcall Profil etwas anpasse...

    Daniel

    Edited once, last by DanielH (February 24, 2018 at 2:37 PM).

  • Dann kopier doch das Profil in ein eigenes und ändere dort dann den Wählformat-Typ RFC3323 statt RFC3325.

    Sollte das funktionieren, dann Auftrag an SIPCALL, dass diese das in ihrem Standardprofil auf siptrunk.de anpassen.

    Nicht nur in der DSGVO sondern auch im Schweizer Datenschutzrecht darf keine Beziehung zwischen einer Nummer und einer Person hergestellt werden; Standardeinstellungen haben grundsätzlich auf "privacy by design" resp. "privacy by default" zu stehen.

    Gruss
    Thomas

    hertli ¦ IT
    hertli Informatik+Treuhand

    eMail: mail ( a t ) hertli.ch
    Internet: https://www.hertli.ch

    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Nach einigen Tests auf einer separaten Testanlage, frisch aufgesetzt mit zwei Linien (031xxxxxxx und 032xxxxxxx), kann ich bestätigen dass die Abänderung von RFC3325 auf RFC3323 den gewünschten Effekt gebracht hat.
    Tatsächlich kann ich auch mit dem Feld fromuser statt der Nummer, den Firmennamen mitgeben. Was dann auf der anderen Seite angezeigt wird muss ich noch im Detail testen.
    RFC3323 ändert übrigens P-Preferred-Identity in P-Asserted-Identity um. Auch dort wird der Name durch die Nummer ersetzt.

    RFC3325:
    From: "Admin Admin" <sip:+4131xxxxxxx@business1.voipgateway.org>;tag=as550a421a
    P-Preferred-Identity: "Admin Admin" <sip:+4131xxxxxxx@starface.de>

    RFC3323:
    From: "+4132xxxxxxx" <sip:+4132xxxxxxx@business1.voipgateway.org>;tag=as68e9718f
    P-Asserted-Identity: <sip:032xxxxxxx@business1.voipgateway.org>

    RFC3323 mit fromuser=FIRMA:
    From: "+4132xxxxxxx" <sip:FIRMA@business1.voipgateway.org>;tag=as68e9718f
    P-Asserted-Identity: <sip:032xxxxxxx@business1.voipgateway.org>


    Die vorherigen Tests auf einer produktiven Anlage haben nicht funktioniert weil das Routing nicht meine angepasste Testleitung benutzt hat (shame on me :( )


    Bleibt nur noch die Sache mit dem default Profil.. Aus DSGVO Gründen sollte dieses RFC3323 benutzen. Thomas hat da schon recht dass Starface und SIPCALL zusammenarbeiten sollten... Ich werde Starface und SIPCALL mal kitzeln..


    Daniel

  • Das korrekte Wählformat hängt natürlich vom Provider ab. Es ist also nicht richtig, das Wählformat einfach auf ein anderes Format zu ändern, denn wie schon richtig festgestellt, ändern sich hierbei Identity-Header, Caller-Presentation, etc.

    Ich empfehle, mit dem folgenden Hinweis an einen STARFACE Partner seines Vertrauens heranzutreten -- dieser kann mögliche Auswirkungen abschätzen:
    In der Datenbanktabelle providersignalling finden sich die konkreten Einstellungen der einzelnen Wählformate. Es lassen sich bestehende Wählformate anpassen oder auch neue Wählformate anlegen. Meist (und das empfehle ich), findet man hier ein alternatives Format, das sowohl auf den eigenen Provider, als auch vielleicht besser zu den eigenen Bedürfnissen passt.

    In der Tabelle gibt es die Spalte value, in der die finalen SIP-Header-Einträge bzw. Variableninhalte mit Hilfe von Platzhaltern definiert sind. ###NAME### wird hier bspw. durch den Anwendernamen ersetzt, ###USERNAME### durch den Login-Benutzernamen und so weiter. Natürlich lassen sich auch statische Inhalte angeben.

    Die Custom-Einträge stammen in der Regel von siptrunk.de-Profilen. Es ist also durchaus nicht verkehrt, bei "Information-Leaks" den eigenen Provider anzusprechen, sofern dieser das Profil auf siptrunk.de verwaltet.

    Oder aber: Man schließt mit dem Provider einen ADV-Vertrag, läßt sich die TOMs des Providers zur eigenen Prüfung übermitteln und akzeptiert die Übermittlung bestimmter, definierter Informationen im Rahmen der Erbringung von Kommunikationsdienstleistungen. Die Anbieter erbringen öffentlich zugängliche Telekommunikationsdieste und Telefondienste im Sinne des Telekommunikationsgesetzes (TKG) und unterliegen ohnehin den besonderen Datenschutzanforderungen und dem Fernmeldegeheimnis des TKG ;)

  • Hallo Fabian,

    danke für deine Erklärungen und die verschiedenen Ansätze, ich stimme dir bei der RFC Signalisierung vollkommen zu (und hab nebenbei wieder was von dir gelernt!).
    Auch stimmt es das es kein explizites Starface Problem ist.

    Aber Starface ist besser als die anderen!
    Deshalb würde ich persönlich als Starface die Diskussion um den Datenschutz einfach nutzen und eine Option bieten die RFC "Konform" signalisiert aber einen Firmennamen anzeigen/einstellen lässt.

    Grüße
    slu

    ---
    Ich bin kein Starface Partner - zufriedener Starface Anwender seit Anfang 2008.

    Meine Module: Einfache Community Blacklist

    Edited once, last by slu: Formulierung (February 25, 2018 at 6:30 PM).

  • Die Anbieter erbringen öffentlich zugängliche Telekommunikationsdieste und Telefondienste im Sinne des Telekommunikationsgesetzes (TKG) und unterliegen ohnehin den besonderen Datenschutzanforderungen und dem Fernmeldegeheimnis des TKG ;)

    Dann sollen sie ihre Standards den Datenschutzvorschriften anpassen.

    Insbesondere DSGVO verlangt

    • privacy by design
    • privacy be default

    Es kann nicht im Sinne der Datenschutzgesetze und schon gar nicht der Anwender sein, dass diese gesetzliche Vorgabe nicht eingehalten wird und der Anwender oder dessen Partner auf die Datenbank verwiesen wird, was dann auch wieder an jedem Standard vorbeigeht.

    Der Hinweis auf die Datenbank kann allerhöchstens ein Workaround bis April 2018 sein, bis DSGVO in vollem Umfang greift, resp. die Übergangsfristen abgelaufen sind.

    Gruss
    Thomas

    hertli ¦ IT
    hertli Informatik+Treuhand

    eMail: mail ( a t ) hertli.ch
    Internet: https://www.hertli.ch

    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Dann sollen sie ihre Standards den Datenschutzvorschriften anpassen.

    Insbesondere DSGVO verlangt

    • privacy by design
    • privacy be default

    Es kann nicht im Sinne der Datenschutzgesetze und schon gar nicht der Anwender sein, dass diese gesetzliche Vorgabe nicht eingehalten wird und der Anwender oder dessen Partner auf die Datenbank verwiesen wird, was dann auch wieder an jedem Standard vorbeigeht.

    Der Hinweis auf die Datenbank kann allerhöchstens ein Workaround bis April 2018 sein, bis DSGVO in vollem Umfang greift, resp. die Übergangsfristen abgelaufen sind.

    Nicht ganz. Zunächst ist es nicht die DSGVO oder BDSG neu, die "privacy by design" oder "privacy by default" fordern, sondern in den Erwägungsgrundsätzen der Verordnung ist folgendes bezüglich "data protection by design" und "data protection by default" formuliert:

    Quote

    (78)
    Zum Schutz der in Bezug auf die Verarbeitung personenbezogener Daten bestehenden Rechte und Freiheiten natürlicher Personen ist es erforderlich, dass geeignete technische und organisatorische Maßnahmen getroffen werden, damit die Anforderungen dieser Verordnung erfüllt werden. Um die Einhaltung dieser Verordnung nachweisen zu können, sollte der Verantwortliche interne Strategien festlegen und Maßnahmen ergreifen, die insbesondere den Grundsätzen des Datenschutzes durch Technik (data protection by design) und durch datenschutzfreundliche Voreinstellungen (data protection by default) Genüge tun. Solche Maßnahmen könnten unter anderem darin bestehen, dass die Verarbeitung personenbezogener Daten minimiert wird, personenbezogene Daten so schnell wie möglich pseudonymisiert werden, Transparenz in Bezug auf die Funktionen und die Verarbeitung personenbezogener Daten hergestellt wird, der betroffenen Person ermöglicht wird, die Verarbeitung personenbezogener Daten zu überwachen, und der Verantwortliche in die Lage versetzt wird, Sicherheitsfunktionen zu schaffen und zu verbessern. In Bezug auf Entwicklung, Gestaltung, Auswahl und Nutzung von Anwendungen, Diensten und Produkten, die entweder auf der Verarbeitung von personenbezogenen Daten beruhen oder zur Erfüllung ihrer Aufgaben personenbezogene Daten verarbeiten, sollten die Hersteller der Produkte, Dienste und Anwendungen ermutigt werden, das Recht auf Datenschutz bei der Entwicklung und Gestaltung der Produkte, Dienste und Anwendungen zu berücksichtigen und unter gebührender Berücksichtigung des Stands der Technik sicherzustellen, dass die Verantwortlichen und die Verarbeiter in der Lage sind, ihren Datenschutzpflichten nachzukommen. Den Grundsätzen des Datenschutzes durch Technik und durch datenschutzfreundliche Voreinstellungen sollte auch bei öffentlichen Ausschreibungen Rechnung getragen werden.


    Quelle: http://eur-lex.europa.eu/legal-content/…16R0679&from=DE

    Wir halten fest:
    Hier ist von Empfehlungen die Rede. Ansonsten stünde nicht "sollte", "könnte", etc. sondern "muß".
    Außerdem betreffen die Empfehlungen die verantwortliche Stelle. Das ist in diesem Fall den Betreiber der DV-Anlage. Nicht die Hersteller -- außer, dass diese "ermutigt" werden sollen, ihre Produkte entsprechend zu gestalten ;)
    Die "Default-Einstellung" einer Anlage enthält übrigens gar keinen SIP-Trunk zu Drittanbietern. Insofern wäre "Data Protection by Default" ohnehin umgesetzt. Es ist die verantwortliche Stelle (hier in der Regel der Kunde), die davon abweichend konfiguriert.

  • Es ist die verantwortliche Stelle (hier in der Regel der Kunde), die davon abweichend konfiguriert.

    Da gehe ich mit Dir nicht einig. Zumindest die Provider, die auf siptrunk.de gelistet sind sollten diese Vorgaben erfüllen. Der Kunde verlässt sich da drauf. Es kann nicht sein, dass hier "Standard"-Profile zur Verfügung gestellt werden und der Kunde nicht deutlich darauf hingewiesen wird, dass mit diesen Einstellungen und Parametern DSGVO nicht erfüllt ist. Dem Kunden ist es nicht zuzumuten, anhand von Parametern zu entscheiden, was diese für Auswirkungen haben.

    Gruss
    Thomas

    hertli ¦ IT
    hertli Informatik+Treuhand

    eMail: mail ( a t ) hertli.ch
    Internet: https://www.hertli.ch

    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Hallo Fabian,

    da hast Du zwar zunächst mal recht - nur muss der Kunde auch die Möglichkeit haben, diese Problemstellen zu kennen. Und wir sind uns sicher einig darin, dass die allermeisten Nutzer der Starface diesen Punkt nicht mal ansatzweise als Problemstelle vermutet, geschweige denn hinterfragt haben werden.
    Nehmen wir mal Deine Module - da weist Du doch auch bewusst und absolut vorbildlich darauf hin, dass diese von Dir aufgeführten Vorgaben entsprechen oder einen defnierten Rahmen einhalten. Du überlässt es also nicht Deinen Kunden, dass die sich um die "Nebeneffekte" kümmern müssen ...

    Die Profildaten werden zur TK-Anlage mitgeliefert (das ist auch gut so) - bei verifizierten Daten (und das soll ja ausdrücklich so sein), suggeriert das aber auch: "alles im Rahmen der Vorschriften". Jedenfalls werden das wohl die allermeisten Nutzer so sehen. Dass eventuell etwas geliefert wird, was man erst anpassen muss, damit es dort wo es neben der Lieferung auch eingesetzt wird korrekt funktioniert, vermutet doch niemand ...

    Ich denke, darauf wollte Thomas raus ... oder?

    Vermutlich wäre es am einfachsten - wenn das alles nur so "Kleinigkeiten" sind, die Vorgabe dort anzupassen, wo sie herkommt. Das möchte ich dann aber auch nur als konmstruktive Kritik und Anregung verstanden wissen.

  • Hallo Ulf,

    ich stimme zu, dass das für den Kunden als verantwortliche Stelle schwer zu prüfen oder auch umzusetzen ist. Aber das interessiert den Betroffenen (dessen Daten gehandhabt werden) oder den Gesetzgeber nicht.
    Zur Not muß die verantwortliche Stelle ihre Anbieterwahl überdenken und sich für einen anderen Provider entscheiden. So ist's nunmal.

    Dass es kein grundsätzliches "Problem der Anlage" ist, haben wir denke ich geklärt.
    Dass die Providerprofile durch die Provider selbst gepflegt werden können, ist denke ich auch sinnvoll. Der Provider kennt die für ihn notwendigen Einstellungen am Besten und kann so auch Änderungen umsetzen.

    Nun muß der Kunde im Rahmen seiner gesetzlichen Verpflichtung für eine konforme Handhabung sorgen. Wenn das in den Standardeinstellungen nicht möglich ist, muß das Profil geändert werden oder man muß zu einem Anbieter wechseln, der es besser macht.

  • Das korrekte Wählformat hängt natürlich vom Provider ab. Es ist also nicht richtig, das Wählformat einfach auf ein anderes Format zu ändern, denn wie schon richtig festgestellt, ändern sich hierbei Identity-Header, Caller-Presentation, etc.
    [...]
    Die Custom-Einträge stammen in der Regel von siptrunk.de-Profilen. Es ist also durchaus nicht verkehrt, bei "Information-Leaks" den eigenen Provider anzusprechen, sofern dieser das Profil auf siptrunk.de verwaltet.

    SIPCALL ist leider auf siptrunk.de nicht gelistet. Da haben wir keinen Ansatzpunkt. Ich habe meinen Kontakt bei SIPCALL mal darauf angesprochen.


    Aber Starface ist besser als die anderen!
    Deshalb würde ich persönlich als Starface den "Hyphe" um den Datenschutz einfach nutzen und eine Option bieten die RFC "Konform" signalisiert aber einen Firmennamen anzeigen/einstellen lässt.

    Finde ich einen guten Ansatz. Allerdings muss man an die richtigen Leute bei Starface gelangen. Mein derzeitiger Supportkontakt zu dem Thema (offenes Ticket [Call#6901192]) ist leider neu und wahrscheinlich nicht der richtige.

    Dann sollen sie ihre Standards den Datenschutzvorschriften anpassen.

    Insbesondere DSGVO verlangt
    privacy by design
    privacy be default

    Es kann nicht im Sinne der Datenschutzgesetze und schon gar nicht der Anwender sein, dass diese gesetzliche Vorgabe nicht eingehalten wird und der Anwender oder dessen Partner auf die Datenbank verwiesen wird, was dann auch wieder an jedem Standard vorbeigeht.

    Der Hinweis auf die Datenbank kann allerhöchstens ein Workaround bis April 2018 sein, bis DSGVO in vollem Umfang greift, resp. die Übergangsfristen abgelaufen sind.

    Da bin ich vollkommen mit dir einig, Thomas

    Ob zuzumuten oder nicht,... die verantwortliche Stelle ist der Kunde. Dieser muß die gesetzlichen Anforderungen erfüllen und zur Not Anpassungen an seinen Systemen vornehmen.


    Ich bin da eher auf der Linie von Thomas. Wenn Starface Vorlagen ("Defaults")für Providerprofile mitliefert, dann sollten diese die entsprechenden gesetzlichen Bedingungen entweder erfüllen, oder man sollte als Anwender darauf hingewiesen werden dass sie es nicht tun.
    Wenn dann Support mich darauf hinweist dass eine Anpassung der von ihnen gelieferten Profile (zum Zweck der Anpassung an das DSGVO) zu einem nicht mehr supportierten Status führt, dann werde ich etwas stutzig.

    Im Kern hast du recht, Fabian. Aber ich glaube kaum dass es effizient ist dass jeder Anwender selber mit dem Provider schauen muss dass das entsprechende Providerprofil funktioniert. Dort sehe ich den grossen Vorteil von Starface wenn sie "supportierte" Providerprofile anbieten.

    Wir haben hier sonst eine klassische Dreiecksbeziehung (Kunde-Provider-Starface). Und in meiner Erfahrung führt das zu oft zu unklaren Situationen.

    Ich würde es begrüssen wenn Starface hier etwas Verantwortung übernimmt. Und natürlich auch der Provider.

    Aus einem ähnlichen Grund (zwar technisch aber im Bereich RFC Kompatibilitäten) habe ich übrigens vor Jahren Konsequenzen gezogen und bin mit allen meinen Kunden weg von e-fon zu SIPCALL gewechselt.

    Daniel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!