Kolejne spotkanie (19 maja 2009, 18:00) - Cyber-przestępczość
8 views
Skip to first unread message
Michał Sobiegraj
May 9, 2009, 11:45:48 AM5/9/09
to ISSA Polska Wrocław
Witajcie!
Zapraszam na kolejne spotkanie ISSA. Tym razem tematem będzie cyber-
przestępczość. Borys Łącki opowie ile kosztują usługi cyberprzestępców
i będziemy mieli okazję podyskutować na temat doświadczeń z
przestępczością elektroniczną.
Wystąpienie Borysa będzie nagrane i opublikowane w sieci.
Termin: 18 maja, godzina 18:00
Miejsce: Credit Suisse, Pl. Grunwaldzki 25, Budynek C (V piętro)
Agenda:
1. Wprowadzenie, Michał Sobiegraj (ISSA)
2. Cyberprzestępcy jutra - ile kosztują, Borys Łącki
3. Dyskusja nt. prelekcji
Rejestracja:
Ze względów organizacyjnych wymagane jest zgłoszenie chęci udziału w
spotkaniu najpóźniej do 18 maja do godziny 15.00. Można to zrobić
wysyłając na adres wroclaw at issa.org.pl wiadomość o temacie "[ISSA]
Potwierdzenie udziału w spotkaniu - Wrocław, 19 maja 2009"
Zapraszamy, wstęp na spotkanie jest bezpłatny dla wszystkich chętnych!
Zapraszam na kolejne spotkanie ISSA. Tym razem tematem będzie cyber-
przestępczość. Borys Łącki opowie ile kosztują usługi cyberprzestępców
i będziemy mieli okazję podyskutować na temat doświadczeń z
przestępczością elektroniczną.
Wystąpienie Borysa będzie nagrane i opublikowane w sieci.
Termin: 18 maja, godzina 18:00
Miejsce: Credit Suisse, Pl. Grunwaldzki 25, Budynek C (V piętro)
Agenda:
1. Wprowadzenie, Michał Sobiegraj (ISSA)
2. Cyberprzestępcy jutra - ile kosztują, Borys Łącki
3. Dyskusja nt. prelekcji
Rejestracja:
Ze względów organizacyjnych wymagane jest zgłoszenie chęci udziału w
spotkaniu najpóźniej do 18 maja do godziny 15.00. Można to zrobić
wysyłając na adres wroclaw at issa.org.pl wiadomość o temacie "[ISSA]
Potwierdzenie udziału w spotkaniu - Wrocław, 19 maja 2009"
Zapraszamy, wstęp na spotkanie jest bezpłatny dla wszystkich chętnych!
Michał Sobiegraj
May 9, 2009, 4:13:54 PM5/9/09
to ISSA Polska Wrocław
Oczywiście spotkanie jest 19 maja, tak jak napisałem w temacie. Nie
mam zielonego pojęcia skąd wzięła się inna data w treści ;-)
On 9 Maj, 17:45, Michał Sobiegraj <msobieg...@gmail.com> wrote:
> Witajcie!
>
> Zapraszam na kolejne spotkanie ISSA. Tym razem tematem będzie cyber-
> przestępczość. Borys Łącki opowie ile kosztują usługi cyberprzestępców
> i będziemy mieli okazję podyskutować na temat doświadczeń z
> przestępczością elektroniczną.
>
> Wystąpienie Borysa będzie nagrane i opublikowane w sieci.
>
> Termin: 19 maja, godzina 18:00
mam zielonego pojęcia skąd wzięła się inna data w treści ;-)
On 9 Maj, 17:45, Michał Sobiegraj <msobieg...@gmail.com> wrote:
> Witajcie!
>
> Zapraszam na kolejne spotkanie ISSA. Tym razem tematem będzie cyber-
> przestępczość. Borys Łącki opowie ile kosztują usługi cyberprzestępców
> i będziemy mieli okazję podyskutować na temat doświadczeń z
> przestępczością elektroniczną.
>
> Wystąpienie Borysa będzie nagrane i opublikowane w sieci.
>
Michał Sobiegraj
May 14, 2009, 3:59:52 PM5/14/09
to ISSA Polska Wrocław
Moi drodzy, spieszę donieść o zmianie miejsca majowego spotkania na:
Credit Suisse, Kameleon, Szewska 6/7 (windą na I piętro)
Godzina i data oczywiście bez zmian.
Pozdrawiam i do zobaczenia,
Michał
Credit Suisse, Kameleon, Szewska 6/7 (windą na I piętro)
Godzina i data oczywiście bez zmian.
Pozdrawiam i do zobaczenia,
Michał
Andrzej Niemiec
May 18, 2009, 11:36:57 AM5/18/09
to issa-pols...@googlegroups.com
Witam
Jakie zapisy sa wymagane w ISO IEC 27001? Ja
zidentyfikowałem nastepujace:
4.3.1 Dokumentacja powinna zawierać zapisy
decyzji kierownictwa, zapewnić że działania są zgodne z decyzjami
kierownictwa i politykami oraz zapewnić, że zapisy rezultatów działań są
odtwarzalne.
4.3.3 Zapisy powinny dotyczyć realizacji procesów, zgodnie z opisem zawartym w 4.2 oraz wszystkich incydentów związanych z bezpieczeństwem związanych z SZBI. (Przykładami zapisów są księgi gości, raporty audytowe i wypełnione formularze autoryzacji dostępu)
5.2.2 … prowadzenie zapisów dotyczących edukacji, szkolenia, umiejętności, doświadczenia i kwalifikacji
6 Audyty wewnętrzne Wymagania i odpowiedzialność za planowanie i przeprowadzanie audytów oraz za raportowanie wyników i utrzymywanie zapisów powinny być zdefiniowane w udokumentowanej procedurze.
7 Przeglądy ISMS realizowane przez kierownictwo
Wyniki przeglądów powinny być jasno udokumentowane, a odpowiednie zapisy powinny być przechowywane
8.2 Działania korygujące …. e) prowadzenia zapisów rezultatów podjętych działań
8.3 Działania zapobiegawcze ...d) zapisu wyników podjętych działań
A5.1.1 Dokument polityki BI
A 5.1.2 Przegląd polityki BI
A 6.1.3 Przypisanie odpowiedzialności
A 7.1.1 Inwentaryzcja aktywów
A 8 – zapisy ze szkoleń + plany szkolen
A9 – księga wydań kluczy, ksiega gości (zapisy może zastapić monitorowanie),
A9.1.5 księga wejść do pomieszczenia serwerów (kto, kiedy i po co)
A10.7.2 zapisy z niszczenia nośników (ale chyba się z tego można wybronić)
A 10.10.4 Działania administratorów i operatorów systemów powinny być rejestrowane.
A 10.10.5 Błędy należy rejestrować i analizować
A 11.2.1 Rejestracja użytkowników
A 13.2.3. Gromadzenie materiału dowodowego
4.3.3 Zapisy powinny dotyczyć realizacji procesów, zgodnie z opisem zawartym w 4.2 oraz wszystkich incydentów związanych z bezpieczeństwem związanych z SZBI. (Przykładami zapisów są księgi gości, raporty audytowe i wypełnione formularze autoryzacji dostępu)
5.2.2 … prowadzenie zapisów dotyczących edukacji, szkolenia, umiejętności, doświadczenia i kwalifikacji
6 Audyty wewnętrzne Wymagania i odpowiedzialność za planowanie i przeprowadzanie audytów oraz za raportowanie wyników i utrzymywanie zapisów powinny być zdefiniowane w udokumentowanej procedurze.
7 Przeglądy ISMS realizowane przez kierownictwo
Wyniki przeglądów powinny być jasno udokumentowane, a odpowiednie zapisy powinny być przechowywane
8.2 Działania korygujące …. e) prowadzenia zapisów rezultatów podjętych działań
8.3 Działania zapobiegawcze ...d) zapisu wyników podjętych działań
A5.1.1 Dokument polityki BI
A 5.1.2 Przegląd polityki BI
A 6.1.3 Przypisanie odpowiedzialności
A 7.1.1 Inwentaryzcja aktywów
A 8 – zapisy ze szkoleń + plany szkolen
A9 – księga wydań kluczy, ksiega gości (zapisy może zastapić monitorowanie),
A9.1.5 księga wejść do pomieszczenia serwerów (kto, kiedy i po co)
A10.7.2 zapisy z niszczenia nośników (ale chyba się z tego można wybronić)
A 10.10.4 Działania administratorów i operatorów systemów powinny być rejestrowane.
A 10.10.5 Błędy należy rejestrować i analizować
A 11.2.1 Rejestracja użytkowników
A 13.2.3. Gromadzenie materiału dowodowego
Czy sa jeszcze jakies inne ?
Best Regards
Andrzej Niemiec :-)
Andrzej Niemiec :-)
Bartosz Nowak
May 18, 2009, 4:35:54 PM5/18/09
to issa-pols...@googlegroups.com
Cześć,
dodatkowo rzeczy, których nie ująłeś (albo mi umknęły) to to, iż :
- należy zdefiniować zakres systemu - to raczej w dokumentacji
systemowej, ale pewnie dałoby się i poprzez zapis (np. oficjalna notatka
z posiedzenia zarządu). Oczywiście nie jest to wtedy "ładne" ;)
- zapisy z procesu ustanowienia, wdrożenia, monitorowania i przeglądów
SZBI oraz utrzymywania są niezbędne ale to w sumie przytoczyłeś cytując
4.3.3, gdzie pisze że procesy z pkt 4.2 muszą być okraszone zapisami,
Jednak kluczowe moim zdaniem jest zdanie z punktu 4.3.3, które pominąłeś:
"W celu dostarczenia świadectwa potwierdzającego zgodność z wymaganiami
oraz skutecznej eksploatacji
SZBI powinny być ustanowione i utrzymywane odpowiednie zapisy".
A co to jest zapis? Jest to informacja i jej nośnik, w którym
przedstawiono uzyskane wyniki lub dowody przeprowadzonych działań.
Więc skoro mamy jakieś zabezpieczenie to często jedynie zapis może
dowieźć audytorowi jego wdrożenie, skuteczność itp. Więc poza zapisami
wymaganymi wprost z 27001 będziemy też potrzebować wiele dodatkowych
zapisów odnoszących się np. do naszych zabezpieczeń (załącznik A)
Dla przykładu w organizacji wyszło, że musimy robić przegląd uprawnień w
systemie X. Jeśli mamy tylko system X i jest tam 5 użytkowników to może
i przejdzie jak nie będzie z przeglądu zapisów bo w każdej chwili admin
otwiera panel z uprawnieniami i widzi bo wszystkich zna i wie do czego
mają prawo. I audytor rzeczywiście może stwierdzić, że takie
zabezpieczenie w tym wypadku jest adekwatne jeśli jeszcze Pan dyrektor
potwierdzi zakładaną cykliczność tych przeglądów.
Jednak jak mamy 100 aplikacji i 1000 użytkowników to nawet jak nasza
procedura mówi, że nie trzeba prowadzić zapisów z przeglądu uprawnień to
audytor ma prawo podważyć skuteczność tego zabezpieczenia. Jak mu
udowodnimy, że dostęp mają tylko uprawnieni? Jak mu udowodnimy, że
panujemy nad rotacją i wykonujemy regularne przeglądy? Tylko tak jak
pokażemy zapisy, że do admina przychodzi lista pracowników, admin
weryfikuje i sporządza jakiś raport wynikowy dla dyrektorów oni to
akceptują itp. itd. Bo zapis jak wspomniałem to dowód z przeprowadzonych
działań. Audytor bez zapisów potwierdzających działanie naszego
mechanizmu kontroli uprawnień może podważyć jego skuteczność...
Tak samo ze wspomnianymi potem nośnikami i ich niszczeniem. Admin może
pokazać wielkie ognisko i powiedzieć, że on tu raz na jakiś czas pali
płyty. I o ile analiza ryzyka nam mówi, że to wystarczające to zapisów
nie potrzebujemy. Jednak często to nam nie wystarcza. Chcemy protokołu
zdania, potwierdzenie zniszczenia, czasem nawet nagranie wideo - czyli
zapisy.
To ognisko to przykład z życia wzięty ;)
Może przykład hardcorowy ale miał nieść przekaz taki - zabezpieczenia,
ich rodzaj i ich zakres powinien nam wyjść z szacowania ryzyka. Po
szacowaniu definiujemy ADEKWATNE i skuteczne zabezpieczenia. Wdrażamy
je. I potem w zależności od zabezpieczenia będzie ono wymagać zapisów z
jego funkcjonowania, bądź nie. I tą potrzebę powinniśmy sami sobie
zdefiniować w odpowiednich procedurach. Żeby było wszystko adekwatne i
skuteczne... dwa ulubione chyba słowa normy jeśli chodzi o zabezpieczenia.
Więc lista punktów z załącznika A jaką przedstawiłeś poniżej na pewno
nie jest kompletna i na pewno nie jest tak wprost definiowalna jeśli
chodzi o wymóg zapisów.
Reszta uwag w tekście poniżej.
Mam nadzieje, że zmęczenie nie spowodowało że zagmatwałem strasznie
odpowiedź :) no i oczywiście, że jest ona przydatna.
pzdr,
Bartosz Nowak
Andrzej Niemiec pisze:
> bezpieczeństwem związanych z SZBI. (/Przykładami zapisów są księgi
> gości, raporty audytowe i wypełnione formularze autoryzacji dostępu/)
> 5.2.2 … prowadzenie* zapisów dotyczących edukacji, szkolenia,
> umiejętności, doświadczenia i kwalifikacji*
> zapisów *powinny być zdefiniowane w udokumentowanej procedurze.
> zapisy powinny być przechowywane*
>
>
> 8.2 Działania korygujące …. e) prowadzenia *zapisów rezultatów
> podjętych działań
> *
> 8.3 Działania zapobiegawcze ...d) zapisu *wyników podjętych działań
> *
> A5.1.1 Dokument polityki BI
To jest dokument, nie zapis.
dowodem na przeprowadzenie działań. Jeśli brak dowodu to audytor może
sformułować spostrzeżenie audytowe na brak dowodów
wdrożenia/funkcjonowania zabezpieczenia.
zapisy z niszczenia nośników. Tutaj ma raczej zastosowanie bronienie się
poprzez przedstawienie zapisów z procesu szacowania ryzyka, o których
pisałem wcześniej. Ta uwaga tyczy się całego aneksu A - wszystko
wdrażasz jeśli wskazuje na to szacowanie ryzyka, jeśli z tej wynika, że
jakieś zabezpieczenie jest nieadekwatne to nie wdrażasz - załącznik A
nie jest przymusem, lecz ten proces wyboru zabezpieczeń poprzez
szacowanie ryzyka musi być udowodniony (np. zapisami:) O tym też pisałem
powyżej.
dodatkowo rzeczy, których nie ująłeś (albo mi umknęły) to to, iż :
- należy zdefiniować zakres systemu - to raczej w dokumentacji
systemowej, ale pewnie dałoby się i poprzez zapis (np. oficjalna notatka
z posiedzenia zarządu). Oczywiście nie jest to wtedy "ładne" ;)
- zapisy z procesu ustanowienia, wdrożenia, monitorowania i przeglądów
SZBI oraz utrzymywania są niezbędne ale to w sumie przytoczyłeś cytując
4.3.3, gdzie pisze że procesy z pkt 4.2 muszą być okraszone zapisami,
Jednak kluczowe moim zdaniem jest zdanie z punktu 4.3.3, które pominąłeś:
"W celu dostarczenia świadectwa potwierdzającego zgodność z wymaganiami
oraz skutecznej eksploatacji
SZBI powinny być ustanowione i utrzymywane odpowiednie zapisy".
A co to jest zapis? Jest to informacja i jej nośnik, w którym
przedstawiono uzyskane wyniki lub dowody przeprowadzonych działań.
Więc skoro mamy jakieś zabezpieczenie to często jedynie zapis może
dowieźć audytorowi jego wdrożenie, skuteczność itp. Więc poza zapisami
wymaganymi wprost z 27001 będziemy też potrzebować wiele dodatkowych
zapisów odnoszących się np. do naszych zabezpieczeń (załącznik A)
Dla przykładu w organizacji wyszło, że musimy robić przegląd uprawnień w
systemie X. Jeśli mamy tylko system X i jest tam 5 użytkowników to może
i przejdzie jak nie będzie z przeglądu zapisów bo w każdej chwili admin
otwiera panel z uprawnieniami i widzi bo wszystkich zna i wie do czego
mają prawo. I audytor rzeczywiście może stwierdzić, że takie
zabezpieczenie w tym wypadku jest adekwatne jeśli jeszcze Pan dyrektor
potwierdzi zakładaną cykliczność tych przeglądów.
Jednak jak mamy 100 aplikacji i 1000 użytkowników to nawet jak nasza
procedura mówi, że nie trzeba prowadzić zapisów z przeglądu uprawnień to
audytor ma prawo podważyć skuteczność tego zabezpieczenia. Jak mu
udowodnimy, że dostęp mają tylko uprawnieni? Jak mu udowodnimy, że
panujemy nad rotacją i wykonujemy regularne przeglądy? Tylko tak jak
pokażemy zapisy, że do admina przychodzi lista pracowników, admin
weryfikuje i sporządza jakiś raport wynikowy dla dyrektorów oni to
akceptują itp. itd. Bo zapis jak wspomniałem to dowód z przeprowadzonych
działań. Audytor bez zapisów potwierdzających działanie naszego
mechanizmu kontroli uprawnień może podważyć jego skuteczność...
Tak samo ze wspomnianymi potem nośnikami i ich niszczeniem. Admin może
pokazać wielkie ognisko i powiedzieć, że on tu raz na jakiś czas pali
płyty. I o ile analiza ryzyka nam mówi, że to wystarczające to zapisów
nie potrzebujemy. Jednak często to nam nie wystarcza. Chcemy protokołu
zdania, potwierdzenie zniszczenia, czasem nawet nagranie wideo - czyli
zapisy.
To ognisko to przykład z życia wzięty ;)
Może przykład hardcorowy ale miał nieść przekaz taki - zabezpieczenia,
ich rodzaj i ich zakres powinien nam wyjść z szacowania ryzyka. Po
szacowaniu definiujemy ADEKWATNE i skuteczne zabezpieczenia. Wdrażamy
je. I potem w zależności od zabezpieczenia będzie ono wymagać zapisów z
jego funkcjonowania, bądź nie. I tą potrzebę powinniśmy sami sobie
zdefiniować w odpowiednich procedurach. Żeby było wszystko adekwatne i
skuteczne... dwa ulubione chyba słowa normy jeśli chodzi o zabezpieczenia.
Więc lista punktów z załącznika A jaką przedstawiłeś poniżej na pewno
nie jest kompletna i na pewno nie jest tak wprost definiowalna jeśli
chodzi o wymóg zapisów.
Reszta uwag w tekście poniżej.
Mam nadzieje, że zmęczenie nie spowodowało że zagmatwałem strasznie
odpowiedź :) no i oczywiście, że jest ona przydatna.
pzdr,
Bartosz Nowak
Andrzej Niemiec pisze:
> Witam
> Jakie zapisy sa wymagane w ISO IEC 27001? Ja zidentyfikowałem nastepujace:
> 4.3.1 Dokumentacja powinna zawierać *zapisy decyzji kierownictwa*,
> Jakie zapisy sa wymagane w ISO IEC 27001? Ja zidentyfikowałem nastepujace:
> zapewnić że działania są zgodne z decyzjami kierownictwa i politykami
> oraz zapewnić, że zapisy rezultatów działań są odtwarzalne.
> 4.3.3 Zapisy powinny dotyczyć realizacji procesów, zgodnie z opisem
> zawartym w 4.2 oraz *wszystkich incydentów* związanych z
> oraz zapewnić, że zapisy rezultatów działań są odtwarzalne.
> 4.3.3 Zapisy powinny dotyczyć realizacji procesów, zgodnie z opisem
> bezpieczeństwem związanych z SZBI. (/Przykładami zapisów są księgi
> gości, raporty audytowe i wypełnione formularze autoryzacji dostępu/)
> 5.2.2 … prowadzenie* zapisów dotyczących edukacji, szkolenia,
> umiejętności, doświadczenia i kwalifikacji*
> 6 Audyty wewnętrzne Wymagania i odpowiedzialność za planowanie i
> przeprowadzanie audytów oraz za raportowanie wyników i *utrzymywanie
> zapisów *powinny być zdefiniowane w udokumentowanej procedurze.
>
>
> 7 Przeglądy ISMS realizowane przez kierownictwo
> Wyniki przeglądów powinny być jasno udokumentowane, a *odpowiednie
>
> 7 Przeglądy ISMS realizowane przez kierownictwo
> zapisy powinny być przechowywane*
>
>
> 8.2 Działania korygujące …. e) prowadzenia *zapisów rezultatów
> podjętych działań
> *
> 8.3 Działania zapobiegawcze ...d) zapisu *wyników podjętych działań
> *
> A5.1.1 Dokument polityki BI
To jest dokument, nie zapis.
> A 5.1.2 Przegląd polityki BI
> A 6.1.3 Przypisanie odpowiedzialności
> A 7.1.1 Inwentaryzcja aktywów
> A 8 – zapisy ze szkoleń + plany szkolen
> A9 – księga wydań kluczy, ksiega gości (zapisy może zastapić
> monitorowanie),
Ale z tego monitorowania też muszą być zapisy. Pamiętajmy, że zapis jest
> A 6.1.3 Przypisanie odpowiedzialności
> A 7.1.1 Inwentaryzcja aktywów
> A 8 – zapisy ze szkoleń + plany szkolen
> A9 – księga wydań kluczy, ksiega gości (zapisy może zastapić
> monitorowanie),
dowodem na przeprowadzenie działań. Jeśli brak dowodu to audytor może
sformułować spostrzeżenie audytowe na brak dowodów
wdrożenia/funkcjonowania zabezpieczenia.
> A9.1.5 księga wejść do pomieszczenia serwerów (kto, kiedy i po co)
> A10.7.2 zapisy z niszczenia nośników (ale chyba się z tego można wybronić)
Nie do końca. 10.7.1 i 10.7.2 mówią, że o ile możliwe należy prowadzić
> A10.7.2 zapisy z niszczenia nośników (ale chyba się z tego można wybronić)
zapisy z niszczenia nośników. Tutaj ma raczej zastosowanie bronienie się
poprzez przedstawienie zapisów z procesu szacowania ryzyka, o których
pisałem wcześniej. Ta uwaga tyczy się całego aneksu A - wszystko
wdrażasz jeśli wskazuje na to szacowanie ryzyka, jeśli z tej wynika, że
jakieś zabezpieczenie jest nieadekwatne to nie wdrażasz - załącznik A
nie jest przymusem, lecz ten proces wyboru zabezpieczeń poprzez
szacowanie ryzyka musi być udowodniony (np. zapisami:) O tym też pisałem
powyżej.
Reply all
Reply to author
Forward
0 new messages