«Доктор Веб» и Sun Microsystems протестировали шлюз безопасности

«Доктор Веб» и Sun Microsystems протестировали шлюз безопасности

Проведенное исследование подтвердило, что шлюз безопасности, разработанный на основе аппаратной платформы Sun Microsystems Sun Fire Х4150 на базе двухядерных процессоров Intel Xeon и решений «Доктора Веб» (Dr.Web для почтовых серверов Unix и Dr.Web для интернет-шлюзов Unix), обеспечивает защиту от вирусов и спама даже при максимально жестких условиях эксплуатации.

Одним из итогов проведенного исследования стало определение наиболее подходящих (типовых) конфигураций серверов для различных групп пользователей.

Проведенное исследование показало, что шлюз безопасности, созданный усилиями «Доктора Веб» и Sun Microsystems, способен обрабатывать до 30 сообщений в секунду не только в период пиковых нагрузок, но и в течение всего цикла тестирования. Производительность программно-аппаратного комплекса позволяет использовать его в организациях различного размера. По расчетам специалистов, данной производительности может быть достаточно для компании с числом сотрудников до 250 человек, при том что уровень спама может составлять 90% от общего количества трафика.

Предложенное решение имеет существенный запас по производительности, несмотря на то что построено на основе платформы с процессорами Intel Xeon 5160, имеющими тактовую частоту всего лишь 3 ГГц, что обеспечивает работу в самых различных условиях без потери передаваемых данных и задержек при обработке трафика.

Тестирование производилось на тестовом стенде, организованном совместно «Доктором Веб» и Sun. Тестовая сеть, построенная на основе серверов Sun Fire Х4150 (в качестве почтового сервера использовалась одна система Sun Fire Х4150), работавших под управлением операционных систем Solaris 10, позволила имитировать работу шлюза безопасности компании, подвергавшегося атакам спамеров. При этом сам шлюз безопасности работал в условиях, гораздо более тяжелых, чем встречающиеся в действительности. В частности, нагрузки на сервер равнялись не усредненным по времени значениям, характерным для соответствующих типов организаций, а постоянно соответствовали пиковым нагрузкам, то есть в сутки сервер обрабатывал в разы больше информации, чем ему пришлось бы обработать в реальных условиях.

Проведенное исследование подтвердило, что шлюз безопасности, разработанный на основе аппаратной платформы Sun Microsystems Sun Fire Х4150 на базе двухядерных процессоров Intel Xeon и решений «Доктора Веб» (Dr.Web для почтовых серверов Unix и Dr.Web для интернет-шлюзов Unix), обеспечивает защиту от вирусов и спама даже при максимально жестких условиях эксплуатации.

" />

В HoneyCorn нашли способ устранить недостатки IoC

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

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

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

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

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

Давайте разберём почему.

  1. В классическом TI не собираются необходимые индикаторы компрометации в требуемом виде (базы паролей, используемых при брутфорсе, полные параметры фишинговых писем, семплы файлов, а также YARA-правила и хеши для инжектов и т. д.).
  2. Нет быстрой верификации индикаторов компрометации, в связи с этим — большое количество ложных срабатываний.
  3. Нет общепринятой классификации индикаторов компрометации по целевым спискам для решения всех необходимых задач и тюнинга количества ложных срабатываний.
  4. Нет единой унифицированной шины распространения индикаторов компрометации.
  5. Нет профессионального сообщества, обмена индикаторами компрометации для повышения базы сбора.
  6. Сейчас нет действенных механизмов сбора новых индикаторов без взлома реальных заказчиков.
  7. Не происходит автоматический реверс угроз нулевого дня.

И это только вершина айсберга – крутая технология становится посредственной из-за ряда практических недочётов.

В HoneyCorn заявляют, что нашли способы закрыть обозначенные пробелы. Детали проекта пока не раскрываются, однако команда приглашает к сотрудничеству других разработчиков ИБ-решений — для создания единой шины обмена индикаторами компрометации, а также компании-заказчики — для практического тестирования новых подходов.

RSS: Новости на портале Anti-Malware.ru