Журнал "Information Security/ Информационная безопасность" #4, 2018

Фундаментальные конт- роли безопасности в боль- шинстве организаций и так уже выполняются админи- страторами – создание резервных копий, антиви- русная защита, администри- рование сетевого оборудо- вания, управление доступом и учетные записи. Так что, пожалуй, единственное, где специалисты по безопасно- сти заменяются с трудом, – это тренинги персонала, реагирование на инциденты и обеспечение безопасности приложений. в Council on Cyber Security, а в 2015 г. – в Center for Internet Security (CIS). Контроли делятся на три части: базовые, фунда- ментальные и организацион- ные. И практически все эти контроли (кроме, пожалуй, орга- низационных) можно выполнить силами исключительно ИТ-под- разделений, они перекликаются с имеющимися в большинстве организаций системами. Взять хотя бы базовый набор, на осно- ве которого строятся все даль- нейшие: l CSC 1 – инвентаризация и контроль железа. Как правило, у администраторов в том или ином виде это уже есть. От файла с табличкой со списком серверов и пользовательских ПК до систем централизован- ного управления и/или монито- ринга; l CSC 2 – инвентаризация и контроль ПО. Если нет – решае- мо системами из CSC 1 или же банальными скриптами; l CSC 3 – управление уязви- мостями. Тут всё несколько сложнее, но в конечном итоге обновлениями серверов будут заниматься всё те же админи- страторы. Впрочем, при нали- чии любого более-менее совре- менного сканера с возмож- ностью генерации отчетов в почту или системы управления задачами роль безопасности сводится только к контролю и периодической интерпретации; l CSC 4 – управление админи- стративными привилегиями. Банальная ИТ-гигиена "не ходи под рутом", отсутствие общих учетных записей и контроль появления новых. Впрочем, этот пункт администраторы обходят и при наличии штатного "без- опасника", например на корот- кий срок отключив логирование событий. И намного разумнее делегировать проверку этого контроля и ответственность за исполнение оного не только системам мониторинга, но и людям внутри ИТ; l CSC 5 – безопасные конфи- гурации оборудования и ПО на всех устройствах. Исполнять это опять же будут специалисты ИТ-подразделения и опять же набором ПО из первых двух пунктов. Роль специалиста по безопасности тут относительно одноразовая – создание стан- дартов и поддержание их спис- ка в актуальном виде. Но можно обойтись и общедоступными CIS Benchmarks, в которых достаточно подробно разъясне- но, зачем делается та или иная настройка; l CSC 6 – мониторинг и анализ логов аудита. Достаточно вспомнить, что SIEM-системы выросли из обычного ИТ-конт- роля, а именно управления логами (LM – лог-менеджмент систем). Фундаментальные же конт- роли безопасности в большин- стве организаций и так уже выполняются администратора- ми – создание резервных копий, антивирусная защита, админи- стрирование сетевого оборудо- вания, управление доступом и учетные записи. Так что, пожа- луй, единственное, где специа- листы по безопасности заме- няются с трудом, – это тренинги персонала, реагирование на инциденты и обеспечение без- опасности приложений. Но с безопасностью прило- жений тоже не все так одно- значно. Да, "взломы" выглядят очень эффектно, но хорошие специалисты по безопасности приложений – это те самые исторические "хакеры", т.е. про- граммисты со знанием безопас- ности. Также проверки на OWASP top-10 (самые "детские" уязвимости) могут выполняться QA и встраиваться в процесс обычного тестирования. Конеч- но, это не будет панацеей от всех бед, и если ваш основной бизнес связан с работой при- ложений или сайта, то пол- ностью полагаться на подобный процесс не стоит. Но эксперт по безопасности приложений может находиться и среди раз- работки. Postmortem ИТ-безопасность как отдель- ная функция – умирает. Она не успевает ни за ИТ, ни за разра- боткой, ни за скоростью бизнеса в целом. Да и кадровый голод способствует тому, что функция если не мертва, то уже близка к этому. Хорошего программиста можно научить нюансам безопас- ности. Хорошего тестировщика можно научить искать уязвимо- сти. Матерому системному адми- нистратору можно объяснить, как распознать компрометированный сервер или защититься. Да даже специалиста по мониторингу можно научить распознавать инцидент (он и так это делает, только в ИТ). Специалиста, кото- рый послушал учебную програм- му по безопасности и прочитал два стандарта, быстро обучить глубоко понимать практические аспекты невозможно. Фундаментально нет разли- чий между процессами ISOC и инфраструктурным мониторин- гом, эксплуатацией ИТ и ИБ, ИТ-тестированием и ИБ-тести- рованием. Поэтому – хватит спорить, кто главнее! Безопасность должна встраи- ваться в другие функции для того, чтобы успевать бежать все эти спринты вместе со всеми. Начиная с возвращения в лоно ИТ-подразделений – с уровня архитекторов (чтобы учитывать аспекты безопасно- сти при проектировании) и до уровня эксплуатации с ответ- ственностью за выполнение тре- бований. Думаю, что и с "бумаж- ным" направлением случится то же самое – хороший юрист намного качественнее осознает сухие требования и поймет, что нужно написать в документах для исполнения. Да, есть очень большой риск – "конфликт интересов" и рычаг пропуска небезопасных реше- ний. Но опция "я принимаю риск" есть и при существующих службах безопасности. А если нет разницы – зачем платить больше? l • 19 УПРАВЛЕНИЕ www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru