Полезное:
Как сделать разговор полезным и приятным
Как сделать объемную звезду своими руками
Как сделать то, что делать не хочется?
Как сделать погремушку
Как сделать так чтобы женщины сами знакомились с вами
Как сделать идею коммерческой
Как сделать хорошую растяжку ног?
Как сделать наш разум здоровым?
Как сделать, чтобы люди обманывали меньше
Вопрос 4. Как сделать так, чтобы вас уважали и ценили?
Как сделать лучше себе и другим людям
Как сделать свидание интересным?
Категории:
АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника
Можливість несанкціонованого одержання інформації під дією дестабілізуючих факторів, незважаючи на застосування засобів ЗІ Рij. 4 page
| 6.6.4 | 8.6.4 | Безпека системної документації | Чи захищена системна документація від НСД. Чи має список доступу до системної документації мінімальне число працівників | |
| 6.7 | 8.7 | Обмін інформацією і програмним забезпеченням | ||
| 6.7.1 | 8.7.1 | Угода про обмін інформацією і ПЗ | Чи існує формальна або неформальна угода між організаціями при обміні інформацією і ПЗ. Чи посилається угода на вимоги безпеки, базуючись на критичності інформації | |
| 6.7.2 | 8.7.2 | Безпека інформації під час транс-портування | Чи здійснюється безпека матеріальних носіїв інформації під час транспортування. Чи достатньо захищені носії інформації від НСД, невірного використання | |
| 6.7.3 | 8.7.3 | Безпека електронної комерції | Чи захищена електронна комерція від шахрайства, сумнівних контрактів, розголошення або модифікації інформації. Чи включає електронна комерція такі засоби забезпечення безпеки, як аутентифікація і авторизація. Чи урегульовані питання з торговими партнерами, тому числі вимоги по безпеці | |
| 6.7.4 | 8.7.4 | Безпека електронної пошти | Чи існує політика, дозволу використовувати електронну пошту і звернена увага у політики інформаційної безпеки використанню електронної пошти. Чи реалізовані такі засоби безпеки, як антивірусна перевірка тощо | |
| 6.7.5 | 8.7.5 | Безпека системи електронного офісу | Чи визначена політика допустимого використання системи електронного офісу. Чи існує керівництво по ефективної безпеці від ризиків, пов’язаних з використанням системи електронного офісу | |
| 6.7.6 | 8.7.6 | Загально доступні системи | Чи існує формалізований процес авторизації для інформації, яку необхідно зробити доступною суспільству. Чи існують засоби безпеки для забезпечення цілісності інформації, призначеної для загального використання, від несанкціонованого доступу Вони можуть включати такі засоби безпеки, як міжмережні екрани, засоби виявлення вторгнення тощо | |
| 6.7.7 | 8.7.7 | Інші форми обміну інформацією | Чи існує політика, процедури або засоби захисту безпеки інформації під час передачі за допомогою голосу, факсу і відео. Чи ознайомлені працівники про необхідність безпеки конфіденційної інформації | |
| Управління доступом | ||||
| 7.1 | 9.1 | Бізнес-вимоги по управлінню доступом | ||
| 7.1.1 | 9.1.1 | Політика управління доступом | Чи визначені і задокументовані бізнес-вимоги по управлінню доступом. Чи має політика управління доступом розроблені правила і права для кожного користувача або групи користувачів. Чи мають користувачі і постачальники сервісів чітке розуміння бізнес-вимог | |
| 7.2 | 9.2 | Управління доступом працівників | ||
| 7.2.1 | 9.2.1 | Реєстрація працівників | Чи існує формальна процедура обліку і відміни обліку працівників, враховуючи багато користувачеві ІС і сервіси | |
| 7.2.2 | 9.2.2 | Управління привілеями | Чи обмежено і контрольовані виділення та використання привілей у багатокориствацьких ІС, чи виділені привілеї тільки на основі принципу «необхідності використання» або тільки після формалізованого процесу авторизаціі | |
| 7.2.3 | 9.2.3 | Управління паролями | Розміщення і видалення паролів повинно контролюватися формальним процесам управління. Чи знають користувачі про необхідність збереження пароля у тайні | |
| 7.2.4 | 9.2.4 | Аудит прав доступу | Чи існує процес аудиту прав доступу користувачів через визначений час. Наприклад, спеціальні привілеї переглядаються один раз у три місяці, звичайні – кожні шість місяців | |
| 7.3 | 9.3 | Відповідальність працівників | ||
| 7.3.1 | 9.3.1 | Використання паролів | Чи існує керівництво користувача по вибору і зберіганню паролів | |
| 7.3.2 | 9.3.2 | Обладнання, яке працює у автономному режимі | Чи знають працівники і сумісники вимоги і процедури по захисту обладнання, яке працює в автономному режимі то відповідальності за забезпеченням безпеки. Наприклад, автономний вихід з системи |
Продовження таблиці 7.2
| 7.4 | 9.4 | Управління мереженим доступом | ||
| 7.4.1 | 9.4.1 | Політика використання мережених сервісів | Чи існує політика, яка висвітлює проблеми, пов’язані з мережею і мереженими сервісами, такими як: частини мережі, дозволу для доступу; сервіси авторизації, визначаючі, хто і що може робити; процедури безпеки доступу до мережних підключень і сервісів | |
| 7.4.2 | 9.4.2 | Обов’язковий маршрут | Чи існують який-небудь засоби безпеки, обмежуючи маршрут між терміналом користувачів і визначеними сервісами на ІС, до якої необхідно отримати доступ, наприклад, обов’язковий маршрут для зменшення ризику | |
| 7.4.3 | 9.4.3 | Аудентифікація працівників для доступу за межами мережі організації | Чи існує якийсь механізм аутентифікації для доступу за межами мережі організації. Наприклад: техніка заснована на криптографії, апаратні засоби ідентифікації, програмні засоби ідентифікації | |
| 7.4.4 | 9.4.4 | Аутентифікація вузлів | Чи аутентифіковані підключення до віддалених ІС, які знаходяться за межами управління безпекою організації. Аутентифікація вузлів може служити альтернативним засобом аутентифікації груп віддалених користувачів, коли вони підключаються до захищених ІС | |
| 7.4.5 | 9.4.5 | Безпека портів віддаленої діагностики | Чи контролюється доступ до портів віддаленої діагностики, чи захищені вони засобами безпеки | |
| 7.4.6 | 9.4.6 | Поділ мереж | Чи поділені мережі до яких потрібен доступ партнерів і сторонніх організацій, з використанням таких механізмів безпеки, як між мережні екрани | |
| 7.4.7 | 9.4.7 | Протоколи мережених з’єднань | Чи існують якісь засоби управління мереженими з’єднаннями для загальної мережі, які знаходяться за межами організації. Наприклад, електронна пошта, Web-доступ, FTP-доступ | |
| 7.4.8 | 9.4.8 | Управління мереженою маршрутиза-цією | Чи існують засоби захисту мережі, які гарантують, що з’єднання і інформаційні потоки не порушують політику контролю доступу бізнес-додатків. Це часто необхідно для мереж, які використовуються декель-кома організаціями одночасно. Чи базується керування маршрутизацією на механізму ідентифікації джерела і відправника. | |
| 7.4.9 | 9.4.9 | Безпека мережених сервісів | Чи впевнена організація, яка використовує загальні або часткові мереживі сервіси, що забезпечена чітким описом вимог безпеки до усіх сервісів | |
| 7.5 | 9.5 | Управління доступом у операційній системі | ||
| 7.5.1 | 9.5.1 | Автоматична ідентифікація терміналів | Чи використовується автоматичний механізм ідентифікації терміналів для аутентифікації з’єднань | |
| 7.5.2 | 9.5.2 | Процедури реєстрації на терміналі | Чи можливий доступ до ІС тільки через захищений процес обліку. Чи існує процедура обліку в ІС. Необхідно для мінімізації можливості НСД | |
| 7.5.3 | 9.5.3 | Ідентифікація і авторизація користувача | Чи представлені унікальні ідентифікатори усім користувачам, таким, як оператори та іншим допущеним працівникам. Загально обліковий запис може бути використано тільки у випадку виключних обставин, коли це є бізнес-перевагою. Додаткові засоби захисту можуть бути необхідними для забезпечення можливості ведення журналу. Чи реалізує використання методу аутентифікації, що необхідний для ідентифікації користувача. Загальний метод, яким користуються: пароль, який знає тільки користувач | |
| 7.5.4 | 9.5.4 | Система управління паролями | Чи існує система управління паролями, котра приводить в дію різні засоби управління паролями, такі, як індивідуальний пароль, примусова зміна пароля, зберігання пароля у зашифрованому вигляді, відключення показу пароля на екрані |
Продовження таблиці 7.2
| 7.5.5 | 9.5.5 | Використання системних утиліт | Чи контролюється доступ до системним утилітам, які поставляються з операційною системою і мають можливість зміни системи і додатків | |
| 7.5.6 | 9.5.6 | Аварійна система | Чи розглянуто забезпечення аварійного сигналу для користувачів | |
| 7.5.7 | 9.5.7 | Тайм-аут для терміналу | Чи сконфігуровано термінал для очистки екрану або автоматичного закриття після визначеного періоду без дії | |
| 7.5.8 | 9.5.8 | Обмеження часу з’єднання | Чи існує обмеження часу з’єднання на критичних додатках. Ця установка повинна бути розглянута для використання у критичних додатках | |
| 7.6 | 9.6 | Управління доступу до додатків | ||
| 7.6.1 | 9.6.1 | Обмеження доступу до інформації | Чи визначено доступ до додатків для різних груп і індивідуальних користувачів організації у політиці управління доступом згідно вимог конкретного бізнес-додатку і не порушують чи вони вимог політики доступу до інформації | |
| 7.6.2 | 9.6.2 | Ізолювання критичних систем | Чи забезпечені критичні системи виділеними обладнанням, таким, як спеціальний сервер | |
| 7.7 | 9.7 | Моніторинг доступу до систем і використання систем | ||
| 7.7.1 | 9.7.1 | Журнал повідомлення | Чи відбувається журнал важливих подій, у тому числі і по безпеки, з метою забезпечення проведення розслідувань і для моніторингу контролю доступу | |
| 7.7.2 | 9.7.2 | Моніторинг використання системи | Чи встановлена процедура по моніторингу використання інформаційних систем, Процедури повинні гарантувати, що користувачі використовують тільки ті дії, які авторизовані. Чи перевіряються результати моніторингу регулярно | |
| 7.7.3 | 9.7.3 | Синхронізація часу | Чи погоджено час ІС або пристрою з єдиним зовнішнім або внутрішнім джерелом часу. Вірне установлення часу важливо для забезпечення вірного аудиту журналів | |
| 7.8 | 9.8 | Праці поза офісу і мобільні користувачі | ||
| 7.8.1 | 9.8.1 | Ноутбуки | Чи враховується політика ризику, пов’язаною з роботою на ноутбуках, персональних цифрових системах, особливо у незахищених областях. Чи проводиться навчання працівників по використанню ноутбуків з метою підвищення усвідомленості про додаткові ризики, які пов’язані з такою роботою і засоби захисту, котрі необхідно реалізувати для зменшення ризику | |
| 7.8.2 | 9.8.2 | Робота поза офісу | Чи існує політика, процедура або стандарт який регулює порядок роботи поза офісом і чи погоджений він з політикою інформаційної безпеки організації. Чи передбачені відповідні засоби захисту від таких загроз, як крадіжка обладнання, несанкціоноване розголошення інформації | |
| Розробка і підтримання системи | ||||
| 8.1 | 10.1 | Вимоги безпеки по відношенню систем | ||
| 8.1.1 | 10.1.1 | Аналіз і специфікація вимог по безпеки | Чи оформлені вимоги безпеки так бізнес-вимоги для нових систем або при розширенні маючих систем. Вимоги і засоби безпеки повинні відображати цінність для бізнес інформаційних активів і наслідок недотримання вимог безпеки. Чи була проведена оцінка ризиків до прийняття рішення о розробці системи | |
| 8.2 | 10.2 | Безпека у додатках | ||
| 8.2.1 | 10.2.1 | Перевірка введеної інформації | Чи здійснюється перевірка введеної інформації на предмет коректності і достовірності. Чи реалізовані такі засоби безпеки, як різні види перевірок для аналізу повідомлень про помилки, процедури обліку на помилки, визначення обов’язків усіх працівників, пов’язаних з процесом введення даних | |
| 8.2.2 | 10.2.2 | Засоби захисту | Чи визначені ризики, що відносяться до циклу обробки |
Продовження таблиці 7.2
| при обробці інформації | інформації і перевірки помилок. У деяких випадках, які були коректно введені, можуть бути викривлення у результаті помилок при обробки або навмисні дії. Чи визначені відповідні засоби захисту для додатків по зменшенню ризиків, пов’язаних з внутрішню обробкою інформації. Засоби захисту будуть залежати від природи додатку і бізнес-впливі у випадку пошкодження інформації | |||
| 8.2.3 | 10.2.3 | Аутентифікація повідомлень | Чи була виконана оцінка ризиків безпеки по визначенню необхідності аутентифікації повідомлень: по визначені найбільш підходящого метода реалізації. Аутентифікація повідомлень – техніка, що використовується для визначення несакціонованих змін або викривлення змісту електронних повідомлень, що передаються | |
| 8.2.4 | 10.2.4 | Перевірка вихідних даних | Чи перевіряються результати роботи додатку для забезпечення корективності і відповідності обставин процесу обробки інформації | |
| 8.3 | 10.3 | Криптографічні засоби | ||
| 8.3.1 | 10.3.1 | Політика використання криптозасобів захисту | Чи існує політика використання криптографічних засобів захисту для забезпечення безпеки інформації. Чи виконана оцінка ризиків для визначення заданого рівня безпеки інформації | |
| 8.3.2 | 10.3.1 | Шифрування | Чи використовується технологія шифрування для забезпечення безпеки інформації. Чи проведено аналіз критичної інформації та визначені вимоги до рівня безпеки | |
| 8.3.3 | 10.3.3 | Електронно цифровий підпис | Чи використовується електронно цифровий підпис для безпеки аутентичності і цілісності електронного документа | |
| 8.3.4 | 10.3.4 | Сервіси невідмовності | Чи використовуються там, де це потрібною, сервіси невідновності для вирішення конфліктних ситуацій по визначенню, була чи дія або ні. Приклад: конфліктна ситуація, що включає використання електронного підпису у контрактах | |
| 8.3.5 | 10.3.5 | Управління ключами | Чи існує в організації система управління по підтримці симетричного і асиметричного шифрування. Чи базується система управління ключами на погоджених стандартах, процедурах і методах безпеки | |
| 8.4 | 10.4 | Захист системних файлів | ||
| 8.4.1 | 10.4.1 | Безпека ОС | Чи існують засоби безпеки на рівні операційної системи. Це мінімізує ризик порушення роботи ІС | |
| 8.4.2 | 10.4.2 | Безпека текстової системної документації | Чи захищена і контрольована текстова системна документація. Забороняється використання бази даних, що має персональні дані, для мети тестування. Якщо таку інформацію потрібно використовувати, дані повинні бути забезпечені | |
| 8.4.3 | 10.4.3 | Доступом до бібліотек завершених кодів програм | Чи існує строгий контроль доступу до бібліотек завершених кодів програм. Це зменшує ризики викривлення програм | |
| 8.5.1 | 10.5.1 | Процедури управління змінами | Чи існують процедури строгого контролю за змінами в інформаційних системах. Це мінімізує ризики по викривленню інформаційної системи | |
| 8.5.2 | 10.5.2 | Технічний аудит змін у операційній системі | Чи існує процес або процедура, яка гарантує, що додатки перевірені і опротестовані після змін у операційній системі. Необхідно періодично обновляти ОС, інсталювати службові програми, обновлення для додатків | |
| 8.5.3 | 10.5.3 | Обмеження на зміни у програмних пакетах | Чи існує обмеження по зміні пакетів програмного забезпечення. Наскільки це можливо, пакет ПЗ повинен використовуватися без внесення змін. Якщо задумані зміни суттєві, оригінальне ПЗ повинно бути збережено і зміни повинні застосовуватися тільки до ідентичної копії. Усі зміни повинні бути протестовані і задокументовані | |
| 8.5 | 10.5 | Захист процесів розробки і підтримки |
Продовження таблиці 7.2
| 8.5.4 | 10.5.4 | Чорні ходи і програми типу «Троянський кінь» | Чи існують засоби безпеки, для перевірки відсутності чорних ходів, не декларованих можливостей і програми типу «Троянський кінь» у новому ПЗ та обновлених. Чорний хід може впливати на інформацію прихованими методами. | |
| 8.5.5 | 10.5.5 | Розробка програмного забезпечення сторонніми організаціями | Чи існують засоби безпеки при розробці програмного забезпечення сторонніми організаціями. Моменти які необхідно враховувати: ліцензійну угоду, вимоги по гарантії якості, тестування перед інсталяцією на відсутність чорних ходів | |
| Управління безперервністю бізнесу | ||||
| 9.1 | 11.1 | Аспекти управління безперервністю бізнесу | ||
| 9.1.1 | 11.1.1 | Процес управління безперервністю бізнесу | Чи існує процес по розвитку і підтримці безперервності бізнесу організації. Він повинен включати: план забезпечення неперервності бізнесу організації, регулярну перевірку і обновлення плану, формулювання і документування стратегії неперервності бізнесу | |
| 9.1.2 | 11.1.2 | Безперервність бізнесу і аналіз шкоди | Чи визначені дії, які можуть бути причиною порушення бізнес-процесів, наприклад, аварії обладнання, повені, пожари. Чи проведено аналіз ризиків для визначення шкоди таких дій. Чи розроблено стратегічний план, оснований на проведеному аналізі ризиків і визначаючий загальний підхід до забезпечення безперервності бізнесу | |
| 9.1.3 | 11.1.3 | Створення і реалізація плану безперервності бізнесу | Чи розроблено плани по відновленню бізнес-операцій у випадку аварій. Чи регулярно обновлюється і тестується плану безперервності бізнесу | |
| 9.1.4 | 11.1.4 | Розробка плану безперервності бізнесу | Чи існує єдиний підхід по розробці плану безперервності бізнесу. Підтримується чи ця інфраструктура для гарантії того, що усі плани погоджені і визначені пріоритети по тестуванню і підтримці. Чи визначені умови активації і персональна відповідальність по виконанню кожного компоненту плану | |
| 9.1.5 | 11.1.5 | Тестування, підтримка і переоцінка планів безперервності бізнесу | Чи регулярно тестується план безперервності бізнесу для гарантії того, що він актуальний і ефективний. Чи існують процедури, у яких визначне порядок аудиту плану неперервності бізнесу по оцінці його ефективності. Чи включена процедура у програму управління змінами для відповідності плану неперервності бізнесу | |
| Відповідність | ||||
| 10.1 | 12.1 | Відповідність вимогам законодавства | ||
| 10.1 | 12.1.1 | Застосування вимог законодавства | Чи визначені і задокументовані для кожної ІС усі вимоги законодавства, нормативних актів і договірних обов’язків. Чи визначений задокументовані засоби безпеки і персональна відповідальність за дотримання цих вимог | |
| 10.1.2 | 12.1.2 | Право інтелектуальної власності | Чи існують процедури, гарантуючи відповідно до вимог законодавства по використанню матеріалів, у відношенні яких може бути встановлені права на захист інтелектуальної власності, як авторське право, конструкторське право, торгова марка. Чи вірно здійснюються процедури. Чи поставляється програмне забезпечення, що має ліцензійну угоду, яка обмежує використання продукту деякими ІС. | |
| 10.1.3 | 12.1.3 | Безпека документів | Чи захищені важливі документи організації від знищення та фальсифікації | |
| 10.1.4 | 12.1.4 | Безпека персональних даних | Чи існує структура управління і засобів безпеки персональних даних і права на приватне життя | |
| 10.1.5 | 12.1.5 | Запобігання неправомірного використання засобів обробки | Чи розглядається використання засобів обробки інформації для любого нецільового або несанкціонованого призначення без погодження керівництвом як неналежне використання засобів. Чи появляється під час обліку |
Продовження таблиці 7.2
| інформації | попереджуюче повідомлення на моніторі інформаційної системи про те, що система, у яку здійснено вхід, є приватною власністю і несанкціонований доступ заборонено | |||
| 10.1.6 | 12.1.6 | Вимоги з викорис тання шифрування | Чи існують і враховані вимоги вітчизняного законодавства по використанню шифрування | |
| 10.1.7 | 12.1.7 | Збір доказів | Чи проведено процес, пов’язаний зі збором доказів, у відповідності до вимог законодавства | |
| 10.2 | 12.2 | Аудит політики інформаційної безпеки і технічної відповідності | ||
| 10.2.1 | 12.2.1 | Відповідність Політики | Чи регулярно проводиться аудит усіх областей організації на відповідність політики інформаційної безпеки, стандартам і процедурам | |
| 10.2.2 | 12.2.2 | Перевірка технічної відповідності | Чи регулярно перевіряються ІС на відповідність технічним стандартам безпеки. Чи здійснюється перевірка технічного стану компетентними і авторизованими працівниками або під їх наглядом | |
| 10.3 | 12.3 | Рекомендації по аудиту систем | ||
| 10.3.1 | 12.3.1 | Засоби аудиту системи | Чи дуже пильно сплановані та погоджені вимоги аудиту і перевірка роботи операційної системи для мінімізації риску порушення системи | |
| 10.3.2 | 12.3.2 | Захист засобів аудиту системи | Чи захищено доступ до засобів аудиту, таким, як програмне забезпечення або файлів даних, з метою попередження усякої можливості зловживання або компрометації |
Таким чином, для побудови збалансованої системи БІТ організаії потрібно спочатку провести аналіз ризиків у сфері ІБ. Потім визначити оптимальний рівень ризику для організації на основі заданого критерію. Систему БІТ (контрзаходи) потрібно будувати так, щоб досягти заданого рівня ризику.
7.5. Міжнародний стандарт ISO/IEC 27001. Призначення та особливості
ISO/IEC 27001 – міжнародний стандарт з інформаційної безпеки розроблений спільно Міжнародною Організацією по Стандартизації (ISO) та Міжнародною електротехнічної комісією (IEC). Стандарт містить вимоги в області ІБ для створення, розвитку і підтримки Системи менеджменту інформаційної безпеки (СМІБ). Поняття "захисту інформації" трактується в стандарті як забезпечення конфіденційності, цілісності та доступності інформації (рис. 7.14). Основа стандарту ІСО 27001 – система управління ризиками, пов’язаними з інформацією. Система управління ризиками дозволяє отримувати відповіді на наступні питання:
на якому напрямку ІБ потрібно зосередити увагу?
скільки часу і коштів можна витратити для захисту інформації?
Процес сертифікації організації акредитованими агентствами згідно з цим стандартом складається з трьох стадій:
стадія 1: вивчення аудитором ключових документів Системи Менеджменту Інформаційної Безпеки (положення про застосування (SoA), план
Рис.7.14. Структура стандарту ISO/IEC 27001
Обробки Ризиків (RTP), та інше). Зазначені заходи можуть виконуватися як на території організації, так і шляхом висилки цих документів зовнішньому аудитору;
стадія 2: детальний, глибокий аудит включаючи тестування впроваджених заходів та оцінювання їх ефективності. Включає повне вивчення документів, які вимагає стандарт;
стадія 3: виконання інспекційного аудиту для підтвердження, що сертифікована організація відповідає заявленим вимогам. Виконується періодично.
Алгоритм впровадження системи менеджменту інформаційної безпеки відповідно до вимог міжнародного стандарту ISO/IEC 27001 передбачає послідовне виконання таких основних етапів:
перший етап – управлінський, полягає в усвідомленні цілей і вигоди впровадження СМІБ, отриманні підтримки керівництва на впровадження та введення в експлуатацію СМІБ, розподіленні відповідальності за СМІБ;
другий етап – організаційний, полягає у створенні груп з впровадження та підтримки СМІБ, навчанні групи з впровадження та підтримки СМІБ, визначення області дії СМІБ;
третій етап – початковий аналіз СМІБ, полягає у проведенні аналізу існуючої СМІБ, визначенні переліку робіт з доопрацювання існуючої СМІБ;
четвертий етап – визначення політики і цілей СМІБ, полягає у визначенні політики СМІБ, визначенні цілей СМІБ по кожному процесу СМІБ;
п’ятий етап – порівняння поточної ситуації зі стандартом, полягає у проведенні навчання відповідальних за СМІБ вимогам стандарту, опрацюванні вимог стандарту, порівнянні вимог стандарту з існуючим станом справ;
шостий етап – планування впровадження СМІБ, полягає у визначенні переліку заходів для досягнення вимог стандарту, розробці керівництва з ІБ;
сьомий етап – впровадження системи управління ризиками, полягає в розробці процедури з ідентифікації ризиків, ідентифікуванні і ранжуванні активів, визначенні відповідальних за активи, оцінюванні активів, ідентифікуванні загроз та вразливостей активів, проведенні розрахунків і ранжуванні ризиків, розробці плану по зниженню ризиків, визначенні непридатних напрямів безпеки, розробці положення про застосування контролів;
Date: 2015-06-11; view: 475; Нарушение авторских прав; Помощь в написании работы --> СЮДА... |