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

• Не были установлены патчи, повышающие безопасность.

• Разрешения на доступ к файлам раздавались направо и налево.

• Были включены ненужные сетевые службы.

• И любой восьмилетний ребенок мог бы легко отгадать многие используемые пароли.

В этот момент появилась Шелли, чтобы сопроводить меня на беседу с сотрудниками. Сбор информации придется закончить позднее.

Техническая поддержка при отсутствии обучения и опыта

Сначала Шелли устроила мне встречу с системным администратором Эндрю Клейном. Эндрю только что поступил на работу в качестве сотрудника по технической поддержке систем сети S&B. Он имел опыт по обслуживанию больших компьютеров и начал осваивать UNIX около года назад, так как считал, что мейнфреймы вымирают, как динозавры.

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

Я немного поговорила с Эндрю о риске, которому подвергаются как клиентские системы, так и системы S&B. Казалось, он очень удивлен тем, что риск, о котором я говорила, вообще возможен. Я настоятельно ему порекомендовала пройти обучение по вопросам безопасности, если он рассчитывает и дальше работать в качестве сотрудника технической поддержки сети такого типа.

Мое следующее интервью было с администратором группы обеспечения безопасности Джимом Барнсом. Джим принес мне копии отчетов по аудитам безопасности, которые охватывали и систему DBS. Просмотрев их, я увидела, что он проверил некоторые важные системные настройки, но не все из них. В его отчетах было указано на избыточность разрешений доступа к файлам и ненужные сетевые службы, но он никогда не проверял установку патчей, повышающих безопасность, и не пытался взламывать пароли пользователей. И конечно, он не ответил на вопрос, вполне подходящий для телевикторины $64 000 Question: «Почему DBS 10 была подключена к двум сетям без какой-либо защиты брандмауэром?»

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

Разумеется, Джим не имел ни малейшего представления, как правильно проводить аудит. Требовать от кого-либо провести аудит группы систем без выработанного подхода или соответствующего обучения глупо и жестоко по отношению к этому сотруднику. Это похоже на то, как если бы ваш механик из автосервиса попросил вас припарковать машину на железнодорожных путях тогда, как вы оба знали бы, что у машины неисправен стартер. «Не беспокойтесь, — говорит он вам. — Если машина не будет заводиться, когда покажется поезд, то позвоните мне». Это не тот уровень риска, с которым бы компании могли мириться в своих сетях.

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

Дни 3-й и 4-й: Понимает ли проблему руководство?

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

Теперь мне нужно было потратить некоторое время на объяснение рисков и проблем руководству. Риск, который представляют такие виды конфигураций, труден для понимания.

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

Я покинула компанию, оставив после себя почти бесцветные лица руководителей S&B Systems. Теперь мяч был на их половине площадки, и они должны были решать проблемы сами.

Резюме: Аутсорсинговые системы должны быть защищены

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

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

Мы пойдем другой дорогой…

Удача S&B Systems и Express Times заключалась в том, что я обнаружила представляющее риск клиентское соединение. Разумеется, такое подключение не должно было быть сделано.

Вот что S&B следовало сделать, чтобы избежать проблем.

Проводить оценку безопасности

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

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

Проводить ее правильно

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

Проводить ее регулярно

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

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

Решать обнаруженные вами проблемы

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

Риск сам по себе со временем не исчезнет. Напротив, он использует такую передышку для того, чтобы вырасти в размерах и сделаться более сложным. Если вы откладываете решение проблемы безопасности потому, что у вас нет средств в этом квартале, то вы будете платить гораздо больше в более поздний срок. Представьте себе затраты S&B Systems в том случае, если хакер нащупает обнаруженное мной незащищенное место и перекроет сбыт всей их продукции.

Не использовать ПОДХОД «ПЛЫВИ ИЛИ ТОНИ»

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