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

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

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

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

Таблица. Нарушения кибербезопасности в 2014–2016 гг
Дата Предприятие, пострадавшее
от атаки
Характер атаки Объект атаки Цель атаки Источник информации
Июль 2014 Европейский центральный банк Внешнее вмешательство Похищено около 20 тыс. электронных писем и персональные данные Шантаж [3]
Март 2014 Компания KT Corporation Внешнее вмешательство Данные аккаунтов более 12 млн подписчиков Продажа данных телемаркетологам [4]
Май 2014 Компания eBay Inc. Внешнее вмешательство Персональная информация и пароли 145 млн пользователей Похищение данных
о счетах, фишинговая реклама, кража банковских счетов
[5]
Октябрь 2014 Банк JPMorgan
Chase & Co.
Внешнее вмешательство Имена, адреса, телефонные номера и электронные сообщения 83 млн клиентов Нет очевидной причины [6]
Февраль 2015 Страховая компания Anthem Health Insurance Государственное преступление Имена, дни рождения, номера социального страхования и другие данные 78,8 млн людей Возможная
причина —
кража личности
[7]
Февраль 2016 NASA (Национальное управление
по аэронавтике и исследованию космического пространства)
Внешнее вмешательство 250 Гб информации с именами, телефонными номерами, адресами электронной почты; данные о 2000 полетов и 600 видеороликов
с самолетов NASA. Заявлен частичный контроль над беспилотными летательными аппаратами (отрицается NASA)
Хактивизм (перенос данных в облако) [8]
Апрель 2016 COMELEC — комиссия по выборам (Республика Филиппины) Внешнее вмешательство Персональные данные каждого зарегистрированного избирателя на Филиппинах (примерно 55 млн), включая такую идентифицирующую личность информацию, как отпечатки пальцев и паспортные данные Хактивизм [9]

Но, с другой стороны, специалисты считают, что инструменты, которые они покупают и используют для предупреждения и смягчения последствий этих угроз, не обеспечивают ожидаемого результата, хотя поставщики изо всех сил пытаются оправдать совокупную стоимость владения этими инструментами. Согласно недавнему исследованию, глобальные инвестиции в обеспечение безопасности за 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. Результаты анализа реального проекта демонстрируют количество диагностических данных, созданных в новом или отредактированном коде

 

Заключение

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

Литература
  1. Warren woman files $5,000,000 suit over Anthem data breach.
  2. Bourne V. 2016 CIO Study Results — The Threat to Our Cybersecurity Foundation. 2016.
  3. Ehrenberg B. Update: Blackmailer hacks ECB website, steals email addresses and contact details.
  4. 12 Million Koreans Hit by KT Corp Data Breach; Korean Govt Investigating.
  5. Cyber Thieves Took Data On 145 Million eBay Customers By Hacking 3 Corporate Employees.
  6. JPMorgan Chase Hacking Affects 76 Million Households.
  7. Anthem: Hacked Database Included 78.8 Million People.
  8. Hackers mirror 250GB of NASA files on the web.
  9. Das S. Is This the Worst Government Data Breach, Ever.
  10. This Tool Allows You To Track Your Friends’ Sleep Patterns Via Facebook.
  11. Dasmalchi G. Why Layered Security Strategies Don’t Work (webinar). 2016.
  12. Jones C. Software Quality and Software Economics. 2009.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *