дарт легко масштабується і нарощується. CoBiT дозволяє використовувати будь розробки виробників апаратно-програмного забезпечення та аналізувати отримані дані. p align="justify"> На етапі підготовки і підписання початково-дозвільної документації визначаються межі проведення аудиту. Вони можуть бути обумовлені критичними точками інформаційної системи (елементами, в яких найбільш часто виникають проблемні ситуації), або приймається рішення про проведення повного аудиту з подальшою поглибленої перевіркою виявлених проблем. В цей же час створюється команда проведення аудиту, визначаються відповідальні особи з боку замовника, створюється і узгоджується необхідна документація. p align="justify"> Далі проводиться збір інформації про поточний стан інформаційної системи у відповідності зі стандартом CoBiT, об'єкти контролю якого отримують інформацію про всі нюанси функціонування інформаційної системи, як у двійковій формі (Так/Ні), так і у формі розгорнутих звітів. Детальність інформації визначається на етапі розробки початково-дозвільної документації. Існує певний оптимум між витратами (тимчасовими, вартісними і т.д.) на отримання інформації та її актуальністю. p align="justify"> Аналіз - найбільш відповідальна частина аудиту. Використання при аналізі недостовірних, застарілих даних неприпустимо, тому необхідно уточнення даних, поглиблений збір інформації. Вимоги до проведення аналізу визначаються на етапі збору інформації. Методики аналізу інформації маються на стандарті CoBiT, але якщо їх не вистачає, не забороняється використовувати дозволені ISACA розробки інших компаній. p align="justify"> Результати проведеного аналізу стають базою для вироблення рекомендацій, які після попереднього узгодження з замовником повинні бути перевірені на здійснимість і актуальність з урахуванням ризиків впровадження.
Контроль виконання рекомендацій - важливий етап, що вимагає безперервного відстеження представниками консалтингової компанії ходу виконання рекомендацій.
На етапі розробки додаткової документації створюються документи, відсутність яких, наприклад документів, що містять поглиблене розгляд питань забезпечення безпеки інформаційної системи, може викликати збої в її роботі.
Постійне проведення аудиту гарантує стабільність функціонування інформаційної системи, тому створення плану-графіка подальших перевірок є одним з результатів професійного аудиту.
.3 Використання CoBiT в Ощадбанку
Бізнес банку надзвичайно широкий, і на всьому цьому обладнанні працює велика кількість прикладних систем. Обслуговування цього обширного господарства ІТ-персоналом до початку впровадження системи управління ІТ було регламентовано досить слабо. Все це призводило до великої кількості збоїв і перерв у бізнесі. Першою метою було кардинальне зниження кількості інцидентів і скорочення термінів їх усунення. p align="justify"> Основна умова впровадження інформаційних систем в підприємство не кількість ПК в компанії, а кількість ІТ-персоналу і рівень його спеціалізації.
Для аудиту ІТ в Ощадбанку використовується система CoBiT.
Аналізуючи результат впровадження, дуже складно відокремити технологічну складову від організаційної. Якщо оцінювати трудовитрати в процесі впровадження, то основна їх частка посідає організаційну сторону, а впровадження ІТ-компонентів становить набагато меншу частину. Наприклад, HP Service Desk було впроваджено протягом трьох місяців. Як тільки вся інформація потрапляє в Service Desk, системні адміністратори позбавляються ілюзії абсолютної влади над своїми користувачами. Якщо говорити про результати, на першому етапі основні результати були досягнуті за рахунок організаційних зусиль. Технології як такі просто підтримували внутрішні організаційні зміни. Наприклад, в три рази скоротився час усунення інцидентів, тобто людей поставили під контроль і вони стали працювати більш дисципліновано. Потім час усунення інцидентів стабілізувалося, їх загальна кількість продовжувало знижуватися, але це зниження було вже не дуже значним. Саме тоді виникла потреба в серйозній технологічній підтримці. p align="justify"> Час усунення інцидентів не змінювалося тому, що основні зусилля витрачалися на з'ясування того, на якій ділянці трапилася несправність - обладнання, локальної мережі, прикладного ПЗ. Наприклад, фахівці з прикладного програмного забезпечення витрачали свій час на дозвон до сетевикам, а ті, у свою чергу, дізнавалися про якісь зміни в службі безпеки. Відповідно, необхідно було створення інтегрованої системи моніторингу, щоб адміністратори всіх рівнів - від системного адміністратора до CIO - могли бачити, в якому елементі інфраструктури трапився інцидент. Раніше існували системи моніторингу були локальні - фахівці з серверів дивилися на сервери, мережевики дивилися на маршрутизатори, адміністратори прикладного ...
