Журнал "Системы Безопасности" № 5‘2022

Почему именно централизованно, почему недо- статочно разбирать продукты поодиночке? Как показывают опыт и практика, события в связан- ных сервисах, не всегда означающие что-то полезное поодиночке, в связке могут дать вам понимание происходящих процессов. Мы в Райффайзенбанке выбрали одно из самых популярных мировых решений для сбора дан- ных – Elastic Stack. Практика эта здравая, потому что в случае, когда у нас есть много данных, мы можем их обрабатывать – обрабатывать в авто- матическом режиме, поставив нужные триггеры или устраивая сессии рассмотрения аналитики, перенимая опыт у коллег из бизнеса, которые давно и успешно используют инструменты BI (Business Intelligence). Среди инструментов дан- ного направления я бы отметил Tableu, но его использовать в новых реалиях не представляет- ся возможным. Популярен также Microsoft Power BI, который сейчас есть в виде наземных лицензий, и это сильно может выручить нас до того момента, когда мы увидим какие-то собст- венные продукты, способные предоставить подобный функционал. Power BI очень прост в освоении. Если вы использовали когда-нибудь Excel в продвину- том режиме, то начать решать задачи по анали- тике в Power BI будет достаточно просто. Процессы для поддержания уровня сервиса, как мне кажет- ся, основополагающие процессы – в первую оче- редь это Incident Management (инцидент-менедж- мент). Первое, на что я хочу обратить внимание в рамках инцидент-менеджмента, – это новые каналы регистрации обращений в поддержку. Гибридный формат работы не предполагает воз- можности подойти к специалисту или позвонить на горячую линию. Поэтому важно проинспекти- ровать имеющиеся у вас чаты и другие средства для совместной работы – возможно, именно в них есть оптимальный канал-инструмент. второй важный момент в инцидент-менедж- менте – максимальный упор на самообслужи- вание. Если какую-то задачу или какую-то поломку ПО сотрудник может исправить сам, то этот кейс необходимо автоматизировать и пре- доставить информацию по решению. Третий момент – это автоматизации, которые могут работать, основываясь на данных из мониторинга, то есть на аналитике данных. Если что-то можно сделать без участия пользователя, это обязательно надо привести в автоматизиро- ванный вид и сделать. другие важные процессы – это Problem Manage- ment (управление проблемами) и Disaster Mana- gement (управление чрезвычайными ситуация- ми), которые скорее направлены на то, чтобы мы не имели проблем со стабильностью в будущем. Следует помнить, что Problem и Disaster Manage- ment – это не поиск виновного на недружелюб- ных собраниях специалистов и менеджмента. Собрания необходимы, но с другой целью – для поиска такого способа, при котором случившая- ся проблема больше никогда не повторится, для извлечения максимальных практических выво- дов и уроков из произошедшего. От стабильности к надежности Термины и их понимание играют очень важную роль для взаимопонимания между коллегами, исполнителями и заказчиками. в данном кон- тексте слово "стабильность", часто применяемое в отношении сервисов, меня не очень устраи- вает, так как подразумевает некоторую "неизменность". но мы не должны стоять на месте, сервисы должны развиваться, поэтому я предлагаю заменить термин "стабильность" для корректного целеполагания на "надежность и устойчивость", ведь именно этого от нас ждут пользователи. n Ч асто работники сферы информационной безопасности сталкиваются с недопони- манием со стороны руководства, которое не заинтересовано в том, чтобы закладывать в бюджет большие суммы на профилактиче- ские меры по информационной безопасности (иБ). Многие руководители не видят смысла в расширении штата отдела иБ, так как, по их мнению, если в штате уже присутствует офи- цер или менеджер по информационной без- опасности, все риски этой сферы закроются сами собой и ничего больше предпринимать не нужно. Если смотреть на данный вопрос с такой точки зрения, поддерживать информацион- ную безопасность в вашей компании на должном уровне будет невозможно. Руково- дитель в первую очередь должен понимать, для чего ему отдел информационной без- опасности и какие результаты он хочет видеть по итогам работы. и это должны быть не абстрактные понятия вроде "все должно работать и ничего не должно уте- кать", а принятие перечня согласованных мер, которые необходимо выполнить в уста- новленные сроки. видов угроз – масса, а их приоритет для каждой компании индивиду- альный. Как представить итоги работы по информа- ционной безопасности руководству? чтобы решить этот вопрос, необходимо в первую оче- редь довести до руководства простой факт того, что неуязвимых систем не существует. невозможно защититься от всего, и основная цель отдела информационной безопасности вашей компании – это снижение найденных рисков возникновения инцидентов до мини- мального уровня. для этого необходимо в первую очередь иден- тифицировать риски, проведя аудит информа- ционной безопасности. Он может быть прове- ден как самостоятельно сотрудниками отдела информационной безопасности, так и внешней компанией, предоставляющей подобные услу- ги. По итогам аудитов необходимо составить план работ (дорожную карту) по повышению уровня защищенности вашей компании либо поддержанию ее на должном уровне. данный план в обязательном порядке должен быть согласован с руководством компании, после чего по выполненным работам и статистиче- ским данным об инцидентах в течение года будет составляться отчет о работе отдела. хочется отметить, что закрытие плана работ по информационной безопасности, разбор штат- ных инцидентов и аварийных ситуаций могут быть недостаточными для некоторых руково- дителей. Технические ошибки в ходе процесса разработки, массовые DDoS-атаки беспреце- дентного характера, которые никаким образом нельзя протестировать, а также принятые ранее риски могут вновь спровоцировать инциденты иБ, которые могут быть приравнены к халатно- сти со стороны отдела информационной без- опасности. в данном случае рекомендуется позаботится о следующем: l документально распределить ответствен- ность за различные технические средства компании (чтобы сотрудники иБ не отвечали за технические ошибки систем, так как это ответственность системных администраторов компании); l составлять протокол или акт по принятым рискам иБ в компании, чтобы в случае наступления инцидента, который можно было предотвратить, ответственность брали на себя сотрудники того департамента, кото- рые выступали за принятие данного риска; l грамотно составить и согласовать план реа- гирования на инциденты и придерживаться его в случае возникновения. здесь важно понимать, что угрозы были локализованы, изолированы и устранены в установленный срок. в противном случае руководство будет сложно убедить в эффективности мероприя- тий по устранению рисков со стороны отдела информационной безопасности. надеюсь, что описанные выше меры помогут сложить правильное мнение руководства о работе вашего отдела информационной без- опасности и укрепить уверенность в правиль- ности вашего подхода к работе. Денис Богданов Независимый эксперт по информационной безопасности МНЕНИЕ ЭКСПЕРТА S E C U R I T Y A N D I T M A N A G E M E N T 19 www.secuteck.ru октябрь – ноябрь 2022 СПЕЦПРОЕКТ БЕзОПаСнОСТь БанКОв и финанСОвых учРЕждЕний в нОвых уСлОвиях Ваше мнение и вопросы по статье направляйте на ss @groteck.ru Для чего нужна информационная безопасность компании и как убедить в этом руководителя? Для поддержания информационной безопасности в компании на должном уровне нужно, чтобы руководитель понимал суть и важность данных процессов. Постараюсь обобщить свой опыт и рассказать, что для этого нужно делать