
- •13 Інформаційна безпека управління інцидентами
- •13.1 Звіти про події інформаційної безпеки і слабкі сторони
- •13.1.1 Звіти про події інформаційної безпеки
- •13.1.2 Звіти про недоліки безпеки
- •13.2 Управління інцидентами інформаційної безпеки та поліпшення
- •13.2.1 Обов'язки та процедури
- •13.2.2 Витяг уроків про інциденти інформаційної безпеки
- •Збір доказів
- •14 Управління безперервністю бізнесу
- •14.1 Аспекти управління інформаційною безпекою і безперервністю бізнесу
- •Інформаційна безпека в бізнес-управлінні процесом наступності
- •14.1.2 Безперервність бізнесу та оцінка ризиків
- •14.1.3 Розроблення та впровадження наступності планів, включаючи управління інформаційною безпекою
- •14.1.4 Безперервність бізнесу рамок планування
- •14.1.5 Тестування, обслуговування та повторне оцінювання безперервності бізнес планів
- •15 Відповідність
- •Додаток а Розширений набір елементів управління телекомунікації
- •Додаток b Додаткові керівні вказівки реалізації
- •Бібліографія
- •Серії рекомендацій мсе-т
13 Інформаційна безпека управління інцидентами
13.1 Звіти про події інформаційної безпеки і слабкі сторони
13.1.1 Звіти про події інформаційної безпеки
Управління Події інформаційної безпеки повинні бути представлені через відповідні канали управління якомога швидше.
Здійснення керівництва
Офіційні події інформаційної безпеки процедури звітування повинні бути встановлені разом з відгуком на інциденти та процедури ескалації , в яких викладаються дії, повинні бути прийняті на отримання звіту про подію інформаційної безпеки. Пункт зв'язку повинен бути встановлений для звітування подій інформаційної безпеки. Це повинно бути забезпечено так, що ця точка взаємодії відома всій організації, завжди доступна і в змозі забезпечити адекватне і своєчасне реагування.
Всі співробітники, підрядники та користувачі третьої сторони повинні бути інформовані про свою відповідальність повідомляти про будь-які події інформаційної безпеки якомога швидше. Вони також повинні бути проінформовані про процедуру подання подій інформаційної безпеки та точки взаємодії. Звіт процедури повинен включати:
відповідні способи зворотного зв'язку, для того, щоб звіти про події інформаційної безпеки були повідомлені про результати після того, як питання було розглянуто і закрито;
форми звітів про події інформаційної безпеки в підтримку звітування, і, щоб допомогти людині, яка звітує, пам'ятати всі необхідні дії в разі події інформаційної безпеки;
правильна поведінка, повинна починатись у випадку подій інформаційної безпеки, а саме:
відзначити всі важливі деталі (наприклад, тип недотримання або порушення, несправності, що виникають, повідомлення на екрані, дивна поведінка) негайно;
не виконує будь-які власні дії, але відразу звітує в точці взаємодії;
посилання на встановлені формальні дисциплінарні процеси для роботи зі співробітниками, підрядниками та користувачами третьої сторони, які здійснюють порушення безпеки.
В умовах високого ризику, може бути наданий примус Alarm2) у відповідності з яким особа, що перебуває під тиском може вказувати на такі проблеми. Процедури реагування на примус сигналізації повинні відображати високий ризик такої ситуації тривоги, яка вказується.
Телекомунікації конкретних вказівок реалізації
Точка взаємодії підготовлена до оцінювання, реагуванні та вивчення інцидентів безпеки, які повинні бути на місці, щоб співпрацювати з групою реагування на інциденти. Це повідомлення може бути сформований практично в телекомунікаційних організацій. Така команда реагування на інциденти повинна бути уповноважена негайно приймати рішення про те, як мати справу з інцидентом. Крім того, відносини між командою реагування і зовнішніми сторонами (наприклад, CERT, правоохоронними органами, іншими органами надзвичайної ситуації, клієнтами і бізнес-партнерами) повинні бути встановлені.
При необхідності, телекомунікації організації повинні негайно повідомляти про події пов'язаних між собою клієнтів шляхом прямої електронної пошти та / або домашньої сторінки, що надаються ними.
Інша інформація
Приклади подій та інцидентів інформаційної безпеки є:
втрата обслуговування, обладнання або об'єктів;
системи несправностей або перевантаження;
людські помилки;
невідповідності з політикою або керівними принципами;
________________ 2) примушування сигналізації це таємний спосіб про те, що дія відбувається «під примусом».
порушення фізичних заходів безпеки;
неконтрольовані зміни системи;
несправності програмного або апаратного забезпечення;
порушення прав доступу.
З належної турботи про конфіденційність аспектів, інциденти інформаційної безпеки можуть бути використані в обізнаності навчання користувачів (див. 8.2.2 ISO / IEC 27002) в якості прикладу того, що може статися, як реагувати на такі інциденти, і як їх уникнути в майбутньому . Для того, щоб вирішити події та інциденти інформаційної безпеки належним чином, може бути необхідно зібрати докази якомога швидше після появи (див. 13.2.3).
Несправності або інша аномальна поведінка системи може бути показником атаки проти безпеки або фактичного порушення безпеки, і тому вони повинні завжди бути представлені в якості подій інформаційної безпеки.
Більш докладну інформацію про звіти про події інформаційної безпеки і керування інцидентами інформаційної безпеки можна знайти в ISO / IEC TR 18044.