Комментарии 36
Строчка отсюда как никогда уместна:
Даже не знаю, что еще добавить.
При этом в России часто ставится знак равенства между информационной безопасностью и IT-безопасностью, что совсем не одно и то же. Например, хранение бумажных документов тоже входит в сферу ИБ, но не в сферу IT-безопасности.
Даже не знаю, что еще добавить.
Это возможно когда руководитель у подразделений ОИТ и ОИБ один. А в РФ в 90% ОИТ это отдельная структура, а ОИБ подчиняется заму по безопасности, который в ИБ — 0.
«Руководитель у подразделений ОИТ и ОИБ один» быть не должен категорически, как следует из лучших практик. Что либо, кроме конфликта интересов, в результате такого совмещения получить сложно.
Несложно найти современные отечественные нормативные документы в области ИБ, напрямую запрещающие такое совмещение.
Несложно найти современные отечественные нормативные документы в области ИБ, напрямую запрещающие такое совмещение.
Очень многие нормативные документы в области ИБ в РФ написаны через пень колоду. Считаю, что лучшая практика заключается в корректном и бесперебойном функционировании организации, а не в «разборках» в течение полу дня между ИТ и ИБ кто прав. И как раз конфликта интересов не будет, т.к никому утаивать ничего не придется и не получится: «серые» маршруты, открытый team viewer, соц сети, game-серверы, аськи и т.п.
Вместо повторения избитой истины о несовершенстве отечественных нормативных документов в области ИБ рекомендую обратить внимание на пункт 2.11.1 положения Банка России № 382-П, прямо запрещающий совмещение руководства ОИТ и ОИБ.
Проблема «разборок» между ОИТ и ОИБ разрешается очень просто: должны быть определены и закреплены полномочия и обязанности каждого из подразделений и их отдельных работников. После чего все просто делают свою работу по установленным правилам.
Предлагаю ещё раз поразмыслить над тем, насколько мотивированно и независимо работники ОИБ, находящиеся в подчинении у руководителя ОИТ, будут представлять факты выявленных нарушений установленных политик. Не удивлюсь, что «серые маршруты, открытый team viewer, соц сети, game-серверы, аськи и т.п.» покажутся им чем-то незначительным на фоне грядущего распределения годовых премий руководителем отдела.
Проблема «разборок» между ОИТ и ОИБ разрешается очень просто: должны быть определены и закреплены полномочия и обязанности каждого из подразделений и их отдельных работников. После чего все просто делают свою работу по установленным правилам.
Предлагаю ещё раз поразмыслить над тем, насколько мотивированно и независимо работники ОИБ, находящиеся в подчинении у руководителя ОИТ, будут представлять факты выявленных нарушений установленных политик. Не удивлюсь, что «серые маршруты, открытый team viewer, соц сети, game-серверы, аськи и т.п.» покажутся им чем-то незначительным на фоне грядущего распределения годовых премий руководителем отдела.
Я в течение определенного немалого времени был сотрудником большого банка в ОИБ. И СТО ИББС и дополнения к вопросам взаимодействия внутренних структур, поверьте, я читал и знаю, поэтому и написал о этом. Находясь внутри процессов, немного переосмысливаешь, то «положительное», что написано в регламентирующих документах. И проблема не разрешается так, как Вы ее описали: собрались, открыли положения и инструкции об отделах и готово. Изначально я имел ввиду что есть рук. ОИТ и ОИБ и оба они подчиняются одному вышестоящему руководителю — заму по направлению. Если в Вашей организации по другому, это просто отлично.
Любые подразделения банка так или иначе подчиняются одному органу — Правлению :) Тут как раз логично задать бывшему работнику банка вопрос: требование о том, что СВК должна быть подчинена непосредственно Правлению — тоже излишне и ведет к «разборкам»?
И проблема не разрешается так, как Вы ее описали: собрались, открыли положения и инструкции об отделах и готово.И что тому причина?
Как раз аудиторы находятся в непосредственном подчинении у самого управляющего. И они проверяют, как ИТ, так и ИБ (вообще-то всегда было одновременно). Но они к ИБ никакого отношения не имеют…
Проблема, как мне кажется 1)в отсутствии компетенции у руководителей отделов 2)боязни признать свои ошибки специалистами 3)непонимании того, что все в одной упряжке 4)незаинтересованности в работе (скинуть бы на кого-нибудь и найти отмазку) 5) псевдозанятость
Проблема, как мне кажется 1)в отсутствии компетенции у руководителей отделов 2)боязни признать свои ошибки специалистами 3)непонимании того, что все в одной упряжке 4)незаинтересованности в работе (скинуть бы на кого-нибудь и найти отмазку) 5) псевдозанятость
6) Отсутствие доверительных отношений между IT и IT Sec. Это — большая проблема. Причем от этого начинают страдать последние, и за это они мстят первым. Т.е. проекты по ИБ, в которых должно принимать участие IT, динамятся со страшной силой и всеми возможными способами, а IT оказывается со всех сторон зажато политиками и даже чихнуть не может без согласования. Я такое много раз наблюдал.
А вот если все дружат со всеми, то и проекты IT Sec идут как по маслу, и эти самые IT Sec могут упорно не замечать ну очень явные нарушения политик безопасности со стороны IT, которые ITшники сотню раз подряд нечаянно спалили (буква закона-то нарушается, но при этом угрозы безопасности нет, все это понимают) :)
В таком сценарии инструкции и положения нередко игнорируются в общих интересах.
А такого, чтобы IT занималось своим, а IT Sec — своим, и их интересы не сталкивались лбами — не бывает.
А вот если все дружат со всеми, то и проекты IT Sec идут как по маслу, и эти самые IT Sec могут упорно не замечать ну очень явные нарушения политик безопасности со стороны IT, которые ITшники сотню раз подряд нечаянно спалили (буква закона-то нарушается, но при этом угрозы безопасности нет, все это понимают) :)
В таком сценарии инструкции и положения нередко игнорируются в общих интересах.
А такого, чтобы IT занималось своим, а IT Sec — своим, и их интересы не сталкивались лбами — не бывает.
Я верно понял, что некомпетентность руководителей отделов, боязнь признать твои ошибки специалистами, непонимание общих целей, незаинтересованность в работе и псевдозанятость разом исчезают, если у ОИБ и ОИТ появляется общий куратор?
НЛО прилетело и опубликовало эту надпись здесь
У нас в организации у ГИБ (группа) находится в подчинении у руководителя ОИТ. Это жесть! Доходит до такого маразма, что сотрудник ГИБ должен пользователей в домен вбивать и настраивать политики.
НЛО прилетело и опубликовало эту надпись здесь
Я придерживаюсь мнения, что ИБшник всё таки должен иметь read-only доступ к сетевым устройствам (CP, Juniper, proxy etc), что бы быть в курсе правил, которые ИТшник создаёт. Не раз бывали грабли, когда «временное» правило становилось вечным, any-to-any вдруг страновилось allow и первым в списке или забывалось включить логирование.
Согласен как с одним из предложений. Но если политика написана безопасником, разве не он же будет лучше всего знать, как ее реализовать? И во время «щекотливой ситуации» будет только одно лицо, которое сможет или не сможет) ответить на вопросы. Пусть сетевиками буду настроены маршруты, Vlan, интерфейсы, ведь доступы можно разделить. Я считаю что правило 2 персон в ситуации наличия ОИТ и ОИБ только вредит.
Безопасник должен обладать довольно высокой компетентностью, чтобы самостоятельно написать политику сетевой безопасности. Как показывает практика, в примерно любой компании сетевики считают безопасников как раз некомпетентными и неспособными принимать правильные решения без подсказок.
Пару лет назад я столкнулся в Крылатском (там принимают мобильные лабы CCIE) с одним из безопасников, работающим на моего предыдущего работодателя. Он в итоге провалил Security, но как бы само посещение подобного мероприятия тоже о многом говорит — как минимум о том, что данный товарищ знает сетевую безопасность куда лучше информационных безопасников из моей текущей конторы. И все равно тамошние сетевики считают его некомпетентным :)
На самом деле, правильный безопасник всегда будет прислушиваться к мнению администратора конечной системы по любым связанным с безопасностью этой системы вопросам. Очевидно, что узкий специалист знает вопрос лучше широкопрофильного. Однако, не каждая компания может позволить себе толпу узких специалистов по ИБ, обычно это не требуется.
Что до «щекотливых ситуаций» — в щекотливой ситуации специалисты разных отделов собираются вместе и решают ее.
Пару лет назад я столкнулся в Крылатском (там принимают мобильные лабы CCIE) с одним из безопасников, работающим на моего предыдущего работодателя. Он в итоге провалил Security, но как бы само посещение подобного мероприятия тоже о многом говорит — как минимум о том, что данный товарищ знает сетевую безопасность куда лучше информационных безопасников из моей текущей конторы. И все равно тамошние сетевики считают его некомпетентным :)
На самом деле, правильный безопасник всегда будет прислушиваться к мнению администратора конечной системы по любым связанным с безопасностью этой системы вопросам. Очевидно, что узкий специалист знает вопрос лучше широкопрофильного. Однако, не каждая компания может позволить себе толпу узких специалистов по ИБ, обычно это не требуется.
Что до «щекотливых ситуаций» — в щекотливой ситуации специалисты разных отделов собираются вместе и решают ее.
А почему спец ИБ является широкопрофильным? В заметке я выделил те направления, которыми можно заниматься безопаснику, не всем сразу и одному. Так в принципе и делается в обособленных ОИБ: кто-то номенклатурой, другой сетью, следующий ключами и ЭЦП. Я как раз и имел ввиду дифференциацию направлений и функций. Да, есть конечная специфичная система — здесь вопросов 0, ее администратор — гуру, но по вопросам обще инфраструктурной схемы, только поверхностным аудитом, считаю не обойтись.
С моего курса выпустилось 35 человек, из них по специальности работает 4
Примерно такая же ситуация. Хотя, я должен тут заметить одно немаловажное НО: большинство людей при поступлении и в процессе обучения по специальности не особо интересовались специальностью. И даже обижались, что им требовалось изучать то, что им не нравилось и что они применять не будут. В итоге ситуация довольно стандартная. Как в том выражении: «Папа не старался, мама не хотела».
Т.е. да, есть проблема системы образования, есть проблема недостаточной заинтересованности фирм и в непонимании реальности ситуации. Об этом давно и долго говорят. Но есть проблема ещё одна: в самом нежелании специалистов работать по специальности. Причины того — это уж тема для отдельной статьи. Ибо у всех своя правда
в процессе обучения по специальности не особо интересовались специальностьюабсолютно согласен, с единственным НО, я почему-то уверен если бы преподавали с большим энтузиазмом, могло бы быть иначе. А вышло как написано здесь. Небольшой пример: я учился с 04 по 09, ФЗ №152 вышел в 06, ни слова о нем в течение 3 лет, зато потом каждый 2 диплом на защите был про ИСПДн разных классов… Ну еще конечно от рынка зависит, он очень слабый в сфере ИБ.
Чистая правда. Автору спасибо за поднятие этой несомненно актуальной темы. Сам по образованию ИБшник «вроде как». Ключевое слово тут все же «вроде как», но не об этом сейчас речь. У нас в принципе были толковые преподаватели, да они не всегда все давали, но как говорится если сильно захотеть… В общем всегда можно было подойти пообщаться, послушать какие-то истории из личного опыта. Еще курсе наверное на третьем, я уже понял насколько специфична данная профессия сама по себе, а у нас в стране особенно. Желания как-то сразу поубавилось поэтому работаю обычным админом, юниксовым правда по большей части, но образование безопасника вроде как в плюс, работодателям нравится, да и самому помогает зачастую взглянуть под другим углом. Насколько знаю про однокурсников, общаюсь лишь с малой частью из них, никто тоже не работает по специальности. Все в IT или около. В чем вообще проблематика с моей точки зрения. Я думаю не в преподавании явно, я думаю хватает умных ребят, которым эта тема интересна и которые и наши законы все знают и ГОСТы и даже, прости господи, PCI DSS. Проблема в том, что у нас не развит данный рынок. У нас вообще рынок не развит, дикий он. Компании реально не видят угрозы, не понимают зачем им это. Большинство управленцев твердолобые кретины. Еще часть просто быдло из 90-х. У нас много подобных проблем на самом деле, просто не все они поднимаются. Да что там, куда ни плюнь, везде все через одно место.
Как правильно заметил Сергей Гордейчик на одной из конференций по безопасности (Кажется, РусКрипто 2011 или 2012), каждый год на конференциях одни и те же лица, почти никого нового. Так что в этой сфере свежей крови мало (((
И вот у меня такая же ситуация: ищу на работу спецов по безопасности — не для бумажной работы. А более интеллектуальной, но всё никто не подходит. Студенты с кафедр по безопасности ни черта не знают… Даже аспирантка одной из кафедр безопасности имела весьма сомнительные познания в этой сфере
И вот у меня такая же ситуация: ищу на работу спецов по безопасности — не для бумажной работы. А более интеллектуальной, но всё никто не подходит. Студенты с кафедр по безопасности ни черта не знают… Даже аспирантка одной из кафедр безопасности имела весьма сомнительные познания в этой сфере
Мне кажется люди просто боятся идти в эту сферу, потому что знают, что получится именно так как описал автор поста. Лично я шел учиться представляя себе все немного по-другому, как более интересную работу, даже что-ли несколько романтизируя, а потом как понял, что надо хорошо разбираться в законодательстве, учить кучу ГОСТов, писать инструкции и что работа по большей части бумажная, то подумал, что мне интереснее практическая часть или архитектурная, а не описание и составление различного рода актов. Конечно последующая работа админом привила мне в некоторой степени любовь к «писанине», я тут имею ввиду всякого рода документирование, но все же это 10-20% процентов рабочего времени, что не так много. Если бы мне было это интересно, то я знал бы это на отлично и мог бы себя называть действительно ИБшником или может быть даже толковым, знающим или <еще какой-то эпитет> ИБшником, а так не пришей… ну вы поняли. :) Вот если бы все было наоборот, я бы сказал возьмите меня, а в данной ситуации боюсь, что окажусь ничуть не лучше тех самых ни черта не знающих студентов. :) Поэтому лишь могу сказать, что наверное есть целеустремленные люди, которым действительно интересна эта тема, хоть может их и мало. Думаю просто они вам не попадались. Поэтому желаю удачи в этом нелегком поиске. )
UPD: Имхо хороший безопасник не только хорошо знающий кучу теории, разбирающийся в математике и криптоалгоритмах человек, а еще и ценный мех а это еще и определенные личностные качества и образ мышления. Например, имхо, будет плюсом даже немного нездоровая паранойя. Хорошо развитая интуиция явно не будет лишней, даже скорее не интуиция а какое-то внутреннее чувство угрозы. Ну это когда знаете часа в 3 ночи, сидишь дома за компьютером, вспоминаешь о каком-то рабочем моменте и думаешь, а пойду-ка я загляну в логи. Заглядываешь а там опа. )
Кстати, вот как раз вспомнил одну историю интересную и поучительную. Часто у нас в компаниях как, админ на все руки мастер, т.е. вопросы по ИБ по идее тоже переходят в его компетенцию по причине отсутствия других специалистов хотя бы как-то с этим связанных. Так вот есть у нас допустим какие-то программисты на аутсорсе даже, их приложение казалось бы крутится на сервере, который в зоне ответственности админа, и соответственно код приложения и механизмы его работы вроде как бы тоже касаются админа (ну раз уж ИБ «повесили»), а нет оказывается. Оказывается это «они там сами разберутся», а потом у меня на сервере левые скрипты так брутфорсят и грузят проц, что SSH лагает. :)
Кстати, вот как раз вспомнил одну историю интересную и поучительную. Часто у нас в компаниях как, админ на все руки мастер, т.е. вопросы по ИБ по идее тоже переходят в его компетенцию по причине отсутствия других специалистов хотя бы как-то с этим связанных. Так вот есть у нас допустим какие-то программисты на аутсорсе даже, их приложение казалось бы крутится на сервере, который в зоне ответственности админа, и соответственно код приложения и механизмы его работы вроде как бы тоже касаются админа (ну раз уж ИБ «повесили»), а нет оказывается. Оказывается это «они там сами разберутся», а потом у меня на сервере левые скрипты так брутфорсят и грузят проц, что SSH лагает. :)
А зачем спецу по информационной безопасности (т.е. человеку, в идеале пишущему политику безопасности и администрирующему некоторые технические решения) знать математику и криптографию? По-моему, умения упорядочить список алгоритмов по степени защищенности и производительности более чем достаточно. Безопаснику ничем не поможет знание матана, стоящего за DH или AES.
Но безопасник, имеющий отношение к сети, должен к примеру понимать, как устроено как минимум большинство control plane протоколов, какие существуют способы их сломать и как защититься от атак. При этом он должен во всех случаях уметь смотреть на вопрос с позиции администратора, даже когда он таковым не является, так как очень легко перегнуть палку, вызвать своими политиками проблемы в работе транспорта (в том числе по причине того, что внесение изменений станет чрезмерно запутанным) и получить лучи поноса от администраторов.
Но безопасник, имеющий отношение к сети, должен к примеру понимать, как устроено как минимум большинство control plane протоколов, какие существуют способы их сломать и как защититься от атак. При этом он должен во всех случаях уметь смотреть на вопрос с позиции администратора, даже когда он таковым не является, так как очень легко перегнуть палку, вызвать своими политиками проблемы в работе транспорта (в том числе по причине того, что внесение изменений станет чрезмерно запутанным) и получить лучи поноса от администраторов.
Небольшое замечание: не стоит ограничивать компетенции специалиста по ИБ только операционной безопасностью и управлением политиками. Тот же CISSP CBK (https://www.isc2.org/cissp-domains/default.aspx) на порядок больше областей включает.
При проведении аудитов зачастую требуются знания, выходящие за пределы указанных выше компетенций «спеца по ИБ».
При проведении аудитов зачастую требуются знания, выходящие за пределы указанных выше компетенций «спеца по ИБ».
Те области как раз и сводятся к планированию и администрированию. Чуть выше я про то и писал.
Аудиторов не рассматриваем — они не относятся к ентерпрайзной безопасности.
Аудиторов не рассматриваем — они не относятся к ентерпрайзной безопасности.
Не нужно путать профессию и квалификацию с родом деятельности и ролью. Специалист по ИБ может быть задействован в управлении, оценке соответствия, проектировании, улучшении, обеспечении и так далее. И называться он будет менеджером, аудитором, инженером, архитектором, консультантом, инженером, специалистом и так далее.
Да, нет адекватного русскоязычного термина для специалиста, занимающегося Security Operations, но это не повод отождествлять его с понятием «специалист по ИБ».
К планированию (в оригинале — написание политик) и администрированию сводится далеко не все. Если не углубляться в частные примеры, которых есть у меня, мониторинг различного рода — это планирование, написание политик или администрирование?
Да, нет адекватного русскоязычного термина для специалиста, занимающегося Security Operations, но это не повод отождествлять его с понятием «специалист по ИБ».
К планированию (в оригинале — написание политик) и администрированию сводится далеко не все. Если не углубляться в частные примеры, которых есть у меня, мониторинг различного рода — это планирование, написание политик или администрирование?
Мониторинг стоит на стыке всех трех направлений. Это и планирование (прогнозирование угроз), и администрирование конкретных систем (которые, грубо говоря, собирают и анализируют валящуюся со всех сторон информацию), и написание политик (руками такую гору данных не обработать). Понятно, что планирование тут главенствует.
Я рад, ты молчаливо согласился с первыми двумя абзацами моего комментария.
Относительно же деятельности, которой занимается специалист по ИБ, мне кажется, что за деревьями (пронозирование угроз, администрирование конкретных систем) ты не видишь леса: любая деятельность может быть разбита на этапы планирования, реализации, мониторинга и принятия корректирующих действий (здравствуй, цикл Деминга!).
Но это не отменяет тот факт, что специалист по ИБ не только пишет политики, администрирует системы и прогнозирует угрозы. Придется углубиться в частные примеры: тестирование на проникновение, проверка актуальности плана обеспечения непрерывности, анализ процессов обработки конфиденциальной информации, обеспечение безопасности при взаимодействии с контрагентами — к чему будут относиться эти мероприятия? К написанию политик, администрированию систем или прогнозированию угроз?
Относительно же деятельности, которой занимается специалист по ИБ, мне кажется, что за деревьями (пронозирование угроз, администрирование конкретных систем) ты не видишь леса: любая деятельность может быть разбита на этапы планирования, реализации, мониторинга и принятия корректирующих действий (здравствуй, цикл Деминга!).
Но это не отменяет тот факт, что специалист по ИБ не только пишет политики, администрирует системы и прогнозирует угрозы. Придется углубиться в частные примеры: тестирование на проникновение, проверка актуальности плана обеспечения непрерывности, анализ процессов обработки конфиденциальной информации, обеспечение безопасности при взаимодействии с контрагентами — к чему будут относиться эти мероприятия? К написанию политик, администрированию систем или прогнозированию угроз?
любая деятельность может быть разбита на этапы планирования, реализации, мониторинга и принятия корректирующих действий (здравствуй, цикл Деминга!).
С натяжкой, очень большой… И это слишком большое обобщение. Постом выше я писал, что конкретно имею в виду.
Придется углубиться в частные примеры
Ну что же, я очень рад, что вам известны ентерпрайзные организации, в которых информационные безопасники выполняют хоть один пункт из перечисленных. Я о таких не знаю.
Особенно пентест порадовал :)
И разве 2194-У относится к аутисекам? Обычно таким риски занимаются.
Анализ процессов обработки конфиденциальной информации — это к планированию.
«Обеспечение безопасности при взаимодействии с контрагентами» — какого рода обеспечение? Техническое (грубо говоря — VPN)? Абсолютный пример «администраторской» работы. А если речь идет про бумаги, то они уже в ведении физбезопасности.
Должно быть, мне очень повезло, что мне несколько подобных организаций известны :)
О внутреннем контроле я упоминал в контексте того, как должно быть организовано подчинение контролирующих подразделений относительно контролируемых ими. (СВК контролирует всех, обычно подчинено высшему органу управления. ОИБ контролирует в том числе ОИТ, нежелательно их подчинение одному руководителю.)
При взаимодействии в контрагентами мероприятия по ИБ могут включать как технические (IDM, 802.1x, MDM, VPN и куча других страшных слов), так и организационные меры (установление требований к договорам; заключение соглашений о конфиденциальности и контроль их выполнения; инструктажи; контроль деятельности; участие в разработке технических заданий и проведении приемочных испытаний — если контрагент является поставщиком или вендором; и так далее).
И да — я верно понял, что вы против включения физической безопасности в состав областей, относящихся к информационной безопасности?
Если это так, то обращаю внимание, что сейчас принято считать, что информационная безопасность (и я целиком и полностью с этим согласен) есть управлением любыми неспекулятивными рисками. Предлагаю поразмыслить над этим определением, при необходимости могу раскрыть его более подробно.
О внутреннем контроле я упоминал в контексте того, как должно быть организовано подчинение контролирующих подразделений относительно контролируемых ими. (СВК контролирует всех, обычно подчинено высшему органу управления. ОИБ контролирует в том числе ОИТ, нежелательно их подчинение одному руководителю.)
При взаимодействии в контрагентами мероприятия по ИБ могут включать как технические (IDM, 802.1x, MDM, VPN и куча других страшных слов), так и организационные меры (установление требований к договорам; заключение соглашений о конфиденциальности и контроль их выполнения; инструктажи; контроль деятельности; участие в разработке технических заданий и проведении приемочных испытаний — если контрагент является поставщиком или вендором; и так далее).
И да — я верно понял, что вы против включения физической безопасности в состав областей, относящихся к информационной безопасности?
Если это так, то обращаю внимание, что сейчас принято считать, что информационная безопасность (и я целиком и полностью с этим согласен) есть управлением любыми неспекулятивными рисками. Предлагаю поразмыслить над этим определением, при необходимости могу раскрыть его более подробно.
так и организационные меры (установление требований к договорам; заключение соглашений о конфиденциальности и контроль их выполнения
Это по большей части относится к компетенции департамента управления рисками.
я верно понял, что вы против включения физической безопасности в состав областей, относящихся к информационной безопасности?
Я не против. Но обычно это — совершенно разные структуры. Опять же, я смотрю не «как оно должно быть у меня в фантазиях», а «как оно обычно есть». Ребята, занятые охраной офисов, СКУДами и прочим, включаются в отдельную иерархическую ветку и пересекаются с IT Sec только на уровне предправления.
Это по большей части относится к компетенции департамента управления рисками.
Зачем подменять действительность своим частным опытом из одной (банковской) отрасли? Кроме того, например, мне приходилось сталкиваться с тем, что в банках в эти конкретные мероприятия гораздо сильнее рисковиков были вовлечены безопасники, юристы и кадровики.
я смотрю не «как оно должно быть у меня в фантазиях», а «как оно обычно есть». Ребята, занятые охраной офисов, СКУДами и прочим, включаются в отдельную иерархическую ветку и пересекаются с IT Sec только на уровне предправления
Лучшие практики, реализуемые в зрелых отечественных компаниях, — фантазии? Возможно. Повторюсь, что не всегда верно ограничиваться только своим частным опытом. Кроме того,
IT Sec[urity]— не то же самое, что Information Security / Information Assurance.
ИБ, ИБ-шник… Есть админы-безопасники, а есть люди, работающие если угодно на другом уровне асбтракции, которым не надо знать толком ни сетевые технологии (хоя полезно), ни серверные вещи. Они должны хорошо разбираться в бизнес процессах, понимать, какие активы, чем череповато то или иное, на чем и как фирма может потерять. Они должны быть связующим звеном в каком-то смысле между разными подразделениями и отделами. Админ, даже профи в вопросах сетевой, допустим безопасности, может совершенно не понимать или даже не знать специфики бизнеса. В одном случае проникновение за периметр и особенно глубже может быть смерти подобно (встает под удар, допустим АСУ ТП или важная база данных), в другом случае это плохо и неприятно, но не смертельно, а вот какое-нибудь неудачное/некорректное слово (даже не раскрывающее конфиденциал), походя брошенное в соц. сети сотрудником или ляп отдела кадров, взявшего «не того» человека гораздо страшней для бизнеса. А дальше, при отличном ориентировании в том, на чем деньги делаем, на чем их (или еще что-то) теряем, при (может быть даже не слишком глубоком) знании конечных технологий, ИБ шник определяется, на что деньги тратим. На DLP и обучение ит-кадров или на IPS/IDS, проф. аудит сетевой инфраструктуры и прочее. Исполнять и оттачивать детали должны уже люди рангом ниже, ИТ-шники обычные и ИТ-шники безопасники, отдел по работе с персоналом ака отдел кадров и прочие. А описанный мной «высокоуровневый» ИБ-шник еще должен озаботиться плюсом ко всему, как проверить адекватность реализаций и результативностью принятых конечных мер. Какой предусмотреть адуит или еще что-то подобное. А то направления и риски могут быть им определены очень точно, а вот кончится это может отписками, что все внедрили и обеспечили, а по факту бардак.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Для ИБшников