Suojaa yritystäsi mukautettujen koodausprojektien aikana

Sopimusohjelmoija David Tinley tunnusti 19. heinäkuuta 2019 syytöksensä syyllisyydestä tahallisesta vahingoittumisesta Siemens Corporationille kuuluville tietokoneille. Asiaa koskevien hakemusten mukaan Tinley istutti logiikkapommit koodiin, jota hän kehitti Siemensille sen Monroevillessa, Pennsylvaniassa. Niiden logiikkapommien, jotka olivat koodin osia, jotka ajoitettiin aiheuttamaan häiriöitä viikkojen tai kuukausien kuluttua projektin päättymisestä, oli tarkoitus varmistaa, että Tinsley sai jatkuvan tulovirran siitä, että se joutui korjaamaan virheiksi oletettuja ongelmia. Kun häntä kutsuttiin korjaamaan ongelma, Tinsley yksinkertaisesti muutti päivämäärää logiikkapommissa niin, että se sammuu myöhemmin uudelleen.

Lopulta toinen ohjelmoija kutsuttiin sisään korjaamaan Tinsleyn koodi lomalla ollessaan, ja juuri silloin juoni paljastettiin. 62-vuotias Tinsley oli työskennellyt Siemensissä noin 12 vuotta ennen kiinniottoaan, mutta tuona aikana hän ei ollut koskaan epäillään. Tuomio asetetaan 8. marraskuuta 2019, ja Tinsley voi viettää jopa 10 vuotta vankilassa ja maksaa sakkoja jopa 250 000 dollaria.

Varmuuskopiokoneiden palkkaaminen

Joten miksi kerron sinulle kaiken tämän? Loppujen lopuksi mahdollisuudet palkata ohjelmoija, joka asettaa tietoisesti logiikkapommeja mukautettuihin koodeihin, eivät ole suuria. Ja vaikka nämä mahdollisuudet eivät ole nollia, on olemassa joukko muita asioita, jotka voivat mennä pieleen, kun joku kirjoittaa koodia organisaatiollesi.

"Mitä tapahtuu, jos henkilö jättää tai putoaa kuollut?" kysyy J. Gold Associatesin pääanalyytikko Jack Gold. Gold ehdottaa, että kun palkat jonkun kehittämistä varten, tarvitset aina varmuuskopion. Loppujen lopuksi mukautettu koodi on koodi. Ei ole kolmansia osapuolia, joihin voit kääntyä, jos jotain menee pieleen, ellet aio suunnitella sitä. Hän ehdotti myös, että on olemassa joitain muita vaiheita, jotka yritysten on tehtävä suojellakseen itseään kehitysprosessin aikana, ja tärkeimpien joukossa vaaditaan koodikatsauksia.

"Kooditarkistus on luultavasti paras tapa selvittää koodissasi oleva sisältö", sanoi Camden Associates -yrityksen pääanalyytikko Alan Zeichick, "mukaan lukien logiikkapommit, tietoturva-aukot tai tyhmät virheet."

"Kooditarkastusten tekemiseen on myös muita syitä", Zeichick lisäsi. "Se auttaa kehitysryhmääsi ymmärtämään paremmin kehityksen toimintaa, auttaa nuorempaa ohjelmoijaa ymmärtämään paremmin. Kooditarvikkeet auttavat myös ryhmänpäällikköä käsittelemään kehitysryhmän laatua ja arvioimaan kuinka kauan työn suorittaminen vie loppuun.

Koodiarviointien suorittaminen

Zeichick kertoi, että on olemassa pari tapaa suorittaa kooditarkastus. "Sinulla voi olla joukkue, jossa työskentelee kaksi ihmistä, tai voit tavata konferenssisalissa tarkistaaksesi koodin."

Joukkueet, joissa jokainen jäsen tarkistaa jonkun toisen koodin, ovat kasvussa, kun ohjelmoijia on vaikeampi löytää. Suurissa organisaatioissa säännölliset kokoukset koodin tarkistamiseksi ovat kuitenkin hyödyllisiä, koska silloin useat silmät saavat apua tarkistusprosessissa. Zeichick kertoi, että jopa vanhimmilla ohjelmoijilla tulisi olla koodinsa tarkistaminen.

Joten miksi Siemens antoi Tinleyn mennä kaikki nämä vuodet ilman koodin tarkistusta? Hänen asianajajansa oikeudenkäynnin aikana esittämien kommenttien mukaan Tinley piti hänen koodiaan omistusoikeutena ja käytti sitä tekosyynä olla pitämättä hänen koodiaan uudelleen.

Miksi tämän sallittiin tapahtua, on epäselvää, mutta sekä Zeichick että Gold huomauttavat, että koodin tarkistamista koskevan vaatimuksen tulisi olla osa kaikkea liikeyrityksen ja itsenäisen ohjelmointivälineen välistä sopimusta. Kulta ehdottaa, että sopimuksessa ei mainita vain koodin tarkistuksia, vaan määritetään kuinka ja milloin ne tapahtuvat.

Zeichick huomautti, että jotkut suuret kehityskaupat saattavat tehdä omat koodiarviointinsa, mikä hänen mukaansa on järkevää. "Paras ihmiset, jotka tekevät kooditarkistuksen, ovat kehitysryhmän jäsenet", hän sanoi.

Haitallisten koodereiden välttäminen

Koodikatsaukset ovat olleet lähes ikuisesti. Kun johdin ohjelmoijaryhmää suurelle valtion laitokselle, menimme yli mielenosoittavien COBOL-linjojen joka perjantai-iltapäivä. Vaikka se oli tylsiä, löysimme usein havaintoja, virheitä, väärin sijoitettuja viitteitä tai muita koodausvirheitä. Tosiasia, että me kaikki teemme virheitä, ja järkevä tarkistus tekee koodista paremman kaikille.

Valitettavasti ohjelmoijat toisinaan paheksuttavat koodiarviointeja uskoen, että ne ovat ajanhukkaa. Toiset sanovat, etteivät halua, että ihmiset arvailevat koodiaan. Mutta tosiasia, kieltäytymisen sallimasta koodin tarkistamista olisi oltava punainen lippu. Jos maksat koodin kirjoittamisesta, sopimukseesi voi kohtuudella sisältyä tarkistusvaatimus. Kieltäytyminen siitä on irtisanomisen syy.

Valitettavasti hyvien ohjelmoijien löytäminen on vaikeaa nykyään. Kysyntä on suurta, ja joissakin tapauksissa sopimusohjelmoijien mielestä he voivat ilmoittaa, että heidän ei tarvitse antaa koodin tarkistamista, vaikka heidän yhteyshenkilönsä sanoisi olevansa.

Paras tapa välttää tällaiset ongelmat on ensin kysyä ja sitten soittaa referenssejä aiemmalle työlle. Toiseksi, ota käyttöön ensimmäisen päivän koodiarvioinnit. Tällä tavalla niistä tulee tapana, ja ohjelmoijat, jotka kieltäytyvät antamasta arvosteluja, voidaan erottaa heti - ennen kuin heistä tulee kriittisiä kehitysprosessille.

• Mitä tehdä, kun olet hakkeroitu Mitä tehdä, kun olet hakkeroitu
• 6 Asioita, joita ei saa tehdä tietorikkomuksen jälkeen 6 Asioita, joita ei saa tehdä tietorikkomuksen jälkeen
• Florida City maksaa 600 000 dollaria hakkereille Ransomware Attackin jälkeen Florida City maksaa 600 000 dollaria hakkereille Ransomware Attackin jälkeen

Valitettavasti kehitysprosessin riskit voivat olla suuria. Gold huomauttaa, että epäeettinen ohjelmoija voi lisätä takaovia koodiin, löytää tapoja varastaa asiakastietojasi tai immateriaalioikeuksiasi tai siirtää kriittisiä tietoja toiselle yritykselle tai vieraalle valtiolle.

Tapa estää tämä on hallita jatkuvasti, tarkistaa ohjelmointihenkilöstösi työtuote ja tarkistaa koodi ennen kuin koodihallintajärjestelmäsi hyväksyy sen.