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

Как всем известно, все задачи, которые решают специалисты служб (отделов, департаментов...) информационной безопасности (далее - ИБ) можно условно разделить на 3 группы: стратегические, тактические и операционные. Решение стратегических задач ведет нас к отдаленным целям и задает общий вектор развития. Решение тактических задач предполагает получение определенных выгод и преимуществ в среднесрочной перспективе. Ну, а операционные задачи просто надо выполнять...
В данном опусе я напомню про такие задачи ИБ-шника, которые необходимо регулярно выполнять, но тем не менее часто так случается, что их игнорируют сознательно ("сейчас не до того", "есть более важные задачи") и/или не осознанно ("забыл", "а я и не знал").

Итак, перечень задач и небольшие комментарии далее.

1.  Пересмотр ожиданий заинтересованных лиц.

Задача ИБ - по максимуму удовлетворять потребности и ожидания заинтересованных сторон, которыми являются:

·         руководство/владельцы компании;

·         руководители бизнес-подразделений;

·         руководство и сотрудники подразделений ИТ;

·         сотрудники подразделения ИБ;

·         рядовые сотрудники организации;

·         партнеры и поставщики;

·         ...

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

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

Что получаем в итоге: 

·         Актуализированный перечень заинтересованных сторон и их ожиданий (рабочий документ).

Периодичность:  1-2 раза в год

2. Пересмотр и анализ области защиты

Сотрудники подразделения ИБ должны четко понимать, что они защищают, какие есть критичные элементы в общей системе обработки информации. Это нужно для общего планирования задач ИБ и определения приоритетов работ. Собранная информация также пригодится если мы захотим реализовать какой-либо крупный и/или комплексный проект по ИБ, например: оценить риски ИБ, внедрить и сертифицировать СУИБ по ISO 27001, построить систему защиты ПДн и т.д.

Что получаем в итоге: 

·         Комплект рабочих или официальных (утвержденных) документов:

o    Схема орг.-штатной структуры организации;

o    Общая схема и описание сети (кол-во и типы рабочих станций и серверов, сегменты сети, мобильные устройства, средства защиты, точки выхода в сеть Интернет и другие сети);

o    Перечень и краткое описание основных АС;

o    Перечень критичных серверов и рабочих станций;

o    Общая физическая схема расположения подразделений организации;

o    Перечень используемых средств защиты и мониторинга;

o    Перечень системных администраторов (с указанием их зон ответственности);

o    Перечень лиц, допущенных в серверные помещения.

Периодичность: 2-4 раза в год

3. Анализ внешних нормативных документов 

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

Что получаем в итоге: 

·         Перечень внешних нормативных документов (рабочий документ)

Периодичность:  1-2 раза в год

4. Постановка целей и определение приоритетов

Необходимо регулярно ставить цели и приоритеты развития ИБ (я рекомендую выбирать 3-4 главные цели на год и квартал). Желательно согласовать их со своим руководством. Вроде бы задача простая, но обычно к ней относятся лишь формально или забывают о своих целях и приоритетах при росте числа операционных задач. А у Вас определены и документированы долгосрочные и краткосрочные цели?

Что получаем в итоге: 

·         Перечень целей подразделения ИБ (рабочий документ)

Рекомендуемая периодичность: в зависимости от горизонта планирования

5. Актуализация перечня внутренних документов, регламентирующих ИТ и ИБ

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

Что получаем в итоге: 

·         Перечень внутренних документов по ИТ и ИБ (рабочий документ)

·         План по доработке/пересмотру внутренних документов  (рабочий/официальный документ)

Периодичность: 1-2 раза в год

6. Проведение внутреннего аудита ИБ

Сотрудники подразделения ИБ должны не только определять/транслировать требования по защите информации (например, формально разрабатывая и внедряя политики и процедуры ИБ), но и проверять, а выполняются ли они. И в случае если они не выполняются, то либо все же "заставить" выполнять, либо пересмотреть их (например, некоторые процедуры и требования ИБ работают лишь на бумаге, и сотрудники их игнорируют, т.к. они бессмысленны и неудобны).

Что получаем в итоге: 

·         Отчет по результатам внутреннего аудита ИБ +  Краткий отчет руководству (официальный документ)

·         План по приведению в соответствие (официальные документы)

Периодичность: 1 раз в год

7. Сбор и анализ показателей ИБ

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

Желательно использовать одни и те же показатели на протяжении некоторого периода времени, так мы сможем отследить динамику изменений. Также рекомендую не выдумывать большого числа показателей, ориентируйтесь на 2 критерия: сколько времени требуется для получения данного показателя, как много информации о системе ИБ он дает (1-й старайтесь уменьшать, 2-е увеличивать).

Что получаем в итоге: 

·         Отчет по результатам анализа показателей  ИБ +  Краткий отчет руководству (официальные документы)

·         План по совершенствованию ИБ  (рабочий/официальный документы)

Периодичность: 1 раз в год

8. Сканирование и анализ уязвимостей ИТ-инфраструктуры

Проводить анализ уязвимостей ИТ-инфраструктуры важно для понимания реальной защищенности сети. Если у нас не хватает ресурсов (денег, времени, персонала, знаний, сканеров уязвимостей) для проведения таких работ самостоятельно, то рекомендуется приглашать внешних консультантов.  

Что получаем в итоге: 

·         Отчет по результатам анализа уязвимостей (рабочий/официальный документ)

·         План по устранению уязвимостей  (рабочий/официальный документы)

Рекомендуемая периодичность: 1-2 раза в год

9. Обучение и повышение осведомленности сотрудников организации

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

Что получаем в итоге: 

·         Материалы (информация) для ознакомления персонала

·         Журнал учета (при необходимости, официальный документы)

Периодичность: 2-12 раз в год

10. Обучение и повышение осведомленности сотрудников подразделения ИБ

Необходимо постоянно развивать свои навыки, получать новые актуальные знания в вопросах ИБ. 

Для этого мы можем:

·         посещать мероприятия по ИБ;

·         посещать мероприятия по смежным областям (ИТ, управление проектами, обеспечение физической безопасности;

·         учиться на курсах по ИБ и ИТ;

·         смотреть вебинары по ИБ и ИТ;

·         читать книги, статьи по ИБ и ИТ;

·         общаться в профессиональных группах по ИБ и ИТ;

·         готовиться и сдавать экзамены по ИБ и ИТ.

Что получаем в итоге: 

·         Перечень компетенций сотрудников подразделения ИБ (рабочий документ)

·         Перечень профессиональных сертификатов сотрудников подразделения ИБ  (рабочий документ)

·         Библиотека знаний (электроных и бумажных носителей)

·         Журнал учета посещения мероприятий и обучения по ИБ (при необходимости, рабочий документ)

Периодичность: 2-4 раза в год

Вроде все!

Читать далее ...

Ошибка подключения по RDP – TermDD Event ID 50

Вот как эту бяку сегодня поборол...

1. Открыть редактор реестра.

2. Найте и выделить раздел реестра

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TermService\Parameters

3. Удалить в этом разделе следующие параметры:

* Certificate

* X509 Certificate

* X509 Certificate ID

4. Закрыть редактор реестра и перезагрузить сервер.

P.$. Не забываем делать резервную копию!

Читать далее ...

Что не стоит виртуализировать

Виртуализация позволяет сэкономить немало денег, консолидировать ИТ-системы, более эффективно использовать ресурсы, а также улучшить возможности администрирования. Но не стоит забывать, что главная задача ИТ-отдела – поддержка бизнес-процессов. Что будете делать, если всё сетевое оборудование выйдет из строя? Тотальная виртуализация без анализа последствий – не самая лучшая идея. Не стоит класть все яйца в одну корзину. Есть вещи, которые не стоит виртуализировать.

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

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

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

Критически важные приложения без тестирования.  Не переводите жизненно необходимые для бизнеса системы и сервисы на виртуальную платформу без предварительного тестирования, даже если оно требует времени. Клонируйте исходную платформу (с помощью Symantec Ghost или Acronis True Image и др.), а затем провести тестирование, охватывающее все аспекты работы приложения или сервера. Лучше сделать это вечером, чтобы устранить возможные проблемы к началу рабочего дня. Всегда храните оригинал системы (просто отключите его, но не удаляйте), по крайней мере, до тех пор, пока не убедитесь, что ее виртуальный клон работает так, как вы ожидали.

ИТ-системы, от которых зависит физическая среда.  Есть две причины для отказа любой виртуальной машины – она сама и ее хостинг. Системы будут работать, только если исправны оба этих компонента. Если вы виртуализируете систему безопасности, которая открывает двери офиса при предъявлении электронного пропуска, ваши сотрудники могут запросто не попасть к себе в кабинет, если с виртуальной машиной что-то случится. Хорошо, если универсальный ключ всегда у вас. А что делать, если он закрыт внутри офиса?

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

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

ИТ-системы, для которых важна синхронизация времени.  VMware может синхронизировать время на виртуальной машине с хост-сервером ESX, да и саму ОС можно настроить на синхронизацию. Но что делать, если время на хост-сервере ESX выставлено неправильно? Эту проблему можно частично решить, используя на всех физических хост-серверах протокол NTP, обеспечивающий стандартизацию часов, но даже в этом случае могут возникать ошибки при сбое настроек или после обновления VMware ESX. Если для ИТ-системы критично правильное время, возможно, лучше ее не виртуализировать.

Компьютеры, которые отлично работают.  Стремясь к инфраструктуре виртуальных ПК (VDI), некоторые компании несколько переусердствуют с виртуализацией. Если у вас парк новых компьютеров (2-3-х летней давности), не тратьте время на виртуализацию и замену их тонкими клиентами. От этого не будет никакой пользы или экономии. Другое дело старые ПК, требующие замены, или ИТ-системы, которым не хватает быстродействия. В общем, если оборудование работает нормально, пусть работает и дальше.

ПО, которое устарело или не работает должным образом.  Часто физические устройства, трансформируют в виртуальную машину, чтобы их можно было восстановить и сохранить. В некоторых ситуациях это полезно, но в других вы неоправданно продляете жизнь устаревшему ПО. Например, у виртуального образа Windows XP, пережившей многочисленные обновления, удаление и установку программ, обязательно будет перегружать процессор и давать большое время отклика. Виртуальную систему нужно создавать с нуля. Лучше всего в этой ситуации создать новый образ ОС с необходимым ПО. То же самое касается унаследованных систем и приложений. Иногда, виртуализация - это единственная возможность продлить жизнь таким системам, но все же стоит внести такие системы в приоритетный список на замену и обновление.

Решающее значение для оптимального соотношения физических и виртуальных машин имеет хорошая документация, квалифицированные специалисты и четкое понимание вашей ИТ-среды. В любом случае вам придется закупать физическое оборудование, знать параметры своих серверов, объемы хранилищ данных, пропускную способность сети и другие детали. Виртуализация – вещь, конечно, хорошая, но если хост-сервер выйдет из строя, последствия могут быть плачевными.

Читать далее ...

Качества, необходимые современному руководителю

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

Вести команду к успеху.  
Традиционная модель руководства строилась на указаниях и контроле. Сотрудники должны были упорно работать как пчелки, чтобы их руководитель достиг успеха (что в принципе ныне и происходит). Современный же руководитель должен сделать все возможное, чтобы помочь добиться успеха своим сотрудникам. Это предполагает расширение полномочий сотрудников и привлечение их к управлению компанией. Сотрудники являются самым ценным активом любой компании. Если раньше руководитель говорил: «Прыгайте!», и сотрудники спрашивали: «Как высоко?», то сегодня вы должны прыгать вместе с сотрудниками.

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

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

Не бояться ошибок.  

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

Делиться информацией. 

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

В чем-то конечно спорно, может не совсем корректно, но на мой взгляд - лучше придерживаться данных правил, а еще лучше - добавить своих

Читать далее ...

Мобильная безопасность

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

Я задал себе теоретический вопрос: "Разрешено ли сотрудникам обрабатывать на мобильных устройствах конфиденциальную информацию компании?". Вариантов разумеется два - запрещаем и не запрещаем. Постараюсь изложить ответы на данные два варианта. Исходя из этого уже можно начинать планировать и реализовывать систему защиты.

1. Если запрещаю

Если ответ предполагает -  "Запрещено", то следует сосредоточить усилия именно на том, чтобы конфиденциальная информация не появилась на мобильных устройствах сотрудников. Для этого необходимо предпринять определенные шаги:

1. Разработать и довести до сведения сотрудников "Политику допустимого использования" (так называемую Acceptable Use Policy), в которой в явном (!) виде прописать требования по использованию мобильных устройств (корпоративных и личных) и удаленного доступа к корпоративным ресурсам и сервисам.
2. Обеспечить контроль и блокирование передачи конфиденциальной информации на устройства. По сути, это будет что-то типа контроля утечки информации за счет:

• передачи файлов по электронной почте; 
• выкладыванию файлов в сети Интернет;
• передачи данных напрямую на устройство при подключении;
• созданию устройством дополнительных сетей (например wifi) и передача данных по ним

3. Запретить и контролировать отсутствие на компьютерах запрещенного/не разрешенного программного обеспечения (различные "синхронизаторы" (iTunes, Activesync и пр.), облачные хранилища (iCloud, DropBox, GoogleDrive, Яндекс Диск, SkyDrive и пр.), средства удаленного доступа (TeamViewer, PC Remote Control и пр.), и другие, с помощью которых можно передать на мобильные устройства конфиденциальную информацию).

4. Пересмотреть подход к предоставлению удаленного доступа к корпоративным ресурсам и сервисам.

Достаточно малореалистичный вариант запретить проносить мобильные устройства на работу и контролировать этот запрет. А риск фото/видео/аудиозаписи рассматривать предпочтительнее отдельно и скорее принимается во внимание.

2. Если не запрещаю

Обращаю внимание на термины - "Не запрещено", а не "Разрешено". Разные вещи, не так ли? С чем это связано? Во многих компаниях на использование мобильных устройств сотрудниками смотрят "сквозь пальцы", в явном виде ничего не запрещая, но и не разрешая. При этом часто сотрудники имеют доступ к корпоративной электронной почте, календарю и списку контактов, а также могут обрабатывать конфиденциальные документы на своем гаджете. Оценка рисков такой обработки обычно не проводится. Чревато последствиями? Еще как.

Ну вот, если отвечаем "Не запрещено", то следует сосредоточить усилия на управлении рисками и инцидентами.

Первым делом необходимо понять область (scope), для этого следует четко определить:

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

После сбора первичной информации следует оценить возможные риски и еще раз ответить на вопрос "А все-таки, следует ли разрешить ли сотрудникам обрабатывать на мобильных устройствах конфиденциальную информацию компании?". Если и сейчас ответ утвердительный, то необходимо:

1. Разработать и довести до сведения сотрудников Политику допустимого использования (Acceptable Use Policy), в которой в явном виде прописать требования по использованию мобильных устройств (корпоративных и личных) и удаленного доступа к корпоративным ресурсам и сервисам.
2. Обучить (повысить осведомленность) пользователей базовым принципам безопасности мобильных устройств (например, "не оставлять без присмотра", "использовать пароли", "установить ПО для поиска/блокирования устройства и стирания информации", "решить с антивирусной защитой" и пр.).
3. C учетом оценки рисков выбрать и внедрить дополнительные средства защиты и управления мобильными устройствами. 

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

Читать далее ...