В этой главе мы обсудим программы безопасности приложений (англ. Application Security, AppSec), которые представляют собой формализацию деятельности по обеспечению безопасности как части жизненного цикла разработки системы. Программа безопасности приложения не является компонентом ПО: это набор взаимосвязанных действий, имеющих конкретную долгосрочную цель.
В данном случае наша цель – обеспечить безопасность создаваемого и поддерживаемого нами программного обеспечения. Мы стремимся к снижению рисков для организации и для тех, кого обслуживаем (клиентов, сотрудников, граждан и т. д.). Мы защищаем конфиденциальность, целостность и доступность систем и данных, находящихся в нашем ведении.
Мы создаем официальные программы безопасности приложения, чтобы усовершенствовать политику безопасности, обеспечить защиту всех наших приложений (без исключения) и доказать другим, что мы предприняли все возможные действия для защиты организации. Без официальной программы нельзя с уверенностью заявлять, что мы производим надежное ПО, которое можно безопасно разместить в интернете, а если произойдет крупный взлом системы, мы практически не сможем себя защитить.
Под программой подразумевается выполняемая нами деятельность: моделирование угроз для каждого нового проекта, рассмотрение всех запросов, касающихся проблем обеспечения безопасности, добавление проверок безопасности в конвейер и т. д. Идея программы заключается в формализации этих действий, то есть они официально становятся частью подхода организации к созданию ПО. Невозможно «пропустить» этап обеспечения безопасности в жизненном цикле разработки системы, потому что он зафиксирован в программе и тем самым является обязательным.
• В идеале программу осуществляет специально собранная команда или по крайней мере отдельный специалист.
• Деятельность по обеспечению безопасности добавляется в жизненный цикл разработки системы.
• Команда по безопасности приложений снабжает и поддерживает разработчиков всеми необходимыми ресурсами, инструментами, обучением, политикой, руководством.
• Команда по безопасности приложений проверяет соблюдение безопасности жизненного цикла разработки системы и безопасность производимого программного обеспечения (тестирование и инструментарий).
В настоящее время не существует общепринятого стандарта того, что должно входить в программу безопасности приложений. Почти всегда она выполняется наугад. Существует множество общих мероприятий, однако нельзя утверждать, что они являются лучшими решениями для каждого конкретного случая. Для определения оптимального варианта действий одни организации используют модели OWASP SAMM или BSIMM, в то время как другие принимают решение самостоятельно. В естественных условиях программы безопасности приложений сильно отличаются друг от друга: некоторые из них очень подробны и включают в себя множество мероприятий, а другие представляют собой беглые проверки, осуществляемые исключительно для того, чтобы соответствовать нормам либо законам. Есть и такие редкие жемчужины, для которых активная культура обеспечения безопасности является приоритетом.
СОВЕТ. Проект OWASP Self Assessment Maturity Model (SAMM) чрезвычайно полезен при запуске программы безопасности приложений с нуля. Технически эта методология «не одобрена» и не признана стандартом, однако группа экспертов поддерживает ее в качестве платформы для создания собственного безопасного жизненного цикла разработки системы. (Источник: owaspsamm.org/model.)
Методология Building Security in Maturity Model (BSIMM) предоставляет исследования, основанные на текущих тенденциях в IТ-отрасли, тем самым помогая компаниям в поисках тех видов деятельности, которые позволят им получить наилучшую окупаемость инвестиций. (Источник: www.bsimm.com/framework.html.)
Важно, чтобы создание собственной программы безопасности приложений проходило в условиях максимальной эффективности и результативности, поскольку у вас никогда не будет достаточно ресурсов, бюджета или времени, чтобы осуществить все задуманное. Если только вы не работаете в условиях чрезвычайно высокого риска или в другой особой ситуации, бизнес-требования всегда будут стоять выше обеспечения безопасности, что ограничивает работу команды безопасности.
Выбирая мероприятия для программы безопасности приложений, необходимо составить список целей, а затем на его основе определить действия и инструменты, которые будут наиболее эффективны в рамках существующих в организации систем. Цели ставятся с учетом приоритетов компании, чтобы обеспечить максимальную защиту наиболее важных для бизнеса элементов.
Исходя из этого, давайте рассмотрим некоторые высокоуровневые цели программы, которые мы могли бы поставить перед собой и работать над их достижением.
Нельзя защитить что-то, о наличии чего мы не знаем. Именно по этой причине проводится инвентаризация всех приложений и других активов, включая API и базы данных. Большинство крупных компаний имеют множество приложений, о которых они не знают. Эти неучтенные приложения не получают должного внимания со стороны службы безопасности и, следовательно, представляют собой брешь в защите всей компании.
Возможно, вы удивитесь, узнав, что создание и ведение реестра приложений является одной из самых сложных задач в сфере IТ. Разработчики нередко выпускают обновления или API без документации, старые приложения теряют актуальность, бизнес-подразделения нанимают теневых IТ-специалистов, которые не соблюдают никаких правил безопасности, продукты SaaS работают в сети без чьего-либо ведома. Многие организации, которые, как вы, вероятно, полагаете, очень надежны, в настоящее время отслеживают свои приложения вручную в таблице Microsoft Excel, пока вы читаете эти строки.
Самая важная причина, по которой вы как специалист в области безопасности приложений должны провести инвентаризацию своих программных активов, заключается в необходимости обеспечить внимание к безопасности каждого приложения. Если все приложения должны пройти проверку безопасности кода перед запуском в эксплуатацию, то вам необходимо знать о каждом из них.
СОВЕТ. Использование базы данных управления конфигурацией (англ. Configuration management database, CMDB) для хранения реестра является отличным способом наладить взаимодействие с остальными IТ-отделами. Нужно, чтобы все команды могли найти информацию о находящихся под вашей ответственностью приложениях, и наоборот. Использование общего инструмента создаст почву для укрепления доверия и обмена сведениями между командами.
Злоумышленники всегда будут искать самое слабое звено компании. Приложения, которым не уделялось никакого внимания с точки зрения безопасности, скорее всего, окажутся таким слабым звеном.
В больших организациях теневые информационные технологии относятся к системам информационных технологий (IТ), развернутым отделами, отличными от центрального IТ-отдела (обычно) для обхода недостатков центральных информационных систем или IТ-отдела.
Википедия