Предложение по новому формату EICAR, который охватывает современность двигателя [закрыто]
Тестовый файл EICAR использовался для функционального тестирования антивирусной системы. В настоящее время почти каждая AV-система будет помечать EICAR как «тестовый» вирус. Для получения дополнительной информации об этом историческом тестовом вирусе, пожалуйста, нажмите здесь.
В настоящее время тестовый файл EICAR хорош только для тестирования presence AV-решения, но он не проверяет наличие файла движка или DAT-файла актуальности. Другими словами, зачем проводить функциональное тестирование системы, которая может иметь файлы DAT, которым более 10 лет. С количеством вирусов, высвобождаемых ежедневно, со временем, сигнатура EICAR теряет ценность в качестве инструмента тестирования.
При этом,Я думаю, что EICAR должен быть обновлен / модифицирован, чтобы быть эффективным тестом, который работает в сочетании с решением для управления AV.
Некоторые люди на serverfault ответили на более раннюю редакцию этого вопроса.
Ответив: Пожалуйста, сосредоточьтесь на сути:
Этот пересмотренный вопрос касается тестирование функциональности AV-системы.
Пожалуйста, не отвечайте решениями для управления, так как они не тестируют то, что развернуто и в полевых условиях. Управленческие решения сообщают и о том, что может быть так или иначе несовершенно: иногда машина может быть не включена в рутинное администрирование AV из-за ошибки оператора. Иногда AV управляется другой компанией или группой. Независимо от того, какова ваша позиция по «управлению», это не учитывается в «тестовом» ИМХО после развертывания. Этот вопрос о тестировании в реальном мире, без использования живых вирусов... что является целью первоначального EICAR.
Я предлагаю новый формат файла EICAR с добавлением БОЛЬШОГО ДВОИЧНОГО ОБЪЕКТА XML, который будет условно вызывать ответ антивирусного ядра.
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-EXTENDED-ANTIVIRUS-TEST-FILE!$H+H*
<?xml version="1.0"?>
<engine-valid-from>2010-1-1Z</engine-valid-from>
<signature-valid-from>2010-1-1Z</signature-valid-from>
<authkey>MyTestKeyHere</authkey>
В этом примере антивирусное ядро будет оповещать файл EICAR только в том случае, если и сигнатура, либо файл ядра равны или новее даты, действительной с даты. Также есть пароль, который защитит использование EICAR системного администратора.
Если у вас есть отставание в TDD «Test Driven Design» для программного обеспечения, вы можете поймить, что все, что я делаю, это применяю принципы TDD к моей инфраструктуре.
Основываясь на вашем опыте и контактах, как я могу воплотить эту идею в жизнь?
Что Вы, после (в контексте системы не под Вашим управлением) вряд ли будет когда-либо становиться жизнеспособным просто, потому что это открыло бы еще одну уязвимость против самого программного обеспечения AV. т.е. стало бы возможно зондировать систему, чтобы определить, способно ли это к обнаружению последнего вируса. Если тест перестал работать, вирус мог бы быть отправлен через необнаруженный, не пробуждая неуместное подозрение.
Что касается теста EICAR, самое время, чтобы от этого отказались. Программное обеспечение Most AV, которое я видел, или трудно кодируется для обнаружения его или имеет подпись для него, делая "тест" абсолютно бесполезным.
Сам файл EICAR не тестирует на присутствие антивируса. Это просто используемый в качестве инструмента для тестирования (таким образом, Вы не Вы, знают тестирование против живых вирусов).
Существует много способов контролировать и управлять механизмом и обновлениями определения (я предполагаю, что Вы используете McAfee, так как Вы используете терминологию DAT),
Каждый антивирус предприятия имеет консоль централизованного управления в наличии. Поскольку McAffee проверяет ePolicy Orchestrator (или независимо от того, что текущее программное обеспечение SMB называют).
Я сомневаюсь, что промышленность собирается сделать новый файл EICAR ежемесячно для Вас. Это - пустая трата времени и ресурсы. Решение Вашей проблемы покупает централизованный AV как Symantec или Sophos, таким образом, можно выполнить отчет и видеть, каким клиентам нужно обновление.
Файл EICAR только тестирует на присутствие AV, это не используется для актуальности. Я полагаю, что сам файл EICAR составляет более чем десятилетие, старое в этой точке, и поэтому 'поддерживается' всем.
Решение проблемы актуальности является тем, для которого весь корпоративный класс продукты AV имеет решения. McAfee имеет ePolicy Orchestrator. Symantec имеет System Center. Microsoft ForeFront также имеет консоль создания отчетов. Они все полагаются на сами механизмы AV для сообщения основной базе о том, что они в настоящее время выполняют и в отношении определений и в отношении механизмов. Более сложные Настольные продукты Материально-технических ресурсов там могут также обеспечить этот вид сервиса.
Ответы выше указывают на Вас к централизованной консоли управления. Это обычно - лучший ответ. Я беру Вашу точку о пассивном контроле, но я думаю, что Вы являетесь немного неосновными. Центральные решения, с которыми я работал, не предполагают, что клиент получил обновление; они обновляют информацию в консоли с тем, что клиент говорит, что ее дата/версия определения. Это точно так же точно как Вы спрашивающий клиентскую машину сами некоторым другим способом. На самом деле худшей, которая может произойти, является разбивка в консоли, все еще отправление обновило DATS, но теряя коммуникацию возврата от клиента, и показав более старую дату определения в консоли, чем клиент на самом деле имеет.
Однако, если Вы не можете сделать этого (машины не собираются оставаться под Вашим управлением после развертывания, и т.д.), затем, можно попытаться узнать, где программное обеспечение AV, которое Вы используете, хранит ту информацию.
Когда я должен был сделать это для CE SAV, Вы могли запросить реестр клиентской машины для нахождения текущей версии определения AV, и я думаю дата также. Для Dat-файлов McAfee Вы смогли узнавать, где каталог DATS сохранен и имеет сценарий, который ищет созданную или измененную в последний раз дату новейшего Dat-файла в том каталоге.
Рассмотрите предложение этой идеи на http://www.eicar.org/contact/
Если я понимаю то, что Вы просите сторонний инструмент, должен протестировать, делает ли сторонний инструмент то, что они говорят, что делают? Если так, почему Вы предложили бы полагаться на сторонний инструмент, когда Вы не смогли полагаться на третьих лиц к настоящему времени?o_O
Я не уверен, что мы можем помочь Вам "заставить его произойти". Я не могу "заставить" eicar больше делать что-либо, чем я могу "заставить" Вас сделать что-то для меня. Я нашел, что, когда я не могу получить что-то выполненное через надежное третье лицо, я делаю это сам или нисколько.
Если Вы хотите протестировать почтовую безопасность, Вы могли бы попробовать почтовый тест безопасности GFIs, хотя я полагаю, что это немного устарело.
Отредактированный для добавления:
Вы продолжаете утверждать, что "обновление потребностей EICAR, чтобы быть релевантными". Нет, это не делает. Их тестовый файл AV только имеет одну цель, и это, "производят файл, который их (и многие другой) "обнаруживают" продукты, как будто это был вирус". Вот именно. В этом отношении они остаются релевантными.
Если у Вас есть сторонний поставщик, который не выполняет к Вашим ожиданиям, то Вы возвращаетесь к SLA. В Вашем SLA должно говориться, что они делают для поддержания текущего AV и как они собираются доказать это Вам к Вашей удовлетворенности. Ничто Вы устраиваете другую вечеринку, не "делает" (в этом случае, Вы просите EICAR делать другой тестовый файл, чтобы протестировать, актуален ли Ваш AV), собирается восполнить то, что Вам не разъяснили это в SLA.