GitHub gehackt? Was tun, wenn der ignorierte Entwickler zurückschlägt?

Die heutige Nachricht ist, dass ein Entwickler github gehackt hat . Er fand eine Schwachstelle in Ruby on Rails, meldete sie und da nichts passiert war – er wurde ignoriert und als Troll betrachtet – nutzte er die Schwachstelle und hackte den zweitberühmtesten Dienst, der Ruby on Rails (github) verwendet.

Obwohl dieser Vorfall nichts mit Projektmanagement zu tun hat, brachte er mich zum Nachdenken; Es gibt viele Entwickler, denen die nötigen Kommunikationsfähigkeiten fehlen und die handeln statt zu reden. Ich kenne eine Handvoll Entwickler, die sich genauso verhalten würden wie der Typ, der Github gehackt hat: Sie würden Schaden anrichten, nur um zu beweisen, dass sie Recht haben. Ihre Absicht ist sicherlich fragwürdig, aber sie sind gut in dem, was sie tun, aber ihnen fehlen einige nützliche Soft Skills.

Also meine Fragen:

  1. Wie würden Sie einem solchen Entwickler helfen (coachen), damit er nicht handelt und das Richtige tut ? Ich habe absichtlich Hilfe in Anspruch genommen, weil jemand zu entlassen eine einfache Antwort ist.
  2. Angenommen, Sie finden einen kritischen Fehler in der Anwendung Ihres Kunden, aber er hört nicht zu. Wie können Sie sie am besten davon überzeugen, dass sie das Problem ernst nimmt?
@Zolt - Ich wollte Ihre sehr großartige Frage zu Programmers SE verschieben, da sie zunächst für diese Site relevanter schien, aber am Ende verknüpfen Sie Ihre Hintergrundinformationen mit zwei sehr relevanten und themenbezogenen Fragen. +1 Ihre Frage betrifft nicht nur das Coaching, sondern ich bin sicher, dass jemand dieses Thema verwenden könnte, um einige großartige Fragen zu Projektrisiko, Führung, Motivation und mehr zu stellen!

Antworten (4)

1: Machen Sie sich zunächst das Richtige so einfach wie möglich und stellen Sie sicher, dass es gut verstanden wird.

In diesem speziellen Fall antwortete ein Github-Sprecher:

Wir haben uns nicht so klar ausgedrückt, wie wir Sicherheitsprobleme verantwortungsbewusst offenlegen sollten, und das tut mir leid.

Denken Sie auch darüber nach, was das Falsche wäre, und bedenken Sie, dass es verschiedene Grade des Richtigen geben kann . Zum Beispiel könnten Sie Leute einladen, Ihre Website in einer sichereren Umgebung zu hacken , um eine Belohnung oder Prestige zu erhalten. Oder Sie könnten Leuten wie Egor einfach vergeben – der nicht wirklich Schaden angerichtet hat, obwohl er es hätte tun können.

Ich glaube nicht, dass es Egor war, dem es in diesem Fall an den nötigen Kommunikationsfähigkeiten gefehlt hat. Er stellte Informationen kostenlos zur Verfügung, und die Rails-Community verfügte nicht über die Kommunikationsfähigkeiten, um ihn zum Teilen zu ermutigen. Die Verantwortung für eine effektive Kommunikation liegt bei der Person, die davon profitiert.

2: Seien Sie überzeugend. Unternimm andere Dinge, um ihr zu helfen, dir zu vertrauen. Erzählen Sie Geschichten über andere Menschen, die nicht zugehört haben. Dann, wenn Reden nicht hilft, handeln.

Dennoch, wenn die Person Schaden angerichtet hat und dieser Schaden absichtlich war, kann ich mir nicht vorstellen, diese Person in der Nähe zu behalten. Sie können diese Person immer noch mögen und ihr oder ihm immer noch das Beste wünschen, aber diese Person hat ihre Nützlichkeit in Ihrer Organisation überlebt. Unfälle werden immer vergeben, Böswilligkeit nicht.
Die begünstigte Person muss effektiv kommunizieren, wenn sie davon profitieren möchte. Sie sollten überhaupt nicht kommunizieren müssen, damit jemand nicht gegen das Gesetz verstößt. Die Schuld für sein Handeln liegt allein beim Hacker.
Meh. Er hat den Buchstaben des Gesetzes gebrochen. Man muss allerdings wirklich, wirklich gemein sein, um ihn strafrechtlich zu verfolgen. Er hat um Himmels willen eine Commit-Nachricht gemacht.
Ich frage mich, was Egor aus der Geschichte gelernt hat. Was wird er beim nächsten Mal anders machen? Ehrlich gesagt habe ich bis gestern noch nie von ihm gehört, aber vielleicht veröffentlicht er seine Erkenntnisse beim nächsten Mal nicht. Ich denke, wir sollten ihn bei uns behalten, weil sich niemand um dieses kritische Thema – das 2008 veröffentlicht wurde – kümmerte, und ihm eine weniger schädliche Art und Weise zeigen, wie er seine Stimme erheben kann. Ich sehe dies als Herausforderung für Manager/Trainer.
Nachdem ich mehr darüber gelesen habe, was passiert ist, ist viel Gutes aus dem herausgekommen, was dieser Typ getan hat. Er könnte Unternehmen, die sich auf GitHub verlassen, viel Umsatz gespart haben und die viel verloren hätten, wenn Egor das Team nicht motiviert hätte, das Problem zu beheben. Soweit ich weiß, war er kein Mitarbeiter von GitHub. Wenn er ein Angestellter war, dann stehe ich zu meiner „er muss gehen“-Aussage. :)
Also sprach ich darüber, dass ich mich als Versager bezeichnen würde, wenn ich Egors PM wäre. Ich plädiere definitiv dafür, diese Probleme durch gutes Coaching zu vermeiden, bevor sie auftreten. Und ... gleichzeitig, wenn ich Egors Manager wäre und er gegangen wäre und das getan hätte, sehe ich keinen Weg, ihn nicht gehen zu lassen. Sie sprechen von einem monumentalen ethischen Verschluss. Wenn der Laden die Straße runter die Hintertür weiterhin unverschlossen ließ und ich den Fehler ihrer Vorgehensweise demonstrierte, indem ich hineinging und mir ein paar ihrer Sachen ausborgte, würde ich wegen schweren Diebstahls verhaftet werden. Stoppen Sie den Fehler, bevor er passiert, aber lassen Sie ihn nicht passieren, wenn er passiert.
Wenn er tatsächlich für GitHub gearbeitet hätte, hätte er dasselbe tun können – sich in das System hacken und eine harmlose Commit-Nachricht hinterlassen – aber es hätte wahrscheinlich „Testing Github Security“ statt „Wollen Sie, dass ich eine Sicherheit mache“ gesagt Rechnungsprüfung für Sie?" Dann wäre er zu den Verantwortlichen gegangen, anstatt darüber zu bloggen, weil er in diesem System gewesen wäre. Außerdem wäre er zu diesem Zeitpunkt als Berater in das Sicherheitsteam geholt und nicht gefeuert worden. Wenn ich so eine Person in meiner Firma hätte, würde ich ihn ermutigen , die Schwachstellen in meinen Systemen zu finden, und ihn nicht feuern.
Lunivore, indem Sie ihn ermutigen, ändern Sie den Umfang seiner Rolle. Das macht das, was er getan hat, in Ordnung, denn das ist eine Form der Bedrohungsmilderung. In diesem Fall hat er es alleine gemacht. Gleiches Verhalten, aber nur autorisiert gegenüber nicht autorisiert. Unterm Strich können die Leiter einer Organisation entscheiden, was abgemildert und was akzeptiert werden soll, und die Mitarbeiter können diese Entscheidung nicht alleine umgehen.
Sie können Risiken den ganzen Tag eskalieren, lauter und lauter schreien, wenn Sie müssen, aber Sie können nicht halbherzig loslegen und sie dazu bringen, einen Standpunkt zu beweisen.
Wenn er es in seiner Freizeit tut, bereits für das Unternehmen arbeitet und dabei keinen Schaden verursacht, dann ist es nur eine Information. Informationen sind eines der wertvollsten Dinge, die Sie haben können, und die Leiter der Organisation haben nicht einmal die Möglichkeit, ohne sie Entscheidungen zu treffen. Wenn Sie ihn feuern, senden Sie außerdem aktiv eine Botschaft aus, dass die Leute Risiken nicht eskalieren oder ihre Initiative nutzen sollten, um sie zu entdecken. Ich stimme zu, dass es ganz anders wäre, wenn er tatsächlich etwas Schädliches getan hätte, aber er tat es nicht.
Obwohl mir die anderen Antworten sehr gut gefallen haben - ich habe auch für eine davon gestimmt -, denke ich, dass diese Antwort und die Folgekommentare sehr gute Informationen, Kenntnisse und brauchbare Ideen enthalten. Deshalb habe ich mich für diese entschieden und nicht für die anderen - und ich mag es auch nicht, Fragen ohne Antwort zu haben.

Also fühlte sich der Entwickler ignoriert, als er eine Bedrohung eskalierte, also zeigte er es ihnen und zeigte es ihnen gut? Organisationen haben jedes Recht, ihre Bedrohungen entweder zu mindern oder sie einfach zu akzeptieren und weiterzumachen. Es ist eine geschäftliche Entscheidung, die auf der Bedrohungsstufe und den zu mindernden Kosten sowie anderen Überlegungen basiert. Sie müssen sich nicht von einem Risikoeskalator das Gegenteil beweisen lassen, indem sie eine Drohung mit einer weniger als sicheren Wahrscheinlichkeit in die Realität umsetzen.

Können Sie sich vorstellen, den Entwickler durch einen TSA-Agenten zu ersetzen und sich in eine Bombe zu hacken? „Boom!" „Siehst du, ich habe es dir doch gesagt!"

Entlasse ihn.

+1 Tolle Analogie, und ich stimme Ihnen zu 100% zu. In einer Organisation ist kein Platz für dieses Verhalten, und selbst wenn Sie ihn in der Nähe behalten würden, hätten Sie wahrscheinlich Vertrauensprobleme mit dieser Person, sowohl vom Management als auch von anderen Teammitgliedern.
Die TSA führt ständig Selbsttests durch. Dies mit einer Bombe zu vergleichen, ist übertrieben. Das ist das Äquivalent zu einem TSA-Agenten, der sich in eine Flasche Wasser schleicht.
Etwas übertrieben. Aber der Punkt war, dass es nicht seine Aufgabe war, Schwachstellen zu testen.
Ich stimme zu, dass es nicht sein Job war, aber heutzutage sind diejenigen, die bereit sind, diese Extrameile zu gehen, sehr selten. Leider machte er zwei Meilen. Er war ehrlich und versuchte, die Gemeinde zu warnen, und er machte danach seine Heldentat. Wenn es umgekehrt gewesen wäre, hätte ich ihn auch gefeuert.
Es ist wie eine Vergoldung. Große Absichten, aber es verursacht normalerweise Probleme für alle auf der Straße. Bei jedem Produkt auf dem Markt gibt es eine Vielzahl bekannter Schwachstellen, die einfach in Kauf genommen werden. Sie können nicht zulassen, dass Ihre Mitarbeiter sie auslösen, weil diese eine Bedrohung für ihn wichtig ist und seine Gefühle verletzt wurden, weil das Management nicht darauf geachtet hat.

Wenn ich Egors Projektmanager wäre, würde ich mich als Egor im Stich lassen.

Mein zweites Prinzip lautet: „Kommunikation ist zu 100 % Ihre Aufgabe (des Projektmanagers, Scrum Masters, Coaches).“ Dieses Problem fällt direkt in diese Maxime.

Als Projektmanager ist es unsere Aufgabe, jeden in unserem Team zu verstehen. Bei jedem Unterfangen mit kreativen Köpfen (Software-Codierung gehört definitiv dazu) werden Sie brillante Leute haben, die nicht gut darin sind, auf eine Weise zu kommunizieren, der die meisten Menschen folgen werden. Als Projektmanager können wir nicht verlangen, dass das Team alle in einer Silbe formulierte PowerPoint-Folien spricht, die der CEO versteht. Stattdessen ist es unsere Aufgabe, dem Team zuzuhören und zu übersetzen.

Ich habe dafür mit großem Erfolg das DISC -Profilsystem genutzt. Kurz gesagt, DISC ist ein Kommunikationsmodell, das auf dem „Standard“-Kommunikationsstil von Menschen basiert. Ds sind eure Storm the Hill Generals, kurz, auf den Punkt. Sind Ihre frohen Verkäufer, "genug davon, dass ich über mich rede, warum redest du nicht über mich". Ss sind die Team-Mama, "können wir uns nicht alle vertragen?" Und die Cs sind die Datenfresser, "Das wäre unlogisch."

Ich wette, Egor würde als hohes C mit hohen S-Tendenzen eingestuft werden. Er wird Ihnen einen zwanzigseitigen schriftlichen Bericht über alles geben, was er an Ruby falsch gefunden hat. Er fängt auch nicht mit dem Punkt an, sondern fängt ganz am Anfang an und erklärt Schritt für Schritt alles. Der Kopf eines durchschnittlichen CEO wäre auf Seite zwei explodiert.

Projektmanager (Scrum Master, Coaches) müssen besser sein als ein durchschnittlicher CEO. Wir müssen lernen, in der Art und Weise, wie unsere Teams kommunizieren, zuzuhören. Wir müssen wissen, wie wir diese Informationen nehmen und sie dann in etwas übersetzen, das jeder andere verstehen kann: „Hey, CEO, Verlust des Kundenvertrauens, was zu einem totalen Umsatzeinbruch und negativer Presse führt, die das Unternehmen ohne genügend Geld zurücklässt, um Ihren goldenen Fallschirm zu finanzieren ."

Wenn ich Egors Projektmanager wäre, hätte ich das Gefühl, sowohl meinen Teamkollegen als auch mein Unternehmen im Stich gelassen zu haben.

Hinweis: Dies ist ein hyperkondensiertes und verallgemeinertes Konzept von DISC und Kommunikationsübersetzung. Dies ist keine konkrete Handlungsempfehlung.

+1 dafür: "Wenn ich Egors Projektmanager wäre, hätte ich das Gefühl, sowohl meinen Teamkollegen als auch mein Unternehmen im Stich gelassen zu haben."
Obwohl ich mit der Kategorie Boxstrategie nicht einverstanden bin, +1 für das gleiche wie Zsolt. PMs sind das Sprachrohr des Teams.

Frage 1:

Nach dem Ereignis haben Sie möglicherweise nur begrenzte Möglichkeiten, dem Entwickler zu "helfen", insbesondere wenn er auf irgendeine Weise gehandelt hat, die als illegal angesehen werden könnte. In einem solchen Fall ist das Beste, was Sie hoffen können, das Problem mit dem Entwickler zu besprechen, aufzuzeigen, welcher Schaden Ihrem Unternehmen durch das Handeln des Entwicklers zugefügt wurde, und ihn zu bitten, seine Sicht auf die Optionen zu schildern, die es gibt Ihnen zur Verfügung. Möglicherweise müssen Sie sich leider immer noch von ihm trennen, um sich und Ihr Unternehmen zu schützen, egal wie ungern Sie diesen Weg einschlagen mögen.

Um eine ähnliche Situation in Zukunft zu vermeiden, sollten Sie erwägen, eine Richtlinie zur akzeptablen Nutzung im Unternehmen einzuführen, die ausdrücklich besagt, dass ein solches Verhalten nicht akzeptabel ist, und vor allem erklärt, warum. Stellen Sie sicher, dass dies allen bestehenden und Mitarbeitern mitgeteilt wird und dass sie die Möglichkeit haben, dies bei Teambesprechungen / Einzelsitzungen oder was auch immer für Sie richtig erscheint, zu besprechen. Erklären Sie, dass dies dazu dient, sie und das Unternehmen zu schützen, und ermutigen Sie Ihre Mitarbeiter, über die Notwendigkeit zu sprechen. Behandeln Sie dies auch bei Einführungsveranstaltungen für neue Mitarbeiter.

Frage 2:

Ich glaube, dass die erste Maßnahme darin besteht, Ihre Bedenken schriftlich festzuhalten und ein formelles Projektrisiko anzumelden, wenn dies möglich ist. Das sollte ihre Aufmerksamkeit erregen. Folgen Sie dem mit einem Telefonanruf oder sogar einem persönlichen Treffen, in dem Sie das Schlimmste benennen, das passieren könnte, wenn der Fehler nicht behoben wird. Letztendlich liegt es in ihrer Verantwortung, den Fehler zu beheben, aber Sie haben die Verantwortung (die Sie bereits erkannt haben), dies mitzuteilen. Nachdem Sie Ihren Fall jedoch so stark wie möglich dargelegt und Lösungen vorgeschlagen haben, wenn Sie können, liegt die letzte Verantwortung beim Kunden. Sie haben noch eine weitere Entscheidung: Wenn das Problem so ernst ist, dass es auch Ihrem Ruf schaden könnte, möchten Sie vielleicht weggehen, anstatt mit dem Problem in Verbindung gebracht zu werden, aber hoffentlich wird es nicht dazu kommen,

GitHub gehackt? Was tun, wenn der ignorierte Entwickler zurückschlägt?
AntwortenHierDatenschutz-Bestimmungen1y, 0v