Как обеспечить разработку безопасных бизнес-приложений

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

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

Проектирование

Требования к обеспечению безопасности приложения должны быть заложены в проект и архитектуру на этапе проектирования. Мировое сообщество и национальные стандарты выработали ряд требований к проектированию приложений. В качестве наиболее часто упоминающихся стандартов и законодательных норм можно упомянуть Open Web Application Security Project, (OWASP), Federal Information Security Management Act (FISMA), Payment Application Data Security Standard (PA-DSS), Health Insurance Portability and Accountability Act (HIPAA). Стоит отметить, что на сегодняшний день ни один из упомянутых стандартов не является обязательным или даже рекомендованным на территории России, что, безусловно, отдает задачу обеспечения безопасности приложений целиком в руки разработчиков

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

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

Этап разработки

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

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

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

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

Процесс разработки и внедрения
Безопасность на всех этапах

Источник: HP, 2010

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

Этап тестирования

На этом этапе проводится тестовая эксплуатация, во время которой пользователи имеют возможность проверить, работает ли система в соответствии с заявленным функционалом. Затем на тестовых данных испытывают, как приложение держит нагрузку. Поскольку приложение уже собрано и работает, можно уже применять гораздо больший арсенал инструментов контроля безопасности приложения и данных. Можно проверить реакцию системы на попытки взлома через пользовательский интерфейс, просканировать на предмет распространенных уязвимостей. Обязательно нужно проверить, как реагирует система на случаи использования известных уязвимостей, таких, как, например, SQL-инъекции в формах ввода.

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

Этап эксплуатации

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

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

Унаследованные приложения

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

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

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

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

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

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