Wat is ISO 27002:2022 Beheer 8.28 oor veilige kodering?
Swak koderingspraktyke soos onbehoorlike insetvalidering en swak sleutelgenerering kan inligtingstelsels blootstel aan sekuriteitskwesbaarhede en tot kuberaanvalle en die kompromie van sensitiewe inligtingbates lei.
Byvoorbeeld, in die berugte Heartbleed gogga voorval, het kuberkrakers onbehoorlike invoervalidering in die kode uitgebuit om toegang tot meer as te kry 4 miljoen pasiënte se data.
Daarom moet organisasies verseker dat veilige koderingbeginsels gevolg word sodat swak koderingspraktyke nie tot sekuriteitskwesbaarhede lei nie.
Doel van beheer 8.28
Beheer 8.28 stel organisasies in staat om sekuriteitsrisiko's en kwesbaarhede wat kan ontstaan as gevolg van swak sagteware-koderingspraktyke te voorkom deur toepaslike veilige sagteware-koderingbeginsels te ontwerp, te implementeer en te hersien.
Eienskappe Tabel van beheer 8.28
Beheer 8.28 is 'n voorkomende tipe beheer wat organisasies help om die sekuriteit van netwerke, stelsels en toepassings te handhaaf deur risiko's uit te skakel wat mag ontstaan uit swak ontwerpte sagtewarekode.
| beheer Tipe | Eienskappe vir inligtingsekuriteit | Kuberveiligheidskonsepte | Operasionele vermoëns | Sekuriteitsdomeine |
|---|---|---|---|---|
| #Voorkomende | #Vertroulikheid | #Beskerm | #Toepassingsekuriteit | #Beskerming |
| #Integriteit | #Stelsel- en netwerksekuriteit | |||
| #Beskikbaarheid |
Kry 'n voorsprong van 81%.
Ons het die harde werk vir jou gedoen, wat jou 'n voorsprong van 81% gee vanaf die oomblik dat jy aanmeld.
Al wat jy hoef te doen is om die spasies in te vul.
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.
Nakoming hoef nie ingewikkeld te wees nie.
Ons het die harde werk vir jou gedoen, wat jou 'n voorsprong van 81% gee vanaf die oomblik dat jy aanmeld.
Al wat jy hoef te doen is om die spasies in te vul.
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.
Bestuur al jou nakoming op een plek
ISMS.online ondersteun meer as 100 standaarde
en regulasies, gee jou 'n enkele
platform vir al jou voldoeningsbehoeftes.
Veranderinge en verskille vanaf ISO 27002:2013
27002:2022/8.28 is 'n nuwe tipe beheer.
Nuwe ISO 27002-kontroles
Nuwe kontroles
| ISO/IEC 27002:2022 Beheeridentifiseerder | ISO/IEC 27002:2013 Beheeridentifiseerder | Beheer naam |
|---|---|---|
| 5.7 | Nuut | Bedreigingsintelligensie |
| 5.23 | Nuut | Inligtingsekuriteit vir die gebruik van wolkdienste |
| 5.30 | Nuut | IKT-gereedheid vir besigheidskontinuïteit |
| 7.4 | Nuut | Fisiese sekuriteitsmonitering |
| 8.9 | Nuut | Konfigurasiebestuur |
| 8.10 | Nuut | Inligting verwydering |
| 8.11 | Nuut | Datamaskering |
| 8.12 | Nuut | Voorkoming van datalekkasies |
| 8.16 | Nuut | Moniteringsaktiwiteite |
| 8.23 | Nuut | Webfiltrering |
| 8.28 | Nuut | Veilige kodering |
Organisatoriese kontroles
Mense beheer
| ISO/IEC 27002:2022 Beheeridentifiseerder | ISO/IEC 27002:2013 Beheeridentifiseerder | Beheer naam |
|---|---|---|
| 6.1 | 07.1.1 | Screening |
| 6.2 | 07.1.2 | Terme en diensvoorwaardes |
| 6.3 | 07.2.2 | Bewustheid, onderwys en opleiding van inligtingsekuriteit |
| 6.4 | 07.2.3 | Dissiplinêre proses |
| 6.5 | 07.3.1 | Verantwoordelikhede na beëindiging of verandering van diens |
| 6.6 | 13.2.4 | Vertroulikheids- of nie-openbaarmakingsooreenkomste |
| 6.7 | 06.2.2 | Afstand werk |
| 6.8 | 16.1.2, 16.1.3 | Rapportering van inligtingsekuriteitsgebeurtenisse |
Fisiese beheer
| ISO/IEC 27002:2022 Beheeridentifiseerder | ISO/IEC 27002:2013 Beheeridentifiseerder | Beheer naam |
|---|---|---|
| 7.1 | 11.1.1 | Fisiese sekuriteit omtrek |
| 7.2 | 11.1.2, 11.1.6 | Fisiese toegang |
| 7.3 | 11.1.3 | Beveiliging van kantore, kamers en fasiliteite |
| 7.4 | Nuut | Fisiese sekuriteitsmonitering |
| 7.5 | 11.1.4 | Beskerming teen fisiese en omgewingsbedreigings |
| 7.6 | 11.1.5 | Werk in veilige areas |
| 7.7 | 11.2.9 | Duidelike lessenaar en duidelike skerm |
| 7.8 | 11.2.1 | Toerusting plaas en beskerming |
| 7.9 | 11.2.6 | Sekuriteit van bates buite die perseel |
| 7.10 | 08.3.1, 08.3.2, 08.3.3, 11.2.5 | Berging media |
| 7.11 | 11.2.2 | Ondersteunende nutsprogramme |
| 7.12 | 11.2.3 | Bekabeling sekuriteit |
| 7.13 | 11.2.4 | Onderhoud van toerusting |
| 7.14 | 11.2.7 | Veilige wegdoening of hergebruik van toerusting |
Tegnologiese kontroles
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.
Spring na onderwerp
