Процессы, которые важны для информационной безопасности

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

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

Информационная безопасность в разработке ПО

• Разработчики должны знать об угрозах ИБ — практически все типичные виды атак на приложения — XSS, CSRF, SQL-инъекции, брутфорс, DDoS — могут быть или исключены на уровне разработки, или их реализация будет сильно усложнена.
• Запрещено всё, что не разрешено — это ключевая мантра безопасности в ИТ: реально хорошо работают только политики, которые основаны на простой модели — запрещаем всё и разрешаем только то, что необходимо. В разработке этот метод применяется при проектировании авторизации и ролевой модели доступа к системе.
• Могут быть подделаны все входные данные, поступающие в приложение — это данные форм, параметры запроса, http-заголовки, cookies. Подделанные данные используются для злома, получения конфиденциальной информации или для нарушения нормально работы приложения. Больше всего думать об этом стоит разработчикам публичных сервисов, доступных не только из внутрикорпоративной сети, но из интернета. Тем не менее, даже если ваш сервис надёжно спрятан внутри компании, то это всё равно не гарантия 100% защиты от проникновения.
• Используйте анализаторы кодовой базы — очень много ошибок может быть выявлено именно благодаря подобным инструментам.
• Используйте системы управления версиями, автоматизированного тестирования и разворачивания проекта — это сильно снижает риски попадания в кодовую базу как инородных фрагментов (типа вирусов), так и позволяет отлавливать возможные ошибки. Про тестирование более подробно написано ниже.
• Помните о вреде «велосипедостроения» — для того, чтобы правильно написать ту же самую систему аутентификации надо достаточно много знать и разбираться в криптографии, хэшировании, знать как работают cookies или как работать с токенами, разбираться в применяющихся методиках брутфорса и других возможных атаках на систему аутентификации. Если нужные знания отсутствуют, то более рациональным решением будет воспользоваться зарекомендовавшей себя библиотекой, а не разрабатывать решение самостоятельно.
• Код-ревью — все люди ошибаются, причём собственные ошибки очень часто заметить бывает труднее, чем чьи-то ещё. Поэтому код надо проверять не только самостоятельно, но и с помощью коллег.

Информационная безопасность и тестирование

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

Информационная безопасность и системное администрирование

• Настройка серверного ПО в соответствии с задачами и ресурсами системы — звучит банально, но проблема очень распространена: если служба не используется извне, то закройте к ней внешний доступ; если на сервере всего 8Gb RAM, то сервер СУБД не может быть сконфигурирован в расчете на 32Gb RAM; если для ПО устанавливается конфигурация «по умолчанию» — обязательно ознакомьтесь с ней, часть софта бывает весьма жадными до ресурсов и вы можете столкнуться с тем, что под нагрузкой это ПО будет прибито тем же OOM-Killer'ом, а бывает и обратная ситуация — «дефолтные» настройки прописаны для работы на очень слабом железе и тогда вы просто не получите хорошей производительности.
• Регулярное обновление ПО — уязвимости бывают в любом софте, чем быстрее вы их закроете — тем меньше риск того, что кто-то их проэксплуатирует. Еще бывает так, что критичическая уязвимость формируется как сумма мелких проблем различных используемых программ.
• Запрещено всё, что не разрешено — этот подход верен и в разработке, и в системном администрировании. Ограничивайте всё, что не нужно для нормально работы.
• Инфраструктура как код — очень хорошая практика, позволяющая ничего не забыть в настройке оборудования и ПО, а также позволяющая хранить знания о настройке оборудования в понятной форме, а не в виде истории bash-команд на production-сервере.
• Высокая доступность сервисов и системы оркестрации — если используете контейнеризованные приложения, то задумайтесь о внедрении системы оркестрации типа Kubernetes, если же нет, то всё равно автоматизируйте процессы отработки отказов и реакции на повышение нагрузки.
• Мониторинг — очень важный процесс. Построение системы мониторинга — это тема для отдельной стать, если тезисно, то отслеживать стоит нагрузку / другие метрики приложения и обязательно настраивать оповещения об отклонениях, необходим контроль целостности программного кода, бывает полузным использование HoneyPot, а также в действительно крупных проектах стоит использовать комплексные системы обнаружения и предотвращения вторжений.
• Резервное копирование — бэкапы также очень важны. Лучше использовать несколько различных и изолированных методов снятия резервных копий. Бэкапы должны отправляться на удаленное хранение — резервная копия на сервере с боевыми данными может быть потеряна вместе с оригиналами. Проверка целостности — бэкапы надо проверять, как автоматикой, так и периодически вручную: резервная копия из которой нельзя ничего восстановить — это не бэкап. Автоматический мониторинг — задачи резервного копирования должны быть под системой мониторинга с оповещениями. Хранилище резерных копий должно быть защищено не хуже production-окружения — в бэкапах очень много чувствительной информации.
• Следите за всем периметром безопасности — это не только production, но и системы управления версиями, тестирования, развертывания, мониторинга, сервера для резервного копирования, корпоративные базы знаний, баг-трекер, рабочие станции разработчиков и администраторов... и это делеко не полный список мест, где может быть ценная информация, а значит всё это может быть возможной целью атаки.