Wszystko o IT Governance, zarządzaniu, standardach CobiT, ITIL i dobrych praktykach zarządczych w informatyce.

web stats stat24

Zobacz mnie na GoldenLine

poniedziałek, 26 kwietnia 2010

Ostatnie spotkanie w ramach trójmiejskiego SPINa było poświęcone złożonym systemom adaptacyjnym i zwinnym metodykom projektowy. Natomiast w maju, hasłem przewodnim będzie IT governance. Pomijając już atrakcyjność tego tematu, z pewnością możemy też liczyć na ciekawą prezentację i liczne pytania z sali, co głównie stanowi o wartości SPINowych spotkań.

Poniżej wklejam info od organizatora:


Zapraszamy na spotkanie SPIN w Trójmieście poświęcone IT Governance.

Tytuł wystąpienia: "Ład organizacyjny czy kultura informatyczna? - wprowadzenie do IT Governance"
Prelegent: Tadeusz Kifner, DOBIS (www.dobis.pl)
Termin: 12.05 (środa), godzina 18:00
Lokalizacja: Sala 2, Instytut Informatyki, Uniwersytet Gdański, ul. Wita Stwosza 57, Gdańsk
Mapa: bit.ly/dlxqco

Abstrakt:
IT Governance (ład korporacyjny) najczęściej jest rozumiany jako kodeks dobrych praktyk w zarządzaniu IT. Przyjmuje się, że przedsiębiorstwa stosujące zasady IT Governance posiadają przejrzyste i dobrze zarządzane działy informatyki, stosują dobre praktyki w zarządzaniu i tym samym aktywnie wspierają całą organizację w odnoszeniu sukcesów. IT Governance to nie jest tylko sama informatyka, ale także szereg praktyk związanych z zarządzaniem informacją oraz wiele działań nietechnicznych na poziomie strategicznym, np. zarządzanie personelem czy opłacalnością przedsięwzięć. Stosowanie jasnych reguł ładu korporacyjnego buduje zaufanie i pokazuje, że IT nie generuje nadmiernego ryzyka biznesowego, co więcej... daje gwarancję osiągnięcia zamierzeń biznesowych poprzez uzyskiwane korzyści „netto”.


ZAPRASZAMY
Wstęp wolny!
Rezerwujcie czas, nie siedźcie w domu!
Przekażcie zaproszenie Znajomym, w grupie raźniej!

--

Pozdrawiam
Mariusz Janczewski

 

piątek, 09 kwietnia 2010

Wprowadzenie do złożonych systemów adaptacyjnych znajdziecie tutaj.

Bazując na właściwościach CAS opisanych na stronie Wikipedii, przedstawiam poniżej zasady budowania zwinnego ładu korporacyjnego:

Ład się sam wykrystalizuje

Każda organizacja wypracowuje z biegiem czasu i wraz ze zdobywanym doświadczeniem metody działania, które można uznać za wewnętrzne dobre praktyki. Pracownicy mimo, że często nie są przez nikogo kontrolowani, ani broń Boże, przez nikogo przymuszani, sami wychodzą z inicjatywami, które ułatwiają bądź porządkują ich pracę. Robią to, bo w dłuższym okresie im się to po prostu opłaca, czy to w postaci zaoszczędzenia czasu, czy uniknięcia pytań "czepialskiego" audytora. Przykłady z życia wzięte:

  • Zespół projektowy wspólnie uzgadnia szereg żelaznych zasad dotyczących spotkań podsumowujących postępy w pracy, np. nie spóźniamy się, nie omawiamy spraw technicznych, informujemy z wyprzedzeniem o agendzie spotkania, itp. Wszystko po to, by nie przeciągać czasu zarezerwowanego na spotkanie i skupić się na najważniejszych rzeczach oraz niczego istotnego nie pominąć, zostawiając techniczne dysputy i rozwiązywanie problemów na inną okazję w węższym gronie.
  • Programiście wspólnie ustalają sposób nazywania klas, bo zbyt często zdarza się, że nie ciężko się połapać, co miał na myśli autor fragmentu kodu opatrzonego niejasną nazwą. Standard nazewnictwa trafia na tablicę informacyjną i jest prezentowany na spotkaniu całego zespołu.

Jak widać, kluczową sprawą jest zachowanie know-how i jego rozpropagowanie wewnątrz organizacji. Dzięki temu, zaczynając od rzeczy małych tworzy się coraz większa i bardziej skomplikowana struktura, która złoży się na kulturę zarządzania IT.

Koewolucja IT governance

Organizacja IT jest częścią czegoś większego - firmy, otoczenia społecznego, branży. Na zmiany w otoczeniu trzeba zatem reagować zmianami (ciągłym dopasowaniem). Należy o tym pamiętać, by nie tworzyć struktur, które będą krępować IT w przypadku zmiany wymagań otoczenia, czy to biznesowych, czy też regulacyjnych...

Zoptymalizowany na miarę potrzeb

Każda energia przeznaczona na poprawianie systemu adaptacyjnego ponad poziom, który daje systemowi lekką przewagę nad konkurencją, jest energią zmarnowaną. Tak samo i o IT governance można powiedzieć, że nie ma sensu dążyć do najwyższych poziomów dojrzałości organizacji IT, skoro wymagania ładu korporacyjnego są o wiele niższe. Co więcej, każda złotówka wydana na poprawę poziomu dojrzałości ponad poziom wystarczający, będzie zmarnowana.

Wewnętrzna różnorodność

Im części złożonego systemu adaptacyjnego są bardziej zróżnicowane, tym silniejszy cały system. Można by to przełożyć na podejmowanie decyzji w IT, które też jest jednym z zagadnień ładu korporacyjnego. Im więcej zróżnicowanych grup podejmuje decyzje (np. biznes, IT, audyt, security, compliance, zarząd), tym lepsze (bardziej trafne) one będę.

W komunikacji siła

CAS cechują się tym, że połączenia między agentami są ważniejsze od samych agentów. Idąc tym tropem, w IT liczy się przepływ informacji zarządczej i łamanie barier komunikacyjnych (np. organizacyjnych silosów) i budowanie kanałów komunikacji.

Proste zasady

Ławicą ryb kierują 3 proste zasady, dzięki którym ławica nie rozprasza się i zwinnie omija ataki drapieżników i naturalne przeszkody. Jeśli chodzi o IT governance, zasadami, które uchronią IT przed "zboczeniem na niebezpieczne tory", mogą być:

  • cokolwiek robisz, kreuj wartość - czyli wystrzeganie się jałowych projektów (bez względu na stadium ich zaawansowania) i jałowych działań,
  • przy podejmowaniu decyzji, zastanów się nad ich ewentualnym wpływem na ryzyko operacyjne,
  • upewnij się, że nie łamiesz reguł lub przepisów, które organizacja musi przestrzegać.

Iteracyjność

Nie od razu Rzym zbudowano i nie od razu powstanie efektywny IT governance. Kolejne cykle budowy ładu w IT wymagają czasu i cierpliwości... aż ład się sam skrystalizuje.

Kolejne 2 właściwości CAS są trudne do pogodzenia z IT governance. Samo-zarządzalność - tu pojawia się na prawdę trudny orzech do zgryzienia, bo systemy adaptacyjne nie wymagają żadnego planowania, ani mechanizmów zarządczych... Zupełnie przeciwnie jak np. budowa architektury IT, gdzie wskazane jest określenie docelowego (strategicznego) modelu funkcjonowania informatyki w organizacji. Z kolei balansowanie na krawędzi chaosu, nie wchodzi w rachubę, gdy na szali jest być albo nie być organizacji i jej klientów.

Podsumowując, ład korporacyjny można wprowadzać w IT na różne sposoby i trudno znaleźć tutaj złoty środek lub wytrych pasujący do wszystkich organizacji. Na pewno warto wspierać się dobrymi praktykami w tym zakresie, ale czy będzie to tradycyjne "ciężkie" podejście projektowe, lekki agile, albo połączenie tych dwóch pomysłów to już leży w gestii indywidualnej decyzji zainteresowanych.

środa, 31 marca 2010

Natchniony ubiegłotygodniowym spotkaniem SPINa w Trójmieście, które dotyczyło teorii złożonych systemów adaptacyjnych i tzw. zwinnych metodyk zarządzania, zacząłem się zastanawiać nad tym, czy IT governance może być wdrażany w inny, bardziej przystający do rzeczywistości sposób. Zanim jednak przedstawię co mam na myśli, należy się parę słów wprowadzenia odnośnie CAS (ang. complex adaptive systems, czyli w skrócie CAS).

Czy zastanawialiście się kiedyś co powoduje, że mrówki ze sobą współpracują, budując skomplikowane konstrukcje, jakimi są mrowiska? Albo obserwowaliście ławicę ryb, która zachowuje się jak jeden, duży organizm lawirując między rafami i unikając drapieżników? Przecież nikt nimi nie kieruje, a jednak zachowują spójność i razem realizują trudne zadania... Takie pytania postawili sobie matematycy i prawdopodobnie znaleźli na nie odpowiedź w postaci CAS. Cóż więc kryje się pod tym terminem? Otóż CAS to systemy, które cechuje złożoność wielu podobnych do siebie elementów (np. tysiące mrówek). Elementy te, zwane agentami, pozostają ze sobą w ciągłej interakcji i nieprzerwanie dopasowują się do siebie i do otaczającego je otoczenia - stąd ich adaptacyjność. Tym co jest szczególnie interesujące w tej teorii, jest fakt, że w wynikiem prostych elementów i interakcji zachodzących w systemie są bardzo skomplikowane zachowania i struktury (np. mrowisko). Rysunek poniżej w dość przejrzysty sposób przedstawia koncepcję CAS.

Złożony system adaptacyjny

CAS są także podstawą teoretyczną zwinnego (ang. agile) zarządzania projektami informatycznymi. Zwinne programowanie bazuje m.in. na prostocie, dobrej komunikacji (interakcji), samozarządzalności zasobów, regularnej adaptacji do zmieniających się wymagań. Brzmi znajomo, prawda? Do tego dochodzi szereg równie prostych reguł, które kierują każdym CAS. Np. każda ryba w ławicy jest "zaprogramowana" aby nie zderzać się z innymi rybami, podążać w tym samym kierunku co inne ryby i zachowywać w miarę stałą odległość od nich (nie być zbyt blisko i nie za daleko). Z kolei agile zakłada to, że funkcjonalność jest podstawową miarą postępu, iteracyjność dostarczania produktu i szybkość z jaką produkt jest budowany, jako podstawową miarę satysfakcji klienta. Pomijając szczegóły wynikające z charakteru założeń i końcowego produktu (unikająca zagrożeń ławica i oprogramowanie), to nie ma właściwie różnicy w obu opisanych przykładach.

Mrowisko

Przechodząc do sedna, czyli do IT governance, po pierwsze pojawia się pytanie - jeśli system (w tym przypadku dział IT) sam się kontroluje i doprowadza do wytworzenia względnego ładu, to czy warto jest się czymkolwiek przejmować? Dajmy IT wolną rękę, określmy proste reguły działania i do dzieła!? Osobiście wróżę takiemu podejściu raczej kiepski finał. Nawet zakładając, że IT w ramach ciągłej interakcji i dopasowywania się ostatecznie spełni cele biznesowe, pozostanie zgodne z regulacjami prawnymi i nie narazi firmy na ryzyko, to nie ma żadnej pewności, że będzie do czego wracać... Wg teorii CAS działają najlepiej, gdy są na krawędzi chaosu. Balansowanie na krawędzi ma to do siebie, że od czasu do czasu odchylamy się niebezpiecznie w stronę przepaści, ale cały czas nie spadamy. W przypadku ławicy ryb, przekroczenie krawędzi chaosu oznacza podzielenie się grupy na 2 osobne ławice, które jednak nie padną łupem rekina. W przypadku działania IT krawędzią chaosu mogą być przepisy prawa lub olbrzymie ryzyko utraty danych/systemów. Złamanie regulacji prawa, czy złe działanie systemu transakcyjnego w banku może doprowadzić do jego upadku. W takim przypadku musimy próbować wprowadzić narzędzie, które będzie utrzymywało IT w pewnej odległości od krawędzi chaosu i w tym miejscu widzę zadanie dla IT governance. Nie ma oczywiście sensu udawać, że wdrożenie nadzoru korporacyjnego załatwi wszystkie problemy i organizacja będzie w pełni zabezpieczona przed ryzykiem. Jedyną rzeczą jaką IT governance może zagwarantować, to zwiększenie poczucia pewności, co do dobrego funkcjonowania informatyki w firmie. O pewność i spokój inwestorów, regulatorów, pracowników i klientów tak na prawdę chodzi w ostatecznym rozrachunku.

W następnej notce opiszę jak widzę budowę IT governance przy wykorzystaniu zwinnych narzędzi zarządzania... cdn.

czwartek, 25 marca 2010

ISACA oficjalnie ogłosiła rozpoczęcie prac nad nową wersją standardu CobiT. Na stronach organizacji już teraz można się zapoznać z dokumentem prezentującym ogólne założenia CobiT 5 i wyrazić swoją opinię na temat proponowanych zmian i ulepszeń. Dla mnie szczególnie atrakcyjnie brzmi:

  • pomysł zintegrowania dotychczasowych rozwiązań (CobiT, Val IT, Risk IT) w jeden, spójny standard,
  • szersze odniesienie się do architektury korporacyjnej (wykorzystano m.in. siatkę Zachmana),
  • przygotowanie oddzielnych publikacji dla różnych, specjalistycznych wycinków IT, jak np. bezpieczeństwo, projekty, usługi, IT governance,
  • wyjaśnienie różnicy pomiędzy zarządzaniem (management) a nadzorem korporacyjnym (governance), której tak na prawdę nie było widać w wersji 4.1.

Zapowiada się, że zespół autorów CobiT ma ambicję stworzenia uniwersalnego podręcznika do zarządzania organizacją IT. Co z tego wyjdzie, tego nikt teraz nie wie, ale zapowiada się co najmniej interesująco...

środa, 17 marca 2010

Czasami nawet najmniejsza awaria systemu informatycznego może spowodować spore zamieszanie. Weźmy chociażby przykład z ostatniego weekendu. W piątkowy wieczór klienci banku Pekao nie mogli się zalogować do systemu e-bankowości. Wg relacji medialnych, nie było też żadnego komunikatu podającego przyczyny niedostępności systemu. No właśnie, relacje medialne. System naprawiono w krótkim czasie, a mimo to czołówki wszystkich portali informacyjnych i strony weekendowych wydań dzienników, biły na alarm. Może dziennikarze pamiętali jeszcze wpadkę banku sprzed pół roku, gdy system banku podwójnie wykonywał zlecone transakcje? Moim zdaniem, nie byłoby takiego zamieszania, gdyby klienci banku dostali na czas przejrzysty komunikat o tym, co się stało i o terminie w którym awaria będzie usunięta. Ludzie z natury mają tendencję do wybaczania błędów i szybkiego ich zapominania pod warunkiem, że w rzetelny i bezpośredni sposób się przekaże im się okoliczności "wpadki".

Ważne też, żeby komunikat trafił do nich zanim sami doświadczą jakiegokolwiek typu niedogodności. Tu mogę podać przykład z autopsji, również dotyczący e-bankowości. Pewnego razu zalogowałem się do swojego konta i zobaczyłem wyczyszczone do zera lokaty. Oczywiście skoczyło lekko ciśnienie, szybko wylogowałem się i spróbowałem od razu dzwonić do centrali. Jednak zanim do końca wysłuchałem litanii automatu, zauważyłem niepozorny komunikat o pracach konserwacyjnych. Fakt, że logowanie w trakcie prac powinno być uniemożliwione, ale w pierwszej kolejności nie próbowałbym dobijać się do konta, gdyby komunikat był lepiej widoczny.

Co zatem można zrobić, żeby uniknąć sytuacji gdy niedoinformowani klienci sieją panikę? Przede wszystkim wdrożyć dobry plan kryzysowy. Jego częścią jest również planowanie komunikacji, która powinna objąć wszystkich interesariuszy. W tym konkretnym przypadku może warto by było informować smsem klientów o awarii, albo przynajmniej umieścić uspokajający komunikat na stronie z logowaniem. Jeśli awaria dotyczyła strony www, to może wzorem niektórych firm hostingowych, zapewnić awaryjną platformę (strona do której jest automatycznie przekierowywany ruch), gdzie będą zamieszczane tylko i wyłącznie komunikaty o przerwach administracyjnych i awariach? Na pewno można coś mądrego wymyślić - nie kosztuje to aż tak dużo, a może nam zaoszczędzić chociażby strat na wizerunku.

Tagi: BCP DRP
12:11, pawess , CIO
Link Komentarze (1) »
środa, 10 marca 2010

Pierwsza część dostępna jest tutaj.


6. Skoncentruj się na tym, czym IT dysponuje obecnie.

Wpierw opisz to, czym teraz dysponujesz i jakie poziomy dostępności oraz przywrócenia ciągłości IT może zapewnić w chwili obecnej. Policz, ile czasu realnie zajmie IT odtworzenie systemów w różnych scenariuszach awarii. Sporządź zestawienie, które zobrazuje, jakie dane i w jakim horyzoncie czasowym mogą być utracone w przypadku kryzysu. Dopiero tak przygotowany, rozmawiaj z biznesem o dalszych korkach.

7. Porównaj oczekiwania biznesu ze stanem obecnym.

Jeśli dobrze udokumentujesz obecne możliwości IT, nie powinieneś mieć problemów z uzasadnieniem wydatków na poprawę ciągłości działania usług informatycznych lub z przekonaniem o konieczności poniesienia takich nakładów w przyszłości. Biznes czasem nie zdaje sobie sprawy, jakie będą konsekwencje poważnej awarii w IT. Jeśli okaże się, że przy obecnym stanie infrastruktury, IT może "odtworzyć się" po tygodniu, gdy oczekiwania są na poziomie 2 dni, to nie świadczy źle o IT, a wręcz przeciwnie. IT, dokonując takiej analizy, będzie traktowane jako partner i na pewno zostanie docenione aktywne podejście do problemu przygotowania się na niespodziewane zagrożenia.

8. Zaproponuj strategie odtworzenia usług IT komponującą się z wymaganiami biznesu.

Przy wyborze strategii przede wszystkim należy pamiętać o balansie między środkami poniesionymi na jej wdrożenie, a ewentualnymi skutkami wystąpienia zagrożenia. Wybrana strategia powinna też uwzględniać wymagany przez biznes czas na odtworzenie oraz maksymalny zakres straconych danych na skutek awarii.

9. Pamiętaj, że scenariuszy nie piszesz dla siebie.

Same scenariusze powinno się pisać z myślą o tych, którzy będą z nich korzystać w przypadku wystąpienia awarii. Nie ma żadnej gwarancji, że cały personel IT będzie wtedy dostępny i że nie zostaną wykorzystane zasoby z zewnątrz, czy z innych oddziałów firmy przy odtwarzaniu IT. Ludzie ci nie będą znali np. rozmieszczenia pokoi, sprzętu, a wiele rzeczy oczywistych dla administratorów będzie dla nich zupełnie niejasne. Wniosek z tego taki, że przejrzystość planów (obok aktualności) jest niezwykle istotna.

10. Rozejrzyj się za narzędziem, które będzie wspierało proces.

Na końcu można rozejrzeć się za narzędziem informatycznym, które ułatwi zarządzanie planami, poprawi ich dostępność i możliwość szybkiego dopasowania do zmieniającego się środowiska IT...

Tagi: BCP CIO DRP
12:27, pawess , CIO
Link Dodaj komentarz »
wtorek, 02 marca 2010

Przygotowanie planów i strategii działania na wypadek poważnej awarii IT nie jest zadaniem łatwym, wymaga dużego zaangażowania i niekiedy sporych nakładów pieniężnych (jeśli w grę wchodzą również inwestycje w zapasową infrastrukturę). Proces planowania kryzysowego, zgodnie z zasadami IT governance, powinien tak jak każdy inny realizować założenia wynikające z celów biznesowych organizacji. By temu sprostać warto pamiętać o paru istotnych sprawach, które często bywają pomijane w procesie wdrażania DRP. Poniżej znajdziecie kilka dobrych praktyk, które z pewnością pomogą w tym zadaniu:

1. Zdobądź poparcie wszystkich zainteresowanych.

Przygotowanie planów kryzysowych będzie wiązało się z koniecznością współpracy z wieloma stronami. Pomijając w tym miejscu problem kooperacji między komórkami wewnątrz IT, w planach musimy uwzględnić analizy wykonane przez biznes (BIA - business impact analysis) albo wręcz sami je przeprowadzić, uzyskać zgodę na wydatki związane z wdrożeniem i utrzymaniem procesu DRP, zbudować ścieżki komunikacji kryzysowej, które to powinny dotrzeć zarówno do zarządu, jak i do wszystkich zewnętrznych stron zaangażowanych w interesy firmy (np. klienci, dostawcy, służby ratownicze, media, itp.). Liczba wewnętrznych działów i zewnętrznych jednostek potencjalnie korzystających z większego bezpieczeństwa ciągłości świadczenia usług IT będzie rosła wraz z zasięgiem i poziomem wsparcia udzielanego przez dział informatyczny. Kluczowe jest zatem, aby uzyskać akceptację dla działań w zakresie DRP na najwyższym poziomie (zarząd), co zapewni finansowanie projektu i otworzy nam drzwi po stronie biznesu. Nie możemy jednak też zapominać o pozostałych interesariuszach, mając szczególnie na uwadze budowę porozumienia odnośnie celów projektu wewnątrz samego IT.

2. Pozyskaj wiedzę.

Nie warto wymyślać koła na nowo, skoro już zostało wymyślone. Zamiast budować autorski proces DRP, skorzystaj z dostępnej na rynku wiedzy, czy to w postaci szkoleń, czy dobrych praktyk (np. ITIL) lub doświadczeń zaprzyjaźnionych firm, które DRP mają już wdrożone. Oczywiście innowacyjność i pomysłowość dotycząca pewnych rozwiązań z zakresu zapewnienia ciągłości jest jak najbardziej na miejscu, bo każda organizacja jest wyjątkowa i nie da się bezmyślnie skopiować wszystkiego, co znajdziemy w książce czy u konkurencji.

DRP Dilbert

3. Wybierz przyszłego właściciela procesu DRP.

DRP to proces, a każdy proces powinien mieć swojego właściciela. To najprostsze tłumaczenie, ale zarazem najbardziej trafiające w sedno. Pamiętajmy, że nie da się raz przygotować planów i potem o nich zapomnieć. Nad procesem wdrażania, utrzymywaniem aktualności i testowaniem planów musi czuwać wyznaczona do tego osoba. Nic nie stoi też na przeszkodzie, żeby właściciel procesu DRP pełnił jednocześnie inną funkcję, np. menedżera d/s bezpieczeństwa IT.

4. Zaangażuj maksymalnie dużą ilość osób.

Gdyby się uprzeć, to na dobrą sprawę plany kryzysowe mogą powstać w zaciszu biurowego kąta, ale korzyść z tego będzie wątpliwa. Raz, że nie będą uwzględniały rzeczywistych ścieżek działania podczas awarii, dwa, że po krótkim czasie staną się nieaktualne, bo nikt nie będzie czuł się za nie współodpowiedzialny. Dlatego wręcz konieczne jest zaproszenie do działania osoby, które na co dzień zajmują się utrzymaniem usług IT.

5. Zacznij od punktu widzenia biznesu.

DRP powstaje po to, by zagwarantować biznesowi dostępność usług IT w danych ramach czasowych. Ramy te są z kolei określone przez krytyczność procesów biznesowych, które wspierają usługi IT. Planujmy więc, mając na uwadze czas, przez jaki biznes może się obejść bez systemu/aplikacji/usługi i nie będzie powodować poważnych strat i utraty marki firmy.

cdn.

Tagi: BCP CIO DRP ITIL
12:24, pawess , CIO
Link Komentarze (3) »
czwartek, 25 lutego 2010

Może nie taki nowy, bo został wydany przed końcem 2009 roku, ale przy okazji powrotu do blogowania na pewno warto o nim wspomnieć ;)

To już trzeci po CobiT i ValIT standard wydany przez ISACA (międzynarodowe stowarzyszenie audytorów IT). Tym razem głównym tematem jest ryzyko, a konkretniej sposób w który się je identyfikuje, zarządza i nadzoruje.

Standard, jak i wiele innych ciekawych materiałów pomocniczych można pobrać po uprzednim zalogowaniu z tego miejsca.

Risk IT - standard ISACA

Z ciekawostek, publikacji nowego opracowania towarzyszy również informacja o możliwości zdobyciu nowego certyfikatu z zakresu zarządzania ryzykiem - CRISC. Tak jak w przypadku wprowadzonego w ubiegłym roku CGEIT (certyfikat z IT governance) istnieje możliwość otrzymania tego papieru świadczącego o kompetencjach w dziedzinie ryzyka "za zasługi". "Wystarczy" być członkiem ISACA i udokumentować swoje doświadczenie w/w dziedzinie. Po szczegóły odsyłam tu.

poniedziałek, 22 lutego 2010

Niemalże rok temu pisałem o badaniu, które miało odpowiedzieć na pytanie czy zasady IT governance są stosowane w polskich firmach i instytucjach publicznych, a jeśli tak, to w jakim zakresie. Otóż wreszcie przyszła pora na publikację częściowych wyników Ankiety IT Governance 2009. Częściowych, bo do kompletnych danych pozyskanych w trakcie badania mają dostęp jedynie respondenci, którzy poświęcili swój cenny czas na wypełnienie elektronicznego formularza ankiety.

Zapraszam wszystkich zainteresowanych wynikami badania do zapoznania się z artykułem pt. "Wierzący, mało praktykujący", zamieszczonym w nr 8 Computerworld oraz na stronach internetowych tygodnika (wymagana jest rejestracja). Dowiecie się z niego czym jest IT governance dla polskiego menedżera, ile organizacji zdecydowało się na wdrożenie ładu korporacyjnego w informatyce, kto mierzy dojrzałość IT i jak (wysoko) się ocenia, w jaki sposób można budować komunikację z biznesem, kto decyduje o zasadach funkcjonowania IT oraz dlaczego działania związane z IT są tak ryzykowne.


Cytat dnia:

73% firm i instytucji ma świadomość pozytywnej roli, jaką może odegrać wdrożenie przejrzystych zasad funkcjonowania IT - jedna ze statystyk badania zaprezentowana z artykule "Wierzący, mało praktykujący".

czwartek, 04 lutego 2010

Żeby odpowiedzieć na pytanie zadane w tytule notki należy wpierw przyjrzeć się potrzebom własnej organizacji i zastanowić się czy to co oferuje norma PN ISO/IEC 27001:2005 jest w stanie spełnić nasze oczekiwania.

Potrzeba wdrożenia systemu zarządzania bezpieczeństwem może wyniknąć z wielu źródeł. Oto przykłady:

  • Organizacja, która doświadczyła przykrego incydentu związanego np. z wyciekiem poufnych danych, będzie szukała metody na zminimalizowanie prawdopodobieństwa wystąpienia podobnego zdarzenia w przyszłości.
  • Instytucja budująca swą markę na zaufaniu publicznym (np. bank, urząd, szpital) chce dostarczyć obecnym i potencjalnym klientom dowodu na to, że jest warta zaufania.
  • Firma, która jest dostawcą usług dla tzw. rynków regulowanych, chce uwiarygodnić swą pozycję i wyróżnić się wśród konkurencji posiadaniem swoistego glejtu, jakim jest certyfikat ISO.
  • I w końcu przypadek bardzo uniwersalny - kierownictwo chce mieć kontrolę nad poziomem bezpieczeństwa informacji, która w obecnych czasach jest najbardziej wartościowym aktywem każdej organizacji.

Wygląda zatem na to, że przepisy normy mogą się przydać prawie każdemu. Zresztą wystarczy spojrzeć na rejestr polskich organizacji, które certyfikowały swój system zarządzania bezpieczeństwem informacji (SZBI). Widać na niej firmy z wielu branż, o różnej wielkości oraz rozmaite urzędy i instytucje. Mimo, że lista ta jest niepełna, to jednak trochę zastanawia niewielka ilość pozycji na liście. Popularność normy ISO 27001 powinna jednak rosnąć z czasem i pewnie w przyszłości dogoni w liczbie wdrożeń "dziewiątkę" i "czternastkę".

Zakładając, że znaleźliśmy się w jednym z wymienionych wcześniej przypadków, pora zerknąć do normy i poszukać w niej przydatnych narzędzi w zarządzaniu bezpieczeństwem. Na pierwszy rzut oka przepisy normy wydają się bardzo ogólne i mało praktyczne i tak też po części jest, bo to czego szukamy to są przecież zabezpieczenia, które podniosą poziom bezpieczeństwa naszej organizacji. Ale czy aby na pewno? Skąd będziemy wiedzieli, że stosujemy odpowiednie zabezpieczenia jeśli wpierw nie zidentyfikujemy zagrożeń i podatności, które wpływają na procesy organizacji? Albo jak zweryfikujemy, że mechanizmy, które z dużym trudem wdrożyliśmy rzeczywiście wypełniają swoją rolę? Może się też okazać, że koszt wdrożenia zabezpieczenia znacznie przewyższył koszt potencjalnych skutków utraty informacji... Aby nie błądzić we mgle różnorakich procedur i innych mechanizmów bezpieczeństwa konieczne jest wdrożenie SZBI i zarządzanie nim zgodnie z procesem opisanym w normie. Zapewnienie poufności, integralności i dostępności informacji w organizacji poprzez wdrożenie odpowiednich zabezpieczeń jest tylko jednym z wielu kroków tego procesu.

Przechodząc do zabezpieczeń trzeba przyznać, że norma (a właściwie załącznik A i norma ISO 27002) pokrywa praktycznie cały zakres czynności, które należałoby zapewnić by organizacja mogła być pewna bezpieczeństwa swoich aktywów informacyjnych. Znajdziemy tam wszystko co się tyczy przetwarzania danych w systemach informatycznych, zgłaszania incydentów, zapewnienia ciągłości działania, zgodności z prawem, itp. obszarami. Oczywiście każde z zabezpieczeń jest opisane na dużym poziomem ogólności, ale to akurat jest zaletą normy, gdyż zostawia nam wolną rękę w gestii rozwiązań techniczno - proceduralnych.

Kolejną kwestią wartą osobnego poruszenia jest certyfikacja. Wracając do przypadków zaprezentowanych na początku, zastanówmy się czy konieczne jest posiadanie "papierka" na SZBI, skoro zależy nam tylko na wewnętrznej pewności co do bezpieczeństwa informacji? Pewnie nie, ale świadomość wiszącego nad nami kija w postaci audytów trzeciej strony, zapewne pomoże nam w motywowaniu dalszych działań w kierunku ulepszenia systemu i bezpieczeństwa organizacji. Przypadki w których certyfikat będzie pracował na naszą korzyść w kontaktach z klientem, chyba nie wymagają dalszego wyjaśniania.


Ciekawostka dnia:

Norma ISO/IEC 27001:2005 wymusza wdrożenie tylko 4 (słownie: czterech) udokumentowanych pisemnie procedur. Każda większa ilość jest dobrowolnym wyborem organizacji, który powinien być zmotywowany efektem przeprowadzonej analizy ryzyka.

 
1 , 2 , 3 , 4 , 5