Как исправить уязвимость программы

Автор: Celil ÜNÜVER

celilunuver[n0sp4m]gmail.com

http://tcc.hellcode.net/musashi

Вступление

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

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

В этой статье я объясню, как исправить уязвимости программного обеспечения.

Исправление

Данная технология также известна как “HotPatching” или “runtime patching “. Исправление является методом модификации двоичного кода программного обеспечения с помощью дизассемблера, отладчика, HEX-редактора и т.д.

Это очень распространенный прием для обратной разработки. Его можно использовать для перехвата API, взлома, вставки кода и т.д. Но в моей статье, я объясню, как использовать эту технику, чтобы закрыть дыры в безопасности.

Инструментарий

Для нашей работы пригодится программное обеспечение, которое хорошо известно и используется всеми реверсивными проектировщиками (отладчиками, дизассемблерами и т.д.). Но задачу может упростить дизассемблер /отладчик, который имеет встроенные функции для редактирования ассемблера и бинарного кода, такой как IDA Pro, Ollydbg.

К сожалению, встроенные функции для редактирования ассемблера и бинарного кода в IDA или Ollydbg доступны только для “x86” исполняемых модулей. Например, если вы хотите исправить исполняемый код ARM или Xbox, вы должны посмотреть на код операции (инструкция кодирования) в информации о процессоре.

Практика

Выполним ”hotpatching” для программы, которую я расположил ниже. Как видите, она имеет уязвимость переполнения буфера. А теперь скомпилируем ее и забудем исходный код, теперь это наше программное обеспечение с закрытым исходным кодом…

#include

int main()

{

char buf[16];

printf("nString giriniz:");

scanf("%s", &buf);

return 0;

}

Как видите в исходном коде и коде сборки, scanf не проверяет размер строки. (% s)

Очевидно вы знаете, что проверить размер строк могут такие функции, как scanf и sprintf. Просто нам нужно поставить целые числа перед форматируемым значением. (e.g% 15s или %0,15 s)

Попробуем решить эту проблему. Для исправления я предпочитаю использовать Ollydbg. Он удобен для этого. IDA я использую только для анализа.

Откроем уязвимую программу через OllyDbg;

Как вы видите в дизассемблере, оно вызывает “00403011” смещение для перемещения строки в буфер.

Через CTRL + G комбинацию попадем на “00403011” адрес.

Думаю, из картинок вам все стало ясно:] Так что теперь мы будем модифицировать следующую строку –> “AND EAX, 694D0073”.

Записываем “and eax, 733531” вместо кода “and eax, 694D0073” (а вы знаете, что коды 313573 являются шестнадцатеричными типами кодов “% 15s”и мы записали его, согласно принципу Last In First Out!)

Ну, вот и все! Мы с легкостью исправили уязвимую часть нашего программного обеспечения. Для сохранения исправлений, щелкните правой кнопкой на исправленной строке и выберите “Копировать в исполняемый модуль>Выбор “. Откроется новое окно, а при закрытии будет предложено сохранить изменения или не сохранять их. После сохранения вы можете попытаться переполнить ее 🙂

Давайте посмотрим на нашу исправленную программу через IDA PRO;

Заключение

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

Благодарности

Я хотел бы поблагодарить моего брата, мою девушку, мою семью и моих друзей [murderkey, AhmetBSD ака L4M3R, Боб ((ulaş), kurti ]

Ссылки:

• http://tcc.hellcode.net
  
• http://hellcoderesearch.wordpress.com

Вот еще один риторический вопрос кибербезопасности. Можно ли победить то, что существует столько же, сколько и само программное обеспечение?

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

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

В «идеальном мире» от неуязвимого программного обеспечения индустрия информационной безопасности выглядела бы совсем по-другому, и, скорее всего, была бы гораздо меньшей, чем сегодня. На самом деле это классическая дилемма: если бы не было войны, не было бы потребности в армии; если бы не было преступлений, не нужна была бы полиция. Не будь заболеваний, и доктора ни к чему. Однако есть и войны, и преступления, и болезни, поэтому есть военные, полицейские и врачи. Все они тоже ошибаются, а порой и совершают преступления.

Можно ли победить программные #vulnerabilities? #security #notgonnahappen

Tweet

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

А что порождает недостатки в программном обеспечении? Как правило, уязвимости — результаты ошибок разработчиков, недостаточного контроля качества и/или прямо неверного подхода к написанию кода, когда программа пишется с первого же дня без оглядки на безопасность. Позднее могут выходить ворохи патчей, от которых размер оригинального пакета вырастает раза в два, а баги все продолжают и продолжают находить. Просто потому, что программное обеспечение «генетически» уязвимо.

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

Так можно ли полностью изжить баги?

Да, конечно, как только древняя максима errare humanum est изживет себя и перестанет быть применима в отношении человечества. Как скоро это произойдет?

На самом деле, всегда есть соблазн возложить вину на разработчиков, то есть тех, кто ошибается в написании кода. Время от времени раздаются «требования» привлечь разработчиков к ответственности за ошибки, которые они не смогли исправить до того, как программное обеспечение поступило в продажу. Но программные уязвимости – это, скорее, организационная проблема, которая имеет мало общего с квалификацией программистов. Кроме того, некоторые ошибки могут оставаться «вне поля зрения» несколько лет, как показали случаи с #heartbleed, багом Stuxnet и, вот буквально только что — с брешью Bash Bug/Shellshock, которая «кошмарит» специалистов ничуть не меньше, а то и больше, чем обнаруженная в апреле многолетняя дыра в OpenSSL. Ни разработчики, ни конечные пользователи не знали о них ничего, пока эти уязвимости не обнаружили эксперты по безопасности или преступники. Так что вопрос о том, кто виноват, интересен, но, в конечном счете, не уместен. Скажем, мало, что можно сделать, чтобы полностью извести ошибки в программном обеспечении, это, очевидно, просто невозможно.

Некоторые #bugs могут оставаться незамеченным годами. #security

Tweet

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

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

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

Во-вторых, защитное решение имеет должно выявлять и блокировать вредоносные атаки, использующие уязвимости, в том числе «нулевого дня» — дыры в безопасности, которые еще не исправлены. В «Лаборатории Касперского» это достигается с помощью ряда технологий, включая интеллектуальную систему Automatic Exploit Prevention, занятую поиском и блокированием необычной и потенциально вредной активности обычных приложений.

Так же в рубрике «Можно ли победить»:

• Возможно ли победить спам?
• Можно ли справиться с социальной инженерией?

Зачем вам чужие ошибки? Исправляем уязвимости в сторонних библиотеках

Любое ПО содержит уязвимости, причем они появляются на разных этапах его жизненного цикла. Полностью избавиться от уязвимостей в коде достаточно сложно, но можно, как минимум, сократить их количество. Для этого используются средства SAST, DAST и IAST – статический, динамический и интерактивный методы анализа соответственно. Эти средства можно гибко интегрировать в процесс разработки, тем самым повысив качество собственного кода. Дела обстоят сложнее со сторонним программным обеспечением, так как исправлять уязвимости в заимствованных библиотеках/фреймворках сложно и трудозатратно. Библиотеки могут быть без исходного кода, в компании может отсутствовать специалист, который готов такие исправления вносить. Да и в целом стоит задуматься о целесообразности исправлений, поскольку библиотека все-таки должна обновляться и поддерживаться командой, которая ее выпускает. Но что делать, если эта команда ленится, а использовать библиотеку надо, чтобы приложение работало? Тут пригодятся средства анализа состава программного обеспечения – SCA. Разберемся, какие SCA-инструменты существуют, как они помогают устранять уязвимости в заимствованных частях кода, и почему их имеет смысл использовать вместе с SAST.

Что представляет собой SCA как процесс? На вход подается исходный код приложения или в некоторых случаях исполняемый, после чего SCA определяет, какие сторонние библиотеки используются в приложении. В дальнейшем эта информация применяется для определения уязвимостей в приложении, а также может пригодиться для проверки лицензионной чистоты библиотеки. Есть различные способы определения используемых библиотек/фреймворков:

1. Если на вход подается исходный код, то самый верный способ – посмотреть на конфигурационные файлы, так как в большинстве случаев система сборки может показать все зависимости без самой сборки. Например, на mvn dependency:tree, в которых прописаны зависимости, – нужно составить список таких файлов. Также необходимые зависимости могут создаваться путем компиляции нужных файлов, например, для Java такие файлы будут добавляться путем сборки исходного кода (см. примеры файлов):
   • Java/Scala/Kotlin — pom.xml, build.gradle, build.sbt + Manifest
   • C# — *.csproj
   • PHP — composer.json
   • JavaScript — package.json (Node.js)
   • Ruby — Gemfile, Gemfile.lock
2. Можно определять по названиям пакетов/файлов.
3. По хешам файлов можно понять, какие библиотеки и какой версии используются.
4. Также можно применять специальные средства, например, OWASP dependency check, для последующей обработки полученных результатов. Например, для самостоятельного поиска уязвимостей в компонентах, которые определились подобными средствами.

Источники информации для SCA

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

1. риски безопасности (Security Risk), то есть поиск уязвимостей в сторонних компонентах;
2. риски использования устаревшего программного обеспечения (Obsolescence Risk);
3. лицензионные риски (License Risk), то есть правомерность использования сторонних компонентов из-за лицензионной политики.

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

1. CVE – основной источник информации об уязвимостях в конкретных версиях продукта, самая полная из бесплатных баз данных с уязвимостями, остальные на нее опираются (см. скриншот):

   

2. NVD – национальная база данных уязвимостей США, основана на CVE, для многих уязвимостей указана оценка CVSS (Common Vulnerability Scoring System) версии 3.0 и 2.0, что может быть полезно для понимания критичности вхождения. Пример:

   

3. VulnDB – платная база данных, которая содержит более полную информацию по уязвимостям, чем CVE.

   

Пример работы SCA-инструмента

После загрузки проекта, например, git репозитория, происходит анализ его компонентов. Следует отметить, что для каждого языка программирования могут быть свои требования для проведения анализа. Например, для Java нужно, чтобы проект корректно собирался базовыми командами средства Maven, или же можно передать на анализ уже собранный проект. В первую очередь оценивается безопасность проекта, после чего следует оценка лицензионной чистоты, то есть насколько правомерно используется та или иная сторонняя библиотека. В качестве примера рассмотрим результаты анализа, проведенного с помощью продукта компании WhiteSource, так как представленный им отчёт и его визуализация наиболее наглядно демонстрируют возможности SCA-инструментов.

Этот продукт работает по 3-му способу определения используемых библиотек/фреймворков – определение по хеш-сумме: хеш-сумма библиотеки сопоставляется с различными хеш-суммами из базы данных вендора. Как можно увидеть на скриншотах выше, действительно, SCA средство может найти проблемные библиотеки и подсказать, что же с ними делать. Зачастую достаточно их просто пропатчить до безопасной версии. Но так ли все просто на самом деле?

Есть несколько нюансов:

1. У вас может эксплуатироваться разрабатываемая или модифицированная компонента (библиотека/фреймворк), которой, попросту нет в базе данных вендора, а проверять ее нужно. Например, .jar библиотека, без которой не работает какой-то модуль вашего веб-приложения.
2. Также вы можете использовать узкоспециализированную версию библиотеки, которую невозможно обновить до безопасной без ущерба для работы вашего приложения.
3. Или же применяется библиотека на каком-то специализированном языке программирования, например, Solidity, для которого просто нет записи в базе данных вендора, как и поддержки анализа подобных библиотек в целом.
4. Может возникнуть проблема с полнотой базы данных SCA-инструмента для вашего типа проектов. В основном вендоры этих систем используют свои собственные базы поиска библиотек, поэтому для вашего стэка проектов подобных библиотек в базе вендора может и не найтись.

Это достаточно частые случаи, с которыми необходимо работать. Кроме того, могут появляться проблемы со сборкой какого-то из компонентов системы или корректной настройки SCA-инструмента для получения полных результатов. Но подобные сложности уже не связаны с технологией анализа сторонних компонентов в целом, а скорее с решением конкретного вендора.

Что же делать с нюансами?

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

Рассмотрим более подробно варианты использования инструментов SAST для решения подобных проблем.

Самый простой вариант, когда исходный код библиотеки есть. В таком случае для анализа кода на уязвимости достаточно лишь загрузить его в статический анализатор в виде архива с кодом.

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

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

Рассмотрим также вариант посложнее, когда есть, например, .jar файл, для которого SCA-средство не смогло найти никакой информации. На самом деле, это достаточно частый случай, когда какая-то из компонент не идентифицируется – такое происходит в 6ти из 10ти сканирований. Как в таком случае убедиться в безопасности использования заимствованной компоненты?

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

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

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

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

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

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

Резюмируя, хотелось бы отметить: SCA-средства отчасти помогут избежать головной боли со сторонними и собственными библиотеками, но их рекомендуется использоваться в комбинации с инструментами статического анализа для действительно качественного устранения уязвимостей в приложениях. Более того, эти решения должны постоянно участвовать в разработке, для этого их стоит внедрить в процесс безопасной разработки. Это позволит проводить проверки на различных этапах жизненного цикла программного обеспечения (об этом мы писали в нашей серии статей про внедрение SAST для обеспечения безопасной разработки). Таким образом можно получить максимальную пользу от подобных инструментов.

Автор: Антон Прокофьев, ведущий аналитик Solar appScreener

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

Самыми опасными уязвимостями являются в первую очередь незакрытые уязвимости. Когда обнародованная уязвимость получает код в базе данных общеизвестных уязвимостей информационной безопасности Common Vulnerabilities and Exposures (CVE), то стоит обратить внимание на ее рейтинг опасности – Common Vulnerability Scoring System (CVSS) Severity Rating. Рейтинг нумеруется от 0 до 10 и последние значения предполагают очень высокую степень опасности. Уязвимости с рейтингом 7.0–10.0 крайне желательно оперативно устранять.

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

• Установка обновления ПО с программной коррекцией для обнародованной уязвимости,
• Использование механизмов так называемого «виртуального патчинга».

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

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

Механизмы «виртуального патчинга» применяются на разных уровнях цифровой среды: на внешнем или внутреннем периметре сети с помощью NGFW (или UTM, IPS) решений, на специализированных для защиты отдельных информационных систем шлюзах – WAF и т.д. Если на периметральных средствах защиты грамотно реализованы политики доступа, то доставка эксплоит для существующих в инфраструктуре уязвимостей сама по себе будет сложно решаемой для хакера задачей.

Например, для уязвимости EternalBlue (CVE-2017-0144) необходимо связаться с узлом жертвы по протоколу SMBv1, и, если данный трафик блокируется на уровне периметра сети средствами NGFW или IPS, то таким образом червь WannaCry не проникнет к вам в систему. Но доставка первого экземпляра эксплоита во внутреннюю сеть компании может произойти и другими путями. Поэтому, если уязвимость не устранена, шифровальщик распространится горизонтально в инфраструктуре.

Для определения уязвимостей в инфраструктуре используются сканеры типа Nesus Professional от Tenable, PT MaxPatrol 8 и др. Отдельно можно проверить исходный код приложений, если он доступен. Для этого используются решения типа PT Application Inspector, CheckMarx Static Code Analysis, Solar appScreener и другие сканеры исходного кода.

Использование этих решений в идеале должно быть встроено в процесс разработки на регулярной основе, равно как и обновление используемых open source программных пакетов и библиотек. Существует отдельный класс решений, позволяющий определить на основании анализа версий ПО в инфраструктуре, известных уязвимостей и политик ИБ средств защиты возможные векторы атак. Это системы типа SkyBox, RedSeal и др.

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

• На сети при перехвате передачи вредоносного файла в инфраструктуру средствами периметральной защиты и передачи их на анализ в Sandbox-решения или «песочницу» – среду эмуляции стандартных пользовательских и серверных сред работы, где производится анализ файла на выполняемые им в системе действия.
• На узлах сети через анализ активности файла уже непосредственно в системе, используя EDR-решения. Если файл осуществляет действия, характерные для вредоносного ПО и не характерные для типовых файлов используемого им расширения, то его выполнение приостанавливается.
• На сети при перехвате передачи вредоносного файла в инфраструктуру средствами периметральной защиты и передачи их на анализ в Sandbox-решения или «песочницу» – среду эмуляции стандартных пользовательских и серверных сред работы, где производится анализ файла на выполняемые им в системе действия.
• На узлах сети через анализ активности файла уже непосредственно в системе, используя EDR-решения. Если файл осуществляет действия, характерные для вредоносного ПО и не характерные для типовых файлов используемого им расширения, то его выполнение приостанавливается.

Ущерб от незакрытых уязвимостей выливается в успешные кибератаки, которые могут стать как причиной репутационных рисков, так и чисто экономических, например, простои в работе систем, от узлов работников компании и вплоть до АСУ ТП и промышленных систем. ИТ- и ИБ-отделы должны быть в данном случае заодно и конструктивно взаимодействовать, и там, где нет объективной возможности исправления ПО через установку программных коррекций, использовать альтернативные методы защиты и «виртуального патчинга». Не стоит забывать, что целью всех сотрудников, и ИТ, и ИБ, в компании является ее успешное бесперебойное функционирование.

Автор: Анна Михайлова, системный архитектор группы компаний Angara.

ЧИТАТЬ ВСЕ НОВОСТИ НА САЙТЕ | ПОДПИСЫВАЙТЕСЬ НА НАШ TELEGRAM КАНАЛ