Защита исходного кода

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

Многие поспешат возразить, что «безопасность через неизвестность» – неэффективная тактика защиты, но я не согласна. Сокрытие кода (то есть работа с закрытым, а не открытым исходным кодом) ни в коем случае не должно быть единственным средством обеспечения безопасности, но использовать этот подход в качестве одного из многих уровней защиты – разумное решение, если преимущества размещения кода в интернете не перевешивают защиту, которую предлагает закрытый исходный код. Многие компании не размещают свой код в открытых репозиториях, чтобы затруднить попытки конкурирующих компаний воспроизвести их продукты. Да, злоумышленник может попытаться провести реинжиниринг популярного программного обеспечения, но у кого есть столько времени?

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

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

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

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

Моделирование угроз

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

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

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

ПРИМЕЧАНИЕ. Моделирование угроз – обширная тема, которой посвящено несколько книг. Здесь представлена лишь малая часть информации, так как цель данного раздела – рассказать в общем о существовании такого понятия, как моделирование угроз, и показать важность его использования при разработке новых приложений. Несмотря на то что моделирование угроз – достаточно новая процедура, ее проведение в любом случае лучше, чем отсутствие.

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

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

Собравшаяся группа обсуждает существующие для системы риски: «Что мешает спать по ночам?», «Если бы вы собирались атаковать ваше приложение, как бы вы это сделали?», «О каких субъектах угроз мы должны знать? К чему следует готовиться?» и т. д. Необходимо взглянуть на систему с точки зрения злоумышленника: «Что может пойти не так?», «Как можно использовать систему не по назначению?», «Как обеспечить защиту пользователя (в том числе от нас)?», «Каков наихудший сценарий?» Эта сессия может быть невероятно формальной (например, создание деревьев атак) либо же вполне неформальной (именно так я бы посоветовала начинать данный процесс).

Отличным стартом будет превращение историй пользователей проекта в «истории злоупотреблений» или негативные примеры использования. Что произойдет, если приложение будет делать А вместо предполагаемого Б? Подборка таких историй даст вам много пищи для размышлений.

Существует несколько методов моделирования угроз, но наиболее популярными являются деревья атак, STRIDE и PASTA. STRIDE фокусируется на вопросах, связанных с аутентификацией, авторизацией, триадой CIA и опровержением (то есть с возможностью доказать чьи-либо действия или бездействие). PASTA направлена на работу с бизнес-требованиями, пользовательскими историями, диаграммами данных и многим другим, что делает его немного более трудоемким. Деревья атак изображаются в виде «деревьев», где цель атаки (например, кража денег) находится на верхушке, а листья представляют собой возможные пути достижения этой цели (пример дерева атак приведен на рис. 3.6).

Рис. 3.6. Пример примитивного дерева атак на приложение для бега

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

СОВЕТ. В моем блоге (wehackpurple.com) можно почитать о нескольких неформальных моделях угроз, разработанных мной для роботов, бессерверных систем, утечек данных при лабораторных испытаниях и т. д.

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

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

ПРИМЕЧАНИЕ. Можно использовать систему рейтинга Common Vulnerability Enumerator (CVE) либо 1–10 – все, что подходит команде и компании, при условии, что используется одна и та же система.

ВНИМАНИЕ. Обоснования опасности каждого риска могут удивить и даже испугать. Однажды мне пришлось сообщить одной компании, что возможный ущерб от угрозы будет «абсолютно катастрофическим». Я была уверена, что ее возникновение приведет к банкротству. Несмотря на то что сам риск был «довольно маловероятным», проектная команда немедленно изменила свой курс действий, как только поняла возможные последствия в долгосрочной перспективе.

Итак, вы составили список рисков и определили степень важности каждого из них. Затем следует составить план действий. Будете ли вы смягчать (исправлять либо устранять) некоторые из проблем? Будете ли вы управлять некоторыми рисками: регистрировать и отслеживать их, чтобы не пропустить увеличение серьезности? Примете ли вы какие-нибудь риски (документально подтвердив, что в отношении них не будут проводиться никакие действия)? Возможно, некоторые из них крайне маловероятны или представляют лишь незначительную угрозу? Зачем тратить средства на то, что не вызывает беспокойства? Скорее всего, принятые решения потребуют внесения дополнительных пунктов в список требований безопасности для проекта, что необходимо обсудить с представителями компании и с командой по управлению рисками.

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

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

ИСТОРИЯ ОТ АВТОРА

Однажды в процессе моделирования угроз я спросила двух разработчиков: «Если бы вы собирались взломать свое приложение, как бы вы это сделали?» Они посмотрели друг на друга, а затем один из них сказал: «Ну… мы написали один модуль администратора, чтобы управлять приложением из дома, может, это?» Модуль администратора не был включен ни в один проектный документ и оказался гигантской дырой в безопасности, о которой мы бы никогда не узнали, не будь этих программистов на встрече.

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

Инженеру по безопасности можно посоветовать пригласить на сеансы моделирования угроз специалистов по разработке и по информационно-технологическому обслуживанию (англ. Dev and Ops) и таким образом повышать их осведомленность о безопасности в будущем. К тому же обычно от них исходят самые хитрые идеи. Такие встречи помогут наладить отношения с другими людьми. Не заблуждайтесь: для качественного выполнения работы необходимы хорошие отношения.

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