Метричні показники як засіб визначення відповідності інформаційної системи вимогам
Концепція метричних показників, їх класифікація. Особливості систем метричних показників: за стандартом NIST SP 800-55 і система Еркана Карамана. Таблиці метричних показників з формулами для обчислення та нормативами, до яких повинні наближатись значення.
| Рубрика | Производство и технологии |
| Вид | дипломная работа |
| Язык | украинский |
| Дата добавления | 22.09.2011 |
| Размер файла | 1,5 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Кпрогр_змін - загальна кількість змін в програмах
*100
Кпатч - кількість систем з патчами
Кскан - загальна кількість _олу автоматич систем
*100
Цілісність даних
Кавто - кількість систем з автоматичним оновленням антивірусних баз та автоматичною перевіркою на наявність вірусів
Кз - загальна кількість систем
*100
100%
Кп_перев - кількість систем з перевіркою паролів
Кп_заг - загальна кількість систем з паролями
*100
100%
Документація
Кдок - кількість програмних продуктів з супроводжувальною документацією в файлі
Кпрогр_з - загальна кількість програмних продуктів
*100
100%
Кд - кількість систем з задокументованою оцінкою ризику
Кз - загальна кількість систем
*100
100%
Розуміння, навчання та тренінги безпеки
Кслужб - службовців з важливими обов`язками в галузі безпеки, які пройшли належні тренінги
Кслужб_з - загальна кількість службовців з важливими обов`язками
*100
Можливість реагування на інциденти
Креаг - кількість частин агенції які мають можливість відповідати на інциденти
Ккомп_з - загальна кількість компонентів
*100
100%
Ка - кількість звітів було, які було зроблено в агенції за звітний період
Кnipc - кількість звітів було, які було зроблено в NIPC за звітний період
КFedCIRC - кількість звітів було, які було зроблено в FedCIRC за звітний період
И30= (Ка+ Кnipc+ КFedCIRC) *100
Ідентифікація та авторизація
Кзмын_пост - кількість систем зі зміненими паролями постачальника
Кз - загальна кількість систем
*100
100%
Заходи логічного доступу
Кдоступ_перс - кількість персоналу з доступом до програмного забезпечення безпеки, що не є адміністраторами
Кзаг_перс - кількість користувачів, які мають доступ до програмного забезпечення безпеки
*100
100%
Кпротокол - кількість систем, які використовують заборонені протоколи
Кз - загальна кількість систем
*100
0%
Квеб_приват - кількість сайтів з політикою приватності
Кзаг - загальна кількість сайтів в організації
*100
100%
Тривалий аудит
Клог_дій - кількість систем, в яких виконується зберігання дій користувачів
Кзаг - загальна кількість користувачів
*100
100%
3.2 Модель Еркана Карамана
Згідно з роботою Еркана Карамана оцінювання - це ретельне визначення, фіксування чи знаходження. Метричні показники, які можливо зібрати можуть відрізнятись в різних галузях через те, що цілі ефективності також є різними. Контроль доступу може бути більш важливим для мереж, в яких виконуються фінансові транзакції, ніж в системах для збереження даних. В своїй роботі Еркан Караман фокусується на метричних показниках, які є важливими для будь-якої системи метричних показників [5].
Через це, можна розділити метричні показники на 4 типи: результативності, ефективності, збитку та реалізації. Метричні показники, які обираються для оцінки, повинні відповідати цілям ефективності та повинні допомагати оцінити ключові аспекти ефективності. В деяких випадках метричні показники можна розділити на 3 типи: результативності, ефективності та реалізації. За моделлю Еркана Карамана, метричні показники розробляються згідно з 3 специфічними зонами оцінювання (Організаційні, Людські та Технічні аспекти оцінювання).
Для Організаційної безпеки дуже важливим є оцінювання рівню захищеності мережі, фаєрволів, вірусного сканування, IDS та ін. Повинна існувати політика, яка б керувала менеджментом підтримкою інформаційної безпеки. За технічні заходи є відповідальним менеджер інформаційної системи чи системний адміністратор. Організаційна політика повинна охоплювати наступні зони:
1. Фізична безпека;
2. Безпека мережі;
3. Заходи безпеки;
4. Полу автоматич;
5. Шифрування;
6. Аудит та періодичний перегляд;
7. Тренінги з безпеки;
8. Система реагування на інциденти та план на випадок НП.
Найважчі проблеми походять не від технічний ускладнень, а від недостатності контролю за поведінкою службовців. Для уникнення таких випадків існують процедури, які описують порядок використання Політик Безпеки ІТ. Ефективність політик прямо пропорційна підтримці процедур, що гарантують виконання процедур.
Людський фактор в інформаційній системі може по різному впливати на інформаційну безпеку. Фактично, безпека залежить від людського фактору. Користувачі можуть призвести до аварійного стану чи до атаки типа “соціальна інженерія”. Звичайно, можуть виникати внутрішні атаки на компанії, які здійснюють зловмисні користувачі, але це є проблемою довіри в кадровій системі. Таким чином, метричні показники з Людської галузі спрямовані на оцінку тренінгів, курсів та освіти працівників, що є необхідним для запобіганню появі аварій та уразливостей.
Сучасні технології швидко удосконалюються, та разом з ними, удосконалюються техніки та технології безпеки. Професіонали з безпеки повинні використовувати VPN, IDS, фаєрволи, маршрутизатори, операційні системи, заходи тестування на проникність та ін. Для оцінювання ефективності безпеки ІТ з технічного боку існують автоматичні та напівавтоматичні джерела даних. Метричні показники з Технічної галузі існують для аналізу заходів безпеки ІТ, оцінювання фаєрволів та IDS, бекапів та планів на випадок НП.
Рисунок 3.2 - Таксономія метричних показників Еркана Карамана
Таблиця 3.2 - Таблиця метричних показників за стандартом Еркана Карамана
|
Метричний показник |
Метод |
Формула |
Пояснення |
||
|
1 Організаційний огляд |
|||||
|
1.1 Перевірка політики |
|||||
|
1. Чи організація має розвинену Політику Безпеки? |
Контрольний лист |
Так (1), Ні (0) |
Для того, щоб почати перевірку повинен існувати Політика Безпеки |
||
|
2. Чи є обов`язковим читати та підписувати Політику Безпеки для нових службовців? |
Контрольний лист |
Так (1), Ні (0) |
Перший крок для того, щоб Політика Безпеки була застосована в організації. Ця процедура повинна повторюватись при прийомі нового службовця чи зміні посади |
||
|
3. Який відсоток відділів має останню версію Політики Безпеки? |
Розрахунок |
Квідділів - кількість відділів з останньою версією ПБ Кзаг - загальна кількість відділів |
Недостатньо мати Політику Безпеки, її необхідно розповсюдити серед відповідних відділів та керівників |
||
|
4. Який відсоток службовців читав та підписав Політику Безпеки? |
Розрахунок |
Кслужб - кількість службовців, які читали та підписали Політику Безпеки Кзаг - загальна кількість службовців |
Виходячи з 2 метричного показника, для того, щоб Політика Безпеки була ефективною необхідно, щоб її знали та прийняли користувачі системи |
||
|
5. Який відсоток веб-сайтів має застосовану політику приватності? |
Розрахунок |
Квеб-сайтів - кількість веб-сайтів з застосованою політикою приватності Кзаг-загальна кількість веб-сайтів в організації |
Якщо публіка має доступ до системи, повинні існувати заходи контролю цілісності програм та конфіденційності публіки |
||
|
6. Який відсоток інцидентів, що трапились, незважаючи на попереджувальні міри, вказані в Політиці Безпеки? |
Розрахунок |
Кінц - кількість інцидентів, які трапились з урахуванням попереджувальних мір Кзаг - загальний відсоток інцидентів |
Це свідчить про ефективність та простоту Політики Безпеки. Чи інциденти ще трапляються, незважаючи на попереджувальні мірі, вказані в Політиці Безпеки? |
||
|
7. Чи Політика Безпеки ІТ легка в застосуванні (проста та практична)? |
Аналіз |
взагалі не (0), (1), (2), (3), (4) легка та практична |
Політика, яка написана лише для того, щоб лежати на полиці, не буде ефективна. Менеджмент повинен підтвердити те, що користувачі задоволені Політикою Безпеки. |
||
|
8. Чи Політику Безпеки ІТ легко підтримувати та керувати нею? |
Аналіз |
взагалі не (0), (1), (2), (3), (4) легка для підтримки та керування |
Політика Повинна бути відкрита для змін та розвитку. |
||
|
9. Який середній проміжок часу між перевірками політик на необхідність змін? |
Аналіз |
Тсер - середній проміжок часу Кзаг - загальна кількість переглядів політики з Тсер |
Чи політика переглядається для змін та доповнень? Бажано мати як найменший проміжок часу між перевірками а також регулярні перевірки по встановленим датам та нерегулярні перевірки під час технічних змін. |
||
|
10. Чи легко можуть отримати доступ до Політики Безпеки люди, які шукають інформацію? |
Аналіз |
взагалі не (0), (1), (2), (3), (4) легко отримати доступ та шукати інформацію |
Цей метричний показник є індикатором доступності Політики Безпеки. Чи ПБ зберігається в електронному вигляді в мережі для доступу та пошуку інформації, або користувачі мають копію на вінчестері? Чи вона структурована та проіндексована для специфічних програм? |
||
|
11. Чи Політика Безпеки ІТ містить класифікацію даних? |
Контрольний Лист |
Так (1), Ні (0) |
Чи дані класифіковані за конфіденційністю та метою використання? Найбільш вживаною класифікацією є: некласифіковані дані, загальнодоступні, тільки для компанії, конфіденційні |
||
|
12. Який відсоток даних зберігається за принципом “класифікація даних”? |
Розрахунок |
Ккласс - кількість даних, які зберігаються за принципом “класифікація даних” Кзаг - загальна кількість загальнодоступних даних |
Обчислюється в мегабайтах. Цей метричний показник використовується для визначення рівня застосування принципу “класифікації даних" в Політиці Безпеки ІТ. |
||
|
13. Чи фізичне обладнання мережі класифікується таким же чином? |
Контрольний Лист |
Так (1), Ні (0) |
_олу авт та інші портативні пристрої, мейнфрейми, сервери повинні мати правила використання та директиви захисту. |
||
|
14. Чи визначає політика рівень відповідальності кожної особи за ІБ? |
Контрольний Лист |
Так (1), Ні (0) |
Коли користувачі підписують Політику Безпеки ІТ, вони повинні розуміти, що вони відповідальні за захист ІТ інфраструктури. |
||
|
15. Чи вказується авторство? |
Контрольний Лист |
Так (1), Ні (0) |
Політика Безпеки ІТ повинна відноситись до когось, хто б міг обробляли запитання користувачів. Автор також відповідає за підтримку документів їх керуванням. |
||
|
16. Чи пояснюються функції та відповідальності Службовцю Безпеки? |
Контрольний Лист |
Так (1), Ні (0) |
Чи в документі вказані обов`язки та роль Службовця Безпеки? |
||
|
17. Чи хто-небудь крім власника має право змінювати політику |
Контрольний Лист |
Так (1), Ні (0) |
Для захисту цілісності Політики Безпеки повинна існувати гарантія, що тільки один автор (окрема персона чи члени групи) має право вносити зміни в документ |
||
|
18. Чи визначена відповідальність за специфічні технічні проблеми для відповідних людей? |
Контрольний Лист |
Так (1), Ні (0) |
Чи План Безпеки ІТ визначає хто відповідає за техніку? Чи політика вимагає, щоб важлива інформація та технології фізично захищались весь час? |
||
|
19. Чи політика передбачає мінімальний контроль _олу автоматич? |
Контрольний Лист |
Так (1), Ні (0) |
Контроль аутентифікація, наприклад, довжина паролю, мінімальний інтервал зміни паролю та ін. повинні бути встановлені для того, щоб отримати надійну політику безпеки |
||
|
20. Чи політика включає документацію по охороні багатьох з ваших технологій? |
Контрольний Лист |
Так (1), Ні (0) |
Метою політики безпеки є гарантія того, що організація розуміє суть ризиків безпеки ІТ. |
||
|
21. Чи існує процедура реєстрації користувачів? |
Контрольний Лист |
Так (1), Ні (0) |
Чи відділ ІТ реєструє кожного користувача згідно з процедурами, відповідно Політиці Безпеки? Чи процедура слідкує за вибором унікальних та важних для відгадування _олу ав та паролів? |
||
|
22. Чи існує процедура усунення реєстраційного _олу а користувача? |
Контрольний Лист |
Так (1), Ні (0) |
Чи існує процедура для усунення застарілого реєстраційного _олу а користувача? Відомо, що після звільнення службовця, його _олу ав можуть зловживати. |
||
|
23. Який відсоток систем використовує політику перевірки паролів |
Розрахунок |
Кперевірки - кількість систем з політикою перевірки паролів Кзаг - загальна кількість систем |
Чи існують політики перевірки паролів? |
||
|
24. Чи існує процедура, за якою проекти повинні проходити тест на відповідність політиці безпеки та контролю якості? |
Контрольний Лист |
Так (1), Ні (0) |
Проекти можуть використовувати конфіденційні дані та важливі інформаційні технології; для попередження втрати інформації чи уразливостей проекти повинні оцінені виміряннями безпеки ІТ |
||
|
25. Який відсоток проектів пройшов тест на відповідність політиці безпеки? |
Розрахунок |
Ксхвал - кількість схвалених проектів Кзаг - загальна кількість проектів |
Метою метричного показника є виміряння ефективності процедур по тестуванню на відповідність політиці безпеки |
||
|
26. Чи існує процедура, яка відповідає за оновлення антивірусних баз? |
Контрольний Лист |
Так (1), Ні (0) |
Чи оновлення антивірусних баз виконується через визначений проміжок часу або воно виконується після виникнення нової загрози? |
||
|
27. Який середній проміжок часу між оновленнями антивірусних баз? |
Розрахунок |
Кперіод - визначений проміжок часу Кзаг - кількість оновлень в рамках обраного проміжку часу |
Менший проміжок часу між оновленнями забезпечить більший захист від вірусів. |
||
|
28. Чи існує процес встановлення патчів? |
Контрольний Лист |
Так (1), Ні (0) |
Деякі продавці надають можливість автоматичних оновлень, але адміністратори повинні керувати схемою оновлень та важливістю патчів. Чи існує людина чи сервіс, якій відповідає за цей процес та чи визначено як часто необхідно перевіряти програми на наявність оновлень? |
||
|
29. Який середній проміжок часу між реалізацією патчів та їх встановленням? |
Розрахунок |
Кзатримки - загальна кількість часової затримки для встановлення патчів Кзаг - загальна кількість процесів встановлення патчів за визначений часовий період |
Системи, які включають ОС, фаерволи та сервери повинні регулярно оновлюватись; коротший період буде давати кращий рівень захисту |
||
|
30. Чи існує процедура для процесу створення бекапів |
Контрольний Лист |
Так (1), Ні (0) |
Схвалена процедура для створення бекапів рекомендується для планування процесів, керування плівками та їх зберіганням |
||
|
31. Чи існує процедура для тестування та нового/оновленого технічного обладнання перед застосуванням |
Контрольний Лист |
Так (1), Ні (0) |
Частка системи управління конфігурацією, усе нове технічне обладнання повинно бути опротестоване та занесене в базу даних |
||
|
32. Який відсоток службовців проходить перевірку минулого життя перед прийняттям на роботу? |
Розрахунок |
Кслужб_пройшли - кількість службовців, які пройшли процес Кзаг - загальна кількість службовців |
Процес гарантує те, що конфіденційні дані не потраплять до рук людини з кримінальним минулим чи обмеження, пов`язані з хакерською діяльністю |
||
|
33. Чи існує дисциплінарний процес за порушення безпеки організації? |
Контрольний Лист |
Так (1), Ні (0) |
Чи політика передбачає дисциплінарний процес для службовців, які порушили процеси та процедури безпеки організації? |
||
|
34. Кількість працівників, які зіткнулися з дисциплінарним процесом за минулий рік |
Розрахунок |
Кількість працівників, які зіткнулися з дисциплінарним процесом за минулий рік |
Чи система дійсно використовується та чи є ефективними її правила. Кількість працівників, які зіткнулися з дисциплінарним процесом за минулий рік повинна бути в балансі з кількістю інцидентів |
||
|
35. Чи існує процедура для створення звітів про інциденти, слабкості чи збої в програмах |
Контрольний Лист |
Так (1), Ні (0) |
Чи система передбачає, щоб користувачі відчували відповідальність за інциденти та слабкості в безпеці та повідомили про таки випадки адміністраторів? |
||
|
36. Яка кількість інцидентів, слабкостей та збоїв за минулий проміжок часу? |
Розрахунок |
Загальна кількість отриманих звітів |
|||
|
2 Оцінка людських ресурсів |
|||||
|
37. Чи користувачі інформуються про політику безпеки та про те, як захищати важливу інформацію? |
Контрольний Лист |
Так (1), Ні (0) |
Чи політика безпеки роздрукована та розповсюджена чи навіть підписана користувачами без надання відповідних тренінгів на тему “навіщо все це” чи “як це працює” |
||
|
38. Чи користувачі інформуються про їх рівень відповідальності за безпеку? |
Контрольний Лист |
Так (1), Ні (0) |
Збереження паролів в таємниці, не залишання комп`ютера без уваги, не відкривання підозрілих листів та інші ключові пункти, про які користувачі повинні бути повідомлені |
||
|
39. Чи досягнутий принцип індивідуальної відповідальності користувачів за безпеку інформації? |
Контрольний Лист |
Так (1), Ні (0) |
Для досягнення принципу індивідуальної відповідальності повинна існувати не тільки Політика Безпеки ІТ, але й тренінги, листи з новинами, буклети та ін. |
||
|
40. Який відсоток працівників зі значними відповідальностями в галузі безпеки, які пройшли спеціальні тренінги? |
Розрахунок |
Ксерт - кількість сертифікованих/тренованих працівників Кзаг - загальна кількість працівників |
Цей метричний показник свідчить про рівень досвідченості серед певних ролей безпеки та відповідальностей для специфічних систем всередині організації. Як джерела даних можуть бути використані сертифікати працівників про завершення курсів |
||
|
41. Чи можете ви визначити рівень знать розуміння працівників? |
Контрольний Лист |
Нема розуміння про Ризики Безпеки ІТ (0), (1), (2), (3), (4) розуміння проблем безпеки ІТ |
Результати тестування на розуміння чи персональний огляд Службовців безпеки; рівень розуміння також свідчить про ефективність тренувальних програм, які проводились раніше, якщо вони проводились |
||
|
42. Який середній час тренувань на кожного працівника? |
Розрахунок |
Квитрачений_час - загальний час, витрачений на тренування Кзаг - загальна кількість працівників |
Завдяки гарним тренінгам може бути досягнутий більш високий рівень розуміння. |
||
|
43. Який відсоток вищого рівня освіти? |
Розрахунок |
Квища_освіта - кількість працівників з вищим рівнем освіти Кзаг - загальна кількість працівників |
Існує 3 рівні освіти: “undergraduate”, “graduate”, “post-graduate”. Дані для розрахунку метричного показника можуть бути отримані з бази даних працівників |
||
|
3 Технічний огляд |
|||||
|
3.1 Перевірка контролю доступу |
|||||
|
44. Чи існує сильна політика паролів, введена в дію управлінням? |
Контрольний лист |
Так (1), Ні (0) |
При встановленні політик та процедур без визначення правил для контролю доступу, неможна очікувати на ефективність |
||
|
45. Чи аутентифікація користувачів виконується індивідуально, за допомогою паролів, старт карт чи інших пристроїв? |
Контрольний лист |
Так (1), Ні (0) |
“Фази доступу" є більш ефективними ніж простий 6 - значний пароль, але система фізичної аутентифакації гарантує набагато більш високий рівень безпеки. |
||
|
46. Який відсоток унікальний ID користувачів? |
Розрахунок |
Кунік - кількість користувачів з унікальними ID Кзаг - загальна кількість користувачів |
Чи механізм контролю доступу використовує розділення обов`язків? Лист контролю доступу та файл з паролями будуть зручними для обчислення метричного показника |
||
|
47. Який відсоток неактивних користувачів? |
Розрахунок |
Кнеактивних - кількість неактивних акантів Кзаг - загальна кількість акантів |
В залежності від статистики логів, метричний показник допоможе адміністраторам виявити _олу а, які не заходили в систему 60 днів, тобто є неактивними. Ці _олу а повинні бути знищені для запобіганню появі вразливосте |
||
|
48. Який відсоток вищого рівню в системах без активних паролів постачальників програмного забезпечення? |
Розрахунок |
Кбез паролів - кількість систем без активних паролів постачальників програмного забезпечення Кзаг - загальна кількість систем |
Багато програмного забезпечення використовують паролі “з коробки”. Ці паролі, назначені постачальником програмного забезпечення, повинні бути негайно змінені, тому що вони загально відомі та вразливі до атак |
||
|
49. Чи існує документація, яка пояснює правила контролю доступу та права для різних груп користувачів? |
Контрольний лист |
Так (1), Ні (0) |
Правила та права контролю доступу повинні бути визначені згідно з політикою та повинні бути задокументовані для майбутніх перевірок. Для ефективності, документація повинна періодично переглядатися та тестуватися |
||
|
50. Чи є регулярне переглядання прав доступу користувачів? |
Контрольний лист |
Так (1), Ні (0) |
Це є мірою для перевірки списків доступу та залежної документації для виправлення помилок |
||
|
51. Яка кількість користувачів має доступ до охоронного програмного забезпечення та не є адміністраторами безпеки. |
Розрахунок |
Кдоступу - кількість користувачів, які мають доступ до охоронного програмного забезпечення та не є адміністраторами безпеки Кадміністраторів - кількість адміністраторів безпеки |
Отриманий з попереднього метричного показника, дані для аналізу беруться зі списку контролю доступу; службовці безпеки можуть оцінити рівень доступу до охоронного програмного забезпечення |
||
|
52. Чи заходи безпеки використовуються в логах ваервола, в системах виявлення атак та VPN? |
Контрольний лист |
Так (1), Ні (0) |
Чи система дозволяє віддалений доступ та з якою метою? Чи використовується шифрування? Якщо так, чи методи шифрування були офіційно схвалені? Чи генерація ключів також безпечна? |
||
|
53. Чи зберігаються спроби входу в систему в логах? |
Контрольний лист |
Так (1), Ні (0) |
Зберігання логів є критичним, але не достатнім, якщо ці логи не аналізуються |
||
|
54. Чи Політика Безпеки ІТ визначає число спроб перед помилкою аутентифікації |
Контрольний лист |
Так (1), Ні (0) |
Чи вимоги визначення кількості невдалих спроб _олу автоматич зазначені в політиці та прийняті процедурою _олу автоматич? |
||
|
55. Чи контролюється фізичний доступ до обладнання та ІТ систем? |
Контрольний лист |
Так (1), Ні (0) |
При інсталяції фаєрволів, VPN та ін. частку системи безпеки ІТ, організація може стати уразливою до старих трюків фізичної безпеки та соціальної інженерії |
||
|
3.2 Перевірка логів безпеки |
|||||
|
56. Чи вивчаються логи активності в фаєрволах? |
Контрольний лист |
Так (1), Ні (0) |
Чи існує система або процес для вивчання активності в логах фаєрвола та аналізу даних для майбутньої діяльності? |
||
|
57. Чи вивчаються логи IDS? |
Контрольний лист |
Так (1), Ні (0) |
Чи існує система або процес для вивчання логів IDS та аналізу даних для майбутньої діяльності? |
||
|
58. Чи вивчається використання веб-сайтів? |
Контрольний лист |
Так (1), Ні (0) |
Чи використання веб-сайтів вивчається з продуктивних причин (загроза відказу сервісу)? |
||
|
59. Яка кількість неавторизованих з`єднань на протязі минулого періоду? |
Розрахунок |
Обчисліть кількість неавторизованих з`єднань на протязі минулого періоду |
В рамках визначеного періоду, обчислення кількості неавторизованих з`єднань через аналіз та вивчення логів може надати інформацію про зміни в продуктивності в часі |
||
|
60. Яка кількість закритих з`єднань? |
Розрахунок |
Обчисліть кількість закритих з`єднань за визначений період |
Так як фаєрволи надають логи (дані), закриті з`єднання можуть означати спроби атак чи небезпечні спроби з`єднання. Метричний показник показує рівень ефективності використання фаєвролів |
||
|
61. Яка кількість електронних листів, відхилених за спам чи обмеження за розміром? |
Розрахунок |
Квідхилених - кількість відхилених електронних листів Кзаг - загальна кількість електронних листів |
В залежності від кількості електронних листів, нормою є отримання низької кількості відхилених електронних листів |
||
|
62. Яких загальний розмір (в мегабайтах) відхилених електронних листів? |
Розрахунок |
Обчисліть загальний розмір (в мегабайтах) відхилених електронних листів за минулий період |
Для розуміння який об`єм каналу займають відхилені електронні листи знання загального їхнього розміру є ефективним вимірянням. Таким шляхом можна зрозуміти загрозу спам-листів для системи |
||
|
63. Який відсоток вихідних електронних листів з невідповідним вмістом? |
Розрахунок |
Обчисліть відсоток вихідних електронних листів з невідповідним вмістом за минулий період |
Фільтри вмісту часто використовуються в системі для припинення небажаного вмісту та зменшення трафіку для оптимізації каналу інтернету. Для оцінки ефективності попередження невідповідного вмісту, кількість вихідних електронних листів з невідповідним вмістом за минулий період буде представляти поточний стан, якщо вимірювати регулярно |
||
|
64. Який коефіцієнт хибно відхилених електронних листів? |
Розрахунок |
Квхибно_відхилених - кількість хибно відхилених електронних листів Квідхилених - кількість відхилених електронних листів |
Метричний показник необхідний для запобігання хибного відхилення електронних листів |
||
|
65. Чи організація використовує заходи автоматичного ведення аудиту? |
Контрольний лист |
Так (1), Ні (0) |
Аналіз логів є дуже важкою та дорогою працею, яка вимагає цілодобового спостерігання. Через це розробляються автоматизовані заходи. Але все ж таки людська експертиза є дуже важливою. Чи хто-небудь переглядає та перевіряє логи? |
||
|
66. Яка кількість закритих спроб доступу до сайту? |
Розрахунок |
В деяких організаціях чи компаніях доступ до інтернету заборонений через мережу компанії або частково заборонений для деяких сайтів. Метричний показник може надати цінні дані для виміряння збитку Політики Безпеки ІТ від обмежень |
|||
|
67. Який відсоток систем захищений від вірусів/черв`яків / троянів? |
Розрахунок |
Канти-вірус - кількість систем, які захищені анти вір. програмами Кзаг - кількість систем, які повинні бути захищені від вірусів |
Метою метричного показника є досягнення 100 відсотків. Після того, як усі система гарантовано захищені можна виконувати інші виміри. |
||
|
68. Відсоток систем з регулярними оновленнями антивірусних баз та регулярним скануванням на наявність вірусів? |
Розрахунок |
Коновлення - кількість систем з регулярним оновленням антивірусних баз (щонеділі) Кзаг - загальна кількість захищених систем |
Антивірусне програмне забезпечення вимагає регулярного оновлення антивірусних баз та керування. Простої інсталяції недостатньо, оновлення антивірусних баз та сканування повинні виконуватись автоматично чи вручну |
||
|
69. Яка кількість систем була попереджена про вірусну активність за минулий період часу? |
Розрахунок |
Обчисліть кількість систем, яка була попереджена про вірусну активність за минулий період часу |
Знаючи кількість інфікованих комп`_олу а, жорстких дисків та ін. буде свідчити про ефективність антивірусних оновлень та сканувань |
||
|
3.4 Перевірка бекапів та непередбачених обставин |
|||||
|
70. Який відсоток важливих даних в системі? |
Розрахунок |
Кважливі дані - розмір важливих даних в системі Кзаг - загальний розмір даних в системі |
Визначення найбільш важливих даних допоможе назначити для них пріоритети. Всі обчислення даних в цій секції повинні проводитись згідно з розміром даних а не кількістю файлів |
||
|
71. Для якого відсотку важливих даних періодично робляться бекапи? |
Розрахнок |
Кбекап - кількість критичних файлів, для яких робляться бекапи Кзаг - загальна кількість файлів, для яких необхідно виконувати бекапи |
Чи часто проводяться бекапи для класифікованих даних та операцій, та яка ефективність цієї процедури? Необхідно досягнути високого відсотку для того, щоб сказати, що процес бекапу є ефективним |
||
|
72. Який відсоток систем має план на випадок непередбачених обставин? |
Розрахунок |
Кплан - кількість систем, які мають план на випадок непередбачених обставин Кзаг - загальна кількість систем |
Якщо система має план, вона готова до внутрішніх/зовнішніх впливів. Але для того, щоб план був ефективний, він повинен бути задокументований та розповсюджений серед працівників |
||
|
73. Чи план на випадок непередбачених обставин тестується щорічно? |
Контрольний лист |
Так (1), Ні (0) |
Для того, щоб план був ефективним його необхідно періодично тестувати. Регулярні тесту зроблять план більш обґрунтованим та легшим в застосуванні |
||
|
74. Який відсоток систем, для яких план на випадок непередбачених обставин тестувався в минулому році? |
Розрахунок |
Ктест - кількість систем, для яких план тестувався в минулому році Кзаг - загальна кількість систем з планом |
Якщо організація має архів планів на випадок непередбачених обставин, воно повинно раз на рік тестуватися та коригуватися. |
||
|
75. Чи виконуються та документуються оцінки ризиків |
Контрольний лист |
Так (1), Ні (0) |
В поєднання з планом на випадок непередбачених обставин оцінки ризиків займають важливе місце. Повинні проводитись та документуватись певні тести та сканування на уразливості. |
||
|
76. Чи використовується система “безпеки в стані збою”? |
Контрольний лист |
Так (1), Ні (0) |
Чи система зберігає безпечний стан у разі збою? |
||
|
77. Чи обладнання зберігається від збоїв в електромережі? |
Контрольний лист |
Так (1), Ні (0) |
Електромережі створюють великий рівень ризиків через розповсюдження. Ефективність джерел електроструму, УПС чи запасних генераторів може вирішити цю проблему |
||
|
78. З якої кількості інцидентів були зроблені внутрішні звіти та звіти в юридичні інстанції? |
Розрахунок |
Обчисліть кількість внутрішніх звітів та звітів в юридичні інстанції |
Багато компаній не подають звіти до юридичних організацій для того, щоб зберегти свій імідж. Але організації повинні використовувати цей метричний показник навіть для своєї найбільш секретної інформації для отримання реалістичних результатів |
||
|
3.5 Перевірка конфігурації |
|||||
|
79. Чи існує база даних управління конфігурацією, яка періодично переглядається адміністраторами? |
Контрольний лист |
Так (1), Ні (0) |
База даних управління конфігурацією дозволяє працівникам використовувати програмне та апаратне забезпечення в мережі. Для управління мережею адміністраторі повинні добре знати її |
||
|
80. Який відсоток систем з останньою встановленою версією патчів? |
Розрахунок |
Кпатч - кількість систем за патчами Кзаг - загальна кількість систем |
Перевірка версії парчів може бути встановлена завдяки заходам сканування на вразливості чи через регулярні перевірки. Дуже важливо визначати версію патчів для виміряння рівню ефективності системи управління патчами |
||
|
81. Чи використовуються стандарти по укріпленню ОС? |
Контрольний лист |
Так (1), Ні (0) |
Укріплення ОС є дуже важливим в сьогоднішній мережі тому, що кожного дня з`являються нові уразливості та хакери намагаються отримати контроль над слабкими системами |
||
|
82. Який відсоток систем зі схваленими стандартами по укріпленню ОС? |
Розрахунок |
Ксхвалені станд - кількість систем зі схваленими стандартами Кзаг - загальна кількість систем |
Метричний показник надає інформації об ефективності застосування стандартів по укріпленню ОС. Бажан отримати 100%. |
||
|
83. Який відсоток комп`_олу а з автоматичним блокуванням дисплею? |
Розрахунок |
Кблок - кількість комп`_олу а з авто блокуванням дисплею Кзаг - загальна кількість комп`_олу а |
Автоматичне блокування дисплею є гарною мірою захисту коли дисплей залишився деякий час без уваги |
||
|
84. Який відсоток комп`_олу а може бути загружений тільки з жорсткого диску? |
Розрахунок |
Кдиск - кількість комп`_олу а, які можуть бути загружені тільки з жорсткого диску Кзаг - загальна кількість комп`ютерів |
Загрузка з USB,CD_Rom чи дискет може призвести до невизначених порушень в безпеці (привілеї адміністратора). Система має бути сконфігурована таким чином, щоб запобігти таким діям |
||
|
85. Чи відключені непотрібні сервіси на сервері? |
Контрольний лист |
Так (1), Ні (0) |
Сервери зазвичай мають набір сервісів та протоколів, багато з яких включені за умовчанням. Адміністратор безпеки повинен виключити непотрібні сервери, тому що вони є джерелом уразливостей |
||
|
86. Чи в організації існує хоча б 1 прийнятий та схвалений крипто алгоритм, який використовується в захищених системах |
Контрольний лист |
Так (1), Ні (0) |
Використання крипто алгоритмів для використання їх в засобах комунікації та конфіденційності важливих даних є необхідним. |
||
|
87. Який відсоток внутрішнього та зовнішнього захищеного зв`язку? |
Розрахунок |
Кне захищений канал - кількість відправлених та отриманих ел. листів по незахищеному каналу Кзаг - загальна кількість електронних листів |
Чи існує активне використання крипто алгоритмів? Метричний показник є дуже корисним для оцінки вимірянь ефективності крипто алгоритмів |
||
|
88. Чи можливе невизнання гарантії оригінальності в системі зв`язку? |
Контрольний лист |
Так (1), Ні (0) |
Ця система гарантує те, що відправник не зможе сказати, що він не відправляв дані. Необхідно використовувати метод, який би давав гарантію, що дані надаються з доведенням ореганальності інформації (цифровий підпис, криптографія відкритого ключа) |
||
|
89. Чи можливе невизнання факту отримання в системі зв`язку? |
Контрольний лист |
Так (1), Ні (0) |
Ця система гарантує те, що одержувач не зможе сказати, що він не одержав дані. Необхідно використовувати метод, який би давав гарантію, що дані надаються з доведенням отримання інформації |
||
|
90. Який відсоток портативних пристроїв з можливістю шифрування важливих файлів? |
Розрахунок |
Кшифр - кількість пристроїв з можливістю шифрування Кзаг - загальна кількість пристроїв |
Потративні пристрої повинні бути захищені, тому що вони вважаються більш уразливими через те, що постійно переміщуються разом зі своїми користувачами та є ризик викрадення чи залишання їх без уваги. Усі важливі файли повинні бути зашифровані на таких пристроях |
4. Побудова підходу реалізації впровадження метричних показників
Пайне (2001) запропонував 7 кроків для керуванням процесом підходу побудови метричних показників:
· Визначення цілей та об`єктів метричних показників;
· Визначення які метричні показники необхідно зібрати;
· Розвиток стратегій для генерації метричних показників;
· Встановлення еталонів та завдань;
· Визначення яким чином будуть робитися звіти о результатах метричних показників;
· Створення плану дій та дія за ним;
· Встановлення формального циклу перегляду/покращення підходу метричних показників.
Інший підхід, підхід метричних показників за стандартом NIST (Сван сон та ін. 2003), складається з 4 незалежних компонентів: Аналіз Результатів Метричних Показників, Вимірні Метричні Показники Ефективності, Практичні Політики Безпеки та Процедури, та Сильна Підтримка Управління на Верхньому рівні.
Баук (2000) представив підхід, що базується на аудиті. Він визначає кроки аудиту, як базові для метричних показників. Її підхід сприяє цілей заходів безпеки інформації та інтерфейс системи, далі виконуються кроки аудиту, тобто кроки, що перевіряють виконуються цілі заходів.
Ці різні підходи є прикладами багатьох методів, що є доступними для створення різних підходів до реалізації метричних показників. Незважаючи на різницю, всі вони базуються на важливості розуміння конструкції та встановлення цілей безпеки, які необхідно виміряти та задоволені метричними показниками.
Згідно з літературними матеріалами, метричні показники IS є неоднозначною концепцією, але вони є спробою отримати чисельні чи не чисельні значення, які описують рівень якогось атрибуту безпеки. Зміна технологій залежить від цілей безпеки та об`єкту, що вимірюється.
Існує декілька класифікацій, доступних для IS метричних показників згідно з їх використанням, користувачами чи методом або стандартом (наприклад, СС). Визначення для об`єктів безпеки та змінних методів концепцій вимірів може залежати від зони та концептуального оточення. Класифікація за Хеннінгом (2001) та Катцке (2001) були обговорені для розуміння різноманіття зон.
5. Огляд підходу впровадження метричних показників безпеки
Підхід до реалізації метричних показників безпеки всередині організації повинен включати 4 незалежні компоненти:
1. Діюча підтримка осіб, що контролюють ресурси ІТ. Це є необхідним не тільки для успіху програми безпеки, але й для реалізації метричних показників, тому що береться до уваги безпека на найвищих рівнях організації. Без твердого фундаменту ефективність метричних показників безпеки може підвести в разі обмеження бюджету;
2. Практичні політики та процедури безпеки. На цьому рівні плануються процедури та політики, які можна досягти в ході впровадження метричних показників та які зможуть забезпечити дійсну безпеку через відповідні заходи;
3. Метричні показники ефективності. Розробка та встановлення метричних показників виконується для збору даних, на підставі яких робляться висновки про ефективність існуючих заходів безпеки. Вимірні метричні показники повинні враховувати при аналізі даних цілі та об`єкти діяльності безпеки ІТ та повинні бути легко доступні. Також вони повинні бути корисними для відслідковувався діяльності та керування ресурсами;
4. Аналіз результатів метричних показників. Метричні показники безпеки повинні виконувати послідовний періодичний аналіз даних вимірювання. Результати цього аналізу використовуються для покращання ефективності існуючих заходів безпеки та планування нових заходів безпеки для нових вимог безпеки, які можуть з`явитися. Всебічна програма аналізу метричних показників безпеки повинна забезпечити незалежне обґрунтування рішень, які впливають на стан безпеки організації. Ці рішення включають бюджет та розміщення доступних ресурсів. Метричні показники безпеки повинні забезпечувати точний базис для підготовки необхідних звітів про рівень безпеки.
6. Основа впровадження метричних показників безпеки ІТ
Метричні показники використовуються для того, щоб спростити процедуру прийняття рішень та покращити продуктивність та облік шляхом збору, аналізу доречних даних, пов`язаних з роботою. Ціль аналізу полягає в спостереженні за активами та полегшенні процедури покращення в цих активах шляхом виконання коригуючих дій.
Метричні показники безпеки ІТ можуть бути використані на різних рівнях в межах організації. Детальні метричні показники, зроблені на системному рівні, можуть бути об`єднані з метричними показниками, зробленими на більш високих рівнях, що залежать від розміру та складності організації.
Метричні показники безпеки ІТ базуються на цілях та об`єктах безпеки ІТ. Цілі безпеки ІТ визначають бажані результати введення безпеки системи, такої, як “Всі службовці повинні отримати адекватні поняття формування безпеки”. Об`єкти діяльності безпеки ІТ роблять можливим досягнення цілей завдяки визначенню практик згідно з політикою безпеки, та процедур, які керують послідовним введенням заходів безпеки в організації. Метричні показники безпеки ІТ контролюють виконання цілей та функціонування об`єктів завдяки створенню певної кількості заходів безпеки, ефективності цих заходів, аналізу адекватності активів безпеки та визначенню можливих дії для покращення заходів безпеки. В ході розроблення метричних показників визначаються цілі та об`єкти федеральних, внутрішніх та зовнішніх керівництв. Далі для цілей та об`єктів визначається пріоритет для того, щоб аспекти вимірювання діяльності безпеки відповідали пріоритетам операцій в організації.
Метричні показники безпеки ІТ повинні надавати інформацію для порівняння, включаючи формули для аналізу та зміни в напрямку, використовуючи ті ж самі рекомендації.
Дані, необхідні для обчислення метричних показників, повинні бути доступні, та процес, який знаходиться під розглядом, повинен бути кінцевим. Тільки процеси, які є послідовними та повторюваними, підлягають вимірянню. Процес також може бути повторюваним та стабільним. Метричні показники повинні використовувати легко доступні дані для гарантії того, що навантаження вимірів на організацію не перевищить ціль вимірів, поглинаючи ресурси, які можуть бути необхідні в інших місцях.
Для контролю діяльності та управлінням ресурсами метричні показники повинні забезпечити відповідний напрямок діяльності в часі та пропонувати дії з покращення для проблемних зон. Адміністрація повинна використовувати метричні показники для оцінки діяльності шляхом аналізу результатів метричних показників, ідентифікації корегувальних дій та застосування цих корегувальних дій, що базуються на факторах зменшення ризику та доступних ресурсах. Метричні показники розробляються з метою ідентифікації причин низької продуктивності та пропонування дій для покращення цього фактору.
Метричні показники безпеки мають ряд організаційних та фінансових переваг. Організації можуть покращити облік безпеки, використовуючи метричні показники безпеки ІТ. Процес збору даних та складання звіту дозволить керувати специфічними технічними, операційними чи адміністративними заходами, які не були реалізовані чи були реалізовані неправильно. Метричні показники безпеки ІТ можуть бути створені для того, щоб оцінити кожен аспект безпеки організації. Використовуючи аналіз метричних показників менеджери програм та власники системи можуть виділити проблеми, використати зібрані дані для виправдання інвестиційних запитів та витрачати інвестиційні кошти саме на ти специфічні зони, які необхідно покращити. Застосовуючи метричні показники для інвестицій безпеки, організації можуть отримати найбільшу користь з доступних ресурсів.
7. Види метричних показників
Зрілість програми безпеки ІТ організації визначає тип метричних показників, які можуть бути успішно зібрані (рисунок 7.1).
Рисунок 7. 1 - Зрілість програми безпеки та типи вимірів
Зрілість програми визначається існуванням та рівнем розвитку процесів та процедур. В ході дозрівання програми безпеки її політики стають більш детальними та краще документованими, процеси, які використовує програма, стають більш стандартизованими, вони виробляють дані, які можуть бути використані для оцінки продуктивності. Згідно NIST SP 800-26, програма безпеки розвивається наступним чином:
1. Визначення політики;
2. Визначення процедур;
3. Реалізація процедур та заходів безпеки;
4. Тестування процедур та заходів безпеки;
5. Інтеграція процедур та заходів безпеки.
Зрілість програми завжди вимагає контролю, щоб задокументувати та визначити кількість різних аспектів її продуктивності. Через зменшення кількості даних, процес оцінки ускладнюється, та необхідність в автоматизованому зборі даних збільшується. Автоматизація збору даних залежить від доступності даних з автоматизованих джерел. Ручний збір даних включає розвиток анкетного опитування та проведення _олу а`ю з персоналом організації. Більш корисні дані стають доступні з _олу автоматичних та автоматичних джерел, таких, як системи самооцінки, бази даних сертифікатів та акредитацій, включаючи бази даних звітів та відповідей та інші джерела даних, в процесі дозрівання програми безпеки. Метрика збору даних є повністю автоматизована, коли всі дані збираються, використовуючи автоматизовані джерела даних без людського втручання.
Типи метричних показників (результативність, ефективність, збиток), які дійсно можуть бути отримані та які можуть бути корисними для покращення продуктивності, залежать від зрілості реалізації заходів безпеки. Також різни типи метричних показників можуть бути використані одночасно, головна ціль метричних показників безпеки ІТ змінюється, як тільки реалізація заходів безпеки стає більш зрілою. Коли система досягає рівня 1 та рівня 2, результати цих метричних показників будуть менші за 100 %, показуючи, що система ще не досягла рівня 3. Коли результати реалізації метричних показників досягають та залишаються на 100%, система повністю реалізувала заході безпеки та досягла рівня 3.
Після документації та розробки заходів безпеки покращується здатність збирати надійні результати їх застосування. Як тільки програма безпеки ІТ організації розвивається та більше даних з продуктивності стають доступними, метричні показники будуть фокусувати свою діяльність на ефективності програми - своєчасність роботи сервісів безпеки та ефективність - експлуатаційні результати застосування заходів безпеки. Як тільки безпека інтегрується в процеси організації, процеси стають самовідновлюючимися, збір даних для оцінки стає повністю автоматизованим, та збиток дій, пов`язаних з безпекою, може бути визначений шляхом аналізу кореляційної залежності даних.
Метричні показники на рівнях 4 та 5 концентруються на вимірі ефективності застосованих заходів безпеки та збитку від цих заходів для дій організації. Ці метричні показники беруть до уваги результати тестування. Замість оцінювати те, який процент планів безпеки є схваленим, метричні показники концентруються на ствердженні де заходи безпеки є ефективними в захисті активів організації. Наприклад, обчислення проценту зламаних паролів за визначений проміжок часу буде підтверджувати ефективність політики організації щодо паролів шляхом виміру часу, необхідного для розкриття паролів. Метричні показники збитку будуть рахувати кількість інцидентів, таких як загроза користувача з правами root, загроза паролю, зловмисний код, відмова в обслуговуванні та пов`язувати кількість даних з процентом користувачів та системних адміністраторів щоб оцінити збиток. Нижче наведені основні визначення, що стосуються метричних показників.
Метричні показники безпеки-це заходи, створені для полегшення прийняття рішень та покращення ефективності та обліку через збір та аналіз зібраних даних, що впливають на ефективність заходів безпеки.
Метричні показники результативності - використовуються для порівняння зібраних оцінок заходів безпеки з заданими, якщо вони визначені, та ідентифікації різниці між фактичною та запланованою результативністю.
Метричні показники ефективності - використовуються для оцінки експлуатаційних результатів застосування заходів безпеки.
Метричні показники збитку - використовуються для оцінки необхідних для реалізації заходів безпеки ресурсів.
Заходи безпеки - це адміністративні, експлуатаційні та технічні заходи, встановлені в інформаційній системі для захисту конфіденційності, цілісності та доступності системи та її інформації.
Інформаційна система - дискретна множина інформаційних ресурсів, організована для збору, обробки, експлуатації, використання, розповсюдження та розміщення інформації.
Об'єкти безпеки - конфіденційність, цілісність та доступність.
Доступність - гарантія своєчасного та надійного доступу до інформації та її використання.
Конфіденційність - авторизація на доступ до інформації та її розкриття, включаючи заходи для захисту персональної секретності.
Цілісність - захист від несанкціонованої модифікації чи знищення інформації.
8. Реалізація впровадження метричних показників безпеки
8.1 Фактори успіху
Деякі фактори збільшують успіх впровадження метричних показників безпеки ІТ. Успіх досягається, якщо метричні показники організовані та застосовані з урахуванням специфічної структури організації, процесів та при розумних обмеженнях ресурсів.
8.1.1 Організаційний розгляд
Співвласники системи повинні бути включені в розвиток метричних показників безпеки ІТ та їх застосування. Працівники організації, які не відповідають за безпеку ІТ але взаємодіють з безпекою ІТ (керування ресурсами, юридичний відділ), повинні також бути включені в процес. Якщо існує працівник організації, який відповідає за ефективність оцінки в цілому, розвиток та застосування метричних показників безпеки ІТ повинні координуватися з цією особою. Якщо існує процес, який ухвалює запити даних та дії в організації, розвиток та застосуванні метричних показників безпеки ІТ повинен підпорядковуватися цьому процесу.
8.1.2 Керованість
Дуже важливим фактором успіху є керованість метричних показників. Результат багатьох дій з безпеки може бути проаналізований та використаний для оцінки продуктивності метричних показників; однак через те, що ресурси є обмеженими та більшість з них буде використана для виправлення пробілів в продуктивності, організації розставити пріоритети в вимогах з оцінки для гарантії того, що зібрана обмежена кількість метричних показників. Це значення повинно бути між 5 - 10 метричними показниками одночасно. Як тільки підхід метричних показників дозріває цільові рівні оцінки досягнуті, старі метричні показники повинні бути знищенні та нові метричні показники, які вимірюють ефективність більшої кількості елементів, повинні застосовуватися. Нові метричні показники також будуть потрібні, якщо ціль організації перевизначається чи, якщо були проведені зміни в політиці безпеки та охороні.
8.1.3 Підприємства управління даними
Для встановлення кількості та термінів дії даних повинні бути стандартизовані методи збору даних та сховища даних, які використовуються метричними показниками збору даних. Термін дії даних встановлюється, якщо головним джерелом є база даних, яка зберігає тільки інформації про деякі елементи організації чи якщо процеси складання звітів між організаціями не узгоджені. Коли організації розробляють та застосовують процеси, які можуть бути використані для підходу реалізації метричних показників безпеки ІТ, вони повинні гарантувати те, що збір даних та розробка звітів чітко визначені.
Організації повинні розуміти, що вони можуть збирати велику кількість даних з безпеки ІТ, але не всі дані будуть користі для метричних показників. Будь-який збір даних, визначений для цілей метричних показників безпеки ІТ, повинен буди якомога більше корисний для гарантії того, що доступні ресурси насамперед використовуються для корекції проблем, а не для збору даних. Встановлення метричних показників вимагає великих інвестицій для гарантії того, що метричні показники належним чином розроблені. Ресурси, необхідні для підтримки метричних показників, повинні бути незначними.
8.2 Технологія розробки та застосування метричних показників
Для організації роботи метричних показників по черзі виконуються два процеси: розробка метричних показників та застосування метричних показників. Процес розробки встановлює набір метричних показників та обирає ті метричні показники, які є адекватними для організації в даний час. Процес застосування керує метричними показниками, які є повторюваними, та гарантує те, що відповідні аспекти безпеки ІТ оцінені для заданого періоду часу.
8.2.1 Процес розробки метричних показників
На рисунку 8.1 показане місце метричних показників безпеки ІТ в структурі організації та демонструє те, що метричні показники безпеки ІТ можуть бути використані для реалізації більш прогресивної оцінки ефективності, результативності, збитків активів безпеки ІТ в рамках організації чи систем.
Рисунок 8.1 - Процес розвитку метричних показників безпеки ІТ
Процес розробки метричних показників ІТ складається з двох головних дій:
1. Ідентифікація та визначення поточної програми безпеки ІТ;
2. Розробка та вибір метричних показників для оцінки використання, ефективності, результативності та збитку заходів безпеки.
Подобные документы
Аналіз ринку зубних паст. Загальні відомості про гігієнічний засіб, характеристика вихідних компонентів. Асортимент, класифікація та призначення зубних паст, підбір сировини для виробництва. Визначення органолептичних показників пінного числа і стійкості.
курсовая работа [788,4 K], добавлен 16.05.2019Огляд сучасного стану текстильної промисловості України. Загальна характеристика заданого асортименту тканини. Розгляд основних правил підбору виду переплетення для заданого асортименту. Визначення структурних показників та проектування кромок тканини.
курсовая работа [339,7 K], добавлен 19.09.2014Особливості та переваги потокового виробництва деталей. Розрахунок кількості обладнання, його завантаження та ступеню синхронізації операцій технологічного процесу. Розрахунок техніко-економічних показників потокової лінії. Собівартість та ціна деталі.
курсовая работа [153,1 K], добавлен 10.02.2009Порівняння техніко-економічних показників різних типів дробарок. Підбір дробарки першої та другої стадії подрібнення. Класифікація конусних дробарок. Визначення обертової частоти конуса. Опис конструкції конусної дробарки, визначення її продуктивності.
курсовая работа [934,3 K], добавлен 29.12.2014Зміни показників надійності тракторів і їх складових в експлуатації. Характеристика станів і формування експлуатаційних несправностей. Закономірності зношування з'єднань і гранично допустимий стан. Зовнішні ознаки типових відмов і їхні можливі причини.
реферат [986,2 K], добавлен 19.03.2010Тривалість лабораторних занять, вимоги до їх виконання, оформлення. Перелік тематик. Вивчення показників якості промислової продукції. Дослідження показників контролю якості, основ сертифікації. Класифікатор державних стандартів, складання технічних умов.
методичка [2,0 M], добавлен 18.12.2010Випробування гум на стійкість до дії рідких агресивних середовищ (відмінність фізико-механічних показників до та після набрякання). Визначення втомної витривалості гум (показники випробування). Випробування гум на багаторазовий стиск, на подовжний згин.
реферат [337,2 K], добавлен 21.02.2011Визначення поняття технопарку, його сутність, особливості формування та управління, базова схема засновників, структура, завдання та аналіз переваг. Загальна характеристика основних технопарків Європи та України, а також оцінка їх показників діяльності.
реферат [103,5 K], добавлен 27.05.2010Застосування неруйнівного контролю для визначення показників якості матеріалів без порушення їх властивостей та функціонування. Класифікація сигналів та методів дефектоскопії. Аналіз придатності виробів на підставі норм бракування та умов експлуатації.
курсовая работа [283,3 K], добавлен 11.09.2014Визначення пластоеластичних властивостей пластометричним та віскозиметричним методами. Визначення кінетики ізотермічної вулканізації за реометром Монсанто. Контроль якості пластмас і еластомерів, розрахунки кількісних показників якості, методи оцінювання.
реферат [936,1 K], добавлен 22.02.2011
