Mitä tulee sisältyä ohjelmistokehityksen tietoturvapolitiikkaan?
Ohjelmistokehityksen tietoturvapoliittinen strategia on asiakirja, jossa määritellään, miten organisaationne käsittelee tietojen, järjestelmien ja koodin turvallisuutta. Ohjelmistoyrityksen osalta se koskee kahta asiaa samanaikaisesti: sen suojausta, mitä rakennatte, ja ympäristön suojausta, jossa sen rakennatte. Molemmat kuuluvat samaan asiakirjaan, vaikka ne ovat sisällöllisesti eri aiheita.
Käytännössä tämä tarkoittaa, että politiikka yleensä käsittelee soveltamisalaa (mitkä järjestelmät ja mitkä kehitysprojektit siihen kuuluvat), vastuita (kuka päättää, kuka hallinnoi, kuka valvoo), sitä, miten pääsy lähdekoodiin ja kehitysympäristöihin järjestetään, miten omassa koodissa olevat haavoittuvuudet löydetään ja korjataan, miten testaus- ja tuotantoympäristöihin suhtaudutaan, miten tapaturmat kirjataan ja miten politiikkaa itsessään ylläpidetään ja tarkistetaan. Ostajan vaatimuksiltaan kysytään usein juuri tällaisia asiakirjoja todisteeksi, ei teknistä kuvausta lähdekoodistanne.
Kaksi tasoa: tuote ja kehitysympäristö
Ensimmäinen taso koskee tuotetta: ohjelmistoa, jonka toimittaa asiakkaille. Siihen kuuluu kuvaus siitä, miten käsittelette toimituksen jälkeen löydettyjä haavoittuvuuksia, miten päivitykset ja korjaukset pääsevät asiakkaiden käyttöön, ja kuka organisaatiossanne on vastuussa tuotteen turvaongelmien ilmoitusten seuraamisesta.
Toinen taso koskee kehitysympäristöä: ympäristöä, jossa tiiminne työskentelee. Se on versionhallintaympäristö, kääntämisen ja testaamisen putki sekä testaus- ja tuotantoympäristöjen erottaminen. Tässä on kyse kysymyksistä kuten kuka saa käyttää lähdekoodia, miten muutoksia ohjataan ennen kuin ne menevät tuotantoon, ja miten pääsy poistetaan, kun joku lähtee tiimistä. Molemmat tasot voidaan sisällyttää samaan asiakirjaan, mutta ne kuvataan usein erikseen, koska niihin liittyvät riskit ja niistä vastuussa olevat tahot ovat erilaiset.
Miksi ostaja tätä kysyy
Organisaatiot, jotka itse joutuvat vastaamaan varautumisvelvollisuudesta, ovat velvoitettuja arvioimaan riskejä toimittajissaan. Ohjelmistoyritys, joka kehittää tällaiselle organisaatiolle, saa näin ollen kysymyksiä, jotka eivät johdu omasta velvollisuudesta vaan toimitusketjusta. Tietoturvapoliittinen strategia pyydetään usein ensimmäisenä, koska se yhdessä asiakirjassa osoittaa, kuinka järjestelmällisesti turvallisuus on käsitelty. Jos se puuttuu, joudut selittämään sen vaatimuksiltaan kysymys kerrallaan, mikä vie enemmän aikaa ja on vähemmän vakuuttavaa kuin olemassa oleva asiakirja.
Se, kuuluuko organisaationne itse varautumisvelvollisuuden piiriin, toimitusketjun piiriin vai kumpaan kumpaan, ei ole yhdellä silmäyksellä nähtävissä. muutamalla kysymyksellä näet, missä organisaatiosi seisoo antaa siihen ensimmäisen viitteen, kertoen perusteella.
Miten tämä politiikka suhteutuu yksittäisiin toimenpiteisiin
Tietoturvapoliittinen strategia ei ole itsenäinen. Se kuvailee pääpiirteissään, miten turvallisuuden kanssa toimitte, kun taas yksittäiset toimenpiteet — pääsynhallinta, varmuuskopiot, tapaturmien kirjaus, toimittajien arviointi — ovat sen konkreettista toteutusta. Kuka kirjoittaa politiikan ilman, että taustalla olevat toimenpiteet ovat kunnossa, hänellä on asiakirja, joka ei vastaa käytäntöä. Päinvastoin on myös vaikeaa: yksittäiset toimenpiteet ilman yhteensovittavaa politiikkaa näyttävät sirpaloituneilta siihen nähden, kuka niistä kysyy. kaikkien aiheiden yleiskatsaus kussakin tilanteessa näyttää, miten nämä osat liittyvät toisiinsa.
Mitä käytännössä usein puuttuu
Monissa näiden politiikkojen ensimmäisissä versioissa puuttuu selkeä vastuuhenkilö kustakin osuudesta: kuka on vastuussa käyttöoikeusja politiikan ajantasaisena pitämisestä, kuka korjauspolitiikan osalta. Usein puuttuu myös kiinteä arviointipäivämäärä, minkä vuoksi kahden vuoden takaa oleva politiikka esitetään edelleen ajankohtaisena, vaikka kehitysputki on sittemmin muuttunut. Ja kolmas usein puuttuva seikka: nimenomainen yhteys politiikan ja todisteisiin, jotka osoittavat sen myös pantavan täytäntöön, kuten käyttöoikeuksien lokit tai luettelo toteutetuista korjauksista.
Arvioi omaa tilannettasi
Tarkalleen mitä osia odotetaan, riippuu organisaatiosi roolista toimitusketjussa ja siitä, mitä tietty ostaja pyytää. Tämä artikkeli kuvaa yleistä rakennetta, ei pakollista mallia, eikä laki itse määritä kiinteää jaottelua. Oman erityistilanteen arviointiin oikea henkilö on lakimies tai toimivaltainen valvontaviranomainen; usein kysytyt kysymykset näistä asiakirjoista antaa lisäkatsauksen siihen, mitä usein kysytään.
Haluatko nähdä, kuinka tämä politiikka yhdessä taustalla olevien toimenpiteiden ja todisteiden kanssa säilytetään jatkuvassa tiedostossa erillisen asiakirjan sijaan? kuinka secria.eu rakentaa ja ylläpitää tietoa näyttää sen. Aloita muutoin ilmaisella NIS2-tarkistuksella tai selaa tietopankkia nähdäksesi, mitkä aiheet ovat relevantteja organisaatiollesi.