# Passwort Sicherheitssteuerung



## stevenn (31 März 2016)

Hallo zusammen,

unser Kunde will das Passwort für die Sicherheitssteuerung. Da in der "Programmierweise"  Know-How steckt und ich als Hersteller natürlich nicht will, das er an der Sicherheitssteuerung etwas macht, will ich das Passwort eigentlich nicht herausgeben. Habt ihr da Ideen, was ich machen kann? Verbietet die MRL nicht auch irgendwie über _die Verpflichtung eine sichere Maschine auf den Markt zu bringen_, das Passwort herauszugeben? Wenn der Kunde das Passwort hat, ist die Anlage für mich nicht mehr sicher.


----------



## LargoD (31 März 2016)

Gerade in einer Sicherheitssteuerung sollte kein schützenswertes Know-How stecken, das sollte so übersichtlich wie möglich programmiert sein, so dass man es ohne Spezialwissen verstehen kann.
Bezüglich Passwort gilt das, was vertraglich vereinbart ist.
Versuch mal bei einem Automobil-Hersteller, das Passwort geheim zu halten 
Gruß
Erich


----------



## MasterOhh (31 März 2016)

Das hängt davon ab wie die Nutzerverwaltung bei deiner Sicherheitssteuerung realisiert ist.
IdR sollte die Sicherheitssteuerung mitloggen wer zu letzt Änderungen am Sicherheitsprogramm gemacht hat. 
Bei Beckhoff ist es z.B. so, dass man mit verschiedenen Accounts auf das TwinSAFE Programm zugreifen kann. Über das Protokoll ist dann nachvollziehbar wer wann Änderungen vorgenommen hat. Wenn das bei deiner Steuerung auch so funktioniert, dann richtet einfach einen Account für den Kunden ein und ihr könnt im Falle eines Problems nachweisen das ihr nicht die letzten wart, die am Programm Hand angelegt haben.

Rechtlich sollte das eigentlich auch keine Probleme verursachen. Ihr könnt ja auch nicht verhindern, dass der Kunde an der Verdrahtung herumspielt. Und da kann der Kunden sogar die Änderungen Rückgängig machen ohne das ihr Nachweisen könnt das Rumgepfuscht wurde.

Was den Know-Schutz angeht hängt das vom Vertrag ab und davon was für ein Verhältnis ihr zum Kunden habt. Locken Folgeaufträge? Ist eine Vertrauensbasis da? Da kann man schwer eine pauschale Aussage treffen.


----------



## stevenn (31 März 2016)

danke für eure Antworten. naja die Programmierung ist schon einfach nachzuvollziehen. nur gibt es ja kniffe, die das Programmieren einfacher machen, aber das soll nicht das Thema sein. 
Mitgeloggt wird, ja. verschiedene Accounts bringen nichts, da der Kunde natürlich das "oberste" Passwort will. 
Also werde ich es nicht verhindern können, das Passwort rauszugeben. Macht für mich wenig Sinn (aus MRL-Sicht), weil ich ihm so die Manipulation natürlich sehr einfach mache, aber mir fällt auch kein Grund ein ihm die Herausgabe zu verweigern (außer einfache Manipulationsmöglichkeit).


----------



## weißnix_ (31 März 2016)

Die Herausgabe kannst Du ja entsprechend schriftlich mit einer Haftungsausschlusserklärung verbinden. Es ist dann zumindest ein Anhaltspunkt da und den Programmstand zum Auslieferungszeitpunkt wirst Du ja dokumentiert haben.


----------



## andrejtm (31 März 2016)

Eine Möglichkeit zu prüfen ob eine Änderung am Code durchgeführt wurde, wäre ein CRC des Codes. Dadurch kann die Integrität des Codes hinsichtlich Manipulationen sichergestellt werden und viele Sicherheitssysteme speichern auch eine Historie der CRC Codes.


----------



## stevenn (31 März 2016)

so läuft es ja. ich hab nur ein bisschen das Problem, das ein Maschinenhersteller nach 14119 Manipulation so weit wie möglich verhindern muss und das würde ich mit der Herausgabe des Passwortes nicht tun.Aber dann kann ich hier halt keine Manipulation verhindern, sondern nur meinen übergebenen Stand dokumentieren. Dieses "Manipulation verhindern" wäre noch der einzige Grund für mich gewesen, das Passwort nicht herauszugeben.


----------



## andrejtm (31 März 2016)

Durch die Einführung eines Passwortes hast du ja versucht eine Manipulation zu verhindern. Und dieses kann ja auch im Sicherheitskonzept niedergeschrieben werden und somit würde die Information im Falle eines "Unfalls nach einer Manipulation" als Nachweis vorhanden sein.

Wenn Euer Kunde das Passwort erhält und dieser das Passwort seinen Mitarbeitern/Servicetechnikern mitteilt, dann ist er in der Verantwortung wenn etwas verändert wird. Eine Manipulation komplett ausschließen kann niemand und dies ist ja auch nicht das Zielt. Man muss nur das Risiko so weit wie technisch möglich mindern...

Ich würde das Passwort nur nicht in der Betriebsanleitung aufführen sondern höchstens als getrenntes Dokument mit dem (bereits genannten) Haftungsausschluss und einem Verweis auf die CRC bei Auslieferung.


----------



## PN/DP (31 März 2016)

Meinst Du das Passwort des Sicherheits-Programms oder willst Du das normale Anwenderprogramm KnowHow-schützen?

Harald


----------



## stevenn (4 April 2016)

PN/DP schrieb:


> Meinst Du das Passwort des Sicherheits-Programms oder willst Du das normale Anwenderprogramm KnowHow-schützen?
> 
> Harald



ich meine das Passwort um am Programm etwas ändern zu können


----------



## Dos6.22 (4 April 2016)

Ich denke mal, dass der Kunde für den Fehlerfall in der Lage sein will in diesen Programmteil zuschauen? Bzw. wenn die Anlage umgebaut wird, dass man auf alles zugreifen kann.
Bei Siemens ist es ja so, dass man in die F Software auch ohne Passwort reinschauen kann. Evtl. reicht das ja schon aus.
Dann solltest du dem Kunde auch klar machen, wenn er das F Programm aus irgendwelchen Gründen ändert, die CE erlöscht die von einer Firma erstellt wurde (würde sie bei bestimmten Umbauten sowieso verlieren). Daher ist es auch wichtig, den Hash Code zu notieren und den Programmstand bei Übergabe aufzubewaren, damit man sowas später beweisen kann.
Genau aus dem Grund haben uns große Firmen untersagt das Passwort denen mitzuteilen, damit gar kein Instandhalter auf die Idee kommt dort was zu ändern. Das Passwort muss sich auch von anderen Standardpasswörtern unterscheiden.

Alles in deinem F Programm wird ja nicht eine geheime Entwicklung sein. Den Teil den du so schützwürdig findest, kannst du ja in einem seperaten Baustein schützen. Wenn diese Blackbox von außen so anparametriert ist, dass man Fehler entdecken kann, reicht das vielen Kunden auch.


----------



## winnman (4 April 2016)

Also wer bei uns was liefern will muss auf alle Fälle das PW für das "normale" Programm rausrücken, PW geschützte Bausteine werden nicht abgenommen.

Bei F-Programmen wird bei der Übergabe Hashcode und Programm und Programmausdruck in die Übergabedoku aufgenommen, das F-Passwort wird ebenfalls übergeben, aber nicht an alle verteilt sondern liegt auf einem nur wenigen Leuten (derzeit 3) zugänglichem Serverlaufwerk.

Wenn hier jemand Änderungen macht, muss das nach dem 4 Augenprinzip erfolgen, dann entsprechend Dokumentiert werden und diese Doku wird dann zur Anlagendoku dazugegeben.


----------

