ISO 27002:2022, Beheer 8.28 – Veilige kodering

Eienaarskap van beheer 8.28

Aangesien 8.28 die ontwerp en implementering van organisasiewye veilige koderingbeginsels en -prosedures vereis, behoort die hoofinligtingsekuriteitsbeampte verantwoordelik te wees om toepaslike stappe vir voldoening te neem.

Algemene riglyne oor nakoming

Beheer 8.28 vereis van organisasies om organisasiewye prosesse vir veilige kodering daar te stel en te implementeer wat van toepassing is op beide sagtewareprodukte verkry van eksterne partye en op oopbronsagtewarekomponente.

Verder moet organisasies op hoogte bly van ontwikkelende werklike sekuriteitsbedreigings en met die mees onlangse inligting oor bekende of potensiële sagteware-sekuriteitskwesbaarhede. Dit sal organisasies in staat stel om robuuste veilige sagteware-koderingbeginsels te verbeter en te implementeer wat effektief is teen ontwikkelende kuberbedreigings.

Aanvullende leiding oor beplanning

Veilige sagteware kodering beginsels moet gevolg word beide vir nuwe kodering projekte en vir sagteware hergebruik bedrywighede.

Hierdie beginsels moet nagekom word vir beide in-huis sagteware-ontwikkeling aktiwiteite en vir die oordrag van die organisasie se sagteware produkte of dienste aan derde partye.

By die opstel van 'n plan vir veilige koderingbeginsels en die bepaling van die voorvereistes vir veilige kodering, moet organisasies aan die volgende voldoen:

• Organisasies moet sekuriteitsverwagtinge bepaal wat aangepas is vir hul behoeftes en goedgekeurde beginsels vir veilige sagtewarekodering daarstel wat van toepassing sal wees op beide interne sagteware-ontwikkeling en uitgekontrakteerde sagtewarekomponente.
• Organisasies moet die mees algemene en historiese swak kodering-ontwerppraktyke en -foute opspoor en dokumenteer wat lei tot die kompromie van inligtingsekuriteit.
• Organisasies moet sagteware-ontwikkelingsnutsmiddels in plek stel en konfigureer om die sekuriteit van alle kode wat geskep word, te verseker. Een voorbeeld van sulke instrumente is geïntegreerde ontwikkelingsomgewings (IDE).
• Organisasies moet voldoen aan die leiding en instruksies wat deur sagteware-ontwikkelingsinstrumente verskaf word.
• Organisasies moet ontwikkelingsinstrumente soos samestellers hersien, onderhou en veilig gebruik.

Aanvullende leiding oor sekuriteit tydens kodering

Veilige koderingspraktyke en -prosedures moet die volgende in ag neem vir die koderingsproses:

• Veilige sagteware kodering beginsels moet aangepas word vir elke programmeertaal en tegnieke wat gebruik word.
• Ontplooiing van veilige programmeringstegnieke en -metodes soos toetsgedrewe ontwikkeling en paarprogrammering.
• Gebruik van gestruktureerde programmeringsmetodes.
• Behoorlike kode dokumentasie en verwydering van kode defekte.
• Verbod op die gebruik van onveilige sagteware-koderingsmetodes soos nie-goedgekeurde kodemonsters of hardgekodeerde wagwoorde.

Aanvullende leiding merk ook op dat sekuriteitstoetsing beide tydens en na die ontwikkeling uitgevoer moet word in ooreenstemming met Beheer 8.29.

Voordat die sagteware in die lewendige toepassingsomgewing gebruik word, moet organisasies die volgende oorweeg:

• Wat is die aanvaloppervlak?
• Word die beginsel van minste bevoorregting gevolg?
• Ontleding van die mees algemene programmeringsfoute en dokumentasie dat hierdie risiko's uitgeskakel is.

Aanvullende leiding oor hersieningsproses

Nadat die kode in die produksie-omgewing in gebruik geneem is

• Opdaterings moet op 'n veilige manier toegepas word.
• Sekuriteitskwesbaarhede wat in ooreenstemming met Beheer 8.8 aangemeld is, moet aangespreek word.
• Vermeende aanvalle op inligtingstelsels en foute moet aangeteken word en hierdie rekords moet met gereelde tussenposes hersien word sodat toepaslike veranderinge aan kode gemaak kan word.
• Ongemagtigde toegang tot, gebruik van of veranderinge aan bronkode moet deur meganismes soos bestuursnutsmiddels voorkom word.

Wanneer organisasies eksterne gereedskap gebruik, moet hulle die volgende in ag neem

• Eksterne biblioteke moet met gereelde tussenposes gemonitor en bygewerk word op grond van hul vrystellingsiklusse.
• Sagtewarekomponente moet noukeurig nagegaan, geselekteer en gemagtig word, veral kriptografie- en verifikasiekomponente.
• Lisensiëring van eksterne komponente en die versekering van hul sekuriteit.
• Sagteware moet opgespoor en onderhou word. Verder moet verseker word dat dit van 'n betroubare bron kom.
• Ontwikkelingshulpbronne behoort vir die langtermyn beskikbaar te wees.

Wanneer veranderinge aan 'n sagtewarepakket gemaak word, moet die volgende oorweeg word

• Risiko's wat kan ontstaan ​​uit ingeboude kontroles of kompromie van integriteitsprosesse.
• Of die verkoper toestemming gee tot veranderinge.
• Of dit moontlik is om toestemming van die sagtewareverkoper te kry vir gereelde opdaterings.
• Die waarskynlike impak van die instandhouding van die sagteware wat voortspruit uit veranderinge.
• Of die veranderinge versoenbaar is met ander sagtewarekomponente wat deur die organisasie gebruik word.

Bykomende leiding oor beheer 8.28

Organisasies moet verseker dat sekuriteitsrelevante kode gebruik word wanneer dit nodig is en bestand is teen gepeuter.

Beheer 8.28 lys ook die volgende aanbevelings vir sekuriteitsrelevante kode:

• Terwyl programme wat via binêre kode geïnstalleer is, sekuriteitsrelevante kode insluit, is dit beperk tot die data wat in die toepassing self gestoor word.
• Konsep van sekuriteitsrelevante kode is slegs nuttig wanneer kode op 'n bediener uitgevoer word wat nie vir die gebruiker toeganklik is nie en dit geskei is van die prosesse wat dit gebruik en die data daarvan veilig in 'n ander databasis gehou word. U kan byvoorbeeld 'n geïnterpreteerde kode op 'n wolkdiens laat loop en toegang tot kode kan beperk word tot bevoorregte administrateurs. Dit word aanbeveel dat jy hierdie toegangsregte beskerm deur middel van metodes soos net-betyds administrateur voorregte en robuuste stawingmeganismes.
• Toepaslike konfigurasies op webbedieners moet geïmplementeer word om ongemagtigde toegang tot en blaai deur die gids te voorkom.
• Wanneer u toepassingskode ontwerp, moet u begin met die aanname dat die kode kwesbaar is vir aanvalle as gevolg van koderingsfoute en optrede deur kwaadwillige akteurs. Jy moet kritieke toepassings ontwerp op 'n manier dat hulle nie kwesbaar is vir interne foute nie. Die uitset wat deur 'n algoritme geproduseer word, kan byvoorbeeld hersien word om te verseker dat dit aan sekuriteitsvereistes voldoen voordat dit in kritieke toepassings soos finansiesverwante toepassings gebruik kan word.
• Sekere webtoepassings is hoogs kwesbaar vir sekuriteitsbedreigings as gevolg van swak koderingspraktyke soos databasisinspuiting en kruis-werf script-aanvalle.
• Organisasies moet na ISO/IEC 15408-reeks verwys vir meer inligting oor IT-sekuriteitsevaluering.

Veranderinge en verskille vanaf ISO 27002:2013

27002:2022/8.28 is 'n nuwe tipe beheer.

Hoe ISMS.online help

Ons platform is spesifiek ontwikkel vir diegene wat nuut is in inligtingsekuriteit of 'n maklike manier nodig het om oor ISO 27002 te leer sonder om tyd te spandeer om van nuuts af te leer of deur lang dokumente te lees.

ISMS.Online is toegerus met al die gereedskap wat nodig is om voldoening te bereik, insluitend dokumentsjablone, kontrolelyste en beleide wat volgens jou behoeftes aangepas kan word.

Wil u sien hoe dit werk?

Kontak vandag nog om bespreek 'n demo.