Реальность требований по обеспечению безопасности. Тактика запугивания или подлинная угроза?

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

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

Но, с другой стороны, специалисты считают, что инструменты, которые они покупают и используют для предупреждения и смягчения последствий этих угроз, не обеспечивают ожидаемого результата, хотя поставщики изо всех сил пытаются оправдать совокупную стоимость владения этими инструментами. Согласно недавнему исследованию, глобальные инвестиции в обеспечение безопасности за 2016 г. составили $83 млрд, но при этом 87% директоров, отвечающих за внедрение информационных технологий, полагают, что их средства контроля и управления безопасностью не смогут защитить бизнес [2]. Это подтверждается тем фактом, что количество попыток нарушить целостность и безопасность данных, а также помешать нормальному функционированию системы безопасности, продолжает расти.

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

Учитывая то, что сейчас движущей силой технической революции являются большие данные (big data) и «Интернет вещей» (англ. Internet of Things, IoT), можно легко предсказать сценарий ее развития. Без эффективной защиты данных мы потенциально можем передать свою жизнь кому-то другому, и он сможет использовать эту информацию в корыстных целях. Безопасность, несмотря на то, что это достаточно сложное понятие, можно измерить — например, как эффективность от инвестиций (в англ. терминологии — Return on Investment, или RoI) в многочисленные инструменты и технологии, используемые для защиты информации. Кроме того, развитие рынка ценных бумаг принесло нам множество полезных показателей, которые помогают оценить эффективность реагирования на инциденты. Это, например, MTTK (Mean Time To Know) — среднее время информированности об инциденте, ATTR (Average Time To Respond) — среднее время ответной реакции на инцидент, среднее время устранения уязвимостей (Mean Time To Fix Vulnerabilities) и т. п. Однако по своей природе все эти показатели относятся к реакции на уже свершившийся факт возникновения нарушения в области безопасности. Заранее (до возникновения инцидента) определить и оценить реальный уровень безопасности, предоставляемый для конкретной организации, довольно сложно.

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

С точки зрения влияния жизненных циклов программного обеспечения (ПО), можно выделить аналогичные проблемы:

• плохую политику разработки и обслуживания исходного кода;
• недостаточно информированных, недовольных или недобросовестных разработчиков;
• повсеместное использование удаленного доступа, VPN, распределенных систем разработки, сервисов XaaS, облачных сервисов и т. п.;
• внешние источники: ПО с открытым исходным кодом, сторонние продукты и ПО неизвестного происхождения (англ. Software of Unknown Provenance, SOUP).

Различные источники риска требуют принятия многоуровневых контрмер, а сама стратегия такой углубленной защиты включает использование дополнительных методов для обеспечения действий по снижению рисков и устранения возможных уязвимостей. Такую концепцию вполне можно принять для снижения риска до приемлемого уровня в жизненном цикле разработки ПО (англ. Software Development Life Cycle, SDLC).

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

Рис. 1. Модель швейцарского сыра

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

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

Некоторые методы обнаружения ошибок и дефектов кода на практике оказываются более эффективными, чем другие. Мерой того, насколько хорошо они проявляют себя в конкретной задаче, является эффективность устранения дефектов (англ. Defect Removal Efficiency, DRE), которая представляет собой процент ошибок/проблем, устраненных с помощью конкретной методики (например, ручного контроля кода, модульного тестирования и т. п.), по отношению к их общему объему (рис. 2). Наивысший показатель DRE обычно достигается двумя классами анализа — ручным и статическим анализом кода [12].

Рис. 2. Эффективность устранения дефектов конкретных методик

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

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

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

Ориентированные на безопасность стандарты кодирования, такие как CERT C/C++ (CERT — Computer Emergency Response Team, Центр реагирования на инциденты информационной безопасности), склоняются к упрощению автоматизированной принудительной реализации. Анализ кода может быть выполнен в рамках инструментальной цепочки хода разработки, в идеале сразу после появления проблемы (например, сразу же после того, как была зафиксирована некая уязвимость). Чем раньше это произойдет, тем ниже будут затраты на доработку, что положительно скажется на показателе доходности от инвестиций в систему обеспечения безопасности.

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

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

На рис. 3 представлена диаграмма анализа, проведенного программой контроля качества QA·Verify v.2.1.0 (PRQA). Она показывает результаты реального проекта, демонстрируя количество диагностических данных, созданных в новом или отредактированном коде (рис. 3). Анализ был проведен с использованием статического анализатора современного уровня QA·C v. 9.0.1 с дополнительным модулем соответствия для стандарта программирования CERT-C CM v.1.0.0.

Рис. 3. Результаты анализа реального проекта демонстрируют количество диагностических данных, созданных в новом или отредактированном коде

Заключение

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