Промахи CISO: Название подразделения

Ну как можно быть начальником и не имеет своего подразделения? А бывает ли подразделение без названия? А название, штука серьезная, потому как "как корабль назовете, так корабль поплывет"(с)...

Мой доклад на UISGCON10

Вчерашний день прошел интересно, но быстро. Долгожданная Конференция по Информационной Безопасности UISGCON10 состоялась.

Политика vs. Политики

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

И вот вчера у вас не было Политики ИБ, а сегодня она есть. Вы стали более защищенным?

Размышления к Размышлениям

Читал много разных постов разных авторов о использовании «планшетов» в корпоративной среде особенно в контексте проблем ИБ, но сегодня после прочтения поста-размышления Владимира  Безмалого (http://bezmaly.wordpress.com/2012/02/21/tablet-2/) о роли и месте «планшетов» в нашей жизни, пришла в голову шальная мысль:

«Использование «планшетов» – это не ослабление системы безопасности, а метод ее укрепления»

В поисках взаимопонимания: ИБ vs ИТ-безопасности

На этой неделе столкнулся в разных источниках на подчеркнутое разделение и противопоставление  ИТ-безопасности и Информационной Безопасности (ИБ), мне казалось, что это деление уже кануло в Лету, а тут снова и из уст авторитетных людей… 

Я воспринимаю такое деление, как  источник снижения уровня защищенности, так как оно вносит дезориентацию в систему управления Предприятием, плохо отражается на корпоративной культуре, приводит к неэффективному   финансированию и внедрению средств управления ИБ.

Пример из практики:  поддержкой геораспрделенной кластерной системы, на которой «крутится» корпоративная ERP-система,  занимаются подчиненные CIO, а вот «выдачей» Check Point GO (в прошлом Abra) для удаленного доступа, к этой системе, занимаются  подчиненные CISO.  Так что, данный пример нужно воспринимать как иллюстрацию раздельного существования ИТ-безопасности и ИБ? Тогда получается, что «конфиденциальность» это ИБ, а «доступность» это ИТ-безопасность?

А пользователь, скажем «операционист Банка», который обеспечивает правильное использование средств управления ИБ, участвует в обработке инцидентов и принимает участие в оценке рисков ИБ он представитель какой безопасности? 

С другой стороны, мне обьясняют, что все очень просто: ИТ-безопасности занимается «безопасностью инструмента» и «поэтому ею может заниматься и "продвинутый" ИТ-шник. ИБ - это безопасность актива: здесь уже риски другие, и область шире, и методы иные.»(с)

Оно конечно все правильно, если бы не «маленькая» метаморфоза: мы не о человеке с его профессиональной подготовкой и обязанностями говорим, а о сфере человеческой деятельности – "направленной на обеспечение защищенного состояния объекта" (с)  

Не существует никакой ИТ-безопасности, есть единый бизнес-процесс обеспечивающий информационную безопасность предприятия, для подержания бизнес процесса в работоспособном состоянии необходимы ресурсы среди которых Инфраструктура и Люди. 

Люди, которые ввели термин «ИТ-безопасность», «безопасность информационных технологий» подсунули огромную свинью, породив anchoring, который стал причиной различных когнитивных искажений не только в головах потребителей услуг безопасности, но и в профессиональной среде… 

---

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

Укращение строптивых

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

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

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

Как укротить этих «железных коней», превратив их из потенциальных «врагов»  в «друзей и помощников»? Некоторые ответы можно подсмотреть в исследовании Gartner-a «Critical Capabilities for Mobile Device Management»

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

Так, например, назвав критическими, Gartner рекомендует анализировать 10 свойств продуктов управления:

1. Device Diversity: возможности работы с различными ОС и различными устройствами
2. Policy Enforcement: возможности настроек и управлением политиками безопасности (доступа, роуминга, фильтрации, приложений и т.д. и т.п)
3. Security and Compliance: наличие средств защиты корпоративных данных хранимых на устройстве (аутентификация, блокровка, шифрование и т.д. и т.п)
4. Containerization: возможности разделения сорпоративных данных от личных
5. Inventory Management: набор механизмов для предоставления, контроля и отслеживания устройства, подключенные к корпоративным приложениям и данным (и снова замечательный перечень для чеклиста)
6. Software Distribution: возможности по распространения приложений и обновлений программного обеспечения для мобильных пользователей (поддержка OTA …) 
7. Administration and Reporting: администрирование и отчетность (интерфейсы, группы, интеграция и т.д.)
8. IT Service Management: доступные уровни обслуживания (интеграция с Help desk, self-service, аlerting и т.п.)
9. Network Service Management: возможности для контроля и оптимизации расходов
10. Delivery Model: модель использования (например: on-premises, hosted, cloud) 

Документ, так же может быть полезен, в процессе разработки политик, процедур, контролей… Приятного прочтения ;-)