IT-безопасность: стоит ли рисковать корпорацией? - Линда Маккарти

День 3-й: Защита взломана снова

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

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

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

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

Дни с 4-й по 7-й: Эскалация инцидента

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

Но хакер уже не появлялся. Руководитель внутреннего аудита продолжал сомневаться, что главной причиной произошедшего был хакер. Достаточно ли было удаления того из системы, чтобы он отказался от дальнейших атак? Может быть, это Майк сам занимался взломом ради забавы и затих, когда осознал, что все ополчились против него?

День 8-й: Слишком поздно собирать улики

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

День 9-й: Кто был этим плохим парнем?

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

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

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

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

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

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

Резюме: Атаки изнутри

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

И хотя мы никогда не узнаем, прав Дэйв или нет, обвиняя Майка, все же он правильно думал, что хакеры могут прийти в сеть изнутри так же, как и снаружи. Как ясно видно на рисунке 1.1, внутренние хакеры представляют собой серьезную угрозу. Но одно дело знать, что внутренние хакеры являются угрозой, и совсем другое — делать с этим что-то. Для защиты ваших данных нужны политика безопасности, процедуры и обучение. Для многих руководителей идея защиты информации от своих же сотрудников выглядит нелепой. Им следовало бы взглянуть на единицы и нули, составляющие эту информацию, как на реальные деньги. У банков не возникает сомнений о надлежащем контроле над денежными хранилищами. Например, никто не оставит сейф широко открытым, так чтобы любой работник банка или зашедший посетитель мог забраться в него и взять деньги. Когда информация будет считаться столь же ценной, как и деньги, контроль над ее безопасностью станет требованием, а не поводом к раздумьям.

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

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