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

Алексей Абрамович 
Директор департамента тестирования безопасности ПО
ЗАО «Технологии качества», A1QA

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

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

Расставляя приоритеты между всеми этапами, у заказчика возникает соблазн перенести тестирование безопасности продукта на окончание процесса разработки. В таком случае и бюджет и график тестирования планировать легче. Но этот соблазн несёт в себе очень высокий риск. Если он реализуется, то очень сильно могут пострадать и сроки выпуска программы, и бюджет проекта.

Раньше вложишь – больше сэкономишь

Ни для кого не секрет, что чем раньше найден дефект, тем дешевле его исправление. Независимо от текущего этапа проекта в случае обнаружения дефекта безопасности необходимо возвращаться на этап разработки требований и архитектуры и вносить исправления во все последующие этапы. По данным исследований Института Понемона и корпорации PGP (http://www.anti-malware.ru/files/Ponemon_Annual_Study_Cost_of_a_Data_Breach_US_2008.pdf), стоимость исправления дефекта безопасности на этапе производства и выпуска может стоить до 30 раз (это 3000%!) больше, чем, если бы дефект был найден на этапе разработки требований и архитектуры.

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

Вот такие незапланированные траты и отсрочки от одного лишь дефекта! А что если этих дефектов несколько, или исправление одного вызвало новую ошибку?

Комплексный подход

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

Сегодня популярны такие методики комплексного подхода к внедрению безопасности на проекте как OWASP, Veracode, Cisco и Security Development Lifecycle (SDL) от Microsoft. В общем виде методики содержат в себе следующие этапы.

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

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

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

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

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

Финальная оценка уровня защищенности системы относительно разработанных требований делается во время релиза.

Последний этап – реагирования - предусматривает выполнение плана реагирования в случае инцидента безопасности.

По международным стандартам

Описанный комплексный подход делает упор на детальной проработке безопасности системы ещё до начала написания кода. Весьма важен здесь первый этап - обучение команд разработки и построение архитектуры.

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

Не только теория

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

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

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