Sichere Codeüberprüfungsanforderung für die Einstellung von Cybersicherheitsingenieuren

mehr im Besitz der Entwicklung, nicht der Cybersicherheit

Das ist absolut vernünftig. Da die Entwicklung die Abteilung ist, die tatsächlich etwas dagegen tun kann, ist es ziemlich sinnlos, sie in eine Richtung laufen zu lassen und ihnen später zu sagen, dass sie ihre Arbeit wiederholen müssen, weil das automatische Scannen eine Schwachstelle gefunden hat. Ich lasse niemanden direkt in den Sonnenuntergang fahren und rufe ihn eine halbe Stunde später an wie „Hey Kumpel, mein Navi sagt, du hättest hier links abbiegen müssen“. Das Tool sollte von den Personen verwendet werden, die das Ergebnis ändern können, und es sollte so schnell wie möglich verwendet werden, nicht nachträglich.

Es sollte normal sein, dass die Entwicklung diese Scans während der Entwicklung durchführt und die Sicherheit sie erneut ausführt (oder die Berichte anfordert), nur um sicherzustellen, dass die Entwicklung ihre Arbeit erledigt hat oder um Schwachstellen in Teilen des Systems zu finden, die nicht in den Händen der internen Entwicklung liegen .

Was groß und reif angeht, ist das schwer zu erraten. Ich habe groß gesehen, ich habe alt gesehen, aber reif ist wirklich etwas, das völlig losgelöst von diesen beiden ist. Ich denke, Sie sind auf der Reifekurve weit voraus, wenn Sie überhaupt erst eine Abteilung oder ein Team für Cybersicherheit haben.

Wie soll ich Kandidaten bewerten, die über beträchtliche Erfahrung in der Verwendung der technischen Tools unseres Teams verfügen, aber möglicherweise keine Erfahrung im Besitz von Prozessen haben oder daran gewöhnt sind, mit einem deutlich anderen Prozess zu arbeiten, der einem anderen Team gehört?

Ich habe die gleiche Frage mit Projektplanungsprozessen. Zum Beispiel Scrum. Es ist immer gut, jemanden mit Erfahrung zu haben, aber am Ende ist es nicht ihre Wahl. Wenn ihr altes Unternehmen es nicht getan hat, ist es nicht ihre Domäne, es zu ändern.

Was ich also tue, ist, dass ich basierend darauf bewerte, was sie theoretisch darüber wissen und ob sie bereit sind, es zu tun. Es ist nicht ihre Schuld, dass sie es vorher nicht getan haben, solange sie interessiert und willens sind. Ich ziehe aber die Grenze bei "noch nie gehört". Auch wenn die ehemalige Firma andere Richtlinien und Abteilungsorganisation hatte, wenn jemand von der Sache noch nichts gehört hat, bedeutet das, dass er sich nicht richtig durch Bücher oder Konferenzen oder Benutzergruppen oder was man sonst tun kann, um auf dem Laufenden zu bleiben, weitergebildet hat.

Ich sehe hier das Problem nicht.

Als ich den Kandidaten fragte, welche Erfahrung er mit statischen und/oder dynamischen Code-Scanning-Tools (SAST/DAST) hat, antworteten sie, dass sie unter anderem Tools wie BurpSuite und SonarQube verwenden, aber der Sicherheitscode-Scanning-Prozess gehört eher der Entwicklung, nicht der Cybersicherheit.

... steht NICHT im Widerspruch zu:

Die Bereitschaft, die Schwachstellen-Management-Prozesse zum Code-Scannen zu besitzen, ist eine entscheidende Anforderung für die Rolle.

Man sagt einfach: "Ich kenne mich mit diesem Thema aus, obwohl die Schwerpunkte in meinen früheren Jobs nicht so waren" und nicht "Ich lehne es ab, die Verantwortung dafür zu übernehmen."

Es ist genau das Gleiche, als würde McDonalds jemanden für einen Drive-Thru-Mitarbeiter interviewen, der sagte: „Ja, ich nehme die Bestellungen entgegen und stehe am Fenster. Wo ich zuletzt gearbeitet habe, wurden sie jedoch von zwei verschiedenen Personen bearbeitet.“

Sie werden nicht sagen: "Alter, dieser Bewerber hat sich geweigert , im Drive-Thru zu arbeiten!" Weil es nicht wahr ist – sie sagen einfach, dass der letzte Ort, an dem sie gearbeitet haben, einen anderen Prozess hatte, nicht, dass sie sich weigern, etwas zu tun!

Dasselbe gilt für Ihren Bewerber. Haben sie wirklich gesagt: "Ich weigere mich, Codes zu scannen!" Denn sonst machst du aus einer (nicht vorhandenen) Maulwurfshügel einen Berg.

Ja, die Zuständigkeit für Aufgaben wie das Scannen auf Schwachstellen und die Behebung von Schwachstellen liegt in vielen Organisationen zunehmend außerhalb einer zentralisierten Sicherheitsorganisation.

Dies wird fast allgemein als Vorteil anerkannt – das Modell des zentralisierten Sicherheitsteams hat 30 Jahre lang versagt, um sichere Systeme und Anwendungen zu produzieren. Daher ist die „Linksverlagerung“ dieser Funktionen in die Teams, die die Software tatsächlich erstellen und die Fähigkeit haben, Schwachstellen tatsächlich zu beheben, ein Beschleuniger, um die Sicherheitsziele tatsächlich zu erreichen.

Hier haben Sie die Möglichkeit, durch die Einstellung von Nachwuchskräften tatsächlich neuere, effektivere Ansätze aus der Branche zu lernen. Es gibt immer noch eine Rolle für engagierte Cybersicherheitsexperten in dieser neuen Arbeitsweise (weshalb Sie mit einer Gruppe von Leuten mit diesen Fähigkeiten sprechen, die einfach nicht von der alten Organisation im Befehls- und Kontrollstil besessen sind). Sie könnten diese neueren Fachkräfte einsetzen, wenn Sie Ihren Fokus auf Bildung, Empowerment und zentralisierte Berichterstattung lenken, anstatt darauf zu bestehen, alles zu „besitzen“. Denn wenn Sie „besitzen“ sagen, meinen Sie das nicht wirklich – Sicherheitsgruppen besitzen immer noch den Ansatz, selbst wenn die Ausführung dieser Aufgaben dezentral in den Teams erfolgt (d. hden Prozess, den die Organisation in diesem Fall verwendet) - Sie meinen das Mikromanagement. Ich würde dringend dazu ermutigen, sich den DevSecOps-Track bei RSA oder anderen ähnlichen Orten anzusehen, um mehr über neuere Ansätze zu erfahren (vielleicht sogar jemanden einzustellen, der sich damit auskennt).

Was „wie man jemanden interviewt, der einen anderen Ansatz verwendet“ – nun, befragen Sie ihn zu seinen Fähigkeiten und sprechen Sie auch mit ihm über Ihren Ansatz. Ich bin ehrlich, es wird wahrscheinlich dazu führen, dass einige von ihnen den Job aufgeben. Ich hatte eine ähnliche Diskussion mit einer technischen Abteilung eines großen Baumarktes über die Leitung eines Teams für die Performance von Webanwendungen – ich hatte dies zuvor getan, indem ich Entwicklungsteams mit Tools und Techniken ausgestattet und die Festlegung abteilungsweiter Ziele geleitet hatte. Ich hatte ein Gespräch mit einigen oberen Managern darüber, dass „nein, wir erwarten, dass SIE und Ihr Team es besitzen und es tun, nicht dieses Hippie-Zeug“, und ich beschloss, die Gelegenheit nicht zu nutzen, weil sie im Grunde den Erfolg künstlich einschränkten sein, und das Leben in der Technik ist zu kurz für diesen Lärm.

Wie soll ich Kandidaten bewerten, die über beträchtliche Erfahrung in der Verwendung der technischen Tools unseres Teams verfügen, aber möglicherweise keine Erfahrung im Besitz von Prozessen haben oder daran gewöhnt sind, mit einem deutlich anderen Prozess zu arbeiten, der einem anderen Team gehört?

Bewerten Sie sie basierend auf ihren Fähigkeiten, Erfahrungen und Verdiensten ... nicht anhand der Prozesse, die ihr aktueller/früherer Arbeitgeber verwendet hat oder verwendet. Sie bringen sie in Ihr Unternehmen und Ihre Prozesse.

Für mich persönlich, als Entwickler von Ruby on Rails, verstehe ich unter „Cybersicherheit“ im Allgemeinen das, was traditionell als Perimetersicherheit und Netzwerksicherheit bezeichnet wird oder in einem Cloud-Kontext als Clustersicherheit oder Cloudsicherheit angesehen werden könnte.

Als Anwendungsentwickler stimme ich Ihrem Kandidaten tendenziell zu, dass im Bereich der App-Entwicklung die App-Entwickler dafür verantwortlich sind, unseren eigenen sicheren Code zu schreiben. Ich denke, es ist am besten für den Entwickler, seinen eigenen sicheren Code zu schreiben, und am besten für die Anwendung. Wenn es „die Aufgabe eines anderen“ ist, meine App sicher zu machen, muss ich ihr weniger Aufmerksamkeit schenken.

Es scheint mir, dass diese Antwort von einem Anwendungsentwickler vollkommen gültig ist, aber vielleicht möchten Sie einen Sicherheitsspezialisten wie Perimeter- und Netzwerksicherheit. Daher die sprachliche Unterscheidung.

Hier ist eine Option, die von einigen missbilligt und von anderen akzeptiert wird: Schicken Sie ihnen eine Übung zum Mitnehmen. Stellen Sie eine temporäre Lizenz für die Tools bereit, beschreiben Sie einen Arbeitsablauf, zusammen mit zu überprüfendem Code und zu erledigenden Aufgaben.

Die großartigen Kandidaten werden den von Ihnen gewünschten Ablauf aufgreifen und ihr Wissen über das Tool nutzen. Die Schlechten reichen das Nötigste ein oder geben einfach auf.

Abhängig von Ihrer Unternehmenskultur und deren Rechtmäßigkeit können Sie sich dafür entscheiden, den Kandidaten einen symbolischen Betrag zu zahlen, z. B. 4-Stunden- oder 8-Stunden-Gehalt. Immer noch günstig im Vergleich zu der Zeit Ihrer Gesprächspartner oder einem Flugticket zum persönlichen Vorstellungsgespräch.

Aber es ist viel mehr Arbeit, es einzurichten und zu warten. YMMV.

PS: Ein Docker-Image, alle Einstellungen mit den Tools und Aufgaben sind einfach zu installieren und zeigen Ihnen den Unterschied zwischen denen, die Dinge herausfinden können, und denen, die es nicht können.