В современном цифровом мире безопасность баз данных играет ключевую роль в обеспечении конфиденциальности, целостности и доступности информации. Предотвращение утечек данных, несанкционированных доступов и атак на информационные ресурсы становится все более важной задачей для организаций и предприятий любого масштаба.
В данной статье будет проведен анализ уязвимостей баз данных, выявлены основные угрозы и риски, а также рассмотрены эффективные методы защиты данных от потенциальных атак и нарушений безопасности.
Для изучения темы возьмем случай из интернета. За период с 27 ноября 2013 г. по 15 декабря 2014 г. хакерам удалось похитить персональные данные (номера телефонов, электронные и почтовые адреса, номера и PIN-коды кредитных и дебетовых карт) 110 млн клиентов компании Target, владеющей третьей по величине торговой сетью США.
В результате американские финансовые институты понесли убытки в размере более 200 млн долларов США. 18 января 2014 г. газета The New York Post сообщила, что вредоносная программа "Картоха", с помощью которой были похищены данные клиентов Target, была написана 17-летним программистом Сергеем Тарасовым из Санкт-Петербурга. Однако к самому взлому россиянин не был причастен. 8 мая 2014 г. полиция шт. Техас арестовала Го Синчэня, подозреваемого в краже данных клиентов сети Target. Это был один из самых масштабных взломов в истории, который вызвал огромный скандал и стоил Target миллионы долларов. Однако, не только Target стал жертвой этого взлома. В ответ на этот взлом, Target потратил миллионы долларов на улучшение своих систем безопасности и реорганизацию своих IT-отделов. Кроме того, компания улучшения системы мониторинга и обнаружения инцидентов безопасности, а также усилила контроль над своими поставщики и контрагентами. Тем не менее, этот взлом стал ярким примером того, что даже крупные компании могут быть уязвимы к кибератакам, особенно если они имеют слабые места в своих цепочках поставок и не уделяют должного внимания своим системам безопасности.
Кроме того, этот взлом стал поводом для повышения осведомленности о кибербезопасности и привлек внимание к проблемам безопасности в цепочках поставок. Этот случай показал, что компании должны улучшать свои системы мониторинга и обнаружения инцидентов безопасности, а также улучшать свои процессы управления рисками в своих цепочках поставок.
Что такое база данных и их виды.
База данных — это упорядоченный набор структурированной информации или данных, которые обычно хранятся в электронном виде в компьютерной системе. База данных обычно управляется системой управления базами данных (СУБД). Данные вместе с СУБД, а также приложения, которые с ними связаны, называются системой баз данных, или, для краткости, просто базой данных.
Данные в наиболее распространенных типах современных баз данных обычно хранятся в виде строк и столбцов формирующих таблицу. Этими данными можно легко управлять, изменять, обновлять, контролировать и упорядочивать. В большинстве баз данных для записи и запросов данных используется язык структурированных запросов (SQL).
Исторически сложилось так, что системы безопасности баз данных развивались в качестве реакции на действия киберпреступников. Оказало влияние и общее развитие баз данных, начиная с решений на мейн фреймах, заканчивая облачными хранилищами.
Специалисты выделяют следующие архитектурные подходы: — полный доступ пользователей к серверу баз данных; — внедрение системы аудита (логов действий юзеров) средствами СУБД; — деление пользователей на частично доверенных и доверенных с помощью средств СУБД; — внедрение шифрования данных с выносом средств аутентификации за пределы СУБД в промежуточное программное обеспечение и операционные системы; исключение полностью доверенного администратора данных.
Внедрение средств защиты, разумеется, необходимо. Но если это происходит лишь как реакция на угрозу, защита от новых способов атака не обеспечивается, да и вообще, о проблеме безопасности баз данных формируется весьма разное представление.
Также существует множество разнородных средств повышения безопасности БД, что стало причиной отсутствия понимания комплексной безопасности баз данных. Нет общего подхода и к обеспечению безопасности хранилищ данных. Сложно спрогнозировать атаки, разработать действенные защитные механизмы. Мало того, многие системы не защищены от уже давно известных атак, а подготовка специалистов не отлажена.
Проблемы безопасности баз данных.
Киберпреступность развивается одновременно с базами данных и средствами защиты. Но, несмотря на это, за последние годы список главных уязвимостей СУБД мало изменился. Выполнив анализ архитектуры БД, известных уязвимостей, имеющихся средств обеспечения безопасности СУБД и прецедентов нарушения безопасности, можно отметить следующие причины появления проблем:
1.Разработчики баз данных, администраторы и программисты уделяют недостаточное внимание вопросам безопасности баз.
2.Разные СУБД применяют различные языковые конструкции доступа к данным, однако они организованы на основе той же модели.
3.Всерьёз занимаются проблемами безопасности лишь крупные производители СУБД.
4.Возникают новые модели хранения данных и их виды, сразу попадая в зону риска.
Кроме того, ряд уязвимостей потенциально опасны из-за банального невнимания, а иногда даже и незнания администраторами систем БД вопросов безопасности. К примеру, широко эксплуатируются в отношении веб-приложений простые SQL-инъекции (метод внедрения кода, используемый для атаки приложений, управляемых данными.), в которых достаточное внимание входным данным запросов не уделено.
Для предприятий финансовым компромиссом является использование разных средств обеспечения информационной защиты, ведь внедрение продуктов повышенной защищённости и подбор высококвалифицированного персонала — это очень большие затраты. Однако стоит понимать, что компоненты безопасности могут оказывать на производительность СУБД негативное влияние.
Проблема усугубляется и широким распространением нереляционных СУБД — они оперируют другой моделью данных, но построены по тем же принципам, если сравнивать с реляционными. Нельзя не вспомнить и про многообразие современных NoSQL-решений — это становится причиной разнообразия используемых моделей данных, и, в свою очередь, размывает границу понятия БД в целом.
Следствие вышеперечисленных проблем — это отсутствие единых методик защиты баз. Если говорить о NoSQL-системах, то тут отсутствуют не только общепринятые механизмы сохранения целостности (например, шифрование и аудит данных), но и развитые средства для аутентификации пользователей.
Инструменты сканирования и выявление уязвимостей.
Black Box
При blackbox-сканировании инструмент должен уметь работать с сервисом через те же интерфейсы, через которые с ним работают пользователи.Сканеры инфраструктуры (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose и т.д.) ищут открытые сетевые порты, собирают «баннеры», определяют версии установленного ПО и ищут в своей базе знаний информацию об уязвимостях в этих версиях. Также пытаются обнаружить ошибки конфигурации, такие как пароли по умолчанию или открытый доступ к данным, слабые шифры SSL и т.д.
Сканеры веб-приложений (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, и т.д.) тоже умеют определять известные компоненты и их версии (например, CMS, фреймворки, JS-библиотеки). Основные шаги сканера — это краулинг и фаззинг.В ходе краулинга сканер собирает информацию о существующих интерфейсах приложения, HTTP-параметрах. В ходе фаззинга во все обнаруженные параметры подставляются мутированные или сгенерированные данные с целью спровоцировать ошибку и обнаружить уязвимость.Такие сканеры приложений относятся к классам DAST и IAST -соответственно Dynamic и Interactive Application Security Testing.
White Box
При white box-сканировании различий больше.В рамках процесса VM сканерам (Vulners, Incsecurity Couch, Vuls, Tenable Nessus и т.д.) зачастую дают доступ к системам, проводя аутентифицированный скан. Таким образом, сканер может выгрузить установленные версии пакетов и конфигурационные параметры прямо из системы, не угадывая их по баннерам сетевых сервисов.Скан получается точнее и полнее.
Если же говорить о whitebox-сканировании (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs и т.д.) приложений, то речь обычно идёт о статическом анализе кода и использовании соответствуюбщих инструментов класса SAST — Static Application Security Testing.
Процессы
Процесс Vulnerability Management («управление уязвимостями») предназначен для непрерывного мониторинга защищённости инфраструктуры и патч-менеджмента.
Процесс Secure SDLC («цикл безопасной разработки») предназначен для поддержки защищённости приложения в ходе разработки и эксплуатации.
Схожей частью этих процессов является процесс Vulnerability Assessment — оценки на уязвимости, сканирования на уязвимости.
Основное различие в сканировании в рамках VM и SDLC в том, что в первом случае целью является обнаружить известные уязвимости в стороннем ПО или в конфигурации. Например, устаревшую версию Windows или community-строку по умолчанию для SNMP.
Во втором же случае целью является обнаружить уязвимости не только в сторонних компонентах (зависимостях), но в первую очередь в коде нового продукта.
Это порождает различия в инструментах и подходах. На мой взгляд, задача поиска новых уязвимостей в приложении значительно интереснее, поскольку не сводится к фингерпринтингу версий, сбору баннеров, перебору паролей и т.д.
Для качественного автоматизированного сканирования уязвимостей приложений необходимы алгоритмы, учитывающие семантику приложения, его предназначение, специфичные угрозы.Инфраструктурный же сканер зачастую можно заменить таймером. Смысл в том, что чисто статистически вы можете считать вашу инфраструктуру уязвимой, если вы её не обновляли, скажем, месяц.
Эффективная защита информации в информационной системе подразумевает регулярное проведение диагностики и мониторинга сети, компьютеров и приложений на предмет обнаружения возможных проблем в системе безопасности. Для сканирования безопасности существуют сканеры уязвимостей, сертифицированные Федеральной службой по техническому и экспортному контролю.
Аспекты создания защищённых баз данных.
Чтобы решить обозначенные проблемы и обеспечить информационную безопасность СУБД, надо перейти от практики закрытия уязвимостей к комплексному подходу, призванному обеспечить более эффективную безопасность хранилищ данных. Вот основные этапы перехода к этому:
1. Разработка комплексных методик, обеспечивающих безопасность хранилищ данных. Комплексные методики применяются как при разработке, так и при внедрении хранилищ данных и программного обеспечения. Следование такому подходу избавит от множества ошибок управления СУБД, поможет защитить данные от распространённых уязвимостей.
2. Оценка и классификация угроз СУБД. После классификации появляется возможность упорядочить угрозы и уязвимости с целью последующего анализа и обеспечения защиты. Специалисты по безопасности установят зависимость между проблемами и причинами их возникновения. Таким образом, после введения конкретного механизма в СУБД, администраторы и разработчики смогут спрогнозировать связанные с новым механизмом угрозы, а значит, заранее подготовят соответствующие средства по обеспечению безопасности.
3. Разработка стандартизированных механизмов обеспечения безопасности. В случае стандартизации языков работы с данными и подходов к защите появляется возможность создания средств безопасности, применимых к разным СУБД. На момент написания материала, к сожалению, речь идёт лишь о методических и теоретических средствах, так как появление уже готовых комплексных программных средств зависит лишь от разработчиков СУБД и производителей, точнее, от их желания следовать стандартам.
Разработка плана мер по устранению выявленных уязвимостей и улучшению общей безопасности баз данных.
Разработка плана мер по устранению выявленных уязвимостей и улучшению общей безопасности баз данных - это важный этап в обеспечении безопасности информационной инфраструктуры. Вот некоторые ключевые шаги, которые могут быть включены в такой план:
Идентификация уязвимостей: Проанализируйте результаты сканирования и выделите уязвимости, выявленные в базе данных. Это могут быть такие проблемы, как недостаточная аутентификация, отсутствие шифрования данных, уязвимости в приложениях баз данных и т. д.
Приоритизация уязвимостей: Оцените уязвимости с точки зрения их серьезности и потенциального воздействия на систему. Приоритизируйте уязвимости с наивысшим уровнем риска для устранения в первую очередь.
Разработка плана действий: Создайте план действий, определяющий конкретные шаги, необходимые для устранения каждой уязвимости. Этот план может включать в себя установку обновлений и патчей, изменение настроек конфигурации, внедрение дополнительных мер защиты и т. д.
Назначение ответственных лиц: Определите ответственных лиц, которые будут отвечать за выполнение каждого шага плана действий. Убедитесь, что каждая задача имеет четкого исполнителя и установленные сроки выполнения.
Обучение персонала: Проведите обучение персонала по методам безопасной работы с базами данных, включая управление доступом, безопасное хранение и передачу данных, а также процедуры обнаружения и реагирования на угрозы.
Внедрение мониторинга и аудита: Реализуйте системы мониторинга и аудита, которые позволят отслеживать активность в базе данных, обнаруживать подозрительные действия и реагировать на них в реальном времени.
Регулярное обновление и анализ: Периодически обновляйте план мер безопасности в соответствии с изменяющейся опасной средой и результатами анализа эффективности реализованных мер.
Резервное копирование и восстановление: Разработайте и реализуйте стратегию резервного копирования данных базы данных и план восстановления в случае нарушения безопасности или потери данных.
Методы защиты.
На практике используют несколько групп методов защиты, в том числе:
препятствие на пути предполагаемого похитителя, которое создают физическими и программными средствами; управление, или оказание воздействия на элементы защищаемой системы; маскировка, или преобразование данных, обычно – криптографическими способами; регламентация, или разработка нормативно-правовых актов и набора мер, направленных на то, чтобы побудить пользователей, взаимодействующих с базами данных, к должному поведению; принуждение, или создание таких условий, при которых пользователь будет вынужден соблюдать правила обращения с данными; побуждение, или создание условий, которые мотивируют пользователей к должному поведению.
Каждый из методов защиты информации реализуется при помощи различных категорий средств. Основные средства – организационные и технические
Технические средства защиты информации
Группа технических средств защиты информации совмещает аппаратные и программные средства. Основные:
резервное копирование и удаленное хранение наиболее важных массивов данных в компьютерной системе – на регулярной основе;
дублирование и резервирование всех подсистем сетей, которые имеют значение для сохранности данных; создание возможности перераспределять ресурсы сети в случаях нарушения работоспособности отдельных элементов; обеспечение возможности использовать резервные системы электропитания; обеспечение безопасности от пожара или повреждения оборудования водой; установка программного обеспечения, которое обеспечивает защиту баз данных и другой информации от несанкционированного доступа.
В комплекс технических мер входят и меры по обеспечению физической недоступности объектов компьютерных сетей, например, такие практические способы, как оборудование помещения камерами и сигнализацией.
Планирование тестирования. В этом этапе определяются цели и объем тестирования, разрабатывается тестовый план, определяются ресурсы, расписывается расписание и составляется список требований для тестирования.
Анализ требований и создание тестовых случаев. На этом этапе производится анализ требований к программному обеспечению и разрабатываются тестовые случаи. Тестовые случаи описывают шаги, которые необходимо выполнить для проверки функционального и нефункционального соответствия требованиям.
Подготовка тестового окружения. Здесь создаются необходимые условия для проведения тестирования, включая установку программного обеспечения, настройку тестовых данных, настройку тестовых средств и инструментов.
Выполнение тестов. На этом этапе проводятся тесты в соответствии с разработанными тестовыми случаями. Тестировщики выполняют шаги тестирования, вводят тестовые данные и проверяют результаты, сравнивая их с ожидаемыми значениями
Регистрация и отслеживание поломок. Если в процессе тестирования обнаруживаются ошибка, она регистрируется в виде дефектных отчетов. В отчетах указывается описание проблемы, шаги для воспроизведения, приоритет и серьезность. Дефекты отслеживаются и передаются разработчикам для исправления.
Анализ результатов тестирования. После завершения тестирования производится анализ результатов. Оцениваются выполнение требований, обнаруженные дефекты, покрытие тестами и эффективность тестирования.
Завершение и отчетность. На последнем этапе составляется отчет о выполненном тестировании, включающий информацию о проведенных тестах, обнаруженных дефектах, выполнении требований и других важных аспектах. Отчет передается заинтересованным сторонам, таким как руководство проекта или заказчику.
Реализация методов защиты.
Реализация методов защиты, таких как шифрование данных, управление доступом и мониторинг активности пользователей, играет ключевую роль в обеспечении безопасности баз данных. Вот некоторые основные методы защиты и способы их реализации:
Шифрование данных:
Шифрование на уровне столбцов: Зашифруйте конфиденциальные данные на уровне столбцов базы данных, чтобы обеспечить защиту при хранении и передаче.
Шифрование на уровне приложения: Используйте приложение для шифрования и расшифрования данных перед сохранением их в базе данных.
Управление доступом:
Ролевые права: Назначайте пользователям роли и определяйте их права доступа к данным на основе их ролей.
Многоуровневая аутентификация: Используйте методы аутентификации, такие как пароли, двухфакторная аутентификация и биометрическая идентификация, для обеспечения безопасного входа в систему.
Ограничение доступа к данным: Ограничьте доступ к чувствительным данным только необходимым пользователям и ролям.
Мониторинг активности пользователей:
Журналирование событий: Включите функционал журналирования, чтобы записывать все операции, совершаемые пользователями с базой данных.
Анализ журналов: Регулярно анализируйте журналы событий для обнаружения подозрительной активности и инцидентов безопасности.
Системы мониторинга безопасности: Реализуйте системы мониторинга безопасности, которые могут автоматически определять аномальную активность и предпринимать меры по ее предотвращению или реагированию.
Обновления и патчи:
Регулярно обновляйте базу данных и соответствующее программное обеспечение, чтобы исправить известные уязвимости и обеспечить безопасность системы.
Обучение персонала:
Проводите обучение персонала по методам безопасной работы с базами данных, включая соблюдение правил доступа, сохранение конфиденциальности данных и определение аномальной активности.
Резервное копирование и восстановление:
Разработайте стратегию резервного копирования данных и план восстановления для быстрого восстановления базы данных в случае нарушения безопасности или потери данных.
Реализация этих методов в сочетании с регулярным обновлением и анализом мер безопасности поможет существенно повысить уровень защиты баз данных от угроз.
Причины взлома компании Target.
Проведя анализ данной ситуации мы выделили основные проблемы почему компанию Target была взломана:
1. Через один из публичных корпоративных порталов Target хакеры нашли электронный ящик компании Fazio Mechanical Services - одного из подрядчиков Target, обслуживавшего системы кондиционирования.
2. С помощью зараженного трояном Citadel электронного письма хакеры получили доступ к компьютеру Fazio. В качестве антивируса в Fazio использовали MBAM - малоизвестный бесплатный антивирус, предназначенный только для домашнего использования, который, по всей видимости, выявить трояна в письме не смог.
3. Используя реквизиты доступа Fazio, хакеры получили доступ к внутренним системам биллинга и управления проектами Target. Эти сервисы оказались в одной сети с платежными терминалами Target, построенными на базе ОС Windows. Все терминалы имели незаблокированную стандартную учетную запись (наверное речь идёт о локальном админе).
4. Хакеры заразили несколько терминалов вредоносным ПО и примерно 2 недели тестировали и отлаживали вирус.
5. 30 ноября хакеры загрузили вирус на большую часть платежных терминалов Target. Начался этап сбора платежной информации. Примерно в это же время хакеры загрузили на сервер Target программу, предназначенную для сбора и передачи информации на сервера хакеров. Система антивирусной защиты Target (Symantec Endpoint Protection) сработала и выдала предупреждение персоналу. Предупреждение было проигнорировано. 30 ноября и 2 декабря Target так же получала предупреждения о вирусной активности внутри сети от FireEye, которые тоже были проигнорированы.
6. В течении 2х недель хакеры в реальном режиме времени собирали с платежных терминалов информацию об используемых банковских картах.
7. 11 декабря сэмпл малвари был загружен кем то на VirusTotal.
8. В тот же день на закрытых форумах стали продавать дампы карт. Американские банки начали внутреннее расследование.
9. 12 декабря Минюст США связался с Target по поводу утечки карт.
10. Только 15 декабря Target начал предпринимать действия по ликвидации утечки.
11. 18 декабря Браян Кребс написал свой пост, с которого начался публичный скандал по поводу взлома.
Необходимо так же отметить, что сеть Target была модернизирована в 2013 году компанией FireEye с целью усиления уровня информационной безопасности. В сентябре 2013 года за несколько месяцев до взлома Target прошел сертификацию на соответствие PCI DSS. Кроме того правительство США и платежная система Visa предупреждали торговые сети о возросшей опасности взлома и новом механизме кражи пинкода путем парсинга оперативной памяти платежного терминала на базе Windows.Таким образом в ходе взлома Target были скомпрометированы следующие контроли информационной безопасности:
1. Система управления доступом к ресурсам информационной сети Target отсутствовали требования к информационной безопасности рабочих мест контрагента; отсутствовала двухфакторная аутентификация субъектов доступа; доступ контрагентов к внутренним ресурсам Target не был ограничен служебной необходимостью; на платежных терминалах имелись активные стандартные учётные записи, вероятно, с предсказуемым паролем по-умолчанию или без него.
2. Сегментирование локальной сети платежные технологические процессы оказались в одном сетевом сегменте с информационными; отсутствовали либо не были должным образом сформулированы правила межсетевого взаимодействия внутри корпоративной сети Target; отсутствовал мониторинг сетевой активности между сегментами.
3. Антивирусная защита анализ отчетов антивирусных средств не осуществлялся.
4. Организация службы информационной безопасности отсутствовала работа с контрагентами компании в области обеспечения информационной безопасности; отсутствовал мониторинг событий информационной безопасности; система информационной безопасности компании не учитывала отраслевых требований и рекомендаций в области информационной безопасности (PCI DSS); неудовлетворительная реакция ответственных лиц на сообщение о взломе.
Если бы компания Target исполнила бы любое из указанных выше требований, размер утечки был бы существенно ниже или взлома и вовсе можно было бы избежать.
Выводы:
Target знала о гипотетической возможности подобного взлома, существовали требования и рекомендации регуляторов, которые позволили бы избежать утечки, компания была оснащена необходимыми средствами защиты информации и инвестировала деньги в создание СИБ.
Ключевым фактором утечки Target следует признать человеческий. Именно отсутствие профессиональных кадров по ИБ с должными полномочиями привело к тому, что существовавшая СИБ не сработала, отчеты антивирусных средств игнорировались, информацию об утечке просто не кому было принять и отреагировать.