Аналитические методы анализа защищённости информационных систем

Призы для победителей конкурса предоставил компьютерный интернет магазин 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