Черводинамика: причины и следствия

Александр Захарченко, http://az13.mail333.com/

«Так наука не делается. Так продаются товары.»
Майкл Крайтон. «Инопланетяне
как причина глобального потепления» [1]

Исследование особенностей распространения сетевых червей становится все более популярной темой, о чем свидетельствует рост количества не только специальных научных работ [2], но и магистерских диссертаций по черводинамике [3], [4]. Интерес этот вызван внезапным осознанием того крайне неприятного факта, что в результате вирусных эпидемий под контролем злоумышленников оказываются вычислительные ресурсы фантастической мощности. По здравому размышлению их можно использовать не только для организации канонических «гадостей», коими являются распределенные DoS-атаки или рассылки спама с «зомбированных» компьютеров, но и более рационально: например, для распределенных вычислений «изгоями», неспособными приобрести необходимое количество суперкомпьютеров.

Разработаны изощренные модели, которые позволяют учесть влияние нюансов топологии Сети на поведение злонамеренного кода [5], провести детальный анализ червей с комбинированными механизмами размножения, а также учесть человеческие факторы риска и даже оценить стоимость еще только надвигающейся напасти [6]. Без сомнения, вся эта сложность, которая по изящному определению Эдсгера Дейкстра (E.W. Dijkstra) лучше продается [7], существенно продвигает черводинамику как науку и способствует катастрофическому увеличению убойной силы перспективных разработок в области виртуальных вооружений, но к решению основной [8] проблемы – предотвращению компьютерных эпидемий – мы так и не приближаемся ни на йоту. Черви превращают Интернет в кишащую пираньями Амазонку [9]. Анализ сетевых ЧП последнего времени уносит последние крохи иллюзий относительно эффективности применяемых мер антивирусной обороны [10], [11], [12].

Математический аппарат для изучения динамики «обычных» биологических эпидемий был разработан достаточно давно (подробный обзор моделей распространения инфекционных заболеваний представлен в [13].) Биологический подход к моделированию вирусной проблемы [14] по общему признанию начался с работ J. O. Kephart и S. R. White из IBM [15] еще до изобретения WWW, однако модным это направление стало только в 2001 г. после шокировавших виртуальных стражей вспышек Code Red и Nimda [16]. Наибольший резонанс получили работы N. Weaver и его старших коллег. Ими введена концепция Warhol (или блицкриг) червей, а также исследованы различные концептуальные алгоритмы размножения самовоспроизводящихся кодов, кардинально повышающие эффективность их распространения [17], [18]. Вирусописатели не заставили себя долго уговаривать и 2003 г. дал старт небывалым по размаху и последствиям сетевым эпидемиям (Slammer, MSBlast, Sobig, MyDoom) [19], [20], [21].

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

Простая эпидемическая модель

Рассмотрим простую эпидемическую модель, в которой предполагается, что произвольный узел сети, состоящей из постоянного количества (N) компьютеров, может находиться только в двух состояниях: уязвимом (S) и инфицированном (I). S + I = N. Предположим, что на каждом инфицированном узле может существовать только одна копия червя, которая случайным образом выбирает в доступном адресном пространстве потенциальную жертву с опять-таки средней постоянной скоростью b в единицу времени (на поиск и заражение одной жертвы в среднем тратится 1/b секунд). В простейшем случае b определяется средней скоростью сканирования червем сети (V_s) и размером её адресного пространства (N_ip):

                                                (1)

(Согласно спецификации IP4 N_ip = 2³².)

Введя переменные i = I/N и s = S/N, получим уравнение динамики доли инфицированных узлов:

                                              (2)

Уравнение (2) имеет аналитическое решение. Предполагая, что в начальный момент времени t₀ = 0 доля инфицированных узлов составляет i₀, получим зависимость:

                                 (3)

из коей вытекает, что эпидемия в принятой модели полностью определяется двумя параметрами: скоростью размножения червя (b) и начальной зараженностью рассматриваемой сети (i₀).

(3) – это логистическая функция, которая только по форме отличается от результата [17], где постоянная интегрирования определена через константу по времени, а не через начальную зараженность, как в нашем случае. Из приведенных в [17] данных следует, что для Code Red v2 i₀ ~10^–11…10^–10, т.е. можно предполагать, что червь начинал атаку на Сеть с одного компьютера.

Динамика функции (3) характеризуется тремя четко различимыми этапами (Рис. 1).

Рис. 1. Развитие эпидемии в зависимости от начальной зараженности сети. Время представлено в единицах b ´ t (т.е. периодах размножения).

1-й этап – сравнительно медленное (но тем не менее экспоненциальное) нарастание зараженности до порогового уровня i_пор » 0,05 (красная горизонтальная прямая на Рис. 1). Скорость удвоения доли пораженных машин равна ln(2)/b.

2-й этап – взрывная фаза (outbreak) в диапазоне 0,05 < i < 0,95. Продолжительность её определяется только скоростью поиска b и приблизительно равна 5,89/b.

3-й этап – насыщение, i > 0,95 (черная горизонтальная прямая на Рис. 1). На этом участке при случайном сканировании адресного пространства зараженные узлы контактируют преимущественно друг с другом, поэтому уцелевшие узлы могут оставаться «чистыми» неопределенно продолжительное время.

Для достижения порога насыщения i=0,95 требуется время

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

Из полученных результатов вытекает, что:

1. Однородность Сети относительно определенной уязвимости представляет главную угрозу [22]. Практика показала, что даже черви, которые выбирают жертву случайным образом и, следовательно, являются самыми медленными [17], за считанные минуты способны поразить ключевые узлы Интернета и вывести из строя телекоммуникации на уровне отдельных стран [23]. Таким образом, любая структура деятельность которой критически зависит от доступа к Интернет (либо, наоборот, нормальное функционирование Интернет зависит от работоспособности таковой структуры), должна иметь резервные системы, построенные на программном обеспечении с различающимся кодом.

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

3. Механизм случайного выбора жертвы ограничивает снизу скорость распространения вирусов по сети. Значительно повысить её можно достаточно простыми средствами: подготовкой предварительного списка адресов для атаки, сканированием подсетей, выделением каждой копии червя отдельного фрагмента сетевого адресного пространства, поиском подходящих мишеней на зараженном компьютере и др. [17]. Если, к примеру, копия червя получает в наследство только непересекающуюся половину адресного пространства от «родителя», то из (1) следует, что это эквивалентно удвоению скорости заражения каждые 1/b секунд (Рис. 2).

Рис. 2. Ускорение эпидемии при выделении каждой копии червя своего непересекающегося фрагмента адресного пространства.

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

5. Системы раннего оповещения о развитии эпидемии окажутся сколько-нибудь эффективными только на участке i << i_пор и при крайне низких значениях b. Моделирование распространения Code Red и Slammer показало, что анализ обращений к несуществующим адресам позволяет определить признаки вирусной активности в сети при заражении 1–2 % уязвимых узлов [24]. Таким образом, предупреждение может быть получено максимум за 1,65/b секунд до достижения порога взрыва i_пор. Согласно данным [24] в случае Code Red это время составило бы не более 50 минут, а для Slammer не превысило бы 15–20 секунд. Очевидно, что в обоих случаях эпидемии можно было бы только зафиксировать, но не предотвратить.

5. Эффективность сетевых эпидемий можно значительно повысить, проводя скрытное предварительное заражение отдельных уязвимых узлов. Чем ближе i₀ к i_пор, тем разрушительнее могут оказаться последствия вирусной атаки (Рис. 1 ).

6. Увеличение адресного пространства N_ip понижает инфекционную способность червей со случайным выбором жертвы. IPv6 предполагает 2¹²⁸ адресов и это может несколько уменьшить темпы нарастания эпидемий, если адреса окажутся достаточно равномерно «размазаны» по всему пространству.

Анализ эпидемий Code Red v2 и Slammer на основе простой модели показал удовлетворительно совпадение с реально наблюдаемой динамикой эпидемий. Уже Code Red v2, чья инфицирующая способность оценивалась по различным данным от 0,7 до 1,8 компьютера в час менее чем за половину суток мог получить контроль над сотнями тысяч серверов. В то же время Slammer при скорости удвоения 8,5 секунд имел инфицирующую способность ~293 узлов в час и мог проникнуть на 90% уязвимых компьютеров всего лишь за 10 минут.

SIR модель и её варианты

Факторы, обеспечивающие затухание сетевых эпидемий, можно оценить на модели, в которой сетевые узлы существуют в трех состояниях: уязвимом (S), зараженном (I) и невосприимчивом (R). S + I + R = N. Для начала предположим, что узлы оказываются неуязвимыми только после излечения от инфекции. Вводя постоянную среднюю скорость «иммунизации» в единицу времени g, получаем систему уравнений:

                                               (4)

В этой модели существует пороговое условие для развития эпидемии. На участке возрастания i(t) производная di/dt должна быть больше 0. Поскольку s(t) непрерывно уменьшается за счет инфицированных машин, то получаем, что для начала эпидемии необходимо:

К сожалению, это условие выполняется очень легко, поскольку g определяется запаздывающей человеческой реакцией и необходимостью загрузки громоздких «заплат», а b – постоянно улучшающимися техническими характеристиками сети и «доброй волей» злоумышленника (он может вставить небольшую паузу в цикл размножения, чтобы не создавать катастрофического трафика и слегка понизить скорость инфицирования). Доля же уязвимых узлов обычно очень велика. Поэтому практически всегда b  на много порядков превосходит g. (К примеру, при моделировании эпидемии Code Red v2 в [25] согласие с реальными данными достигнуто при соотношении b/g  ~10⁶.)

В реальных условиях «иммунитет» посредством установки антивирусного ПО, межсетевых экранов и «заплат» приобретают не только инфицированные узлы (I), но и уязвимые (S). Предполагая, что средняя скорость иммунизации примерно одинакова для узлов обоих типов и равна (столь же малой) величине g, получим:

                                          (6)

и условие развития эпидемии (5) сохраняется.

r(t) = 1 – exp(–gt), откуда вытекает, что при достаточно большом времени любую эпидемию теоретически можно вроде бы и преодолеть. Проблема заключается только в том, что это время может оказаться неприемлемо большим.

Рис. 3. Динамика развития эпидемии в системе (6) при сравнительно малой начальной зараженности сети (10^–7). При b/g  < 15 вспышка не происходит.

Рис. 4. Динамика развития эпидемии в системе (6) при значительной начальной зараженности сети (10^–4). В этом случае пороговое значение b/g  < 9.

Как видно из Рис. 3 и 4 при «вакцинации» уязвимых узлов для заметной эпидемической вспышки необходимо, чтобы скорость инфицирования превышала скорость иммунизации на два порядка и более, для того, чтобы за время порядка 1/g  был пройден порог вспышки i_пор. Пока что это не слишком обременительное условие для вирусописателей. Возможным выходом оказалась бы автоматизация процессов устранения уязвимостей. Она могла бы стать существенным фактором ограничения эпидемических рисков, конечно при условии, что черви не смогут блокировать систему обновления ОС, а сами автоматически устанавливаемые «заплаты» не будут нарушать работоспособность иммунизируемой системы и создавать в ней новые опасные уязвимости.

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

Динамика системы с переменным числом узлов будет определяться скоростью прироста новых уязвимых (S) узлов a:

                                     (7)

Теперь условие развития эпидемии приобретает вид:

Рис. 5. Динамика развития эпидемии в системе (7).

Основной отличительной особенностью системы (7) оказывается наличие постоянного уровня, к которому со временем стремиться доля инфицированных компьютеров (Рис. 5 ). Это означает, что в реальных условиях от конкретного вируса в системе с приростом уязвимых узлов полностью избавиться нельзя даже при автоматической «вакцинации». Хотя бы и незначительное постоянное добавление новых уязвимых узлов создает «резервации», обеспечивающие повторные вспышки при благоприятных условиях.

Работа над ошибками

Моделирование и сравнение его результатов с фрагментарными данными наблюдений за развитием реальных эпидемий подталкивает к интуитивно понятному (если не сказать банальному) выводу: массовое распространение ПО, однородного относительно конкретной уязвимости, и крайне низкая скорость устранения обнаруженных «дыр» приводят к тому, что высокие технологии создают гораздо больше проблем, чем решают. Поспешное внедрение непроверенных новаций создало патовую ситуацию: с одной стороны невозможно безболезненно отказаться от паутины нововведений, которые стремительно изменяют среду обитания человека, с другой – опасность этих новшеств возрастает с каждым днем. К примеру, пока SCO пугала конгрессменов страшилками о виртуальных суперкомпьютерах на базе ПО с открытым кодом, которые якобы могут создать в «странах-изгоях» для исследования ядерного оружия [26], вирус MyDoom передал контроль над миллионами компьютеров с проприетарной ОС вообще неизвестно кому [27]. Остается только гадать, какие задачи могут решаться под прикрытием такого виртуального терроризма.

Монокультура ПО стала результатом жесточайшей конкурентной борьбы между родоначальниками эры персональных компьютеров. Бои без каких-либо правил, перенесенные из большого бизнеса в область ПО, которое с момента зарождения десятилетиями неспешно развивалось в академической «тиши», не оставили от имен многих отцов-основателей даже торговых марок. Чисто теоретически можно конечно допустить, что после захвата господствующих экономических высот, победители собирались вернуться к отброшенным из-за дороговизны проблемам безопасности и предложить более надежные продукты. Так Microsoft уже не первый год проводит кампанию за отказ от линейки ОС Win95/98/Me и постоянно предупреждает о прекращении её поддержки. Однако, никто не учел, что сущности в виртуальном мире не изнашиваются и если потребителя удовлетворяет уже имеющиеся ПО, то заставить его платить за новые «рюшечки» не так-то просто. А если этих потребителей многие миллионы, то монстру ПО приходится уступать их требованиям и даже с жутким скрипом соглашаться на исправление древних уязвимостей [28].

На сегодняшний день словосочетание «качественное ПО» выглядит откровенным оксимороном, чему значительно поспособствовало нелегальное обнародование части исходных кодов Windows [29]. Очевидно, что если злонаправленный код можно пристегнуть даже к картинкам разного формата [30], [31], то ожидать доверительного компьютинга придется бесконечно долго. Все это свидетельство глубокого кризиса в разработке ПО. Продвинутый инструментарий для разработки и отладки формирует иллюзию легкости создания сложнейших программ. Однако, дружественные настройки не могут устранить конструктивные просчеты языков программирования и архитектур ОС, многие из которых хорошо известны, но остаются по требованиям обратной совместимости. В результате даже в простеньких программах могут появляться ошибки, которые отправляют на свалку хитроумные «защитные» средства. Заметить и устранить их под силу только немногочисленным специалистам высшей квалификации, привлечение которых делает коммерческие проекты малоприбыльными.

Уже при разработке первых программ исследователи были неприятно поражены непомерными трудозатратами на отладку [32]. С тех пор программные ошибки вместе отказами аппаратуры так и остаются неотъемлемой частью компьютерных комплексов, а потому для военных приложений или атомной энергетики поливариантность оказывается единственным выходом. Однако, разработчики коммерческих приложений широкого потребления вынуждены минимизировать себестоимость проектов и укладываться в жесткие (хотя и регулярно проваливаемые) сроки. Следовательно ни о какой N-вариантности говорить не приходится. Рыночная гонка вынуждает искать компромисс между количеством отказов предлагаемой к продаже системы и продолжительностью её предварительной доводки [33].

Несмотря на многолетнее развитие методов тестирования ПО [34] отличным результатом считается наличие менее одной ошибки на 1000 строк исходного кода. Этот показатель нечасто достигается на практике и только после продолжительной эксплуатации продукта. Исследования показали, что 5–10 ошибок на 1000 строк не окажутся сногсшибательной новостью [35]. Более того, также выявлено, что в результате непредусмотренных побочных эффектов на каждые устраненные семь ошибок появляется одна столь же серьезная [36].

Конечно, далеко не все программные огрехи оказываются «дырами», сквозь которые черви могут свободно скользить по Сети. Наверняка таких дыр крайне малое количество по сравнению с общим числом просчетов в широко распространенном ПО, но в абсолютном исчислении их более чем достаточно для  удовлетворения фантазий вирусописателей любой квалификации. Так SecurityLab.ru каждый день публикует информацию о десятке-другом уязвимостей, которые могут использоваться и для проникновения в ОС. Прогноз-2010 предсказывает обнаружение 100 тысяч таких «дыр» за один год [37].

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

Не меньшую проблему представляет и устранение обнаруженных «дыр». Червь Морриса показал, что «латание» системы остается второразрядной задачей даже в стенах разработчиков ОС, что актуально и по сей день.

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

Несмотря на давно обоснованные сомнения, остается непотопляемой идея о «добрых» червях-вирусах, которые по замыслу авторов должны уничтожать злонамеренные коды и доставлять на компьютеры «заплаты» и прочее полезное ПО. Если бы не примкнувший к этой партии первоопределитель понятия вирусов F. Cohen, то такую гипотезу можно было бы рассматривать как пережитки студенческого романтизма [38]. Конечно, анализ модели (6) дает надежду на то, что античервь, распространяющийся со скоростью на 2 порядка меньшей, чем у врага-конкурента, способен достаточно быстро остановить эпидемию (Рис. 3 и 4), да и выборочная «иммунизация» Сети после обнаружения уязвимости во всех отношениях кажется благом [39].

Однако, опыт контрчервя Welchia подтвердил, что «полезный» вирус – это всего лишь академическое заблуждение. Не вспоминая всуе ошибки реализации, нужно осознавать, также, что найти баланс между количеством «доброты» и степенью вмешательства во внутренние дела «иммунизируемых» систем вряд ли получится [40]. Даже черви с ограниченным сроком активности оказываются неуничтожимыми и продолжают замусоривать Интернет, поскольку в Сети обретается достаточное количество компьютеров с неправильно установленной датой (в т.ч. серверов).

Сегодня компьютерная безопасность – модная и очень прибыльная область деятельности . Не удивительно, что в массовом порядке появляются «волшебные» средства, якобы способные извести на корню зловредные коды из Всемирной Паутины [41], [42], [43]. К сожалению, опыт эвристических анализаторов и систем распознавания лиц, которые столь эффективны в лабораториях, сколь и бесполезны в реальной работе, не позволяет надеяться на достижение заявляемого результата в обозримом будущем. На деле же, охотники за сверхприбылями, имеющие весьма смутное представление о множестве нетривиальных уязвимостей ПО [44], способны только безнадежно дискредитировать саму идею безопасных ОС.

[1] http://www.computerra.ru/compunity/femida/31986/

[2] The Workshop on Rapid Malcode (WORM), October 27, 2003, The Wyndham City Center Washington DC, USA. (http://pisa.ucsd.edu/worm03/)

[3] Jasmin Leveille «Epidemic Spreading in Technological Networks» (http://www.hpl.hp.com/techreports/2002/HPL-2002-287.pdf)

[4] C. G. Senthilkumar «Worms: How to stop them?» (http://wwwcsif.cs.ucdavis.edu/~cheetanc/worms/proposal.ps)

[5] M. Garetto, W. Gong, D. Towsley «Modeling Malware Spreading Dynamics» IEEE INFOCOM 2003 (http://www.ieee-infocom.org/2003/papers/46_01.PDF)

[6] M. M. Williamson and J. Leveille «An epidemiological model of virus spread and cleanup» HPL-2003-39 (http://www.hpl.hp.com/techreports/2003/HPL-2003-39.pdf)

[7] E.W. Dijkstra «On the nature of computing science» (EWD896) (перевод на русский язык http://club.shelek.com/viewart.php?id=146)

[8] S.R. White «Open Problems in Computer Virus Research» Virus Bulletin Conference, Oct 22, 1998, Munich Germany (http://www.research.ibm.com/antivirus/SciPapers/White/Problems
/Open%20Problems%20in%20Computer%20Virus%20Research.pdf)

[9] А. Красоткин «WWW – дикий, дикий, дикий Интернет» (http://www.computerra.ru/hitech/tech/31379/)

[10] John Leyden «The trouble with anti-virus» (http://www.theregister.co.uk/content/56/32680.html)

[11] Duncan Graham-Rowe «Computer antivirus strategies in crisis» (http://www.newscientist.com/news/news.jsp?id=ns99994119)

[12] А. А. Захарченко «Бой с тенью: компьютерные вирусы и причины сетевого хаоса» Защита информации. Конфидент, 2003, № 6, с. 49–52.

[13] H. W. Hethcote «The Mathematics of Infectious Diseases» SIAM Review Vol. 42, No. 4, pp. 599–653 (http://www.math.rutgers.edu/~leenheer/hethcote.pdf)

[14] M. M. Williamson «Biologically Inspired Approaches to Computer Security» HPL-2002-131 (http://www.hpl.hp.com/techreports/2002/HPL-2002-131.pdf)

[15] J. O. Kephart and S. R. White «Directed-Graph Epidemiological Models of Computer Viruses» Proceedings of the 1991 IEEE Computer Society Symposium on Research in Security and Privacy; Oakland, California, May 20-22, 1991; pp. 343-359. (http://www.research.ibm.com/antivirus/SciPapers/Kephart
/VIRIEEE/virieee.gopher.html)

[16] C.C. Zou, W. Gong and D. Towsley. «Code Red Worm Propagation Modeling and Analysis» In 9th ACM Symposium on Computer and Communication Security, pages 138-147, Washington DC, 2002. (http://tennis.ecs.umass.edu/~czou/research/codered.pdf)

[17] S. Staniford, V. Paxson and N. Weaver. «How to Own the Internet in Your Spare Time» 11th Usenix Security Symposium, San Francisco, August, 2002. (http://www.icir.org/vern/papers/cdc-usenix-sec02/)

[18] N. Weaver. «Warhol Worms: The Potential for Very Fast Internet Plagues» (http://www.cs.berkeley.edu/~nweaver/warhol.html)

[19] А. Захарченко «Черводинамика» (http://az13.mail333.com/3/worm1.htm)

[20] А. Захарченко «Вирусы и энергосистемы» (http://www.inauka.ru/computer/article35855)

[21] Sh. Gaudin «2003 'Worst Year Ever' for Viruses, Worms» (http://www.esecurityplanet.com/trends/article.php/3292461)

[22] Р. Лемос «США финансируют исследование в области ИТ-монокультур» (http://zdnet.ru/?ID=309987)

[23] «Slammed!» Wired magazine, 11-07-2003 (http://www.wired.com/wired/archive/11.07/slammer_pr.html)

[24] C.C. Zou, L. Gao, W. Gong, D. Towsley «Monitoring and Early Warning for Internet Worms» CCS’03, October 27–30, 2003, Washington, DC, USA. (http://tennis.ecs.umass.edu/~czou/research/monitoringEarlyWarning.pdf)

[25] Z. Chen, L. Gao, K. Kwiat «Modeling the Spread of Active Worms» IEEE INFOCOM 2003
(http://www.ieee-infocom.org/2003/papers/46_03.PDF)

[26] «SCO to Congress: Linux hurts the U.S.» ()

[27] Р. Лемос «MyDoom заставил задуматься о будущем антивирусного ПО» (http://zdnet.ru/?ID=313230)

[28] «План поддержки Windows говорит о трудностях Microsoft» (http://zdnet.ru/?ID=313154)

[29] «Утечка “исходника” Windows: 10 последствий» (http://www.cnews.ru/newcom/index.shtml?2004/02/16/155213)

[30] «Первая уязвимость, обнаруженная при исследовании исходного кода Windows» (http://www.securitylab.ru/42843.html)

[31] http://www.securitylab.ru/43090.html

[32] D. Wittenberg «On Unverifiable “Facts”» Brandeis Graduate Journal, 2003, v. 1 (1) (http://www.brandeis.edu/gradjournal)

[33] Les Hatton «Repetitive failure, feedback and the lost art of diagnosis» Journal of Systems and Software, (10) , 1999 (http://www.leshatton.org/JSS_1099.html)

[34] G. Myers «The Art of Software Testing» 1979

[35] L. Hatton «The T-experiments: Errors in Scientific Software» IEEE Computational Science and Engineering, 1997, 4(2), p. 27-38 (http://www.leshatton.org/IEEE_CSE_297.html)

[36] Les Hatton «Some notes on software failure» (http://www.leshatton.org/RS_1001.html)

[37] S. Berinato «The future of security» (http://www.computerworld.com/securitytopics/security
/story/0,10801,88646,00.html)

[38] G. Moorer «The Case for Beneficial Computer Viruses and Worms» (http://csrc.nist.gov/nissc/2000/proceedings/papers/601.pdf)

[39] C. Wang, J. Knight and M. Elder «On Computer Viral Infection and the Effect of Immunization» (http://www.cs.virginia.edu/~techrep/CS-99-32.pdf)

[40] А. Захарченко «Червивые баталии» (http://az13.mail333.com/3/worm3.htm)

[41] «He’s confident system can stop any virus» (http://www.suntimes.com/output/tech/cst-fin-lundy22w.html)

[42] «С хакерами будут бороться с помощью скриптов-мутантов» (http://www.securitylab.ru/42420.html)

[43] «TruSecure announces early-warning system» (http://www.computerworld.com/securitytopics/security
/story/0,10801,89424,00.html)

[44] Крис Касперски «Неизвестная уязвимость функции printf» (http://www.citforum.ru/security/articles/printf/)