авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 || 3 |

«НОВИНКИ НАУЧНОЙ ЛИТЕРАТУРЫ (выбор редакции) Вышла в свет монография «Высокие технологии в США: Опыт министерства обороны и ...»

-- [ Страница 2 ] --

исторического, учитывающего ретроспекти вой стадии, может вызвать сложности в эксплу атации, затруднить экономичное изготовление вы и перспективы развития системы.

элемента СБО КИИ в заданные сроки. При формировании требований к СБО КИИ не Невозможность или нецелесообразность от- обходимо также учитывать особенности решения мены на последующих стадиях создания СБО КИИ проблемы. Следует отметить, что определение всей ранее принятых решений, неопределенность в совокупности характеристик СБО не может быть некоторых случаях будущих условий эксплуата- полностью сведено к системе формализованных ции, отмеченная ранее, постоянно возрастающая процедур, так как многие из них требуют, прежде сложность КИИ, необходимость сокращения сро- всего, качественного анализа. Существенную по ков ее разработки по причине быстрого мораль- мощь в решении таких вопросов оказывает исполь ного старения, требуют применения методов си- зование одного из основных эффективных методов стемного подхода. системного анализа - метода структуризации, осно Необходимость использования методов си- ванного на расчленении исследуемой проблемы стемного подхода связана также с методологи- на элементы, конкретизации целей СБО КИИ, пути и ческими особенностями решения проблемы, средств их достижения, предусматривающего при которые заключаются в необходимости рассмо- влечение компетентных экспертов для выявления трения совокупности взаимосвязанных элемен- различных способов и средств решения конкрет тов, учета большого количества неформализуе- ных задач. Анализ проблемы с использованием мых факторов, широком использовании методов метода структуризации должен рассматриваться прогнозирования и методов экспертных оценок, как стадия, предшествующая разработке взаимос необходимости учета высокой степени неопре- вязанной системы конкретных моделей и методов деленности, многокритериальности решаемой обоснования принимаемых решений.

проблемы, необходимости генерирования аль- При решении проблемы формирования тре тернативных целей с последующей декомпози- бований к СБО КИИ необходимо учитывать такие цией на частные задачи и альтернативных вари- принципы системного анализа, как:

антов СБО КИИ. принцип первичности функции по отношению Всестороннее исследование проблемы воз- к структуре СБО КИИ и ее характеристикам, можно только при использовании в совокупности подчиненность характеристик СБО КИИ основ следующих аспектов системного подхода: ным функциям, выполняемым КИИ, функционального, определяющего функции, необходимость рассмотрения различных ва которые должна выполнять СБО КИИ и ее элемен- риантов этих требований для отбора тех, которые ты, и изучающего функциональные зависимости обеспечивают выполнение стоящих перед КИИ между элементами системы;

задач при наименьших затратах.

элементного, предусматривающего изучение С учетом изложенных аспектов системного состава системы на основе выделения ее элемен- подхода и стадий жизненного цикла СБО КИИ тов, взаимодействие которых обеспечивает при- последовательность решения рассматриваемой сущие системе качественные особенности. Это проблемы может состоять из следующих основ изучение необходимо для обоснования анализа ных этапов:

и обеспечения на основе последующего синтеза формирование облика СБО КИИ;

целостности системы;

определение целей задания требований, по структурного, предполагающего изучение строение дерева целей и выбор путей их дости внутренних связей и взаимодействия элементов жения, разработка требований и значений харак системы и устанавливающего структуру системы, теристик СБО;

цель для каждой ее структурной части. Этот аспект оценка альтернативных вариантов СБО КИИ, является одним из важных, определяющим впо- выбор варианта требований к СБО КИИ и характе следствии принимаемые технические решения;

ристикам СБО для их задания в ТТ.

интегративного, предусматривающего изуче- Остановимся подробно на перечисленных основ ние системообразующих механизмов, присущих ных этапах формирования требований к СБО КИИ.

данной системе, факторы, обусловливающие ее Облик СБО КИИ формируется с учетом резуль функционирование и развитие;

татов прогноза их развития и имеющихся научно Анализ и синтез требований к системам безопасности объектов...

исследовательских и проектно-поисковых прора- ональным вариантам отдельных конструктивно боток. При этом предварительно устанавливаются схемных (компоновочных) решений ее элементов.

структура перспективной КИИ (перечень наиме- Для определения наиболее вероятного на нований и количество составных частей, возмож- правления развития СБО КИИ необходимо:

ные функционально-конструктивные решения), оценить возможность качественного скачка условия эксплуатации (перечень характеристик, в развитии систем на основе новых технических определяющих условия использования и включа- идей. Такое развитие наиболее вероятно в случа ющих характеристики среды, в которой должны ях, когда характеристики СБО достигли предель действовать системы, и характеристики вероят- ных значений при имеющемся заделе новых раз ного внешнего воздействия). Для проведения работок, запатентованных идей, появились конку дальнейших исследований на рассматриваемом рентоспособные решения в смежных или других этапе целесообразно уточнить время, отведенное отраслях техники, резко изменились требования на создание системы, условия ее развертывания заказчика;

(ожидаемые темпы ввода), ожидаемый гарантий- оценить возможность развития СБО КИИ на ный срок службы системы. базе прежних решений за счет улучшения отдель Следующим этапом решения проблемы фор- ных их характеристик;

мирования требований к СБО КИИ в соответствии определить характеристики ожидаемых усло с принципами системного подхода является фор- вий развития КИИ в рассматриваемый период, а мирование основных целей функционирования также установить общий ход развития их СБО.

системы. При формировании целей необходимо При рассмотрении состава требований к СБО учитывать, что они должны в максимальной сте- КИИ целесообразно выделить характеристики, пени соответствовать перспективным возмож- требования к которым достигли предельно воз ностям, вытекающим из сложившихся тенденций можных значений, и характеристики, требования научно-технического развития, и будущим по- к которым установлены действующими норматив требностям заказчика. При этом выполнение ос- ными документами. Это позволит определить со новных целей должно обеспечивать достижение став остальных характеристик, требования к кото главной цели функционирования СБО КИИ, кото- рым могут прогнозироваться. Прогнозирование рая подчинена задачам, стоящим перед создава- должно осуществляться с учетом видов и объема емыми КИИ. Состав основных целей для создава- ресурсов, необходимых для создания СБО КИИ емой конкретной КИИ согласовывается с заказчи- с этими характеристиками, и дефицитности от ком и при необходимости корректируется. Таким дельных ресурсов. При этом следует определить образом, осуществляется итеративный процесс прогрессивность и перспективность требований согласования, который дает возможность более к характеристикам СБО. С этой целью на основе полно установить цели, изменить или определить использования результатов проводимых научно их заново. исследовательских работ по перспективам разви С учетом основных целей функционирования тия СБО КИИ оценивается длительность периода, СБО КИИ на основе использования принципов в течение которого они будут в состоянии отве системного анализа строится нормативное де- чать на возрастающие со временем требования рево целей и путей их достижения (структурная к ним, а также учитывается влияние задаваемых модель), которое охватывает элементы системы (с требований к характеристикам СБО на характери учетом их взаимосвязи) и этапы их эксплуатации. стики применения.

На основе количественного и качественного Таким образом, изложенный подход к опре анализа передового отечественного и зарубеж- делению требований к СБО КИИ наряду с учетом ного опыта, тенденций развития науки и техники, перспектив технического прогресса стимулирует имеющегося задела новых разработок и их ин- освоение новых технических идей.

женерного анализа, уровня проработанности за- Необходимым и важным условием в решении патентованных идей, возможностей промышлен- проблемы формирования требований к СБО КИИ ности при сроках, отпущенных на создание КИИ, является проверка достижения поставленных ос необходимо оценить возможность реализации новных целей задания требований. Достижение зафиксированных в деревьях целей и путей их до- основных целей может быть оценено по обоб стижения. щенным характеристикам, к которым следует от Построенное дерево целей позволяет опреде- нести показатели надежности, временные (сум лить возможный состав требований к СБО КИИ и, марное время приведения КИИ в готовность к кроме того, возможные рекомендации по раци- применению, максимальная продолжительность Безопасность ключевых систем устранения неисправностей, периодичность и К основным особенностям этого этапа ис продолжительность технического обслуживания, следований следует отнести необходимость по периодичность проверок систем и т. д.) и ресурс- строения формализованных моделей СБО КИИ ные показатели. и процесса ее функционирования, учета данных Обобщенные характеристики могут быть экспериментов, проводимых разработчиками на определены с помощью соответствующих мате- ранних стадиях создания СБО КИИ, учета про матических моделей, которые конкретизируются шлого опыта при исследовании аналогичных КИИ для каждого нового образца КИИ. Эти характери- и определение возможности его использования стики должны определяться для одной КИИ или для новых типов СБО КИИ, направленность ре всей совокупности создаваемых КИИ в условиях зультатов исследования на обеспечение приня их развертывания по прогнозируемым значени- того решения. Основу данного этапа составляют ям частных количественных эксплуатационных методы математического моделирования.

характеристик. Задача выбора варианта требований СБО к КИИ Из полученного множества характеристик це- относится к задачам теории принятия решения по лесообразность задания требования к каждой нескольким критериям. Формальным обобщени из обобщенных и частных характеристик может ем процесса выбора решений служит векторная быть оценена экспертным методом. При этом, как модель оптимизации общего вида показывает опыт задания требований и отработ ки СБО КИИ, необходимо учитывать: Wo = opt W(x) возможность прямой оценки выполнения тре бований по данной характеристике СБО. Предпо- где:

оптимальное ре Wo чтение следует отдавать требованиям, степень шение реализации которых можно оценить прямым путем на всех стадиях создания СБО КИИ. Этому вектор х = ( х 1, х 2, …, х к) частных эксплуатационных требованию должна быть подчинена и форма за- х Dх требований, a D х дания требований к характеристикам СБО;

подмножество их имеющийся опыт задания и отработки требо допустимых значе ваний к существующим СБО КИИ, а также возмож ний;

ности их оценки за сроки, отведенные на ее отра вектор обобщенных W = (W 1, W 2, …, W n ) ботку;

эксплуатационных W DW относительную важность требований. Предпо требований, a D W чтение отдается тем требованиям, которые влия - подмножество их ют на выполнение нескольких основных целей.

допустимых значе В общем случае в результате отбора требова ний;

ний получается несколько их альтернативных ва оператор оптими opt риантов, из которых для последующего анализа зации вектора W, необходимо отобрать варианты, удовлетворяю имеющий смысл щие ограничениям на разработку СБО КИИ, опре отношения порядка деляемым и согласовываемым с заказчиком. Таки и определяющий ми ограничениями, например, могут быть: правила выбора сроки разработки, изготовления и ввода систе- принципов опти мы в эксплуатацию;

мального решения, суммарные затраты на проектирование, раз- позволяющих учи тывать качество работку, производство и развертывание СБО КИИ;

решения по всем затраты на эксплуатацию совокупности созда рассматриваемым ваемых КИИ;

обобщенным тре численность личного состава и его загрузка и др.

бованиям.

Таким образом, на этом этапе конкретизирует ся облик СБО КИИ, осуществляется ее формали- Реализация данной модели может быть про зованное описание и анализ требований, опре- ведена любыми способами и не обязательно с деляющих достижение поставленных целей, осу- использованием математической модели оптими ществляется исследование функционирования зации, но обязательно при участии лица, прини вариантов СБО КИИ с определением оценок ее мающего решение.

обобщенных характеристик. В том случае, если представляется возмож Анализ и синтез требований к системам безопасности объектов...

ность выделить в качестве главной (доминирую- системы и др.

щей) одну из обобщенных характеристик (напри- Окончательный вариант требований к СБО мер, численность личного состава), а на осталь- создаваемой КИИ, выбираемый на основе про ные требования наложить ограничения, то выбор водимых работ, согласовывается с заказчиком и наилучшего варианта из числа допустимых (соот- включается в ТТ.

ветствующих наложенным ограничениям) произ- Таким образом, предлагаемая структура про водится по главному требованию. цесса формирования требований к СБО пер Выбранные таким образом варианты требова- спективных КИИ учитывает условия наиболее ний к СБО КИИ предлагаются в виде технических эффективного применения СБО КИИ на основе требований (ТТ) для проработки предприятиям- научно-технического прогнозирования развития разработчикам на стадиях проведения научно- СБО и использования результатов выполнения исследовательских (проектно-поисковых) работ и проблемных фундаментальных исследований, на разработки технических предложений. учного обобщения опыта разработки и эксплуата Целями такой проработки являются: ции существующих КИИ, исследований патентной обоснование научных, экономических и орга- и технической документации, анализа техниче низационных возможностей создания СБО КИИ с ских предложений разрабатываемых КИИ, новей характеристиками, удовлетворяющими требова- ших достижений и перспектив развития отече ниям ТТ;

ственной и зарубежной техники.

анализ возможности разработки системы с бо- При разработке СБО КИИ первичным является лее высокими, чем заданные, характеристиками целевой анализ, т.е. выявление цели (целей) СБО СБО, а также сравнения создаваемой СБО КИИ по КИИ, уяснение того, что объективно нужно для основным эксплуатационным характеристикам обеспечения требуемой эффективности КИИ, ха с другими существующими и разрабатываемыми рактеризующейся совокупностью показателей.

отечественными и зарубежными системами;

Требуемый уровень показателей эффектив выработка обоснованных предложений о вне- ности может быть достигнут только при условии сении изменений в проект ТТ. обеспечения основных характеристик СБО КИИ в Материалы технических предложений явля- течение гарантийного срока ее эксплуатации. По ются основой либо для окончательного выбора этому организация эксплуатации СБО КИИ долж варианта требований, предлагаемых для включе- на обеспечивать поддержание в течение гаран ния их в ТТ, либо для обоснования необходимости тийного срока эксплуатации требуемого уровня внесения изменений и дополнений в технические их основных характеристик.

предложения (или разработки новых технических Следовательно, в качестве показателя эффек предложений). При этом целесообразно учиты- тивности СБО КИИ на этапах применения долж вать предложения предприятия-разработчика о на быть рассмотрена вероятность выполнения внесении изменений в ТТ, а также информацию, задачи системами, которые в случайный момент содержащуюся в технических предложениях и времени могут быть подвергнуты внешнему воз включающую сведения: действию, ограничивающему возможность вы о проработках возможных вариантов СБО КИИ, полнения ими задачи.

особенностях функционирования и эксплуатации Для разработки математических зависимостей, ее элементов, обосновании основных техниче- определяющих показатель эффективности СБО ских решений и выборе варианта компоновки КИИ с учетом возможного воздействия на этапе системы, ее составных частей и основных эле- подготовки систем к применению, рассматрива ментов с учетом надежности и технико-экономи- ется сложная система, которая может находиться ческих показателей КИИ;

в одном из возможных состояний - исправное со сравнительном анализе технического уров- стояние, состояние проверки, устранение неис ня создаваемой системы с достижениями отече- правности, состояние технического обслужива ственной и зарубежной науки и техники;

ния и т. д.

структурных и функциональных схемах надеж- В процессе восстановления готовности СБО ности КИИ и ее основных элементах, расчетах ос- КИИ к применению из различных состояний воз новных показателей надежности;

можно случайное внешнее воздействие. Время возможностях унификации, стандартизации и между поступлением команды на подготовку к использования существующих и разрабатывае- применению и внешнему воздействию будем счи мых элементов СБО КИИ;

тать случайным с известной функцией распреде оценке технико-экономических показателей ления Fc(t).

Безопасность ключевых систем Предположим, что в произвольный момент Основную роль при решении задачи оценки времени tк поступает команда на выполнение за- эффективности СБО КИИ играют методы анализа дачи за заданное время t. Предполагая, что внеш- эффективности затрат. Главное назначение мето нее воздействие может помешать выполнить за- да анализа эффективности затрат заключается в дачу только на этапе подготовки к применению и том, чтобы установить связь затрат с конечным применения, можем записать следующее выра- результатом их использования, т.е. мерой вы жение для определения вероятности успешного полнения поставленной задачи. В качестве такой выполнения задачи СБО КИИ за заданное время t: меры можно использовать показатель эффектив ности СБО КИИ.

Для проведения анализа эффективности СБО перспективных КИИ необходимо определение следующих основных факторов:

где: ресурсов (материальных, людских, финан вероятность нахождения систем в i-м совых и др.) в стоимостном и натуральном состоянии выражении;

способов использования ресурсов (варианты суммарная продолжительность на СБО КИИ с учетом их особенностей);

хождения систем в i-м состоянии за время эксплуатации СБО КИИ;

конечных результатов (меры выполнения по – вероятность доведения команды на ставленных задач).

подготовку и применение за время не Общему анализу эффективности систем по более до систем;

священы многие работы. С учетом рекомендаций, вероятность подготовки к примене изложенных в этих работах, решение задачи ана нию из i-го состояния за заданное лиза эффективности системы эксплуатации КИИ время t;

проводится в такой последовательности:

вероятность успешной работы систе мы при условии, что функциониро- определяются условия эксплуатации КИИ, учи вание произведено из i-го состояния;

тываются при этом также характеристики внеш вероятность достижения заданной ней среды;

цели. определяются альтернативные варианты СБО КИИ с учетом их стоимости;

разрабатывается модель для определения за Вероятности и опре, трат, позволяющая определять стоимость вариан деляются по соответствующим методикам.

тов СБО КИИ:

Успешная подготовка систем к работе и функ ционированию за время, не превышающее t, мо жет быть осуществлена путем реализации одного из следующих событий:

где - множество характеристик СБО КИИ;

подготовка и работа систем произведены за заданное время при отсутствии случайных воз- разрабатывается модель для определения эф действий;

фективности СБО КИИ;

подготовка и функционирование системы про- анализируется соотношение стоимости и эф изведены под воздействием, которое не привело фективности СБО КИИ;

к срыву выполнения задачи, подготовка систем и производится сравнительная оценка вариан работа закончились за время, не превышающее t. тов СБО КИИ.

При оценке эффективности СБО перспектив- Процесс и результаты анализа эффективности ных КИИ на ранних стадиях их создания необхо- затрат не предопределяют выбора конкретного димо учитывать затраты на реализацию СБО КИИ, варианта по возможным способам использова поскольку ресурсы, выделяемые на ее разработку ния ресурсов.

ограничены. Необходимость учета затрат накла Задача анализа заключается лишь в том, чтобы дывает дополнительные требования на оценку выделить возможные и целесообразные вариан эффективности СБО КИИ. Задача в этом случае ты СБО КИИ и получить и исходные данные для сводится к задаче поиска компромисса между ха принятия окончательного решения заказчиком.

рактеристиками элементов СБО КИИ.

Анализ и синтез требований к системам безопасности объектов...

Литература 1. Проект Федерального закона “О безопасности критической информационной инфраструктуры Российской Федерации”. Url: www.consultant.ru/document/cons_doc_PRJ_ 2. Агеев С.А., Саенко И.Б., Филиппов А.Г. Концептуальное моделирование управления доступом к информации в ключевой системе информационной инфраструктуры // Вестник Санкт-Петербургского университета ГПС МЧС России”. 2011. №4. С.55-60.

3. Бородакий Ю.В., Добродеев А.Ю. Проблемы и перспективы создания автоматизированных систем в защищен ном исполнении // Известия Южного федерального университета. Технические науки. 2007. Т. 76. № 1. С. 3-6.

4. Захаренков А.И., Лазарев В.М. Модель системы мониторинга угроз информационной безопасности // Инфор мационные и телекоммуникационные технологии. 2013. № 18. С. 54-62.

5. Калашников А.О., Ермилов Е.В., Чопоров О.Н., Разинкин К.А., Баранников Н.И. Атаки на информационно-тех нологическую инфраструктуру критически важных объектов: оценка и регулирование рисков / Под ред. чл. корр. РАН Д.А. Новикова. Воронеж: ВГТУ, 2013. 220 с.

6. Кононов А.А., Черешкин Д.С. Ключевые проблемы обеспечения безопасности Национальной информацион ной инфраструктуры//Информационное общество. 2002. Вып. 1. С. 8-18.

7. Критически важные объекты и кибертерроризм. Часть 1. Системный подход к организации противодействия / Под. Ред. В.А.Васенина. МЦНМО, 2008. 398 с.

8. Марков А.С. Модели оценки и планирования испытаний программных средств по требованиям безопасности информации // Вестник МГТУ им. Н.Э. Баумана. Сер. «Приборостроение». 2011. Специальный выпуск «Техни ческие средства и системы защиты информации». С. 90-103.

9. Математические модели и алгоритмы процессов эксплуатации сложных систем / Под общ. ред. В.А. Чобаняна и В.В. Линника. М.: ВА РВСН им. Петра Великого, 2005. 168 с.

10. Методы оценки несоответствия средств защиты информации / А.С.Марков, В.Л.Цирлов, А.В.Барабанов;

под ред. А.С.Маркова. - М.: Радио и связь, 2012. 192 с.

11. Хомяков И.В. Модель элемента системы защиты критически важного объекта // Безопасность информацион ных технологий. 2012. № 1. С. 51-57.

12. Чобанян В.А. Методы определения и контроля эксплуатационных требований к перспективным сложным си стемам. М.: ВА РВСН им. Петра Великого, 2005. 344 с.

13. Шивдяков Л.А., Соловьев С.В., Язов Ю.К. Некоторые онтологические аспекты проблемы обеспечения безопас ности информации в критически важных системах информационной инфраструктуры // Информация и без опасность. 2010. Т. 13. № 3. С. 411-414.

References 1. Proekt Federal`nogo zakona “O bezopasnosti kriticheskoi` informatcionnoi` infrastruktury` Rossii`skoi` Federatcii”.

Url: www.consultant.ru/document/cons_doc_PRJ_ 2. Ageev S.A., Saenko I.B., Philippov A.G. Kontceptual`noe modelirovanie upravleniia dostupom k informatcii v cliuchevoi` sisteme informatcionnoi` infrastruktury` // Vestneyk Sankt-Peterburgskogo universiteta GPS MChS Rossii”. 2011. No 4. pp. 55-60.

3. Borodakii` Iu.V., Dobrodeev A.Iu. Problemy` i perspektivy` sozdaniia avtomatizirovanny`kh sistem v zashchishchennom ispolnenii // Izvestiia Iuzhnogo federal`nogo universiteta. Tekhnicheskie nauki. 2007. T. 76. No 1. pp. 3-6.

4. Zaharenkov A.I., Lazarev V.M. Model` sistemy` monitoringa ugroz informatcionnoi` bezopasnosti // Informatcionny`e i telekommunikatcionny`e tekhnologii. 2013. No 18. pp. 54-62.

5. Kalashnikov A.O., Ermilov E.V., Choporov O.N., Razinkin K.A., Barannikov N.I. Ataki na informatcionno tekhnologicheskuiu infrastrukturu kriticheski vazhny`kh ob``ektov: ocenka i regulirovanie riskov / Pod red. chl.-korr.

RAN D.A. Novikova. Voronezh: VGTU, 2013. 220 p.

6. Kononov A.A., Chereshkin D.S. Cliuchevy`e problemy` obespecheniia bezopasnosti Natcional`noi` informatcionnoi` infrastruktury`//Informatcionnoe obshchestvo. 2002. Vy`p. 1. pp. 8-18.

7. Kriticheski vazhny`e ob``ekty` i kiberterrorizm. Chast` 1. Sistemny`i` podhod k organizatcii protivodei`stviia / Pod.

Red. V.A.Vasenin. MTCNMO, 2008. 398 p.

8. Markov A.S. Modeli ocenki i planirovaniia ispy`tanii` programmny`kh sredstv po trebovaniiam bezopasnosti informatcii // Vestneyk MGTU im. N.E`. Baumana. Ser. «Priborostroenie». 2011. Spetcial`ny`i` vy`pusk «Tekhnicheskie sredstva i sistemy` zashchity` informatcii». pp. 90-103.

9. Matematicheskie modeli i algoritmy` protcessov e`kspluatatcii slozhny`kh sistem / Pod obshch. red. V.A. Chobaniana i V.V. Leennika. M.: VA RVSN im. Petra Velikogo, 2005. 168 p.

10. Metody` ocenki nesootvetstviia sredstv zashchity` informatcii / A.S.Markov, V.L.Tcirlov, A.V.Barabanov;

pod red.

A.S.Markova. - M.: Radio i sviaz`, 2012. 192 p.

11. Homiakov I.V. Model` e`lementa sistemy` zashchity` kriticheski vazhnogo ob``ekta // Bezopasnost` informatcionny`kh tekhnologii`. 2012. No 1. pp. 51-57.

12. Chobanian V.A. Metody` opredeleniia i kontrolia e`kspluatatcionny`kh trebovanii` k perspektivny`m slozhny`m sistemam. M.: VA RVSN im. Petra Velikogo, 2005. 344 p.

13. Shivdiakov L.A., Solov`ev S.V., Iazov Iu.K. Nekotory`e ontologicheskie aspekty` problemy` obespecheniia bezopasnosti informatcii v kriticheski vazhny`kh sistemakh informatcionnoi` infrastruktury` // Informatciia i bezopasnost`. 2010.

T. 13. No 3. pp. 411-414.

ОРГАНИЗАЦИОННО-ТЕХНИЧЕСКИЕ ПРОБЛЕМЫ ЗАЩИТЫ ОТ ЦЕЛЕВЫХ ВРЕДОНОСНЫХ ПРОГРАММ ТИПА STUXNET Марков Алексей Сергеевич, кандидат технических наук, старший научный сотрудник, CISSP Фадин Андрей Анатольевич, CISSP Рассмотрены особенности целевых вредоносных программ (ЦВП). Приведены примеры, модель, факторы эксплуатации целевых вредоносных программ. Предложены организационно-технические меры по защите компьютерных ресурсов от целевых вредоносных программ в свете современной нормативно-методической базы.

Ключевые слова: вредоносные программы, вирусы, меры безопасности, механизмы безопасности, менеджмент информационной безопасности, кибербезопасность, кибероружие ORGANIZATIONAL AND TECHNICAL PROBLEMS OF PROTECTION AGAINSTTARGETED MALWARE SUCH AS STUXNET Alexey Markov, Ph.D., Associate Professor, CISSP Andrey Fadin, CISSP The characteristics of the target of malware are considered. The examples, model, factors of opera tion of targeted malware are shown. The organizational and technical measures to protect the computer resources from targeted malware in light of the current regulatory basis are proposed.

Keywords: malware, viruses, security measures, security controls, information security management, cybersecurity, cyberweapons, Stuxnet, Flame, Duqu Введение имели больше полуавтоматизированный характер, Как известно, 2010 год ознаменовал начало будь то демонстративные атаки на отказ в обслужи новой эпохи киберпротивоборства, касающегося вании, подмена сайтов или рассылка троянских по использования вредоносных программ промыш- чтовых приложений. Однако кибервойны вышли на ленного назначения класса Stuxnet. новый уровень после публикации информации об Высокая эффективность решения задач по успешном применении комплексных высокотехно компрометации точечных IT-целей, технологиче- логичных вредоносных программ, ориентирован ская сложность реализации подобных вредонос- ных на решение точечных задач информационного ных программ обусловили необходимость поиска противоборства, в том числе в области АСУ ТП.

и разработки новых путей обеспечения безопас- Указанные целенаправленные вредоносные ности ресурсов критических систем. Анализу этой программы (ЦВП) как вид кибероружия имеют проблемной ситуации с организационно-техни- следующие особенности:

ческой точки зрения посвящена данная статья. - избирательность цели и действий, Актуальность вредоносных программ - использование уязвимостей, в том числе уяз Кибервойны как форма проявления межгосу- вимостей 0-дня, закладок и скрытых каналов;

дарственного противостояния вошли в активную - маскировка, скрытность, криптозащита, само фазу в последнем десятилетии прошлого века (см. ликвидация;

рис.1). При этом разведывательная и деструктив- - широкая функциональность в плане решения ная составляющая компьютерных воздействий целевых задач;

Организационно-технические проблемы защиты...

Рис.1. Исторические примеры кибервойн - гибкая система репродуцирования, Рассмотрим наиболее интересные, на наш - инфраструктурная поддержка, обновление и взгляд, публичные ЦВП.

управление, Stuxnet как пример промышленного - масштабируемость, наличие СУБД атак, кибероружия - высокое качество кода, обработка некоррект ных ситуаций. Stuxnet – первое широко известное вредонос Примеры наиболее публичных подобных вре- ное программное средство, имеющее точечную доносных программ представлены на рис.2. целевую функцию компрометации конкретной Рис. 2. Лента сообщений об обнаружении фактов применения кибероружия Организационно-технические меры конфигурации АСУ ТП. CVE-2010-3338, CVE-2010-3888, CVE-2010-3889, Вредоносная программа Stuxnet была обна- CVE-2010-4252, CVE-2012-3015 и другие [1-4].

родована экспертом антивирусной компании Flame как комплекс киберразведки «ВирусБлокАда» (Республика Беларусь). В насто ящее время замечено несколько сотен тысяч за- Вредоносная программа Flame, известная так ражений, около 60% из которых – на территории же как Skywiper или Flamer, является примером Ирана, причем деструктивные функции (моди- ЦВП, ориентированной на решение конкретных фикация PLC-кода) реализованы строго избира- разведывательных задач на Ближнем Востоке, в тельно. Активный период действия программы первую очередь, в Иране. Flame был впервые опи составляет 2009-2010 гг., однако были выявлены сан учеными CrySyS (Венгрия) [5].

версии программы (Stuxnet 0.5), созданные, пред- Замечено около 700 заражений. Активный пе положительно, в 2005 г. По заявлению бывших со- риод действия составляет порядка 6 лет до мо трудников NSA и JCS DoD, указанная вредоносная мента обнаружения.

программа разработана в рамках американо-из- Flame представляет собой комплекс программ раильской операции противодействия ядерным объемом около 20 Мб (устанавливается поэтап планам Ирана.

но), в состав которого входят криптобиблиотеки, Stuxnet включает десяток выполняемых ком библиотеки архивирования, СУБД, веб-сервер, понент общим объемом в 1.2 Мб, написанных, виртуальная машина. Базовой функциональной главным образом, на языках С, С++ [1]. Базовой средой является Win32.

функциональной средой является Win32.

Ключевыми особенностями вредоносной про Отличительными особенностями Stuxnet явля граммы являются:

ются:

- использование уязвимостей, в том числе - использование уязвимостей 0-дня;

0-дня, - возможность распространения в изолиро - компрометация ЭЦП (путем атаки на MD5), ванной среде (без выхода в Интернет), посред - поиск офисных документов, проектной до ством flash-накопителей (flash-net) или собствен кументации и чертежей (например, pdf и drw ной локальной p2p-сети;

файлов), контактной информации, в том числе из - наличие компонент, подписанных похищен соцсетей, ными 2-мя ЭЦП;

- возможность перехвата аудио и экранной ин - заражение системы управления технологиче скими процессами Siemens Simatic Step7;

формации, - выполнение модификации PLC-кода на кон- - поиск и подключение к Bluetooth-устройствам, троллерах Siemens с целью деструктивного воз- - закрытая передача информации на удалён действия на физическое оборудование (ядерных ный компьютер, центрифуг) и дезинформацию операторов завода. - наличие инструментария для взлома меха Stuxnet поддерживает, как минимум, 8 спосо- низмов защиты.

бов репродуцирования, эксплуатацию более де- Что касается последнего, то в составе имеются сяти уязвимостей, в том числе программной за- средства инвентаризации, мониторинга трафика, кладки (мастер-пароля), осуществляет контроль включая подсистему сбора парольной инфор и управление через удаленные компьютеры мации, поиска остаточной информации, анализа (при обнаружении выхода в Интернет), включа- файловой системы, архивов и множества типов ет Windows- и PLC-руткиты и другие способы ма файлов, кейлогер и т.п.

скировки и скрытия, также выполняет обработку Flame может распространяться через USB ошибочных ситуаций и др. Stuxnet способен вне носители и сеть, также имеет оригинальную воз дряться в ряд системных «доверенных» процес можность обновления путем компрометации сов, в том числе инициируемых антивирусными Microsoft Windows Update.

продуктами Avira, BitDefender, Computer Associ К основным эксплуатируемым программой ates, Eset, F-Secure, Kaspersky Lab, McAfee, Syman уязвимостям относят: CVE-2010-2568, CVE-2010 tec и Trend Micro.

2729, CVE-2011-3402 [5,6].

В настоящее время описаны уязвимости, ко Работа программы обеспечивается сложной торые эксплуатировались разными релизами динамичной инфраструктурой, например, извест Stuxnet, а именно: CVE-2008-4250, CVE-2010-2549, но около сотни доменов, задействованных для CVE-2010-2568, CVE-2010-2719, CVE-2010-2729, передачи данных на командные серверы Flame, CVE-2010-2743, CVE-2010-2744, CVE-2010-2772, Организационно-технические проблемы защиты...

Факторы реализации вредоносных попеременно располагавшиеся в различных программ странах мира.

Бытуют мифы, что противодействие вредонос Несмотря на явно разведывательные цели, ным программам связано исключительно с ис Flame содержит модуль удаления файлов.

пользованием антивирусных средств, но, к сожа Sputnik - троянская программа для лению, приведенные выше примеры демонстри кибершпионажа руют обратное.

Можно назвать ряд технических факторов, из Следует отметить, что для ряда вредоносных которых складывается успех современных ЦВП:

программ, а именно: Stuxnet, Flame, Duqu, Gauss, - наличие программных закладок, главным об MiniFlame, MiniDuqu эксперты отмечают общие разом, мастер-паролей;

технологические черты, как-то: библиотеки (в том - наличие уязвимостей 0-дня;

числе open source), среды, используемые уязвимо - отсутствие своевременного закрытия извест сти, приемы противодействия средствам защиты, а ных уязвимостей;

также качество кода и др. [7-9]. В то же время, сре - нарушения политик безопасности;

ди ЦВП встречаются программы другой архитекту - другие факторы, связанные с недостаточно ры, уровня технологичности, качества реализации.

стью традиционных мер защиты.

Наглядным примером может быть троянская Часть угроз можно относительно легко исклю программа Sputnik, используемая в рамках раз чить, а часть из них требует проведения серьез ведывательной точечной кибероперации Red ных тематических исследований.

Ocrober. Целевой функцией троянской програм Перечислим технические задачи противодей мы является сбор информации, касающейся дея ствия эксплуатации ЦВП:

тельности дипломатических, правительственных, - выявление неизвестных дефектов безопасно научных организаций. Максимальное число зара сти программ путем аудита безопасности кода;

жений пришлось на нашу страну. О факте прове - сканирование известных уязвимостей;

дения данной кибероперации сделали заявление - обновления с целью устранения уязвимостей, специалисты Kaspersky Lab [10].

локализованных доверенными разработчиками Особенностями указанной вредоносной про- систем, граммы являются: - поиск и контроль активности известных клас - использование известных уязвимостей сов компьютерных вирусов и других вредонос Windows-приложений (Word, Excel, Outlook) и ме- ных программ, ханизма социальных атак, - обнаружение вторжений в соответствии с ба - сбор нескольких десятков типов офисных, зами сигнатур и паттернов;

графических, почтовых, адресных файлов, в том - выявление нарушений информационных си числе уничтоженных, стем путем тестирования на проникновение, - сбор данных со сменных носителей, дистанци- - мониторинг событий безопасности в соответ онных почтовых серверов и мобильных устройств ствии с сформулированными правилами и др.

(iPhone, Nokia, Windows Mobile), Пример технических мер противодействия - сбор параметров сетевых устройств, ЦВП приведен в табл.1.

- сложная распределенная система управле- Очевидно, что технические меры сами по себе ния (около 60 доменов). не могут обеспечить необходимый уровень без Отмечают такие особенности, как поддержка опасности. Например, информирование и обуче кириллицы и сбор файлов, закрытых с помощью ние сотрудников - важный фактор противодей Cryptofiler и PGP. ствия социальным атакам и обеспечения внима К основным эксплуатируемым программой тельности к угрозам.

уязвимостям относят: CVE-2009-3129, CVE-2010- Также важным моментом кибербезопасности является избирательность и уровень доверия к 3333, CVE-2012-0158.

поставщикам ИТ-решений. Как известно, основ Кибероперация Red Ocrober включает итераци ным методом регулирования рынка ИБ является онные атаки с участием людей, когда в очередных обязательная сертификация программного кода, атаках используются данные, полученные ранее.

когда испытательная лаборатория фиксирует ис Несмотря на то, что Sputnik не так технологиче ходные код и компоновочную среду, а в конечном ски изящен, как кибероружие класса Stuxnet, ука счете – ответственность разработчика.

занное ЦВП встречается с 2007 года по сей день.

Организационно-технические меры Таблица 1.

Примеры технических мер противодействия ЦВП Негативный фактор Защитные меры Наличие уязвимостей 0-дня Применение анализаторов кода Применение средств тестирования безопасности Применение SIEM-решений Наличие известных Применение сканеров уязвимостей (VA), а также средств контроля уязвимости обновлений («патчей») Внедрение политик по обновлению ПО Применение САВЗ, СОВ, SIEM Установка в режимах Применение сканеров уязвимостей, а также средств проверки небезопасной конфигурации конфигураций Внедрение политик по конфигурациям Применение СОВ, SIEM Внедрение вредоносного ПО с Применение СЗИ от НСД помощью съемных носителей Внедрение политик по работе со съемными носителями Применение САВЗ, SIEM Внедрение вредоносного ПО с Применение САВЗ, SIEM, систем фильтрации контента, DLP помощью методов социальной Внедрение политик по коммуникациям инженерии Определение системного подхода ся задачи и требования, проводится управление Как мы показали, исключительное использо- рисками, формируются процедуры физического, вание традиционных антивирусных решений, технического и административного характера, основанных на сигнатурном поиске, не позволя- включая работу с персоналом, что в итоге реали ет эффективно решать задачи защиты от ЦВП, т.е. зует весь жизненный цикл управления безопас необходим комплексный системный подход. Рас- ностью информации организации, ее сегментов и смотрим проблемную ситуацию на трех уровнях: подсистем [11].

- нормативный уровень;

Наиболее авторитетными в области менед - уровень менеджмента;

жмента информационной безопасности считают - технический уровень. ся стандарты серии ISO 27000. Например, ISO/IEC 27001:2013 включает 114 механизмов (controls) Нормативный уровень безопасности, объединенных в 14 классов мер:

Если эволюция в области защиты информации - политики информационной безопасности, конфиденциального характера очевидна, то нор- - организация информационной безопасности, мативный комплекс по защите государственной - безопасность персонала, тайны остается консервативным и ориентирован- - управление ресурсами, ным на директивные методы защиты, берущие на- - контроль доступа, чало еще от «Оранжевой книги» прошлого века - криптография, (DoD 5200.28-STD: 1983). Фактически, такие за- - физическая безопасность и безопасность щищенные системы предполагают наличие ком- окружения, плексных средств управления безопасным досту- - операционная безопасность, пом (СВТ), дополненных средствами межсетевого - безопасность коммуникаций, управления доступом и антивирусными средства- - безопасность поставки, разработки, сопрово ми. Несмотря на структурное единство и компакт- ждения, ность указанных документов, надо понимать, что - связь с поставщикам, внедрение современных технологий связано с - управление инцидентами информационной новыми классами угроз, в том числе угроз 0-дня. безопасности, - управление непрерывностью бизнеса в плане Уровень менеджмента информационной безопасности, Уровень менеджмента является самым важ- - соответствие нормативным требованиям.

ным в организации, т.к. на этом уровне уточняют- Правильный выбор и реализация механизмов Организационно-технические проблемы защиты...

безопасности определяют требуемый уровень - целостность информационной системы и ин защищенности от всевозможных актуальных формации, угроз, в том числе связанных с вредоносными - доступность информации, программами. - защита среды виртуализации, - защита технических средств, Технический уровень - защита информационной системы и передачи В нашей стране, как известно, кроме средств данных.

криптографической защиты, нормативно пока Указанный перечень базовых мер можно ис определены средства защиты информации он пользовать при формировании списка контрмер несанкционированного доступа (СВТ), межсете- и средств защиты конкретной информационной вые экраны (МЭ), средства антивирусной защиты системы.

(САВЗ) и средства обнаружения вторжений (СОВ), Полученный список можно усиливать соглас но планируется расширение этого списка. В то же но модели актуальных угроз и дополнительных время ФСТЭК России сформулировала в ведом- требований. К примеру, надо понимать, что уро ственном приказе № 17 (вступил в силу в сентябре вень аудита безопасности кода, декларируемый 2013 г.) перечень организационно-технических в Приказах ФСТЭК России № 21 и 17, разумеется, мер защиты информации конфиденциального ха- недостаточен для выявления уязвимостей 0-дня, рактера в государственных информационных си- т.е. указанные требования следует поднять, как стемах, а именно [12]: минимум, до 2-го уровня контроля отсутствия не - идентификация и аутентификация, декларированных возможностей (НДВ), который - управление доступом, включает проверку конструкций кода.

- ограничение программной среды, Пример организации системы защиты - защита машинных носителей информации, от целевых вредоносных программ - регистрация событий безопасности, - антивирусная защита, Рассмотрим организацию защиты на примере - обнаружение (предотвращение) вторжений, Stuxnet. Схему работы ЦВП можно представить - контроль (анализ) защищенности инфор- UML-диаграммой деятельности (см. рис1).

мации, Рис. 3. Общая схема функционирования Stuxnet Организационно-технические меры На рисунке 3 показаны основные факторы экс- - развитие научно-технического потенциала плуатации ЦВП, связанные с наличием уязвимо- страны, стей, что послужило главной причиной неэффек- - создание и усиление кибервойск, сил и тивности используемых СЗИ. средств кибервооружений, В целях противодействия внедрению и работе - смещение задач оценки соответствия от пока ЦВП предлагается внедрение комплекса органи- зателей «доверия» в направлении кибербезопас зационно-технических мер и процедур, часть из ности путем обязательного проведения тестов на которых показана в табл. 2. проникновение и аудита безопасности программ ного кода, Опыт США в области кибербезопасности - ведение черных и белых списков поставщи Следует отметить несколько моментов из за- ков.

рубежного опыта. К примеру, США - страна, нахо- Особое внимание в США уделено обязатель дящаяся в состоянии жесткого противоборства с ным системам менеджмента информационной технологической экспансией со стороны Китая. безопасности федеральных служб в соответствии Геополитические амбиции США определили не- с актом FISMA-2002.

сколько векторов развития стратегии кибербезо пасности США:

Таблица 2.

Примеры классов контрмер и средств защиты от ЦВП ISO/IEC 27001:2013, механизмы Приказ ФСТЭК России № 17, базовые Негативный фактор безопасности меры Уязвимости 0-дня A.12.4. Регистрация и мониторинг РСБ.4/5 Регистрация событий A.16.1.4. Классификация событий ЗИС.16. Скрытые каналы A.14.2.8/9. Тестирование/испытания ЗИС.27. Ложные системы A.18.2.2/3. Оценка соответствия ИАФ.7. Идентификация исполняемых модулей ОПС.4. Контроль временных файлов ОПС.1-3. Ограничения ПС НДВ.2. Усиление в части НДВ- Незакрытые известные A.12.6.1. Управление уязвимостями АВЗ.2 Обновления САВЗ уязвимости A.16.1.3. Оповещение о СОВ.2 Обновления СОВ недостатках АНЗ.1/2 Анализ уязвимостей Скомпрометированный A.9.4.3. Системы управления АНЗ.5. Правила паролей пароль паролями Идентифицируемый A.12.2.1. Защита от вредоносных АВЗ.1/2 Антивирусная защита вредоносный код программ Зараженные съемные А.6.2.1. Политика для мобильных УПД.15 Мобильные средства носители устройств ЗНИ.1-3.7. Носители информации A.8.3.1. Управление съемными носителями A.14.2.3/4. Тестирование/контроль АНЗ.2. Контроль обновлений «Недоверенные»

обновления изменений Раскрытие A.13.2.4. Соглашения о ОЦЛ.5. Контроль контента технологической неразглашении ЗИС.28. Скрытие структуры ИС конфигурации Внешнее управление A.13.1.3. Разделение сетей УПД.16. Взаимодействие между A.14.1.2. Защита от публичных сетей системами Организационно-технические проблемы защиты...

Заключение стрировала необходимость серьезного совер Факты применения ЦВП демонстрируют но- шенствования подходов в области информаци вый технологический уровень информационного онной безопасности. В частности, рекомендует противоборства в киберпространстве. Очевидно, ся комплексное решение, сочетающее развитие что в создание таких средств вовлечены чрезвы- нормативной базы, внедрение лучших практик чайно квалифицированные исследователи, раз- менеджмента информационной безопасности, работчики и тестировщики, имеющие в том числе комплексов сертифицированных средств защиты доступ к новейшим достижениям криптографии, информации, в первую очередь, средств тестиро ИТ и АСУ ТП [14-18]. вания систем защиты и мониторинга событий без Исследование указанных вредоносных про- опасности (VA- и SIEM-технологий).

грамм произошло благодаря публичной деятельно- С точки зрения кибербезопасности, первосте сти экспертов зарубежных или международных ан- пенные шаги следует сделать в направлении раз тивирусных компаний и научных заведений [1-10]. вития методологии, методов и средств тестиро Статистика многолетней скрытой активности вания на проникновение и аудита безопасности указанных вредоносных программ продемон- программного кода.

Литература 1. Larimer J. An inside look at Stuxnet // IBM X-Force. 2010. 37 p.

2. Byres E., Ginter A., Langill J. How Stuxnet Spreads. A Study of Infection Paths in Best Practice Systems // White paper by TS/AT/SH. 2011. 26 p.

3. Falliere N., Murchu L.O., Chien E. W32.Stuxnet Dossier // Symantec Security Response. 2011. 69 p.

4. Matrosov A., Rodionov E., Harley D., Malcho J. Stuxnet Under the Microscope // ESET. 2012. 85 p.

5. Skywiper: a complex malware for targeted attacks / by Skywiper Analysis Team // Technical Report by Laboratory of Cryptography and System Security. Budapest: Budapest University of Technology and Eco nomics. 2012. 64 p.

6. Walter J. Flame attacks: briefing and compromise. // White paper by McAfee Labs. 2012. 14 p.

7. Chien E., OMurchu L., Falliere N. W32.Duqu. The precursor to the next Stuxnet // Symantec Security Re sponse. 2011. 71 p.

8. Duqu: A Stuxnet-like malware found in the wild / B.Bencsth, G.Pk, L.Buttyn, M.Flegyhzi // Technical Report by Laboratory of Cryptography and System Security. Budapest: Budapest University of Technol ogy and Economics. 2011. 60 p.

9. Gauss: Abnormal Distribution // Kaspersky Lab Global Research and Analysis Team. 2012. 48 p.

10. Гостев А.А. Операция Red October - обширная сеть кибершпионажа против дипломатических и го сударственных структур // Право и кибербезопасность. 2013. № 1. С. 15-23.

11. Дорофеев А.В., Шахалов И.Ю. Основы управления информационной безопасностью современной организации // Правовая информатика. 2013. C. 4-14.

12. Требования о защите информации, не составляющей государственную тайну, содержащейся в госу дарственных информационных системах. ФСТЭК России. 2013. Рег.№ 28608. 37 с.

13. Организация антивирусной защиты: опыт МО США / А.С.Марков и С.А.Щербина // PC Week. 2007.

№44 (602). С.17.

14. Кухаркин А.В. Киберугрозы и защита информации // Научно-аналитический журнал Обозреватель Observer. 2012. Т. 273. № 10. С. 94-104.

15. Левыкин М.В. Новые особенности самораспространяющихся вредоносных программ // Системы и средства информатики. 2011. Т. 21. № 2. С. 69-72.

16. Симоненко М.Д. Stuxnet и ядерное обогащение режима международной информационной без опасности // Индекс безопасности. 2013. Т. 19. № 1. С. 233-248.

17. Тарасов А.М. Кибершпионы: Duqu, Stuxnet, Flame, Gauss: что дальше? // Право и кибербезопасность.

2012. № 1. C.23-26.

18. Фрейдман А.В. Stuxnet и промышленная безопасность. // Автоматизация в промышленности. 2011.

№ 11. С. 48-53.

Организационно-технические меры References 1. Larimer J. An inside look at Stuxnet, IBM X-Force, 2010, pp. 1-37.

2. Byres E., Ginter A., Langill J. How Stuxnet Spreads. A Study of Infection Paths in Best Practice Systems, White paper by TS/AT/SH, 2011, pp. 1-26.

3. Falliere N., Murchu L.O., Chien E. W32.Stuxnet Dossier, Symantec Security Response, 2011, pp. 1-69.

4. Matrosov A., Rodionov E., Harley D., Malcho J. Stuxnet Under the Microscope, ESET, 2012, pp. 1-85.

5. (Skywiper: a complex malware for targeted attacks), Paper by Skywiper Analysis Team, Technical Report by Laboratory of Cryptography and System Security, Budapest, Budapest University of Technology and Economics, 2012, pp. 1-64.

6. Walter J. (Flame attacks: briefing and compromise), White paper by McAfee Labs, 2012, pp. 1-14.

7. Chien E., OMurchu L., Falliere N. W32.Duqu, The precursor to the next Stuxnet, Symantec Security Response, 2011, pp 1-71.

8. Duqu: A Stuxnet-like malware found in the wild. By B.Bencsth, G.Pk, L.Buttyn, M.Flegyhzi, Technical Report by Laboratory of Cryptography and System Security, Budapest, Budapest University of Technology and Economics, 2011, pp. 1-60.

9. Gauss: Abnormal Distribution, Kaspersky Lab Global Research and Analysis Team, 2012, pp. 1-48.

10. Gostev A.A. Operatsiya Red October - obshirnaya set kibershpionazha protiv diplomaticheskikh i gosudarstvennykh struktur, (Operation Red October - a vast network of cyber espionage against diplomatic and governmental structures), Pravo i kiberbezopasnost. 2013. № 1. pp. 15-23.

11. Dorofeyev A.V., Shakhalov I.Yu. Osnovy upravleniya informatsionnoy bezopasnostyu sovremennoy organizatsii, (The Basics of Information Security Management modern organization), Pravovaya informatika, 2013, pp. 4-14.

12. Trebovaniya o zashchite informatsii, ne sostavlyayushchey gosudarstvennuyu taynu, soderzhashcheysya v gosudarstvennykh informatsionnykh sistemakh, (Requirements for protection of information that is not state secrets contained in public information systems), FSTEC Russia, 2013, Reg.№ 28608, pp. 1-37.

13. Markov A., Shcherbina S. Organizatsiya antivirusnoy zashchity: opyt DoD (The organization of anti-virus protection: the experience of the U.S. DoD), PC Week, R.Ed., 2007, No 44 (602), pp. 17-17.

14. Kukharkin A.V. Kiberugrozy i zashchita informatsii, (Cyberthreats and protection of information), Nauchno analiticheskiy zhurnal Obozrevatel – Observer, 2012, Vol 273, No 10, pp. 94-104.

15. Levykin M.V. Novyye osobennosti samorasprostranyayushchikhsya vredonosnykh programm, (New features self-propagating malware), Sistemy i sredstva informatiki, 2011, Vol 21, No 2, pp. 69-72.

16. Simonenko M.D. Stuxnet i yadernoye obogashcheniye rezhima mezhdunarodnoy informatsionnoy bezopasnosti, (Stuxnet and nuclear enrichment regime of international information security), Indeks bezopasnosti, 2013, Vol 19, No 1, pp. 233-248.

17. Tarasov A.M. Kibershpiony: Duqu, Stuxnet, Flame, Gauss: chto dalshe? (Cyberspies: Duqu, Stuxnet, Flame, Gauss: what next ?), Pravo i kiberbezopasnost, 2012, No 1, pp. 23-26.

18. Freydman A.V. Stuxnet i promyshlennaya bezopasnost, (Stuxnet and industrial safety), Avtomatizatsiya v promyshlennosti, 2011, No 11, pp. 48-53.

СТАНДАРТИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ БЕЗОПАСНЫХ ПРОГРАММНЫХ СРЕДСТВ Барабанов Александр Владимирович, CISSP, CISSLP Статья посвящена вопросам стандартизации процесса разработки безопасных программных средств, рассмотрены основные положения разрабатываемого ФСТЭК России ГОСТ Р «Защита информации. Требования по обеспечению безопасности разработки программного обеспечения».

Ключевые слова: безопасность программ, уязвимости, дефекты безопасности, сертификация THE STANDARDIZATION OF THE PROCESS OF DEVELOPING A SECURITY SOFTWARE Alex Barabanov, CISSP, CISSLP The standardization process of developing secure software are discussed. National standard GOST R «Information Security. Security requirements of software development» are considered.

Keywords: security software, vulnerability, security defects Наиболее распространенными1 типами Анализ современных тенденций в области ин формационной безопасности (ИБ) показывает, уязвимостей, выявляемых в ПС, подаваемом что на протяжении последних лет наблюдается сертификацию являются: аутентификацион устойчивый рост количества нарушений ИБ, при- ные данные в исходном коде ПС, межсайтовый водящих к снижению уровня целостности, доступ- скрптинг, внедрение SQL-кода (рис. 2).

ности и конфиденциальности информационных Уязвимости обнаруживаются как с исполь ресурсов автоматизированных систем (рис. 1). зованием методов структурного тестирования Следует отметить, что большинство наруше- (как правило, статический сигнатурный ана лиз), так и с использованием функционального тестирования (в случае отсутствия доступа к исходным кодам ПС).

До недавнего времени наблюдался некий нормативный и методический вакуум, не по зволяющий испытательным лабораториям, обоснованно и целенаправленно заниматься выявлением уязвимостей в ПС, подаваемых на сертификацию. Ситуация изменилась с введе нием ФСТЭК России нового подхода к форми Рис.1 Количество нарушений информацион- рованию требований к сертифицируемым ПС и действиям испытательных лабораторий при ной безопасности в информационных системах проведении испытаний - в настоящее время ний ИБ связано, в первую очередь, с наличием выполнение тестирования на проникновения уязвимостей в программных средствах (ПС), ис- является обязательной процедурой, которое пользуемых в автоматизированных системах. должна выполнить испытательная лаборато Опыт работы аккредитованной испытательной рия при проведении сертификационных ис лаборатории, проводящей сертификационные пытаний.

испытаний ПС в различных системах сертифика ции, показывает, что даже в продуктах, представ ляемых разработчиками на сертификацию, содер- Статистическая информация основана на результатах сертификационных испытаний, проведенных компанией жаться уязвимости и дефекты безопасности.

НПО «Эшелон».

Организационно-технические меры формационной системе системного и (или) при кладного программного обеспечения, разрабо танного с использованием методов защищенного программирования, является дополнительной мерой по обеспечению безопасности информа ции в случае определения в качестве актуальных угроз безопасности персональных данных 1-го и 2-го типов. В тоже время документ, определяю щий содержание и порядок выполнения работ по созданию программного обеспечения с исполь зованием методов защищенного программиро вания, отсутствует. Эти положения и определяют Рис. 2. Распределение дефектов безопасности актуальность разработки ГОСТ.

программного обеспечения по типам При разработке первой редакции проекта ГОСТ учитывались следующие особенности:

Следует отметить, что тестирование на про 1.  Поскольку известно, что стоимость устра никновение может выполняться как на основе нения уязвимостей и дефектов безопасности ПС анализа исходных текстов (если разработчик пре выше на поздних стадиях проектирования, ГОСТ доставляет к ним доступ), так и по методологии должен обеспечить внедрение необходимых про «черного ящика».

цедур на самых ранних стадиях проектирования При сертификации по низким классам защи ПС.

щенности общепринятой практикой является сле 2.  ГОСТ должен учитывать современные тен дующая:

денции разработки безопасных ПС, учитывать по - изучение списка известных уязвимостей, опу ложения «лучших практик» (например, Microsoft бликованных в открытых источниках (например, SDL, Cisco SDL) [4-7].

osvdb.org, securityfocus.com), и формирование 3.  ГОСТ должен быть полностью совместим с списка потенциальных уязвимостей, которые мо методологией разработки и сертификации ПС, гут быть в ПC;

используемой в настоящее время ФСТЭК России -  проверка выдвинутых гипотез относительно («Общие критерии») [3].

уязвимостей ПC (тестирование с использованием 4.  Разрабатываемый ГОСТ должен обеспечить различных инструментальных средств).

возможность интеграции процедур разработки При сертификации по высоким классам защи безопасных ПС с существующей на предприятии щенности, когда предоставление доступа к ис системой управления ИБ (например, построенной ходным кодам ПС является обязательным, тести в соответствии с ГОСТ Р ИСО/МЭК 27001 «Инфор рование на проникновение основывается на ре мационная технология. Методы и средства обе зультатах статического и динамического анализа спечения безопасности. Системы менеджмента исходного кода ПС [2, 3].

информационной безопасности. Требования») [1].

Другим важным направлением развития, наце Анализ современных методологий (Таблица 1) ленным на повышение качества ПС и уменьшение проектирования безопасных ПС позволил сфор числа уязвимостей и дефектов безопасности, яв мулировать следующий перечень процедур, ко ляется внедрение цикла разработки безопасных торые должны быть реализованы разработчи ПС. Опыт компании Microsoft показал, что внедре ком ПС:

ние цикла разработки безопасных ПС позволило - процедуры управления конфигурацией;

сократить число уязвимостей в ПС компании в - процедуры определения модели жизненного среднем на 80%.

цикла;

В настоящее время ФСТЭК России ведется ра -  процедуры проектирования и реализации бота над государственным стандартом «Защита безопасных ПС;

информации. Требования по обеспечению без -  процедуры использования инструменталь опасности разработки программного обеспече ных средств и методов разработки;

ния». Кроме этого, в соответствии с нормативным -  процедуры обеспечения безопасности раз правовым актом ФСТЭК России «Состав и содер работки;


жание организационных и технических мер по - процедуры поставки;

обеспечению безопасности персональных дан -  процедуры обновления и устранения уязви ных при их обработке в информационных систе мостей и дефектов безопасности ПС.

мах персональных данных», использование в ин Стандартизация процесса разработки безопасных программных средств В таблице 1 представлены результаты сравни- Следует отметить, что требования к реализа тельного анализа следующих методологий проек- ции большинства процедур согласованы с требо тирования безопасных ПС: «Общие критерии» [3], ваниями доверия, предъявляемыми ГОСТ Р ИСО/ Microsoft SDL [6], OpenSAMM [7]. МЭК 15408-3 (Таблица 2).

Таблица 1 – Результаты сравнительного анализа методологий проектирования безопасных ПС «Общие Open Характеристика Microsoft SDL критерии» SAMM Обучение специалистов - + + Обеспечение физической и логической безопасности при + - разработке ПС Управление конфигурацией + - Моделирование угроз + + + Определение требований безопасности к разрабатываемым + + + ПС Использование принципов безопасного проектирования + + + Анализ исходных кодов ПС - + + Анализ уязвимостей + + + Использование методов проектирования безопасных ПС - + + Обеспечение безопасности поставки + - + Таблица 2– Соответствие требований разрабатываемого стандарта требованиям ГОСТ Р ИСО/ МЭК 15408- Требование Требование ГОСТ Р ИСО/МЭК 15408- разрабатываемого стандарта Требования к функциональным ACM_CAP.1, ACM_CAP.2, ACM_CAP.3, ACM_CAP.4, возможностям системы управления ACM_CAP. конфигурацией Требования к области действия системы ACM_SCP.1, ACM_SCP.2, ACM_SCP. управления конфигурации Требования к средствам автоматизации ACM_AUT.1, ACM_AUT. процесса управления конфигурацией Требования к процедурам определения ALC_LCD.1, ALC_LCD.2, ALC_LCD. модели жизненного цикла Требования к процедурам проектирования и ATE_FUN.1, ATE_FUN.2, AVA_VLA, ADV_FSP, ADV_HLD, реализации безопасных ПС ADV_LLD, ADV_RCR Требования к процедурам использования ALC_TAT.1, ALC_TAT.2, ALC_TAT. инструментальных средств и методов разработки Требования к обеспечению безопасности ALC_DVS.1, ALC_DVS. разработки Требования к процедуре поставки ADO_DEL.1, ADO_DEL.2, ADO_DEL.3, ADO_ISG, AGD_ ADM, AGD_USR Требования к реализации процедур ALC_FLR.1, ALC_FLR.2, ALC_FLR. обновления и устранения недостатков Организационно-технические меры Отдельно рассмотрим перечень основных тре- 5.  Разработка ПС должна выполняться с ис бований к процедурам проектирования и реали- пользованием методов защищенного программи зации безопасных ПС, сформулированные по ре- рования. Например, в ходе разработки ПС разра зультатам анализа «лучших практик» и обобщения ботчик должен избегать использования скомпро опыта работы аккредитованных испытательных метированных (небезопасных) функций в исход лабораторий систем сертификации средств защи- ных кодах ПС. В качестве источника небезопасных ты информации. функций могут использоваться, например, списки 1. Должно проводиться периодическое обуче- «Security Development Lifecycle Banned Function ние сотрудников разработчика ПС с целью повы- Calls» компании Microsoft.

шения их осведомленности в области разработки 6.  Должен проводиться периодический стати безопасных ПС. Выполнение данного требования ческий анализ исходных кодов ПС с целью выяв позволяет обеспечить повышение осведомленно- ления уязвимостей и дефектов кода, результаты сти в области безопасной разработки ПС сотруд- анализа должны документироваться.

ников, связанных с разработкой ПС и, как след- 7.  Должна проводиться периодическая ин ствие, повышение уровня безопасности разраба- спекция кода с целью выявления уязвимостей и тываемых ПС. В программу обучения сотрудников дефектов кода, результаты инспекции должны до могут входит курсы безопасного программирова- кументироваться.

ния, инспекции кода, тестирования на проникно- 8.  Должно проводиться и документироваться вение, статического анализа, динамического ана- тестирование (функциональное, нагрузочное) ПС.

лиза, функционального тестирования и другие. 9.  Должен проводиться динамический анализ 2.  Разработчиком ПС должны быть определе- исходных кодов ПС с целью выявления уязвимо ны и документированы требования безопасности стей и дефектов кода, результаты анализа должны к разрабатываемому ПС. Например, могут быть документироваться.

определены следующие классы требований: тре- 10. Должно проводиться тестирование на про бования к обеспечению конфиденциальности, никновение с целью выявления уязвимостей ПС, требования к обеспечению идентификации и ау- результаты тестирования должны документиро тентификации, требования к реализации разгра- ваться.

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

зоваться следующие принцип проектирования Планируется, что будет введена некоторая гра безопасных ПС: принцип эшелонированной за- дация, которая позволит предъявлять требования щиты, принцип минимальных привилегий, прин- к организациям-разработчикам в зависимости от цип модульного проектирования, принцип раз- критичности создаваемого ПС.

деления обязанностей. Внедрение подобных процедур в российские 4. При проектировании ПС разработчиком ПС организации-разработчики ПС, на наш взгляд, должно выполняться моделирование угроз с це- повысить уровень защищенности создаваемых лью выявления уязвимостей ПС этапа проектиро- ПС и, как следствие, значительно уменьшить вания, результаты моделирования угроз должны число инцидентов информационной безопас документироваться. ности.

Литература 1. Дорофеев А.В., Шахалов И.Ю. Основы управления информационной безопасностью современной организации // Правовая информатика. 2013. № 3. C. 4-14.

2. Марков А.С., Цирлов В.Л. Сертификация программ: мифы и реальность // Открытые системы. СУБД.

2011. № 6. С. 26-29.

3. Марков А.С., Цирлов В.Л., Барабанов А.В. Методы оценки несоответствия средств защиты информа ции. М.: Радио и связь, 2012. 192 с.

Стандартизация процесса разработки безопасных программных средств 4. Building Security into Your Software Development Lifecycle. Coverity White Paper. 2012. 14 p.

5. Cisco Secure Development Lifecycle. Cisco White Paper. 2013. 4 p.

6. Howard M., Lipner S. The Security Development Lifecycle: A Process for Developing Demonstrably More Secure Software. Microsoft Press. 2006. 352 p.

7. Software Assurance Maturity Model: A guide to building security into software development. Ver. 1.0.

OWASP. 2013. 96 p.

References 1. Dorofeyev A.V., Shakhalov I.Yu. Osnovy upravleniya informatsionnoy bezopasnostyu sovremennoy organizatsii, (Basics of Information Security Management modern organization), Pravovaya informatika, 2013, No 3, pp. 4-14.

2. Markov A.S., Tsirlov V.L. Sertifikatsiya programm: mify i realnost, (Certification programs: myths and reality), Otkrytyye sistemy. SUBD, (Open Systems Journal), 2011, No 6, pp. 26-29.

3. Markov A.S., Tsirlov V.L., Barabanov A.V. Metody otsenki nesootvetstviya sredstv zashchity informatsii, Moscow, Radio i Svyaz, 2012, pp. 1-192.

4. Building Security into Your Software Development Lifecycle. Coverity White Paper. 2012. 14 p.

5. Cisco Secure Development Lifecycle. Cisco White Paper. 2012. 14 p.

6. Howard M., Lipner S. The Security Development Lifecycle: A Process for Developing Demonstrably More Secure Software. Microsoft Press. 2006. 352 p.

7. Software Assurance Maturity Model: A guide to building security into software development. Ver. 1.0.

OWASP. 2013. 96 p.

Рецензент: Гарбук Сергей Владимирович, к.т.н, доцент ОПЫТ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ В ЗАРУБЕЖНЫХ ПРОГРАММНЫХ ПРОДУКТАХ Марков Алексей Сергеевич, кандидат технических наук, старший научный сотрудник, CISSP Цирлов Валентин Леонидович, кандидат технических наук Рассмотрены вопросы безопасности импортных программах средств. Приведена статистика по выявленным уязвимостям в импортных программных продуктах. Рассмотрены общие методы выявления уязвимостей и дефектов безопасности программных средств.

Ключевые слова: безопасность программ, дефекты безопасности, уязвимости, сертификация средств защиты информации EXPERIENCE IN IDENTIFYING VULNERABILITIES IN SOFTWARE Alexey Markov, Ph.D., Associate Professor, CISSP Valentin Tsirlov, Ph.D Questions of security software are considered. The statistics on the identified vulnerabilities in the import software are submitted. The general methods for identifying security software vulnerabilities and defects are discussed.

Keywords: security software, security defects, vulnerability, information security certification, informa tion security conformity assessment Введение имеется обратная связь с разработчиком, а в В рамках обсуждения проблем кибербезо- ряде случаев предоставляется исходный про пасности остро стоит вопрос о наличии разного граммный код, компоновочная среда и т.д.

рода уязвимостей в программных продуктах им- Сертификационные испытания и тематические портного производства. В открытых источниках исследования, регламентированные современ периодически обсуждаются скандалы с обна- ной нормативной базой, проводятся путем:

ружением программных закладок в продукции - функционального тестирования на соответ мировых разработчиков информационных тех- ствие нормативным и методическим документам нологий. Одним из способов противодействия или документации (ТУ, формуляр, задание по без подобным угрозам является проверка безопас- опасности);

ности программного кода в процессе сертифи- - структурного декомпозиционного анализа кационных испытаний и тематических исследо- программного обеспечения на отсутствие неде ваний по требованиям безопасности. В данной кларированных возможностей [2].

статье приведены примеры выявленных уязви- Особенностями указанных подходов является мостей исходя из опыта работы испытательной следующее:

лаборатории. 1. Функциональное тестирование программ Виды сертификационных испытаний касается проверки задекларированных детер В Российской Федерации основным леги- минированных механизмов безопасности, т.е.

тимным способом выявления уязвимостей ПО проверяется факт их работы, не касаясь глубо является обязательная сертификация средств кого анализа защищенности. Однако, используя защиты информации по требованиям безопас- личный опыт, квалифицированные эксперты спо ности информации (по линии Минобороны Рос- собны построить тесты, позволяющие выявлять сии, ФСБ России и ФСТЭК России) [1]. Это свя- некоторые специфические ошибки безопасности зано с тем, что при сертификации официально проектирования, реализации, конфигураций, предоставляются необходимые спецификации, прототипов, интерфейсов и т.д.

Опыт выявления уязвимостей в зарубежных программных продуктах 2. При структурном анализе импортной про- Роль и место указанных факторов в рамках мо дукции (если он предусмотрен) проводится, глав- дели управления безопасностью программного ным образом, проверка полноты/избыточности обеспечения (ПО) представлены в табл. 1.

кода. При проверке программных средств защиты В настоящее время методы и технологии вы информации, отнесенной к гостайне, также дол- явления уязвимостей не носят универсальный ха жен проводиться еще статический и динамиче- рактер и ориентированы на определенные клас ский анализ, который заключается в выполнении сы уязвимостей и их причин (дефектов).

декомпозиции программной системы (формиро- На практике выделяют три условных класса де вании и контроле условной части маршрутов). фектов и уязвимостей:

Однако нормативная база не ограничивает 1. «Некорректности программирования», клас экспертов в использовании дополнительных ме- сифицируемые как нефункциональные ошибки, тодов и приемов проверки кода, например: ин- сделанные при кодировании и влияющие на кон спекции кода, использовании статических анали- фиденциальность, целостность, доступность ре заторов, изучении бюллетеней безопасности, ор- сурсов. Теоретически, такие дефекты могут быть ганизации фаззинг - и стресс-тестирования и др. внесены умышлено.

Виды тестирования безопасности кода При тестировании обычно полагается, что та Опираясь на методологию риск-менеджмента, кие дефекты имеют стохастический характер, т.е.

при тестировании безопасности программного кода для выявления применяются методы функцио следует сформулировать вертикаль факторов ИБ: нального тестирования (обычно, фаззинг-тести {ДЕФЕКТЫ} - {УЯЗВИМОСТИ} - {УГРОЗЫ} - рование). К примеру, по заявлению разработчи {РИСКИ} ков, бета-версия Windows 8 прошла 1 миллиард В названном перечне, с точки зрения анализа запусков.

В настоящее время развивается направле кода, первичными являются именно дефекты без ние прикладной верификации кода, позволя опасности, которые представляют собой потен ющей в рамках статического анализа найти циальные уязвимости, влияющие на целостность, «некорректности программирования»: пере доступность, конфиденциальность ресурсов. Де полнение буфера, избыточные переменные и фекты, которые локализованы, описаны, эксплу объекты и др.

атируемы, идентифицируются как уязвимости.

Как правило, дефекты выявляются на этапе аудита 2. Дефекты, идентифицируемые как предна безопасности кода, а уязвимости выявляются при меренные. Так как такие дефекты связаны с ред сканировании информационной системы (сопо- кими входными данными, то в реальное время их ставлении идентифицируемых программ базе можно выявить только ручными экспертными и описаний уязвимостей или проверке кода про- полуавтоматизируемыми сигнатурными (эвристи граммы на наличие сигнатуры уязвимости). ческими) методами [3].

Таблица Управление безопасностью программ Управление Фактор Анализ/тестирование Контроль Контрмеры Дефекты Выявление, локализация Инспекционный контроль Безопасное ПО программирование Уязвимости идентификация, сканирование Периодическое Исправления сканирование, контроль целостности, контроль источников происхождения компонентов и др.

Угрозы Формирование модели угроз Мониторинг угроз Обновления, блокировка, фильтрация и др.

Риски Оценка риска Оценка остаточного риска Обработка риска Организационно-технические меры 3. Ранее обнаруженные (известные) уязвимо- - дизассемблирование - реально провести для сти, которые выявляются методами сканирования небольших незащищенных программ;

и экспертными методами, включающими также - ручные экспертные методы предъявляют высо сбор и анализ бюллетеней, прототипов и т.д. кие требования к опыту и знаниям тестировщиков.

При отсутствии исходных данных применяются Примеры отдельных техник тестирования подходы реверс-инжиниринга и функциональные представлены в табл.2 [2].

методы (по принципу «черного ящика»). Реверс- Важным моментом при выявлении уязвимо инжиниринг может проводиться путем: стей является сочетание методов тестирования - ретрансляции/дизассемблирования, прогона и методов мониторинга информационной безо в отладочном режиме - для машинных и проце- пасности (ИБ), включая реверсинг трафика и кон дурных языков;

троль событий ИБ.

- высококачественной декомпиляцией - для Таким образом, использование различных тех языков с промежуточным кодом [4]. ник проверки кода в рамках общей организации Надо понимать, что все методы имеют ограни- сертификации импортной программной продук чения по использованию: ции позволяет выявить ряд дефектов и уязвимо - функциональные методы ограничены про- стей, статистика по которым представлена ниже.

клятием размерности входных данных, неэффек Статистика выявления уязвимостей тивны при выявлении программных закладок и пригодны для небольших продуктов ;

В процессе сертификации ПО испытательной - структурные статические методы, кроме на- лабораторией было выявлено несколько десят личия исходных текстов, имеют ограничения на ков дефектов ПО, идентифицированных как кри выявление дефектов, связанных с динамикой тические уязвимости, и более тысячи дефектов программы (циклами и т.д.);

безопасности, которые идентифицировать как Таблица 2.

Примеры техник тестирования средств защиты информации Метод тестирования Основные выявляемые дефекты и уязвимости Функциональное тестирование Дефекты реализации функций и ошибки документации Фаззинг-тестирование Дефекты реализации интерфейсов данных Граничное тестирование Ошибки граничных условий Нагрузочное тестирование Ошибки производительности Стресс-тестирование (а разве это не одно и тоже, что Отказ в обслуживании нагрузочное? Просто разные слова) Профилирование Недостатки оптимизации кода Статический семантический анализ (прикладная Некорректности кодирования верификация) Статический сигнатурный анализ Заданные потенциально опасные фрагменты Статический анализ отсутствия недекларируемых «Мертвый код»

возможностей (НДВ) Динамический анализ отсутствия НДВ «Мертвый код»

Мониторинг операционных процессов Нарушения целостности процессов и ресурсов Тестирование конфигураций Ошибки администрирования Сканирование уязвимостей Известные опубликованные уязвимости Тест на проникновение Известные уязвимости, ошибки конфигурирования Регрессионное тестирование Повторные ошибки прошлых версий Опыт выявления уязвимостей в зарубежных программных продуктах Рис. 1. Статистика по типам уязвимостям преднамеренные не удалось. Под проверки под- преднамеренные, однако их можно эксплуа пала продукция 15 зарубежных производителей тировать при проведении компьютерных атак, из 7 иностранных держав. например, межсайтовый скриптинг (Cross-Site Scripting - XSS).

Статистика по типам уязвимостей Статистика уязвимостей по типам про Испытания показали, что в ПО в явном виде грамм встречаются программные закладки, маски руемые под отладочные средства (встроен- Из зарубежной продукции в рамках серти ные учетные записи и мастер-пароли, а также фикации были проверены операционные си средства удаленного управления). Около 70% стемы, антивирусные решения, системы обна выявленных уязвимостей являются именно та- ружения вторжений, системы хранения инфор кими. В то же время зафиксирован ряд дефек- мации и автоматизации предприятий, сетевые тов, которые трудно идентифицировать как устройства. Статистика соответствует общеми Рис. 2. Статистика уязвимостей по типам ПО Организационно-технические меры Рис. 3. Статистика по методам выявления уязвимостей Статистика дефектов в открытом коде ровой – большинство уязвимостей обнаруже но в прикладных системах. Следует указать, что современные программ Следует отметить, что во всех образцах теле- ные комплексы включают модули программ с от коммуникационного оборудования были обнару- крытым кодом. Исследование показало, что такие жены встроенные учетные записи (CWE-798). программы тоже включают уязвимости. Ниже представленная статистика демонстрирует нали Статистика по методам тестирования чие уязвимостей в открытом коде (рис.4).

Подавляющее большинство уязвимостей было выявлено методами статического эвристического Краткие выводы по сертификационной ста (сигнатурного) анализа. Для сравнения, следует тистике отметить, что в практике проверки российского Можно сделать краткие выводы:

ПО доля уязвимостей (главным образом ошибок - большинство импортных программных про кодирования), выявленных функциональными дуктов имели программные закладки аутентифи методами, существенно выше (до 30%), чем для кационного характера и др.;



Pages:     | 1 || 3 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.