-->

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

На нашем литературном портале можно бесплатно читать книгу IT-безопасность: стоит ли рисковать корпорацией?, Маккарти Линда-- . Жанр: Прочая компьютерная литература. Онлайн библиотека дает возможность прочитать весь текст и даже без регистрации и СМС подтверждения на нашем литературном портале bazaknig.info.
IT-безопасность: стоит ли рисковать корпорацией?
Название: IT-безопасность: стоит ли рисковать корпорацией?
Дата добавления: 16 январь 2020
Количество просмотров: 447
Читать онлайн

IT-безопасность: стоит ли рисковать корпорацией? читать книгу онлайн

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

Информационные технологии все глубже проникают в нашу жизнь, Не говоря о фирмах, непосредственно занятых разработками или внедрением ИТ, без них уже не могут обойтись банки, крупные торговые фирмы, госпитали, музеи… И этот список легко продолжить. И все чаще объектом грабителей, террористов или просто вандалов становятся информационные системы и сети и хранимая в них информация. Как убедиться, что ваша информация надежно защищена? Что злоумышленник или просто резвящийся тинэйджер, украв или уничтожив данные в вашей сети, не разрушит и вашу личную судьбу, и судьбу всей компании? Этим вопросам и посвящена книга, которую вы держите в руках. Увы, технические проблемы безопасности не всегда очевидны для тех, кто принимает решения о выделении средств и проведении необходимых мероприятий. Но в книге вы и не найдете технических деталей, необходимых системным администраторам и специалистам по безопасности. Автор разбирает конкретные достаточно типичные ситуации, с которыми она сталкивалась как аудитор безопасности, и приводит простые советы, как убедиться в том, что в вашей компании такое невозможно.

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

Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала

1 ... 15 16 17 18 19 20 21 22 23 ... 67 ВПЕРЕД
Перейти на страницу:

День 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). В некоторых компаниях выборочный аудит проводится для выяснения уровня риска. При его проведении выбирается репрезентативная группа наиболее важных систем. Если аудит показывает, что эти системы подвержены риску, то есть вероятность риска и для остальных систем. Это — ресурсосберегающий подход в тестировании безопасности. Хотя он рангом ниже, чем полный аудит, но определенно лучше простого расчета на удачу (последнюю стратегию безопасности используют гораздо больше компаний, чем вы думаете).

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

Аудит, день 1-й: Схемы сети говорят о многом

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

У JFC была отличная схема сети. Глядя на нее, я заметила, что один из серверов базы данных, подключенных к интранет JFC, был также подключен к какой-то другой безымянной сети. Куда шла эта другая сеть? Очевидно, она куда-то уходила, но из схемы было неясно — куда. Одна линия сети, выходящая из сервера, повисала в воздухе и была проведена в том же направлении, что и брандмауэр компании. Из общего вида схемы можно было предположить, что этот сервер был подключен прямо к Интернету.

Подключение сервера базы данных к Интернету без настроек безопасности или без брандмауэра перед сервером выглядело нелепым. Этого никто бы никогда не сделал! Или все-таки сделал?

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

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

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

1 ... 15 16 17 18 19 20 21 22 23 ... 67 ВПЕРЕД
Перейти на страницу:
Комментариев (0)
название