Аудит інформаційних систем дає актуальні та точні дані про те, як працює ІС. На базі даних можна планувати заходи для підвищення ефективності підприємства. Практика проведення аудиту інформаційної системи - порівняно зразка, реальної обстановки. Вивчають нормативи, стандарти, регламенти та практики, які застосовуються в інших фірмах. Під час проведення аудиту підприємець отримує уявлення у тому, як його фірма відрізняється від нормальної успішної компанії у аналогічній сфері.

Загальне уявлення

Інформаційні технології у світі розвинені виключно сильно. Важко уявити собі підприємство, яке має на озброєнні інформаційні системи:

• глобальні;
• локальні.

Саме за рахунок ІС компанія може нормально функціонувати та йти в ногу з часом. Такі методології необхідні для швидкого та повного обміну інформацією із навколишнім середовищем, що дозволяє компанії підлаштовуватися під зміни інфраструктури та вимог ринку. Інформаційні системи повинні задовольняти низку вимог, що змінюються з часом (впроваджуються нові розробки, стандарти, застосовують оновлені алгоритми). У будь-якому разі інформаційні технології дозволяють зробити доступ до ресурсів швидким, і це завдання вирішується через ІС. Крім того, сучасні системи:

• масштабовані;
• гнучкі;
• надійні;
• безпечні.

Основні завдання аудиту інформаційних систем – виявлення, чи відповідає впроваджена ІС зазначеним параметрам.

Аудит: види

Найчастіше застосовується так званий процесний аудит інформаційної системи. Приклад: зовнішні фахівці аналізують впроваджені системи щодо відмінності від еталонів, вивчаючи зокрема й виробничий процес, на виході якого - програмне забезпечення.

Може проводитися аудит, спрямований виявлення того, наскільки правильно застосовується у роботі інформаційна система. Практику підприємства порівнюють зі стандартами виробника та відомими прикладами корпорацій міжнародного масштабу.

Аудит системи інформаційної безпеки підприємства торкається організаційної структури. Мета такого заходу – знайти тонкі місця у кадрах ІТ-відділу та позначити проблеми, а також сформувати рекомендації щодо їх вирішення.

Зрештою, аудит системи забезпечення інформаційної безпеки спрямований на якісний контроль. Тоді запрошені експерти оцінюють, у якому стані процеси всередині підприємства, тестують впроваджену інформаційну систему та роблять деякі висновки щодо отриманої інформації. Зазвичай застосовується модель TMMI.

Завдання аудиту

Стратегічний аудит стану інформаційних систем дозволяє визначити слабкі місця у впровадженій ІВ та виявити, де застосування технологій виявилося неефективними. На виході такого процесу замовник матиме рекомендації, що дозволяють усунути недоліки.

Аудит дозволяє оцінити, наскільки дорого обійдеться внесення змін до діючої структури і скільки часу це займе. Фахівці, які вивчають діючу інформаційну структуру компанії, допоможуть підібрати інструментарій для реалізації програми покращень, враховуючи особливості компанії. За підсумками можна також видати точну оцінку, якого обсягу ресурсів потребує фірма. Проаналізовано інтелектуальні, грошові, виробничі.

Заходи

Внутрішній аудит інформаційних систем включає проведення таких заходів, як:

• інвентаризація ІТ;
• виявлення навантаження на інформаційні структури;
• оцінка статистики, даних, одержаних при інвентаризації;
• визначення, чи відповідають вимоги бізнесу та можливості впровадженої ІВ;
• формування звіту;
• розробка рекомендацій;
• формалізація фонду НДІ.

Результат аудиту

Стратегічний аудит стану інформаційних систем – це процедура, яка: дозволяє виявити причини недостатньої ефективності впровадженої інформаційної системи; провести прогнозування поведінки ІС під час коригування інформаційних потоків (числа користувачів, обсягу даних); надати обґрунтовані рішення, що допомагають підвищити продуктивність (придбання обладнання, удосконалення впровадженої системи, заміна); дати рекомендації, створені задля підвищення продуктивності відділів підприємства, оптимізацію вкладень у технології. А також розробити заходи, які покращують якісний рівень сервісу інформаційних систем.

Це важливо!

Немає такої універсальної ІВ, яка б підійшла будь-якому підприємству. Є дві поширені бази, на основі яких можна створювати унікальну систему під вимоги конкретного підприємства:

• Oracle.

Але пам'ятайте, що це лише основа, не більше. Усі удосконалення, що дозволяють зробити бізнес ефективним, потрібно програмувати з огляду на особливості конкретного підприємства. Напевно доведеться вводити функції, що раніше відсутні, і відключати ті, які передбачені базовою збіркою. Сучасна технологія аудиту банківських інформаційних систем допомагає зрозуміти, які саме особливості повинна мати ІВ, а що потрібно виключити, щоб корпоративна система була оптимальною, ефективною, але не надто «важкою».

Аудит інформаційної безпеки

Аналіз, що дозволяє виявити загрози інформаційній безпеці, буває двох видів:

• зовнішній;
• внутрішній.

Перший передбачає одноразову процедуру. Організовує її керівник компанії. Рекомендовано регулярно практикувати такий захід, щоб утримувати ситуацію під контролем. Ряд АТ, фінансових організацій запровадили вимогу зовнішнього аудиту ІТ-безпеки обов'язковою до виконання.

Внутрішній - це заходи, що регулярно проводяться, регламентовані локальним нормативним актом «Положення про внутрішній аудит». Для проведення формують річний план (його готує відділ відповідальний за аудит), стверджує генеральний директор, інший керівник. ІТ-аудит - кілька категорій заходів, аудит безпеки займає не останнє місце за значимістю.

Цілі

Головна мета аудиту інформаційних систем в аспекті безпеки - це виявлення ризиків, пов'язаних з ІС, що пов'язані з загрозами безпеці. Крім того, заходи допомагають виявити:

• слабкі місця чинної системи;
• відповідність системи стандартам інформаційної безпеки;
• рівень безпеки на поточний момент часу.

При аудиті безпеки в результаті будуть сформульовані рекомендації, що дозволяють покращити поточні рішення та впровадити нові, зробивши тим самим діючу ІС безпечніше та захищені від різних загроз.

Якщо проводиться внутрішній аудит, покликаний визначити загрози інформаційної безпеки, додатково розглядається:

• політика безпеки, можливість розробки нової та інших документів, що дозволяють захистити дані та спростити їх застосування у виробничому процесі корпорації;
• формування завдань забезпечення безпеки працівникам ІТ-відділу;
• розбір ситуацій, пов'язаних із порушеннями;
• навчання користувачів корпоративної системи, що обслуговує персонал загальним аспектам безпеки.

Внутрішній аудит: особливості

Перелічені завдання, які ставлять перед співробітниками, коли проводиться внутрішній аудит інформаційних систем, власне, не аудит. Теоретично проводить заходи лише як експерт оцінює механізми, завдяки яким система убезпечена. Залучена до завдання особа стає активним учасником процесу і втрачає незалежність, що вже не може об'єктивно оцінювати ситуацію та контролювати її.

З іншого боку, практично при внутрішньому аудиті залишитися осторонь практично неможливо. Справа в тому, що для проведення робіт залучають спеціаліста компанії, в інший час зайнятого іншими завданнями у подібній галузі. Це означає, що аудитор - це той самий співробітник, який має компетенцію для вирішення згаданих раніше завдань. Тому доводиться йти на компроміс: на шкоду об'єктивності залучати працівника до практики, щоб отримати гідний результат.

Аудит безпеки: етапи

Такі багато в чому подібні до кроків загального ІТ-аудиту. Виділяють:

• старт заходів;
• збирання бази для аналізування;
• аналіз;
• формування висновків;
• звітність.

Ініціювання процедури

Аудит інформаційних систем в аспекті безпеки починається, коли на це дає відмашку керівник компанії, тому що саме начальники - ті персони, які більше зацікавлені в ефективній перевірці підприємства. Проведення аудиту неможливе, якщо керівництво не підтримує процедуру.

Аудит інформаційних систем зазвичай є комплексним. У ньому бере участь аудитор та кілька осіб, які представляють різні відділи компанії. Важливою є спільна робота всіх учасників перевірки. При ініціації аудиту важливо приділити увагу наступним моментам:

• документальна фіксація обов'язків, прав аудитора;
• підготовка, узгодження плану аудиту;
• документальне закріплення того факту, що співробітники зобов'язані надавати аудитору посильну допомогу і надавати всі запитані дані.

Вже під час ініціації перевірки важливо встановити, у яких межах проводиться аудит інформаційних систем. У той час як деякі підсистеми ІВ критичні і вимагають особливої ​​уваги, інші такими не є і незначні, тому допускається їх виключення. Напевно, знайдуться і такі підсистеми, перевірка яких буде неможлива, тому що вся інформація, яка там зберігається, конфіденційна.

План та кордони

Перед початком робіт формується перелік ресурсів, які передбачається перевірити. Це можуть бути:

• інформаційні;
• програмні;
• технічні.

Виділяють, на яких майданчиках проводять аудит, які загрози перевіряють систему. Існують організаційні межі заходу, аспекти забезпечення безпеки, обов'язкові для обліку під час перевірки. Формується рейтинг пріоритетності із зазначенням обсягу перевірки. Такі межі, а також план заходу затверджуються генеральним директором, але попередньо виносяться темою загальних робочих зборів, де присутні начальники відділів, аудитор та керівники компанії.

Отримання даних

Під час проведення перевірки безпеки стандарти аудиту інформаційних систем такі, що етап збирання інформації виявляється найтривалішим, трудомістким. Як правило, ІС немає документації до неї, а аудитор змушений щільно працювати з численними колегами.

Щоб зроблені висновки виявилися компетентними, аудитор має отримати максимум даних. Про те, як організована інформаційна система, як вона функціонує і в якому стані перебуває, аудитор дізнається з організаційної, розпорядчої, технічної документації під час самостійного дослідження та застосування спеціалізованого ПЗ.

Документи, необхідні у роботі аудитора:

• організаційна структура відділів, які обслуговують ІВ;
• Організаційна структура всіх користувачів.

Аудитор інтерв'ює працівників, виявляючи:

• провайдера;
• власника даних;
• користувача даних.

Для цього потрібно знати:

• основні види додатків ІВ;
• число, види користувачів;
• послуги, що надаються користувачам.

Якщо у фірмі є документи на ІВ із перерахованого нижче списку, обов'язково потрібно надати їх аудитору:

• опис технічних методологій;
• опис методик автоматизації функцій;
• функціональні схеми;
• робітники, проектні документи.

Виявлення структури ІВ

Для коректних висновків аудитор повинен мати максимально повне уявлення про особливості впровадженої на підприємстві інформаційної системи. Потрібно знати, якими є механізми безпеки, як вони розподілені в системі за рівнями. Для цього з'ясовують:

• наявність та особливості компонентів використовуваної системи;
• функції компонентів;
• графічність;
• входи;
• взаємодія з різними об'єктами (зовнішнє, внутрішнє) та протоколи, канали для цього;
• платформи, використані для системи.

Користь принесуть схеми:

• структурна;
• потоків даних.

Структури:

• технічних засобів;
• інформаційного забезпечення;
• структурні компоненти.

Насправді багато хто з документів готують безпосередньо під час проведення перевірки. Аналізувати інформацію можна лише за зборі максимального обсягу інформації.

Аудит безпеки ІВ: аналіз

Є кілька методик, що застосовуються для аналізу даних. Вибір на користь конкретної ґрунтується на особистих уподобаннях аудитора та специфіці конкретної задачі.

Найбільш складний підхід передбачає аналіз ризиків. Для інформаційної системи формуються вимоги до безпеки. Вони базуються на особливостях конкретної системи та середовища її роботи, а також загроз, властивих цьому середовищу. Аналітики сходяться на думці, що такий підхід потребує найбільших трудовитрат і максимальної кваліфікації аудитора. Наскільки гарним буде результат, визначається методологією аналізу інформації та застосовністю обраних варіантів до типу ІС.

Більш практичний варіант передбачає звернення до стандартів безпеки даних. Такими визначається набір вимог. Це підходить для різних ІС, оскільки методика вироблена на основі найбільших фірм із різних країн.

Зі стандартів випливає, які вимоги безпеки, що залежать від рівня захисту системи та належності її тій чи іншій установі. Багато залежить від призначення ІВ. Головне завдання аудитора – визначити коректно, який набір вимог щодо безпеки актуальний у заданому випадку. Вибирають методику, за якою оцінюють, чи відповідають стандартам наявні параметри системи. Технологія досить проста, надійна, тому поширена широко. При невеликих вкладеннях можна отримати точні висновки.

Нехтувати неприпустимо!

Практика показує, що багато керівників, особливо невеликих фірм, а також ті, чиї компанії працюють вже досить давно і не прагнуть освоювати всі новітні технології, ставляться до аудиту інформаційних систем досить недбало, тому що просто не усвідомлюють важливості цього заходу. Зазвичай лише збитки бізнесу провокує начальство вживати заходів щодо перевірки, виявлення ризиків та захисту підприємства. Інші стикаються з тим, що в них крадуть дані про клієнтуру, в інших витоку походять з баз даних контрагентів або йде інформація про ключові переваги якогось суб'єкта. Споживачі перестають довіряти компанії, як тільки випадок наголошується, і компанія зазнає ще більшої шкоди, ніж просто від втрати даних.

Якщо є можливість витоку інформації, неможливо побудувати ефективний бізнес, який має хороші можливості зараз і в майбутньому. Будь-яка компанія має дані, що становлять цінність для третіх осіб, і їх потрібно берегти. Щоб захист був на найвищому рівні, необхідний аудит, який виявляє слабкі сторони. У ньому необхідно враховувати міжнародні стандарти, методики, нові напрацювання.

При аудиті:

• оцінюють рівень захисту;
• аналізують застосовувані технології;
• коригують документи з безпеки;
• моделюють ризикові ситуації, при яких можливий витік даних;
• рекомендують використання рішень для усунення вразливостей.

Проводять ці заходи одним із трьох образів:

• активний;
• експертний;
• виявляє відповідність стандартам.

Форми аудиту

Активний аудит передбачає оцінку системи, яку дивиться потенційний хакер. Саме його думку «приміряють» він аудитори - вивчають мережевий захист, навіщо застосовують спеціалізоване ПЗ і унікальні методики. Обов'язковий і внутрішній аудит, що проводиться також з погляду передбачуваного злочинця, який бажає вкрасти дані або порушити роботу системи.

При експертному аудиті перевіряють, наскільки вдосконалена система ідеальна. При виявленні відповідності стандартам за основу беруть абстрактний опис стандартів, із якими порівнюють наявний об'єкт.

Висновок

Коректно та якісно проведений аудит дозволяє отримати наступні підсумки:

• мінімізація ймовірності успішної хакерської атаки, збитків від неї;
• виключення атаки, заснованої на зміні архітектури системи та інформаційних потоків;
• страхування як зменшення ризиків;
• мінімізація ризику рівня, коли такий зовсім не враховувати.

На сьогоднішній день автоматизовані системи (АС) відіграють ключову роль у забезпеченні ефективного виконання бізнес-процесів як комерційних, так і державних підприємств. Разом з тим, повсюдне використання АС для зберігання, обробки та передачі інформації призводить до підвищення актуальності проблем, пов'язаних з їх захистом. Підтвердженням цьому є той факт, що за останні кілька років, як у Росії, так і у провідних зарубіжних країнах має місце тенденція збільшення кількості інформаційних атак, що призводять до значних фінансових та матеріальних втрат. Щоб гарантувати ефективний захист від інформаційних атак зловмисників компаніям необхідно мати об'єктивну оцінку поточного рівня безпеки АС. Саме для цього і застосовується аудит безпеки, різні аспекти якого розглядаються в рамках цієї статті.

1. Що таке аудит безпеки?

Незважаючи на те, що в даний час ще не сформувалося усталеного визначення аудиту безпеки, у загальному випадку його можна подати у вигляді процесу збирання та аналізу інформації про АС, необхідну для подальшого проведення якісної чи кількісної оцінки рівня захисту від атак зловмисників. Існує безліч випадків, коли доцільно проводити аудит безпеки. Ось лише деякі з них:

• аудит АС з метою підготовки технічного завдання на проектування та розроблення системи захисту інформації;
• аудит АС після впровадження системи безпеки з метою оцінки рівня її ефективності;
• аудит, спрямований на приведення діючої системи безпеки у відповідність до вимог російського або міжнародного законодавства;
• аудит, призначений для систематизації та впорядкування існуючих заходів захисту інформації;
• аудит з метою розслідування інциденту, що стався, пов'язаного з порушенням інформаційної безпеки.

Як правило, для проведення аудиту залучаються зовнішні компанії, які надають консалтингові послуги у сфері інформаційної безпеки. Ініціатором процедури аудиту може бути керівництво підприємства, служба автоматизації чи служба інформаційної безпеки. У ряді випадків аудит може проводитися на вимогу страхових компаній або регулюючих органів. Аудит безпеки проводиться групою експертів, чисельність та склад якої залежить від цілей та завдань обстеження, а також складності об'єкта оцінки.

2. Види аудиту безпеки

В даний час можна виділити такі основні види аудиту інформаційної безпеки:

• експертний аудит безпеки, в процесі якого виявляються недоліки в системі заходів захисту інформації на основі досвіду експертів, що беруть участь у процедурі обстеження;
• оцінка відповідності рекомендаціям Міжнародного стандарту ISO 17799, а також вимогам керівних документів ФСТЕК (Держкомісії);
• інструментальний аналіз захищеності АС, спрямований на виявлення та усунення вразливостей програмно-апаратного забезпечення системи;
• комплексний аудит, що включає всі вищеперелічені форми проведення обстеження.

Кожен із перелічених вище видів аудиту може проводитися окремо чи комплексно залежно від тих завдань, які потрібно вирішити підприємству. Як об'єкт аудиту може виступати як АС компанії загалом, і її окремі сегменти, у яких проводиться обробка інформації, підлягає захисту.

3. Склад робіт із проведення аудиту безпеки

У випадку аудит безпеки, незалежно від форми проведення, складається з чотирьох основних етапів, кожен із яких передбачає виконання певного кола завдань (рис. 1).

Рисунок 1: Основні етапи робіт під час проведення аудиту безпеки

На першому етапі спільно із Замовником розробляється регламент, що встановлює склад та порядок проведення робіт. Основне завдання регламенту полягає у визначенні меж, у межах яких буде проведено обстеження. Регламент є тим документом, який дозволяє уникнути взаємних претензій щодо завершення аудиту, оскільки чітко визначає обов'язки сторін. Як правило, регламент містить таку основну інформацію:

• склад робочих груп від Виконавця та Замовника, які беруть участь у процесі проведення аудиту;
• перелік інформації, що буде надано Виконавцю для проведення аудиту;
• список та розташування об'єктів Замовника, що підлягають аудиту;
• перелік ресурсів, що розглядаються як об'єкти захисту (інформаційні ресурси, програмні ресурси, фізичні ресурси тощо);
• модель загроз інформаційній безпеці, на основі якої проводиться аудит;
• категорії користувачів, які розглядаються як потенційні порушники;
• порядок та час проведення інструментального обстеження автоматизованої системи Замовника.

На другому етапі, відповідно до узгодженого регламенту, здійснюється збір вихідної інформації. Методи збирання інформації включають інтерв'ювання співробітників Замовника, заповнення опитувальних листів, аналіз наданої організаційно-розпорядчої та технічної документації, використання спеціалізованих інструментальних засобів.

Третій етап робіт передбачає проведення аналізу зібраної інформації для оцінки поточного рівня захищеності АС Замовника. За результатами проведеного аналізу на четвертому етапі проводиться розробка рекомендацій щодо підвищення рівня захищеності АС від загроз інформаційній безпеці.

Нижче докладніше розглянуті етапи аудиту, пов'язані зі збором інформації, її аналізом і розробкою рекомендацій щодо підвищення рівня захисту АС.

4. Збір вихідних даних щодо аудиту

Якість аудиту безпеки багато в чому залежить від повноти і точності інформації, яка була отримана в процесі збору вихідних даних. Тому інформація має включати: існуючу організаційно-розпорядчу документацію, що стосується питань інформаційної безпеки, відомості про програмно-апаратне забезпечення АС, інформацію про засоби захисту, встановлені в АС тощо. Більш докладний список вихідних даних представлений у таблиці 1.

Таблиця 1: Перелік вихідних даних, необхідних для проведення аудиту безпеки

Як зазначалося вище, збір вихідних даних може здійснюватися з наступних методів:

• інтерв'ювання співробітників Замовника, які мають необхідну інформацію. При цьому інтерв'ю зазвичай проводиться як з технічними фахівцями, так і з представниками керівної ланки компанії. Перелік питань, які планується обговорити в інтерв'ю, узгоджується заздалегідь;
• надання опитувальних листів за певною тематикою, які самостійно заповнюють співробітники Замовника. У випадках, коли подані матеріали не повністю дають відповіді на необхідні питання, проводиться додаткове інтерв'ювання;
• аналіз існуючої організаційно-технічної документації, що використовується Замовником;
• використання спеціалізованих програмних засобів, які дозволяють отримати необхідну інформацію про склад та налаштування програмно-апаратного забезпечення автоматизованої системи Замовника. Так, наприклад, у процесі аудиту можуть використовуватися системи аналізу захищеності (Security Scanners), які дозволяють провести інвентаризацію наявних мережевих ресурсів і виявити вразливості, що є в них. Прикладами таких систем є Internet Scanner (компанії ISS) та XSpider (компанії Positive Technologies).

5. Оцінка рівня безпеки АС

Після збору необхідної інформації проводиться її аналіз із метою оцінки поточного рівня захищеності системи. У процесі такого аналізу визначаються ризики інформаційної безпеки, яким може бути схильна компанія. Фактично ризик є інтегральною оцінкою того, наскільки ефективно існуючі засоби захисту здатні протистояти інформаційним атакам.

Зазвичай виділяють дві основні групи методів розрахунку ризиків безпеки. Перша група дозволяє встановити рівень ризику шляхом оцінки ступеня відповідності певному набору вимог щодо забезпечення інформаційної безпеки. Як джерела таких вимог можуть виступати (рис. 2):

• Нормативно-правові документи підприємства щодо питань інформаційної безпеки;
• Вимоги чинного російського законодавства - керівні документи ФСТЕК (Держкомісії), СТР-К, вимоги ФСБ РФ, ГОСТи та ін;
• Рекомендації міжнародних стандартів – ISO 17799, OCTAVE, CoBIT та ін;
• Рекомендації компаній-виробників програмного та апаратного забезпечення – Microsoft, Oracle, Cisco та ін.

Рисунок 2: Джерела вимог інформаційної безпеки, на основі яких може проводитись оцінка ризиків

Друга група методів оцінки ризиків інформаційної безпеки базується на визначенні ймовірності реалізації атак, а також рівнів їх збитків. В даному випадку значення ризику обчислюється окремо для кожної атаки і в загальному випадку представляється як добуток ймовірності проведення атаки на величину можливої ​​шкоди від цієї атаки. Значення збитків визначається власником інформаційного ресурсу, а ймовірність атаки обчислюється групою експертів, які проводять процедуру аудиту.

Методи першої та другої групи можуть використовувати кількісні чи якісні шкали визначення величини ризику інформаційної безпеки. У першому випадку ризик і всі його параметри виражаються у числових значеннях. Так, наприклад, при використанні кількісних шкал ймовірність проведення атаки може виражатися числом в інтервалі, а збитки атаки можуть задаватися у вигляді грошового еквівалента матеріальних втрат, які може зазнати організація у разі успішного проведення атаки. З використанням якісних шкал числові значення замінюються на еквівалентні їм понятійні рівні. Кожному понятійному рівню у разі відповідатиме певний інтервал кількісної шкали оцінки. Кількість рівнів може змінюватись в залежності від застосовуваних методик оцінки ризиків. У таблицях 2 і 3 наведено приклади якісних шкал оцінки ризиків інформаційної безпеки, в яких для оцінки рівнів збитків та ймовірності атаки використовується п'ять понятійних рівнів.

Таблиця 2: Якісна шкала оцінки рівня збитків

Таблиця 3: Якісна шкала оцінки ймовірності проведення атаки

При використанні якісних шкал для обчислення рівня ризику застосовуються спеціальні таблиці, у яких у першому стовпці задаються понятійні рівні збитків, а першому рядку – рівні ймовірності атаки. Комірки таблиці, розташовані на перетині першого рядка і стовпця, містять рівень ризику безпеки. Розмірність таблиці залежить від кількості концептуальних рівнів ймовірності атаки та збитків. Приклад таблиці, на основі якої можна визначити рівень ризику, наведено нижче.

Таблиця 4: Приклад таблиці визначення рівня ризику інформаційної безпеки

При розрахунку значень ймовірності проведення атаки, і навіть рівня можливої ​​шкоди можуть використовуватися статистичні методи, методи експертних оцінок чи елементи теорії прийняття рішень. Статистичні методи припускають аналіз вже накопичених даних про реальні інциденти, пов'язані з порушенням інформаційної безпеки. На основі результатів такого аналізу будуються припущення про ймовірність проведення атак та рівні збитків від них в інших АС. Однак застосування статистичних методів не завжди можливе через відсутність у повному обсязі статистичних даних про раніше проведені атаки на інформаційні ресурси АС, аналогічною тій, яка виступає як об'єкт оцінки.

При використанні апарату експертних оцінок проводиться аналіз результатів роботи групи експертів, компетентних у галузі інформаційної безпеки, які на основі наявного досвіду визначають кількісні або якісні рівні ризику. Елементи теорії прийняття рішень дозволяють застосовувати для обчислення значення ризику безпеки складніші алгоритми обробки результатів роботи групи експертів.

У процесі проведення аудиту безпеки можуть використовуватися спеціалізовані програмні комплекси, що дозволяють автоматизувати процес аналізу вихідних даних та розрахунку значень ризиків. Прикладами таких комплексів є «Гриф» та «Кондор» (компанії Digital Security), а також АванГард (Інституту Системного Аналізу РАН).

6. Результати аудиту безпеки

На останньому етапі проведення аудиту інформаційної безпеки розробляються рекомендації щодо вдосконалення організаційно-технічного забезпечення підприємства. Такі рекомендації можуть включати такі типи дій, спрямованих на мінімізацію виявлених ризиків:

• зменшення ризику за рахунок використання додаткових організаційних та технічних засобів захисту, що дозволяють знизити ймовірність проведення атаки або зменшити можливу шкоду від неї. Так, наприклад, встановлення міжмережевих екранів у точці підключення АС до мережі Інтернет дозволяє суттєво знизити ймовірність проведення успішної атаки на загальнодоступні інформаційні ресурси АС, такі як Web-сервери, поштові сервери тощо;
• ухилення від ризику шляхом зміни архітектури чи схеми інформаційних потоків АС, що дозволяє унеможливити проведення тієї чи іншої атаки. Так, наприклад, фізичне відключення від мережі Інтернет сегмента АС, в якому обробляється конфіденційна інформація, дозволяє виключити атаки на конфіденційну інформацію з цієї мережі;
• зміна характеру ризику внаслідок вжиття заходів зі страхування. Як приклади такої зміни характеру ризику можна навести страхування обладнання АС від пожежі або страхування інформаційних ресурсів від можливого порушення їх конфіденційності, цілісності чи доступності. В даний час російських компаній вже пропонують послуги зі страхування інформаційних ризиків;
• прийняття ризику в тому випадку, якщо він зменшений до того рівня, на якому він не становить небезпеки для АС.

Як правило, розроблені рекомендації спрямовані не на повне усунення всіх виявлених ризиків, а лише на їхнє зменшення до прийнятного залишкового рівня. При виборі заходів щодо підвищення рівня захисту АС враховується одне принципове обмеження – вартість їх реалізації не повинна перевищувати вартість інформаційних ресурсів, що захищаються.

На завершення процедури аудиту його результати оформлюються у вигляді звітного документа, який надається Замовнику. Загалом цей документ складається з наступних основних розділів:

• опис меж, у межах яких було проведено аудит безпеки;
• опис структури АС Замовника;
• методи та засоби, які використовувалися в процесі проведення аудиту;
• опис виявлених уразливостей та недоліків, включаючи рівень їхнього ризику;
• рекомендації щодо вдосконалення комплексної системи забезпечення інформаційної безпеки;
• пропозиції щодо плану реалізації першочергових заходів, спрямованих на мінімізацію виявлених ризиків.

7. Висновок

Аудит інформаційної безпеки є сьогодні одним із найефективніших інструментів для отримання незалежної та об'єктивної оцінки поточного рівня захищеності підприємства від загроз інформаційній безпеці. Окрім того, результати аудиту є основою для формування стратегії розвитку системи забезпечення інформаційної безпеки організації.

Однак, необхідно уявляти, що аудит безпеки не є одноразовою процедурою, а має проводитися на регулярній основі. Тільки в цьому випадку аудит приноситиме реальну віддачу і сприятиме підвищенню рівня інформаційної безпеки компанії.

8. Список літератури

1. Віхорєв С.В., Кобцев Р.Ю., Як дізнатися – звідки напасти чи звідки виходить загроза безпеці інформації // Конфидент, №2, 2001.
2. Симонов З. Аналіз ризиків, управління ризиками // Інформаційний бюлетень Jet Info № 1(68). 1999. с. 1-28.
3. ISO/IEC 17799, Information technology – Code of practice for information security management, 2000
4. Operationally Critical Threat, Asset, та Vulnerability Evaluation (OCTAVE) – security risk evaluation – www.cert.org/octave.
5. Risk Management Guide for information Technology Systems, NIST, Special Publication 800-30.

Згідно з Федеральним законом від 30.12.2008 №307-ФЗ «Про аудиторську діяльність», аудит - це «незалежна перевірка бухгалтерської (фінансової) звітності особи, яка аудується, з метою висловлення думки про достовірність такої звітності». До інформаційної безпеки цей термін, згаданий у цьому законі, не має відношення. Проте так уже склалося, що фахівці з інформаційної безпеки досить активно його використовують у своїй промові. І тут під аудитом розуміється процес незалежної оцінки діяльності організації, системи, процесу, проекту чи продукту. У той же час треба розуміти, що в різних вітчизняних нормативних актах термін «аудит інформаційної безпеки» застосовується не завжди – його часто замінюють або термін «оцінка відповідності», або трохи застарілий, але все ще вживаний термін «атестація». Іноді ще застосовується термін «сертифікація», але стосовно міжнародних закордонних нормативних актів.

Аудит інформаційної безпеки проводиться або з метою перевірки виконання нормативних актів, або з метою перевірки обґрунтованості та захищеності застосовуваних рішень.

Але який би термін не використовувався, по суті, аудит інформаційної безпеки проводиться або для перевірки виконання нормативних актів, або з метою перевірки обґрунтованості та захищеності застосовуваних рішень. У другому випадку аудит має добровільний характер, і рішення про його проведення приймається організацією. У першому ж випадку відмовитися від проведення аудиту неможливо, оскільки це тягне за собою порушення встановлених нормативними актами вимог, що призводить до покарання у вигляді штрафу, зупинення діяльності або інших форм покарання.
У разі обов'язковості аудиту він може проводитися як самою організацією, наприклад, у формі самооцінки (щоправда, у цьому випадку про «незалежність» вже не йдеться і термін «аудит» застосовувати тут не зовсім правильно), так і зовнішніми незалежними організаціями - аудиторами. Третій варіант проведення обов'язкового аудиту - контроль із боку регулюючих органів, наділених правом здійснювати відповідні наглядові заходи. Цей варіант найчастіше називається не аудитом, а інспекційною перевіркою.
Так як добровільний аудит може проводитися абсолютно з будь-якого приводу (для перевірки захищеності системи ДБО, контролю активів придбаного банку, перевірки філії, що знову відкривається, тощо), то даний варіант розглядати не будемо. В цьому випадку неможливо ні чітко окреслити його межі, ні описати форми його звітності, ні говорити про регулярність - все це вирішується договором між аудитором та організацією, що перевіряється. Тому розглянемо лише форми обов'язкового аудиту, властиві саме банкам.

Міжнародний стандарт ISO 27001

Іноді можна почути про проходження тим чи іншим банком аудиту на відповідність вимогам міжнародного стандарту ISO/IEC 27001:2005 (його повний російський аналог - ГОСТ Р ИСО/МЭК 27001-2006 - Інформаційна технологія - Методи та засоби безпеки. інформаційної безпеки – Вимоги»). По суті, цей стандарт - це набір найкращих практик з управління інформаційною безпекою у великих організаціях (невеликі організації, зокрема й банки, який завжди може виконати вимоги цього стандарту повному обсязі).
Як і будь-який стандарт у Росії, ISO 27001 – суто добровільний документ, приймати який чи не приймати вирішує кожен банк самостійно. Але ISO 27001 є стандартом де-факто по всьому світу, і фахівці багатьох країн використовують цей стандарт як універсальну мову, якою слід керуватися, займаючись інформаційною безпекою.

З ISO 27001 пов'язані і кілька не найбільш очевидних моментів, що не часто згадуються.

Однак з ISO 27001 пов'язані і кілька не найочевидніших моментів, що не часто згадуються. По-перше, аудиту за цим стандартом підлягає не вся система забезпечення інформаційної безпеки банку, а лише одна або кілька її складових частин. Наприклад, система захисту ДПВ, система захисту головного офісу банку або система захисту процесу управління персоналом. Іншими словами, отримання сертифіката відповідності на один із оцінюваних у рамках аудиту процесів не дає гарантії, що інші процеси знаходяться в такому ж близькому до ідеального стану. Другий момент пов'язаний з тим, що ISO 27001 є універсальним стандартом, тобто застосовним до будь-якої організації, а значить, не враховує специфіку тієї чи іншої галузі. Це призвело до того, що в рамках міжнародної організації стандартизації ISO вже давно ведуться розмови про створення стандарту ISO 27015, який є перекладом ISO 27001/27002 на фінансову галузь. У створенні цього стандарту активну участь бере і Банк Росії. Однак Visa та MasterCard проти проекту цього стандарту, який уже розроблено. Перша вважає, що проект стандарту містить надто мало потрібної для фінансової галузі інформації (наприклад, платіжних систем), а якщо її туди додати, то стандарт треба переносити в інший комітет ISO. MasterCard також пропонує припинити розробку ISO 27015, але мотивація інша – мовляв, у фінансовій галузі і так повно регулюючих тему інформаційної безпеки документів. По-третє, необхідно звертати увагу, що багато пропозицій, що зустрічаються на російському ринку, говорять не про аудит відповідності, а про підготовку до аудиту. Справа в тому, що право проводити сертифікацію відповідності вимогам ISO 27001 має лише кілька організацій у світі. Інтегратори ж лише допомагають компаніям виконати вимоги стандарту, які потім будуть перевірені офіційними аудиторами (їх ще називають реєстраторами, органами із сертифікації тощо).
Поки тривають суперечки про те, чи впроваджувати банкам ISO 27001 чи ні, окремі сміливці йдуть на це і проходять 3 стадії аудиту відповідності:

• Попереднє неформальне вивчення аудитором основних документів (як біля замовника аудиту, і поза нею).
• Формальний та глибший аудит впроваджених захисних заходів, оцінка їх ефективності та вивчення розроблених необхідних документів. Цим етапом зазвичай закінчується підтвердження відповідності і аудитор видає відповідний сертифікат, визнаний у всьому світі.
• Щорічне виконання інспекційного аудиту на підтвердження раніше отриманого сертифіката відповідності.

Кому ж потрібен ISO 27001 у Росії? Якщо розглядати цей стандарт не тільки як набір кращих практик, які можна впроваджувати і без проходження аудиту, але і як процес сертифікації, що знаменує підтвердження відповідності банку міжнародним визнаним вимогам з безпеки, то ISO 27001 має сенс впроваджувати або банкам, що входять в міжнародні банківські групи , Де ISO 27001 є стандартом, або банкам, які планують вихід на міжнародну арену. В інших випадках аудит відповідності ISO 27001 та отримання сертифікату, на мій погляд, не потрібне. Але тільки для банку і лише у Росії. А все тому, що ми маємо свої стандарти, побудовані на базі ISO 27001.

Де-факто інспекційні перевірки Банку Росії проводилися донедавна саме відповідно до вимог СТО БР ІХБС

Комплекс документів Банку Росії СТО БР ІББС

Таким стандартом, а точніше набором стандартів, є комплекс документів Банку Росії, що описує єдиний підхід до побудови системи забезпечення ІБ організацій банківської сфери з урахуванням вимог законодавства. В основі даного набору документів (далі СТО БР ІББС), що містить три стандарти та п'ять рекомендацій щодо стандартизації, лежить і ISO 27001 та низка інших міжнародних стандартів з управління інформаційними технологіями та інформаційною безпекою.
Питання аудиту та оцінки відповідності вимогам стандарту, як і для ISO 27001, прописані в окремих документах – «СТО БР ІББС-1.1-2007. Аудит інформаційної безпеки», «СТО БР ІББС-1.2-2010. Методика оцінки відповідності інформаційної безпеки організацій банківської системи Російської Федерації вимогам СТО БР ІББС-1.0-2010» та «РС БР ІББС-2.1-2007. Посібник із самооцінки відповідності інформаційної безпеки організацій банківської системи Російської Федерації вимогам СТО БР ІББС-1.0».
Під час оцінки відповідності за СТО БР ІХС перевіряється виконання 423 приватних показників ІБ, згрупованих у 34 групових показники. Результатом оцінки є підсумковий показник, який має перебувати на 4-му чи 5-му рівні за п'ятибальною шкалою, встановленою Банком Росії. Це, до речі, дуже сильно відрізняє аудит з СТО БР ІХС від аудиту за іншими нормативними актами в області ІБ. У СТО БР ІХБС не буває невідповідності, просто рівень відповідності може бути різним: від нуля до п'яти. І лише рівні вище 4-го вважаються позитивними.
Станом на кінець 2011 року близько 70–75% банків запровадили чи перебувають у процесі впровадження цього набору стандартів. Незважаючи ні на що вони де-юре мають рекомендаційний характер, але де-факто інспекційні перевірки Банку Росії проводилися донедавна саме відповідно до вимог СТО БР ІХБС (хоча явно це ніколи і ніде не звучало).
Ситуація змінилася з 1 липня 2012 року, коли на повну силу набув чинності закон «Про національну платіжну систему» ​​та розроблені для його виконання нормативні документи Уряду Росії та Банку Росії. З цього моменту питання необхідності проведення аудиту відповідності вимогам СТО БР ІХБС знову постало на порядку денному. Справа в тому, що методика оцінки відповідності, запропонована в рамках законодавства про національну платіжну систему (НПС), та методика оцінки відповідності СТО БР ІХБС можуть дуже сильно розходитися у підсумкових значеннях. При цьому оцінка за першою методикою (для НПС) стала обов'язковою, тоді як оцінка за СТО БР ІХБС, як і раніше, де-юре носить рекомендаційний характер. Та й у самому Банку Росії на момент написання статті ще не було ухвалено рішення про подальшу долю цієї оцінки. Якщо раніше всі нитки сходилися до Головного управління безпеки та захисту інформації Банку Росії (ГУБЗІ), то з поділом повноважень між ГУБЗІ та Департаментом регулювання розрахунків (LHH) питання поки що залишається відкритим.

Вже зараз ясно, що законодавчі акти про НПС потребують обов'язкової оцінки відповідності, тобто аудиту

Законодавство про національну платіжну систему

Законодавство про НПС знаходиться лише на зорі свого становлення, і на нас чекає чимало нових документів, у тому числі й з питань забезпечення інформаційної безпеки. Але вже зараз ясно, що випущене та затверджене 9 червня 2012 року Положення 382-П «Про вимоги до забезпечення захисту інформації при здійсненні переказів грошових коштів та про порядок здійснення Банком Росії контролю за дотриманням вимог до забезпечення захисту інформації при здійсненні переказів грошових коштів » вимагає у п.2.15 обов'язкової оцінки відповідності, тобто аудиту. Така оцінка здійснюється або самостійно, або із залученням сторонніх організацій. Як уже сказано вище, оцінка відповідності, що проводиться в рамках 382-П, схожа за своєю суттю на те, що описано в методиці оцінки відповідності СТО БР ІХБС, але видає зовсім інші результати, що пов'язано з введенням спеціальних коригувальних коефіцієнтів, які і визначають різні результати.
Жодних особливих вимог до організацій, що залучаються для аудиту, положення 382-П не встановлює, що вступає в деяку суперечність з Постановою Уряду від 13 червня 2012 року №584 «Про захист інформації в платіжній системі», яка також вимагає організації та проведення контролю та оцінки виконання вимог до захисту інформації один раз на 2 роки. Однак Постанова Уряду, розроблена ФСТЕК, вимагає, щоб зовнішній аудит проводився лише організаціями, які мають ліцензію на діяльність з технічного захисту конфіденційної інформації.
Додаткові вимоги, які складно віднести до однієї з форм аудиту, але які накладають на банки нові обов'язки, наведені в розділі 2.16 Положення 382-П. Відповідно до цих вимог оператор платіжних систем зобов'язаний розробити, а банки, які приєдналися до цієї платіжної системи, зобов'язані виконувати вимоги щодо регулярного інформування оператора платіжної системи про різні питання інформаційної безпеки в банку: про виконання вимог щодо захисту інформації, про виявлені інциденти, про проведені самооцінки , про виявлені погрози та вразливості.
Додатково до аудиту, що проводиться на договірній основі, ФЗ-161 про НПС також встановлює, що контроль та нагляд за виконанням вимог, встановлених Урядом Російської Федерації у 584-й Постанові та Банком Росії у 382-му Положенні, здійснюються ФСБ ФСТЕК та Банком Росії відповідно . На момент написання статті ні ФСТЕК, ні ФСБ не мали розробленого порядку проведення такого нагляду на відміну від Банку Росії, який випустив Положення від 31 травня 2012 року №380-П «Про порядок здійснення спостереження в національній платіжній системі» (для кредитних організацій) та Положення від 9 червня 2012 року №381-П «Про порядок здійснення нагляду за дотриманням не є кредитними організаціями операторами платіжних систем, операторами послуг платіжної інфраструктури вимог Федерального Закону від 27 червня 2011 року № 161-ФЗ «Про національну платіжну систему», прийнятих відповідно до ним нормативних актів Банку Росії».
Нормативні акти у сфері захисту у національній платіжної системі перебувають лише на початку докладної розробки. З 1 липня 2012 року Банк Росії розпочав їх апробацію та збирання фактів із правозастосовчої практики. Тому сьогодні передчасно говорити про те, як застосовуватимуться ці нормативні акти, як проводитиметься нагляд за 380-П, які висновки робитимуться за підсумками самооцінки, що проводиться раз на 2 роки і надсилається до Банку Росії.

Стандарт безпеки платіжних карток PCI DSS

Payment Card Industry Data Security Standard (PCI DSS) - стандарт безпеки даних платіжних карток, розроблений Радою стандартів безпеки індустрії платіжних карток (Pys Card Industry Security Standards Council, PCI SSC), який був заснований міжнародними платіжними системами Visa, MasterCard, American Express, JCB та Discover. Стандарт PCI DSS являє собою сукупність 12 високорівневих та понад 200 детальних вимог щодо забезпечення безпеки даних про власників платіжних карток, які передаються, зберігаються та обробляються в інформаційних системах організацій.

Вимоги стандарту поширюються на всі компанії, що працюють із міжнародними платіжними системами Visa та MasterCard. Залежно від кількості транзакцій, що обробляються, кожній компанії присвоюється певний рівень з відповідним набором вимог, які ці компанії повинні виконувати. Ці рівні відрізняються залежно від платіжної системи.

Успішне проходження аудиту ще не означає, що з безпекою в банку все добре - існує безліч хитрощів, що дозволяють організації, що перевіряється, приховати якісь недоліки в своїй системі захисту

Перевірка виконання вимог стандарту PCI DSS здійснюється у межах обов'язковоюсертифікації, вимоги до якої відрізняються залежно від типу компанії, що перевіряється - торгово-сервісне підприємство, що приймає платіжні картки за оплату товарів і послуг, або постачальник послуг, що надає послуги торгово-сервісним підприємствам, банкам-еквайєрам, емітентам тощо. (процесингові центри, платіжні шлюзи тощо). Така оцінка може здійснюватися у різних формах:

• щорічні аудиторські перевірки за допомогою акредитованих компаній, які мають статус Qualified Security Assessors (QSA);
• щорічне проведення самооцінки;
• щоквартальне сканування мереж за допомогою уповноважених організацій, що мають статус Approved Scanning Vendor (ASV).

Законодавство про персональні дані

Останній нормативний документ, який також має відношення до банківської індустрії та встановлює вимоги щодо оцінки відповідності, - Федеральний закон «Про персональні дані». Однак ні форма такого аудиту, ні його періодичність, ні вимоги до організації, яка проводить такий аудит, поки що не встановлено. Можливо, це питання буде зняте восени 2012 року, коли вийде чергова порція документів Уряду РФ, ФСТЕК та ФСБ, які вводять нові нормативи у сфері захисту персональних даних. Поки що ж банки можуть спати спокійно і самостійно визначати особливості аудиту питань захисту персональних даних.
Контроль та нагляд за виконанням організаційних та технічних заходів щодо забезпечення безпеки персональних даних, встановлених 19-ю статтею 152-ФЗ, здійснюються ФСБ та ФСТЕК, але тільки для державних інформаційних систем персональних даних. Контроль комерційних організацій у сфері забезпечення інформаційної безпеки персональних даних поки що здійснювати за законом нема кому. Чого не скажеш про питання захисту прав суб'єктів персональних даних, тобто клієнтів, контрагентів та просто відвідувачів банку. Це завдання взяв він Роскомнагляд, який дуже активно здійснює свої наглядові функції і вважає банки одними із злісних порушників закону про персональні дані.

Заключні положення

Вище розглянуто основні нормативні акти у сфері інформаційної безпеки щодо кредитних організацій. Цих нормативних актів чимало, і кожен із них встановлює свої вимоги щодо проведення оцінки відповідності у тій чи іншій формі - від самооцінки у вигляді заповнення опитувальних листів (PCI DSS) до проходження обов'язкового аудиту один раз на два роки (382-П) або один раз на рік (ІSO 27001). Між цими найпоширенішими формами оцінки відповідності є й інші – повідомлення оператора платіжної системи, щоквартальне сканування тощо.

Варто також пам'ятати та розуміти, що в країні досі відсутня єдина система поглядів не лише на державне регулювання процесів аудиту інформаційної безпеки організацій та систем інформаційних технологій, а й узагалі саму тему аудиту інформаційної безпеки. У Російській Федерації існує ціла низка відомств та організацій (ФСТЕК, ФСБ, Банк Росії, Роскомнагляд, PCI SSC тощо), відповідальних за інформаційну безпеку. І всі вони діють на підставі власних нормативних документів і посібників. Різні підходи, різні стандарти, рівні зрілості… Все це заважає встановленню єдиних правил гри. Картину псує і поява фірм-одноденок, які в гонитві за прибутком пропонують дуже неякісні послуги з оцінки відповідності вимогам з інформаційної безпеки. І на краще ситуація навряд чи зміниться. Якщо є потреба, то будуть і охочі її задовольнити, тоді як на всіх кваліфікованих аудиторів просто не вистачить. При невеликому їх числі (показано в таблиці) та тривалості аудиту від кількох тижнів до кількох місяців очевидно, що потреби в аудиті значно перевищують можливості аудиторів.
У так і не прийнятій ФСТЕК «Концепції аудиту інформаційної безпеки систем інформаційних технологій та організацій» була така фраза: «у той же час у відсутності необхідних національних регуляторів така діяльність /за нерегульованим законодавством аудиту з боку приватних фірм/ може завдати непоправної шкоди організаціям». На закінчення автори Концепції пропонували уніфікувати підходи до аудиту та законодавчо встановити правила гри, включаючи правила акредитації аудиторів, вимоги до їх кваліфікації, процедури проведення аудиту тощо, але віз і нині там. Хоча, враховуючи ту увагу, яку вітчизняні регулятори в галузі інформаційної безпеки (а у нас їх 9) приділяють питанням захисту інформації (тільки за минулий календарний рік було прийнято або розроблено 52 нормативні акти з питань інформаційної безпеки – один нормативний акт на тиждень!), не виключаю, що до цієї теми незабаром знову повернуться.

СТАНДАРТИ АУДИТУ ІНФОРМАЦІЙНОЇ БЕЗПЕКИ

У таких умовах, на жаль, доводиться визнавати, що основна мета аудиту інформаційної безпеки банку – підвищення довіри до його діяльності – у Росії недосяжна. У нас мало хто з клієнтів банку звертає увагу на рівень його безпеки або результати проведеного в банку аудиту. До аудиту у нас звертаються або у разі виявлення дуже серйозного інциденту, що призвів до завдання серйозних матеріальних збитків банку (або його акціонерам та власникам), або у разі законодавчих вимог, яких у нас, як було показано вище, чимало. І на найближчі півроку вимогою №1, заради якої варто звернути увагу на аудит безпеки, є положення Банку Росії 382-П. Вже є перші прецеденти запиту з боку територіальних управлінь ЦП відомостей про рівень захищеності банків та виконання вимог 382-П, а виходять ці відомості саме внаслідок зовнішнього аудиту чи проведеної самооцінки. На друге місце я поставив би аудит виконання вимог закону «Про персональні дані». Але проводити такий аудит варто не раніше весни, коли буде випущено всі обіцяні ФСТЕК та ФСБ документи і коли стане зрозумілою доля СТО БР ІББС. Тоді ж можна буде порушити питання проведення аудиту відповідності вимогам СТО БР ІББС. Вже стане зрозумілим не тільки майбутнє комплексу документів Банку Росії, але і його статус по відношенню до схожого, але все-таки відмінного 382-П, а також, як і раніше, СТО БР ІББС буде покривати питання захисту персональних даних.
Успішне проходження аудиту ще не означає, що з безпекою в банку все добре - існує безліч хитрощів, що дозволяють організації, що перевіряється, приховати якісь недоліки в своїй системі захисту. Та й від кваліфікації та незалежності аудиторів залежить дуже багато. Досвід минулих років показує, що навіть в організаціях, які успішно пройшли аудит відповідності стандартам PCI DSS, ISO 27001 або СТО БР ІХБС, бувають інциденти та інциденти серйозні.

Багато бізнесменів намагаються зберегти секрет своєї фірми таємно. Так як на подвір'ї повік високих технологій, зробити це досить складно. Практично всі намагаються убезпечити себе від витоку корпоративної та особистої інформації, проте не секрет, що професіоналу не важко дізнатися необхідні дані. На даний момент існує досить багато методів, що захищають від таких атак. Але щоб перевірити ефективність роботи такої охоронної системи, потрібне проведення аудиту інформаційної безпеки.

Що таке аудит?

Відповідно до ФЗ «Про аудиторську діяльність», аудит включає різні методи і методи, і навіть практичне виконання перевірок. Щодо інформаційної безпеки підприємства він є незалежною оцінкою стану системи, а також рівень її відповідності встановленим вимогам. Експертизи проводяться щодо бухгалтерської та податкової звітності, економічного забезпечення та фінансово-господарської діяльності.

Навіщо потрібна така перевірка?

Деякі вважають таку діяльність марною витратою коштів. Проте, своєчасно визначивши проблеми у цьому секторі, можна запобігти ще більшим економічним втратам. Цілі аудиту інформаційної безпеки полягають у наступному:

• визначення рівня захисту та доведення його до необхідного;
• врегулювання фінансового питання щодо забезпечення конфіденційності організації;
• демонстрація доцільності вкладень у цей сектор;
• отримання максимальної вигоди від витрат за безпеку;
• підтвердження ефективності внутрішніх сил, засобів контролю та їх відображення на веденні підприємницької діяльності.

Як здійснюється перевірка інформаційної безпеки на підприємстві?

Комплексний аудит інформаційної безпеки відбувається у кілька етапів. Процес поділяється на організаційний та інструментарний. В рамках обох частин комплексу відбувається дослідження захищеності корпоративної інформаційної системи замовника, а потім – визначення відповідності встановленим нормам та вимогам. Проведення аудиту інформаційної безпеки поділяється на такі стадії:

1. Визначення вимог замовника та об'єму робіт, що виконується.
2. Вивчення необхідних матеріалів та винесення висновків.
3. Аналіз можливих ризиків.
4. Експертний висновок щодо виконаної роботи та винесення відповідного вердикту.

Що входить до першого етапу аудиту інформаційної безпеки?

Програма аудиту інформаційної безпеки починається саме з уточнення обсягу робіт, які потрібні замовнику. Клієнт висловлює свою думку та мету, переслідуючи яку він і звернувся для проведення експертної оцінки.

На цій стадії починається перевірка загальних даних, які надає замовник. Йому описують методи, які будуть використані, і комплекс заходів, що планується.

Головним завданням цьому етапі є постановка конкретної мети. Клієнт та організація, що проводить аудит, повинні розуміти один одного, зійтися в єдиній думці. Після цього формується комісія, до складу якої підбираються відповідні фахівці. Із замовником окремо узгоджується також необхідне технічне завдання.

Здавалося б, цей захід має лише загалом описати стан системи, що захищає від інформаційних атак. Але кінцеві результати перевірки можуть бути різними. Одних цікавить повна інформація про роботу захисних засобів фірми замовника, а інших лише ефективність роботи окремих інформаційно-технологічних ліній. Саме від вимог і залежить вибір методів та засобів проведення оцінки. Постановка мети впливає і подальший хід роботи експертної комісії.

До речі, робоча група складається з фахівців двох організацій - фірми, яка виконує аудит, та співробітників організації, що перевіряється. Адже саме останні, як ніхто інший, знають тонкощі своєї установи та можуть надати всю необхідну для комплексної оцінки інформацію. Також вони проводять своєрідний контроль роботи співробітників фірми-виконавця. Їхня думка враховується і при винесенні результатів перевірки.

Експерти фірми, яка проводить аудит інформаційної безпеки підприємства, займаються дослідженням предметних галузей. Вони, маючи відповідний кваліфікаційний рівень, а також незалежну та неупереджену думку, здатні з більшою точністю оцінити стан роботи захисних засобів. Експерти ведуть свою діяльність відповідно до наміченого плану робіт та поставлених завдань. Вони розробляють технічні процеси та узгоджують між собою отримані результати.

Технічне завдання чітко фіксує мету роботи компанії-аудитора, визначає методи його здійснення. У ньому також прописані терміни проведення перевірки, можливо навіть, що кожен етап матиме свій період.

На цій стадії відбувається налагодження контакту та зі службою безпеки установи, що перевіряється. Фірма-аудитор зобов'язання про нерозголошення отриманих результатів перевірки.

Як відбувається реалізація другого етапу?

Аудит інформаційної безпеки підприємства на другій стадії є розгорнутим збиранням необхідної для оцінки інформації. Спочатку розглядається загальний комплекс заходів, спрямованих на реалізацію політики конфіденційності.

Оскільки нині більшість даних дублюється в електронному варіанті чи взагалі свою діяльність фірма здійснює лише з допомогою інформаційних технологій, під перевірку потрапляють і програмні засоби. Аналізується та забезпечення фізичної безпеки.

На цьому етапі фахівці займаються тим, що розглядають та оцінюють те, як відбувається забезпечення та аудит інформаційної безпеки всередині установи. Для цього аналізу піддається організація роботи системи захисту, а також технічні можливості та умови її забезпечення. Останньому пункту приділяється особлива увага, оскільки шахраї найчастіше знаходять пробоїни у захисті саме через технічну частину. З цієї причини окремо розглядаються такі моменти:

• структура програмного забезпечення;
• конфігурація серверів та мережевих пристроїв;
• механізми забезпечення конфіденційності.

Аудит інформаційної безпеки підприємства на цьому етапі завершується підбиттям підсумків та вираженням результатів про виконану роботу у формі звіту. Саме документально оформлені висновки лягають основою реалізації наступних стадій аудиту.

Як аналізуються можливі ризики?

Аудит інформаційної безпеки організацій проводиться також з метою виявлення реальних загроз та їх наслідків. Після закінчення цього етапу має сформуватися перелік заходів, які дозволять уникнути чи хоча б мінімізувати можливість інформаційних атак.

Щоб запобігти порушенням конфіденційності, необхідно проаналізувати звіт, отриманий наприкінці попереднього етапу. Завдяки цьому можна визначити, чи можливе реальне вторгнення у простір фірми. Виноситься вердикт про надійність та працездатність діючих технічних захисних засобів.

Оскільки всі організації мають різні напрями роботи, то й перелік вимог до безпеки може бути ідентичний. Для установи, що перевіряється, розробляється список в індивідуальному порядку.

На цьому етапі також визначаються слабкі місця, клієнту надаються дані про потенційних зловмисників і загрози, що нависають. Останнє необхідно для того, щоб знати, з якого боку чекати каверзи, і приділити цьому більше уваги.

Замовнику також важливо знати, наскільки дієвими будуть нововведення та результати роботи експертної комісії.

Аналіз можливих ризиків має такі цели:

• класифікація джерел інформації;
• визначення уразливих моментів робочого процесу;
• складання прототипу можливого шахрая.

Аналіз та аудит дозволяють визначити, наскільки можлива успішність інформаційних атак. Для цього оцінюється критичність слабких місць та способи користування ними з незаконною метою.

У чому останній етап аудиту?

Завершальна стадія характеризується письмовим оформленням результатів роботи. Документ, що виходить на виході, називається аудиторським звітом. Він закріплює висновок про загальний рівень захищеності фірми, що перевіряється. Окремо йде опис ефективності роботи інформаційно-технологічної системи щодо безпеки. Звіт дає вказівки про потенційні загрози, описує модель можливого зловмисника. Також у ньому прописуються можливості несанкціонованого вторгнення за рахунок внутрішніх та зовнішніх факторів.

Стандарти аудиту інформаційної безпеки передбачають не лише оцінку стану, а й надання рекомендацій експертній комісії на проведення необхідних заходів. Саме фахівці, які провели комплексну роботу, проаналізували інформаційну інфраструктуру, можуть сказати, що необхідно робити для того, щоб захиститись від крадіжки інформації. Вони вкажуть на ті місця, які треба посилити. Експерти дають вказівки щодо технологічного забезпечення, тобто обладнання, серверів і міжмережевих екранів.

Рекомендації є тими змінами, які необхідно зробити у конфігурації мережевих пристроїв та серверів. Можливо, вказівки стосуватимуться безпосередньо обраних методів безпеки. Якщо це потрібно, експерти пропишуть комплекс заходів, спрямованих на додаткове посилення механізмів, що забезпечують захист.

У компанії також має бути проведено спеціальну роз'яснювальну роботу, вироблено політику, спрямовану на конфіденційність. Можливо, мають бути проведені реформи щодо служби безпеки. Важливим моментом є і нормативно-технічна база, яка має закріплювати положення про безпеку фірми. Колектив необхідно проінструктувати належним чином. Між усіма працівниками діляться сфери впливу та покладена відповідальність. Якщо це доцільно, то краще провести курс підвищення освіченості колективу щодо інформаційної безпеки.

Які види аудиту?

Аудит інформаційної безпеки підприємства може мати два види. Залежно від джерела здійснення цього процесу можна виділити такі типи:

1. Зовнішня форма. Вона відрізняється тим, що має одноразовий характер. Другий її особливістю і те, що виробляється вона у вигляді незалежних і неупереджених експертів. Якщо вона має рекомендаційний характер, то проводиться на замовлення власника установи. У деяких випадках проведення зовнішнього аудиту є обов'язковим. Це може бути обумовлено типом організації та надзвичайними обставинами. В останньому випадку ініціаторами подібної перевірки зазвичай стають правоохоронні органи.
2. Внутрішня форма. Вона ґрунтується на спеціалізованому положенні, яке прописує ведення аудиту. Внутрішній аудит інформаційної безпеки потрібний для того, щоб постійно проводити моніторинг системи та виявляти вразливі місця. Він є переліком заходів, які проводяться у встановлений період часу. Для цієї роботи найчастіше засновано спеціальний відділ або уповноважений співробітник. Він проводить діагностику стану захисних засобів.

Як проводиться активний аудит?

Залежно від того, яку мету має замовник, обираються і методи аудиту інформаційної безпеки. Одним із найпоширеніших способів дослідження рівня захищеності є активний аудит. Він є постановкою реальної хакерської атаки.

Плюсом такого методу є те, що дозволяє максимально реалістично змоделювати можливість загрози. Завдяки активному аудиту можна зрозуміти, як розвиватиметься аналогічна ситуація у житті. Такий метод ще називають інструментальним аналізом безпеки.

Суть активного аудиту полягає у здійсненні (за допомогою спеціального програмного забезпечення) спроби несанкціонованого вторгнення до інформаційної системи. При цьому захисні засоби повинні знаходитись у стані повної готовності. Завдяки цьому можна оцінити їхню роботу в такому випадку. Людині, яка здійснює штучну атаку хакерів, надається мінімум інформації. Це потрібно для того, щоб відтворити максимально реалістичні умови.

Систему намагаються піддати якомога більшій кількості атак. Застосовуючи різні методи, можна оцінити ті способи злому, яким система найбільш схильна. Це, звичайно, залежить від кваліфікації фахівця, який проводить цю роботу. Але його дії не повинні мати будь-якого деструктивного характеру.

Зрештою експерт формує звіт про слабкі місця системи та відомості, які є найбільш доступними. Він також надає рекомендації щодо можливої ​​модернізації, яка має гарантувати підвищення захищеності до належного рівня.

У чому полягає експертний аудит?

Щоб визначити відповідність фірми встановленим вимогам, також проводиться аудит інформаційної безпеки. Приклад такого завдання можна побачити у експертному методі. Він полягає у порівняльній оцінці з вихідними даними.

Та сама ідеальна робота засобів захисту може ґрунтуватися на різних джерелах. Пред'являти вимоги та ставити завдання може і сам клієнт. Керівник фірми, можливо, бажає знати, наскільки далеко знаходиться рівень безпеки організації від бажаного.

Прототипом, щодо якого буде проведено порівняльну оцінку, можуть бути і загальновизнані світові стандарти.

Відповідно до ФЗ «Про аудиторську діяльність», фірма-виконавець має достатньо повноважень для того, щоб зробити збір відповідної інформації та зробити висновок про достатність існуючих заходів щодо забезпечення інформаційної безпеки. Оцінюється також несуперечність нормативних документів та дій співробітників щодо роботи засобів захисту.

У чому полягає перевірка на відповідність стандартам?

Цей вид дуже схожий з попереднім, оскільки його суттю також порівняльна оцінка. Але в цьому випадку ідеальним прототипом є не абстрактне поняття, а чіткі вимоги, закріплені в нормативно-технічній документації та стандартах. Однак тут також визначається ступінь відповідності до рівня, заданого політикою конфіденційності компанії. Без відповідності цьому моменту не можна говорити про подальшу роботу.

Найчастіше подібний вид аудиту необхідний для сертифікації системи безпеки, що діє на підприємстві. Для цього потрібна думка незалежного експерта. Тут важливий як рівень захисту, а й його задоволеність визнаними стандартами якості.

Отже, можна дійти невтішного висновку, що з проведення такого роду процедури необхідно визначитися з виконавцем, і навіть виділити коло цілей і завдань з власних потреб і повноважень.

Збір, обробка, зберігання та використання персональних даних здійснюються у багатьох сферах діяльності суспільства та держави. Наприклад, у фінансовій та податковій сфері, при пенсійному, соціальному та медичному страхуванні, в оперативно-розшуковій діяльності, трудовій та інших сферах суспільного життя.

У різних сферах діяльності під персональними даними розуміються набори відомостей, що часто не збігаються. Визначення персональних даних містяться у різних федеральних законах, причому обсяг відомостей визначається них по-різному.

З розвитком інформаційних технологій все більшого значення набуває захист комерційної інформації, що дозволяє компанії підтримувати конкурентоспроможність своїх товарів, організовувати роботу з партнерами та клієнтами, знижувати ризики виникнення санкцій з боку регуляторів.

Захистити комерційну таємницю компанії та притягнути винних у розголошенні до відповідальності можливо, запровадивши режим комерційної таємниці, тобто вживши правові, організаційні та технічні заходи щодо охорони конфіденційності інформації.

На сьогоднішній день вірусні атаки, як і раніше, відбуваються з лякаючою частотою. Найефективнішими є атаки, які здійснюються з використанням файлів, що відкриваються звичайними програмами. Наприклад, шкідливий код може міститися у файлах Microsoft Word або PDF-документах. Така атака називається експлойтом і не визначається звичайним антивірусом.

Palo Alto Networks Traps забезпечує розширений захист робочих станцій від цілеспрямованих шкідливих атак, запобігає експлуатації вразливостей операційної системи та додатків.

Рекомендації щодо захисту інформації при роботі в системах ДПВ

Останнім часом почастішали випадки шахрайських дій у системах дистанційного банківського обслуговування (ДБО), спрямовані на розкрадання секретних ключів користувачів та коштів організацій. У статті ми розглянули практичні заходи, необхідні для зниження ймовірності крадіжки коштів та навели рекомендації щодо реагування на можливі шахрайські дії.