☰

» »

ISO 27001

ISO 27001

Kapitan Jack ::

Koliko od vas je ze delalo aktivno v podjetju na tem projektu? V mojem podjetju to delamo in imam obcutek, da noben v IT-ju ne razume kaj je potrebno narediti. Sefe je naredil neke table, pa zdruzeval iz drugih ze pridobljenih certifikacij, pa vsak teden se spomni, da je potrebno se "en dokument", medtem pa delas operativo itak...

Imam filing, da je zadeva dejansko simpl, ampak ljudje jo komplicirajo do nebes.

Sam ne vem od kje zaceti. Hocejo se dokumenti, ki slisijo na ime topic specific policy, pa potem za ta policy gre SOP, pa potem neki guidlines. Potem pa tam pises in pises in vidis, da vse kar pises je skoraj bs, ker ali ne delas tako ali si sele v procesu, da zacnes tako delati.

Po meni, je treba najprej zadeve implementirati, potem sele zaceti s pisanjem dokumentov.

Kako je pri vas potekal ta projekt? Kdo je bil "taglavni" pri projektu.

videc ::

https://www.iso.org/standard/27001
Vse kar te zanima.

adol2 ::

Podjetje vedno najame zunanjega svetovalca, ki je običajno prijatelj s presojevalci :)

In gre vse skupaj precej lažje...

samotest ::

Cist odvisno od podjetja. Dost je nerazumevanja, da se gre za močno varnost, se pa gre za upravljanje varnosti, nacin kako izbirat kontrole in dolocat kolk globoko se organizaciji 'splaca'. To se mora dolocit prek ocenjevanja tveganj naceloma.

Teli imajo nekaj dobrih smernic for free, https://advisera.com/iso-27001/

Je pa potrebne kr nekaj dokumentacije, je res.

darkolord ::

samotest je izjavil:

Cist odvisno od podjetja. Dost je nerazumevanja, da se gre za močno varnost, se pa gre za upravljanje varnosti, nacin kako izbirat kontrole in dolocat kolk globoko se organizaciji 'splaca'. To se mora dolocit prek ocenjevanja tveganj naceloma.
Ta zadnji del je najpomembnejši, pa se ga v praksi sedaj zelo pogosto izpušča, ker je treba razmišljati in je enostavneje izbrati najstrožje kontrole in implementirati/kupiti rešitev, ki bo to naredila.

Če zazidaš vsa vrata ni treba razmišljati o tem, kdo bo imel ključe od vrat.

Ti pa ta del lahko v resnici prihrani precej dela, ker določena tveganja oceniš kot nizka in se z njimi ni treba več posebej ukvarjati.

Kapitan Jack ::

Ja, tocno to delamo mi @darklord in jaz skoz tezim, da nemores nekaj iz iso prebrati in potem, ce tega nimas, kupiti resitev za katero potrebujes cas, da jo implementiras, ter na koncu tudi kakovostno uporabljas.
Do predkratkim nismo imeli Vulnerability Managementa oziroma procesa. Kupili smo produkt in sedaj vsi admini gledajo kot teleta v vrata. Jaz sem zadevo vzel v svoje roke in pocasi resujem zadeve, ki jih je resitev predlagala. Ampak bossu je pomemben dokument in kolikor mu poskusam dopovedati, da mu ne pomaga dokument, ce zadeve niso implementirane.

Kaj ti pomeni, da reces delamo tako in tako vuln. management in imamo za ta proces, to pa to resitev, potem ti pride asseor in te povprasa po tem, ti pa ja tle imam, in mu pokazes sistem, notri pa 1000 nezakrpanih lukenj.

Jaz razumem, da je to napacen pristop. Nimam pa izkusenj, zato tu sprasujem kaksen je pravi pristop. Pomoje bi bil pravilen pristop, delati na resitvi in dejanski implementaciji in pocasi pisati dokument.

Vice ::

Ta standard je dokaj obsežen in ni omejen samo na "digitalno" varovanje informacij. Žal pa tukaj ni recepta kakšen je točen in pravi pristop ker je vse odvisno od firme do firme. Sam paziti je treba, da se stvari ne zakomplicira preveč. Namreč standard ti ponuja samo smernice ki jih prilagodiš svojim potrebam in načinu dela. Tudi ne rabiš neke zunanje firme za to, ker nobena zunanja firma ne razume vašega načina dela. Namesto tega je boljše, če daste tistih par "100EUR" in imate svojega notranjega presojevalca.

Šmorn ::

Naredite GAP analizo, da ugotovite, česa še nimate, potem pa naprej. Če že imate kak poslovnik, potem lahko uporabite muštr iz tam. Lahko da že imate tehnično ali vsebinsko urejeno, pa še ni dokumentirano. V tem primeru dokumentirajte. Pazite kaj pišete, ker če boste zakomplicirali, boste potem komplicirano izvajali.

darkolord ::

Kapitan Jack je izjavil:

Jaz razumem, da je to napacen pristop. Nimam pa izkusenj, zato tu sprasujem kaksen je pravi pristop. Pomoje bi bil pravilen pristop, delati na resitvi in dejanski implementaciji in pocasi pisati dokument.
Lažje iz druge strani, po korakih:



Sploh SOA je pomemben (dobiš template), tam si lahko prihraniš največ časa, da preskočiš implementacijo stvari, ki pri tebi ne pridejo v poštev oz. nimajo smisla. In vidiš tudi, kaj imaš že narejeno.

Presojevalec bo šel po svojem seznamu in delal kljukice. Če rečeš "tega ne rabimo, ker [vnesi smiseln razlog]", je to kljukica.

Če boš šel iz rešitve nazaj in iskal, kaj lahko z njo pokriješ, bo si boš lahko zakompliciral zadeve, ker boš moral pokazati implementacijo, tudi če je v resnici ne rabiš.

fikus_ ::

Tako kot je šmorn napisal, ne zakomplicirat! Ne pretiravat, morate vedeti kaj hočete, narediti oceno in potem iskati rešitve . To je delo za več ljudi, ki dobro poznajo proces.
Dobro bi bilo, da dobite zunanjega človeka za pomoč, gleda vaše sedanje stanje in možne rešitve drugače kot sami.
Učite se iz preteklosti, živite v sedanjosti in razmišljajte o prihodnosti.

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Schleswig-Holstein gre na Linux (strani: 1 2 )

Oddelek: Novice / Operacijski sistemi		727381 (3764) tony1
»

Blockchain za fotografije (strani: 1 2 )

Oddelek: Kriptovalute in blockchain		515804 (4336) SmeskoSnezak
»

ISO 9001 programska oprema

Oddelek: Pomoč in nasveti		162466 (1976) MTB
»

šola In varnost

Oddelek: Informacijska varnost		325363 (4211) poweroff
»

Prihajajo novi spamerji

Oddelek: Novice / Zasebnost		235669 (3664) BlueRunner

Več podobnih tem