Please enable JavaScript.

Coggle requires JavaScript to display documents.

Лр.8 МІЖНАРОДНІ СТАНДАРТИ ІЗ ЗАХИСТУ ІНФОРМАЦІЇ ISO/ІЕС 27002 Ч.4 -…

- - - - a. подвійне введення або інші процедури перевірки введення, наприклад перевірка кордонів або обмеження полів до певних діапазонів даних, що вводяться з метою виявлення таких помилок:
        
        значень, що виходять за допустимий діапазон;
        
        неприпустимих символів в полях даних;
        
        відсутніх або неповних даних;
        
        перевищення верхніх і нижніх меж обсягу даних;
        
        заборонених або суперечливих контрольних даних;
      - b. періодична перевірка вмісту ключових полів або файлів даних для підтвердження їх достовірності та цілісності;
      - c. звірка друкованих копій документів, що вводяться на предмет виявлення будь-яких несанкціонованих змін (необхідно, щоб всі зміни у вводяться документах були затверджені);
      - d. процедури реагування на помилки перевірки;
      - e. процедури перевірки достовірності даних, що вводяться;
      - f. визначення обов'язків всіх співробітників, залучених до процесу введення даних;
      - g. створення журналу реєстрації дій, пов'язаних з процесом введення даних (див. 10.10.1).
    - - Необхідно враховувати, зокрема, наступне:
        
        a. використання функцій додавання, модифікації і видалення для здійснення змін даних;
        
        b. процедури, що не допускають запуск програм, виконуваних в неправильній послідовності або виконуваних після збою в попередньої обробки (див. 10.1.1);
        
        c. використання відповідних програм для відновлення після збоїв і забезпечення правильної обробки даних;
        
        d. захист від атак, що використовують перевантаження / переповнення буфера.
    - - Перевірка вихідних даних може включати:
        
        a. перевірки достовірності з метою визначення прийнятності вихідних даних;
        
        b. контрольна звірка результатів, для забезпечення впевненості в тому, що всі дані були оброблені;
        
        c. надання достатньої інформації для читання або подальшої системи обробки, щоб визначити коректність, повноту, точність і класифікацію інформації;
        
        d. процедури реагування на перевірку придатності вихідних даних;
        
        e. визначення обов'язків всіх співробітників, залучених до процесу виведення даних;
        
        f. створення журналу реєстрації дій по підтвердженню коректності вихідних даних.
  - - - Система управління ключами повинна бути заснована на узгодженому безлічі стандартів, процедур і безпечних методів для:
        
        a. генерації ключів для різних криптографічних систем і прикладних програм;
        
        b. генерації та отримання сертифікатів відкритих ключів;
        
        c. розсилки ключів передбачуваним користувачам, включаючи інструкції по активації зазначених ключів при отриманні;
        
        d. зберігання ключів, в тому числі інструкцій щодо отримання доступу до ключів авторизованих користувачів;
        
        e. заміни або поновлення ключів, включаючи правила щодо порядку і термінів заміни ключів;
        
        f. дій щодо скомпрометованих ключів;
        
        g. анулювання ключів, в тому числі порядок вилучення і деактивації, наприклад в разі компрометації ключів або при звільненні користувача з організації (при цьому ключі необхідно також архівувати);
        
        h. відновлення ключів, які були загублені або зіпсовані, як частина менеджменту безперервності бізнесу, наприклад для відновлення зашифрованої інформації;
        
        i. архівування ключів, наприклад для відновлення заархівувати або резервної інформації;
        
        j. знищення інформації;
        
        k. реєстрації та аудиту дій, пов'язаних з управлінням ключами.
  - - - Для зведення до мінімуму ризику пошкодження експлуатованих систем необхідно врахувати наступні рекомендації щодо контролю змін:
        
        a) оновлення експлуатованого програмного забезпечення, прикладних програм і бібліотек програм повинні виконувати тільки навчені адміністратори при наявності відповідного дозволу керівництва (див. 12.4.3); і не повинні містити коди розробки або компілятори;
        
        b) прикладні програми та програмне забезпечення слід впроваджувати в експлуатований систему тільки після всебічного і успішного тестування, яке повинно виконуватися на ізольованих системах і включати в себе тести на придатність до експлуатації, безпека, вплив на інші системи і зручність для користувача (див. 10.1.4); необхідно забезпечити впевненість у тому, що всі відповідні бібліотеки вихідних текстів програм були оновлені;
        
        c) заходи і засоби контролю і управління конфігурацією системи необхідно використовувати згідно системної документації для збереження управління всім реалізованим програмним забезпеченням;
        
        d) перш ніж зміни будуть реалізовані, необхідно застосовувати метод відкоту;
        
        e) в контрольному журналі повинні бути збережені всі оновлення експлуатованої бібліотеки програм;
        
        f) попередні версії прикладного програмного забезпечення слід зберігати на випадок непередбачених обставин;
        
        g) старі версії програмного забезпечення слід архівувати разом з усією необхідною інформацією та параметрами, процедурами, конфігураційними деталями і підтримує програмним забезпеченням до тих пір, поки дані зберігаються в архіві.
    - - Для захисту діючих (робочих) даних, якщо вони використовуються для цілей тестування, необхідно застосовувати такі рекомендації:
        
        a) процедури управління доступом, застосовні для експлуатованих прикладних систем, слід також застосовувати і для тестування прикладних систем;
        
        b) необхідно окремий дозвіл на кожен випадок копіювання діючої (робочої) інформації для тестування прикладної системи;
        
        c) після того як тестування було завершено, діючу (робочу) інформацію слід негайно видалити з тестованої прикладної системи;
        
        d) копіювання та використання діючої (робочої) інформації має фіксуватися для забезпечення контрольної записи.
  - - - Цей процес повинен охоплювати:
        
        a) аналіз заходів та засобів контролю і управління прикладними програмами і процедур цілісності на предмет забезпечення впевненості в тому, що вони не будуть порушені змінами експлуатованої системи;
        
        b) забезпечення впевненості в тому, що щорічний план підтримки та бюджет передбачає аналіз і тестування систем, необхідні при змінах експлуатованої системи;
        
        c) забезпечення впевненості в тому, що повідомлення про зміни експлуатованої системи надходять своєчасно, щоб дати можливість перед їх реалізацією провести відповідні тести і аналізи;
        
        d) забезпечення впевненості в тому, що відповідні зміни вносяться до планів забезпечення безперервності бізнесу (див. 14).
    - - Там, де необхідно внести зміни в пакет програм, слід враховувати наступне:
        
        a) ризик щодо вбудованих заходів і засобів контролю та управління і процедур забезпечення цілісності;
        
        b) необхідність отримання згоди постачальника;
        
        c) можливість отримання необхідних змін від постачальника в якості стандартної програми оновлення;
        
        d) можливі наслідки в разі, якщо організація стане відповідальною за майбутнє супровід програмного забезпечення в результаті внесених змін.
    - - Для зниження ризику витоку інформації, наприклад, з причин використання і експлуатації прихованих каналів, необхідно брати до уваги наступне:
        
        a) сканування носіїв вихідної інформації і каналів зв'язку на наявність прихованої інформації;
        
        b) маскування і регулювання поведінки систем і каналів зв'язку для зниження ймовірності того, що третя сторона зможе отримати інформацію з поведінки систем і каналів зв'язку;
        
        c) використання систем і програмного забезпечення, які вважаються максимально достовірними, наприклад використання оцінених продуктів (див. ISO / IEC 15408);
        
        d) регулярний моніторинг діяльності персоналу та систем там, де це дозволено існуючим законодавством або приписами;
        
        e) моніторинг використання ресурсів в комп'ютерних системах.
    - - Там, де для розробки програмного забезпечення залучається стороння організація, необхідно враховувати наступне:
        
        a) ліцензійні угоди, права власності на програми і права інтелектуальної власності (див. 15.1.2);
        
        b) сертифікацію якості і точності виконаної роботи;
        
        c) угоди умовного депонування на випадок відмови третьої сторони виконувати свої
        
        d) зобов'язання;
        
        e) права доступу з метою перевірки якості і точності виконаної роботи;
        
        f) договірні вимоги до якості та функціональної безпеки програм;
        
        g) тестування програм перед установкою на предмет виявлення шкідливих і «троянських» програм.
- - - - Необхідно, щоб процедури інформування включали:
        
        a) відповідні процеси зворотного зв'язку, для забезпечення впевненості в тому, що співробітник, який повідомив про події інформаційної безпеки, був повідомлений про результати після того, як проблема була вирішена і закрита;
        
        b) форми повідомлень про події інформаційної безпеки, які повинні нагадати особі про дії, які необхідно здійснити;
        
        c) правила поведінки в разі, якщо відбудеться подія інформаційної безпеки, а саме:
        
        d) посилання на встановлені формальні дисциплінарні процеси щодо співробітників, підрядників і користувачів третьої сторони, які порушують правила безпеки.
  - - - Відносно процедур менеджменту інцидентів інформаційної безпеки необхідно враховувати наступні рекомендації:
        
        a) слід встановити процедури обробки різних типів інцидентів інформаційної безпеки, включаючи:
        
        1) збої інформаційних систем і втрату обслуговування;
        
        2) шкідливі програми (див. 10.4.1);
        
        3) відмова в обслуговуванні;
        
        4) помилки, які є наслідком неповноти або неточності даних бізнесу;
        
        5) порушення конфіденційності та цілісності;
        
        6) неправильне використання інформаційних систем;
        
        b) на додаток до звичайних планам забезпечення безперервності бізнесу (див. 14.1.3), процедури повинні також охоплювати (див. 13.2.2):
        
        1) аналіз і виявлення причини інциденту;
        
        2) обмеження поширення наслідків;
        
        3) планування і реалізацію коригувальних дій для запобігання повторення, якщо це необхідно;
        
        4) взаємодія з особами, які зазнали вплив інциденту або брали участь у відновленні після інциденту;
        
        5) повідомлення про прийняте дії до відповідного органу;
        
        c) контрольні записи і аналогічні докази необхідно збирати (див. 13.2.3) і захищати для:
        
        a) аналізу внутрішніх проблем;
        
        b) використання в якості судового докази щодо можливого порушення договору або нормативного вимоги, а також в разі цивільного чи кримінального провадження, наприклад на підставі неправильного використання комп'ютера або законодавства про захисту даних;
        
        c) обговорення умов про виплату компенсації постачальниками програмного забезпечення і послуг;
        
        d) дії по відновленню після прояву недоліків безпеки і щодо усунення збоїв систем слід ретельно контролювати; процедури повинні забезпечувати впевненість у тому, що:
        
        1) тільки чітко ідентифікованого та уповноваженому персоналу дозволений доступ до експлуатованих систем і даними (див. 6.2 на предмет зовнішнього доступу);
        
        2) всі вжиті аварійні дії документуються в деталях;
        
        3) керівництво інформується про аварійний дії, і така дія аналізується належним чином;
        
        4) цілісність систем, а також заходів і засобів контролю та управління бізнесу підтверджується з мінімальною затримкою.
    - - В основному, правила, які застосовуються щодо збору доказів, передбачають:
        
        a) допустимість доказів, тобто чи може доказ використовуватися в суді;
        
        b) вагомість доказів тобто якість і повнота доказів.
- - - - Даний процес повинен об'єднувати такі ключові елементи менеджменту безперервності бізнесу:
        
        a) розуміння ризиків, з якими стикається організація, з точки зору ймовірності і тривалості впливу, включаючи визначення критичних процесів бізнесу і встановлення їх пріоритетів (див. 14.1.2);
        
        b) визначення всіх активів, залучених в критичні процеси бізнесу (див. 7.1.1);
        
        c) розуміння наслідків для бізнесу, які можуть бути викликані перериваннями, зумовленими інцидентами інформаційної безпеки (важливо, щоб були знайдені рішення, які будуть застосовуватися як в разі незначних, так і суттєвих інцидентів, потенційно загрозливих життєдіяльності організації), а також визначення цілей бізнесу стосовно до засобів обробки інформації;
        
        d) розгляд можливості відповідного страхування, яке може стати частиною загального процесу безперервності бізнесу, а також частиною менеджменту експлуатаційного ризику;
        
        e) визначення і розгляд впровадження додаткових превентивних і політики з боротьби з і засобів контролю і управління;
        
        f) визначення достатності фінансових, організаційних, технічних ресурсів і ресурсів навколишнього середовища для реагування на виявлені вимоги інформаційної безпеки;
        
        g) забезпечення безпеки персоналу та захист засобів обробки інформації і майна організації;
        
        h) розробку і документальне оформлення планів забезпечення безперервності бізнесу, які враховують вимоги інформаційної безпеки відповідно до узгодженої стратегією забезпечення безперервності бізнесу (див. 14.1.3);
        
        i) регулярне тестування і оновлення даних планів і застосовуваних процесів (див. 14.1.5);
        
        j) забезпечення впевненості в тому, що менеджмент безперервності бізнесу органічно вписується в процеси і структуру організації; відповідальність за процес менеджменту інформаційної безпеки слід призначати на відповідному рівні в рамках організації (див. 6.1.1).
    - - Процес планування безперервності бізнесу повинен передбачати наступне:
        
        a) визначення та узгодження всіх обов'язків і процедур, пов'язаних із забезпеченням безперервності бізнесу;
        
        b) визначення прийнятних втрат інформації та послуг;
        
        c) впровадження процедур, що дозволяють відновити і відновити операції бізнесу і доступність інформації в необхідні терміни; особливу увагу слід приділити оцінці зовнішніх і внутрішніх залежностей бізнесу та існуючих договорів;
        
        d) експлуатаційні процедури, яких необхідно дотримуватися в очікуванні завершення відновлення і відновлення;
        
        e) документальне оформлення узгоджених процедур і процесів;
        
        f) відповідне навчання співробітників узгодженими процедурами розвиваються, включаючи управління в критичних ситуаціях;
        
        g) тестування та оновлення планів.
    - - В основу планування безперервності бізнесу повинні бути закладені вимоги інформаційної безпеки, і передбачено наступне:
        
        a) умови активізації планів, що описують процес, якому необхідно слідувати (наприклад, як оцінити ситуацію, хто повинен брати участь), перш ніж привести в дію кожен план;
        
        b) процедури, що визначають порядок дій при надзвичайних ситуаціях, які повинні бути зроблені після інциденту, що ставить під загрозу операції бізнесу;
        
        c) процедури переходу на аварійний режим, що описують дії, які повинні бути зроблені, щоб перенести важливі операції бізнесу і послуги підтримки в альтернативне тимчасове місце розміщення і відновити процеси бізнесу в необхідні терміни;
        
        d) тимчасові експлуатаційні процедури, яких слід дотримуватися в очікуванні завершення відновлення і відновлення;
        
        e) процедури відновлення, що визначають порядок дій, які повинні бути зроблені, щоб повернутися до нормального стану операцій бізнесу;
        
        f) графік підтримки плану, який визначає спосіб і час перевірки, а також процес підтримки плану в актуальному стані;
        
        g) інформування, навчання та тренінг, спрямовані на розуміння процесів забезпечення безперервності бізнесу та забезпечення впевненості в ефективності цих процесів;
        
        h) обов'язки осіб із зазначенням відповідальних за виконання кожного пункту плану, при необхідності повинні бути вказані альтернативні відповідальні особи;
        
        i) найважливіші активи і ресурси, необхідні для дій в надзвичайних ситуаціях, при переході на аварійний режим і в процедурах відновлення.
    - - До таких методів належать:
        
        a) теоретична перевірка різних сценаріїв (обговорення заходів по відновленню бізнесу на різних прикладах переривань);
        
        b) моделювання особливо для тренінгу співробітників по виконанню їх ролей менеджменту в постінцідентних і кризових ситуаціях;
        
        c) тестування технічного відновлення (забезпечення впевненості в можливості ефективного відновлення систем);
        
        d) тестування процесів відновлення діяльності на альтернативному майданчику (процеси бізнесу здійснюються паралельно з процедурами відновлення на віддаленій альтернативному майданчику);
        
        e) тестування обладнання і послуг постачальників (забезпечення впевненості в тому, що надані сторонніми організаціями продукти і послуги задовольняють договірним зобов'язанням);
        
        f) «генеральні репетиції» (перевірка готовності персоналу, обладнання, засобів і процесів до забезпечення безперервності бізнесу).
- - - - Пропрієтарне (власницьке) програмне забезпечення:
        
        a. програмне забезпечення захищене авторським / патентним правом. Модифікація і подальше поширення такого програмного забезпечення заборонена або строго обмежена;
        
        b. програми власного виробництва, розроблені компаніями для внутрішнього використання (На відміну від стандартних програмних засобів відомих виробників).
    - - Наступні питання необхідно розглядати стосовно дотримання відповідних угод, законів і нормативних актів:
        
        a) обмеження на імпорт і (або) експорт комп'ютерних апаратних і програмних засобів для виконання криптографічних функцій;
        
        b) обмеження на імпорт і (або) експорт комп'ютерних апаратних і програмних засобів, які розроблені таким чином, що мають в якості доповнення криптографічні функції;
        
        c) обмеження на використання шифрування;
        
        d) обов'язкові або представлені на власний розсуд методи доступу державних органів до інформації, зашифрованої за допомогою апаратних або програмних засобів для забезпечення конфіденційності змісту.
  - - - Якщо в результаті проведення аналізу було виявлено якесь невідповідність, керівникам слід:
        
        a) визначити причини невідповідності;
        
        b) оцінити необхідність дій з метою забезпечення впевненості у тому, що невідповідності неможливо повториться;
        
        c) визначити і реалізувати відповідне коригувальну дію;
        
        d) проаналізувати зроблене коригувальну дію.
  - - - Необхідно враховувати наступні рекомендації:
        
        a) вимоги аудиту повинні бути погоджені з відповідним керівництвом;
        
        b) область перевірок слід узгоджувати і контролювати;
        
        c) при проведенні перевірок доступ до програмного забезпечення та даними повинен бути обмежений тільки читанням;
        
        d) інші види доступу, крім доступу тільки для читання, можуть бути дозволені тільки в відношенні ізольованих копій файлів системи, які необхідно видалити після завершення аудиту або забезпечити відповідним захистом, якщо необхідно зберігати такі файли у відповідності до вимог документального оформлення аудиту;
        
        e) ресурси, необхідні для виконання перевірок, повинні бути чітко визначені і зроблені доступними;
        
        f) вимоги щодо спеціальної або додаткової обробки даних слід визначити і узгодити;
        
        g) весь доступ необхідно відстежувати і реєструвати для створення простежуються посилань; для критично важливих даних і систем належить розглядати використання датуються простежуються посилань;
        
        h) всі процедури, вимоги і обов'язки слід оформляти документально;
        
        i) особа (и), що проводить (і) аудит, має (и) бути незалежним (і).