Posts Tagged: ‘Security’

DQL, hübsche Domino Applikationen und sichere Domino Web-Server – ITWU bei der DNUG46 in Essen

7. Oktober 2019 Posted by Lela Meiners

Im Juni war ITWU auf der DNUG46 um sich umzuhören, was sich in der NotesDomino-Welt gerade so interessantes tut. Die Messe war vom 3. bis zum 5. Juni 2019 in Essen und sehr gut besucht. Wir fanden die Vorträge sehr spannend und man merkte grundsätzlich bei der Veranstaltung, dass viel Neues im Gange ist und eine breitere Fülle an Themen aufgefahren wurden, als zu Zeiten unserer letzten DNUG-Besuche – Domino ist und bleibt einfach eine spannende Plattform! Wir finden auch super, dass HCL wieder den Fokus auf die Security legt und es ist überwältigend, wie viel Elan HCL ins Produkt Domino steckt. Den Vorträgen nach können wir schon auf eine riesige Fülle an Möglichkeiten gespannt sein, die in Domino endlich eingebaut werden sollen und auf welche die Nutzer schon lange warten – z.B. Stichwort: ADSync.

Wir haben uns drei Vorträge herausgepickt, von denen wir euch in diesem Artikel berichten möchten:

- Making cool websites with Classic Notes

- Domino Query Language (DQL)

- Domino Webserver Security

 

Making cool websites with Classic Notes

Im Vortrag „Making cool websites with Classic Notes“ war der Clue des Ganzen, dass der Redner bei der Erstellung einer Notes-basierten Webseite ganz ohne Xpages ausgekommen ist und den Webseiten-Code in Formulare geschrieben hat. Diesen Code hat er dann später mit jQuery aus den Views auslesen lassen. Auf diese Weise konnte er die Vorteile von Notes (super schnelle Anwendungsentwicklung, einfache Integration von weiteren Tools wie JQuery, Bootstrap etc., Weltklasse No-SQL Datenbank, …) mit von Notes nicht unterstützten Tools vereinen, da auf diese Weise keine Validierung stattfindet und man prinzipiell im HTML-Code einbinden kann was man möchte.

-> Hier geht es zum vorgestellten Webseiten-Beispiel

Wir waren beeindruckt, wie gut die Beispiel-Webseite aussah. Allerdings sind uns auch Nachteile dieser Methode aufgefallen: z.B. bekommt man auf diese Weise ellenlange und unübersichtliche Views. Zudem ist unseren Kunden in der Regel die schnelle Erzeugung der gewünschten Anwendungsfunktionalität wichtiger als die Verschönerung der Eingabemasken – die Anwendungen sollen einwandfrei laufen, der Rest ist eher Nebensache. Und last but not least kann man den Code mit dieser Methode im Designer nicht debuggen – was für uns ein ziemlicher Schwachpunkt darstellt, weil dadurch nicht so leicht festgestellt werden kann, an welcher Stelle die Anwendung in einen Fehler läuft.

Quelle: Vortrag „Making cool websites with Classic Notes – Theo Heselmans https://dnug46.sched.com/event/LMOg/making-cool-websites-with-classic-notes

 

Domino Query Language (DQL)

Domino Query Language ist als zusätzliche Sprache mit Domino 10 hinzugekommen und dient dazu sich schnelle Datenbankabfragen (kurze Schreibweisen) zu konstruieren (z.B. zur Programmierung von Suchfunktionen). Ohne DQL muss man sich für Datenbankabfragen sehr lange query strings zusammenbauen um Daten einer zugrunde liegenden Datenbank abzurufen. DQL soll recht komplizierte Abfragen mit vielen Dokumenten in kurzer Zeit durchlaufen können und durch eine leicht verständliche Syntax sehr einfach sein, sodass kein Domino-spezifisches Wissen z.B. zu formular language benötigt wird. Da unsere Entwickler allerdings alle bisher noch auf Notes 9 entwickeln, können wir euch noch nichts über unsere eigenen Erfahrungen zu DQL erzählen. Nichtsdestotrotz finden wir, hört sich das Ganze wirklich super vielversprechend an!

Quelle: Vortrag „Domino Query Language (DQL) – John Curtis https://dnug46.sched.com/event/LMQK/domino-query-language-dql

 

Domino Webserver Security

Der Vortrag zur Domino Webserver Security war besonders spannend: Es wurden weit verbreitete Annahmen zu Sicherheitsaspekten von Webservern widerlegt, die wir übrigens in unserer jahrelangen Erfahrung schon leider viel zu oft gehört haben.

Die erste Annahme war, dass ein Webserver nicht gefunden werden kann, wenn dieser nicht öffentlich ist und somit nicht darauf zugegriffen werden kann. Allerdings wird das Web kontinuierlich gescannt und die Ergebnisse sind auf Webseiten wie z.B. „Shodan.io“ ohne Probleme einsehbar. Und sobald die IP Adresse bekannt ist, ist erstmal jeder Server angreifbar. Es ist also auch bei nicht-öffentlichen Webservern sinnvoll und nötig Sicherheitsfeatures zu aktivieren.

Der zweite Einwand war, dass ein Domino (Web-)Server ja recht spezifisch sei und deshalb nicht so leicht zu hacken ist. Die Entgegnung hierauf war, dass es mittlerweile für alles Toolkits gibt mit denen es nicht mehr notwendig ist, dass Hacker sich mit der Serverarchitektur z.B. eines Domino Servers auskennen müssen. Angriffe auf veraltete Systeme seien hier besonders einfach. Ungesicherte Domino Webserver sind also mit den entsprechenden Tools genauso angreifbar, wie gewöhnliche Webserver, besonders diejenigen mit veralteten Betriebssystemen.

In der dritten Fehlannahme ging es darum, dass auf die eigenen Webanwendungen ja nicht ohne weiteres zugegriffen werden könne. Es gibt allerdings in dieser Hinsicht einige mögliche Sicherheitslücken, wie z.B. rein clientseitige Validierungen, die grundsätzlich manipulierbar sind oder schlecht eingestellte Zugriffskontrollen (ACLs). Als Beispiel wurde gezeigt, wie bei einer Anwendung mit schlecht eingestellten ACLs mittels Übergabe von Befehlen über die URL Aktionen ausgeführt werden konnten (z.B. http://Host/Database/View/Document?DeleteDocument – löscht Dokument). Der URL-Befehl-Trick war besonders eindrucksvoll und auch eine Warnung: Wer seine ACLs nicht gut im Blick hat, riskiert nicht-autorisierte Datenbankzugriffe und -manipulationen – nicht nur im Web.

Annahme vier war, dass Verschlüsselung im internen Netz nicht wichtig sei.  Zu dieser Aussage wurde entgegnet, dass HTTP-Verbindungen sehr einfach über bestimmte Software, Hardwaresniffer oder selbst per Smartphone abhörbar sind, d.h. alles was über einen Webserver ausgetauscht wird, ist grundsätzlich abgreifbar. Zwar sind nicht alle Daten schützenswert, aber Nutzer- und Anmeldeinformationen sind es immer! Es ist also grundsätzlich besser auch intern SSL-Verschlüsselung einzusetzen.

Und last but not least die Annahme, dass es schon ausreicht, wenn die Nutzer ihre Kennwörter einmal im Monat ändern. Besser wäre als Admin nicht zu häufige Passwortwechsel zu erzwingen und vom Nutzer ein Passwort wählen zu lassen, welches sehr sicher und einzigartig unter seinen Passwörtern ist, anstatt eines seiner Standardpasswörter hochzuzählen (sind wir mal ehrlich, wer tut es nicht …). Hierzu muss man sagen, dass die Zertifizierung in Notes über die Notes ID schon sehr sicher ist. D.h. man kann einen Notes-Account nicht einfach so Hacken, denn dafür braucht man die Notes ID an die man nicht ganz so einfach kommt. Allerdings bleibt das Thema Passwortsicherheit auch in der Domino Umgebung weiterhin wichtig, allein wenn es um das Internet-Kennwort des Nutzers für Web-Anwendungen geht. Auf letztere kann man nämlich auch ohne Notes-ID zugreifen. So kann z.B. über die altbekannte Bruteforce-Methode versucht werden Zugriff bekommen: Per Script werden hier verschiedene Kennwörter-Nutzername-Kombinationen ausprobiert. So ein Angriff erfolgt meist über Kennwortlisten, welche z.B. nach einem Angriff auf Facebook oder Twitter im Netz auftauchen. Hat man auch woanders ein ähnliches Passwort passend zur selben Mailadresse gewählt, ist es nicht mehr ganz so schwer Passwörter zu knacken. Domino erlaubt per Default unendlich viele Login-Versuche, deshalb ist es sinnvoll als Gegenmaßnahme das sogenannte Internet Lockout im Server-Konfigurationsdokument zu aktivieren. Auf diese Weise deckelt man die möglichen Login-Versuche auf ein gesetztes Maximum.

Zudem sorgt eine hochgedrehte Passworthash-Einstellung intern dafür Nutzerpasswörter recht sicher zu speichern. Beim Passworthash handelt es sich um eine nicht zurückberechenbare Verschlüsselungsfunktion die Anwendung findet in Datensignaturen und der sicheren Ablage von Kennwörtern, in unserem Fall z.B. in der Ablage der Internet-Kennwörter der Nutzer im Domino Directory. Seit Domino 8 ist beispielsweise schon eine recht hohe Passworthash-Verschlüsselung auswählbar, die allerdings nicht standardmäßig eingestellt ist. Um die Passworthash-Einstellung anzupassen, kann man das Domino Directory öffnen und dann über „Actions“>“Edit Directory Profile“ zu den Konfigurationsprofil-Einstellungen gelangen.

Wenn ihr euch für spezifischer mit dem Thema Passwort-Hashes in Domino beschäftigen möchtet, kommt ihr hier auf einen sehr interessanten Artikel dazu.

Quelle: Vortrag „Domino – Webserversecurity – Markus Petzold“ https://dnug46.sched.com/event/LMOm/domino-web-security

 

Abschließend möchten wir nochmal unsere Freude darüber betonen, dass HCL wieder die Sicherheit von Domino als eine seiner großen Stärken aufgreift und daran weiterarbeitet. Grundsätzlich warten wir schonmal sehr gespannt auf die Sicherheitsfeatures von Domino 11.

Habt ihr Fragen oder Anregungen? Ruft uns einfach an unter 05251-288160 oder schreibt uns eine Mail an info@itwu.de.

Read full article |Kommentare deaktiviert für DQL, hübsche Domino Applikationen und sichere Domino Web-Server – ITWU bei der DNUG46 in Essen
Tags: , , , , , , , , , , , ,
Categories: Allgemein

Unter dem Radar: Microsoft macht es sehr clever und überlässt Facebook, Google, Amazon und Co. die „Aufmerksamkeit“

9. August 2019 Posted by Stefan Pfeiffer

Vor meinem Urlaub habe ich noch einen Artikel von Robert Linder in der Frankfurter Allgemeinen vom 20. Juli unter dem Titel „Unter dem Radar“ gelesen. Er beschäftigt sich darin damit, dass die großen Tech-Konzerne Google, Amazon, Facebook und Apple derzeit in Washington nicht sehr gut gelitten sind. Sogar von Zerschlagung wird gesprochen.

Nur ein Unternehmen bleibt außen vor, fliegt quasi „unter dem Radar“: Microsoft. So habe ich es selbst auch im Januar 2019 formuliert:

Fast unbemerkt unter dem Radar fliegt Microsoft dahin und geniesst gerade auch in Deutschland vergleichsweise großes Vertrauen und das obwohl auch das Redmonder Unternehmen Dreck am Stecken zu haben scheint. Ein Grund dafür ist sicher, dass ein großer Teil der Presse – Ausnahme der heise-Verlag – einfach nicht oder nur wenig darüber berichten: Microsoft bekam für die Datenübermittlung im Betriebssystem Windows 10 an Microsoft-Server den Big Brother-Award wurde. Seit Jahren gibt es immer wieder Sicherheitslücken in den Produkten. Windows mit der Version 10 war erneut in 2018 kein Ruhmesblatt. Office 365 verletzt EU-Recht und sammelt massiv Daten, was in Deutschland kaum registriert und verbreitet wurde. LinkedIn, bei dem es auch in 2018 mindestens einen Vorfall gegeben hat, lasse ich hier einmal außen vor.

über Datenschutz oder „Ich habe ja nichts zu verbergen“ oder was 2018 so passierte bei Amazon, Google, Facebook und Microsoft – StefanPfeiffer.Blog

Satya Nadella, der Microsoft CEO, hat das Unternehmen neu positioniert, ist erfolgreich im Cloud-Geschäft und gebärdet sich bescheidener als zu Zeiten eines Steve Ballmer. Clever. Chapeau. Aber für mich gehört Microsoft unbedingt auf die Watchlist GAFAM mit Google. Apple, Facebook, Amazon und eben Microsoft. Treffende Analyse, aber leider scheint der Kommentar nicht mehr online verfügbar zu sein und ist über Blendle auch nicht mehr verfügbar. Schade. Hätte ihn gerne verlinkt. Wer ihn findet: Trage den Link gerne nach.

Read full article |Kommentare deaktiviert für Unter dem Radar: Microsoft macht es sehr clever und überlässt Facebook, Google, Amazon und Co. die „Aufmerksamkeit“
Tags: , , , , ,
Categories: Allgemein

Weiter aktuell: Das Magazin vom 6. Juni mit Oliver und Gunnar in Marzahn, dem Sicherheitslaster CTOC und #FreierCode für freie Bürger

7. Juni 2019 Posted by Stefan Pfeiffer

Auf dem Rückweg von Berlin schaffe ich es jetzt endlich, auch hier das gestrige Magazin mit einer Vielzahl interessanter Themen zu publizieren. Gunnar hat mit meinem Kollegen Oliver Hüfner eine mit dem Malteser Hilfsdienst entwickelte altersgerechte Musterwohnung in Marzahn besucht, ein hochaktuelles Thema sowohl unter sozialen wie auch finanziellen Aspekten. Er wird auch noch eine ausführlichere Version des Beitrags für Euch schneiden. Lars hat wichtigen Aussagen der lebhafte Podiumsdiskussion zum Thema Freier Code für freie Bürger zusammengeschnitten – und mich dabei herausgeschnitten. Ich bin jetzt schon ein bisschen nachdenklich, was das bedeuten könnte.

Und daneben gibt es noch eine Vielzahl weiterer Impressionen zum Beispiel vom Security Summit und dem X-Force Command Cyber Tactical Operations Center, kurz CTOC, dem mobilen Sicherheitszentrum, das sich in einem Truck befindet. Hoffentlich haben wir Euch auch den Mund wässrig gemacht auf weitere Beiträge, die wir heute aufnehmen beziehungsweise aufgenommen haben: Wir besuchen den Parfumeur Marc vom Ende von Symrise, der mit Unterstützung künstlicher Intelligenz neue Düfte kreiert. Im Bikini bauen/bauten am 7.Juni 300 Schüler Wettersensoren und verteilen sie in der Stadt, um die Luftqualität zu messen*.

Bei der We Are Developers-Konferenz wird das Projekt und der Call for Code mit dem UN Office für Human Rights vorgestellt, in dem IT-Lösungen entwickelt werden, die Menschen im Fall von Naturkatastrophen helfen sollen. Am 15. und 16. Juni gibt es dazu auch einen Hackathon während der Think at IBM. Wir hoffen, dass noch viele Entwickler bei diesem sozialen Projekt mitmachen. Und hoffentlich schafft es Sascha Pallenberg ins Bikini, um mit uns über den Chatbot Ask Mercedes zu sprechen. All diese Beiträge werden die Tage geschnitten und gehen dann neben anderem Material live.

Unsere nächsten Magazine senden wir dann jeweils dienstags am 11. Juni, 18. Juni und am 25. Juni. Natürlich werden zwischendurch auch einzelne Berichte publiziert. Also dran bleiben. Es lohnt sich

(Stefan Pfeiffer)

* Über 200 Schülerinnen und Schüler haben in Teams selbst einen Umweltsensor zur Messung von Temperatur, Feuchtigkeit und Feinstaub aus einfachen Bauteilen gebaut und gelernt, sie sinnvoll aufzustellen und auf der Online-Plattform luftdaten.info einzuhängen. Die so anfallenden Daten können dann später im Unterricht mit Verkehrs- und Wetterdaten verbunden werden und bieten Grundlage für die Auseinandersetzung mit IoT, BigData und Citizen Science an einem konkreten, aktuellen Beispiel.

 

Read full article |Kommentare deaktiviert für Weiter aktuell: Das Magazin vom 6. Juni mit Oliver und Gunnar in Marzahn, dem Sicherheitslaster CTOC und #FreierCode für freie Bürger
Tags: , , , , , , , , , ,
Categories: Allgemein

Ein Thema bleibt sicher in den kommenden Jahren: Cybersecurity und Datenschutz #ThinkatIBM

12. Mai 2019 Posted by Stefan Pfeiffer

Vor einigen Tagen hatte ich die Gelegenheit mit Michael Cerny, dem Verantwortlichen der IBM für Security in der Region Deutschland, Österreich und Schweiz, über die aktuellen Themen rund um Cybersecurity von mangelnder Vorbereitung der Unternehmen, den nur zu menschlichen Herausforderungen bis zu technischen Lücken, von Datenschutzregulierungen wie DSGVO bis zu Sicherheitsattacken oder aktuellen Herausforderungen im Zeitalter des Internets der Dinge in der „Operational Technology“ (OT) unterhalten. Und natürlich weisen wir beide auch auf die Veranstaltungen zum Thema Security während der Think at IBM in Berlin hin:

 

Und Schmankerl ist das C-TOC, das IBM® X-Force® Command Cyber Tactical Operations Center (C-TOC) ist das weltweit erste mobile Sicherheitszentrum, das in Berlin ab 3. Juni vor Ort sein wird: ein 23 Tonnen schwerer schwarzer Truck! Cool. Und wir werden mit dem IBM Livestudio nicht nur aus dem Laster über die Laster der Bedrohungen von Sicherheit und Privatsphäre berichten.

Read full article |Kommentare deaktiviert für Ein Thema bleibt sicher in den kommenden Jahren: Cybersecurity und Datenschutz #ThinkatIBM
Tags: , , , , , ,
Categories: Allgemein

Cybersecurity und Datenschutz: Menschliche Bequemlichkeit und Versagen einerseits, Sicherheitslücken in Systemen andererseits

29. April 2019 Posted by Stefan Pfeiffer

Viele Nutzer predigen bei der Privatsphäre nach außen hin Wasser, trinken im stillen Kämmerlein aber dann doch lieber Wein – indem sie aus Bequemlichkeit oder Ahnungslosigkeit Daten preisgeben.

So schreibt Michael Kroker in seinem Rant vom 26. April und trifft ins Schwarze. Auf der einen Seite wollen wir alle mehr Datenschutz, Privatsphäre und Sicherheit, auf der anderen Seite sind die meisten von uns bequem. Aus Bequemlichkeit geben wir unsere Daten „weg“, die von dem ein oder anderen Konzern monetarisiert werden. Oft sind wir einfach nur zu bequem, wenn es beispielsweise um unser Passwort geht. Die zweistufige Authentifizierung ist nun halt mal etwas aufwendiger – aber eben sicherer.

Doch das Thema Sicherheit geht auf vielerlei Ebenen noch deutlich weiter. Privat, im Geschäftsleben, aber auch im Alltag, wo unsere Infrastruktur mehr und mehr bedroht wird.  Mal ist es menschliche Bequemlichkeit, mal sind es technische Unzulänglichkeiten, Sicherheitslücken in den Systemen, die uns bedrohen. Das Problem sitzt zwar oft, aber nicht immer vor dem Rechner oder am Steuer oder im eigenen Heim.

Das vernetzte Auto als Sicherheitsrisiko

Hackern ist es vor kurzem gelungen, das Elektroauto Tesla Model 3 zu knacken, wie die NZZ berichtet. Im Rahmen eines Hacker-Contests entdeckten sie eine Sicherheitslücke im auf dem Open-Source-Browser-Projekt Chromium von Google basierenden Infotainment-System. Doch auch schon vorher wurde nachgewiesen, dass Teslas (und bestimmt nicht nur die) „geknackt“ werden können. Die Basler Polizei durfte, wie futurezone.at berichtete, Ende vergangenen Jahres wegen Datenschutzbedenken extra umgebaute Teslas nicht in Betrieb nehmen, da der Autohersteller die Fahrzeuge remote kontrollieren könne und natürlich wisse, wo sich diese aufhielten.

Neue Fahrzeuge werden und sind immer mehr fahrende Computer, manchmal „Smartphones auf Rädern“ genannt, deren Apps und Steuerungssysteme Daten erfassen, vom Bewegungsprofil bis potentiell zu den Kameras. Solche Daten können missbraucht, das ganze Fahrzeug im schlimmen Fall angegriffen werden.

100 Millionen Zeile Code beim #ConnectedCar

Das IBM Institite for Business Value (IBV) hat übrigens aktuell zu diesem Thema den Report Securing privacy for the future of connected cars publiziert, der hier heruntergeladen werden kann. Demnach prozessieren vernetzte Autos (#ConnectedCars) bis zu 25 Gigabyte Daten pro Stunde. Die entsprechende Software des Fahrzeugs könne mehr als 100 Millionen Zeilen Code umfassen, deutlich mehr, als die 93.5 Million Zeilen Code, die es benötigt die Flug- und Unterstützungssysteme einer Boeing 787 zu. betreiben. Da wundert es auch nicht, dass beim Volkswagen der 8. Generation laut FAZ  „haperte es vor allem an der Vernetzung des Autos und an der Ausstattung mit softwaregestützten Funktionen und Diensten„.

Die Fragen rund um Datenschutz in Kombination mit Sicherheit werden uns bei allem Komfort und oft auch sinnvollen Anwendungsgebieten überall dort beschäftigen, wo immer mehr „intelligente“ Geräte und Software zum Einsatz kommen, vom eigenen Wagen bis zum Smart Home. Je mehr Devices wir im eigenen Heim einsetzen, desto potentiell anfälliger wird auch das eigene Heim.

Angriffsziel: Unser aller Infrastruktur

Aber denken wir weiter. Es geht unterdessen um weit mehr als das eigene Zuhause. Unsere Infrastruktur könnte angegriffen, gehackt, stillgelegt werden, wird es teilweise schon. Eva Wolfangel berichtet auf Zeit Online über Hackerangriff auf ein saudi-arabisches Kraftwerk, der zu eklatanten Umweltschäden hätte führen können. Auch hier war wohl wieder eine Mixtur von menschlichem – die Fernwartungssoftware sei aus Bequemlichkeit eingeschaltet gewesen, obwohl gerade nicht benötigt – und technischem Versagen – die Steuerungsmodule eines Herstellers wurden „geknackt“ – schuld.

Saudi-Arabien, das ist weg und die blicken es eh nicht? Von wegen, auch unsere Infrastruktur ist angreifbar. Erinnern wir uns nur an den Trojaner WannaCry, der eine Lücke in Windows nutzte und auch in Deutschland IT-Systeme der Deutschen Bahn, von Krankenhäusern und Unternehmen befiel. Und die Bedrohung nimmt zu: Laut eines Berichtes der Welt vom Februar 2019 vermeldet das Bundesamt für Sicherheit in der Informationstechnik deutliche mehr und eine neue Qualität Cyberangriffe. Die Gefahr sei deutlich gestiegen, dass Strom, Wasser oder andere lebenswichtige Versorgung angegriffen und ausfallen könnten.

Auch der TÜV Rheinland stößt in seinem Cybersecurity Trend Report 2019 (Download gegen Registrierung hier) in dieses Horn: Cyberangriffe werden zu einem immer höheren Risiko und bedrohen Technologien wie Operational Technology (OT) in der Industrie sowie das Internet der Dinge. Hier möchte ich auch nochmals auf mein Gespräch mit Lisa Unkelhäußer von der Hannover Messe 2019 verweisen.

Das Thema muss uns weiter beschäftigen: privat, in Unternehmen und Verwaltungen und als generelle Bedrohung unserer Infrastruktur. Weniger Bequemlichkeit der Anwender in jedem Lebenszusammenhang, intensive Schulungen, immer wieder, ja lebenslang, und natürlich auch sinnvolle Vorkehr- und Abwehrmaßnahmen müssen die Antwort sein.

Thema auf der Think at IBM am 5. und 6. Juni in Berlin

Das Thema Cybersecurity und Datenschutz wird auch ein zentrales Thema während der Think at IBM zwischen dem 20. Mai und 29. Juni 2019 in Berlin sein. Das Security Summit am 5. und 6. Juni ist sicherlich das zentrale Event zu diesem Thema. Auch im Livestudioio zur Think at IBM werden wir ganz sicher über das Thema berichten. Lust zu einigen Gesprächsrunden, Lisa Unkelhäußer, Michael Cerny, Carsten Dietrich und Martin Runde. Vielleicht kommt ja auch das BSI zu der ein oder anderen Diskussionsrunde dazu?

Und natürlich sind wir auf das C-TOC gespannt, das 23 Tonnen schwere Trainings-, Simulations- und Sicherheitszentrum auf Rädern – integriert in einen beeindruckenden schwarzen Truck. Den werden wir uns im Livestudio nicht entgehen lassen. Hier ein Vorgeschmack:

(Stefan Pfeiffer)

Michael Kroker hat in seinem Blog eine für sich sprechende Infografik von Varonis veröffentlicht, in der die Wahrscheinlichkeit eines Cyberangriffs im Vergleich mit Einbruch, Blitzschlag verglichen werden: Die Wahrscheinlichkeit eines Cyberangriffs liegt bei 1 zu 4, bei einem Wohnungseinbruch bei 1 zu 345

CyberWahrscheinlichkeitIG

Read full article |Kommentare deaktiviert für Cybersecurity und Datenschutz: Menschliche Bequemlichkeit und Versagen einerseits, Sicherheitslücken in Systemen andererseits
Tags: , , , , , , , ,
Categories: Allgemein

Re: Make sure that the “Names.nsf” cannot be accessed via Internet!

11. Februar 2019 Posted by Sven Hasselbach

Because my comments are still awaiting moderation (tried two times hours ago, but no luck), I have decided to answer to this post from Milan in my blog:

„Yes, it is not good that these passwords are reachable from „outside“, but keep in mind that under normal circumstances the access to the names.nsf is restricted by default, because “Anonymous” is set to “No access”. So, the “exposed data” to the web are the informations which would be accessible for all users when using the Notes client.

The exposed data itself are hashed and salted, so even if the password hashes are reachable this does not mean that this is directly a security nightmare – you should not sleep well, but it is enough time to fix this in the next days. I don’t want to play it down, but the CVE is from 2016 and does not contain an exploit to extract the passwords from the hashes.

For more details, Ben has written a very informational post on passwords and hashes: Deep Dive into IBM Domino Security Part 1: Password Hashes

Also, you can use xACL for protecting these sensitiv data. Here is what IBM wrote about this topic: Securing Internet passwords„

Read full article |Kommentare deaktiviert für Re: Make sure that the “Names.nsf” cannot be accessed via Internet!
Tags: ,
Categories: Allgemein

Exchange API for Java: Allow *all* type of certificates

29. Januar 2019 Posted by Sven Hasselbach

I had troubles accessing internal Exchange servers using the EWS Java API because of self-signed SSL certificates (and not matching host names), that’s why I created a patch which overrides the existing certificate check and allows all type of SSL certificates.

The code can be found here: https://github.com/hasselbach/ews-java-api

Be aware that this is lowers the security, so you should know what you are doing before using it in productive environments!

Read full article |Kommentare deaktiviert für Exchange API for Java: Allow *all* type of certificates
Tags: , , , , , ,
Categories: Allgemein

#9vor9 Premiere 2019 frei nach @gsohn: #Habeck, #Hass und #Hacker

15. Januar 2019 Posted by Stefan Pfeiffer

Unser Gunnar ist in der zweiten Januar-Woche wieder aufgewacht und hat zu #9vor9 geblasen und Lars und ich sind gekommen. Unser Thema – klar – war das „Hackerangriff“, das „Doxing“, warum Emma und Otto Nomalanwender/in überfordert sind und dass der Staat eigentlich Open Source-Plattformbetreiber werden müsste – daran aber wohl keine Partei wirklich Interesse hat. Die Lobbyisten eh nicht. Hier über den Periscope-Link reinhören. Weiter unten füge ich dann einig Tweets und Pins zum Thema ein:

Zum Thema:

Read full article |Kommentare deaktiviert für #9vor9 Premiere 2019 frei nach @gsohn: #Habeck, #Hass und #Hacker
Tags: , , , , , , ,
Categories: Allgemein

Das Internet of Things (IoT), der Stoff, aus dem Träume auch im eigenen Heim gemacht sind?

27. November 2018 Posted by Stefan Pfeiffer

Welch ein Pamphlet von Greg James, Global Chief Strategy Officer der Havas Media Group, auf LEAD. Die schöne neue Welt der vernetzten Städte und des voll automatisierten Heims …

Unser Zuhause ist nicht nur unser Zufluchtsort, sondern auch ein sorgfältig kalibriertes und hochgradig personalisiertes Ökosystem, das auf uns allein oder wenige andere Personen angepasst ist. Oder zumindest wird es dies bald sein.

So sehr ich mich über die Aussicht freue, in einer Smart City zu leben, umso ungeduldiger warte ich auf den Tag, an dem mein Roomba nicht nur die Wollmäuse entfernt, sondern sich auch noch um die Wäsche, das schmutzige Geschirr, und meine Steuererklärung kümmert – man wird ja noch träumen dürfen.

über Smart Cities: Wie die Städte der Zukunft aussehen werden | LEAD

Und wenn ich seine Träume lese, denke ich an meinen Roomba, der immer am Teppich und an Ecken gescheitert ist und deshalb verkauft wurde. Und dann frage ich nach der Sinnhaftigkeit und stolpere wenig später über den Beitrag von Mirko Borsche, der sich zu Hause sicherer fühlen wollte, und deshalb „eine Welcome-Kamera von Netatmo“ zum Testen bestellte:

Sie nimmt jeden Menschen auf, der zur Tür hereinkommt, identifiziert ihn per Gesichtserkennung und verschickt eine Nachricht an den Wohnungsbesitzer … Handelt es sich um eine noch nicht abgespeicherte Person, bekommt man eine Nachricht mit dem Hinweis: „Unbekanntes Gesicht gesehen.“

Der große Vorteil liegt also darin, dass man durch die Fotos der Kamera Einbrecher identifizieren könnte. Andererseits gibt es auch einen Nachteil. Wenn man – wie ich – vergisst, die Privatsphäre so einzustellen, dass bekannte Gesichter nicht mehr gemeldet oder aufgezeichnet werden, kriegt man jedes Mal eine Nachricht, wenn jemand an der Kamera vorbeiläuft. Da das in einer Wohnung recht häufig passiert, habe ich inzwischen gefühlt 10.000 Fotos von meiner Familie, dem Nachbarsjungen und auch von mir selber zugeschickt bekommen.

über Welcome-Kamera: Mirko Borsche will sich zu Hause sicherer fühlen | ZEITmagazin

10.000 Fotos  und allein der Name Welcome-Kamera, quasi willkommen, liebe Einbrecher oder was … Sorry, natürlich das genau nicht. Einbrecher sollen ja ferngehalten werden. Auch ich habe mal überlegt, mir eine Sicherheitslösung wie das Arlo Pro System von Netgear zu zulegen, mich aber bisher dagegen entschieden. Wegen des Preises und des Blickes meiner Göga. Meine geplante Ausrede war, dass in der Nachbarschaft eingebrochen wurde, aber ich habe mich dann (doch noch) am Riemen gerissen.

In meinem Smart Home hat es bisher nur zur Heizungssteuerung gereicht und ganz ehrlich hätte ich mir hier eine komfortablere Lösung gewünscht. Gut, das MAX!-System von ELV tut es, hat aber nicht gerade die benutzerfreundlichste Bedienung. Zum Zeitpunkt, als ich MAX! anschaffte, fand ich kein in preislich vernünftiges System, das mit zu Apple Home kompatibel war. Meine heimischer IT-Zoo ist halt total veräppelt.

Und gehen wir mal einen Schritt zurück. Liest man den typisch amerikanischen Beitrag von Greg James, dann ist künftig alles vernetzt vom Kochtopf bis zur Clospülung. Wunderbare neue Welt:

Für viele von uns ist der Begriff eines vollständig verwirklichten Internets der Dinge (IoT) – einschließlich wirklich digital verbundener Städte – der Stoff, aus dem Träume gemacht sind.

über Smart Cities: Wie die Städte der Zukunft aussehen werden | LEAD

An der Stelle muss ich dann schon einmal STOP sagen und dazu raten, darum bitten, das Hirn bei der Vernetzung – hier des eigenen Heims, aber auch generell von Städten und Unternehmen – einzuschalten und die Chancen und Risiken bewusst abzuwägen. Wie schreibt Mirko Bosche:

Die Digitalisierung soll helfen, das Wohnen nicht nur einfacher und effizienter zu machen, sondern auch sicherer.

über Welcome-Kamera: Mirko Borsche will sich zu Hause sicherer fühlen | ZEITmagazin

Was ist überhaupt sinnvoll und – ganz wichtig – was ist sicher? Unter Experten ist es keine Frage, dass mit immer mehr Sensoren und „Devices“ im Internet der Dinge (Internet of Things, IoT) auch immer größere Sicherheitsanforderungen auf Unternehmen, aber eben auch Privatpersonen zukommen. Ende 2016 fielen 900.000 Telekom-Router durch eine Schadsoftware aus. Nun streiten gerade das Bundesamt für Sicherheit in der Informationstechnik (BSI) und der Chaos Computer Club (CCC)  darüber, wie man auf das „Mindesthaltbarkeitsdatum“ von Routern aufmerksam machen sollte, also den Zeitraum kennzeichnet, wie lange ein Router mit aktueller Firmware (Software) unterstützt wird. Der CCC will einen „Aufkleber auf der Packung, als wäre der Router ein leicht verderbliches Lebensmittel“.

Und es geht latent mit Vorfällen weiter, manchmal nicht öffentlich kommuniziert, manchmal sehr publik wie im Oktober 2017. Da wurde durch KRACK die WPA2-Verschlüsselung von drahtlosen Netzwerken bedroht und die entsprechend Meldung schaffte es bis in die Tagesschau.

Jedes Gerät im Internet der Dinge ist angreifbar

KRACK war nur ein Fanal: Router, Überwachungskameras, das per W-LAN öffnende Garagentor, der Kühlschrank, alle SmartHome-Geräte, alle Devices, das im Internet der Dinge in das Netzwerk eingebunden werden, müssen auf dem neuesten Sicherheitsstand sein und sollten die neuesten Patches eingespielt haben. Aber das ist bestimmt nicht immer der Fall und so raten viele Experten beispielsweise dazu, nur Geräte von größeren, bekannten Herstellern zu kaufen.

Und nochmals explizit: Je vernetzter das eigene Heim ist, je mehr IoT-Geräte dort im Einsatz sind, umso wichtiger ist das Thema Sicherheit. Ich glaube nicht – und das ist snobistisch gemeint, denn auch ich blicke da nicht durch -, dass jeder Häusle- und Heimbesitzer sich der Risiken bewusst ist und die entsprechenden Kenntnisse hat.

Drüber nachdenken: Was machen Alexa & Co mit uns oder wir mit ihnen?

Über eine andere potentielle Sicherheitsbedrohung habe ich in den vergangenen Monaten zur Genüge geschrieben. Für mich sind smarte Lautsprecher und Geräte wie Alexa von Amazon oder Google Assistant ebenfalls ein Sicherheitsrisiko. Wer garantiert, dass unsere Gespräche nicht aufgezeichnet werden? Sind die Geräte wirklich ausgeschaltet, wenn ich sie OFF schalte? Wo und wie werden die erfassten Gespräche und damit Daten gespeichert? Wer hat Zugriff darauf und vermarktet sie potentiell? Platziert man mit Alexa & Co den permanenten Dauerverkäufer im eigenen Wohnzimmer? Amazon freut sich darüber in vielerlei Beziehung. Alexa wird zum neuen Windows, zum Betriebssystem unseres Heims und bald Autos und hält auch teilweise Einzug in Unternehmen

Nochmals zum Ursprung: Was ist überhaupt sinnvoll, habe ich gefragt. Brauche ich wirklich den Kochtopf, den ich per Sprachsteuerung sage, dass ich zu spät komme. Ist das der riesige Nutzen- und Komforteffekt? Meiner Meinung nach nicht. Die Frage Brauche ich das wirklich? sollte durchaus gestellt werden dürfen. Und, Männer, manchmal auf Eure Frau hören.

Vernetzen, aber dabei Hirn einschalten

Zum Abschluss des Beitrags nochmals klar und deutlich: Ich bin ein absoluter Freund intelligenter Geräte und damit des Internet of Things auch im eigenen Heim. Wir sollten uns bewusst dort vernetzen, wo es Sinn macht. Ich bin davon überzeugt, dass sich Sprachassistenten wie Alexa oder Siri durchsetzen werden und die natürliche Art sind, wie man gerade zu Hause Geräte bedienen sollte. Wenn ich das schreibe, schaue ich beispielsweise auf sage und schreibe 7 Fernbedienungen, aber das ist eines eigenen Beitrags wert. Und, liebe Frauen, wir Männer dürfen auch mal die Tech Gadgets spielen, aber lasst uns alle unser Hirn einschalten, was das Thema Sicherheit und Datenschutz angeht. Gerade auch im Smart Home.

(Stefan Pfeiffer)

P.S. Bei wem die doch wohl vorhandene klassische Rollenverteilung Mann will neue technische Spielzeuge und Frau ist (in dieser Beziehung) vernünftig, anders herum verteilt ist, der möge meine Zuordnung oben verzeihen. Es ist in keiner Weise diskriminierend gemeint und auch manche Männer lieben Schuhe!

Read full article |Kommentare deaktiviert für Das Internet of Things (IoT), der Stoff, aus dem Träume auch im eigenen Heim gemacht sind?
Tags: , , , , , , , , , , , , ,
Categories: Allgemein

node node.js, domino-db & Docker (12): DominoDB and a big NO-NO?

15. November 2018 Posted by Sven Hasselbach

Disclaimer: This is a response on Heiko’s post about his security considerations with the domino-db module. It is good to have such a discussion, and hopefully this discussion will go on. This is my personal view on this topic. If you have another opinion, feel free to add a comment.

What is gRPC?

gRPC was designed for inter-system communication, and uses HTTP/2 instead of HTTP.

Is it cool?

Yes. And super fast. Millenials will love it. It’s lightweight. Did I mention that it is super fast?

Can I use it in my node.js application for accessing Domino?

gRPC was designed exactly for this purpose. You can also directly use it for connections from a desktop or mobile app, if you want. Or for data access from IOT devices. It may be used directly within the browser in the future (if IBM/HCL gives us access to it.)

Is it safe?

Google developed it for its microservices architecture. If you are not trusting Google’s technical experience, you should shutdown your computer right now. And don’t power it on again.

Should others systems be allowed to access the Proton task directly?

Why not? This is inter-system communication. The traffic is encrypted when using certificates. If you need an additional security layer for limiting access, use a firewall. Or tunnel the traffic with VPN/SSH. This is the typical setup for cloud applications.

The Proton port shouldn’t be reachable from outside

Why not? NRPC is also open. And HTTP, HTTPS, LDAP, SMTP, IMAP, POP3, …

gRPC is bad and voodoo!

Really? What do you think does NRPC stands for? You are using RPC for decades… By the way, which encryption algorithms are you using on your Domino servers for NRPC?

What are theses client certificates?

The certificates are the same as a username / password. Nothing else. And nothing more. This has nothing to do with a Notes ID.

Isn’t it insecure to use client cerificates?

No, because it is the same as when you giving access to your system with username/password. Ever created a webservice provider or a REST API for a 3rd Party system? How do you give these systems access?

But I have to trust a external system…

Sure you need to. Same thing must other systems do when you are connecting to them from Domino. This is the reason why you have to fill out 500 pages and get a sign-off by a long list of involved persons before this is allowed (especially in the financial sector).

I am running a local node.js server on my domino…

Fine. This is still as insecure as running the system somewhere in the cloud. If you are doing the user authentication in your node.js application, you are still making a „insecure“ request to Domino, and Domino has to „trust“ the incoming request.

The client key is stored without password!

If the „other“ system is compromised, it doesn’t matter which kind of authentication was used. Where do you think are they storing username / password for accessing your WebService / REST API?

How to handle user authentication?

This is an open topic. domino-db is still a beta. But this must be solved by IBM/HCL. At least we need a way to run queries „in the name of“ a user.

But you also encrypt the keys…

Yes. But for other reasons: For preventing accidential check-ins in code repositories. And to prevent to store them in backups or direct access from „outside“ by a bug.

I have created a REST API with node.js as a wrapper for gRPC/domino-db

So why did you use the domino-db module? Write it directly on top of Domino, as Servlet or XPages REST API. Then you don’t have any limitations and the authentication problem is solved too.

But this is a secure approach to use it in production!

No. It’s a beta. Don’t use it in production. Period.

You were sceptical about node.js & Domino

Yes, and I am still thinking there is a lot of work to do to use it. But please read again what I have written in my post:

"So far I am still open for a big surprise and hopefully HCL can convince me of the contrary."

Read full article |Kommentare deaktiviert für node node.js, domino-db & Docker (12): DominoDB and a big NO-NO?
Tags: , , ,
Categories: Allgemein

node.js, domino-db & Docker (10): Protecting Proton Keys

12. November 2018 Posted by Sven Hasselbach

Before we are looking into the details how to setup a non-anynomous connection to Domino’s Proton server, I have an advice for protecting the key files required for the connection.

The keys are not password protected, and this is a high risk which should be avoided: First, if you make a mistake or if there is a bug in the software, the keys could be accessed from „outside“. And second, if you check in your code in a repository, the IT security should roast you. It’s clear that the keys are still unprotected if someone hacks the application, but this is a different topic.

First thing to to is to encrypt the keys with AES. To achive this, we are using openssl:

openssl enc -aes-256-cbc -k "0123456789" -in domino-express.key -out domino-express.key.enc

The parameter -k is the key to use for encryption. The path to the unencrypted file is passed with -in, and -out is the path of the encrypted file.

I also encryted the .crt files, which is not required, but it does not hurt either.

The config.js file must now be changed to the follwing (a new method for reading and decrypting the files with openssl is added):

const exec = require('child_process').execSync;

const path = require('path');

/**
 * reads an aes-256-cbc encrypted file & decrypts it
 * 
 * @param {*} fileName 
 *  the encrpyted file 
 * @param {*} key 
 *  the decryption key
 */
const readFileEncrypted = (fileName, key) => {
  try {
    // resolve the filepath
    const filePath = path.resolve(fileName);

    // use openssl to decrypt the keys
    return exec(`openssl enc -d -aes-256-cbc -k "${key}" -in "${filePath}"`, 
    (error, stdout) => {
      if (error) {
        console.error(`exec error: ${error}`);
      }
      return stdout;
    });
  } catch (error) {
    console.error(error);
    return undefined;
  }
};

// the password (stored in environment)
const password = process.env.PASSWORD_KEYFILES;
if (!password) {
  console.error('Environment Variable "PASSWORD_KEYFILES" is not set.');
  process.exit(1);
}

// load the keys & certificates
const rootCertificate = readFileEncrypted('./app/certs/ca.crt.enc', password);
const clientCertificate = readFileEncrypted('./app/certs/domino-express.crt.enc', password);
const clientKey = readFileEncrypted('./app/certs/domino-express.key.enc', password);

// check if the keys are ok 
if (!rootCertificate || !clientCertificate || !clientKey) {
  console.error('Unable to load certificates and/or key.');
  process.exit(1);
}

const Config = {
    serverConfig: {
        hostName: process.env.NODE_ENV === 'development' ? 'dev.example.com' : 'example.com', // Host name of your server
        connection: {
          port: '3002', // Proton port on your server
          secure: true,
        }, 
        credentials: {
            rootCertificate,
            clientCertificate,
            clientKey,
          },
      },
      databaseConfig: {
        filePath: 'testnode.nsf', // The database file name
      }
};

module.exports = Config;

But where to store the key? Nowhere, the key is stored in an evironmental variable.

This line reads the value from the variable PASSWORD_KEYFILES.

const password = process.env.PASSWORD_KEYFILES;

When running your application in a docker container, just start the container with the following command including the variable:

docker run -e "PASSWORD_KEYFILES=0123456789" --name dominoexpress -p 3000:3000 -d -it shasselba/domino-express

To use it in a IDE like Visual Studio Code, you have to add it to the debugging configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Programm starten",
            "program": "${workspaceFolder}/app/bin/www",
            "env": {"PASSWORD_KEYFILES": "0123456789"}
        },
    ]
}

Now you can add the .enc files to your application in folder /app/certs without worrying about it. If the variable is not set, the application terminates with error code 1.

P.S. Don’t forget to remove the original key files from your project!

Read full article |Kommentare deaktiviert für node.js, domino-db & Docker (10): Protecting Proton Keys
Tags: , , , , ,
Categories: Allgemein

node.js, domino-db & Docker (8): Security

9. November 2018 Posted by Sven Hasselbach

Security is a big topic when developing node.js applications. A simple helper for writing secure code is the plugin. It checks for common mistakes during writing code, for example using the eval statement with external input, or unsafe RegEx expressions…

To install the plugin, just save it to the project with

npm install --save-dev eslint-plugin-security

To enable it, you need to change the .eslintrc configuration file:

{
  "plugins": ["security"],
  "extends": [
    "plugin:security/recommended",
    "rallycoding"
  ]
}
Read full article |Kommentare deaktiviert für node.js, domino-db & Docker (8): Security
Tags: , ,
Categories: Allgemein

java.security.AccessControlException kills productivity

9. April 2018 Posted by Sven Hasselbach

Dear IBM, can you please remove the totally useless java policy restrictions? Especially for agents running on the server?

I can’t imagine how much life time and customers money was spent during the last decades just to find a workaround for these limitations. The Q&A sites are full of questions about problems with this topic, and I never met someone who found the restriction usefull.

It’s 2018, and writing something in Lotus Script just to „solve“ this issue makes absolutly no sense. The whole „Let’s restrict Java as much as we can“ is pita – everyone knows how to ship around these restrictions. The „bad guys“ are not stopped, only the „good developers“ will be limited.

By the way: Are these limitations planned for notes.js integration? If so, please drop it immediatly.

Read full article |Kommentare deaktiviert für java.security.AccessControlException kills productivity
Tags: , ,
Categories: Allgemein

The anatomy of a LTPA token

27. März 2018 Posted by Sven Hasselbach

LTPA Tokens

LTPA tokens are widely used in the IBM world for authentication between different physical machines, also known as WebSSO. There are two types available, LTPA1 and LTPA2.

LTPA2 is commonly used with WebSphere, and Domino can import the keys to work with this kind of tokens – they can be validated, but only WebSphere is able to generate them. LTPA1 is the token normally used in the Domino world, and that’s the token I will write about.

First, what is a LTPA token in general? It is a BASE64 encoded String containing the information about the user, including some timestamps. To avoid a security problem, the token is hashed and then encrypted (see here: LTPA versions and token formats).

So let’s look into a real world example. Here is a LTPA1 token from my domino server*:

77+9AQIDNUFCMTJBNjk1QUIxMzg3OUNOPVN2ZW4gSGFzc2VsYmFjaC9PPUhhc3NlbGJhL089Q0gwezcFKix7Fy00cg==

Now here comes the BASE64 decoded version:

As you can see, there is my username insinde of the token. And at this point I am a little bit confused, because the IBM writes in the linked article above:

LTPA1 signatures are generated with SHA-1 as the hash algorithm, and RSA (1024-bit key) as the encryption algorithm. After the digital signature is attached, the user data and signature are encrypted with a 3DES key from the LTPA key file.

Maybe it is because I have super powers which allow me to decrypt the 3DES encrypted userdata in my brain. But I think it is just a wrong information, and the userdata are not encrypted with 3DES.

This does not make the LTPA1 token unsafe, there is still a SHA-1 hash which protects the userdata from beeing changed in a text editor. Let’s look how the token is build up:

Anatomy of LTP1 Token

Byte 0-3 4-11 12-19 20 – ? ? – ? + 20
Content Header Creation Expiration Username Hash

Header (4 Bytes)

Byte 01 02 03 04
Value 0 1 2 3

Creation & Expiration (each 8 Bytes)

These values are Java Dates stored as Long value.

Username (Length different)

A string containing the abbreviated form of the current username. The length varies.

Hash (20 Bytes)

A SHA-1 hash, 160 Bits long. The hash is generated by adding the LTPA secret at the end of the userdata; the result is added to the end of the LTPA token.

The Problem

The problem with LTPA1 token is the use of an insecure hash algorithm. We had to change all SSL certificates because it, the NIST has deprecated it in 2011. And the 3DES encryption is a myth.

But we are still protecting our infrastructure with this weak algorithm…

*: no, it’s not 😉

Read full article |Kommentare deaktiviert für The anatomy of a LTPA token
Tags: , , ,
Categories: Allgemein

Der neue Hacker-Angriff: Weiteres Indiz für die Notwendigkeit eines potenten Digitalministeriums?

3. März 2018 Posted by Stefan Pfeiffer

Der Hackerangriff auf das deutsche Regierungsnetz geht durch alle Gazetten. Die Informationslage ist – so weit ich das übersehen kann – derzeit unvollständig und eine komplette, seriöse Einschätzung, was warum passiert ist, schwierig. Der Vorfall ist aber nur ein weiteres Beispiel dafür, dass das Thema Security in 2018 noch relevanter und wichtiger werden wird. Und…

via Der neue Hacker-Angriff: Weiteres Indiz für die Notwendigkeit eines potenten Digitalministeriums? —  CIO Kurator 

Read full article |Kommentare deaktiviert für Der neue Hacker-Angriff: Weiteres Indiz für die Notwendigkeit eines potenten Digitalministeriums?
Tags: , , , , , , ,
Categories: Allgemein
« Older Entries
Newer Entries »