Po długiej i zagmatwanej procedurze rejestracyjnej kilka dni temu otrzymaliśmy informację, że Sąd Rejonowy dla M.St. Warszawa dokonał rejestracji Stowarzyszenia CSA Polska.

Stowarzyszenie będące polskim przedstawicielem Cloud Security Alliance ma na celu krzewienie wiedzy oraz promowanie najlepszych standardów i praktyk w zakresie bezpieczeństwa przetwarzania danych w modelu „cloud computing”.
Mamy nadzieję, że odegra ono znaczną rolę nie tylko w promowaniu bezpiecznych sposobów zarządzania tym zagadnieniem, ale również w twórczy sposób będzie wpływało na kształtowanie nowych, rozwijających się międzynarodowych standardów w tym zakresie.


Pierwszy Zarząd ukonstytuował się w składzie:

  • Marcin Fronczak – Przewodniczący
  • Adam Haertle – Skarbnik
  • Krystian Szybis – Sekretarz
  • Patryk Gęborys – Wiceprzewodniczący
  • Jakub Syta – Wiceprzewodniczący

Do Komisji Rewizyjnej Komitet Założycielski wybrał następujące osoby:

  • Radosław Kaczorek
  • Bolesław Szomański
  • Wojciech Szyksznia


Więcej o stowarzyszeniu i jego działalności można przeczytać na stronie http://www.cloudsecurityalliance.pl/
.
KNF ogłosił ostatnio publiczne konsultacje dla rekomendacji D.


Jest to ważna informacja dla wszystkich bezpieczników z bankowości. Szczególnie ważna, gdyż wygląda na to, że będzie zawierać sporo zmian. Kilka przykładowych, które szczególnie zwróciły mają uwagę to:

1.1 podkreślająca rolę rady nadzorczej w nadzorowaniu IT
4.3 podkreślająca współpracę IT i biznesu
5.2 wprowadzający separację obowiązków
– funkcji tworzenia lub modyfikowania systemów informatycznych od ich testowania, administracji i użytkowania,
– funkcji administrowania środowiskiem teleinformatycznym od zarządzania jego bezpieczeństwem,
– funkcji administrowania sieciami teleinformatycznymi, bazami danych oraz systemami informatycznymi,
– funkcji audytu od pozostałych funkcji w obszarze technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego.
5.4 podkreślająca kto tak naprawdę jest odpowiedzialny za bezpieczeństwo informacji
5.9 wymagający aktualnej i precyzyjnej dokumentacji środowiska teleinformatycznego
7.11 podkreślający zasady zarządzania zmianą (w tym zmiany pilne i awaryjne)
9.5 wprowadzający odseparowane podsieci
9.8 zezwalający na sieć bezprzewodową w bankach
9.18 wymagający szyfrowania i uwierzytelniania podczas wykorzystywania drukarek sieciowych (choć tu  mam wątpliwości czy nie powinno to bazować na analizie ryzyka. Nie każda drukarka sieciowa (moim zdaniem)musi oferować uwierzytelniania. A koszty wymiany są spore
10.6 de facto zezwalająca na przetwarzanie danych w modelu cloud computing
11.5 wymagający narzędzi automatyzujących zarządzanie uprawnieniami (w tym historycznymi
12.4 i 14 wymagający uświadamiania użytkowników w zakresie bezpieczeństwa
17.1 zarządzanie oprogramowaniem końcowych użytkowników
18.3 podkreślenie przydatności norm serii ISO 27000
18.4 podkreślenie konieczności integracji zarządzania bezpieczeństwem z narzędziami zarządzania ryzykiem operacyjnym
18.5 i 18.10 i 18.12 podkreślenie konieczności zarządzania ryzykiem w zakresie bezpieczeństwa środowiska teleinformatycznego
18.9 podkreślającego przydatność wymiany informacji o zagrożeniach oraz doświadczeń wynikających z analizy naruszeń bezpieczeństwa
20.7 sugerujący potrzebę wdrażania SIEM
22.4 sugerujący potrzebę korzystania z zewnętrznych usług audytu



Jak widzicie za jakiś czas naprawdę będzie ciekawie.
.
W trakcie wielu projektów obserwowałem specyficzny rozdział dotyczący pojmowania różnych aspektów bezpieczeństwa: poufności, integralności i dostępności (że skoncentruję się na tych podstawowych). Potężna część osób – studentów czy klientów przede wszystkim utożsamia bezpieczeństwo z poufnością. Coś jest bezpieczne jeżeli inni tego nie znają – tak można podsumować definicję bezpieczeństwa w ich wykonaniu. Przy lekkim naprowadzeniu dość szybko udaje nam się podkreślić aspekt dostępności. Jednak osoby, które dopiero zaczynają zajmować się bezpieczeństwem często nie są w stanie podkreślić istotności „integralności” dla ich pracy czy zadań wykonywanych przez ich pracodawców.

Wczorajsze zamieszanie z Play jest świetnym przykładem na to, że integralność danych potrafi stać się niezmiernie istotną kwestią nie tylko dla IT, ale również dla przedstawicieli działów biznesowych. Nie chcę kopać leżącego (zarówno w tej kwestii jak i komunikacji kryzysowej) – inni już to zrobili, więc tylko dodam parę wniosków. Tak często niedoceniana integralność danych może spowodować wielkie straty wizerunkowe. Może też doprowadzić do bardzo poważnych problemów prawnych, gdyż zdziwiłbym się gdyby Play nie został przez przynajmniej niektórych z klientów pozwany za naruszenie tajemnicy korespondencji – MMS w końcu do takich należy. Nie jest przypadkiem, że awaria miała miejsce w niedzielę – soboty to w końcu bardzo popularny dzień na wdrażanie wszelkiego rodzaju poprawek. Niemniej dobrze przygotowana poprawka po pierwsze jest odpowiednio przetestowana na środowiskach testowych, po drugie jest odpowiednio zweryfikowana po wdrożeniu jej na środowisko testowe a po trzecie zawiera przygotowany plan czynności na wypadek niepowodzenia.

W tym przypadku nie zadziałały wszystkie z tych elementów poddając w zapytanie jakość procesu zarządzania zmianą oraz jego integrację z procesem zarządzania incydentami i dalej zarządzania kryzysowego. Play powinien teraz wyciągnąć wnioski i dokonać szybkich zmian by podkreślić swoją wiodącą rolę wśród polskich telekomów.
.
Bruce Schneier wygrzebał, ja powielę...
przecież to takie prawdziwe
.