Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #624154 > unrolled thread

Crowdstrike

Started by"Dr. Joachim Neudert" <neudert@5sl.org>
First post2024-07-19 10:26 +0200
Last post2024-08-03 13:44 +0200
Articles 20 on this page of 138 — 34 participants

Back to article view | Back to ger.ct

Contents

  Crowdstrike "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-07-19 10:26 +0200
    Re: Crowdstrike Ulrich Weise <ulrich.weise@t-online.de> - 2024-07-19 11:30 +0200
    Re: Crowdstrike Ulrich Weise <ulrich.weise@t-online.de> - 2024-07-19 11:35 +0200
      Re: Crowdstrike "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-07-19 11:39 +0200
        Re: Crowdstrike Goetz Schultz <ng.expire1225@goetz.co.uk> - 2024-07-19 10:53 +0100
          Re: Crowdstrike "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-07-19 12:46 +0200
        Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-19 12:56 +0200
        Re: Crowdstrike Th.me@thomas-heier.de (Thomas Heier) - 2024-07-20 02:02 +0200
          Re: Crowdstrike Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-07-20 06:28 +0200
          Re: Crowdstrike Ulrich Weise <ulrich.weise@t-online.de> - 2024-07-20 10:49 +0200
        Re: Crowdstrike Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-21 12:16 +0200
      Re: Crowdstrike Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-07-19 09:51 +0000
      Re: Crowdstrike Dr. Joachim Neudert <neudert@5sl.org> - 2024-07-19 11:53 +0000
        Re: Crowdstrike Ruediger Lahl <ruediger.lahl@gmx.de> - 2024-07-19 13:55 +0200
          Re: Crowdstrike Dr. Joachim Neudert <neudert@5sl.org> - 2024-07-19 11:59 +0000
        Re: Crowdstrike Frank Hucklenbroich <hucklenbroich@gmx.net> - 2024-07-20 17:05 +0200
      Re: Crowdstrike Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-19 14:35 +0200
      Re: Crowdstrike Peter McD <peter.posts@gmx.net> - 2024-07-19 14:49 +0200
        Re: Crowdstrike Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-19 15:04 +0200
          Re: Crowdstrike Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-07-19 16:01 +0200
            Re: Crowdstrike Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2024-07-19 16:15 +0200
            Re: Crowdstrike Michael Zink <michael@swamp.franken.de> - 2024-07-19 16:24 +0200
              Re: Crowdstrike Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2024-07-19 19:46 +0200
            Re: Crowdstrike Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-19 17:45 +0200
              Re: Crowdstrike Gunter Kühne <kuehne-g@freenet.de> - 2024-07-20 11:28 +0200
                Re: Crowdstrike Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-20 14:52 +0200
        Re: Crowdstrike "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-07-19 15:20 +0200
          Re: Crowdstrike Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-07-19 16:03 +0200
          Re: Crowdstrike Michael Zink <michael@swamp.franken.de> - 2024-07-19 16:25 +0200
          Re: Crowdstrike Jörg Tewes <jogi1964@gmx.net> - 2024-07-19 23:11 +0200
          Re: Crowdstrike Gunter Kühne <kuehne-g@freenet.de> - 2024-07-20 11:29 +0200
          Re: Crowdstrike Joerg Walther <joerg.walther@magenta.de> - 2024-07-20 11:30 +0200
          Re: Crowdstrike Lars Gebauer <lgebauer@live.de> - 2024-07-20 11:59 +0200
          Re: Crowdstrike Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-07-27 05:58 +0000
        Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-20 00:25 +0200
      Re: Crowdstrike Michael Pachta <mipani@gmx.de> - 2024-07-19 20:09 +0200
        Re: Crowdstrike Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-07-20 06:37 +0200
      Re: Crowdstrike Shinji Ikari <shinji@gmx.net> - 2024-07-20 08:12 +0200
        Re: Crowdstrike Dr. Joachim Neudert <neudert@5sl.org> - 2024-07-20 09:46 +0000
    Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-19 12:53 +0200
      Re: Crowdstrike Jörg Tewes <jogi1964@gmx.net> - 2024-07-19 23:13 +0200
        Re: Crowdstrike "Wendelin Uez" <wuez@online.de> - 2024-07-20 11:24 +0200
          Re: Crowdstrike Dr. Joachim Neudert <neudert@5sl.org> - 2024-07-21 12:26 +0000
            Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-21 14:33 +0200
              Re: Crowdstrike Dr. Joachim Neudert <neudert@5sl.org> - 2024-07-21 12:35 +0000
    Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-07-19 22:59 +0200
      Re: Crowdstrike Jörg Tewes <jogi1964@gmx.net> - 2024-07-19 23:18 +0200
        Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-07-20 02:32 +0200
          Re: Crowdstrike Jörg Tewes <jogi1964@gmx.net> - 2024-07-20 13:06 +0200
        Re: Crowdstrike Heinz-Juergen Kronemeyer <meierdrei@protonmail.com> - 2024-07-20 11:19 +0200
          Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-20 11:31 +0200
            Re: Crowdstrike Heinz-Juergen Kronemeyer <meierdrei@protonmail.com> - 2024-07-20 17:23 +0200
              Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-21 11:39 +0200
                Re: Crowdstrike Heinz-Juergen Kronemeyer <meierdrei@protonmail.com> - 2024-07-21 18:27 +0200
                  Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-21 19:38 +0200
          Re: Crowdstrike Jörg Tewes <jogi1964@gmx.net> - 2024-07-20 13:16 +0200
            Re: Crowdstrike Heinz-Juergen Kronemeyer <meierdrei@protonmail.com> - 2024-07-20 17:32 +0200
            Re: Crowdstrike nobody@nowhere.invalid (Marc Olschok) - 2024-07-23 00:34 +0000
              Re: Crowdstrike Bernd Ohm <invalid@invalid.invalid> - 2024-07-23 09:14 +0200
                Re: Crowdstrike Peter McD <peter.posts@gmx.net> - 2024-07-23 12:38 +0200
                  Re: Crowdstrike Goetz Schultz <ng.expire1225@goetz.co.uk> - 2024-07-23 14:46 +0100
                    Re: Crowdstrike Lars Gebauer <lgebauer@live.de> - 2024-07-23 16:05 +0200
                    Re: Crowdstrike Bernd Ohm <invalid@invalid.invalid> - 2024-07-23 17:05 +0200
                      Re: Crowdstrike "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-07-23 17:10 +0200
                        Re: Crowdstrike Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-07-23 18:32 +0200
                          Re: Crowdstrike Bernd Ohm <invalid@invalid.invalid> - 2024-07-23 19:27 +0200
                            Re: Crowdstrike Dr. Joachim Neudert <neudert@5sl.org> - 2024-07-23 17:37 +0000
                              Re: Crowdstrike Bernd Ohm <invalid@invalid.invalid> - 2024-07-23 19:51 +0200
                              Re: Crowdstrike Bernd Ohm <invalid@invalid.invalid> - 2024-07-23 21:24 +0200
                            Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-23 20:00 +0200
                  Re: Crowdstrike Michael Zink <michael@swamp.franken.de> - 2024-07-23 17:48 +0200
      Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-07-19 23:54 +0200
        Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-07-20 00:59 +0200
          Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-07-20 10:49 +0200
            Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-07-23 15:32 +0200
              Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-07-24 08:58 +0200
                Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-24 09:30 +0200
                  Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-07-24 10:43 +0200
                    Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-24 13:59 +0200
                Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-07-25 03:29 +0200
        Re: Crowdstrike Lothar Kimmeringer <news201705@kimmeringer.de> - 2024-07-21 20:45 +0200
          Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-21 20:57 +0200
      Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-07-20 00:33 +0200
        Re: Crowdstrike Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-07-20 06:40 +0200
          Re: Crowdstrike Gunter Kühne <kuehne-g@freenet.de> - 2024-07-20 11:38 +0200
        Re: Crowdstrike Gunter Kühne <kuehne-g@freenet.de> - 2024-07-20 11:37 +0200
      Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-20 12:01 +0200
    Re: Crowdstrike Frank Hucklenbroich <hucklenbroich@gmx.net> - 2024-07-20 17:02 +0200
      Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-21 11:40 +0200
    Re: Crowdstrike "Wendelin Uez" <wuez@online.de> - 2024-07-20 11:17 +0200
    Re: Crowdstrike Peter McD <peter.posts@gmx.net> - 2024-07-22 15:10 +0200
      Re: Crowdstrike "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-07-22 16:05 +0200
        Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-22 20:12 +0200
          Re: Crowdstrike Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-07-23 08:42 +0200
        Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-07-22 22:01 +0200
          Re: Crowdstrike Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-01 07:12 +0000
            Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-08-04 12:58 +0200
              Re: Crowdstrike "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-08-04 13:06 +0200
                Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-04 13:35 +0200
                  Re: Crowdstrike Dr. Joachim Neudert <neudert@5sl.org> - 2024-08-04 11:56 +0000
                Re: Crowdstrike Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-08-04 18:51 +0200
              Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-08-04 13:51 +0200
                Re: Crowdstrike Hendrik van der Heijden <hvdh@gmx.de> - 2024-08-04 14:12 +0200
                  Re: Crowdstrike "Dr. Joachim Neudert" <neudert@5sl.org> - 2024-08-04 14:17 +0200
                    Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-04 14:58 +0200
                      Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-08-04 15:13 +0200
                        Re: Crowdstrike Hendrik van der Heijden <hvdh@gmx.de> - 2024-08-04 16:17 +0200
                          Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-04 16:25 +0200
                            Re: Crowdstrike Hendrik van der Heijden <hvdh@gmx.de> - 2024-08-04 20:48 +0200
                              Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-04 20:55 +0200
                                Re: Crowdstrike Hendrik van der Heijden <hvdh@gmx.de> - 2024-08-04 21:16 +0200
                                  Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-04 23:32 +0200
                                  Re: Crowdstrike Ruediger Lahl <ruediger.lahl@gmx.de> - 2024-08-04 23:37 +0200
                                  Re: Crowdstrike Shinji Ikari <shinji@gmx.net> - 2024-08-04 23:47 +0200
                  Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-08-04 15:06 +0200
                Re: Crowdstrike "Jörg Tewes" <jogi1964@gmx.net> - 2024-08-04 23:18 +0200
        Re: Crowdstrike Michael Zink <michael@swamp.franken.de> - 2024-07-23 14:43 +0200
          Re: Crowdstrike Lars Gebauer <lgebauer@live.de> - 2024-07-23 15:24 +0200
            Re: Crowdstrike Michael Zink <michael@swamp.franken.de> - 2024-07-23 17:56 +0200
              Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-23 19:13 +0200
                Re: Crowdstrike Michael Zink <michael@swamp.franken.de> - 2024-07-23 21:39 +0200
                  Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-23 22:28 +0200
                    Re: Crowdstrike Michael Zink <michael@swamp.franken.de> - 2024-07-29 18:51 +0200
                      Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-07-29 19:17 +0200
                        Re: Crowdstrike Wolfgang  Εnzinger <we_usenet@nurfuerspam.de> - 2024-08-02 01:26 +0200
                          Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-02 07:42 +0200
                          Re: Crowdstrike Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-08-02 09:38 +0200
                            Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-08-02 11:38 +0200
                            Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-02 12:25 +0200
                              Re: Crowdstrike Wolfgang  Εnzinger <we_usenet@nurfuerspam.de> - 2024-08-02 13:38 +0200
                                Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-02 16:37 +0200
                                  Re: Crowdstrike Wolfgang  Εnzinger <we_usenet@nurfuerspam.de> - 2024-08-02 16:55 +0200
                                    Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-02 17:39 +0200
                                      Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-08-02 18:50 +0200
                                        Re: Crowdstrike Wolfgang  Εnzinger <we_usenet@nurfuerspam.de> - 2024-08-02 19:35 +0200
                                        Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-02 21:47 +0200
                                          Re: Crowdstrike Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2024-08-03 11:52 +0200
                                            Re: Crowdstrike Michael Bode <m.g.bode@web.de> - 2024-08-03 13:44 +0200

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#624396

FromGoetz Schultz <ng.expire1225@goetz.co.uk>
Date2024-07-23 14:46 +0100
Message-ID<v7oc6q$145s5$3@dont-email.me>
In reply to#624375
On 23/07/2024 14:31, Stefan Ram wrote:
> Peter McD <peter.posts@gmx.net> schrieb oder zitierte:
>> Was ist daran außergewöhnlich?
> 
>    Ich habe mich auch etwas gewundert über einen Satz in
>    einem Heise-Kommentar zu dieser Geschichte:
> 
> |Was wir brauchen, ist letztlich Herstellerhaftung.
> 
>    . Ich hatte bisher angenommen, daß ein Hersteller
>    grundsätzlich für Schäden in seine Produkten haftet.
> 
>    Zum Beispiel haben doch Ärzte eine Versicherung weil
>    sie für ihre Fehler haften, ähnlich bei Anwälten.
> 
>    Kann jemand erklären, warum Heise dann "Hersteller-
>    haftung" fordert?

Vermutlich wegen der Ausschlussklausel in den AGB/T&C's. CS wird sich 
hinstellen und sagen das Du es so akzeptiert hast und that's that. Es 
sei man definiert die Klausel als "unwirksam" aus $GRUND, sehe ich da 
wenig Spielraum was zu bekommen.

-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

[toc] | [prev] | [next] | [standalone]

#624398

FromLars Gebauer <lgebauer@live.de>
Date2024-07-23 16:05 +0200
Message-ID<v7odc0$13pma$3@dont-email.me>
In reply to#624396
Am 23.07.2024 um 15:46 schrieb Goetz Schultz:
> On 23/07/2024 14:31, Stefan Ram wrote:
>> Kann jemand erklären, warum Heise dann "Hersteller-
>> haftung" fordert?

Notorische Albernheit.

> Vermutlich wegen der Ausschlussklausel in den AGB/T&C's. CS wird sich 
> hinstellen und sagen das Du es so akzeptiert hast und that's that. Es 
> sei man definiert die Klausel als "unwirksam" aus $GRUND, sehe ich da 
> wenig Spielraum was zu bekommen.

Gibt es /überhaupt/ irgendeinen Softwarehersteller, der a) 
Massengeschäft betreibt *und* b) für irgendetwas außerhalb Vorsatz haftet?

Nein. Der Anwender betreibt eine Software immer auf ganz eigenes Risiko.

Will er dieses Risiko abwälzen, muß er dafür zahlen. Aber das will er 
natürlich nicht. Lieber kreischt er nach Herstellerhaftung. Als ob die 
vom Himmel fiele und nicht auch bezahlt werden müßte. => Notorische 
Albernheit.
-- 
"Journalisten informieren, worüber die Bevölkerung informiert werden soll."
                             --re:publica24
Niemand hat gelacht.

[toc] | [prev] | [next] | [standalone]

#624404

FromBernd Ohm <invalid@invalid.invalid>
Date2024-07-23 17:05 +0200
Message-ID<lg9v5dF7c8gU1@mid.individual.net>
In reply to#624396
Am 23.07.2024 um 15:46 schrieb Goetz Schultz:

> Vermutlich wegen der Ausschlussklausel in den AGB/T&C's.

CS hat in ihren Klauseln doch noch was vergessen:

"Acts of God."

Habe ich in den Garantieausschlüssen eines Herstellers
der von uns eingesetzten Chips gefunden.
Damit sollte dann wirklich alles ausgeschlossen sein,
was nur irgendwie denkbar ist. ;-)

-- 
bis denn, BEN

[toc] | [prev] | [next] | [standalone]

#624405

From"Dr. Joachim Neudert" <neudert@5sl.org>
Date2024-07-23 17:10 +0200
Message-ID<v7oh5h$7ujn$1@solani.org>
In reply to#624404
Am 23.07.24 um 17:05 schrieb Bernd Ohm:
> Am 23.07.2024 um 15:46 schrieb Goetz Schultz:
> 
>> Vermutlich wegen der Ausschlussklausel in den AGB/T&C's.
> 
> CS hat in ihren Klauseln doch noch was vergessen:
> 
> "Acts of God."
> 
> Habe ich in den Garantieausschlüssen eines Herstellers
> der von uns eingesetzten Chips gefunden.
> Damit sollte dann wirklich alles ausgeschlossen sein,
> was nur irgendwie denkbar ist. ;-)
> 


Aber wirklich nicht!

"Gottes Werk und Teufels Beitrag"
- was ist mit Aktionen die des Teufels sind?



-- 
Bitt um Vrzihung, di Tast " " klmmt manchmal...

[toc] | [prev] | [next] | [standalone]

#624409

FromGeorg Gruber <g.gruber_hauwech@gmx.net>
Date2024-07-23 18:32 +0200
Message-ID<06D917164FB6C36F@ggruber793.news.solani.org>
In reply to#624405
Am 23.07.2024 um 17:10 schrieb Dr. Joachim Neudert:
> Am 23.07.24 um 17:05 schrieb Bernd Ohm:
>> Am 23.07.2024 um 15:46 schrieb Goetz Schultz:
>>
>>> Vermutlich wegen der Ausschlussklausel in den AGB/T&C's.
>>
>> CS hat in ihren Klauseln doch noch was vergessen:
>>
>> "Acts of God."
>>
>> Habe ich in den Garantieausschlüssen eines Herstellers
>> der von uns eingesetzten Chips gefunden.
>> Damit sollte dann wirklich alles ausgeschlossen sein,
>> was nur irgendwie denkbar ist. ;-)
>>
> 
> 
> Aber wirklich nicht!
> 
> "Gottes Werk und Teufels Beitrag"
> - was ist mit Aktionen die des Teufels sind?

Mit "Force Majeure” ist alles erschlagen und es klingt nicht so spinnert 
esoterisch wie "Act of God".


LG Georg

-- 
Den Sozialisten geht nicht nur das Geld anderer Leute aus,
ihnen gehen jetzt auch schon die anderen Leute aus.

[toc] | [prev] | [next] | [standalone]

#624413

FromBernd Ohm <invalid@invalid.invalid>
Date2024-07-23 19:27 +0200
Message-ID<lga7foF7c8gU2@mid.individual.net>
In reply to#624409
Am 23.07.2024 um 18:32 schrieb Georg Gruber:

> Mit "Force Majeure” ist alles erschlagen und es klingt nicht so spinnert
> esoterisch wie "Act of God".

So einfach ist das offensichtlich nicht.

Wikipedia:
"Die Begriffe der höheren Gewalt sind im Deutschen, Französischen
und Englischen nicht deckungsgleich. Die französisch-rechtliche
höhere Gewalt (französisch force majeure) ist im engeren Sinne
auf Naturereignisse beschränkt, aber im weiteren Sinne gleichbedeutend
mit dem deutschen Begriff; zu vom Menschen verursachten Ereignissen
kennt die französische Rechtstradition einen Fachbegriff (französisch
cas fortuit). Die englisch-rechtliche höhere Gewalt (englisch act of
God; wörtlich „Gottestat“) ist ein Unterfall der höheren Gewalt,
während der aus dem Französischen neu entlehnte Fachbegriff force
majeure mehr dem deutschen entspricht."

Alles viel zu uneindeutig.
Ich würde einfach schreiben:
"Wir haften in allen Fällen überhaupt nicht!"

-- 
bis denn, BEN

[toc] | [prev] | [next] | [standalone]

#624414

FromDr. Joachim Neudert <neudert@5sl.org>
Date2024-07-23 17:37 +0000
Message-ID<v7oppc$85kf$1@solani.org>
In reply to#624413
Bernd Ohm <invalid@invalid.invalid> wrote:
> Am 23.07.2024 um 18:32 schrieb Georg Gruber:
> 
>> Mit "Force Majeure” ist alles erschlagen und es klingt nicht so spinnert
>> esoterisch wie "Act of God".
> 
> So einfach ist das offensichtlich nicht.
> 
> Wikipedia:
> "Die Begriffe der höheren Gewalt sind im Deutschen, Französischen
> und Englischen nicht deckungsgleich. Die französisch-rechtliche
> höhere Gewalt (französisch force majeure) ist im engeren Sinne
> auf Naturereignisse beschränkt, aber im weiteren Sinne gleichbedeutend
> mit dem deutschen Begriff; zu vom Menschen verursachten Ereignissen
> kennt die französische Rechtstradition einen Fachbegriff (französisch
> cas fortuit). Die englisch-rechtliche höhere Gewalt (englisch act of
> God; wörtlich „Gottestat“) ist ein Unterfall der höheren Gewalt,
> während der aus dem Französischen neu entlehnte Fachbegriff force
> majeure mehr dem deutschen entspricht."
> 
> Alles viel zu uneindeutig.
> Ich würde einfach schreiben:
> "Wir haften in allen Fällen überhaupt nicht!"
> 

Jupp, das ist das angestrebte Ziel. Bündig formuliert!

Man könnte noch Konventionalstrafen ergänzen, wenn jemand  versucht,
trotzdem eine Haftung einzuklagen.

-- 
please forgive my iPhone typos

[toc] | [prev] | [next] | [standalone]

#624416

FromBernd Ohm <invalid@invalid.invalid>
Date2024-07-23 19:51 +0200
Message-ID<lga8s7F7c8dU1@mid.individual.net>
In reply to#624414
Am 23.07.2024 um 19:37 schrieb Dr. Joachim Neudert:

> Bernd Ohm <invalid@invalid.invalid> wrote:

>> Alles viel zu uneindeutig.
>> Ich würde einfach schreiben:
>> "Wir haften in allen Fällen überhaupt nicht!"

> Jupp, das ist das angestrebte Ziel. Bündig formuliert!

> Man könnte noch Konventionalstrafen ergänzen, wenn jemand  versucht,
> trotzdem eine Haftung einzuklagen.

Hehe, du bist ja noch frecher als ich!
Es geht halt nicht anders; Kunden werden ja sonst
unverschämt. ;-)

-- 
bis denn, BEN

[toc] | [prev] | [next] | [standalone]

#624428

FromBernd Ohm <invalid@invalid.invalid>
Date2024-07-23 21:24 +0200
Message-ID<lgaec9F7c8dU2@mid.individual.net>
In reply to#624414
Am 23.07.2024 um 21:07 schrieb Stefan Ram:

> |Stefan Ram haftet nicht für leichte Fahrlässigkeit.
> 
>    . So hat dies AFAIK wenigstens eine Chance auf Wirksamkeit.

Jau, leg dich wieder hin, wir unternehmen nichts
gegen dich! ;-)

-- 
bis denn, BEN

[toc] | [prev] | [next] | [standalone]

#624418

FromDietz Proepper <dietz.usenet@rotfl.franken.de>
Date2024-07-23 20:00 +0200
Message-ID<20240723200030.23d67953.dietz.usenet@rotfl.franken.de>
In reply to#624413
Bernd Ohm <invalid@invalid.invalid> wrote:
> Alles viel zu uneindeutig.
> Ich würde einfach schreiben:
> "Wir haften in allen Fällen überhaupt nicht!"

Das würde vielleicht dann irgendwann doch auffallen?

-- 
CDU - unser "K" steht für "Kompetenz".

[toc] | [prev] | [next] | [standalone]

#624407

FromMichael Zink <michael@swamp.franken.de>
Date2024-07-23 17:48 +0200
Message-ID<lga1maF7raiU1@mid.individual.net>
In reply to#624375
IANAL und auch sonst nicht tiefer drinn. Daher nur ganz
grrundsätzlich. Evtl. Rückfragen bitte nicht an mich, sondern einen
Fachmann ;-)


On 23 Jul 2024 13:31:30 GMT, Stefan Ram wrote:

>  . Ich hatte bisher angenommen, daß ein Hersteller
>  grundsätzlich für Schäden in seine Produkten haftet.

Grundsätzlich nur sehr eingeschränkt. Das geht dann über das
Produkthaftungsgesetz und ist gegenüber den normalen Regeln
eingeschränkt.

>  Zum Beispiel haben doch Ärzte eine Versicherung weil
>  sie für ihre Fehler haften, ähnlich bei Anwälten. 

Die haften aber normalerweise, wenn durch ihren Fehler jemand direkt
geschädigt wird. Bei der Produkthaftung wird aber durch den Fehler
direkt erstmal niemand geschädigt. Der Schaden entsteht erst, wenn das
Produkt eingesetzt wird.

Dazu kommt, daß man bei fehlerhaften Produkten meistens keinen
direkten Vertrag mit dem Hersteller hat.

>  Kann jemand erklären, warum Heise dann "Hersteller-
>  haftung" fordert?

Weil Herstellerhaftung gerade bei Software bisher nicht sehr weit
reicht.

Auf Wiederlesen

Michael

-- 
Das Internet darf kein GRUNDrechtsfreier Raum werden!

[toc] | [prev] | [next] | [standalone]

#624212

FromHergen Lehmann <hlehmann-usenet24@snafu.de>
Date2024-07-19 23:54 +0200
Message-ID<5u3rmk-kacq3.ln1@hergen.spdns.de>
In reply to#624208
Am 19.07.24 um 22:59 schrieb Ulrich D i e z:

> Wieso müssen sie(tm) überhaupt so ins System eingreifen, dass es unter
> Umständen gar nicht mehr hochfährt? Was machen sie(tm) da genau?

Wenn ich es richtig verstanden habe, soll das Ding die Aktivitäten des 
Betriebssystems überwachen und Auffälligkeiten melden. Dazu muss es 
mindestens (als Treiber) auf der selben Privilegierungsebene laufen wie 
das OS, wenn nicht sogar als Hypervisor darüber.


> Und wieso testen sie(tm) ihre Updates nicht, bevor sie(tm) sie auf die
> Welt loslassen?

Weil man nicht alle möglichen Konstellationen testen kann. Weil Tests 
Zeit kosten, welche man bei der Abwehr von akut drohenden Cyberangriffen 
nicht unbedingt hat. Da geht es mitunter um Minuten, um die Signaturen 
schneller zu aktualisieren, als das Virus sich ausbreiten kann.


> Wieso können die, die sich von ihnen(tm) mit Cyber-Sicherheit versorgen
> lassen, ihrerseits nach einem schlechten Update kein schnelles Rollback
> vornehmen? 

Weil in diesem Fall das System nicht mehr bootet.


> dass das Rollback ausgeführt werden kann, zB ein Recovery-System
> ferngesteuert booten, um die Sache zu richten? (Ich meine so in Richtung
> PXE-Boot oder was auch immer die heutige Entsprechung davon ist...)

Fernwartung auf BIOS-Ebene oder Remote-Boot wären in der Cloud ein 
fatales Sicherheitsrisiko. Zudem sind übliche Desktop-Mainboards aus 
Marketinggründen nicht mit Fernwartung ausgerüstet und kann man ein 
Windows überhaupt aus dem Netzwerk booten?


> Und wieso soll es beruhigend sein, dass das anscheinend kein
> Hacker-Angriff war?

Die IT-Verantwortlichen der betroffenen Unternehmen müssen (zunächst) 
nicht befürchten, das über den Boot-Schluckauf hinaus Schäden 
angerichtet wurden oder sensible Daten abgeflossen sind.


> Könnte doch auch ein Testangriff sein, der darin
> besteht, die Arbeit von Cyber-Security-Unternehmen zu korrumpieren.

Ja, Schlangenöl ist gefährlich und allzu oft selbst das Einfallstor.

[toc] | [prev] | [next] | [standalone]

#624215

FromUlrich D i e z <ud.usenetcorrespondence@web.de>
Date2024-07-20 00:59 +0200
Message-ID<v7er1r$30ab$1@solani.org>
In reply to#624212
Hergen Lehmann schrieb:

> Am 19.07.24 um 22:59 schrieb Ulrich D i e z:
> 
>> Wieso müssen sie(tm) überhaupt so ins System eingreifen, dass es unter
>> Umständen gar nicht mehr hochfährt? Was machen sie(tm) da genau?
> 
> Wenn ich es richtig verstanden habe, soll das Ding die Aktivitäten des 
> Betriebssystems überwachen und Auffälligkeiten melden. Dazu muss es 
> mindestens (als Treiber) auf der selben Privilegierungsebene laufen wie 
> das OS, wenn nicht sogar als Hypervisor darüber.
> 
> 
>> Und wieso testen sie(tm) ihre Updates nicht, bevor sie(tm) sie auf die
>> Welt loslassen?
> 
> Weil man nicht alle möglichen Konstellationen testen kann. 

Ich denke, die gängigsten könnte man testen...

> Weil Tests 
> Zeit kosten, welche man bei der Abwehr von akut drohenden Cyberangriffen 
> nicht unbedingt hat. Da geht es mitunter um Minuten, um die Signaturen 
> schneller zu aktualisieren, als das Virus sich ausbreiten kann.
> 
> 
>> Wieso können die, die sich von ihnen(tm) mit Cyber-Sicherheit versorgen
>> lassen, ihrerseits nach einem schlechten Update kein schnelles Rollback
>> vornehmen? 
> 
> Weil in diesem Fall das System nicht mehr bootet.

Bootet man heutzutage halt ein anderes Betriebssystem, zB eins auf einer
Recovery-Partition oder eins von einem PXE-Boot-Image oder so etwas.

>> dass das Rollback ausgeführt werden kann, zB ein Recovery-System
>> ferngesteuert booten, um die Sache zu richten? (Ich meine so in Richtung
>> PXE-Boot oder was auch immer die heutige Entsprechung davon ist...)
> 
> Fernwartung auf BIOS-Ebene oder Remote-Boot wären in der Cloud ein 
> fatales Sicherheitsrisiko. Zudem sind übliche Desktop-Mainboards aus 
> Marketinggründen nicht mit Fernwartung ausgerüstet und kann man ein 
> Windows überhaupt aus dem Netzwerk booten?

Es geht ja nicht nur um Clouds, sondern un großem Stil um Geräte (am
Schalter im Flughafen, Geldautomat, Supermarktkasse), mit denen man sich
an datenverarbeitenden Systemen anmeldet, um für diese Systeme Daten
einzugeben und von diesen Systemen Daten abzurufen, also Geräte, die das
Benutzerinterface bereitstellen.

In dem Fall jetzt reicht es, um die Systeme wieder zum Laufen zu
bekommen, offenbar aus, eine bestimmte Datei zu löschen:

Bundesamt für Sicherheit und Informationstechnik - Fehlerhaftes Update
von Crowdstrike Falcon, Datum 19.07.2024:

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2024/2024-257485-10F1.pdf

Dazu müsste man das betreffende System vielleicht nicht unbedingt mit
Windows booten - ein kleines Linux, welches diese Datei löscht und dann
den Rechner neu bootet, täte es vielleicht auch?

>> Und wieso soll es beruhigend sein, dass das anscheinend kein
>> Hacker-Angriff war?
> 
> Die IT-Verantwortlichen der betroffenen Unternehmen müssen (zunächst) 
> nicht befürchten, das über den Boot-Schluckauf hinaus Schäden 
> angerichtet wurden oder sensible Daten abgeflossen sind.

So gesehen...  :-)

>> Könnte doch auch ein Testangriff sein, der darin
>> besteht, die Arbeit von Cyber-Security-Unternehmen zu korrumpieren.
> 
> Ja, Schlangenöl ist gefährlich und allzu oft selbst das Einfallstor.


Mit freundlichem Gruß

Ulrich

[toc] | [prev] | [next] | [standalone]

#624226

FromHergen Lehmann <hlehmann-usenet24@snafu.de>
Date2024-07-20 10:49 +0200
Message-ID<k9asmk-ogmq3.ln1@hergen.spdns.de>
In reply to#624215
Am 20.07.24 um 00:59 schrieb Ulrich D i e z:

> Hergen Lehmann schrieb:
>> Weil man nicht alle möglichen Konstellationen testen kann.
> 
> Ich denke, die gängigsten könnte man testen...

Tja, und dann hat ein bestimmter Kundenkreis (z.B. Fluggesellschaften) 
ohne Wissen des Softwareherstellers weitere Fremdsoftware installiert, 
welche sich zufällig beißt.


> Bootet man heutzutage halt ein anderes Betriebssystem, zB eins auf einer
> Recovery-Partition oder eins von einem PXE-Boot-Image oder so etwas.

Um von einer anderen Partition zu booten, muss ein Techniker mit 
Kenntnis des BIOS-Passwort physisch an die Maschine heran. Da hast du 
gegenüber einem Boot-Stick nichts gewonnen.

Netzwerk-Boot wäre sicherlich möglich.
Das erfordert aber, das bei allen Kunden ein Boot-Server in jedem 
einzelnen LAN-Segment vorhanden ist - im Zeitalter der VPNs nicht mehr 
selbstverständlich. Es verlängert die Reaktionszeiten bei Fehlern, die 
Präparation eines Boot-Image zur Autoreparatur (diesmal hoffentlich 
ausreichend getestet) dauert wesentlich länger als eine kurze 
Pressemitteilung. Und es hilft nicht zuverlässig - der nächste Bug 
erfordert vielleicht einen Registry-Patch, der von einem aus dem 
Netzwerk gebooteten Linux aus nicht möglich ist.


> Es geht ja nicht nur um Clouds, sondern un großem Stil um Geräte (am
> Schalter im Flughafen, Geldautomat, Supermarktkasse), mit denen man sich
> an datenverarbeitenden Systemen anmeldet, um für diese Systeme Daten
> einzugeben und von diesen Systemen Daten abzurufen, also Geräte, die das
> Benutzerinterface bereitstellen.

Gerade die werden meist in einer privaten Cloud (VPN) ohne lokalen 
Server laufen, was Netzwerkboot weitgehend unmöglich macht.

[toc] | [prev] | [next] | [standalone]

#624394

FromUlrich D i e z <ud.usenetcorrespondence@web.de>
Date2024-07-23 15:32 +0200
Message-ID<v7oba9$8r2r$1@solani.org>
In reply to#624226
Hergen Lehmann schrieb:

> Um von einer anderen Partition zu booten, muss ein Techniker mit 
> Kenntnis des BIOS-Passwort physisch an die Maschine heran.

Nicht unbedingt. Bei PC-artigen Maschinen kann man zB über efi-Loader
oder MBR und Bootsektoren der MBR-Partitionen in den Bootprozess
einhaken mit Bootmanagern und/oder Chain-Loadern, ohne im BIOS etwas
verstellen zu müssen.

Seit ich mich das letztemal intensiver mit den Bootvorgängen von
BIOS-Maschinen mit Festplatten mit MBR-Partitionen und den Bootvorgängen
bei UEFI-Maschinen mit Festplatten mit GPT-Partitionen bzw.
GPT/MBR-Hybriden befasst habe, ist einige Zeit vergangen und es werden
sich die Möglichkeiten nochmal beträchtlich erweitert haben. Soll ja
anscheinend demnächst Mainboards geben, bei denen das UEFI bzw die
Entsprechung mit einem Large Language Module/bzw einer KI auf einer Art
neuronalem Netz daherkommen soll...

Und ich habe außerdem eine ältere Maschine, bei der man zwar einstellen
kann, dass man ein Passwort braucht, um beim Booten per Tastendruck ins
BIOS zu kommen und Dinge einstellen zu können. Aber wenn der Rechner
gebootet ist kann man auch per Software ans BIOS, wobei es kein Passwort
braucht. Zugegeben musste ich das selbst schreiben, aber das war auch
nicht viel anders als bei meinem ersten 80386-Rechner, bei dem solche
von bootbarer 5.25-Zoll-Diskette laufende Software zur BIOS-Einstellung
beim Mainboard dabeilag, die natürlich nutzlos war, wenn der Rechner
wegen durch ausgelaufenen 3.7V-CMOS-Batterien-Akku gelöschtem CMOS nicht
mehr so weit hochfuhr, dass an Booten von Diskette zu denken war. ;-)

> Da hast du 
> gegenüber einem Boot-Stick nichts gewonnen.

Ich halte auch eine Bootreihenfolge für denkbar, die eine Art PXE-Boot
miteinschliesst, bei der aber die einzelnen Dateien im Boot-Image (nicht
die Image-Datei selbst) eine Art bestimmter Bitlocker-Verschlüsselung
haben müssen, die nur die Admins kennen, damit das PXE-Booten mit dem
Image funktioniert und nicht übergangen und normal gebootet wird.

> Netzwerk-Boot wäre sicherlich möglich.
> Das erfordert aber, das bei allen Kunden ein Boot-Server in jedem 
> einzelnen LAN-Segment vorhanden ist - im Zeitalter der VPNs nicht mehr 
> selbstverständlich. Es verlängert die Reaktionszeiten bei Fehlern, die 
> Präparation eines Boot-Image zur Autoreparatur (diesmal hoffentlich 
> ausreichend getestet) dauert wesentlich länger als eine kurze 
> Pressemitteilung. Und es hilft nicht zuverlässig - der nächste Bug 
> erfordert vielleicht einen Registry-Patch, der von einem aus dem 
> Netzwerk gebooteten Linux aus nicht möglich ist.

Vom aus dem Netzwerk gebooteten Betriebssystem aus könnte man aber
vielleicht Backups einspielen oder den letzten funktionierenden Zustand
anhand von Wiederhertellungspunkten herstellen, die vor der Vornahme der
zu Problemen führenden Updates angelegt wurden. Dann könnte die
Maschinen wieder hochfahren und das hoffentlich richtig funktionierende
Update holen lassen.

Und das müsste ja auch nicht unbedingt zB Crowdstrike für seine Kunden
administrieren, sondern diejenigen Admins der Kunden, die sich ansonsten
darum kümmern, dass die Systeme laufen.

>> Es geht ja nicht nur um Clouds, sondern un großem Stil um Geräte (am
>> Schalter im Flughafen, Geldautomat, Supermarktkasse), mit denen man sich
>> an datenverarbeitenden Systemen anmeldet, um für diese Systeme Daten
>> einzugeben und von diesen Systemen Daten abzurufen, also Geräte, die das
>> Benutzerinterface bereitstellen.
> 
> Gerade die werden meist in einer privaten Cloud (VPN) ohne lokalen 
> Server laufen, was Netzwerkboot weitgehend unmöglich macht.

Du meinst Cloud-PCs? Wie habe ich mir diese Cloud-PCs vorzustellen? Sind
da die Endgeräte, an denen zB die Leute am Schalter im Flughafen sitzen,
im Prinzip Remote-Desktop-Clients, sodass die Endgeräte selbst zwar
booten, aber die in der Cloud laufenden (vermutlich virtuellen)
Remote-Desktop-Server nicht laufen? Falls das so ist, dann nützt es eh
nichts, per Netzwerkboot am Client ansetzen zu wollen, weil der Client
ja hoffentlich funktioniert.

Aber dann müsste man doch vor dem Update so eines virtuellen Servers
einen Snapshot machen können, damit man, wenn es nötig ist, den letzten
problemlos funktionierenden Zustand wiederherstellen kann.
Stelle ich mir als virtuelle Entsprechung dazu vor, bei einem RAID 1
System einen Snapshot zu machen, indem man im laufenden Betrieb eine der
Festplatten einfach rausnimmt und zum Snapshot deklariert... ;-)
Die rausgenommene Platte kann man durch eine andere ersetzen, die
während des Updates synchronisiert wird. Und wenn das Update Probleme
macht, nimmt man halt die rausgenommene zum Snapshot deklarierte
Festplatte und fährt damit hoch...
Ich denke, mit virtuellen Systemen statt tatsächlich so vorhandenen
RAID-Volumes mit darin eingebauten Festplatten dürfte so etwas
heutzutage recht schnell gehen.

Mit freundlichem Gruß

Ulrich

[toc] | [prev] | [next] | [standalone]

#624444

FromHergen Lehmann <hlehmann-usenet24@snafu.de>
Date2024-07-24 08:58 +0200
Message-ID<o9l6nk-87jt3.ln1@hergen.spdns.de>
In reply to#624394
Am 23.07.24 um 15:32 schrieb Ulrich D i e z:

> Hergen Lehmann schrieb:
> 
>> Um von einer anderen Partition zu booten, muss ein Techniker mit
>> Kenntnis des BIOS-Passwort physisch an die Maschine heran.
> 
> Nicht unbedingt. Bei PC-artigen Maschinen kann man zB über efi-Loader
> oder MBR und Bootsektoren der MBR-Partitionen in den Bootprozess
> einhaken mit Bootmanagern und/oder Chain-Loadern, ohne im BIOS etwas
> verstellen zu müssen.

Weitere Fehlerquellen, bei denen die Nachlässigkeit eines weiteren 
Lieferanten zu fatalen Ausfällen führen kann.

Weitere Angriffspunkte für Cyberattacken, gegen die die bisherigen (an 
das Betriebssystem gebundenen) Lösungsansätze nicht helfen.

Nein, die moderne BIOSe haben schon viel zu viel Bloat, das will man in 
sicherheitskritischen Umgebungen weitestmöglich deaktivieren und nicht 
etwa noch ausweiten.


> Und das müsste ja auch nicht unbedingt zB Crowdstrike für seine Kunden
> administrieren, sondern diejenigen Admins der Kunden, die sich ansonsten
> darum kümmern, dass die Systeme laufen.

Damit entfiele aber das Verkaufsargument für Anbieter wie Crowdstrike, 
welche ja gerade von dem Versprechen "ihr könnt euch zurücklehnen, wir 
kümmern uns um eure Sicherheit" leben.


>> Gerade die werden meist in einer privaten Cloud (VPN) ohne lokalen
>> Server laufen, was Netzwerkboot weitgehend unmöglich macht.
> 
> Du meinst Cloud-PCs? Wie habe ich mir diese Cloud-PCs vorzustellen? Sind
> da die Endgeräte, an denen zB die Leute am Schalter im Flughafen sitzen,
> im Prinzip Remote-Desktop-Clients, sodass die Endgeräte selbst zwar
> booten, aber die in der Cloud laufenden (vermutlich virtuellen)
> Remote-Desktop-Server nicht laufen? 

Die Geräte werden booten, aber die darauf installierte Software ist ohne 
den Server im zentralen Rechenzentrum der Fluggesellschaft funktionslos. 
Es gibt am Abfertigungsschalter eines Flughafens keinen lokalen Server, 
welcher einen autonomen Betrieb erlauben würde. Ob das per Remote 
Desktop realisiert ist, oder antik mittels DCOM/CORBA/RPC oder modern 
als Webapplikation, macht an der Stelle keinen Unterschied.

Und ohne den lokalen Server fällt auch Netzwerkboot aus.

[toc] | [prev] | [next] | [standalone]

#624447

FromDietz Proepper <dietz.usenet@rotfl.franken.de>
Date2024-07-24 09:30 +0200
Message-ID<20240724093035.44f71157.dietz.usenet@rotfl.franken.de>
In reply to#624444
Hergen Lehmann <hlehmann-usenet24@snafu.de> wrote:

> Am 23.07.24 um 15:32 schrieb Ulrich D i e z:
> > Und das müsste ja auch nicht unbedingt zB Crowdstrike für seine
> > Kunden administrieren, sondern diejenigen Admins der Kunden, die
> > sich ansonsten darum kümmern, dass die Systeme laufen.  
> 
> Damit entfiele aber das Verkaufsargument für Anbieter wie
> Crowdstrike, welche ja gerade von dem Versprechen "ihr könnt euch
> zurücklehnen, wir kümmern uns um eure Sicherheit" leben.

Gab es bislang auch nur einen Anbieter solcher Lösungen, der nicht
maximal drei Jahre gebraucht hat um selber zum Problem zu werden?

Das ist doch der Grund, warum entsprechende Unternehmen gerne als snake
oil sellers tituliert werden - sie kosten Geld, geben ein gutes, warmes
Gefühl, nützen wenig und wenn etwas passiert, dann hatte man alles
Menschenmögliche getan.

-- 
CDU - unser "K" steht für "Kompetenz".

[toc] | [prev] | [next] | [standalone]

#624454

FromHergen Lehmann <hlehmann-usenet24@snafu.de>
Date2024-07-24 10:43 +0200
Message-ID<4fr6nk-87jt3.ln1@hergen.spdns.de>
In reply to#624447
Am 24.07.24 um 09:30 schrieb Dietz Proepper:

> Hergen Lehmann <hlehmann-usenet24@snafu.de> wrote:
>> Damit entfiele aber das Verkaufsargument für Anbieter wie
>> Crowdstrike, welche ja gerade von dem Versprechen "ihr könnt euch
>> zurücklehnen, wir kümmern uns um eure Sicherheit" leben.
> 
> Gab es bislang auch nur einen Anbieter solcher Lösungen, der nicht
> maximal drei Jahre gebraucht hat um selber zum Problem zu werden?

Vermutlich nicht.

Die Kosten und der Aufwand für den Aufbau und die Zertifizierung(!!) 
eines vernünftigen Inhouse-Sicherheitsmanagement sind aber so heftig, 
das das Management immer wieder auf solche Anbieter herein fällt.

Oft kann es gar nicht anders, weil Sicherheitsexperten auch nicht in 
unbegrenzter Zahl auf dem Arbeitsmarkt verfügbar sind.


> Das ist doch der Grund, warum entsprechende Unternehmen gerne als snake
> oil sellers tituliert werden - sie kosten Geld, geben ein gutes, warmes
> Gefühl, nützen wenig und wenn etwas passiert, dann hatte man alles
> Menschenmögliche getan.

Man hat zumindest das getan, was die übergeordnete Sicherheitsbehörde 
fordert und hat ein Papier in der Hand, das dies bescheinigt.

[toc] | [prev] | [next] | [standalone]

#624477

FromDietz Proepper <dietz.usenet@rotfl.franken.de>
Date2024-07-24 13:59 +0200
Message-ID<20240724135910.34607c8b.dietz.usenet@rotfl.franken.de>
In reply to#624454
Hergen Lehmann <hlehmann-usenet24@snafu.de> wrote:

> Am 24.07.24 um 09:30 schrieb Dietz Proepper:
> > Das ist doch der Grund, warum entsprechende Unternehmen gerne als
> > snake oil sellers tituliert werden - sie kosten Geld, geben ein
> > gutes, warmes Gefühl, nützen wenig und wenn etwas passiert, dann
> > hatte man alles Menschenmögliche getan.  
> 
> Man hat zumindest das getan, was die übergeordnete Sicherheitsbehörde 
> fordert und hat ein Papier in der Hand, das dies bescheinigt.

Seufz.

-- 
CDU - unser "K" steht für "Kompetenz".

[toc] | [prev] | [next] | [standalone]

#624508

FromUlrich D i e z <ud.usenetcorrespondence@web.de>
Date2024-07-25 03:29 +0200
Message-ID<v7s9lu$a621$1@solani.org>
In reply to#624444
Hergen Lehmann schrieb:

> Am 23.07.24 um 15:32 schrieb Ulrich D i e z:
> 
>> Hergen Lehmann schrieb:
>> 
>>> Um von einer anderen Partition zu booten, muss ein Techniker mit
>>> Kenntnis des BIOS-Passwort physisch an die Maschine heran.
>> 
>> Nicht unbedingt. Bei PC-artigen Maschinen kann man zB über efi-Loader
>> oder MBR und Bootsektoren der MBR-Partitionen in den Bootprozess
>> einhaken mit Bootmanagern und/oder Chain-Loadern, ohne im BIOS etwas
>> verstellen zu müssen.
> 
> Weitere Fehlerquellen, bei denen die Nachlässigkeit eines weiteren 
> Lieferanten zu fatalen Ausfällen führen kann.

An den Dingen, mit denen ich im Fall, dass ein Lieferant etwas
verpfuscht hat, das Zurücksetzen auf den letzten problemfreien Zustand
bewerkstelligen können will, hätte doch gerade kein Lieferant etwas
verloren, denn das wäre meine Sicherung gegen Lieferanten.

> Weitere Angriffspunkte für Cyberattacken, gegen die die bisherigen (an 
> das Betriebssystem gebundenen) Lösungsansätze nicht helfen.
> Nein, die moderne BIOSe haben schon viel zu viel Bloat, das will man in 
> sicherheitskritischen Umgebungen weitestmöglich deaktivieren und nicht 
> etwa noch ausweiten.



> 
>> Und das müsste ja auch nicht unbedingt zB Crowdstrike für seine Kunden
>> administrieren, sondern diejenigen Admins der Kunden, die sich ansonsten
>> darum kümmern, dass die Systeme laufen.
> 
> Damit entfiele aber das Verkaufsargument für Anbieter wie Crowdstrike, 
> welche ja gerade von dem Versprechen "ihr könnt euch zurücklehnen, wir 
> kümmern uns um eure Sicherheit" leben.

Wenn meine wirtschaftliche Existenz davon abhinge, dass meine Rechner
laufen, dann würde ich mich nie zurücklehnen und allein auf Kaspersky
oder Sophos oder Crowdstrike vertrauen. Es ist ja vielleicht nett wenn
die die Detektionsroutinen für ungute Dinge aktuell halten und so
weiter, aber es müsste eine Ebene da sein, auf der ich die Oberhoheit
hätte und ggfs zurücksetzn und notfalls auch diese Leute aussperren
könnte wenn ihre Aktivitäten schädlich werden würden.

>>> Gerade die werden meist in einer privaten Cloud (VPN) ohne lokalen
>>> Server laufen, was Netzwerkboot weitgehend unmöglich macht.
>> 
>> Du meinst Cloud-PCs? Wie habe ich mir diese Cloud-PCs vorzustellen? Sind
>> da die Endgeräte, an denen zB die Leute am Schalter im Flughafen sitzen,
>> im Prinzip Remote-Desktop-Clients, sodass die Endgeräte selbst zwar
>> booten, aber die in der Cloud laufenden (vermutlich virtuellen)
>> Remote-Desktop-Server nicht laufen? 
> 
> Die Geräte werden booten, aber die darauf installierte Software ist ohne 
> den Server im zentralen Rechenzentrum der Fluggesellschaft funktionslos. 
> Es gibt am Abfertigungsschalter eines Flughafens keinen lokalen Server, 
> welcher einen autonomen Betrieb erlauben würde. Ob das per Remote 
> Desktop realisiert ist, oder antik mittels DCOM/CORBA/RPC oder modern 
> als Webapplikation, macht an der Stelle keinen Unterschied.

Schon klar. Aber wieso haben die dann ihre Server nicht so, dass sie
sie, wenn da ein Update nicht klappt, möglichst schnell zurücksetzen können?

> Und ohne den lokalen Server fällt auch Netzwerkboot aus.

Meines Wissens kann man zB per iPXE nicht nur Images von einem
PXE-Server im LAN booten, sondern auch dhcp und html nutzen, um ein
Boot-Image über WAN/Internet zu holen.

Wäre aber allenfalls interessant wenn wirklich Clients nicht mehr
hochfahren und es nicht nur bei den Servern klemmt, deren Zeug auf den
Clients angezeigt werden soll.

Mit freundlichem Gruß

Ulrich

[toc] | [prev] | [next] | [standalone]

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | ger.ct

csiph-web