Comments 39
С большим интересом прочел статью. По роду работы я весьма близок к описанным проблемам ИБ. В российском сегменте IT есть несколько неразрешимых в настоящее время проблем ИБ - от нас ушли иностранные вендоры и это повлекло например:
Невозможность лицензировано обновиться на новую версию Vmware, на которой крутится весь виртуальный прод
Новые платные коммерческие жавы стали недоступны (возможно я не прав, если так, то прошу коммент)
Оракл базы и весь их софт для нас стал недоступен в плане обновлений и поддержки
Поддержка RHEL (есть варианты, по серой схеме, кто знает, тот в курсе)
И так далее.
Как в таких случаях быть в тренде ИБ?
Варианты перевода на "отечественные" оси просто смешон. Платить RedOS за сборку каждого нужного пакета отдельно или использовать Астру - болгенос с нескучными обоями - мы перейдем со временем и на эту дрянь, но это вгоняет меня в печаль.
Вот тут я, каюсь, решительно бесполезна, у меня такого опыта никогда не случалось, ттт :)
По идее, это же часть Vendor Risk Assessment'а и прочего Business Continuity, не – что делать, если ваш основной драгоценный вендор красиво застрелился навсегда. Но такой вариант происходящего, как последний год происходит, в страшном сне никто не рассматривал, я полагаю.
Не стоит так оскорблять Астру, при всей явной вашей любви к заморскому. Там под капотом работает PARSEC - прямой конкурент других систем Mandatory access control (MAC) таких как AppArmor, SELinux. Если бы вы почитали про её математическую верифицируемость и используемые модели безопасности, то не стали бы сравнивать с "болгенос", намекая на просто переделанные "нескучные обои". И хоть Астра в хорошем смысле основана на Debian GNU/Linux, но вдумайтесь что пакеты не берутся один в один, а патчатся (тестируются, проверяются) на работу с их моделью безопасности. Буквально вчера сам на собственной шкуре оценил такую работу - на сервере с Astra Linux SE есть PostgreSQL, в котором как думал я легко и просто добавлю себе учётную запись для подсоединения со своего рабочего ПК. Пришлось разбираться, а что мне выводит не ванильный PostgreSQL - Error obtaining MAC configuration for user.
Имхо, работа нужна, чтобы работу работать, а не обои рассматривать) А если серьезно, то астра musthave для безопасной инфраструктуры и, учитывая сколько багов было выпилено и насколько продукт в целом улучшился за пару-тройку лет, работают над ней более чем активно и в нужном направлении.
Статья - огонь! Все так и есть. На разделе про Asset Management пошли горькие слезы, ибо за него родимы боролся послдених лет пять, и если бы не животворящие грабли, то наверное бы так и не появился.
Коллега, спасибо за то, что передали суть простым языком.
В качестве расхожих предствалений об ИБ к настройке фаервола добавил бы еще и антивирус. ИБ = фаервол+антиврус. )))
Спасибо, коллега, на добром слове :)
Рыдания при виде Asset Management'а – это у нас профессиональное, чо уж. По приходе на новое место можно ожидать всякого и разного, но что Asset Management там будет первым пунктом повестки, можно даже не сомневаться. Единственный раз в жизни при всех сотрудничествах и обменах опытом я видела заведение с довольно непреклонным Asset Management'ом – это был нидерландский ING банк, приличных размеров банчище на 12, что ли, стран в общей сложности, где во главе IT operations, видимо, стоял кто-то реально понимающий. И вот у них было прямо загляденье, конечно. А так в среднем по деревне, конечно, мда.
У этого явления есть причина: зрелое управление ИТ-активами и процессами просто не явлется частью KPI ИТ, даже если менеджмент прокачался до того, что бы KPI ИТ увязывать с целями бизнеса (а это уже не мало). Управление ИТ-активами это глубоко бэк-офисная штука, которая стоит очень дорого в поддержке, а явного легко видимого профита не дает. И есть гигантский соблазн заниматься инновациями и новыми проектами, накапливая технический долг в управлении инфраструктурой. Платят то за вершинку айсберга, а канализация никому не интересна. Меняется что-то лишь тогда, когда серьезно прорвет.
Тут можно провести аналогию с ресурсами на поддержку качественной кодовой базы и процессов рефакторинга кода в процессах разработки.
Ну вот я обычно пытаюсь сделать количество неопознанных объектов в системе метрикой для IT operations. Потому что я могу предложить им процесс и даже где-то повоевать за приоритизацию и понимание в верхах, но я не могу за них сделать красиво. Но соблазн забить все равно всегда есть, конечно. А ну как не отвалится. А ну как я тут проработаю годика три-четыре-пять и свалю на более тучные пастбища, а взорваться оно не успеет. Тьфу.
Отличная статья, отличная профессия. Был инженером - ненавидел ваших коллег при полном понимании важности. То рута отключи, то слезь с привычной версии софта, то патчи на операционку ставь в каждый месяц, то что-то более заковыристое с сетевой архитектурой. Молодцы, очень важная работа, как же бесите, господи!
Только не очень понял, как-то в одну кучу безопасность и itil с asset management. Без них конечно жизнь не жизнь, но это точно не безопасность должна пушить и отвечать.
Если мы вас не бесим, значит, мы плохо работаем, ясное дело :)
С ITILем дружить надо, потому что огромная часть безопасности с ним напрямую пересекается. Три великих кита инфобеза – Confidentiality, Integrity, Availability, и вот тут вот в последней части к нам подъезжает, например, тот же Incident Mgmt. А без Asset Mgmt и самого понятия сервисов и компонентов сервисов мы никуда. Так что управление этими самыми активами – первое же требование во всех возможных инфобезовских фреймворках и опросниках. Это очень даже безопасность. Но именно отвечает за это основное айти, конечно, наше дело – ныть и пилить.
а тортик вкусный прямо сейчас. Искушение сэкономить на ИБ неодолимо.
Тортик — это ложь. (с) Portal
Средний возраст уязвимости, через которую влезают злодеи, составляет семь лет. СЕМЬ
Можно ткнуть ссылкой на источник данной фразы?
Какой-то Гартнер наверняка, поищу. Помню, что определенно прошлогодний, мы эту статистику вынимали для большой презентации по awareness где-то в октябре, что ли.
Я не знаю, откуда фраза, но подозреваю, что дело в комбинации того, как собирали эту статистику и статистических проблем типа "ошибки выжившего", но наоборот.
Ломать хорошо защищённую систему сложно же. Приходится искать наиболее рациональный путь: социнженерия, слабозащищённые побочные каналы/сети, "полузаброшенные" сайты компании и т.п. И тут скорее всего получается так, что именно та дыра которая используется может оказаться древней. Хотя, о чём это я, почему "древней"? 7 лет назад уже был 2016 год - это примерный возраст Ubuntu 16.04, RHEL 7, Windows 10, SQL Server 2016, PostgreSQL 9.5.
круто написано, и шикарным языком!
Поскольку вы работаете в Европе, немного личный вопрос. Вы знаете только английский или ещё и "местный" язык?
Совершенно случайно на LinkedIn смотрел вакансии по секьюрити. Знание "местного" языка в них на уровне B2 - маст хэв.
Добрый день, местный знаю, да, но в моем случае (и абсолютном большинстве остальных вакансий, какие мне попадались) местным языком работать не приходится. Более того, я знаю, что одно из государственно-важных предприятий в моей стране, например, имеет импортное CISO, поэтому даже государственные совещания по этому поводу происходят на английском. Но банк, в котором я работала до этого, имел Global CISO в Швеции и local CISOs в каждой из остальных стран со знанием местного языка, да, на случай, если надо поработать говорящей головой и что-нибудь хорошенько прокомментировать для прессы.
Ну то есть вот первое попавшееся объявление с линкедина, которое буквально копия моей позиции. Ни слова о местном языке.
Отличная статья, прямо таки универсальное how to "как работать в большой корпорации"
Интересная статья. Большое спасибо.
Надеюсь она развеет миф о том, что ИБ - это только правильно настроенный файрвол плюс антивирусник со свежими обновлениями.
Прохождение на соответствие PCI DSS не мало сил потребовало в своё время.
Осилили.
Всякий раз, когда я читаю про ИБ и затыкание дыр у меня начинает подёргиваться глаз.
Окей, допустим у нас есть идеальная ситуация: пришло ИБ и всё обезопасило.
Пользователь защищён по кругу антивирусами и файрволами, винда максимально обновлена, вокруг там ещё какая-то сетевая магия, которая всех спасёт.
А потом внезапно оказывается, что файрвол с антивирусом мешает работать пользователю, да и ежедневные обновления винды тоже время отнимают.
И вот сотрудник занят тем, что безостановочно строчит таски в джиру (выпуститеменяотсюдаааа), ибо работать как-то надо, да антивирус мешает.
И вся эта конструкция сваливается, по сути, в перекладывание головной боли с одной головы на другую.
У ИБ всё хорошо ("ура! я всех защитил!" - думает ИБшник). А у сотрудников всё плохо, ибо они в полной безопасности, но.... работать не могут.
Ыыых
Отлично, но сколько это всё стоит? И как это соотносится с масштабом потерь от киберугроз? Это вопросы с которых вообще-то надо начинать, чтобы понять осмысленность намерений что-то изменить, но при этом они совсем никак не затронуты в статье и вообще почему-то их не слишком принято обсуждать.
Грубо говоря, даже если в компании полнейший бардак с процессами ИБ, то совершенно нет смысла его исправлять, если мы посчитали, что средний ожидаемый ущерб от злоумышленников составляет, например, сто тысяч долларов в год, а затраты на внедрение процессов - один миллион единоразово и те же сто тысяч ежегодно. От улучшения процессов мы только лишь потеряем лишний миллион и не получим никакой пользы. Так что в этой гипотетической ситуации осмысленно ничего не делать будет не только допустимо, но ещё и оптимальнее, чем приводить всё к идеальному виду.
Поэтому мне бы хотелось больше слышать о том, как оценивается вероятность атаки на инфраструктуру и как посчитать ущерб от её последствий. Эти данные будут гораздо более весомыми для убеждения кого-то (и даже просто самого себя), что нужно действительно предпринимать какие-то действия (или наоборот - не тратить лишние ресурсы), чем просто информирование о рисках, которые в общем-то в отвязке от своей финансовой стоимости примерно так же абстрактны, как риск падения метеорита или риск того, что директора фирмы переедет трамвай. То есть, если нет ответа на вопрос, почему ресурсы нужно тратить на ИБ, а не на систему предупреждения директора о приближающемся трамвае, то вряд ли и убедить кого-то получится в необходимости подобных трат.
Поэтому мне бы хотелось больше слышать о том, как оценивается вероятность атаки на инфраструктуру и как посчитать ущерб от её последствий
Интересно, как оценивают такие риски. Например, экзистенциальные, репутационные, денежные риски от утечки персональных данных. Есть ли какие-то признанные методики или на практике это вопрос про внутрикорпоративную политику?
Есть, конечно, тут изобретением велосипеда обычно не обойдешься. Вот симпатичный обзор самых популярных: https://www.csoonline.com/article/2125140/it-risk-assessment-frameworks-real-world-experience.html
В статье вообще довольно много чего не затронуто, если кто заметил, потому что статья конечна, а информационная безопасность – не очень. Но при желании вы наверняка найдете в сети множество статей получше и на интересующие вас темы.
Шикарно!
А через что у вас реализован Asset Management?
Мм, есть большое искушение ответить "через жопу", но через нее он почти у всех реализован, чо уж. Так что я обтекаемо скажу, что наиболее крупные игроки на рынке сейчас – Service Now, Qualys, Atlassian (у которых оно немножечко сыровато, впрочем) и какой-нибудь ADDM для коллекции. Причем Service Now и Atlassian обладают тем преимуществом, что являются одновременно и automated discovery, и operational platform, так что ничего никуда интегрировать хотя бы не надо. Qualys – огромный роскошный лимузин в мире инфобеза, который умеет вообще все на свете, но за много денег. Он же легко и приятно интегрируется в Service Now и, по слухам, в Atlassian, но я лично не пробовала.
Завхоз ландшафта в поисках хозяина дыры: зачем и как я шантажирую начальство