Аналітичні методи аналізу захищеності інформаційних систем

Наша взаимовыгодная связь https://banwar.org/

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

Призи для переможців конкурсу надав комп'ютерний інтернет магазин www.PlanetaShop.ru ,
тел .: (095) 795-0903.

Автор: Michael _ X

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

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

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

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

Введемо такі визначення і допущення, які будуть в подальшому мною використовуватися:

1. Життєвий шлях програмно-технічного засобу буде оцінюватися мною в кількості випущених виробником версій і модифікацій;
2. Підрахунок кількості версій ведеться не за фактом виникнення, а за статистикою дроблення від самого малого розряду, до найбільшого. Оскільки процес пошуку версій програмно-технічного засобу за фактом є досить трудомістким, але при цьому веде до більш суворим і точним результатами досліджень;
3. Види і типи вразливостей класифікуємо наступним чином:
   • Low - уразливості типу «підняття локальних привілеїв», але не до local system;
   • Normal - уразливості, що заважають нормальному функціонуванню системи і призводять до виникнення DoS, уразливості призводять до підняття локальних привілеїв до local system;
   • High - уразливості, що дозволяють зловмисникові отримати віддалений контроль над системою.
4. 4. Ставлення вразливостей певного класу до кількості версій буде вимірюватися в поинтах. Один поінт буде характеризувати кількість вразливостей даного типу, що припадають в середньому на одну версію програмно-технічного продукту.

аналіз ProFTPD

Перелік уразливих версій:

1.2.0 rc 1 Версії схильні до вразливостей типу Normal 1.2.0 rc 2 1.2.4 1.2.9 rc 3

1.2.7 rc 3 Версії схильні до вразливостей типу High 1.2.9 rc 1 1.2.7 1.2.8 1.2.8 rc 1 1.2.8 rc 2 1.2.9 rc 1 1.2.9 rc 2 1.2.9 rc 3

Виходячи із прийнятого методу визначення життєвого шляху програмно-технічного продукту, має 90 версій ProFTPD.

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

Уразливість сервісу по типу Low - поінтів.

Уразливість сервісу по типу Normal - поинта.

Уразливість сервісу по типу High - поинта.

Аналіз Serv-U FTP

Перелік уразливих версій:

4.1 Версії схильні до вразливостей типу Low

2.5e Версії схильні до вразливостей типу Normal 4.0 4.2 3.x 4.x 5.x

3.x Версії схильні до вразливостей типу High 4.x 5.x

Виходячи із прийнятого методу визначення життєвого шляху програмно-технічного продукту, має 50 версій Serv-U FTP.

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

Уразливість сервісу по типу Low - поинта.

Уразливість сервісу по типу Normal - поинта.

Уразливість сервісу по типу High - поинта.

Можна ще спробувати звести ці три класифікації (Low, Normal, High) в одну єдину оцінку, але вже зараз помітна тенденція, в якій явно програє Serv-U FTP.

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

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

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

укладення

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

література

1. www.securitylab.ru
2. www.serv-u.com
3. www.proftpd.org
4. www.securityfocus.com