Блог

Продолжение статьи

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

Change Auditor Threat Detection связывает необычное место доступа с последующей подозрительной активностью, например снупингом или внесением необычных изменений BAD. Таким образом, аномальное место доступа предоставляет дополнительный контекст, который повышает уровень предупреждения, и становится очевидной необходимость быстро расследовать событие (экран 6).

Индикаторы такой активности:

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

Продолжение статьи

Иногда интенсивность действий с какой-нибудь учетной записью настолько велика, что их определенно не может выполнять пользователь в интерактивном режиме. Поэтому вероятно, что с учетными данными пользователя работает программа или сценарий, возможно с целью внести разрушительные изменения в AD или ценные данные в файлах (экран 5). Грамотно спроектированные программа или сценарий могут завладеть учетной записью пользователя и работать медленнее, чтобы не вызвать предупреждения в результате простого превышения порога. Но даже эта тактика не позволит обойти Change Auditor Threat Detection. Данное решение постоянно сравнивает текущее поведение пользователя с индивидуальным базовым шаблоном, и ненормальное число попыток доступа или внесения изменений будет сразу отмечено как вероятная атака.

К индикаторам такой активности относится чрезмерное число успешных или неудачных попыток:

• изменить пользователей или группы в Active Directory;
• выполнить доступ, переместить или удалить файлы;
• проверить подлинность учетных данных пользователей;
• выполнить доступ к различным компьютерам и серверам.

 

В продолжение статьи

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

Change Auditor Threat Detection может обнаружить многие признаки ненормальной активности AD, в том числе:

• резкий всплеск количества изменений, вносимых в AD пользователем, по сравнению с его обычной нормой, возможно указывающий, что учетная запись скомпрометирована и используется для уничтожения критических данных каталога (экран 1);
• привилегированные пользователи, выполняющие административные действия, которые не являются их обычной обязанностью, например сотрудник службы поддержки первого уровня, ответственный
  только за разблокировку учетных записей пользователей и сброс их паролей, внезапно начинает создавать новые учетные записи пользователей или изменять членство в группах (экран 2);
• изменение пользователями членства в конфиденциальных привилегированных группах AD, что может указывать на несанкционированную эскалацию привилегий;
  значительное увеличение количества изменений учетных записей AD, за которым может скрываться использование интерактивной привилегированной учетной записи для запуска сценариев;
• ненормальное число неудачных изменений AD, что может указывать на попытку использовать скомпрометированные учетные данные.

Продолжение статьи

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

Change Auditor Threat Detection идентифицирует подозрительную активность, указывающую на скомпрометированные учетные записи, не засыпая вас лавиной предупреждений.

Change Auditor Threat Detection выделяет не только неудачные попытки доступа к данным, для которых у пользователя явно нет разрешений, но и успешные попытки доступа к данным, находящимся вне кометенции пользователя, в случаях, когда разрешения определены недостаточно строго (экран 3). Индикаторы такой активности следующие:

• большое число попыток доступа к файлам в течение короткого времени;
• большое число событий неудачного доступа к файлам;
• попытки доступа к файловому серверу и папкам, к которым пользователь редко или никогда не обращался в прошлом.

Всем известен классический сюжет фильмов ужасов: герои спешно запирают двери и окна, но обнаруживают, что чудовище уже в доме. Специалистам по ИТ-безопасности полезно пересмотреть эти кадры и поразмышлять о том, какое отношение они имеют к их работе. Сейчас многие компании тратят миллионы долларов, укрепляя периметр защиты, чтобы не допустить проникновения злоумышленников в свою сеть, но не уделяют достаточного внимания пользователям, которые уже находятся внутри компании. Опасность уже внутри, независимо от того, знаете вы об этом или нет. Согласно документу Cyber Security, внутренние угрозы составляют 60% всех атак. Насколько быстро вы можете обнаружить и блокировать действия сотрудника или подрядчика, злоупотребляющего своими привилегиями? Использует ли взломщик учетные данные, полученные в результате фишинга? Программа-шантажист шифрует ваши ценные файлы? Проходят минуты, а риск сопряженных с серьезными убытками потерь данных резко увеличивается. Насколько серьезными? Поданным исследования Ponemon 2017 Cost of Data Breach Study, средний размер убытков от одного взлома достигает величины в 25 млн рублей.

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

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

Change Auditor Threat Detection

Change Auditor Threat Detection — необычный продукт. В нем используется машинное обучение и анализ поведения пользователей и сущностей User and Entity Behavioral Analytics (UEBA), позволяющий выделить из огромного массива данных аудита активность, указывающую на настоящего злоумышленника или скомпрометированную учетную запись. Затем выявляются наиболее подозрительные пользователи и выдаются предупреждения, чтобы можно было быстро и эффективно среагировать на опасность. В частности, данное решение определяет базовый уровень нормального поведения каждого пользователя— обычное время регистрации в системе, к каким папкам и файлам он обращается, типы изменений, вносимых им в Active Directory (AD) и т. д. Затем машинное обучение без управления, анализ поведения пользователя, SMART-корреляция и набор заранее определенных индикаторов угрозы используются для анализа последующего поведения пользователя в реальном времени и обнаружения истинных угроз. Например, в одной реально существующей среде с 7000 пользователей описываемое решение за 45 дней выделило 42 потенциально опасных пользователя на основе 46 млн исходных событий (см. рисунок).

Далее в статье будет описано девять самых важных шаблонов подозрительного поведения, которые может обнаружить Change Auditor Threat Detection.

1. Ненормальная активность в службе каталогов AD.
2. Атака методом подбора.
3. Пользователь, ведущий наблюдение.
4. Несанкционированное копирование, передача, извлечение или уничтожение данных.
5. Повышение прав.
6. Использование привилегированной учетной записи на основе сценариев.
7. Необычный доступ к системе.
8. Вредоносные программы.
9. Боковое смещение.

Втечение почти десяти лет DevOps пользуется повышенным вниманием, по крайней мере среди специалистов в ИТ-отрасли. Повсюду мы слышим похвалы аналитиков в адрес DevOps как лучшего, быстрого, безопасного и одновременно наименее затратного подхода к построению и развертыванию программного обеспечения. Это убедительные аргументы. В большинстве случаев понять преимущества DevOps не составляет труда. Но сегодня во многих компаниях у DevOps есть один существенный недостаток: применение теории DevOps на практике. Легко говорить об этом подходе на абстрактном уровне. Гораздо сложнее понять, как использовать DevOps в реальной среде или преобразовать принципы DevOps в действенные практические методы. По-видимому, это одна из причин, почему компании обычно сообщают о медленных темпах внедрения DevOps. Если перед вами стоит такая проблема, то в этой статье вы как раз найдете практические советы по работе с DevOps.

DevOps на высоком уровне

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

Разные специалисты определяют DevOps по-разному, но основные споры разгораются вокруг нескольких ключевых принципов.

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

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

Внедряем DevOps в практику

Труднее реализовать конкретные процессы и инструменты, обеспечивающие перечисленные выше цели. В отличие от многих ИТ-концепций, таких как «облако» и «автоматизированное тестирование», внедрение DevOps не сводится просто к использованию нового типа инфраструктуры или нового типа инструмента. Недостаточно также нанять нужных специалистов, хотя некоторые компании ошибочно считают, что наоборот (именно поэтому «инженер DevOps» — такая востребованная позиция у кадровиков). В действительности реализация DevOps на практике требует изменения конфигурации всего процесса доставки программного обеспечения, для этого необходимы разнообразные новые инструменты, а также применение существующего инструментария новыми способами. Помня об этих трудностях, перейдем к практическим советам по реализации DevOps.

1. Выбор необходимых инструментов

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

• Сервер непрерывной интеграции, такой как Jenkins или TeamCity. Такой инструмент помогает обрабатывать новый программный код со скоростью непрерывной доставки.
• Инфраструктура автоматизированного тестирования, такая как Selenium, с помощью которой можно быстро тестировать приложения в различных средах.
• Инструменты мониторинга программного обеспечения, которые помогают обнаружить проблемы доступности и производительности. В идеальном случае эти инструменты используются не только для рабочих приложений, но и на этапах предварительной подготовки к выпуску в канале доставки программного обеспечения.
• Средства обмена данными, такие как Slack и Trello, которые помогают упростить обмен информацией между рабочими группами.

Другие полезные типы инструментов:

• Инструменты управления настройками, такие как Ansible или Puppet. Эти инструменты помогают автоматизировать подготовку инфраструктуры и развертывание приложений. Они необязательны, если масштаб операции доставки программного обеспечения мал, но критически важны при масштабировании.
• Инструменты оркестровки приложений, такие как Kubernetes, также критичны для крупномасштабных развертываний программного обеспечения.

2. Определение инфраструктуры

В дополнение к применению подходящих инструментов для DevOps необходимо определить тип инфраструктуры, вместе с которым будут использоваться инструменты. Рассмотрите следующие (перекрывающиеся до некоторой степени) варианты:

• «Облачная» инфраструктура IaaS, которая обеспечивает более высокую масштабируемость и переносимость, чем локальная инфраструктура.
• Контейнеры Docker полезны для непрерывной доставки, поскольку упрощают запуск однажды спроектированного программного обеспечения в любом месте (при условии поддержки Docker, но это справедливо для большинства современных сред Linux и Windows).
• Бессерверные функции, еще один строительный блок для экономичного масштабирования развертывания приложений.
• Возможно, вы уже используете некоторые или все перечисленные компоненты инфраструктуры. Чтобы наиболее эффективно задействовать их для DevOps, следует найти путь оптимальной интеграции этих ресурсов в канал непрерывной доставки, доступный всем членам вашей ИТ-группы.

3. Реорганизация (или расширение) группы

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

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

4. Реализация процессов реагирования на отклики

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

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

Наши DevOps специалисты помогут оптимизировать работу и выполнят поддержку вашей инфраструктуры, обращайтесь office@itfb.com.ua

Источник: Журнал Windows ITPro