Файл: Назначение и структура системы защиты информации коммерческого предприятия (АНАЛИЗ УЯЗВИМОСТЕЙ В ЗАЩИТЕ ИНФОРМАЦИИ И МЕТОДЫ ЛИКВИДАЦИИ НА ПРИМЕРЕ КОММЕРЧЕСКОЙ КОМПАНИИ).pdf

ГЛАВА 2. АНАЛИЗ УЯЗВИМОСТЕЙ В ЗАЩИТЕ ИНФОРМАЦИИ И МЕТОДЫ ИХ ЛИКВИДАЦИИ НА ПРИМЕРЕ КОММЕРЧЕСКОЙ ОРГАНИЗАЦИИ

2.1 Защита проектной документации от несанкционированного доступа

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

Уязвимость: данный тип информации хранился на google Doc, с доступом под одним аккаунтом для всех сотрудников компании. Не было ограничения на доступ к данной информации, следовательно, к документам имели доступ сотрудники, не работающие с ней на прямую.

Устранение уязвимости: для защиты данной информации нужно ограничить доступ к данной информации, отказать от хранения в открытых источниках, облачных хранилищ таких как google Doc. Наиболее подходящим вариантом хранения проектной документации является организация хранения на собственном сервере, и использование приложения для хранения информации с возможностью ограничения доступа, например в atlassian confluence .

Atlassian Confluence — это web-based корпоративная wiki, основном применяющаяся внутри корпораций. Обеспечьте безопасность сайта и контента с помощью различных прав доступа, что позволит вам полностью контролировать работу.

Atlassian Confluence позволяет настроить безопасность самого приложения

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

Данное приложение обеспечит безопасность документации.

2.2 Защита программного продукта

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

1. угрозы, направленные на нарушение конфиденциальности информации;
2. угрозы направленные на нарушение доступности информации.

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

1. автоматические системы эксплуатации уязвимостей;
2. профессиональные кибер-преступники;
3. начинающие, любители.

Они обладают различными методами, способами и инструментарием — объединяет их только одна цель взломать или вывести из строя веб приложение.

Для примера рассмотрим веб-приложение, написанное на asp.net, хранении данных осуществляется в базе данные SQL.

ASP.NET (Active Server Pages для .NET) — технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформы Microsoft .NET и развитием более старой технологии Microsoft ASP.

SQL (англ. structured query language — «язык структурированных запросов») — язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных.

База данных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).

Уязвимость приложения:

• 1. Приложение доступно только по HHTP протоколу

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

Устранение уязвимости: переход на HTTPS протакол, HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от снифферских атак и атак типа man-in-the-middle, при условии, что будут использоваться шифрующие средства и сертификат сервера проверен и ему доверяют.

По умолчанию HTTPS URL использует 443 TCP-порт (для незащищённого HTTP — 80). Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат открытого ключа для этого веб-сервера. В TLS используется как асимметричная схема шифрования (для выработки общего секретного ключа), так и симметричная (для обмена данными, зашифрованными общим ключом). Сертификат открытого ключа подтверждает принадлежность данного открытого ключа владельцу сайта. Сертификат открытого ключа и сам открытый ключ посылаются клиенту при установлении соединения; закрытый ключ используется для расшифровки сообщений от клиента. Существует возможность создать такой сертификат, не обращаясь в ЦС. Подписываются такие сертификаты этим же сертификатом и называются самоподписанными (self-signed). Без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) такое использование HTTPS подвержено атаке man-in-the-middle. Эта система также может использоваться для аутентификации клиента, чтобы обеспечить доступ к серверу только авторизованным пользователям. Для этого администратор обычно создаёт сертификаты для каждого пользователя и загружает их в браузер каждого пользователя. Также будут приниматься все сертификаты, подписанные организациями, которым доверяет сервер. Такой сертификат обычно содержит имя и адрес электронной почты авторизованного пользователя, которые проверяются при каждом соединении, чтобы проверить личность пользователя без ввода пароля. В HTTPS для шифрования используется длина ключа 40, 56, 128 или 256 бит. Некоторые старые версии браузеров используют длину ключа 40 бит (пример тому — IE версий до 4.0), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является сколько-нибудь надёжной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 бит, с целью обеспечить достаточный уровень безопасности. Такое шифрование значительно затрудняет злоумышленнику поиск паролей и другой личной информации.

Традиционно на одном IP-адресе может работать только один HTTPS сайт. Для работы нескольких HTTPS-сайтов с различными сертификатами применяется расширение TLS под названием Server Name Indication (SNI).

• 1. Использование для обмена данными с сервером public API

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

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

Устранение уязвимости: переход на PRIVATE API – при запросе данных системе нужно будет передать token, своего рода ключ безопасности, для определенного системного пользователя. Не зная пользователя и пароля получить такой token невозможно.

• 1. Хакерские атаки

Атака: Тип уязвимости: SQL injection, RCE, Auth Bypass Описание: слепая инъекция на форме входа Риски: бизнес процессы, безопасность, кража, репутация.
Защита: выявлять и блокировать паттерны эксплуатации SQL инъекции, такие как: использование кавычек, специальных конструкций — в данном примере функции sleep.

Атака: Взлом сайта доставки пиццы, взлом mobidel.ruТип уязвимости: Insecure Direct Object References, хранимая XSS, захват сессииОписание: отсутствие каких-либо проверок, классические клиент-сайд атаки. Риски: бизнес процессы, безопасность, кража, репутация.

Защита: выявлять и блокировать паттерны эксплуатации XSS вектора — использование функций инъекций html кода, множества запросов авторизации с разными id.

Кейс: Надёжная авторизация для веб-сервиса Тип уязвимости: SQL Риски: security through obscurity.

Защита: выявлять и блокировать паттерны эксплуатации SQL инъекции (union, select и т.д.) — даже зная где она находится (при наличии исходного кода), злоумышленник не сможет ее проэксплутировать.

Кейс: Как взламывают телеком-провайдеров: разбор реальной атаки Тип уязвимости: SQL injection Описание: взлом периметра через веб, проникновение в сеть. Риски: бизнес процессы, безопасность, кража, репутация.Защита: выявлять и блокировать паттерны использования автоматических средств поиска уязвимостей (по заголовкам, частоте (парсингу) обращений.

Никакие инструкции по разработке безопасного кода, рекомендации, «бест-прэкстис» и т.д. не работают. Необходимы дополнительные защитные, или даже страховочные меры, для того чтобы предотвратить взлом веб-приложения. Это не значит, что современные WAF — панацея. Это одна из защитных мер, которая поможет предотвратить взлом веб-приложения. Обычно предвестником атаки является сканирование веб-приложения теми или иными утилитами. Явный признак: частое обращение с одного IP к разными страницам, больше количество 404 ошибок. Это может быть поисковый бот (его ни в коем случаем не баним, но и при этом мы должны быть точно уверены, что это именно бот — проверка поля User Agent не даст таких гарантий). Это может быть краулер или парсер — если нам не жалко — пусть парсит, можно лишь ограничить ему "аппетит" количеством запросов в минуту, если у вас слабый сервер. Другое дело сканеры: в первую очередь их можно сразу же определить по User Agent/служебным заголовкам (а большинство из тех, кто ими пользуется, никогда его не меняют и скорее всего даже не догадываются об этом): например сразу же выявляются такие сканеры, как: acunetix, w3af, netsparker, nikto и т.д. Такие обращения необходимо блокировать сразу же, чтобы не облегчать злоумышленникам работу (и не засорять логи). Если заголовки все-таки замаскированы — определить сканер можно по множеству 404 ошибок, попыток авторизации и обращений к служебным файлам. Как мы видели в вышеприведенных примерах, используются разные технологии, платформы — поэтому современные защитные средства должны это учитывать. Во всех случаях использование WAF могло бы предотвратить эксплуатацию уязвимости, а система уведомлений сообщить о попытке эксплуатации.

Для того, чтобы избежать эксплуатации тех или иных уязвимостей, современный WAF должен:

1. моментально обрабатывать трафик;
2. блокировать нелегитимные запросы;
3. выявлять бот-активность;
4. уметь работать с любым протоколом http/https;
5. не зависеть от платформы веб-приложения;
6. уметь выявлять брутфорс-атаки, краулинг и т.д.
7. уметь работать с вебсокетами и т.д.;
8. минимизировать false детекты;
9. блокировать DoS (L7);
10. выявлять и блокировать новые атаки, в т.ч. с помощью машинного обучения;
11. содержать актуальную и пополняемую базу сигнатур атак;
12. содержать актуальную и пополняемую базу IP-reputation;
13. применять virtual patching.