Frage:
Wie kann ich Entwicklern helfen, die Anzahl der Sofortnachrichten an mein Team zu reduzieren?
Anthony
2020-04-01 02:34:14 UTC
view on stackexchange narkive permalink

Ich bin der Teamleiter des IT-Sicherheitsteams, in dem ich derzeit arbeite. Wir haben kürzlich unsere jährlichen Schwachstellendurchdringungstests abgeschlossen. Jetzt arbeiten Benutzer an Storys zur Behebung von Schwachstellen.

Viele der entdeckten Probleme befinden sich im Anwendungscode und sind klassische Anwendungsschwachstellen, wie sie in der OWASP-Dokumentation erwähnt werden. Nur durch Beheben des Fehlers im Code werden die Sicherheitslücken behoben. Entwickler, die Storys sehr häufig zugewiesen wurden (zweistellige Zahlen an einem einzigen Tag), senden mir oder einem Teammitglied in meinem Team eine IM, um eine Lösungsvalidierung, Fragen zur Implementierung usw. anzufordern, sodass andere Arbeiten, die wir haben, gestört werden - Reaktion auf Vorfälle, Scannen von Sicherheitslücken, Überprüfung der Einhaltung von Vorschriften usw.

Ich möchte weder die Entwicklung von Fixes verlangsamen, noch distanziert und nicht bereit sein, zu helfen. Bis zu einem gewissen Grad verstehe ich die Aktionen der Entwickler, da unser Team die Experten für Sicherheit sind.

Vielleicht ist ein Wiki oder eine Knowledge Base-Lösung der richtige Weg, damit Fragen asynchron zusammengestellt und beantwortet werden können? Entwickler haben unterschiedliche Erfahrungsstufen, wobei einige mehr Hilfe benötigen als andere.

Wie kann ich höflich sagen, dass die einmaligen Anfragen über IM allmählich nicht mehr funktionieren?

Als Nebenbemerkung ist es wahrscheinlich, dass mit der Zeit die Anzahl der IMs sinken wird, wenn die Geschichten fertiggestellt werden ...
Könnten Sie hier einen Eindruck von der Lautstärke vermitteln?Die Anzahl der Entwickler, Mitglieder des Sicherheitsteams und das Fehlervolumen können sich auf mögliche Antworten auswirken.Darüber hinaus besteht die typische Reaktion auf diese Art von Erfahrung darin, diese Ad-hoc-Anfragen in formellere Support-Kanäle zu leiten, von denen es den Anschein hat, dass Sie sie auch haben.Gibt es einen Grund, warum Sie das noch nicht ausprobiert haben?
Einfache Online-Aufgabenliste?Trello ist gut dafür, und es gibt andere Lösungen.Die Leute können immer noch um Hilfe bitten, sobald sie wissen, dass sie sie brauchen, aber die Leute, die antworten, können dies nach ihrem eigenen Zeitplan tun.
Das klingt nach einem großen Projekt, das von vielen Teams durchgeführt wird.Vielleicht ist es möglich, einen eigenen Chat-Kanal für dieses Projekt zu erstellen und alle, die Korrekturen vornehmen, dazu zu bringen, sich anzumelden.Wenn dann Fragen beantwortet werden, können andere die Antworten sehen, und hoffentlich passieren zwei Dinge: Sie kennen die Antwort UND sie kennen die Prinzipien, die zur Definition der Antwort beigetragen haben.Ist ein solcher Chatkanal möglich?
Acht antworten:
#1
+10
Matthew Gaiser
2020-04-01 02:56:30 UTC
view on stackexchange narkive permalink

Warum nicht eine dedizierte E-Mail oder ein einzelner Support-Chat?

Widmen Sie einen Ihrer Mitarbeiter (dies scheint einer Vollzeitstelle zu entsprechen) der Arbeit mit dem Entwickler müssen diese Fragen beantworten und verlangen, dass alle Fragen dort eingehen.

Sie können sogar noch weiter gehen und ein Ticketingsystem verwenden, mit dem auf zuvor beantwortete Fragen verwiesen werden kann, wenn sie erneut gestellt werden.

Und Sie können den Entwicklern wahrscheinlich nur sagen, dass eine bestimmte Organisationsebene erforderlich ist. Jeder Entwickler, den ich kenne, beschwert sich über eine Unterbrechung. Ich bin mir also sicher, dass er es verstehen würde, wenn er die Menge der gestellten Fragen versteht.

#2
+8
Stephan Branczyk
2020-04-01 03:32:47 UTC
view on stackexchange narkive permalink

Bürozeiten. Legen Sie regelmäßige Zeiten fest, zu denen Sie für Fragen erreichbar sind. Oder machen Sie das Gegenteil und legen Sie regelmäßige Zeiten fest, zu denen Ihr Team die Kommunikation mit der Außenwelt abschaltet.

Verwenden Sie für Abmeldungen und andere asynchrone Kommunikationen https://asana.com/ oder ein Wiki.

Beachten Sie jedoch, dass keine Technologie perfekt ist. Viele werden IM weiterhin verwenden, weil es praktisch ist und sie glauben, auf diese Weise eine schnellere Antwort zu erhalten.

+1.Kombinieren Sie dies mit der von anderen Antwortenden vorgeschlagenen IM-Gruppe, an der Sie während der "Bürozeiten" aktiv teilnehmen sollten, und beantworten Sie diese Art von Fragen nicht mehr direkt (weisen Sie die IM-Gruppe höflich auf Initiatoren hin).
#3
+5
DarkCygnus
2020-04-01 02:49:19 UTC
view on stackexchange narkive permalink

Zuerst werde ich Ihre Frage nicht beantworten (hehe) und vorschlagen, dass Sie vielleicht einen Gruppenchat mit der von Ihnen verwendeten IM-Software führen könnten , in der diese Fragen veröffentlicht werden können.

Auf diese Weise können entweder Sie oder ein anderes Mitglied jede dort gestellte Frage validieren oder beantworten, und auf frühere beantwortete Fragen kann schnell verwiesen werden.

Dies wird die Belastung sicherlich verringern auf Sie allein alle Nachrichten zu beantworten.

Wie kann ich höflich sagen, dass die einmaligen Anfragen über IM allmählich nicht mehr bearbeitet werden können?

Ich würde höflich und höflich eine E-Mail an die Beteiligten schreiben Bitten Sie sie, ihre Fragen zu verdichten, oder versuchen Sie zuerst, andere Mitglieder zu konsultieren.

Wenn Sie dem Vorschlag für einen Gruppenchat folgen, können Sie auch die E-Mail schreiben und stattdessen höflich ankündigen, dass ein solcher Gruppenchat jetzt der offizielle ist Kanal zum Stellen / Beantworten von Fragen zu den User Stories.

#4
+3
Donald
2020-04-01 18:25:48 UTC
view on stackexchange narkive permalink

Viele der entdeckten Probleme befinden sich im Anwendungscode und sind klassische Anwendungsschwachstellen, wie sie in der OWASP-Dokumentation erwähnt werden. Nur durch Beheben des Fehlers im Code werden die Schwachstellen behoben. Entwickler, die Storys sehr häufig zugewiesen wurden (zweistellige Zahlen an einem einzigen Tag), senden mir oder einem Teammitglied in meinem Team eine IM, um eine Lösungsvalidierung, Fragen zur Implementierung usw. anzufordern, sodass andere Arbeiten, die wir haben, gestört werden - Reaktion auf Vorfälle, Scannen von Sicherheitslücken, Überprüfung der Einhaltung von Vorschriften usw.

Ich spreche mit mehr als einem Jahrzehnt Erfahrung in der Softwareentwicklung. Wenn Sie versuchen, jede bekannte Sicherheitsanfälligkeit in einer einzigen Version zu beheben, ist es sinnvoll, jedes Update zu validieren. Es ist jedoch äußerst schwierig, Software zu schreiben, die keine Fehler enthält. Das bedeutet, dass das Entwicklungsteam immer Schwachstellen behebt, sodass Ihr Unternehmen etwas anderes tun muss, andernfalls überprüft Ihr Team nur Fehlerbehebungen.

Ihr Unternehmen sollte ermitteln, wie diese Schwachstellen behoben werden. Ihr Sicherheitsteam sollte einen potenziellen Release-Build vor einem potenziellen Release-Datum evaluieren, damit der Build rechtzeitig und mit der entsprechenden Anzahl von Sicherheitslücken für diesen Build veröffentlicht werden kann. Den Entwicklern sollte gestattet werden, zu identifizieren, welche Sicherheitslücken in diesem Build behoben wurden oder nicht.

Ich möchte die Entwicklung von Fixes nicht verlangsamen erscheinen distanziert und nicht bereit zu helfen. Bis zu einem gewissen Grad verstehe ich die Aktionen der Entwickler, da unser Team die Experten für Sicherheit sind.

Entwickler müssen keine Sicherheitsexperten sein, um zu verstehen, wie eine Sicherheitsanfälligkeit behoben werden kann. Wenn eine Sicherheitsanfälligkeit festgestellt wurde und sowohl das unangemessene als auch das ordnungsgemäße Verhalten festgestellt wurden, sollte ein Entwickler in der Lage sein, die Ergebnisse eines Softwarefixes zu überprüfen, um das richtige Verhalten zu erzielen. Auf diese Weise kann Ihr Team Korrekturen vor einem möglichen Veröffentlichungsdatum validieren und dem Entwicklungsteam genügend Zeit geben, um festzustellen, welche Fehler für den nächsten Veröffentlichungszyklus übrig bleiben.

Möglicherweise ein Wiki oder Wissen Basislösung ist der richtige Weg, damit Fragen asynchron zusammengestellt und beantwortet werden können? Entwickler haben unterschiedliche Erfahrungsstufen, wobei einige mehr Hilfe benötigen als andere.

Leider gibt es keine einheitliche Antwort auf diese Frage. Dies kann Ihr Unternehmen entscheiden.

Wie kann ich höflich sagen, dass die einmaligen Anfragen über IM nicht mehr funktionieren?

Sie haben die Möglichkeit, Änderungen selbst zu implementieren. Sie sollten festlegen, welches System verwendet wird. um zu überprüfen, ob ein potenzieller Fix eine Sicherheitsanfälligkeit behebt oder nicht. Als Teamleiter sollten Sie mit den anderen Teamleitern sprechen und den besten Weg finden, um vorwärts zu kommen. Sie sollten diesen Teamleitern erlauben, das andere Ende des Seils zu handhaben. Es hört sich so an, als hätten Sie genug zu tun.

Vielen Dank für Ihre Erfahrung!Bevor die Storys den Entwicklern zugewiesen wurden, wurde der Kritikalitätsgrad jeder Sicherheitsanfälligkeit von unserem Team in Absprache mit den Geschäftsinhabern jeder Anwendung bewertet.
Wir haben auch ein robustes QS-Team, das sowohl automatische als auch manuelle Tests durchführt.Ich denke darüber nach, dass sie einige der zukünftigen nicht funktionsfähigen Release-Anforderungen validieren, wie z. B. Sicherheitskontrollen.Irgendwelche Gedanken?
@Anthony - Sie sollten alles tun, was für Ihr Team funktioniert.
#5
+2
Dave3of5
2020-04-01 20:55:15 UTC
view on stackexchange narkive permalink

Klingt so, als ob Ihr Remote-Arbeitssystem hier falsch ist. Ich würde vorschlagen, einen Kanal oder eine Gruppe zu haben, der Fragen stellen kann, und jemanden aus Ihrem Team entweder täglich oder wöchentlich zuzuweisen, um diese Fragen zu beantworten. Angesichts der Tatsache, dass es sich um ein jährliches Audit handelt, würde ich mich täglich daran halten und dass nur Personen dafür verantwortlich sind, Fragen der Entwickler an diesem Tag zu beantworten. Wird es die Gesamtarbeitsmenge reduzieren, die Ihr Team leisten kann? Ich würde die Vermutung wagen, dass Sie, wenn Ihr Team nicht aus 1-2 Personen besteht, immer noch viel Arbeit erledigen können.

Sie können keine Menge aufbringen von technischen Tickets und erwarten 0 Fragen von der Person, die mit der Arbeit beauftragt ist. Sie müssen also bereit sein, zu helfen, und das bedeutet, unterbrochen zu werden.

In Bezug auf die Entwickler, die nicht wissen, welche Lösungen es gibt, ist dies besonders in Teams mit weniger erfahrenen Entwicklern üblich. Es ist also sehr schlecht, sie auf ein Wiki zu verweisen. Es hört sich so an, als ob Sie auch viele Schwachstellen aufgreifen müssen, die ich bei einem Ihrer Management-Meetings darauf hinweisen sollte, dass die Arbeit nicht nach bewährten Methoden durchgeführt und auf Schwachstellen überprüft wird. Das liegt wirklich in der Verantwortung der Entwickler / leitenden Angestellten, entweder die richtigen Mitarbeiter einzustellen oder die aktuellen Mitarbeiter mit den Schulungen zu schulen, die Sie für richtig halten. Ich sage, Sie halten es für richtig, wenn Sie darüber informiert werden, welche Schulungen die Entwickler benötigen, wenn sie grundlegende Fragen stellen, die durch Lesen der OWASP-Liste beantwortet werden können.

Dies ist keine ungewöhnliche Situation, in der Entwicklerteams tätig sind Welt sind sich XSS, SQL-Injection ... usw. nicht bewusst. Als Leiter des "InfoSec" -Teams liegt es in Ihrer Verantwortung, der gesamten Organisation beizubringen, wie wichtig Informationssicherheit ist und ob die Entwickler keine Ahnung haben, was sie lernen müssen. Dies alles hängt von der Unterstützung der Geschäftsleitung ab, als ob sie glauben, Sie würden aus einem Maulwurfshügel einen Berg machen, und Sie könnten sich als klebriges Wicket wiederfinden.

Ja, es wurden viele Sicherheitslücken festgestellt, und mein Team hat bestätigt, dass die von Drittanbietern festgestellten Sicherheitslücken mit gültigen Angriffsmethoden auf uns zutreffen.Ja, Entwicklerschulungen in Software-Sicherheit waren historisch gesehen nicht die besten, und wir versuchen, die Verschiebung im Entwicklungszyklus nach links zu verschieben.Die Teamgröße beträgt 8.
Dann können Sie Ressourcen sparen, um den Entwicklern zu helfen.
#6
+1
codebeard
2020-04-03 04:18:47 UTC
view on stackexchange narkive permalink

Dies ist eine Gelegenheit für das Sicherheits- und das Entwicklungsteam. Silos sind allzu häufig und Sie haben die Möglichkeit, einige hier zu sprengen. Ich kann mir vorstellen, dass beide Teams sehr an Cross-Training und Zusammenarbeit interessiert sind. Aber bevor Sie so weit kommen ...

Ich denke, es ist wirklich wichtig, sich an die zwei sehr unterschiedlichen Kulturen zu erinnern, die Sie in dieser Situation haben.

In Ihrem Beispiel hat das Sicherheitsteam eine Analyse durchgeführt und gab die Ergebnisse ab, aber ohne die Absicht, den Code zu schreiben. Sie sind fertig.

Softwareentwicklungsteams sind in der Regel chaotischer, kooperativer und verfügbarer. Selbst wenn die Arbeit abgeschlossen ist, sind sie nie wirklich "erledigt". Es gibt immer mehr Arbeit am Projekt und aus diesem Grund sind Entwickler verfügbar, erwarten aber auch, dass andere verfügbar sind. Etwas wie "Du hast mich gebeten, etwas zu tun, nun, ich muss dir Fragen dazu stellen, damit wir es richtig machen". Beachten Sie auch, dass Entwickler normalerweise nur mit Geschäftsleuten oder Benutzern zu tun haben, die in der Regel hoch verfügbar und bereit sind, zu sprechen. Selbst in dieser Situation, insbesondere in der agilen Welt, ist dies organisiert.

In einer idealen Situation müssten nicht alle Entwickler ständig mit allen sprechen. Es würde einen Projektmanager geben, der Meetings nur mit den erforderlichen Personen, Teamleitern und Produktbesitzern organisiert. Auf diese Weise können Probleme und Fragen an die richtigen Personen in Teams weitergeleitet werden, und die Besprechungen werden effizienter.

Der Schlüssel hier ist, dass Sie jemanden benötigen, der die Verantwortung übernimmt. Teamleiter und Projektmanager.

Für alle anderen einmaligen Fragen erstellen Sie einen Gruppenchat-Kanal, den beide Teams getrennt von ihren eigenen Kanälen teilen können, mit dem Verständnis, dass größere Fragen an die Leiter und die Quickies gehen kann zu diesem informellen Kanal gehen.

Grundsätzlich empfehle ich, ein wenig Agile zu folgen, auf das das Entwicklerteam springen sollte. Sie sollten auch in der Lage sein, mit ihrem Lead zu sprechen und etwas auszuarbeiten. Jeder mag es nicht, den Kontext zu wechseln oder unterbrochen zu werden, und beide Teams verstehen das.

Zurück zur dauerhafteren Zusammenarbeit. Regelmäßige Shows im Showup-Stil und Tells oder Hackathons würden wahrscheinlich einen großen Beitrag zu einer ernsthaften Teambindung leisten. Es wäre wahrscheinlich auch ein großer Gewinn, dem Entwicklerteam eine Sicherheitsperson für einen Sprint zu leihen. Und umgekehrt: Ein Entwickler tritt dem Sicherheitsteam für ein oder zwei Sprints bei, um beim Erstellen von Skripten zu helfen. Ich kann gar nicht genug betonen, wie wertvoll Cross-Training ist. Dadurch werden beide Teams besser.

#7
+1
user114216
2020-04-03 14:06:16 UTC
view on stackexchange narkive permalink

Als Entwickler kann ich Ihnen versichern, dass Sie etwas erleben, das das Entwicklerteam ähnlich nervig finden würde, sodass Sie allen Anfragen, die Sie stellen, diese Tatsache voranstellen können. Im Wesentlichen müssen Sie den Fluss eingehender Anforderungen verlangsamen. Wir haben einen bestimmten Manager, der die Fragen zusammenstellt und in regelmäßigen Abständen weiterleitet. Idealerweise wählen Sie beispielsweise zweimal täglich ein Intervall, das die Auswirkungen auf Ihr Team verringert, ohne die Auswirkungen auf das andere Team zu beeinträchtigen.

#8
+1
gnasher729
2020-04-04 19:26:14 UTC
view on stackexchange narkive permalink

Die Aufgabe Ihres Teams besteht nicht darin, Sicherheitsprobleme zu finden. Die Aufgabe Ihres Teams besteht darin, alles zu tun, um die Anzahl der vorhandenen Sicherheitsprobleme zu verringern. Das ist nicht ganz dasselbe - es bedeutet, dass Sie nicht nur Sicherheitsprobleme finden müssen, sondern auch Entwicklern die Mittel zur Verfügung stellen müssen, um diese Sicherheitsprobleme zu beheben, und Informationen, die sie benötigen, um Prioritäten zu setzen, was zuerst behoben wird, was behoben wird später, was möglicherweise überhaupt nicht behoben wird.

Deshalb erhalten Sie so viele Anfragen nach zusätzlichen Informationen: Weil Ihr Team überhaupt keine gute Arbeit geleistet hat. Zumindest würde ich für jedes gefundene Problem Folgendes erwarten: Wie überprüft ein Entwickler, ob das Problem vorliegt, wie überprüft er, ob das Problem behoben wurde, welche Auswirkungen hat das Problem (was kann passieren, wenn dies nicht der Fall ist)? (nicht behoben) und alle anderen Informationen, die Sie zu diesem Problem haben.

Anstatt zu fragen, wie ich mit vielen Informationsanfragen von Entwicklern umgehe, sollten Sie sich fragen, was ich Entwicklern bereitstellen muss, damit es überhaupt keine Fragen gibt.

PS. "Wir haben bereits durch Tools überprüft, dass alle Schwachstellen mit gültigen Angriffsmethoden anwendbar sind", hilft den Entwicklern kein bisschen. Haben sie die Werkzeuge zur Verfügung? Haben Sie Beschreibungen, was zu tun ist, um die Sicherheitsanfälligkeit zu provozieren, und um zu überprüfen, ob sie verschwunden ist? Wie gesagt, Ihr Problem ist, dass Sie nicht die Informationen bereitstellen, die die Entwickler benötigen.

"Schweregrad der Sicherheitslücken" - das sagt mir nicht, wie sich das Geschäft auswirkt, und entscheidet darüber, in welcher Reihenfolge Korrekturen angewendet werden müssen. Sie sprechen in einer Sprache, die sowohl Unternehmen als auch Entwicklern fremd ist. Sie scheinen auch fest entschlossen zu sein, nicht zu lernen.

Wir haben bereits durch Tools überprüft, dass alle Sicherheitslücken mit gültigen Angriffsmethoden anwendbar sind.Die Auswirkungsanalyse wurde bereits durchgeführt und der Schweregrad der Sicherheitslücken eingestuft


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...