Линда Маккарти - IT-безопасность: стоит ли рисковать корпорацией? Страница 17
- Категория: Компьютеры и Интернет / Прочая околокомпьтерная литература
- Автор: Линда Маккарти
- Год выпуска: -
- ISBN: -
- Издательство: -
- Страниц: 60
- Добавлено: 2019-05-28 14:46:36
Линда Маккарти - IT-безопасность: стоит ли рисковать корпорацией? краткое содержание
Прочтите описание перед тем, как прочитать онлайн книгу «Линда Маккарти - IT-безопасность: стоит ли рисковать корпорацией?» бесплатно полную версию:Информационные технологии все глубже проникают в нашу жизнь, Не говоря о фирмах, непосредственно занятых разработками или внедрением ИТ, без них уже не могут обойтись банки, крупные торговые фирмы, госпитали, музеи… И этот список легко продолжить. И все чаще объектом грабителей, террористов или просто вандалов становятся информационные системы и сети и хранимая в них информация. Как убедиться, что ваша информация надежно защищена? Что злоумышленник или просто резвящийся тинэйджер, украв или уничтожив данные в вашей сети, не разрушит и вашу личную судьбу, и судьбу всей компании? Этим вопросам и посвящена книга, которую вы держите в руках. Увы, технические проблемы безопасности не всегда очевидны для тех, кто принимает решения о выделении средств и проведении необходимых мероприятий. Но в книге вы и не найдете технических деталей, необходимых системным администраторам и специалистам по безопасности. Автор разбирает конкретные достаточно типичные ситуации, с которыми она сталкивалась как аудитор безопасности, и приводит простые советы, как убедиться в том, что в вашей компании такое невозможно.Книга даст массу полезных советов для руководителей верхнего уровня и специалистов, отвечающих за информационную безопасность компаний.
Линда Маккарти - IT-безопасность: стоит ли рисковать корпорацией? читать онлайн бесплатно
Сетевой доступ
Обнаружение играет очень важную роль в любой архитектуре безопасности. Рано или поздно противник захочет скомпрометировать вашу организацию, и на его стороне будут время и ресурсы. Для эффективного обнаружения большую важность имеют уровни защиты. Программы-датчики обнаружения вторжения, honeypots[18] и системные журналы играют ключевую роль в обнаружении.
Лэнс Спишнер, старший специалист по архитектуре безопасности в Sun Microsystems и основатель Honeynet ProjectВы являетесь генеральным директором очень молодой фармацевтической компании. Вы стоите у окна в вашем просторном кабинете и наслаждаетесь ростом цен на ваши акции. Сегодня за ваши акции давали около 100 000 долларов. Но в следующем году, когда ваше лекарство со сверхсекретной формулой завоюет рынок, вы ожидаете, что стоимость вашей компании поднимется до 5 миллионов долларов. Разве жизнь не прекрасна?
Но рано радуетесь. Как только вы переносите свой взгляд на вашу электронную почту, то замечаете, что менеджер группы безопасности прислал сигнал тревоги:
«УВЕДОМЛЕНИЕ О ВТОРЖЕНИИ. ВТОРЖЕНИЕ ХАКЕРА В СЕТЬ НОВЕЙШИХ ИССЛЕДОВАНИЙ».
По телефону вы быстро узнаете, что хакер проник почти незамеченным в сеть. Ваши специалисты выяснили, что он вошел через внешнее соединение, но никто не может определить, какую точку входа в сеть он использовал. Ваша сеть растет так же быстро, как и ваша компания, и никто не знает, сколько внешних входов в нее имеется. Ваш системный администратор может знать, сколько подключений к Интернету у вас есть. (В прошлом году у вас было одно подключение. В этом году их три.) Но никто не знает, сколько модемов установлено.
Печально, но такое незнание широко распространено. Лишь несколько лет назад «удаленный доступ» для обычной компании представлял собой несколько модемов и, может быть, одно подключение к Интернету. Сегодня та же самая компания может иметь десятки подключений к Интернету и сотни модемных подключений к внешнему миру.
Каждый день в офисах и лабораториях создаются новые подключения, и сотрудники компаний подключаются из своего дома. Клиентам нужен доступ в реальном времени, и они также подключены к вашей сети. В стремлении подключиться, иногда компании теряют способность контролировать внешние соединения. Результатом становится размытость границ между Интернетом, интранет и экстранет. При этом трудно или почти невозможно сказать, где начинается и где кончается ваша сеть.
Подключение к внешнему миру похоже на снежный буран. Он может начаться с отдельных порывов ветра, а затем быстро превращается в плотную снежную завесу, через которую вы не можете увидеть своих ног. Если вы не сможете контролировать внешние подключения, то вы споткнетесь или упадете лицом в снег — запросто. Теперь посмотрим…
Соединение с партнерами
Компания JFC Farmaceutical захотела предоставить доступ к своей информации одному из своих клиентов для ускорения совместного исследовательского проекта. Клиенту, компании McConnell Drugs, был нужен доступ к информации, хранящейся на сервере базы данных (Drug10). Технической стороной подключения клиента занимался системный администратор Дэйв Ферлонг.
Так как Дэйв раньше никогда не работал над проектом такого масштаба, то он начал смотреть документацию. Он обнаружил, что у JFC нет утвержденной архитектуры или политики по подключению клиентов к ее интранет. Поэтому Дэйв попросил совета у эксперта компании по брандмауэрам Фреда Джонсона. Вместе Фред и Дэйв выработали свой план. Они подключили сервер базы данных к Интернету для того, чтобы сотрудники McConnell Drugs имели доступ к информации. К сожалению, они подключили сервер базы данных напрямую к Интернету, не поставив впереди него брандмауэр для его защиты и не проведя настроек безопасности на сервере базы данных. Такая конфигурация оставила дверь к сети JFC широко открытой. Было только вопросом времени, чтобы в нее «зашел» хакер. Это как раз и случилось — хакер зашел прямо в дверь.
Как смогли администратор по брандмауэрам и системный администратор сделать такую серьезную ошибку? Кто дал им полномочия на принятие такого решения?
Пугает то, что такие вещи могут происходить. Когда компании теряют контроль над своими внешними подключениями и границы сети становятся «размытыми», то одна ошибка может разрушить будущее целой компании. Это чуть-чуть не случилось с JFC.
День 1-й: Архитектура безопасности
Фред и Дэйв вместе стали решать, как обеспечить работоспособный доступ. Так как у Фреда не было письменного документа о том, как подключать клиентов к сети JFC, то они вдвоем обсудили, как предоставить клиенту доступ к информации на Drug10 (сервере базы данных) и как это реализовать. В общем, Фред и Дэйв решили подключить Drug10 прямо к Интернету, чтобы McConnell Drugs смогла иметь доступ к серверу через Интернет. Они предположили, что настроят Drug10 для двух целей. Во-первых, Drug10 должен служить брандмауэром. Во-вторых, что более важно для Дэйва, компании McConnell Drugs должен обеспечиваться доступ к нужной информации.
Фред имел опыт в установке брандмауэров и подключении систем к Интернету и поэтому согласился помочь Дэйву.
Несколько недель спустя; Политика установки средств безопасности
Дэйв закончил свою часть работы первым. Время отклика Drug10 уже его не удовлетворяло. Поэтому перед подключением сервера к Интернету Дэйв установил в него более мощную систему и загрузил программное обеспечение. Так как у Дэйва не было каких-либо политик или процедур подключения систем к Интернету, то он просто проделал стандартную установку. У Дэйва не было идей по настройке безопасности систем, и он посчитал, что с этим справится Фред как специалист по брандмауэрам. Но у Фреда тоже не было идей.
На следующий день: Кто отвечает за безопасность
Фред подключил сервер базы данных к Интернету. Затем он предоставил доступ McConnell Drugs, чтобы они могли копировать файлы из Drug10 на систему в их сети. Фред вообще не думал о настройке безопасности системы, так как считал, что это работа Дэйва. Он полагал, раз все получили доступ к тому, что им надо, то его работа на этом закончена. Фред приступил к другой работе.
Еще через 29 дней: Хакер захватывает контроль
Было лишь вопросом времени, чтобы хакер обнаружил незащищенную сеть. Хакер взломал Drug 10 и захватил контроль над сервером базы данных. Он заменил важные системные файлы и оставил «черный ход» в системе для легкого доступа при следующем визите.
С этого момента сеть компании McConnell Drugs стала тоже подвергаться риску. Сотрудники компании брали информацию из системы, которая могла быть заражена вирусом, «червем», «троянским конем» или чем-то подобным. Даже если предположить, что хакер не был злоумышленником (довольно рискованное предположение), все равно результаты взлома могли быть опустошительными. Представьте себе, что вы обнаруживаете утром в понедельник всю информацию по персоналу компании опубликованной в Интернете, Представьте себе также возмущение своих сотрудников, которые думали, что сведения о них, их заработной плате и служебные характеристики являлись конфиденциальными. Теперь вспомните, в какой стране мы живем. Как всем известно, возмущенные американцы так просто не успокаиваются — они бегут к адвокату!
Кстати, о юристах. Хакер, прогулявшийся по интранет JFC, мог уничтожить всю их информацию и заразить или уничтожить информацию McConnell Drugs тоже. Теперь подумайте об ответственности. Конечная ответственность за уничтоженную информацию, очевидно, лежит на хакере. Но корпоративные судебные разбирательства очень часто основываются на поиске того, кто может заплатить, а не того, кто должен платить. Несомненно, JFC с ее финансовым положением представляла бы собой лучшую, более крупную мишень для юристов, чем бедный хакер, даже если хакер сразу был бы пойман.
+Один месяц: Незапланированное тестирование безопасности
Drug 10 оставался подключенным к Интернету целый месяц, пока не обнаружилось, что он скомпрометирован взломщиком. Это открытие было сделано совершенно случайно. Его сделала я, когда меня наняли провести профилактический аудит некоторых систем JFC. Без такого счастливого совпадения скомпрометированный сервер мог остаться незамеченным и незащищенным до бесконечности.
Мое участие в этом началось с момента, когда руководство JFC наняло меня для проведения тестирования безопасности нескольких серверов, размещенных в их компьютерном зале. Хотя скомпрометированная система (Drug10) являлась сервером данных, она не была среди систем, которые я должна была тестировать.
JFC наняла меня провести, как они сказали, «выборочный аудит» (spot audit). В некоторых компаниях выборочный аудит проводится для выяснения уровня риска. При его проведении выбирается репрезентативная группа наиболее важных систем. Если аудит показывает, что эти системы подвержены риску, то есть вероятность риска и для остальных систем. Это — ресурсосберегающий подход в тестировании безопасности. Хотя он рангом ниже, чем полный аудит, но определенно лучше простого расчета на удачу (последнюю стратегию безопасности используют гораздо больше компаний, чем вы думаете).
Жалоба
Напишите нам, и мы в срочном порядке примем меры.