# Verstädnisfragen zu PROFIBUS



## AlexSc (10 Juli 2015)

Hi Leute,

schonmal vorweg, ich bin relativ neu in der Materie und doppeltes Sorry   für den ziemlich langen Post! Im Zuge meiner Bachelorarbeit beschäftige   ich mich mit Sicherheit in einem Feldbussystem. Der Fokus liegt dabei   auf PROFIBUS.
Nach einiger Recherche bin ich nun soweit gekommen, dass ich denke,   PROFIBUS ganz gut erklären zu können. Hier würde ich darum gerne mal   meine Sicht der Dinge schildern und bitte um jede Art von Kommentare von   Ergänzungen bis 'Nein da liegst du komplett falsch' :wink:
Also, ich würde auf die Frage 'Was kannst du alles zu PROFIBUS erzählen?' folgendermaßen antworten:

- PROFIBUS ist wie der Name schon sagt ein Feldbus, sprich es dient  dazu, sehr schnell  auf bestimmten Übertragungsmedien (in diesem Fall  nur Kabel)  Informationen zu übertragen. Standardmäßig geschieht dies in  beliebigen Netzwerken in dem eine SPS mit verschiedenen Endgeräten   spricht. Zum Beispiel könnte eine SPS in einem Aufzug installiert sein,   welche die Eingangssignale vom Bedienfeld im Aufzug (welche Etage?)   verarbeitet und entsprechend via PROFIBUS die Tür und den Motor, der den   Aufzug hoch oder runter zieht steuert.
SPS können zB in AWL programmiert werden (hier wäre meine Frage noch,   was sich genau mit AWL nun alles machen lässt bzw wie nun die Endgeräte   tatsächlich angesprochen werden?)

- Das PROFIBUS Protokoll ist für den (Multi-)Master-Slave Betrieb   ausgelegt. An einen Bus können also mehrere Geräte angeschlossen sein,   die andere Geräte steuern. Dies geschieht zyklisch via Token Passing   zwischen den Mastern. Diese Master nennt man Class 1 Master. Zusätzlich   muss mindestens ein 'Class 2 Master' angeschlossen werden, welcher  überwachende Funktionen übernimmt und auch beim Hochfahren des Netzes   Adressen verteilt und alle anderen Geräte konfiguriert.

- Das PROFIBUS Protokoll unterteilt sich in 3 Schichten. Jedes Profibus   Telegramm besteht auf der mittleren Schicht aus einem FDL Telegramm  (das  Übertragungsmedium, also Schicht 0, sei hier mal übersprungen).  Sprich  auf dieser Ebene haben wir zB. SD1, SD2 oder SC Telegramme die  einen  Funktionscode und evtl. verschiedene Service Access Points  ansprechen.
Der Funktionscode gibt an, ob ein Telegramm ein Request, eine   Bestätigung, eine Fehlermeldung oder Ähnliches ist. Der SAP gibt   sozusagen den Tatsächlichen Befehl an, der ausgeführt werden soll (zB   ein SET_PARAM zum Setzen von verschiedenen Konfigurationsparametern in   einem Feldgerät).

- In der nächsten Schicht befinden sich dann DP-V0, DP-V1 oder DP-V2   Telegramme. Welches der Pakete nun wirklich vorhanden ist kann an den   SAPs festgemacht werden (SAP 62 (0x3E) für den Master bedeutet   zyklischen Datenaustausch, also DP-V0 usw.). DP-V0 wird ausschließlich   dazu verwendet, Eingangs und Ausgangsdaten auszutauschen (und mehr   nicht).
DP-V1 und V2 werden für Konfiguration, Parameterübergabe und Global  Control (also Broadcastbefehle an alle Slaves gleichzeitig) verwendet.

Soo, so viel dazu. Für den Fall, dass ich das alles soweit richtig verstanden habe, hier noch einige Fragen:

- Was hat es nun mit den Profilen auf sich (ProfiSAFE, PROFIdrive, etc)?
- Wird PROFIBUS tatsächlich ausschließlich zum Hin und Herschieben von Eingangs und Ausgangsdaten verwendet?
- Könnte jemand mal ein etwas umfassenderes Beispiel liefern, wie nun SPS, Endgeräte und PROFIBUS tatsächlich zusammen wirken?

Vielen Dank für jegliche Hilfe!!

Liebe Grüße,
Alex


----------



## Aventinus (10 Juli 2015)

Servus,

ich denke, mit dem 'Class 2 Master' liegst du falsch. Das PG ist ein solcher Master, muss aber nicht zwangsläufig vorhanden sein. Wenn alle Master 1. Klasse konfiguriert sind läuft der Bus ohne Master 2. Klasse.


----------



## UNI (10 Juli 2015)

Hallo Alex,

vielleicht hilft dir das hier schonmal einen Schritt weiter:
https://cache.industry.siemens.com/dl/files/591/35222591/att_105790/v1/MN_PB-Net_0.pdf

Gruß
UNI


----------



## volker (10 Juli 2015)

zu profisafe kannste hier mal schauen
http://www.profibus.com/nc/download...y-and-application-system-description/display/
http://www.profibus.com/nc/download...-application-system-description/download/196/


----------



## Gerhard Bäurle (11 Juli 2015)

AlexSc schrieb:


> Hi Leute,
> schonmal vorweg, ich bin relativ neu in der Materie und doppeltes Sorry   für den ziemlich langen Post! Im Zuge meiner Bachelorarbeit beschäftige   ich mich mit Sicherheit in einem Feldbussystem. Der Fokus liegt dabei   auf PROFIBUS.



Allgemein – falls Du es noch nicht kennst, eine gute
Quelle für Profibus sind Webseite und Buch von Max Felser:

http://www.profibus.felser.ch/index.html?technik.htm

Eventuell kannst Du noch erwähnen, warum Feldbusse
überhaupt eingesetzt werden: 

https://de.wikipedia.org/wiki/Dezentrale_Peripherie



AlexSc schrieb:


> Zum Beispiel könnte eine SPS in einem Aufzug installiert sein,   welche die Eingangssignale vom Bedienfeld im Aufzug (welche Etage?)   verarbeitet und entsprechend via PROFIBUS die Tür und den Motor, der den   Aufzug hoch oder runter zieht steuert.



Ein Aufzug ist immer ein gutes Beispiel, kennt jeder.



AlexSc schrieb:


> SPS können zB in AWL programmiert werden (hier wäre meine Frage noch,   was sich genau mit AWL nun alles machen lässt bzw wie nun die Endgeräte   tatsächlich angesprochen werden?)



Die Programmierung der SPS ist erst mal unabhängig 
vom Feldbus. E/As, die als dezentrale Peripherie ausgeführt
sind, werden vom SPS-Programm gleich behandelt, wie 
lokale E/As.



AlexSc schrieb:


> - In der nächsten Schicht befinden sich dann DP-V0, DP-V1 oder DP-V2   Telegramme. Welches der Pakete nun wirklich vorhanden ist kann an den   SAPs festgemacht werden (SAP 62 (0x3E) für den Master bedeutet   zyklischen Datenaustausch, also DP-V0 usw.). DP-V0 wird ausschließlich   dazu verwendet, Eingangs und Ausgangsdaten auszutauschen (und mehr   nicht).
> DP-V1 und V2 werden für Konfiguration, Parameterübergabe und Global  Control (also Broadcastbefehle an alle Slaves gleichzeitig) verwendet.



Es gibt auch noch die Varianten FMS und PA, die könntest
Du der Vollständigkeit halber erwähnen.

https://de.wikipedia.org/wiki/Profibus



AlexSc schrieb:


> Könnte jemand mal ein etwas umfassenderes Beispiel liefern, wie nun SPS, Endgeräte und PROFIBUS tatsächlich zusammen wirken?



Beim Aufzug hast Du das schon ganz gut geschrieben. Statt jeden
Taster, Sensor und Motor direkt mit der SPS zu verbinden, kommt
dezentrale Peripherie zum Einsatz. Der Umrichter zu Motorsteuerung
kann ebenfalls per Profibus angebunden werden.

Beispiel:

http://w3.siemens.com/mcms/sce/de/f...documents/feldbussysteme/d07_cpu315_micro.pdf

Bezüglich der Sicherheit – nur ein funktionierender Feldbus ist 
sicher – könntest Du noch die Themen Alterung und EMV erwähnen.

Dazu habe ich kürzlich hier etwas geschrieben:

http://www.openautomation.de/detailseite/bussysteme-als-stiefkind-der-instandhaltung.html

und hier:

https://www.keosk.de/read/JHAd63UDFKeNj/m.html?page=27


----------



## AlexSc (11 Juli 2015)

Guten Abend,

vielen Dank für die vielen Informationen!

@Bernard Bäurle:
Danke für die ausführliche Antwort, das Profibus Handbuch von Max Felser kenne ich bereits und habe auch den Großteil meines Wissens daher. Profibus PA und FMS kenne ich auch, in meiner Arbeit geht es aber ausschließlich um DP.
Nun möchte ich meine Fragen mal etwas konkretisieren. Es geht mir bzgl. 'Sicherheit' vor allem um die Sicherheit vor gezielten Angriffen und Manipulationen. Da ich zwar viel Wissen durch Lesen und Lernen erhalten kann aber im Rahmen meiner Arbeit niemals ein echtes Industriesystem zu Gesicht bekommen werde, habe ich absolut keine Erfahrung mit diesen Systemen. In wiefern stellen die angeschlossene Geräte an sich Funktionalität in diese Richtung?
- Was passiert, wenn ich einen Master (der evtl auf einer Seite via Industrial Ethernet an ein größeres Netz angeschlossen ist) übernehme und plötzlich fremde Slaves anspreche?
- Was passiert, wenn ich wahllos Adressen ändere? Wenn ich das Token nicht weiterreiche oder außerhalb meiner Zeit Slaves anspreche? Halten die Slaves selbst auch fest, wer das Token hat und reagieren im Notfall einfach garnicht?
- Dann nochmal zu meiner alten Frage: Während des azyklischen Datenaustauschs liest die SPS alle Eingänge der jeweiligen Slaves und schreibt deren Ausgänge, und MEHR definitiv nicht?
- Was kann denn noch so über den Profibus laufen also welche Art von Datenverkehr kommt da überhaupt zustande (außer dem Datenaustausch, Konfiguration, Master-Master) und dürfen manche Vorgänge evtl. nur beim Hochfahren des Systems erfolgen?
- Das FDL Protokoll und die DP-V0 bis DP-V2 Protokolle sind ja relativ eng miteinander verbunden, jedenfalls nicht so klar voneinander zu trennen wie ein IP und ein TCP Paket. Wie bauen darauf nun die Profile auf, also welche Funktion haben die genau? Ich hab das nun so verstanden, dass Profile für bestimmte Branchen (zB. die Automobilindustrie) etwas detailliertere Standards definieren, also Funktionalitäten die da einfach häufig gebraucht werden. Ist das korrekt?

Ich bedanke mich nochmals im Vorraus für jede Hilfe und wünsche ein schönes Wochenende!
Liebe Grüße,
Alex


----------



## ChristophD (11 Juli 2015)

Hallo,

wir das jetzt eine Fortsetzung von diesem Thema: https://support.industry.siemens.com/tf/ww/de/posts/129472/ oder ein neues Projekt?

Welche fremden Slaves willst du den ansprechen? Die SPS kennt nur die projektierten Slaves aud den SDB Daten und nur mit denen kann sie auch kommunizieren.
Welche Adressen willst du ändern? DP Adressen werden in der Regel bei PROFIBUS an den Geräten die als DP-Slave arbeiten direkt eingestellt, sowas wie DHCP beii Ethernet gibt es nicht bei PROFIBUS.
Die Eingänge/Ausgänge werden eigentlich im zyklischen Bereich gelesen im azyklischen Bereich sind eher Diagnoseaufträge wie Paremeter Lesen/Schreiben, Status der Slaves etc. zu finden.
Bei den Profilen meinst Du vermutlich PROFIdrive und PROFIsafe, diese beiden definieren eigentlich lediglich als Standard den Aufbau der Daten die ausgetauscht werden, also wie die Telegramme aufgebaut sind und welche Bedeutung die einzelnen Daten im Telegramm haben.

Gruß
Christoph


----------



## AlexSc (11 Juli 2015)

Guten Abend,

eine Fortsetzung sollte das eigentlich nicht werden, allerdings habe ich mich (wie du nun auch im Siemens Forum nachlesen kannst  ) mit der Programmierung einiger Softwarekomponenten meiner Arbeit beschäftigt.
Soweit ich weiß, können Master mittels eines SET_ADDR Befehls Adressen von Slaves selbst bestimmen. Mit fremden Adressen meine ich im Multimasterbetrieb zB. folgende Situation:
Master 1 hat die Slaves 1, 2 und 3
Master 2 hat die Slaves 4, 5 und 6
Was hält M1 nun davon ab mit S4 oder S6 zu sprechen und wenn, wie wird das geregelt?

Wie gesagt mir fehlt es einfach völlig an Erfahrung, darum sind manche Fragen vielleicht sogar völlig 'sinnlos', mit jeder Antwort helft ihr mir aber enorm! Allgemein, was könt ihr euch für Sicherheitslücken in solchen Systemen vorstellen bzw. wie stark sind slolche Systeme gegen Missbrauch geschützt?
Darum geht es mir und wie sich solche Missbräuche zeigen würden sodass man sie aufdecken und evtl. verhindert könnte?

Liebe Grüße,
Alex


----------



## ChristophD (11 Juli 2015)

Hallo,

da M1 in seinen SDB keine Kenntniss hat von S4 und S6 kann er nicht mit diesen kommunizieren.
Bevor ein Slave in den Datenaustauch mit einem Master eintritt benötigt er ein güldiges PRM_CFG Telegram, dieses bildet der Master aus den SDB und verschickt es auf den Bus an die Slaves.
Wird diese PRM_CFG Telegram vom Slave akzeptiert findet der Datenaustausch statt.
Man müsste dann also auf Systemebene des Masters die SDB's manipulieren, das wiederrum erfordert dann einen Restart des Masters da die SDB beim hochfahren des masters ausgewertet werden.

Gruß
Christoph


----------



## AlexSc (11 Juli 2015)

Ok dann soweit schonmal. Aber was ist, wenn ich als Master einfach beliebig Adressen ausprobiere? Oder noch besser, da ich an ein Bussystem angeschlossen bin kann ich sowieso jedes Telegramm mitlesen und alle Adressen speichern. Je nachdem von wo die Requests und von wo die Responses kommen weiß ich dann ja auch wer Master und Slave ist, was übertragen wurde etc.
Mal ein Beispiel:
In einem super futuristischen Gebäudekomplex (wird warscheinlich heute schon genau so gemacht  ) ist in jedem Raum ein Rauchsensor mit einer Sprenkleranlage verbunden (natürlich über PROFIBUS). Parallel dazu ist in jedem Raum noch eine Klimaanlage, welche aber von einer für das ganze Gebäude zentralen SPS gesteuert wird. Dann wäre M1 die Klima SPS die zyklisch mit einem Temparatursensor und dann mit allen Klimaanlagen spricht. M2 wären die jeweils im Raum instalierten SPSen, die nur mit Rauchmelder und Sprenkleranlage sprechen. Wenn nun aber M1 und M2 sowie alle Slaves aus welchen Gründen auch immer an den selben Bus angeschlossen sind und ich nur eine Klima SPS (also Master 2) ganz stupide gesagt 'gehackt' habe.
Was hindert mich daran, den Verkehr ein bisschen zu analysieren bis ich mir sicher bin, wer M1 ist und dann einfach im Namen von M1 selbst Telegramme zu schicken (zB schalte alle Anlagen aus). Oder anders rum, warum kann M1 nicht allen Sprenkleranlagen den Befehl geben, Wasser auszusprühen?
Dass das nicht sein SOLLTE ist mir klar, aber gibt es irgendwelche aktiven Maßnahmen dagegen?

Liebe Grüße,
Alex


----------



## ChristophD (11 Juli 2015)

Hi,

damit verlässt du bei diesem konstruierten Beispiel die PROFIBUS Feldebene.
Um die Telegramme mitzulauschen oder auch nur alle Teilnehmeradressen mal auszuprobieren musst du auf den Profibus ASIC der Baugruppe aufschalten und den CODE der diesen steuert modifizieren, das wiederrum stellt einen Eingriff in die FW der SPS dar, dürfte schwierig bis werden das unbemerkt zu tun.

Wenn M1 die Rolle von M2 übernehmen würde dann würde zum einen M2 ausfallen was bemerkt werden würde und gleichzeitig würden alle Slaves die bisher von M1 angesprochen würden ausfallen da M1 nicht mehr existiert.

Und außerdem würde kaum einer ein solches Konstrukt wie du beschreibst realisieren 

Gruß
Christoph


----------



## AlexSc (11 Juli 2015)

Da haben wir doch schonmal ein grundsätzliches Verständnisproblem meinerseits. Ich bin bis dato davon ausgegangen, dass die SPSen via Profibus quasi 'direkt' an die Feldgeräte angeschlossen sind und auch eigenen Code tragen. Was ein ASIC ist weiß ich leider noch nicht.
Die Tatsache, dass bei einer falschen Nutzung des Profibusses alle beteiligten Geräte einfach ausfallen ist ganz sicher? Vielleicht ist das Verhalten ja nicht eindeutig definiert.


----------



## Thomas_v2.1 (12 Juli 2015)

Wenn ich das im Zusammenhang mit IT-Security lese, stellen sich mir ein paar generelle Fragen:
Für Hobby-Hacker ist Profibus uninteressant, weil spezielle und entsprechend teure Hardware dafür notwendig ist. Wer sollte also ein solches Netzwerk manipulieren wollen? Das können nur staatliche Organisationen sein, wie z.B. die USA/NSA mit quasi unendlichem finanziellen Potenzial, bei denen auch ein Menschenleben nichts wert ist.

Man könnte einen Angriff wie Stuxnet im Iran ja mal auf Profibus-Ebene durchspielen. D.h. das Steuerungsprogramm bekommt manipulierte Daten der Profibusteilnehmer zu Gesicht. Im Fall Stuxnet wurde das über eine Manipulation des Steuerungsprogramms realisiert. Mit einer entsprechenden Person mit Zugriff auf die Hardware ließe sich durchaus hinter dem Master ein Gerät zwischenschalten, dass ggf. dem Master die gesamten Slaves vortäuscht oder zumindest dessen Daten manipuliert (an Datenmanimpulation wurde beim Design von Profibus nicht gedacht). Dazu könne man beispielsweise einen Repeater oder LWL-Konverter ge(miss)brauchen. Technisch ist das mit entsprechendem finanziellen Aufwand kein Problem. Bei allen Ethernet-Geräten aus den USA kann man mittlerweile von entsprechenden Backdoors ausgehen die Funktionen beinhalten um den Datenverkehr abzuhören und ggf. zu manipulieren. Das würde dein Analyse-Gerät nicht mitbekommen, dass dort so ein Gerät verbaut ist.
Ich habe von anderen universitären Einrichtungen aus dem Ausland (Frankreich, Israel) mitbekomen, die das gleiche wie du vorhaben, allerdings auf Ethernet-Ebene. Da gibt es auch entsprechende Vorlesungen im Internet.

Das Problem ist eigentlich kein technisches, sondern ein politisches. Bei uns werden höchste Regierungsstellen vollständig abgehört ohne dass etwas dagegen unternommen wird.


----------



## AlexSc (12 Juli 2015)

Guten Morgen,

genau, an solche Sachen habe ich auch gedacht. Dass ein Skriptkiddie was besseres zu tun hat, als ein Profibus Netz anzugreifen ist klar, da braucht es schon größere Organisationen.
Der Kontext meiner Arbeit ist ein Forschungsprojekt des IT Security Unternehmens in dem ich die Arbeit anfertige. Da dieses Projekt hier relativ neu ist und ich quasi Pionierarbeit leisten darf, sind wir uns alle noch nicht ganz sicher in welche Richtung das laufen wird. Hinzukommt die Nichtverfügbarkeit eines echten Netzes.

Wo genau hast du Informationen zu den Projekten aus Frankreich und Israel her? Kannst du mir da evtl. ein paar Links geben?

Da die Art von Software die ich entwickeln möchte ja prinzipiell immer davon ausgeht, dass Angriffe auf das System sich durch signifikant abweichenden Datenverkehr detektieren lassen (andere kann ja selbst das beste IDS beim besten Willen nicht aufspüren), ist mein Vorgehen bisher die mitgelesenen Pakete bestmöglich zu 'entpacken' (also möglichst viele enthaltene Daten für den Anwender aufzubereiten) und verschiedene statistische Tests darüber laufen zu lassen. Als Beispiel sei mal der Chi Quadrat Homogenitätstest genannt. Der ermittelt für zwei Stichproben, ob sich die die Verteilungsfunktion der beiden Stichproben signifikant verändert hat. Sowas könnte man dann ja als Anomalie werten. Weitere Möglichkeiten wären Mittelwert und Standardabweichung verschiedener numerischer Größen.
Auch hier bin ich natürlich immer für Ratschläge offen!

Liebe Grüße und einen schönen Sonntag,
Alex


----------



## Thomas_v2.1 (12 Juli 2015)

Du kannst dir diese beiden Sachen ja mal ansehen, dürfte so ungefähr dem entsprechen was du auf Profibus-Seite vorhast, wenn ich das richtig verstanden habe.

Accurate Modeling of The Siemens S7 SCADA Protocol For Intrusion
Detection And Digital Forensic, Amit Kleinmann, Avishai Wool
http://ojs.jdfsl.org/index.php/jdfsl/article/view/262

Vorlesung dazu:
https://www.youtube.com/watch?v=qRuIspqnl_Q


----------



## manseluk (13 Juli 2015)

Nebst Profibus gibt es ja noch andere Bussysteme, z.B. Can-Bus (wird häufig in Autos verwendet). Dieser Bus wurde / wird häufig "gehacked" und im Internet findest du mit Begriffen "can-bus" und "hack" viele Tutorials, wie dies gemacht wird. Evenutell kannst du Methoden, die dort verwendet werden, auf Profibus übertragen.


Gruss


----------



## ducati (13 Juli 2015)

AlexSc schrieb:


> Dass ein Skriptkiddie was besseres zu tun hat, als ein Profibus Netz anzugreifen ist klar, da braucht es schon größere Organisationen.



 Wie immer hat Thomas hier schon mal alles richtige erwähnt 
Genau wie eine Firewall am PC könnte m.M. nach ein PB-IDS-System höchstens Scriptkiddies abhalten...
Einen hochqualifizierten Angreifer mit unbegrenzten Mitteln und Insiderwissen wird das nicht aufhalten können.

Zu Eurem theoretischen Ansatz am Schreibtisch würde ich sagen: Baut Euch mal ein SPS-System auf. Das kostet nicht die Welt und Ihr werdet leicht erkennen, an welcher Stelle der Kette Programmiersystem-SPS-Profibus-DP-Feldgerät realistische Angriffsmöglichkiten bestehen. (Für mich hört sich das hier so ähnlich an wie: Ich hab eigentlich keine Ahnung von nem PC und hab auch noch nie einen gesehen. Im Buch hab ich jetzt aber gelesen, wie ein PC funktioniert und möchte jetzt mal einen Virenscanner mit Firewall programmieren...) Aber das ist leider (zu) oft bei Abschlussarbeiten so.

Das Beispiel mit den zwei Mastern M1 und M2 welche sich ein PB-Netz teilen finde ich ziemlich konstruiert und unrealistisch. In der Praxis hat jede SPS in der Regel sein eigenes physikalisches PB-Netz, u.U. noch mit nem PG/OP dran.

Die Idee von Christoph, die Firmware der SPS zu manipulieren (bzw. werksseitig vorhandene Backdoors?) um unerkannt die Anlage zu stören hört sich allerdings gar nicht so abwegig an.

Gruß.


----------



## AlexSc (13 Juli 2015)

Guten Morgen und vielen Dank für die ausführliche Antwort!

hier ein SPS System aufzubauen wird leider nicht möglich sein. Dies liegt vor allem daran, dass ich nur als Praktikant angestellt bin (und in diesem Rahmen die BA schreibe) und der Umfang den es braucht, so ein System vollständig zu verstehen, die Teile zu beschaffen und ein korrekt funktionierendes Profibus Netz aufzubauen quasi selbst schon als (kleine) BA gewertet werden könnte.
Dazu kommt dann noch, dass ich zwar noch nicht in Verzug bin, jetzt aber noch ein SPS System aufzubauen leider zeitlich einfach nicht mehr passt.

Ich sehe meinen Vorteil momentan noch darin, dass ich ja von vorne herein nicht angestrebt habe, jeden Angriff von tatsächlich professionellen Hackern aufzudecken (und ich denke, nicht mal die meisten Dissertationen in diese Richtung würden das schaffen) sondern lediglich die Angriffe, welche eine statistisch signifikante Änderung im Datenverkehr hinterlassen.
Wie nun ein Angreifer Zugriff zum System erhält ist ja "erstmal" unwichtig für mich. Fängt er aber an, den Datenverkehr zu stören, könnte sich das in Übertragungsfehlern, insgesamt höherem Datenverkehr oder Rekonfigurationsvorgängen äußern.
Beobachtet man die Häufigkeiten solcher Ereignisse über einen längeren Zeitraum, ließe sich mit den richtigen Tests so etwas aufdecken.
Zumindest ist das meine Hoffnung 
Außerdem ist ein weiterer großer Vorteil meiner Software, dass sie extrem leicht zu erweitern sein wird, was eventuellen Anwendern später die Wahl lässt, selbst statistische Module für das System zu schreiben und ala Plug and Play sofort zu erweitern.

Leider hast du Recht, mit deinem Beispiel zum PC und dem Virenscanner/Firewall  Konnte mir das Thema nicht aussuchen und versuche nun, das Beste daraus zu machen!
Vielen Dank an alle nochmal für die Hilfe!

Liebe Grüße,
Alex


----------



## ChristophD (13 Juli 2015)

Hi,

1) bisher dachte ich ja das es am Ende ein in der Praxis verwendbares Endprodukt werden sollte
2) Datenverkehr stören ist die mit Abstand seltenste Angriffsmethode bei SPS, sobald das passiert wird die Anlage abgestellt und isoliert, Störungen sind heute schon diagnostizierbar !
3) Hauptproblem ist nicht die Störung sondern die Verfälschung von Daten, sprich das Datenvolumen selber ändert sich nicht aber die Werte z.B, werden modifiziert, so das z.B. Stellgrößen geändert werden ,
    Das betrachtest du aber wohl gar nicht, zumindest lese ich immer nur heraus das du nur eine Abweichung der Datenströme an sich analysierst, also wie viele Daten innerhalb einer bestimmten Zeit zwischen 2 Teilnehmern ausgetauscht 
    werden. Nur wird das wohl eher selten der Fall sein bei einem SPS Feldbus, siehe auch Stuxnet.

Eventuell verstehe ich auch einfach den theoretischen Ansatz für das ganze Thema nicht, aber ich finde es falsch einfach die IT Security von Ethernet auf einen SPS Feldbus runterbrechen zu wollen.
Aber wie willst du alle eventuell gefunden Theorien und Erkenntnisse den ohne einen Aufbau überhaupt prüfen? Und in der ganzen Firma ist kein Profibus- Aufbau vorhanden bei dem Du z.B. die Telegramm erfassen und auswerten kannst?
Alleine die erwähnten reconfigurations würden schon für ein Alarmsignal beim Anlagenbetreiber sorgen da sie in der Regel mit Stations und Bus ausfällen einhergehen die auch mitgeloggt werde in der SPS, eventuell sogar zu einem SPS Stop führen wenn dieser Fall nicht über FehlerOB's abgefangen wird in der Programmierung.

Gruß
Christoph


----------



## norustnotrust (13 Juli 2015)

Es gibt ja solche Heuristiken die auf PC Ebene versuchen gewünschtes von unerwünschtem Verhalten zu trennen und zu identifizieren. Meiner Erfahrung nach für das eher zu mehr Störungen als das es einem hilft und endet damit dass man bestimmte Programme (oft die mit denen man als Automatisierer arbeitet) von der Suchfunktion ausnehmen muss da diese Dinge machen die für einen Office PC per se verdächtig sind (Direktzugriffe auf Peripherie, etc..) Ich frage mich also generell ob das funktionieren kann.

Aber abgesehen davon folender Gedanke: Das Einfallstor für deinen "Hacker" wird nicht der Profibus selbst sein. Will der "Hacker" deinen Datenstrom auf dem Bus manipulieren bräuchte er ein Gerät das er physisch im Schaltschrank anbringt was A.) einen enormen Aufwand bedeutet und B.) für die genannten staatlichen Stellen das Risiko einer Entdeckung ungleich steigern würde. Bleibt also der Weg (wie Stuxnet) einen PC zu infizieren der Pakete an den Bus sendet. Wenn diese Software manipuliert wird, wird sie per se keinen verdächtigen Traffic produzieren bzw. keinen den du als solchen erkennen wirst können. Wieso auch?

Es bleibt also der einzige Weg (siehe Versiondog) die PLC Programme und die PC auf geänderte Softwarestände von dritter Stelle abzufragen.

Zusammengefasst also: halte diese "Hacker" Detection Heuristik auf dem Profibus für vergebene Liebesmühe.

EDT: Tippfehler


----------



## norustnotrust (13 Juli 2015)

Ich will ja jetzt nicht unnötig reintrollen und den TE anzipf'n aber mir fällt gerade bei so "Heimprojekten" immer wieder ein ähnlicher Mechanismus auf. Wann immer eine Software daran scheitert das zu leisten was sie leisten soll erklärt man einfach:



AlexSc schrieb:


> Außerdem ist ein weiterer großer Vorteil meiner Software, dass sie extrem leicht zu erweitern sein wird, was eventuellen Anwendern später die Wahl lässt, selbst statistische Module für das System zu schreiben und ala Plug and Play sofort zu erweitern



und hofft darauf dass irgendjemand seine eigene Baustelle fertig baut. So als wäre es die größere Herausforderung einen Programmrumpf zu schaffen der dann die "Technologiemodule" aufnimmt.

Das ist keine Kritik an dir sondern ich denke dass deine obskure Aufgabenstellung weit weit über die Möglichkeiten eines BA's hinausgeht und daher von Anfang an zum Scheitern verurteilt ist. Ich meine je nach dem was dein Schwerpunkt ist wäre es doch viel  gewinnbringender für alle Beteiligten etwas zu machen was beherrschbar  ist und dennoch wichtige Aspekte der Ausbildung beinhaltet wie z.B. einen einfachen PB Master (oder Slave) zu schreiben oder einen einfachen PB Analysator zu machen. Da hast du auch alle Themen eines Bussystems und einen praktischen Teil auch drinnen.

Ich denke das Problem bei vielen BAs ist, dass man als Student/Betreuer/Studieneinrichtung gerne etwas Besonderes schaffen möchte (um sein eigene Reputation an hochtrabenden PP Präsentationen zu pushen) um im Endeffekt oftmals grandios daran scheitert anstatt einfach sich auf was konzentriert was sinnvoll und machbar ist. Dieses Thema das du da beschreibst kann sicher für einen Dissertanten ein interessantes Gebiet sein auf dem man forscht (wobei ich die Sinnhaftigkeit auch da nicht ganz sehe, aber das heißt ja nicht viel) aber für eine BA? Was lernt man als Student dabei? Mach halt irgendwas, hauptsache du kannst es danach schönargumentieren? Das Arbeitsergebnis ist egal hauptsache du präsentierst es gut? Der Prozess ist wichtiger als das Ergebnis?

Ich verstehe es echt nicht...


----------



## AlexSc (13 Juli 2015)

Hi,

wie immer zuerst danke für alle Antworten!

@ChristophD: Nein du verstehst das nicht falsch, abgesehen davon, dass ich als Bachelorarbeit wohl kaum ein fertiges (also marktreifes) Tool entwickeln kann 

Zum Thema:
Ich denke, ich habe meine Gedanken noch nicht ausreichend erläutert. Dass ein Angriff mehr Traffic erzeugt oder Geräte direkt abschaltet (was euch zufolge ja sofort bemerkt würde) ist auch nur ein Aspekt auf den man den Datenverkehr prüfen könnte (also zu prüfen, ob die Gesamtzahl an Bytes in einem Zeitraum von x Minuten um mehr als y Prozent abweicht oder ob plötzlich bestimmte Adressen nicht mehr angesprochen werden...).
Wenn ich tief genug in das Protokoll hineingehe das an einer bestimmten Stelle verwendet wird, kann ich ja auch beobachten, welche Werte als PARAMETER für andere Geräte übergeben werden.

Ein Beispiel: Beobachte die Stellgrößen für die Geräte X1 .. X5. Dann hätte man folgende Beobachtungsdaten (die später auch beliebig variiert werden können):
1. ( 17, 34, 21, 9, 19)    Gerät X1 hat den Wert 17, Gerät X2 den Wert 34, etc.
2. ( 15, 33, 20 ,10 ,22)   ...
3. ( 16, 30, 22, 12, 20)   ...
...
Da die Daten nun unmittelbar von den Übergebenen Werten an Slaves abhängen könnte sogar ein Stuxnet Angriff damit (natürlich nur in der Theorie) aufgedeckt werden.
Genau darauf liegt ja auch mein Fokus, dem statistischen Analysieren von bereits vorhandenen Daten. Ich mache das quasi extra, noch Methoden zur Datenbeschaffung und Aufbereitung zu stellen.
Selber für jede Art von PROFIBUS Version die den verschiedensten Anlagen unterschiedlich eingesetzt wird einen Parser zu schreiben ist hier nicht meine Aufgabe, jedoch erlaubt mein System später einem Benutzer diese Funktionalität maximal einfach selbst mit einzubringen.

Liebe Grüße,
Alex


----------



## norustnotrust (13 Juli 2015)

1.) Wieso sollte ein infizierter Master Slaves nicht mehr apsrechen?
2.) Wie willst du feststellen ob ein Sollwert bösartig geändert wurde oder gutartig?


----------



## ducati (13 Juli 2015)

norustnotrust schrieb:


> Ich denke das Problem bei vielen BAs ist, dass man als Student/Betreuer/Studieneinrichtung gerne etwas Besonderes schaffen möchte (um sein eigene Reputation an hochtrabenden PP Präsentationen zu pushen) um im Endeffekt oftmals grandios daran scheitert anstatt einfach sich auf was konzentriert was sinnvoll und machbar ist. Dieses Thema das du da beschreibst kann sicher für einen Dissertanten ein interessantes Gebiet sein auf dem man forscht (wobei ich die Sinnhaftigkeit auch da nicht ganz sehe, aber das heißt ja nicht viel) aber für eine BA? Was lernt man als Student dabei? Mach halt irgendwas, hauptsache du kannst es danach schönargumentieren? Das Arbeitsergebnis ist egal hauptsache du präsentierst es gut? Der Prozess ist wichtiger als das Ergebnis?
> 
> Ich verstehe es echt nicht...



Jo, wie ich es verstehe, hört sich das für mich auch eher nach einer Dissertation an!

Aber Forschung an sich ist ja erstmal nichts schlimmes, nur selten kommt leider was verwendbares dabei heraus...

Wie funktioniert das heute? Ne Uni oder Firma denkt sich ein Forschungsthema aus und beantragt Forschungsgelder. Darüber werden dann BAs oder was auch immer bezahlt. Wenn was rauskommt ist gut, wenn nicht ist auch egal...
Statistik ist seit einiger Zeit ein Modethema. Es wird versucht, sie für alles Mögliche einzusetzten.

Ich war vor einiger Zeit mal an nem Forschungsthema beteiligt bei dem mittels Statistik eine Diagnose von Automatisierungsanlagen durchgeführt werden sollte. Also man nimmt die Archivdaten einer Anlage lässt die offline durch nen "statistischen Algorithmus" laufen und erzeugt daraus nen Algorithmus welcher ONline die Anlage beobachtet und bei Fehlern "Alarm" schlägt. (das ganze war übrigens ne Dissertation von nem Kollegen)

Hier im Forum laufen aber so viele Praktiker herum, die sich an mehr als 10 Finger abzählen können, warum sowas in der Praxis nur sehr schwer einzusetzen ist. Dem Forschungsprojekt ist das aber egal. Irgendjemand sagte mal zu mir, nur jedes 10. Forschungsprojekt schafft es in die Praxis. Und wieviele davon sinnvoll sind, steht nochmal auf nem anderen Blatt.

@TE: lass Dich nicht entmutigen und mach das beste draus. Für die BA-Arbeit ist nicht entscheidend, obs funktioniert, sondern wie Du die "These" untersucht hast und wie Dus un der Arbeit formuliert hast.

Gruß.


----------



## ChristophD (13 Juli 2015)

Hi,

und wer sagt Dir das die Werte immer im gleichen Muster , immer konstant in der gleichen Sequenz ablaufen?
Ne Ne wir sprechen hier von Regelkreisen, sprich da werden aufgrund der gsamten Maschinenabläufe die unterschedlichsten Werte zu unterschiedlichen Zeiten an die unterschiedlichsten Slaves verschickt.
Das ist doch kein binäres System was da nur ein und aus hin und her schubst.
Das einzige wo du mit dem Erfolg hast was du vorhast ist ein Laboraufbau wo genau definierte Werte zu genau definierten Zeiten zu genau definierten Empfängern von genau definierten Sendern laufen und das kannst dann überwachen.
Aber das hat nicht wirklich einen Sinn, solch eine Anlage gibt es quasi nicht!

Dann kommt noch hinzu das quasi jeder Hersteller auch gerne seine eigene Suppe kocht was die Daten in den Telegrammen angeht, sprich was sind die relevanten Daten zur Ansteuerung, Sollwerte, Freigaben etc.
Da darfst du dann für jeden Slave eine Telegrammschablone nehmen und individuell auf die Anlage anpassen.

Gruß
Christoph


----------



## norustnotrust (13 Juli 2015)

Ein einfaches Beispiel:

Ein Sollwert X ist 5 Monate 10 % und dann plötzlich 30%. Ist es ein Virus oder nur ein warmer Tag?


----------



## ducati (13 Juli 2015)

norustnotrust schrieb:


> 2.) Wie willst du feststellen ob ein Sollwert bösartig geändert wurde oder gutartig?



Der Statistik ist das egal. Man schaut sich halt die Vergangenheit an und entwickelt daraus einen mehr oder weniger guten Online-Beobachter. Wie gut oder schlecht das funktioniert hängt vom verwendeten Algorithmus und von den Archivdaten ab. Wenn sich die i.O. Archivdaten signifikant von den manipulierten Onlinedaten unterscheiden funktionierts. Ansonsten nicht. Nebenbei erzeugen die Algorithmen auch keine 100%ige Erkennungsraten, sondern auch nur eine Erkennungswahrscheinlichkeit. Statistik halt 

Gruß.


----------



## ducati (13 Juli 2015)

AlexSc schrieb:


> Wenn ich tief genug in das Protokoll hineingehe das an einer bestimmten Stelle verwendet wird, kann ich ja auch beobachten, welche Werte als PARAMETER für andere Geräte übergeben werden.
> 
> Ein Beispiel: Beobachte die Stellgrößen für die Geräte X1 .. X5. Dann hätte man folgende Beobachtungsdaten (die später auch beliebig variiert werden können):
> 1. ( 17, 34, 21, 9, 19)    Gerät X1 hat den Wert 17, Gerät X2 den Wert 34, etc.
> ...



In die Profibusdiagnose noch zusätzlich eine Prozessdiagnose einzubauen finde ich allerdings sportlich 

Wieviele Bytes an Nutzdaten können eigentlich maximal pro Zyklus im PB übertragen werden? Jedenfalls viele. Die in Echtzeit statistisch zu analysieren ist vermutlich ebenfalls sportlich.


----------



## norustnotrust (13 Juli 2015)

ducati schrieb:


> Der Statistik ist das egal.



Das heißt jedes Mal wenn du einen Button drückst bekommst du einen Alarm! Außer du bemühst dich und drückst den Button nur jeden Tag um 07:43. . Also ich bin mir recht gut darüber im Klaren was Statistik leisten kann aber das kann nicht funktionieren (= einigermaßen verläßlich bösartige Änderungen erkennen und gutartige ignorieren)

Ode rlass mich mal folgenes Szenario bemühen: Nehmen wir mal an dein heuristischer Superalgorithmus kann das alles. Wie lange braucht er um verlässliche Aussagen treffen zu können. An den Stellgrößen der Anlagen die ich kenne sind fast immer klimatische Elemente in irgendeiner Art und Weise beteiligt. Also braucht er ein Jahr (plusminus) zum lernen. Oder lassen wir das mal weg und sagen optimistisch 3 Monate Daten reichen aus. Das heißt nach jeder Programmänderung, Rezeptänderung, Änderung des Materialeingangs, der Chargengröße, des Produktes usw... funktioniert er 3 Monate schlechter als sonst? Bei wie vielen Anlagen habe ich den Fall dass all diese Komponenten stets gleich bleiben? 
Mal abgesehen davon dass dieser "Teaching Modus" auch wieder ein Einfallstor für den Virus ist, denn wenn er böse ist aktiviert er diesen ganz einfach.


----------



## ducati (13 Juli 2015)

@ NRNT Dass das alles gut funktioniert hab ich ja nicht behauptet  Dazu bin ich zu viel Praktiker um die gleichen "Probleme" zu sehen wie Du. Das hindert aber die Theoretiker nicht, Forschungsanträge zu stellen. Und Statistik ist da grad IN. Und irgendjemand muss es dann bearbeiten. 

Gruß.


----------



## AlexSc (14 Juli 2015)

norustnotrust schrieb:


> ...und hofft darauf dass irgendjemand seine eigene Baustelle fertig  baut. So als wäre es die größere Herausforderung einen Programmrumpf zu  schaffen der dann die "Technologiemodule" aufnimmt.


Nunja, sobald man im Zuge einer Abschlussarbeit auch ein  Stück Software entwickeln muss, muss man sich auch immer überlegen in  wie weit diese einsetzbar sein soll (abgesehen davon, dass man sich  natürlich zuerst Gedanken darber machen sollte, WAS die Software  eigentlich leisten soll). Nun habe ich mich entschieden, eine Software  zu schreiben, die sowohl PROFIBUS Netztraffic rudimentär parst (FDL wird  mittlerweise vollständig verstanden, an den DP Versionen bin ich dran)  und anhand der aufbereiteten Daten sogenannte "Beobachtungen" anfertigt.  Eine Beobachtung sieht bei mir z.B. so aus (und kann auch beliebige andere Formen annehmen):
- Einer Funktion, welche jedem  Paket eine Klasse zuweist (z.B. "Stellwert viel zu klein", "Stellwert  leicht unter normal", "Stellwert normal", etc.)
- Einer Anzahl von  Datensätzen in der nach der obigen Klassifizierung absolute Häufigkeiten  gezählt werden. Für die obige Klassifizierungsfunktion könnte das so  aussehen
(0, 3, 20, 2, 0)
(0, 2, 22, 1, 0)
(0, 0, 25, 0, 0)
...
- Die Anzahl der Pakete die in einen Datensatz mit aufgenommen werden (in diesem Fall immer 25)
Die  Klassifizierungsfunktion ist denkbar einfach geschrieben und es könnten  auch beliebige weitere von jedem erstellt werden, der 3 Stunden Python  programmiert hat. DAS meine ich mit einfacher Erweiterbarkeit. Natürlich  kann auch ein Statistikprofessor kommen und die Häfte des Systems neu  entwerfen (ginge tatsächlich, aber das ist Nebensache) aber voll allem  soll der Admin eines Netzwerk das vorhandene System möglichst gut auf  seine Bedüfnisse anpassen können. Das ist ja auch unter anderem ein  vorgegebener Schwerpunkt der Arbeit.



			
				norustnotrust schrieb:
			
		

> Das ist keine Kritik an dir sondern ich denke dass deine obskure  Aufgabenstellung weit weit über die Möglichkeiten eines BA's hinausgeht  und daher von Anfang an zum Scheitern verurteilt ist. Ich meine je nach  dem was dein Schwerpunkt ist wäre es doch viel  gewinnbringender für  alle Beteiligten etwas zu machen was beherrschbar  ist und dennoch  wichtige Aspekte der Ausbildung beinhaltet wie z.B. einen einfachen PB  Master (oder Slave) zu schreiben oder einen einfachen PB Analysator zu  machen. Da hast du auch alle Themen eines Bussystems und einen  praktischen Teil auch drinnen.
> 
> Was lernt man als Student dabei? Mach halt irgendwas, hauptsache du  kannst es danach schönargumentieren? Das Arbeitsergebnis ist egal  hauptsache du präsentierst es gut? Der Prozess ist wichtiger als das  Ergebnis?
> Ich verstehe es echt nicht...


Mal anders rum, was können schon Lernziele in einer BA sein? Verständnis  eines bisher unbekannten Systems, neuer Algorithmen die evtl. über das  bisherige Studium hinausgehen? Einrichten einer Testumgebung um gewisse  Daten zuerheben?
Um tatsächlich richtig neue Erkenntnisse zu  erhalten, welche dem aktuellen Stand der Forschung in entscheidender  Weise von Nutzen sein können braucht es wohl einiges mehr als einen  einzelnen Studenten und 3 Monate Arbeitszeit. An dieser Vorstellung  scheitern wohl viele, dem Gedanken da etwas wirklich neues und allerwelt  nützliches zu schaffen.
Ich habe bisher schon enorm viel gelernt. Um  nur die Themen anzureißen: das PROFIBUS Protokoll, allgemein Einsatz  und Funktion von Feldbussen, Grundlagen der Prozessautomatisierung,  Grundlagen der Intrusion Detection, statistische Algorithmen und deren  Anwendung in verschiedenen Fällen und nicht zuletzt auch einige neue  Erfahrung in der Programmierung eines halbwegs großen Softwareprojekts,  immerhin muss ich das ganze System selbst schreiben.



			
				norustnotrust schrieb:
			
		

> Ein Sollwert X ist 5 Monate 10 % und dann plötzlich 30%. Ist es ein Virus oder nur ein warmer Tag?


Ist  doch egal, selbst wenn es nur zu heiß ist, kann eine Abweichung von 20%  eines Sollwertes sicher nichts guten heißen. Wenn das niemand mitbekäme  hätte das sicherlich Folgen.. Und so eine Wertänderung kann definitiv  auch von einfachen statistischen Tests als signifikant eingestuft  werden.



			
				norustnotrust schrieb:
			
		

> Das heißt jedes Mal wenn du einen Button drückst bekommst du einen  Alarm! Außer du bemühst dich und drückst den Button nur jeden Tag um  07:43. . Also ich bin mir recht gut darüber im Klaren was Statistik  leisten kann aber das kann nicht funktionieren (= einigermaßen  verläßlich bösartige Änderungen erkennen und gutartige ignorieren)


Nur  wenn das Überwachungssystem schlecht eingestellt ist. Nur um das mal  klar zu stellen, es ist absoluter Grundsatz in diesem Forschungsbereich,  dass die Feinstellung eines solchen Systems IMMER dem Admin überlassen  werden muss und IMMER sau schwierig ist. Es geht auch stets nur darum  false positives zu minimieren, nicht sie komplett auszuschließen.
Ein  aus-dem-Hut Vorschlag von mir wäre jetzt, zeitbasiert das Datenprofil  zu ändern und bestimmte regelmäßige Ereignisse miteinzukalkulieren. Wie  gesagt, selbst für das weltbeste IDS lassen sich immer pathologische  Fälle konstruieren. Allein zu diesem Unterthema gibt es unzählige Doktorarbeiten.



			
				ChristophD schrieb:
			
		

> Dann kommt noch hinzu das quasi jeder Hersteller auch gerne seine eigene  Suppe kocht was die Daten in den Telegrammen angeht, sprich was sind  die relevanten Daten zur Ansteuerung, Sollwerte, Freigaben etc.
> Da darfst du dann für jeden Slave eine Telegrammschablone nehmen und individuell auf die Anlage anpassen.


Auch  hier nochmal, die Feinstellung muss jeder Admin selber übernehmen. Und  auch hier nochmal, DAS meine ich mit einfach zu erweitern, modular  aufgebaut, etc. Admins können nicht nur die vorhandenen Filter konfigurieren (also irgendwelche Werte in Konfigfiles anpassen) sondern zum Beispiel kleine (wirklich kleine, vielleicht 40 Zeilen Code) Plugins schreiben, die ein Paket nehmen und es anders klassifizieren. Das Plugin wird in das entsprechende Verzeichnis geschoben und funktioniert sofort. Damit ist eine weitere Sicht auf den Datenstrom gewonnen, welche dem Admin vielleicht sehr gefehlt hat, gedade weil jeder "seine eigene Suppe kocht".



> Oder lass mich mal folgenes Szenario bemühen: Nehmen wir mal an dein  heuristischer Superalgorithmus kann das alles. Wie lange braucht er um  verlässliche Aussagen treffen zu können. An den Stellgrößen der Anlagen  die ich kenne sind fast immer klimatische Elemente in irgendeiner Art  und Weise beteiligt. Also braucht er ein Jahr (plusminus) zum lernen.  Oder lassen wir das mal weg und sagen optimistisch 3 Monate Daten  reichen aus. Das heißt nach jeder Programmänderung, Rezeptänderung,  Änderung des Materialeingangs, der Chargengröße, des Produktes usw...  funktioniert er 3 Monate schlechter als sonst? Bei wie vielen Anlagen  habe ich den Fall dass all diese Komponenten stets gleich bleiben?
> Mal abgesehen davon dass dieser "Teaching Modus" auch wieder ein  Einfallstor für den Virus ist, denn wenn er böse ist aktiviert er diesen  ganz einfach.


Ja du hast recht mit all diesen Aussagen,  der Lernmodus kann unter anderem sehr lange dauern, ist nicht immer  zuverlässig, ein Virus könnte auch einfach das IDS ausschalten oder ein  Einbrecher könnte alle Kabel zum IDS kappen oder einfach die Anlage  sprengen. Es gibt immer Wege, ein IDS zu umgehen, gerade ein statistisch  basiertes. Niemand spricht davon, sowas als universelles Heilmittel  einzusetzen sondern nur, es in eine Reihe anderer Sicherheitstools  einzugliedern.


Mein Ziel ist es, ein (evtl. auch nur in einer konstruierten Umgebung) funktionierendes System zu entwickeln, dass  signifikante Änderung in beliebigen Teilen eines PROFIBUS Datenstroms  feststellen kann.
Zur Erweiterbarkeit habe ich denke ich genug  gesagt, ich selbst möchte für jede Funktion mindestens eine  Defaulteinstellung liefern UND die Möglichkeit, beliebig daran weiter  zuarbeiten. Inbesondere weil es hier im Unternehmen möglichst gut weiter  verwendet werden soll und ich nicht weiß, was spätere Mitarbeiter damit nun  genau vorhaben. Darum auch die Erweiterbarkeit auf allen Ebenen und  nicht weil ich keinen Bock hab, die schwierigen Sachen selbst zu  programmieren.


----------



## ChristophD (14 Juli 2015)

Hi,

aha der Admin machst, na super.
Welcher Admin bitte schön, wir sprechen hier von Industrie Anlagen, Werkzeugmaschinen, Verpackungsmaschinen , Walzwerke, Kraftwerk etc., die komplette Bandbreite wo theoretisch PROFIBUS als Feldbus eingesetzt wird.
Es gibt da in der Regel keinen Admin wie du dir das vorstellst, es geht sogar soweit das ein Maschinenhersteller das Komplettpacket aus SW und HW verkauft, der Kunde kriegt es geliefert und alles was er dann macht ist anschließen und einschalten und die Maschine tut, da ist nix mit Admin der noch Wochen-Monate.lang irgendwelche Statistikalgorithmen paramatriert.
Und welcher Admin bitteschön hat den Überblick für die in der Maschine hin und her schwierenden Telegramm, ihren Aufbau und Signalbedeutung? Selbst ein Maschinenhersteller hat das nicht, der projektiert seine Sachen zusammen und wie das auf dem Bus aussieht ist ihm doch erstmal sowas von egal.

Und weil dann auch jeder bereit ist sich für seine Maschine und seine Daten in Python was zusammenzuproggen damit er am Ende wenn er glück hat nur 50% false positiv bekommt?
Dir ist schon klar das auch bei IT Security irgenwann der Spaß aufhört wenn man überwiegend wegen "es besteht die Möglichkeit das..." Aktionen/Analysen losgejagt wird oder gar die Anlage deswegen abschaltet, weil es könnte ja sein das.

Im Unternehmen weiterverwenden ? In einem Unternehmen was nicht mal in der Lage seinem Praktikanten/BA einen einfachen Aufbau bereitzustellen wo er sich zumindest rudimentär mal Daten auf dem betrachteten Feldbussystem anschauen kann?

Wie hast Du Dir denn überhaupt die Erfassung der Daten vorgestellt, hängst du eine Busmonitor rein , wenn ja welchen? In welchem Format liegen die Daten vor, propitäres Format oder z.b. Excel?
Welche Erfassungszyklen sind angestrebt , wie wirken sich Netzeinstellungen und Übertragunszeiten auf die Erfassung aus? Erfolgt die Erfassung ohne Rückwirkung auf die Kommunikation?

Sorry so viel Du auch gelernt hast bisher das ganze geht immer mehr an der Praxis und somit Nutzen vorbei.

Gruß
Christoph


----------



## AlexSc (14 Juli 2015)

> aha der Admin machst, na super.


Ja, so läuft das nunmal bei einer Netzüberwachung.



> es geht sogar soweit das ein Maschinenhersteller das Komplettpacket aus  SW und HW verkauft, der Kunde kriegt es geliefert und alles was er dann  macht ist anschließen und einschalten und die Maschine tut, da ist nix  mit Admin der noch Wochen-Monate.lang irgendwelche Statistikalgorithmen  paramatriert.


Ah, also einfach kaufen, anschließen und dann wird es schon gut gehen. Und das bezeichnest du jetzt als sicher? Niemand redet von wochenlangem Parametrieren aber wer eine Anlage aufbauen will sollte doch zumindest grob einen Plan haben, welche Daten er über seinen Feldbus jagen will.



> Und welcher Admin bitteschön hat den Überblick für die in der Maschine  hin und her schwierenden Telegramm, ihren Aufbau und Signalbedeutung?


Wie gesagt, ich komme nicht aus eurer Branche aber wann sollte man bitte NICHT wissen, welche Daten durch das eigene Netz laufen? Gerade wo wir uns doch darüber unterhalten dass genau über dieses Netz Daten direkt zu Geräten gesendet werden können und diese damit unmittelbar beeinflussen.
Dann anders rum, sag mir mal welche Sicherheitsmechanismen es gibt, die sicherstellen, dass manipulierte Daten gefunden werden, wenn schon die Firmware einer SPS geknackt wurde (wie irgendwann vorher mal für Stuxnet beschrieben). Ist es tatsächlich gängige Praxis, dass in einer Anlage in der "Werkzeugmaschinen, Verpackungsmaschinen , Walzwerke, Kraftwerk etc." gesteuert werden nirgendwo darauf geachtet wird, welche Parameter von Punkt A zu Punkt B fließen?



> Und weil dann auch jeder bereit ist sich für seine Maschine und seine  Daten in Python was zusammenzuproggen damit er am Ende wenn er glück hat  nur 50% false positiv bekommt?


Wäre schön, weiter sachlich über das Thema zu reden. 50% false positives sind jenseits jeder Vorstellung, ich betone nochmals, dass ich nicht mit dem Tool reich werden will weil 100 mal besser ist als alle anderen aber da hier alle so unglaublich entrüstet auf die bloße Frage danach reagieren scheint es mir, als hätte man sich hier noch nie ernsthaft mit diesem Thema auseinander gesetzt...
Sich in Python etwas zusammen zu proggen ist evtl auch gar nicht nötig, wenn der Hersteller eines Geräts einfach von Haus aus soetwas unterstützen würde. Kann ja nicht so schwer sein die Sollwerte für die eigene Maschine zu kennen. Wenn ich einen Automotor verkaufe sag ich ja auch nicht "der läuft ab 13.000 Umdrehungen am besten".



> Im Unternehmen weiterverwenden ? In einem Unternehmen was nicht mal in  der Lage seinem Praktikanten/BA einen einfachen Aufbau bereitzustellen  wo er sich zumindest rudimentär mal Daten auf dem betrachteten  Feldbussystem anschauen kann?


Nein, in einem Unternehmen das das gesamte Thema (wie nun auch schon mehrfach erwähnt) lediglich als Forschungsprojekt startet und ich NOCH der einzige bin, der sich damit befasst. Hier als Praktikant quasi vorgeschickt zu werden um in eventuellen Sackgassen zu landen ist so betrachtet nicht sehr cool aber ich sehe es so, dass spätere Arbeiter in dieser Richtung dann schon mal einen groben Überblick haben, was machbar ist und was nicht. Dabei ist es dann mehr als natürlich einige 'blöde' Fragen zu stellen oder Vorstellungen zu haben, die in den Augen alteingesessener Ingenieure völlig utopisch sind.
Ich schreibe hier auch nur eine Bachelorarbeit, genau so gut hätten die mich in nen Raum setzen und sagen können "guck mal nach, die man Netzwerke ordentlich mit nmap scannt und gib ne sichere Konfiguration eines Netzes an auf dem folgende Dienste laufen sollen...".


----------



## ChristophD (14 Juli 2015)

> Ja, so läuft das nunmal bei einer Netzüberwachung.



Aber nicht auf Feldbusebene, das ist klassisch gesehen eben kein Netz was administrative Betreuung erfährt.



> Ah, also einfach kaufen, anschließen und dann wird es schon gut gehen. Und das bezeichnest du jetzt als sicher? Niemand redet von wochenlangem Parametrieren aber wer eine Anlage aufbauen will sollte doch zumindest grob einen Plan haben, welche Daten er über seinen Feldbus jagen will.



Ja genau so läuft es in der Regel ab, der Endkunde kauft die komplette Maschine und baut sie bei sich auf. Teilweise sogar ohne zu wissen was für Geräte in der Maschine genau verbaut sind. 
Es gibt klar auch Anlagen und Maschinen wo Maschinenbauer und Kunde gleich sind, da besteht auch ein größeres KnowHow über die "Innereien".
Ich habe nie behauptet das dies Sicher ist.
Sicherheit in der Automatisierung bzw. Sicherheit an einer Maschine in Betrachtung auf IDS/Manipulation/Hack ist heute "Häng das Ding nicht ans Internet"



> Wie gesagt, ich komme nicht aus eurer Branche aber wann sollte man bitte NICHT wissen, welche Daten durch das eigene Netz laufen? Gerade wo wir uns doch darüber unterhalten dass genau über dieses Netz Daten direkt zu Geräten gesendet werden können und diese damit unmittelbar beeinflussen.
> Dann anders rum, sag mir mal welche Sicherheitsmechanismen es gibt, die sicherstellen, dass manipulierte Daten gefunden werden, wenn schon die Firmware einer SPS geknackt wurde (wie irgendwann vorher mal für Stuxnet beschrieben). Ist es tatsächlich gängige Praxis, dass in einer Anlage in der "Werkzeugmaschinen, Verpackungsmaschinen , Walzwerke, Kraftwerk etc." gesteuert werden nirgendwo darauf geachtet wird, welche Parameter von Punkt A zu Punkt B fließen?



Ebenfalls die Regel und nicht die Ausnahme. Kaum ein Maschinenhersteller/Anlagenbetreiber weiß was auf Protokollebene für Daten ausgetauscht werden und welche Bedeutung sie haben.

Wie schon mehrfach angesprochen arbeitest Du mit diesem Konzept auf einer Ebene die kaum jemand kennt geschweige den nutzt. Eine Analyse der Daten auf dem Bus erfolgt wenn man Glück hat im Störungsfall mit einem entsprechenden Busanalyzer, bei dem allerdings der Schwerpunkt nicht auf Daten liegt sondern auf physikalische Signalanomalien auf dem Bus die durch falsche/defekte Verkabelung , falsche Terminierungen, EMV Problemen etc. hervorgerufen werden.

Versuch Dir alleine die Schwierigkeit der Datenerfassung für Deine Analyse vor Augen zu führen.
Wie kommst Du an die Aufzeichnung des Telegramverkehrs auf dem Bus?
Eine SPS oder Busteilnehmer liefert Dir diese Daten nämlich nicht, sprich du musst ein zusätzliches Stück Hardware in Form eines Busmonitors nehmen, damit hast du das Problem diesen überhaupt integrieren zu können so das er die Daten aufzeichnet und auch beim Anschluss den Bus nicht stört (Abschlusswiderstände bei PROFIBUS sind nicht so ganz ohne).
Dann hast du in der Maschine eventuell nicht nur eine Leitung sondern mehrere, sprich du bist schon bei mehreren Monitoren (Kosten!).
So gehen wir davon aus das alles ist getan:
In welcher Form liegen dann die erfassten Daten vor ? Anbieter solche Monitorsysteme setzen meist auch auf eigene Auswertungs-SW mit einem bestimmten Format, also nicht zwangsweise offen für eine Analyse durch andere Tools.
Sprich du musst Dich einmal festlegen welches Monitoring-System von welchem Anbieter überhaupt für dich geeignet ist, das wiederum ist für dein gesamtes Konzept entscheidend.

Gruß
Christoph


----------



## AlexSc (14 Juli 2015)

> Sicherheit an einer Maschine in Betrachtung auf IDS/Manipulation/Hack ist heute "Häng das Ding nicht ans Internet"


Das werd ich sowas von in der BA zitieren 
Okay, ich denke wir sind nun etwas mehr beim selben Punkt angelangt. Erstmal danke für die Antworten und die vielen Infos.



> Ebenfalls die Regel und nicht die Ausnahme. Kaum ein  Maschinenhersteller/Anlagenbetreiber weiß was auf Protokollebene für  Daten ausgetauscht werden und welche Bedeutung sie haben.


Womit wir haargenau beim Thema Industrie 4.0 wären. Genau diese Tatsache ist doch der Grund für Aussagen wie "hängs nur nicht ans Internet". Dass sowas aber bald der Fall sein wird (und auch heute teilweise schon so gemacht wird) ist meiner Meinung nach absolut klar.
Um die Diskussion vielleicht noch ein bisschen zu besänftigen, ja ich verstehe alle deine Bedenken und allein durch die Probleme auf die ich bei bloßer Recherche zum Thema PROFIBUS getreten bin habe ich gemerkt, wie "unbekannt" diese Ebene eigentlich ist. Es gibt auch ganz sicher viele viele andere Ansätze zur Verbesserung der Sicherheit in Industrie Anlagen. Ich befasse mich jedoch mit diesem Thema und möchte das Beste da raus holen.



> Versuch Dir alleine die Schwierigkeit der Datenerfassung für Deine Analyse vor Augen zu führen.
> ...
> ...


Auch hier hast du völlig Recht, aber die Antwort darauf habe ich schon gegeben. Ich kann beim besten Willen nicht an all diese Dinge denken und das will ich auch garnicht. Ich persönlich lese den Traffic momentan aus einer PCAPNG Datei, die ich im Netz gefunden habe. Das ist weder echtzeitfähig noch sonst irgendwie toll aber immerhin.
Ich habe keine Hardware, kein echtes Netz, keine Echtzeitdaten, allgemein keinen Anschluss an ein Netz und muss den PROFIBUS Traffic den ich bekomme selbst parsen (quasi ein mini Wireshark, da es nicht mal dafür ein PROBIUS Plugin gibt -.-).

Darum geht es aber auch alles nicht, all diese Funktionen können ruhig sehr einfach gehalten sein. Ich brauche das alles ja nur als "Brücke" um überhaupt zu meiner eigentlichen Aufgabe zu gelangen und das ist (wer hätt's gedacht) die statistische Analyse. Meine Arbeit soll zum allergrößten Teil danach bewertet werden, welche Möglichkeiten ich biete, Datenverkehr zu analysieren (welche Algorithmen, auf welche Arten Stichproben genommen werden können, etc).

Zusätzlich (und damit als extra) habe ich mir viele Gedanken dazu gemacht, wie man all die "schlechten" Module die ich nutze (Datenquelle und Aufbereitung) einfach auswechseln und parallel nutzen kann.


----------



## ChristophD (14 Juli 2015)

Hi,

ich will dir nicht alle Illussionen und Vorstellungen rauben.
Aber auch bei Industrial Ethernet und PROFINET wirst du auf exakt die gleichen Sachen stoßen, keiner weiß was auf Datenebene abgeht und leider interessiert es auch keinen.
Daran wird auch Industrie 4.0 nichts ändern ! Da werden Daten auf der Feldebene nicht mal erwähnt 

Gruß
Christoph


----------



## MSB (14 Juli 2015)

Hier mal der grobe Ablauf wie der Anwender vorgeht:
a) HW-Konfig grafisch zusammenklicken: https://support.industry.siemens.com/cs/br/en/view/17420755
b) Auf die SPS Übertragen
c) "Hoffen" das alle roten Lampen ausgehen
d) Wenn jetzt noch beim Befehl "= A0.0" basierend auf obigem Bild der richtige Motor startet oder die richtige Lampe leuchtet, freuen wie problemlos doch alles funktioniert
e) Inbetriebnahme fertigstellen, womit die Anlage dann 20 Jahre, oft genug sogar ohne jedwede Änderungen ihren Dienst tut

Was die SPS damit jetzt dann protokolltechnisch auf dem Feldbus tut interessiert aus Anwendersicht absolut niemanden (höchstens aus wissenschaftlichen Interesse).
Wenn man sich dann doch mal dafür interessiert, dann höchsten bei konkreten Problemen, was aber in aller Regel physikalische Probleme durch defekte Gerätschaften oder EMV sind,
wobei selbst hier die konkreten Daten relativ egal sind.

Mfg
Manuel


----------



## AlexSc (14 Juli 2015)

Und da meine Bachelorarbeit in der Fakultät für Netzwerke und IT Sicherheit geschrieben wird, noch ein wunderbares Zität 

Dass das so gemacht wird, scheint ein Indikator dafür zu sein, dass es so gemacht werden kann ohne dass sie Welt zusammen bricht.
Da aber wie gesagt immer mehr Anlagen (mindestens über ein angeschlossenes Gerät) doch irgendwie mit den Internet verbunden sind wird man sich zwangsläufig über neue Sicherheitsaspekte Gedanken machen müssen. Wenn dann irgendwann mal etwas richtig schief gegangen ist und der Gedanke laut wird, es könnte sich um einen gezielten Angriff handeln, dann wird es nicht mehr reichen auf die roten Lampen zu schauen...


----------



## norustnotrust (14 Juli 2015)

AlexSc schrieb:


> Ist  doch egal, selbst wenn es nur zu heiß ist, kann eine Abweichung von 20%  eines Sollwertes sicher nichts guten heißen. Wenn das niemand mitbekäme  hätte das sicherlich Folgen.



Sorry aber das ist Unsinn. Schwankungen der Stellgrößen von 0-100% sind nicht die Ausnahme sondern die Regel. Signifikante Änderungen sind nicht die Ausnahme sondern die Regel. Und das Schlimme ist, deine Änderungen haben komplexe Zusammenhänge die du statistisch imho nicht erfassen können wirst. Ich verstehe deinen Eifer aber du solltest nicht leichtfertig glauben dass wir Kritiker hier auf der Nudelsuppe dahergeschwommen sind und sehr wohl eine Vorstellung haben was man statistisch auswerten kann und was nicht.

Auf die PC Welt umgelegt versuchst du folgendes: Du hast einen Rechner und schaust auf den Inhalt der Datenpakete die über den SATA Bus geschrieben werden und den Inhalt der gelesen wird. Nur das, du weißt nicht welches Programm die Daten schreibt, du weißt nicht welche Programme, welche Zustände am Rechner gerade aktiv sind, ob der Rechner überhaupt eingeschaltet ist, ob ein Benutzer angemeldet ist gar nichts. Nur den Dateninhalt der gelesen und geschrieben wirst. Wie willst du statistisch da eine Aussage treffen ob ein Virus läuft oder nicht?


----------



## manseluk (14 Juli 2015)

Ich finde es Schade, das dieses Thema aus "praktischer Erfahrung" einfach so als unrealisierbar dargestellt wird. Stuxnet hat uns doch alle gezeigt, was möglich ist (wenn auch unter enormen Kosten, aber der Angriff ging ja immerhin auf eine Zentrifuge im Iran). Wer garantiert uns, dass vieleicht nicht morgen, aber in 20 Jahren Angriffe auf heute erstellte Anlagen erfolgen? Sei es auch "nur" zur Spionage und nicht zur Zerstörung / Fehlfunktionen.

Ich bin kein Experte in der Fuzzy-Logik (kann also auch ein Holzweg sein), aber eventuell hilft dir dieser Ansatz weiter, um die Zuverlässigkeit von Sollwerten zu überprüfen. Einfach mal googlen und eventuell hast du ja einen Dozenten der sich im Bereich Fuzzy / Neuronale Netzwerke auskennt.


----------



## JesperMP (14 Juli 2015)

Sicherheit sit eine grossen Thema, und es wird mehr und mehr Bedeutung haben.
Aber, nicht für Profibus (*). Profibus gehört zu den Zeit wo den Zugang "freiwillig" gesteuert war. Auf Sicherheit in den Sinne ein bösartige Angriff zu sperren war mit Profibus nie überlegt.
Wenn in den Zukunft ein Profibusnetz sicher sein soll, muss den Zugang von ein übergeordneter System sicher gestaltet werden.
Und warum überhaupt Profibus ? Warum nicht auch andere ebenso veraltete Feldbusse ?
*: edit.. Ich meine das den einzigsten Weg ein Profibus Netz sicher zu machen, ist den Zugang von unbefugte komplett zu sperren.

Den Plausibilität von die Prozesswerte zu analysieren, das gehört zu den Funktionalität von ein SCADA oder Prozessleitsystem. Da kann man sicher viel machen, bzw. es wird schon viel gemacht in bestehender Anlagen.


----------



## norustnotrust (14 Juli 2015)

manseluk schrieb:


> Ich finde es Schade, das dieses Thema aus "praktischer Erfahrung" einfach so als unrealisierbar dargestellt wird.



Es ist keine Frage der generellen Ablehnung sondern eine Frage der (Wissenschafts-)Ökonomie. Ich finde es schade wenn man Ressourcen an Ansätzen verschwendet die von vornhinein wenig Aussicht auf Erfolg haben anstatt sie für Ansätze zu verwenden die vielversprechender scheinen.


----------



## ducati (14 Juli 2015)

norustnotrust schrieb:


> Auf die PC Welt umgelegt versuchst du folgendes: Du hast einen Rechner und schaust auf den Inhalt der Datenpakete die über den SATA Bus geschrieben werden und den Inhalt der gelesen wird. Nur das, du weißt nicht welches Programm die Daten schreibt, du weißt nicht welche Programme, welche Zustände am Rechner gerade aktiv sind, ob der Rechner überhaupt eingeschaltet ist, ob ein Benutzer angemeldet ist gar nichts. Nur den Dateninhalt der gelesen und geschrieben wirst. Wie willst du statistisch da eine Aussage treffen ob ein Virus läuft oder nicht?



Ziemlich treffende Analogie!

Trotzdem hackt hier mal nicht auf Alex rum. Er kann nichts dafür, das sich jemand dieses "utopische" Projekt ausgedacht hat. Zu der praktischen Umsetzung kann er mit seinen Kenntnissen und Möglichkeiten auch nichts sagen. Er könnte aber in der Arbeit erwähnen, das Leute mit praktischer Erfahrung starke Zweifel an der praktischen Realisierbarkeit (mit auch wirklichem praktischen Nutzen) haben, und das Thema nochmal gesondert betrachtet werden sollte, bevor zu viel an der Praxis vorbei entwickelt wird.

Was passiert, wenn Theoretiker aus dem Büro etwas entwickeln sieht man ja an vielen Ecken, z.B. TIA-Portal.

Gruß.

PS: Was zum Thema Industrial Security gemacht werden kann bzw. sollte schreibt Siemens ja z.B. hier:
http://www.industry.siemens.com/topics/global/de/industrial-security/seiten/default.aspx 
http://www.industry.siemens.com/topics/global/de/industrial-security/support/Seiten/whitepaper.aspx 
Warum viele Dinge in der Praxis nicht/anders gemacht werden, hat viele Gründe. Sicherlich nicht zuletzt eine Frage von Kosten/Nutzen/Aufwand/Wahrscheinlichkeit.


----------



## AlexSc (14 Juli 2015)

norustnotrust schrieb:
			
		

> Auf die PC Welt umgelegt versuchst du folgendes: Du hast einen Rechner  und schaust auf den Inhalt der Datenpakete die über den SATA Bus  geschrieben werden und den Inhalt der gelesen wird. Nur das, du weißt  nicht welches Programm die Daten schreibt, du weißt nicht welche  Programme, welche Zustände am Rechner gerade aktiv sind, ob der Rechner  überhaupt eingeschaltet ist, ob ein Benutzer angemeldet ist gar nichts.  Nur den Dateninhalt der gelesen und geschrieben wirst. Wie willst du  statistisch da eine Aussage treffen ob ein Virus läuft oder nicht?


Und noch mal:
Natürlich bringt mir das nichts. Es bringt mit genau so wenig, wie eine Datei auf Viren zu scannen, wenn ich keine bekannten Virensignaturen zur Auswahl habe. Ein fach zu sagen "jetzt kam 10 mal die 0 und dann hundert Einsen" ist sicher kein toller Ansatz. WENN ich aber etwas mehr über die Struktur der zu Grunde liegenden Daten habe, dann habe ich sehr wohl eine Chance, da was zu reißen.
Aufdein Beispiel bezogen: Wenn ich aber dann doch Informationen über die laufenden Programme und den sonstigen Systemzustand, dann kann mir ein Analysetool im Datenbus sehr wohl in Verbindung mit anderen Mechanismen helfen, einen tatsächlichen Angriff aufzudecken.

Und noch mal:
kein Tool der Welt, das so aufgebaut ist kann alleine wirklich was großes bewirken. Es ist immer dazu gedacht, in Verbindung mit anderen einen weiteren Standpunkt genauer zu betrachten (in diesem Fall die "Normalität" des Datenverkehrs).

Wir sprechen also weiterhin aneinander vorbei. Ich stütze mich auf die Grundlage, dass es um so ein Netz irgendwann mal großflächig ans Internet hängen zu können auch noch andere Sicherheitssysteme geben wird. Um nochmal zu Stuxnet zu kommen:
Da wurden nach meinen Informationen Druckverhältnisse in Tanks verfälscht, was letztendlich zum Ausfall und Beschädigung dieser Geräte führte. Wo wäre das Problem, vorher zu definieren, welche Werte da als Normal und welche als Anormal zu sehen sind? Wenn irgendjemand dort doch nur einen einzigen Blick auf die (nicht vorhandenen) PROFIBUS Logs geworfen hätte oder am besten schon ein Tool hätte, das diese übermittelten Daten auf Unregelmäßigkeiten prüft, wäre das sofort aufgefallen.
Dass die Geräte ausgefallen sind konnte man sich nämlich die ersten Male garnicht erklären!


----------



## JesperMP (14 Juli 2015)

AlexSc schrieb:


> Um nochmal zu Stuxnet zu kommen:
> Da wurden nach meinen Informationen Druckverhältnisse in Tanks verfälscht, was letztendlich zum Ausfall und Beschädigung dieser Geräte führte. Wo wäre das Problem, vorher zu definieren, welche Werte da als Normal und welche als Anormal zu sehen sind? Wenn irgendjemand dort doch nur einen einzigen Blick auf die (nicht vorhandenen) PROFIBUS Logs geworfen hätte oder am besten schon ein Tool hätte, das diese übermittelten Daten auf Unregelmäßigkeiten prüft, wäre das sofort aufgefallen.
> Dass die Geräte ausgefallen sind konnte man sich nämlich die ersten Male garnicht erklären!


Was ich über Stuxnet verstanden habe:
Der Trojaner lief auf der "Engineering Station" wobei geänderte Programmbausteine in den SPS geladen wurde. Der Trojaner war so schlaurig das die geänderte Programmbausteine auf Sicht von der Engineering Station versteckt wurde. Die Datenwerte den die Anwender (von das SCADA system) beobachtete wurde ebenso verfälscht.
Was man davon lernen kann: Wenn ein Übeltäter Zugang zu ein System hat, und er hat genügend Kentniss zu wie plausible Daten aussehen müssen, dann kann man sich dagegen nicht schützen.
Man kann sich nur schützen vor einem Angreifer, durch die Blockierung seiner Zugang.


----------



## ducati (14 Juli 2015)

AlexSc schrieb:


> Wo wäre das Problem, vorher zu definieren, welche Werte da als Normal und welche als Anormal zu sehen sind? Wenn irgendjemand dort doch nur einen einzigen Blick auf die (nicht vorhandenen) PROFIBUS Logs geworfen hätte oder am besten schon ein Tool hätte, das diese übermittelten Daten auf Unregelmäßigkeiten prüft, wäre das sofort aufgefallen.



Das ist einfach eine Frage des Aufwandes: Eine Anlage besteht u.U. aus mehreren zig tausend Signalen. Für die alle Grenzwerte festzulegen ist Wahnsinn. Das ganze müsste dann zusätzlich noch immer aktuell gehalten werden, da sich die Anlage auch ständig ändert (wie oben schon geschrieben). Weiterhin würde ein Insider auch von diesem Profibusanalysetool wissen und dieses ebenfalls manipulieren...


----------



## JesperMP (14 Juli 2015)

AlexSc schrieb:
			
		

> Wo wäre das Problem, vorher zu definieren, welche Werte da als Normal und welche als Anormal zu sehen sind? Wenn irgendjemand dort doch nur einen einzigen Blick auf die (nicht vorhandenen) PROFIBUS Logs geworfen hätte oder am besten schon ein Tool hätte, das diese übermittelten Daten auf Unregelmäßigkeiten prüft, wäre das sofort aufgefallen.





			
				ducati schrieb:
			
		

> Eine Anlage besteht u.U. aus mehreren zig tausend Signalen. Für die alle Grenzwerte festzulegen ist Wahnsinn.


Kein Wahnsinn. Eine relativ normalen Aufgabe für ein Prozessleitsystem.
Nicht nur Grenzwerte, aber auch mehr komplexe Zusammenhänge können beobachtet werden.
z.B.
Heizelement X startet --> Temperatur Y muss steigen.
Ventil Z öffnet --> Druck W muss fallen.
Usw.

Ich bin der Meinung das dies ist eine Aufgabe für eine Prozessleitsystem, und nicht für eine Profibus (oder Profinet oder...) Busanalysator.


----------



## ducati (14 Juli 2015)

JesperMP schrieb:


> Kein Wahnsinn. Eine relativ normalen Aufgabe für ein Prozessleitsystem.
> Nicht nur Grenzwerte, aber auch mehr komplexe Zusammenhänge können beobachtet werden.
> z.B.
> Heizelement X startet --> Temperatur Y muss steigen.
> ...



Ja eben, im Leitsystem wird es ja gemacht. Nur es ist Wahnsinn, es nochmal zusätzlich für den Profibusanalysator zu machen. Das ganze muss ja dann nicht nur konsistent zum Leitsystem programmiert werden sondern auch noch bei der Inbetriebnahme bzw. jeder Änderung getestet. 

Gruß.

PS: Der Vorteil von Profibus DP ist ja eigentlich die Einsparung von Kosten in der Verkabelung. Wenn ich jetzt riesen Kosten verursache, indem ich sehr aufwändige Profibussicherheitssysteme installiere, dann kann ich auch gleich auf Profibus verzichten und alle Signale direkt auf die SPS verkabeln.
Zwischen die Feldgeräte und der SPS noch ein Gerät zu schalten, welches den Prozess auf Manipulationen/Fehler/Sonstwas überwacht sehe ich wenig als sinnvoll an. Weil das ja eigentlich die Aufgabe der SPS ist. Die SPS macht ja genau das, was hier diskutiert wird. Nur ist die SPS eben auch manipulationsgefährdet, ebenso wie auch dieser Profibusanalysator.


----------



## Gerhard Bäurle (14 Juli 2015)

Mit etwas Abstand betrachtet ist es doch so, dass es
ein Riesenaufwand ist, Systeme ohne eigene Security-
Funktionen zu überwachen oder sicher zu machen. 

Das betrifft den Profibus ebenso wie KNX oder gängige 
Steuerungen. In dem Moment, wo ich physisch 
Zugang und die passenden Standard-Software auf 
dem Rechner habe, kann ich alles machen.

Ein Beispiel:
http://www.zeit.de/digital/datenschutz/2014-08/black-hat-2014-hotelzimmer-gehackt

Meiner Ansicht nach bringt das Prinzip der DMZ

https://de.wikipedia.org/wiki/Demilitarized_Zone

am ehesten Sicherheit. Physischer Schutz und Daten-
übergabe/Kopplung an definierten Punkten, die 
dann tatsächlich überwacht werden können.

Soweit meine Meinung, aber auch ich möchte den 
Forscherdrang nicht bremsen.


----------



## volker (14 Juli 2015)

ich habe den thread jetzt auch verfolgt und bin wie die meisten der meinung das dies ehr nicht realisierbar ist.
ich muss aber auch zugeben, dass ich mir über sowas beisher nie gedanken machen musste.

prüfung der prozessdaten werte ich auf der steuerungsebene auf gültigkeit aus. 
leichte manipulationen, die ein hack einbringen könnte, kann man nicht wirklich abfangen. 
diese könnten aber durchaus die qualität des endproduktes beeinflussen. (ähnlich stuxnet. das hat auch nicht alles lahmgelegt, sondern nur prozesswerte soweit manipuliert, das das endprodukt nicht mehr wirklich ok war)

und warum wurde gerade profibus gewählt? ist zwar noch lange nicht tot aber wird mit sicherheit auf dauer sterben.
pb ist ehr ein system welches nicht über internet oÄ ereicht werden kann. 
um hier einzugreifen wären definitiv zusätzliche hardwarebauteile erforderlich die in den bus eingeschleift werden müssten.
dazu müsste der hacker aber erst mal an die anlage.

bei profinet sähe das evtl schon in wenig anders aus.
aber auch hier würde ich sagen kann man nicht die busskommunikation mit fremden daten "überschreben" kann ohne das irgendwelche kommunikationsfehler auftreteten. und eine hard-/software wäre (imho) auch hier erforderlich

als wichtig seh ich hier ehr, dass der zugriff auf die steuerung/hmi geschützt wird.
z.b. http://www.process-informatik.de/produkte/s7-firewall&mt=1
das hab ich zwar noch nicht getestet, hört sich für mich aber recht gut an.


----------



## norustnotrust (14 Juli 2015)

Um nochmal klarzustellen: Du hast dein BA Thema eh und das ist gut so.  Aber das hier ist nun mal ein Forum und nicht immer bekommt man das  nachdem man fragt. Ich finde solche Themen ja grundsätzlich sehr  interessant, ansonsten würde ich auch hier nicht Zeit investieren um mit  euch zu diskutieren. Meine Eingangs geäußerte Kritik bezog sich ja auch  auf das Thema BA Themen allgemein, da ich nicht sehe dass man BAs, die  nach dem Bologna Konzept eigentlich primär für einen Eintritt in den  Arbeitsmarkt ausgebildet werden sollten, mit so ... sagen wir mal  vornehm "extrem praxisfernen Fragestellungen" die sich halt meiner  Meinung nach eher für Diss eignen, in das Feld geschickt werden. Aber  OK, das ist halt so. Auch ist das natürlich keine Kritik an dir und ich  wünsche dir das Beste für deine Noten und deinen Abschluss.


Dennoch möchte eine einfache Kritik hier nochmal auf den Punkt bringen:

Ich  denke mal wir sind uns einig dass das Bedrohungspersonal wie folgt  aussieht. Ein Bösewicht erlangt Kontrolle über einen HMI Rechner, eine  Engineering Station oder greift direkt aus dem Netzwerk auf die CPU zu  und verändert entweder das Programm in der SPS oder einzelne Zustände in  der SPS damit diese Sollwerte an die Anlage schickt um diese zu  beschädigen. Die kritische Richtung die es am Bus zu überwachen gibt,  sind also Sollwerte von der SPS zu den Akteuren.

Diese Sollwerte  haben komplexen (im Sinne von "nicht einfach deterministisch" also z.B.  nichtlinear, schwellwertabhängig, zeitabhängig) Zusammenhang zu den  Eingängen (die du am Bus erfassen kannst) UND zu inneren Zuständen (die  du am Bus nicht erfassen kannst). Daher behaupte ich dass du mit mit  statistischen Methoden unmöglich "normale" von "abnormalen" Zuständen  unterscheiden kannst.

Ich nehme irgendeinen Regelkreis als  Beispiel. Wie willst du bei einem Regelkreis ein abnorme Stellgröße mit  statistischen Mitteln detektieren OHNE den Sollwert(=innerer Zustand) zu  kennen? Wie könnte ein Erkennungsalgorithmus grundsätzlich dafür aussehen?


----------



## AlexSc (15 Juli 2015)

Auch von mir an dieser Stelle noch mal vielen Dank an alle Diskussionsteilnehmer! Ich hätte ehrlich gesagt nicht gedacht, dass sich so viele Interessenten dafür finden und eine derartige Diskussion überhaupt zustande kommt. Ob positive oder negative Kritik, helfen tut ihr mir sowieso 

Heute hatte ich ein Gespräch mit meinem Professor. Der sieht die Sache widerum so, dass ich schon um ein Vielfaches näher an "der Praxis" bin als ein sehr großer Teil aller Bachelorarbeiten. Er hat mir versichert, dass keine Bachelorarbeit jemals danach bewertet werden kann, wie die Community einer entsprechenden Branche das Thema annimmt bzw. als sinnvoll erachtet. Notfalls müsste dafür wenn überhaupt dem Unternehmen die Schuld gegeben werden auf Grund der (wie schon angesprochen) seltsamen Aufgabenstellung. Hinzu kommt, dass meine vorherige Leistungsbeschreibung ja schon von allen Seiten abgesegnet wurde und damit steht auch fest wonach bewertet wird.
Das nimmt mir schon mal eine Menge Stress ab, der sich hier zugegebenermaßen aufgebaut hat...

Zum Thema:

@Gerhard Bäurle:
Vielen Dank für die Links und das Statement. Was eine DMZ ist, weiß ich aber schon 

@volker:
Warum genau dieses Protokoll gewählt wurde weiß ich leider nicht, wie gesagt; Vorgabe der Firma...

@norustnotrust:
Zu deinem Statement hab ich oben schon was geschrieben. Ich bin des Öfteren in Foren unterwegs und weiß, wie schnell es da mit enthusiastischen Vorschlägen und eben so starker Kritik bis hin zu Spott hin und her geht (wobei hier von Spott nicht die Rede ist, aber das gibt es auch häufig genug).
Zu deiner Frage, da kann ich mich leider wieder nur wiederholen. Es muss doch eine Möglichkeit geben, vorher zu definieren, was Sollwerte für bestimmte Geräte sind. Wenn die SPS irgendein Gerät im Netzwerk anspricht und Sollwerte übermittelt, dass muss es mindestens ein FDL Telegramm verschicken. Darüber kann ich die Adresse filtern und weiß genau, wer wen anspricht. Nun kann entweder jemand vorher das Überwachungssystem einmalig so eingestellt haben, dass für dieses Gerät klar ist, in welcher Situation welche Werte erwartet werden oder noch besser (utopische Vorstellung) die Hersteller der Geräte würden so einen Ansatz selbst unterstützen.

Mal ein genaueres Beispiel (hoffe dass es ungefähr so tatsächlich funktionieren könnte):
Eine SPS steuert einen Greifarm oder ähnliches, der automatisiert nach links fährt, einen Gegenstand von einem Fließband nimmt, nach rechts fährt und den Gegenstand fallen lässt. In dem Moment in dem der Arm nach links fährt, sendet die SPS natürlich völlig einzigartige Signale. Vorher könnte aber eine kleine Ergänzung im Konvertierungsmodul (welches die roh mitgeschnittenen Daten parst und in Pakete umwandelt) kurz vermerken, in welchem Status sich das Gerät befindet (0=nach links, 1=greifen, etc). Das Analysemodul könnte darauf reagieren und Stichproben entsprechend dem Status einzeln verwalten. Wenn dann der Arm 100 mal ordentlich nach links gefahren ist und beim 101. Mal schneller fährt oder nur die Hälfte des Weges zurücklegt würde die Software das (sofern sich das im Datenverkehr zeigt) mitbekommen.

Liebe Grüße und einen schönen Abend,
Alex


----------



## dr.pfb (16 Juli 2015)

Hallo zusammen,

wir hatten schon vor Jahren solche Anfragen. Es ging immer um; wie schon hier mehrmals gesagt; Plausibiltaetspruefung der Prozesswerte, sowie Unterbindung eines evtl. Zugriffes von aussen und (schlimmer) Manipulation des Programms bzw. des Datenstroms. PLT ist auch anfaellig, es musste der direkte PROFIBUS Telegrammverkehr ueberwacht werden. 

Es gab interessante Diskussionen. Z.B. Werteaenderung ala Stuxnet; Store and Forward fuer PROFIBUS war auch ein Thema.

Selbstlernende neuronale Netze, die die Prozesszustaende (Ausgangswerte!) auf Gueltigkeit pruefen. 

Also nicht so weit hergeholt, das Thema. Auch viel Prozessknowhow steckt evtl. im SPS Programm. 

Vg
Tim



volker schrieb:


> ich habe den thread jetzt auch verfolgt und bin wie die meisten der meinung das dies ehr nicht realisierbar ist.
> ich muss aber auch zugeben, dass ich mir über sowas beisher nie gedanken machen musste.
> 
> prüfung der prozessdaten werte ich auf der steuerungsebene auf gültigkeit aus.
> ...


----------



## dr.pfb (16 Juli 2015)

Hi

FDL ist Schicht 2, DP ist hoeher. Die Sollwerte (Ausgangsdaten) stehen im Telegramm, ist standardisiert, kein Problem das zu dekodieren. 

Vielleicht sowas: http://www.iba-ag.com/de/anlagenueberwachung-einer-warmbreitbandstrasse/

Oder Profitrace, der hat auch ne API, da kannst Du die Telegramme abgreifen und weiterverarbeiten.

Zu Deiner Greifarmfrage, Du kannst nur mitbekommen wenn Dein Arm da schneller faehrt, wenn Du das auf irgendeine Weise misst und zurueckbekommst. 

VG
Tim



AlexSc schrieb:


> @norustnotrust:
> Zu deinem Statement hab ich oben schon was geschrieben. Ich bin des Öfteren in Foren unterwegs und weiß, wie schnell es da mit enthusiastischen Vorschlägen und eben so starker Kritik bis hin zu Spott hin und her geht (wobei hier von Spott nicht die Rede ist, aber das gibt es auch häufig genug).
> Zu deiner Frage, da kann ich mich leider wieder nur wiederholen. Es muss doch eine Möglichkeit geben, vorher zu definieren, was Sollwerte für bestimmte Geräte sind. Wenn die SPS irgendein Gerät im Netzwerk anspricht und Sollwerte übermittelt, dass muss es mindestens ein FDL Telegramm verschicken. Darüber kann ich die Adresse filtern und weiß genau, wer wen anspricht. Nun kann entweder jemand vorher das Überwachungssystem einmalig so eingestellt haben, dass für dieses Gerät klar ist, in welcher Situation welche Werte erwartet werden oder noch besser (utopische Vorstellung) die Hersteller der Geräte würden so einen Ansatz selbst unterstützen.
> 
> ...


----------



## ducati (16 Juli 2015)

dr.pfb schrieb:


> Hallo zusammen,
> 
> wir hatten schon vor Jahren solche Anfragen. Es ging immer um; wie schon hier mehrmals gesagt; Plausibiltaetspruefung der Prozesswerte, sowie Unterbindung eines evtl. Zugriffes von aussen und (schlimmer) Manipulation des Programms bzw. des Datenstroms. PLT ist auch anfaellig, es musste der direkte PROFIBUS Telegrammverkehr ueberwacht werden.
> 
> ...



Und habt Ihr es realisiert, wenn nein, warum nicht?
Gruß


----------



## ducati (16 Juli 2015)

Und nochmal. In einer realen Anlage geht es nicht um EINEN Greifarm sondern um tausende Signale, welche Plausibilisiert werden muessten. 
Das von Hand zu machen ist Aufwand. Und ob ein Statistiktool es automatisch kann wäre zu beweisen.
Gruß


----------



## AlexSc (17 Juli 2015)

Hey Leute,

vorerst denke ich, dass ich genug Informationen hier bekommen habe.
Ich werde mich nun fürs Erste wieder der Softwareentwicklung widmen. Bei neuen Ergebnissen (und spätestens bei neuen Fragen  ) melde ich mich aber definitiv zurück!

Nochmals vielen Dank an alle für die Unterstützung und bis bald!
Alex


----------



## norustnotrust (17 Juli 2015)

dr.pfb schrieb:


> Plausibiltaetspruefung der Prozesswerte, sowie Unterbindung eines evtl. Zugriffes von aussen und (schlimmer) Manipulation des Programms bzw. des Datenstroms. PLT ist auch anfaellig, es musste der direkte PROFIBUS Telegrammverkehr ueberwacht werden.
> 
> Es gab interessante Diskussionen. Z.B. Werteaenderung ala Stuxnet; Store and Forward fuer PROFIBUS war auch ein Thema.
> 
> Selbstlernende neuronale Netze, die die Prozesszustaende (Ausgangswerte!) auf Gueltigkeit pruefen.



Wir reden da aber von zwei verschiedenen Paar Schuhen. Wenn ich auf Basis eines selbstlernenden Systems versuche ein Model meines Anlagenverhaltens zu erlernen dann wäre das ein Ansatz der theoretisch funktionieren könnte. Allerdings auch nur dann wenn zusätzlich zu den Profibus Daten auch die inneren Zustände der SPS (Alle SPS Variablen) erfasst werden. Denn kann kann ich erkennen ob sich die Anlage jetzt anders verhält weil sie z.B. im manuellen Betrieb, andere Sollwert hat oder was auch immer (die inneren Zustände von denen ich gesprochen habe). Das Thema dürfte dennoch ausreichend schwierig sein um einige Doktoranten damit zu beschäftigen aber machbar.

Der Plan hier ist aber STATISTISCH ausschließlich aus dem PB Daten abweichendes Verhalten zu indentifizieren und ich sehe schon in der Theorie kein Licht dafür (mal von den praktischen Problemen abgesehen).

Zusätzlich stellt sich für mich mittlerweile auch die Frage: Was tue ich wenn ich einen Fehler bemerke? Wenn der Virus das Ziel hat meine Anlag zu zerstören dann wird das bei 99% der Anlagen durchführbarsein bevor jemand auf den Alarm adäquat reagieren kann.


----------



## dr.pfb (18 Juli 2015)

norustnotrust schrieb:


> Wir reden da aber von zwei verschiedenen Paar Schuhen. Wenn ich auf Basis eines selbstlernenden Systems versuche ein Model meines Anlagenverhaltens zu erlernen dann wäre das ein Ansatz der theoretisch funktionieren könnte. Allerdings auch nur dann wenn zusätzlich zu den Profibus Daten auch die inneren Zustände der SPS (Alle SPS Variablen) erfasst werden. Denn kann kann ich erkennen ob sich die Anlage jetzt anders verhält weil sie z.B. im manuellen Betrieb, andere Sollwert hat oder was auch immer (die inneren Zustände von denen ich gesprochen habe). Das Thema dürfte dennoch ausreichend schwierig sein um einige Doktoranten damit zu beschäftigen aber machbar.
> 
> Der Plan hier ist aber STATISTISCH ausschließlich aus dem PB Daten abweichendes Verhalten zu indentifizieren und ich sehe schon in der Theorie kein Licht dafür (mal von den praktischen Problemen abgesehen).
> 
> Zusätzlich stellt sich für mich mittlerweile auch die Frage: Was tue ich wenn ich einen Fehler bemerke? Wenn der Virus das Ziel hat meine Anlag zu zerstören dann wird das bei 99% der Anlagen durchführbarsein bevor jemand auf den Alarm adäquat reagieren kann.



Zum ersten Teil Zustimmung, wurde meine ich auch realisiert, aber nur lesend (OPC meine ich mich erinnern zu koennen). Studienarbeit.

Zum zweiten Teil, auch Zustimmung. Delay (dann ja PROFIBUS) wird in Kauf genommen. Ohne extra Massnahmen (Hardware) keine Chance zu unterbinden; nur melden. Traffic muss sofort unterbrochen werden bzw. Slave muss mit alten Werten weiterversorgt werden. Wie ein PA Koppler das macht. Also Hardware Loesung. Machbar in Kombinatio0n mit 1.

VG
Tim


----------



## Gerhard Bäurle (18 Juli 2015)

dr.pfb schrieb:


> Zum ersten Teil Zustimmung, wurde meine ich auch realisiert, aber nur lesend (OPC meine ich mich erinnern zu koennen). Studienarbeit.
> 
> Zum zweiten Teil, auch Zustimmung. Delay (dann ja PROFIBUS) wird in Kauf genommen. Ohne extra Massnahmen (Hardware) keine Chance zu unterbinden; nur melden. Traffic muss sofort unterbrochen werden bzw. Slave muss mit alten Werten weiterversorgt werden. Wie ein PA Koppler das macht. Also Hardware Loesung. Machbar in Kombinatio0n mit 1.
> 
> ...



Das scheinen mir eher akademische Betrachtungen zu sein. 

Die Frage von ducati zielte vermutlich dahin, ob bzw. warum
es für den Anwender keine Lösungen zu kaufen gibt.

"machbar" im Labor ist eine Seite, im Feld dagegen ...


----------



## ducati (18 Juli 2015)

dr.pfb schrieb:


> Traffic muss sofort unterbrochen werden bzw. Slave muss mit alten Werten weiterversorgt werden. ... Machbar in Kombinatio0n mit 1.



Oha. Ein statistischer Algorithmus, welcher mehr oder weniger viele False Positive liefert und dessen Erkennungsrate (wie will er eigentlich Manipulationen von sonstigen Fehlern/Defekten unterscheiden) auch nicht bei 100% liegen wird, soll jetzt den Profibus unterbrechen? Da werden die Anlagenbetreiber/Instandhalter aber erfreut sein. Ich lehne mich mal aus dem Fenster und behaupte es wird durch dieses Gerät mehr Probleme in der Anlage geben als durch Virenangriffe/Manipulationen.

Gruß.


----------



## AlexSc (21 August 2015)

Hey Leute,

ich melde mich mal zurück! 
In den letzten Wochen ist viel passiert. Neben der Fast-Fertigstellung der schriftlichen Arbeit kann mein Tool mittlerweile PROFIBUS Telegramme dekodieren (FDL wird vollständig unterstützt, DP zum Teil) und es können aus allen Telegrammen beliebige Daten extrahiert und klassifizert werden. Dadurch lassen sich Tabellen und Listen anlegen, auf denen dann statistische Tests durchlaufen werden können.
Des Weiteren ist es möglich Zeitprofile anzulegen um den Begriff des "normalen Datenstroms" in verschiedenen Momenten so zu definieren, wie er entsprechend sein sollte (da hier ja oft der Kritikpunkt aufkam, man könnte nicht wissen, was da gerade über den PROFIBUS läuft). Es können beliebig viele Profile und beliebig viele Sichtweisen auf den Datenstrom angelegt werden. Die Analyse-Module arbeiten seriell auf den Eingangsdaten und generieren neue Ergebnisse immer nur dann, wenn ein vollständiger neuer Datensatz (dessen Größe auch manueel einstellbar ist) aufgenommen wird.
Die Erebnisse der Tests werden anschließend an eine Loggingstation gesendet und dort benutzerfreundlich dargestellt.

Was nun eigentlich noch fehlt ist das Testen des Systems in einem richtigen PROFIBUS Netz. Wer den Thread vollständig verfolgt hat, der weiß evtl. noch, dass ich bis dato kein echtes Netz zur Verfügung habe und meine Daten statisch aus einer Datei lese (ziemlich lahm...). Nun möchte ich doch den Schritt wagen, ein minimales (wirklich absolut minimales) Profibus Netz aufzustellen. Ein Master und ein Sensor als Slave, die per DP-V0 ein paar Messdaten austauschen würde absolut genügen, dazu noch ein Gerät mit dem man die Daten (auf niedrigster Ebene) mitschneiden kann. Wie gesagt, sowas wie ProfiTrace brauche ich nicht da ich ja die Funktion des Geräts ja fast komplett selber übernehme. Es geht nur darum, die Rohdaten irgendwie abzugreifen. Kann mir jemand bzgl. der Frage helfen, wie man an entsprechende Hardware am günstigsten kommt?

Liebe Grüße und vielen Dank an alle!
Alex


----------



## ChristophD (21 August 2015)

das günstigste was mir einfällt:

alten rechner mit Windows XP + Office
alte CP5611
das FreeTool Amprolyzer


----------

