АВТОМАТИЧЕСКОЕ ОБНАРУЖЕНИЕ И РЕАГИРОВАНИЕ НА УЯЗВИМОСТИ Российский патент 2012 года по МПК G06F21/00 

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Многие способы уменьшения уязвимости безопасности программного обеспечения являются реагирующими постфактум и интенсивными по времени. То есть, как только уязвимость обнаружена, компании-разработчики некоторое время спустя, как правило, выпускают программу-исправление («заплатку»), применяемую для того, чтобы противодействовать атакующей стороне в использовании этой уязвимостью. Хотя эта стратегия функционировала хорошо для защиты пользователей в прошлом, ее эффективность частично требует, чтобы (1) обнаружители уязвимостей находили уязвимости до хакеров, (2) обнаружители уязвимостей сообщали о проблемах компаниям-разработчикам программного обеспечения прежде, чем они раскроют их публично, а также (3) высоких темпов ввода исправлений в эксплуатацию, чтобы в случае, если использующий уязвимости вредоносный код (эксплойт) разработан, принявшие исправления пользователи были защищены.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 - иллюстрация системы в соответствии с одним вариантом осуществления.

Фиг.2 - блок-схема, которая описывает этапы способа в соответствии с одним вариантом осуществления.

Фиг.3 - иллюстрация системы в соответствии с одним вариантом осуществления.

Фиг.4 - блок-схема, которая описывает этапы способа в соответствии с одним вариантом осуществления.

Фиг.5 - иллюстрация системы в соответствии с одним вариантом осуществления.

Фиг.6 - блок-схема, которая описывает этапы способа в соответствии с одним вариантом осуществления.

ПОДРОБНОЕ ОПИСАНИЕ

КРАТКИЙ ОБЗОР

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

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

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

УЯЗВИМОСТИ БЕЗОПАСНОСТИ В ЦЕЛОМ

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

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

Следовательно, исходя из сбоя программы можно сделать вывод, что существует проблема с этой программой. Данная проблема может быть связана с уязвимостью безопасности. Таким образом, сбой программы часто является признаком уязвимости, потому что: (1) многие из тех ошибок программирования, что являются причиной сбоев программы, пригодны для злонамеренного использования, (2) разработка эксплойта включает в себя значительное количество проб и ошибок - следовательно, в течение ранних стадий разработки эксплойта неудачные попытки будут приводить к сбою программы, и (3) эксплойты часто функционируют только на конкретных версиях программы и иногда приводят к сбою других версий.

ЛОКАЛЬНОЕ AVD/R

Фиг.1 иллюстрирует систему в соответствии с одним вариантом осуществления, в общем обозначенную как 100. Система 100 включает в себя вычислительное устройство 102, имеющее один или более процессоров 104, один или более машиночитаемых носителей 106 и одно либо более приложений 108, которые хранятся на машиночитаемых носителях и исполняются процессорами (процессором). Кроме того, вычислительное устройство 102 включает в себя компонент 110 локального AVD/R, который в этом примере реализован в программном обеспечении.

Хотя вычислительное устройство 102 иллюстрировано в форме настольного компьютера, можно оценить и понять, что другие компьютерные устройства могут использоваться без отклонений от сущности и объема притязаний заявленного изобретения. Например, другие компьютерные устройства могут включать в себя, в качестве примера, но не ограничения, портативные компьютеры, карманные компьютеры, такие как персональные цифровые помощники (PDA), сотовые телефоны и т.п.

В этом примере компонент 110 локального AVD/R включает в себя средство 112 контроля журнала регистрации, компонент 114 пользовательского интерфейса и средство 116 построения защиты. При работе, когда программа на локальном вычислительном устройстве дает сбой, информация, связанная со сбоем, вносится в журнал регистрации сбоев, что понятно для специалиста. Обычно журнал регистрации сбоев содержит информацию, которая описывает параметры, ассоциированные с конкретным сбоем. Например, журнал регистрации сбоев может содержать информацию, которая описывает программу, давшую сбой, какая функция или интерфейс программы дали сбой, и/или какие-либо параметры, ассоциированные с функцией или интерфейсом, которые дали сбой. Средство 112 контроля журнала регистрации из состава компонента 110 локального AVD/R может проводить мониторинг на предмет сбоев и, когда сбой имеет место, может автоматически просмотреть журнал регистрации сбоев на предмет информации, связанной с этим сбоем. Это может включать в себя выяснение того, какие функция или интерфейс связаны со сбоем. Как только средство контроля журнала регистрации установит причину сбоя, оно может задействовать средство 116 построения защиты для построения средства защиты, которым эффективно обеспечивается автоматическое решение времени исполнения, которое блокирует функцию или интерфейс. Об этом факте можно далее сообщить пользователю через пользовательский интерфейс 114.

Как пример, рассмотрим следующее. Предположим, что пользователь пользуется своим приложением-браузером, и функция Alert() дает сбой. В качестве реакции на этот сбой журнал регистрации сбоев обновляется информацией, которая относится к данному сбою, такой как имя функции, которая дала сбой, и где она дала сбой. Используя эту информацию, средство 112 контроля журнала регистрации может задействовать средство 116 построения защиты для создания средства защиты, которое автоматически блокирует функцию Alert(). В одном или более вариантах осуществления средство построения защиты может поддерживать таблицу уязвимостей/нейтрализации, как показано на чертеже. Здесь таблица уязвимостей/нейтрализации включает в себя столбец, в котором перечислены дескрипторы уязвимостей, и столбец, в котором перечислены нейтрализующие функции. Дескрипторы уязвимостей описывают конкретную функцию или интерфейс, к которой(ому) должна применяться нейтрализующая функция. Нейтрализующие функции описывают конкретные нейтрализующие функции, которые используются. В примере выше, когда происходит сбой, средство построения защиты создает запись в таблице уязвимостей/нейтрализации и добавляет “Alert()” в столбец дескриптора уязвимости. Кроме того, средство построения защиты добавляет “Заблокировать” в соответствующую строку в столбце нейтрализующей функции. Это сообщает приложению - в данном случае браузеру пользователя - что функция “Alert()” была заблокирована.

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

Фиг.2 представляет собой блок-схему, которая описывает этапы способа согласно одному варианту осуществления. Этот способ может быть реализован в связи с любым подходящим аппаратным обеспечением, программным обеспечением, программно аппаратным обеспечением или их комбинацией. В одном или более вариантах осуществления способ может быть реализован в связи с системой, такой что показана и описана на Фиг.1. Другие системы могут быть использованы без отхода от сущности и объема притязаний заявленного изобретения.

На этапе 200 обнаруживают локальный сбой программы. Примеры того, как это может быть сделано, даны выше. На этапе 202 просматривают журнал регистрации сбоев для выяснения обстоятельств сбоя. На этапе 204 блокируют функцию или интерфейс, которые привели к сбою. Примеры того, как это может быть сделано, даны выше. На этапе 206 уведомляют пользователя о блокированных функции или интерфейсе.

УДАЛЕННОЕ AVD/R

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

Как пример, рассмотрим Фиг.3. Там проиллюстрирована система в соответствии с одним вариантом осуществления, в общем обозначенная как 300. Система 300 включает в себя вычислительное устройство 302, имеющее один или более процессоров 304, один или более машиночитаемых носителем 306 и одно либо более приложений 308, которые хранятся на машиночитаемых носителях и которые исполняются процессором (процессорами). Кроме того, вычислительное устройство 302 включает в себя компонент 310 удаленного AVD/R, который в этом примере реализован в программном обеспечении.

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

В этом примере компонент 310 удаленного AVD/R включает в себя средство 312 контроля журнала регистрации, компонент 314 пользовательского интерфейса и компонент 316 сообщения о сбоях. При работе, когда программа на локальном вычислительном устройстве претерпевает сбой, информация, связанная со сбоем, вводится в журнал регистрации сбоев, как описано выше. Средство 312 контроля журнала регистрации из состава компонента 310 удаленного AVD/R может проводить мониторинг на предмет сбоев и, когда сбой происходит, может автоматически просмотреть журнал регистрации сбоев на предмет информации, связанной с этим сбоем. Это может включать в себя выяснение того, какие функция или интерфейс связаны со сбоем. Как только средство контроля журнала регистрации установило причину сбоя, компонент удаленного AVD/R, через пользовательский интерфейс 314, запрашивает пользователя о том, желает ли пользователь сообщить о сбое удаленному серверу для дальнейшего анализа. Если пользователь хочет сообщить информацию о сбое, данная информация компонуется и анализируется сервером. В по меньшей мере некоторых вариантах осуществления анализ информации о сбое может включать в себя использование экспертов-людей для анализа и установления применения каких-либо эксплойтов.

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

Фиг.4 представляет собой блок-схему, которая описывает этапы способа в соответствии с одним вариантом осуществления. Этот способ может быть реализован в связи с любым пригодным аппаратным обеспечением, программным обеспечением, программно аппаратным обеспечением или их комбинацией. В одном или более вариантах осуществления способ может быть реализован в связи с системой, такой как показана и описана на Фиг.3. Другие системы могут быть использованы без отхода от сущности и объема притязаний заявленного изобретения.

На этапе 400 обнаруживают локальный сбой программы. Примеры того, как это может быть сделано, даются выше. На этапе 402 просматривают журнал регистрации сбоев, чтобы установить обстоятельства сбоя. На этапе 404 запрашивают пользователя, чтобы установить, можно ли сообщить о сбое. На этапе 406 сообщают о сбое удаленному серверу в случае, если пользователь санкционировал это. На этапе 408 принимают и применяют средство защиты, которое приспособлено блокировать функцию или интерфейс, которые привели к сбою. Средство защиты может быть получено посредством загрузки его по сети, такой как Интернет. Как часть этого этапа, пользовательский интерфейс может использоваться для того, чтобы предложить пользователю вариант выбора для блокирования функции или интерфейс, либо повторно активации функции или интерфейса. Примеры того, как это может быть сделано, приводятся выше.

ПРИМЕНЕНИЕ КАК ЛОКАЛЬНОГО, ТАК И УДАЛЕННОГО AVD/R

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

Как пример, рассмотрим фиг.5. Там проиллюстрирована система в соответствии с одним вариантом осуществления, в общем обозначенная как 500. Система 500 включает в себя вычислительное устройство 502, имеющее один или более процессоров 504, один или более машиночитаемых носителей 506 и одно или более приложений 508, которые хранятся на машиночитаемых носителях и исполняются процессором(ами). Кроме того, вычислительное устройство 502 включает в себя компонент 510 локального/удаленного AVD/R, который, в этом примере, реализован в программном обеспечении.

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

В этом примере компонент 510 удаленного AVD/R включает в себя средство 512 контроля журнала регистрации, компонент 514 пользовательского интерфейса, средство 516 сообщения о сбоях и средство 518 построения защиты. При работе, когда программа на локальном вычислительном устройстве претерпевает сбой, информация, связанная со сбоем, вводится в журнал регистрации сбоев, как описано выше. Средство 512 контроля журнала регистрации из состава компонента 510 локального/удаленного AVD/R просматривает, может проводить мониторинг на предмет сбоев и, когда сбой происходит, может автоматически просматривать журнал регистрации сбоев на предмет информации, связанной с этим сбоем. Это может включать в себя выяснение того, какие функция или интерфейс связаны со сбоем. Как только средство контроля журнала регистрации установит причину сбоя, компонент локального/удаленного AVD/R может применить средство защиты локально, как описано выше, чтобы блокировать функцию или интерфейс, которые связаны со сбоем. Об этом можно также сообщить пользователю через компонент 514 пользовательского интерфейса, который также может позволить пользователю повторно активировать функцию или интерфейс, которые были блокированы.

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

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

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

На этапе 600 обнаруживают локальный сбой программы, и на этапе 602 запрашивают одобрение пользователя на сообщение об этом сбое удаленному серверу. Если одобрение пользователя получено на этапе 604, тогда на этапе 606 выясняют причину сбоя, сообщают о сбое удаленному серверу и выполняют проверку на предмет каких-либо решений, которые могут быть доступными для сбоя. Посредством сообщения о сбое удаленному серверу, по множеству пользователей может быть проведен анализ сбоя и на предмет любых связанных с ним шаблонов. Анализ может включать в себя как автоматический, машинный анализ, так и анализ, выполняемый людьми. На этапе 608 затем загружают и применяют локально любые соответственные средства защиты, и на этапе 610 уведомляют пользователя.

Если, с другой стороны, одобрение не получено на этапе 604, на этапе 612 идентифицируют сбойные функцию или интерфейс, и на этапе 614 определяют приемлемость средства защиты. Если на этапе 616 определено, что есть приемлемое локальное средство защиты для решения проблемы, на этапе 618 применяют это средство защиты, как описано выше, и на этапе 620 уведомляют пользователя. Если, с другой стороны, нет никакой приемлемой защиты, на этапе 620 уведомляют пользователя.

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

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

ЗАКЛЮЧЕНИЕ

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

Хотя изобретение было описано на языке, характерном для структурных признаков и/или методологических этапов, нужно понимать, что изобретение, определенное в приложенной формуле изобретения, не обязательно ограничено описанными конкретными признаками или этапами. Скорее, конкретные признаки и этапы раскрыты как предпочтительные формы осуществления заявленного изобретения.

Изобретение относится к области обнаружения и реагирования на уязвимости. Техническим результатом является повышение эффективности обнаружения и нейтрализации уязвимостей. Согласно различным вариантам осуществления обнаруживают уязвимости безопасности и, в качестве реакции, могут изменить подвергающуюся их воздействию программу так, чтобы даже если вредоносный код исполняется, целостность данной программы будет сохранена и поддержана. В по меньшей мере некоторых вариантах осуществления компонент локального автоматического обнаружения уязвимостей и реагирования на уязвимости (AVD/R) исполняется на пользовательской локальной машине для обнаружения и нейтрализации возможных уязвимостей посредством использования средства защиты; и компонент удаленного автоматического обнаружения уязвимостей и реагирования на уязвимости (AVD/R) исполняется, чтобы сообщать о зафиксированных уязвимостях так, чтобы одно или более средств защиты можно было доставить и применить локально для нейтрализации зафиксированных уязвимостей. 7 н. и 8 з.п. ф-лы, 6 ил.

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

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

3. Способ по п.1, в котором средство защиты обеспечивает автоматическое решение времени исполнения.

4. Способ по п.1, в котором этапы построения и применения выполняются посредством использования таблицы уязвимостей/нейтрализации, которая связывает уязвимости и нейтрализующие их функции.

5. Способ по п.1, в котором этапы обнаружения и блокирования выполняются Web-браузером.

6. Считываемый компьютером носитель, на котором находятся считываемые компьютером инструкции, которыми при их исполнении реализуется способ по п.1.

7. Компьютерная система, в которой воплощен считываемый компьютером носитель по п.6.

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

9. Способ по п.8, в котором этап применения выполняют посредством использования таблицы уязвимостей/нейтрализации, которая связывает уязвимости и нейтрализующие их функции.

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

11. Способ по п.8, в котором упомянутые этапы обнаружения, запроса, сообщения, приема и применения выполняются Web-браузером.

12. Считываемый компьютером носитель, на котором находятся считываемые компьютером инструкции, которыми при их исполнении реализуется способ по п.8.

13. Компьютерная система, в которой воплощен считываемый компьютером носитель по п.12.

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

15. Способ по п.14, в котором этапы обнаружения и запроса выполняются Web-браузером.