Zuhause Geschäft Schützen Sie Ihr Unternehmen bei benutzerdefinierten Codierungsprojekten

Schützen Sie Ihr Unternehmen bei benutzerdefinierten Codierungsprojekten

Inhaltsverzeichnis:

Video: Datensicherung für kleine-mittlere Unternehmen - Hyper Backup Webinar DSM 6.0 (November 2024)

Video: Datensicherung für kleine-mittlere Unternehmen - Hyper Backup Webinar DSM 6.0 (November 2024)
Anonim

Am 19. Juli 2019 bekannte sich der Vertragsprogrammierer David Tinley schuldig, Computer der Siemens Corporation absichtlich beschädigt zu haben. Den Akten zufolge hat Tinley in den Code, den er für Siemens am Standort Monroeville, Pennsylvania, entwickelte, Logikbomben eingesetzt. Diese Logikbomben, die Teile des Codes waren, die Wochen oder Monate nach Abschluss eines Projekts eine Unterbrechung verursachten, sollten sicherstellen, dass Tinsley einen konstanten Ertragsstrom erzielte, indem er die Probleme beheben musste, von denen angenommen wurde, dass es sich um Fehler handelte. Als er zur Behebung eines Problems gerufen wurde, änderte Tinsley einfach das Datum der Logikbombe, damit es später wieder losging.

Schließlich wurde ein anderer Programmierer hinzugezogen, um Tinsleys Code zu reparieren, während er im Urlaub war, und dann wurde die Handlung aufgedeckt. Der 62-jährige Tinsley arbeitete ungefähr 12 Jahre lang für Siemens, bevor er erwischt wurde. In dieser Zeit wurde er jedoch nie verdächtigt. Die Verurteilung ist für den 8. November 2019 angesetzt, und Tinsley könnte bis zu 10 Jahre im Gefängnis verbringen und Geldstrafen von bis zu 250.000 USD zahlen.

Backup-Codierer einstellen

Warum erzähle ich Ihnen das alles? Schließlich sind die Chancen, dass Sie einen Programmierer einstellen, der bewusst Logikbomben in Ihren benutzerdefinierten Code einfügt, nicht groß. Und obwohl diese Chancen nicht gleich Null sind, gibt es eine Reihe anderer Dinge, die schief gehen können, wenn jemand Code für Ihr Unternehmen schreibt.

"Was passiert, wenn diese Person geht oder tot umfällt?" fragt Jack Gold, Principal Analyst bei J. Gold Associates. Gold empfiehlt, dass Sie immer ein Backup benötigen, wenn Sie jemanden für die Entwicklung einstellen. Schließlich ist benutzerdefinierter Code Ihr Code. Es gibt keinen Dritten, an den Sie sich wenden können, wenn etwas schief geht, es sei denn, Sie planen dies. Er schlug auch vor, dass es einige andere Schritte gibt, die Unternehmen unternehmen müssen, um sich während des Entwicklungsprozesses zu schützen.

"Eine Codeüberprüfung ist wahrscheinlich der beste Weg, um herauszufinden, was in Ihrem Code enthalten ist", sagte Alan Zeichick, Principal Analyst bei Camden Associates.

"Es gibt andere Gründe, Code-Reviews durchzuführen", fügte Zeichick hinzu. "Es hilft Ihrem Entwicklerteam, ein besseres Verständnis für die Funktionsweise der Entwicklung zu erlangen, und den Junior-Programmierern, ein besseres Verständnis zu erlangen. Code-Reviews helfen dem Team-Manager auch, die Qualität des Entwicklerteams in den Griff zu bekommen und eine Schätzung der Dauer zu erhalten Es wird dauern, bis der Job abgeschlossen ist.

Durchführung von Code Reviews

Zeichick gab an, dass es mehrere Möglichkeiten gibt, Code-Reviews durchzuführen. "Sie können ein Team haben, in dem zwei Personen daran arbeiten, oder Sie können sich in einem Konferenzraum treffen, um den Code zu überprüfen."

Teams, in denen jedes Mitglied den Code eines anderen überprüft, werden immer beliebter, da Programmierer immer schwerer zu finden sind. In größeren Organisationen sind jedoch regelmäßige Besprechungen zur Überprüfung des Codes immer noch nützlich, da dann mehrere Augen bei der Überprüfung hilfreich sind. Zeichick sagte, dass selbst die erfahrensten Programmierer ihren Code überprüfen lassen sollten.

Warum ließ Siemens Tinley all die Jahre ohne Code-Überprüfung durch? Nach den Kommentaren seines Anwalts während des Prozesses betrachtete Tinley seinen Code als geschützt und benutzte dies als Ausrede, um seinen Code nicht überprüfen zu lassen.

Warum dies geschehen durfte, ist unklar, doch sowohl Zeichick als auch Gold weisen darauf hin, dass eine Anforderung für Codeüberprüfungen Bestandteil eines Vertrags zwischen einem Unternehmen und einem unabhängigen Programmierunternehmen sein sollte. Gold schlägt vor, dass der Vertrag nicht nur Codeüberprüfungen erwähnt, sondern auch angibt, wie und wann sie stattfinden.

Zeichick merkte an, dass einige große Entwicklungsunternehmen möglicherweise eigene Code-Reviews durchführen, was seiner Meinung nach Sinn macht. "Die besten Personen für die Codeüberprüfung sind die Mitarbeiter des Entwicklungsteams", sagte er.

Vermeiden von böswilligen Programmierern

Code-Reviews gibt es schon fast seit Ewigkeiten. Als ich ein Team von Programmierern für eine große Regierungseinrichtung leitete, gingen wir jeden Freitagnachmittag durch die sinnlosen Zeilen von COBOL. Während es langwierig war, fanden wir häufig Versehen, Fehler, verlegte Verweise oder andere Codierungsfehler. Tatsache ist, dass wir alle Fehler machen und eine vernünftige Überprüfung den Code für alle besser macht.

Leider ärgern sich Programmierer manchmal über Codeüberprüfungen und glauben, sie seien Zeitverschwendung. Andere sagen, sie wollen nicht, dass Leute ihren Code hinterfragen. Die Weigerung, die Überprüfung von Code zuzulassen, sollte jedoch eine rote Fahne sein. Wenn Sie für den zu schreibenden Code bezahlen, kann Ihr Vertrag vernünftigerweise eine Überprüfungsanforderung enthalten. Die Weigerung, dies zu tun, ist Anlass zur Entlassung.

Leider ist es heutzutage schwierig, gute Programmierer zu finden. Die Nachfrage ist hoch, und in einigen Fällen haben Vertragsprogrammierer das Gefühl, dass sie angeben können, dass sie sich nicht einer Überprüfung ihres Codes unterziehen müssen, auch wenn ihr Kontakt dies vorschreibt.

Der beste Weg, solche Probleme zu vermeiden, besteht darin, zunächst Referenzen für frühere Arbeiten anzufordern und diese dann aufzurufen. Erzwingen Sie zweitens Codeüberprüfungen ab dem ersten Tag. Auf diese Weise werden sie zur Gewohnheit, und Programmierer, die sich weigern, Überprüfungen vorzunehmen, können sofort entlassen werden - bevor sie für den Entwicklungsprozess kritisch werden.

  • Was tun, wenn Sie gehackt wurden? Was tun, wenn Sie gehackt wurden?
  • 6 Dinge, die Sie nach einer Datenverletzung nicht tun sollten 6 Dinge, die Sie nach einer Datenverletzung nicht tun sollten
  • Florida City zahlt nach Ransomware-Angriff 600.000 US-Dollar an Hacker Florida City zahlt nach Ransomware-Angriff 600.000 US-Dollar an Hacker

Leider können die Risiken im Entwicklungsprozess groß sein. Gold weist darauf hin, dass ein unethischer Programmierer Hintertüren in Ihren Code einfügen, Wege finden kann, Ihre Kundendaten oder Ihr geistiges Eigentum zu stehlen oder kritische Daten an ein anderes Unternehmen oder eine ausländische Macht weiterzugeben.

Um dies zu verhindern, müssen Sie kontinuierlich verwalten, das Arbeitsprodukt Ihres Programmierpersonals überprüfen und den Code überprüfen, bevor er von Ihrem Codeverwaltungssystem akzeptiert wird.

Schützen Sie Ihr Unternehmen bei benutzerdefinierten Codierungsprojekten