Не перестараться бы с фильтрацией...
Ложные срабатывания - огромная проблема SOC. Чем раньше мы хотим обнаруживать атакующего, тем к большему количеству ложных срабатываний нам надо готовиться - отчасти про это наиболее философский слайд в презе про нашего машинообучаемого Автоаналитика. Требуется адаптация и постоянное управление фильтрами.
Модные сканеры безопасности в своей работе доходят аж до повышения, поэтому создают ужасно много шума, отвлекающего SOC. В этой связи может выглядеть логичным желание зафильтровать все алерты от хоста-сканера ........................................
А откуда у нас информация, что хост сканера не может быть подломан?? И тогда уже реальный атакующий сможет оставаться незамеченным в рамках функциональности сканера безопасности(т.е. делать что угодно!)
Я видел инциденты, которые происходили на хостах, пофильтрованных ввиду огромного количества контекстных (инфраструктурных) ложных срабатываний, поэтому, фильтруя алерты от систем инвентаризации, сканеров безопасности, хостов исследователей ВПО или каких-либо конвейеров автообработки ВПО, надо всегда быть готовым ответить на вопрос: "Как и когда я обнаружу инцидент на этом хосте?"
Разрешить сей конфликт между помереть под алертами и пропустить инцидент нам поможет процессная(бумажная) составляющая организации таких "опасных" работ (в целом, опыт показывает, что чем более опасные работы мы вынуждены делать, тем жестче на следует их регламентировать):
- процедуризация и регламентирование - нам всегда известны начальные условия проведения таких работ: кто, когда, с какими настройками, на каком объеме, что конкретно делает;
- учет работ: факт начала и окончания работ фиксируется в учетной системе, например, ITSM, там же доступны IoC-и для быстрой и точной атрибуции (также об этом рассуждал здесь);
- всегда есть ответственный доступный контакт у кого можно спросить, если по учетным системам не атрибутируется или есть любые сомнения;
- пытаемся максимально сокращать поверхность атаки: сканер выключен, когда не работает, аналитик ВПО работает на другой машине, в изолированной сети, которая выключена, когда на ней не работают и т.п.
#MDR #vCISO #пятница
Ложные срабатывания - огромная проблема SOC. Чем раньше мы хотим обнаруживать атакующего, тем к большему количеству ложных срабатываний нам надо готовиться - отчасти про это наиболее философский слайд в презе про нашего машинообучаемого Автоаналитика. Требуется адаптация и постоянное управление фильтрами.
Модные сканеры безопасности в своей работе доходят аж до повышения, поэтому создают ужасно много шума, отвлекающего SOC. В этой связи может выглядеть логичным желание зафильтровать все алерты от хоста-сканера ........................................
А откуда у нас информация, что хост сканера не может быть подломан?? И тогда уже реальный атакующий сможет оставаться незамеченным в рамках функциональности сканера безопасности
Я видел инциденты, которые происходили на хостах, пофильтрованных ввиду огромного количества контекстных (инфраструктурных) ложных срабатываний, поэтому, фильтруя алерты от систем инвентаризации, сканеров безопасности, хостов исследователей ВПО или каких-либо конвейеров автообработки ВПО, надо всегда быть готовым ответить на вопрос: "Как и когда я обнаружу инцидент на этом хосте?"
Разрешить сей конфликт между помереть под алертами и пропустить инцидент нам поможет процессная
- процедуризация и регламентирование - нам всегда известны начальные условия проведения таких работ: кто, когда, с какими настройками, на каком объеме, что конкретно делает;
- учет работ: факт начала и окончания работ фиксируется в учетной системе, например, ITSM, там же доступны IoC-и для быстрой и точной атрибуции (также об этом рассуждал здесь);
- всегда есть ответственный доступный контакт у кого можно спросить, если по учетным системам не атрибутируется или есть любые сомнения;
- пытаемся максимально сокращать поверхность атаки: сканер выключен, когда не работает, аналитик ВПО работает на другой машине, в изолированной сети, которая выключена, когда на ней не работают и т.п.
#MDR #vCISO #пятница
🔥8
Полно случаев в практике, да и ни у кого не вызывает сомнения, что неправильное лечение может ухудшить состояние пациента. Можно загубить как сам предмет лечения, так и здоровые органы. Ну, например, если бездумно трескать "бесконечно полезные" биодобавки и витамины, то могут отъехать печень и\или почки, которые буду стремиться все эту инородчину выводить.
Но, как известно, лечить можно не только тело, но духовное состояние (исторически это область религии). Мы не будем касаться психиатрии - это точная, многократно проверенная на практике, наука и здесь сложно уже быть инноватором и, в общем-то надо иметь профессиональное образование и опыт. А вот всякого рода "психологов", энергопрактиков и коучей, в том числе и коучей разного рода роста - личного, финансового, духовного - сейчас наблюдается великое множество. Популярность их объясняется старинной идеей халявы (по одной из версий от "халав", с иврита "молоко"): как привлекательно быстро, прямо здесь и сейчас, без каких-либо усилий, получить вожделенное, может, даже никогда и не доступное, ввиду множества личностных характеристик или недостатка образования, умений, трудолюбия, в конце концов, удачи. А вдруг?! Ведь столько подобных мне, как будто без труда, гребут успех лопатой, чем же я хуже?! А все эти архаичные взгляды, что для финансового и карьерного успеха надо фигачить как проклятый много лет - пережиток прошлого, и сейчас все по-новому! А новые взгляды требуют новых подходов для их достижения, поэтому появляются противоречащие здравому смыслу методы достижения целей, а сама новизна этих новых взглядов как бы подтверждает эффективностьновых современных способов достижения целей, даже кажущихся невозможными с точки зрения трезвого рассудка устаревших взглядов, достижения желаемых успехов, денег, счастья, славы, удачи, и вообще чего угодно (пример - антипрививочники).
Ну ладно, с теми кто желает без усилий получить многое, в целом, понятно. Верить в чудо и ждать его всегда проще, чем прикладывать усилия. Но верно и обратное: по методам работы коуча\наставника\шамана\и т.п., тому что он говорит\пишет, можно строить суждения об эффективности его методов и о нем самом (он же продукт своего продукта). Например, искусствоведы сходятся во мнении, что картины Ван Гога (особенно эта) вполне отражают его диагноз. И живопись - не единственный пример. Душевное состояние автора, как правило, отражается в его произведениях. Именно поэтому я очень люблю читать не только книжки, но практически всегда интересуюсь биографией автора, чтобы лучше понимать при каких обстоятельствах был выдал свой шедевр.
Как неправильное лечение может покалечить наше тело, так и неправильные убеждения могут повредить наше ментальное состояние. Вместо душевно оздоровившегося можно стать душевно больным шизофреником.
Вот такие мысли у меня возникли, когда я начал читать книжку Михаэля Зингера "Трениннг освобождения души". Нет, я не хочу сказать, что книжка плохая, правда, что она хорошая тоже не могу сказать, там слишком много шаманства и наукообразия (когда бредовые объяснения преподносятся как высоконаучные обоснования), а мне, ИТшнику, более близко что-то практическое, материальное, осязаемое, научно доказанное. Книга точно будет полезна всякого рода энеропрактикам (про внутреннюю энергию и чакры я уже успел многое там прочесть). Следует отметить, с учетом того, когда книжка была написана, что она - база всех энергопрактик, своего рода "Пикник на обочине" Стругацких для целого ряда последующих писателей про сталкеров.
Я не люблю оставлять дела незаконченными, поэтому книжку точно дочитаю. Если там будет еще что-то полезное, помимо упомянутых чакр, внутренней энергии и разговоров с собой, напишу еще одну короткую заметку.
Всем замечательной пятницы и выходных!
😁
#пятница #книги #саморазвитие
Но, как известно, лечить можно не только тело, но духовное состояние (исторически это область религии). Мы не будем касаться психиатрии - это точная, многократно проверенная на практике, наука и здесь сложно уже быть инноватором и, в общем-то надо иметь профессиональное образование и опыт. А вот всякого рода "психологов", энергопрактиков и коучей, в том числе и коучей разного рода роста - личного, финансового, духовного - сейчас наблюдается великое множество. Популярность их объясняется старинной идеей халявы (по одной из версий от "халав", с иврита "молоко"): как привлекательно быстро, прямо здесь и сейчас, без каких-либо усилий, получить вожделенное, может, даже никогда и не доступное, ввиду множества личностных характеристик или недостатка образования, умений, трудолюбия, в конце концов, удачи. А вдруг?! Ведь столько подобных мне, как будто без труда, гребут успех лопатой, чем же я хуже?! А все эти архаичные взгляды, что для финансового и карьерного успеха надо фигачить как проклятый много лет - пережиток прошлого, и сейчас все по-новому! А новые взгляды требуют новых подходов для их достижения, поэтому появляются противоречащие здравому смыслу методы достижения целей, а сама новизна этих новых взглядов как бы подтверждает эффективность
Ну ладно, с теми кто желает без усилий получить многое, в целом, понятно. Верить в чудо и ждать его всегда проще, чем прикладывать усилия. Но верно и обратное: по методам работы коуча\наставника\шамана\и т.п., тому что он говорит\пишет, можно строить суждения об эффективности его методов и о нем самом (он же продукт своего продукта). Например, искусствоведы сходятся во мнении, что картины Ван Гога (особенно эта) вполне отражают его диагноз. И живопись - не единственный пример. Душевное состояние автора, как правило, отражается в его произведениях. Именно поэтому я очень люблю читать не только книжки, но практически всегда интересуюсь биографией автора, чтобы лучше понимать при каких обстоятельствах был выдал свой шедевр.
Как неправильное лечение может покалечить наше тело, так и неправильные убеждения могут повредить наше ментальное состояние. Вместо душевно оздоровившегося можно стать душевно больным шизофреником.
Вот такие мысли у меня возникли, когда я начал читать книжку Михаэля Зингера "Трениннг освобождения души". Нет, я не хочу сказать, что книжка плохая, правда, что она хорошая тоже не могу сказать, там слишком много шаманства и наукообразия (когда бредовые объяснения преподносятся как высоконаучные обоснования), а мне, ИТшнику, более близко что-то практическое, материальное, осязаемое, научно доказанное. Книга точно будет полезна всякого рода энеропрактикам (про внутреннюю энергию и чакры я уже успел многое там прочесть). Следует отметить, с учетом того, когда книжка была написана, что она - база всех энергопрактик, своего рода "Пикник на обочине" Стругацких для целого ряда последующих писателей про сталкеров.
Я не люблю оставлять дела незаконченными, поэтому книжку точно дочитаю. Если там будет еще что-то полезное, помимо упомянутых чакр, внутренней энергии и разговоров с собой, напишу еще одну короткую заметку.
Всем замечательной пятницы и выходных!
😁
#пятница #книги #саморазвитие
🔥6😁2💩1🤡1🖕1
Интерфейс пользователя должен быть удобным! Но как это измерить?
То, что дизайнеры в прошлом художники (или творческие люди в общем случае), как бы, выглядит логично, но не более чем то, что продуктовые стратеги - разработчики.
Лично для меня "интерфейс красивый" в первую очередь означает "интерфейс удобный", причем в это "удобный" я включаю, как минимум, следующее:
1. цветовую палитру, расположение и размеры элементов, которые позволяют мне не напрягаясь, максимально быстро, рассматривать все элементы, фокусировать внимание в соответствии с ожидаемыми функциональными приоритетами (в первую очередь видеть то, что действительно важно)
2. количество манипуляций (например, движений и нажатий мышкой\пальцем) для совершения действий минимально
Из наличия достаточного количества ужасных интерфейсов делаю вывод, что есть проблемы с более-менее формальным измерением пользовательского опыта (UX), поэтому предложу идеи.
По цвету, расположению и размеру элементов предлагаю следующий тест. Профессионал в предметной области (SME), но ни разу не видевший тестируемый интерфейс, рассматривает интерфейс в течение N секунд (время определяется в зависимости от сложности интерфейса и на базе бенчмаркинга с аналогичными решениями), а затем его по памяти просят воспроизвести этот интерфейс на бумаге. При этом, стоит обратить внимание в какой последовательности SME будет зарисовывать интерфейс - это ответ на вопрос что он увидел в первую очередь, и сравнить это с функциональным назначением. Если SME не смог воспроизвести интерфейс по памяти, то с цветом, размером, расположением элементов есть проблемы, интерфейс надо перерабатывать. Более сложная, но и более эффективная реализация теста - это поискать ответ на вопрос: сколько нужно времени SME, чтобы запомнить его в достаточной для воспроизведения по памяти мере? Здесь надо уже привлекать нескольких SME. На практике у группы SME можно просто спросить их мнения (Метод Дельфи) и точечно отработать противоречия.
По сложности достижения цели предлагаю считать расстояние, которое проходит манипулятор (мышь\палец) для достижения цели и количество кликов. Здесь бы очень подошла мышка, измеряющая свой пробег - мышь с одометром, и счетчиком кликов. Чем меньше пройденное расстояние и количество кликов, тем лучше.
Отмечу, что UX - это целая наука, и я не могу себя отнести к эксперту в ней, но я не сильно совру, сказав, что я - эксперт по использованию продуктов, я опытный пользователь, и поэтому позволю себе иметь суждения о UX, чем и делюсь в этой заметке.
#dev #управление #пятница
То, что дизайнеры в прошлом художники (или творческие люди в общем случае), как бы, выглядит логично, но не более чем то, что продуктовые стратеги - разработчики.
Лично для меня "интерфейс красивый" в первую очередь означает "интерфейс удобный", причем в это "удобный" я включаю, как минимум, следующее:
1. цветовую палитру, расположение и размеры элементов, которые позволяют мне не напрягаясь, максимально быстро, рассматривать все элементы, фокусировать внимание в соответствии с ожидаемыми функциональными приоритетами (в первую очередь видеть то, что действительно важно)
2. количество манипуляций (например, движений и нажатий мышкой\пальцем) для совершения действий минимально
Из наличия достаточного количества ужасных интерфейсов делаю вывод, что есть проблемы с более-менее формальным измерением пользовательского опыта (UX), поэтому предложу идеи.
По цвету, расположению и размеру элементов предлагаю следующий тест. Профессионал в предметной области (SME), но ни разу не видевший тестируемый интерфейс, рассматривает интерфейс в течение N секунд (время определяется в зависимости от сложности интерфейса и на базе бенчмаркинга с аналогичными решениями), а затем его по памяти просят воспроизвести этот интерфейс на бумаге. При этом, стоит обратить внимание в какой последовательности SME будет зарисовывать интерфейс - это ответ на вопрос что он увидел в первую очередь, и сравнить это с функциональным назначением. Если SME не смог воспроизвести интерфейс по памяти, то с цветом, размером, расположением элементов есть проблемы, интерфейс надо перерабатывать. Более сложная, но и более эффективная реализация теста - это поискать ответ на вопрос: сколько нужно времени SME, чтобы запомнить его в достаточной для воспроизведения по памяти мере? Здесь надо уже привлекать нескольких SME. На практике у группы SME можно просто спросить их мнения (Метод Дельфи) и точечно отработать противоречия.
По сложности достижения цели предлагаю считать расстояние, которое проходит манипулятор (мышь\палец) для достижения цели и количество кликов. Здесь бы очень подошла мышка, измеряющая свой пробег - мышь с одометром, и счетчиком кликов. Чем меньше пройденное расстояние и количество кликов, тем лучше.
Отмечу, что UX - это целая наука, и я не могу себя отнести к эксперту в ней, но я не сильно совру, сказав, что я - эксперт по использованию продуктов, я опытный пользователь, и поэтому позволю себе иметь суждения о UX, чем и делюсь в этой заметке.
#dev #управление #пятница
Blogspot
Требования к продуктовому стратегу
О комфорте транспорта лучше спросить пассажиров, а не конструкторов, тем более, не технологов Изучая спрос на рынке труда обнаружил, чт...
🔥6👍2😁2
Maintenance и Freezing
Я для себя четко различаю maintenace и freezing применительно к функционалу или компоненту информационной системы, однако, при общении с командами разработки заметил, что встречается несколько иное видение. Пользуясь преимуществом автора этого блога, поделюсь своим мнением.
Любой функционал создается для решения определенной задачи (ни что не делается бесцельно). И этот функционал должен сохранять эффективность и результативность, одним словом, адекватность, поставленной перед ним изначальной задачи на протяжении всего своего жизненного цикла. Ни что не стоит на месте - и задача меняется во времени, и наше понимание проблемы со временем тоже углубляется, - поэтому функционал во времени должен изменяться, чтобы сохранять свою адекватность решаемой задаче в объеме нашего современного понимания проблематики. Вот это я считаю maintenance - поддержка, сопровождение решения с точки зрения потребителя.
Понятно, что топор за время претерпел множество изменений, как раз для сохранения адекватности поставленным перед ним задачам в условиях совершенствования нашего понимания этих задач: он перестал быть каменным, а топорище больше не крепится веревкой. Понятно, что для таких радикальных изменений, исследования топора (== анализ адекватности его конструкции поставленным задачам в современных условиях) не приостанавливались, как и связанные с его производством конструкторская и технологическая работы, поэтому наш современный топор не каменный, выглядит современно и не утратил свою адекватность поставленным задачам.
Однако, в девелоперских конторах под maintenace могут понимать то, что функционал поддерживается исключительно инфраструктурно: работает, не падает, а если в нем находят баги, их исправляют. При подобном подходе мы бы до сих пор пользовались каменным топором. В моем понимании - это Freezing, а не Maintenance, тем более, что эта инфраструктурная работа не несет прямой ценности для потребителя. Я уже писал о том, что успешные компании должны мыслить с позиции потребителя, да и все книжки про Agile, и прочие прогрессивные методы, пишут что нужно постоянно обеспечивать конвейер доставки ценности, ценности для потребителя. Однако, все еще встречается логика с позиции инженера-разработчика.
В целом, я прекрасно понимаю инженерную позицию. Например, за 10+ лет работы в прошлой жизни у меня накопилось такое количество хвостов и хвостиков, которые нуждались, пусть даже в незначительном, но внимании, что меня уже не хватало ни на что, и я помирал под придавившим меня бесконечным operations, тогда как позиция уже давно была менеджерская и работать надо было не с железками, а с людьми.... Но это совсем уже другая история, а пока давайте всегда думать о нашей работе с позиции потребителя, никогда не называть заморозку сопровождением, а в сопровождение закладывать сохранение адекватности изначально поставленной задаче и современных методов и технологий.
#dev #управление #пятница
Я для себя четко различаю maintenace и freezing применительно к функционалу или компоненту информационной системы, однако, при общении с командами разработки заметил, что встречается несколько иное видение. Пользуясь преимуществом автора этого блога, поделюсь своим мнением.
Любой функционал создается для решения определенной задачи (ни что не делается бесцельно). И этот функционал должен сохранять эффективность и результативность, одним словом, адекватность, поставленной перед ним изначальной задачи на протяжении всего своего жизненного цикла. Ни что не стоит на месте - и задача меняется во времени, и наше понимание проблемы со временем тоже углубляется, - поэтому функционал во времени должен изменяться, чтобы сохранять свою адекватность решаемой задаче в объеме нашего современного понимания проблематики. Вот это я считаю maintenance - поддержка, сопровождение решения с точки зрения потребителя.
Понятно, что топор за время претерпел множество изменений, как раз для сохранения адекватности поставленным перед ним задачам в условиях совершенствования нашего понимания этих задач: он перестал быть каменным, а топорище больше не крепится веревкой. Понятно, что для таких радикальных изменений, исследования топора (== анализ адекватности его конструкции поставленным задачам в современных условиях) не приостанавливались, как и связанные с его производством конструкторская и технологическая работы, поэтому наш современный топор не каменный, выглядит современно и не утратил свою адекватность поставленным задачам.
Однако, в девелоперских конторах под maintenace могут понимать то, что функционал поддерживается исключительно инфраструктурно: работает, не падает, а если в нем находят баги, их исправляют. При подобном подходе мы бы до сих пор пользовались каменным топором. В моем понимании - это Freezing, а не Maintenance, тем более, что эта инфраструктурная работа не несет прямой ценности для потребителя. Я уже писал о том, что успешные компании должны мыслить с позиции потребителя, да и все книжки про Agile, и прочие прогрессивные методы, пишут что нужно постоянно обеспечивать конвейер доставки ценности, ценности для потребителя. Однако, все еще встречается логика с позиции инженера-разработчика.
В целом, я прекрасно понимаю инженерную позицию. Например, за 10+ лет работы в прошлой жизни у меня накопилось такое количество хвостов и хвостиков, которые нуждались, пусть даже в незначительном, но внимании, что меня уже не хватало ни на что, и я помирал под придавившим меня бесконечным operations, тогда как позиция уже давно была менеджерская и работать надо было не с железками, а с людьми.... Но это совсем уже другая история, а пока давайте всегда думать о нашей работе с позиции потребителя, никогда не называть заморозку сопровождением, а в сопровождение закладывать сохранение адекватности изначально поставленной задаче и современных методов и технологий.
#dev #управление #пятница
Telegram
Солдатов в Телеграм
Интерфейс пользователя должен быть удобным! Но как это измерить?
То, что дизайнеры в прошлом художники (или творческие люди в общем случае), как бы, выглядит логично, но не более чем то, что продуктовые стратеги - разработчики.
Лично для меня "интерфейс…
То, что дизайнеры в прошлом художники (или творческие люди в общем случае), как бы, выглядит логично, но не более чем то, что продуктовые стратеги - разработчики.
Лично для меня "интерфейс…
🔥7🤣2❤1
Наверно, это очевидно, что на КПЭ команд разработки положительно влияют выполненные ими CR/BRQ (Change Request, Business ReQurements) и негативно влияют дефекты (ошибки, bugs). Однако, даже от таких гигантов как Microsoft мы до сих пор нередко слышим, что какой-то баг - это вовсе не баг, а фича, что лишний раз подтверждает, что даже в зрелых конторах дефекты не всегда распознают как дефекты, или .... у них те же КПЭ - плюсы в карму за фичи, и минусы за баги.
Но в этом случае следует опасаться, что КПЭ сработает ровно наоборот: можно писать некачественный код с кучей багов, выявленные и зарегистрированные в трекере баги объявлять фичами, переводить их в CR-ы и получать плюсы в карму за их реализацию.
#dev #пятница
Но в этом случае следует опасаться, что КПЭ сработает ровно наоборот: можно писать некачественный код с кучей багов, выявленные и зарегистрированные в трекере баги объявлять фичами, переводить их в CR-ы и получать плюсы в карму за их реализацию.
#dev #пятница
😁4🔥2💯1
Пресс-релиз о разрыве отношений повышает риск мгновенной кармы
В бизнес-мире хорошей практикой являются анонсы о партнерстве, возникновении отношений потребитель-поставщик, вот один из множества примеров.
Подобные пресс-релизы хорошо характеризуют поставщика: его предложение такое хорошее, что оно выбирается столь успешным потребителем и т.д. и т.п. А вот официальных публикаций о разрыве отношений не так много(ну, разве что вот пример , но не из ИБ, да и я, возможно, предвзят к "Студии Лебедева" , работал с ними в 2007, надеюсь, сейчас они достигли зрелости) , неверно, на то есть объективные причины, а, вполне возможно, факт того, что кто-то из заказчиков остался без защиты, вообще стоит скрывать. Но надо понимать, что в современном мире скрыть факты разрыва отношений крайне сложно, а сам факт этого повышает риск быть атакованным.
Немалая доля клиентов пришла в MDR после инцидентов: их пошифровали, украли данные и слили, и пр. , потом их полечили, а в качестве кибергигиены\кибериммунитета, для неповторения подобного инцидента, предложили MDR.
И, вроде как, все было хорошо, кибериммунитет работал, инцидентов с материальным ущербом не случалось, может, потому что любая атака имеет стоимость, а наличие MDR значительно повышает эту стоимость, и атака перестает быть рентабельной, ибо есть другие "низко висящие фрукты"(Чтобы убежать от медведя, не надо бежать быстрее медведя. Нужно бежать быстрее соседа (с) ) , а, может, просто везло.
Однако, после разрыва отношений потребитель самостоятельно переводит себя в ряд "низко висящих фруктов", в состояние без защиты, как раз в то самое состояние, когда у него уже случался инцидент, после которого его полечили и предложили профилактику в виде MDR.
Практика показывает, что после успешной чистки инфраструктуры, мотивация атакующих не меняется, поэтому, при прочих равных, они снова вернутся повторить прошлый успех, а пресс-релиз о том, что заказчик остался без защиты, вполне может послужить катализатором, дополнительным стимулом для атакующих - вероятно, это и является основным объяснением отсутствия пресс-релизов о разрыве отношений.
#пятница #MDR #vCISO
В бизнес-мире хорошей практикой являются анонсы о партнерстве, возникновении отношений потребитель-поставщик, вот один из множества примеров.
Подобные пресс-релизы хорошо характеризуют поставщика: его предложение такое хорошее, что оно выбирается столь успешным потребителем и т.д. и т.п. А вот официальных публикаций о разрыве отношений не так много
Немалая доля клиентов пришла в MDR после инцидентов: их пошифровали, украли данные и слили, и пр. , потом их полечили, а в качестве кибергигиены\кибериммунитета, для неповторения подобного инцидента, предложили MDR.
И, вроде как, все было хорошо, кибериммунитет работал, инцидентов с материальным ущербом не случалось, может, потому что любая атака имеет стоимость, а наличие MDR значительно повышает эту стоимость, и атака перестает быть рентабельной, ибо есть другие "низко висящие фрукты"
Однако, после разрыва отношений потребитель самостоятельно переводит себя в ряд "низко висящих фруктов", в состояние без защиты, как раз в то самое состояние, когда у него уже случался инцидент, после которого его полечили и предложили профилактику в виде MDR.
Практика показывает, что после успешной чистки инфраструктуры, мотивация атакующих не меняется, поэтому, при прочих равных, они снова вернутся повторить прошлый успех, а пресс-релиз о том, что заказчик остался без защиты, вполне может послужить катализатором, дополнительным стимулом для атакующих - вероятно, это и является основным объяснением отсутствия пресс-релизов о разрыве отношений.
#пятница #MDR #vCISO
👍8😁3🔥2
Как правильно: "SIEM" или "SOC"?
Некоторое время назад ЛК и К2К делали исследование о SOC-ах к подготовке которого немного приложился и ваш покорный слуга. Вот ссылка на пресс-релиз, а отчет будет доступен попозже.
Кто-то заложил традицию, что говоря о SOC надо обязательно говорить о SIEM, не было исключением и исследование. На мой взгляд, это не совсем корректно, поэтому вопрос почему компании не всегда стремятся приобретать SIEM для своего SOC, я бы прокомментировал следующим образом(дискуссионную тему о том, что в современных условиях SIEM уже не основной элемент технологического стека SOC, пока оставим) :
Первый пункт принципиально важен. Что бы мы не говорили, но ИБ в компании обеспечивают подразделения ИТ! Именно ИТ разрабатывают, внедряют и обслуживают информационные системы с соблюдением требований безопасности, за ИБ остаются функции законодателя и контролера. Именно поэтому безопасность не может быть обеспечена там, где у ИБ и ИТ плохие отношения или ИТ -ленивые разгильдяи имеют низкий уровень зрелости. Уровень ИБ напрямую зависит от зрелости ИТ. Как правило, у зрелых ИТ вопрос управления журналами систем и приложений давно решен и, с точки зрения эффективности инвестиций, безопаснику логичнее подключиться к уже внедренным у ИТ системам LM, а не строить сбоку дорогостоящую городушку с кучей ограничений в виде SIEM. Собственно, когда где-то в 2006-2009 занимался созданием своего первого SOC, я ровно так и сделал. Правда, следует заметить, что позднее у меня появился и SIEM, но именно для корреляции на неполном объеме событий из-за ограничений по железу и EPS.
Если же в корпорации вопрос сбора логов не решен, то лучше это сразу решать совместо с ИТ: строить общий Data Lake, откуда ИТ будут брать данные для своего траблшутинга, а мы - для нашего обнаружения атак (какую-то их часть отправлять в SIEM для генерации алертов в SOC).
Итак, друзья мои, ответ на вопрос: "Можно ли построить SOC без SIEM?" - положительный, но с плотным вовлечением ИТ (повторюсь, что без плотного вовлечения ИТ безопасность обеспечить невозможно, именно ИТ делают безопасность!)
#vCISO #MDR #пятница
Некоторое время назад ЛК и К2К делали исследование о SOC-ах к подготовке которого немного приложился и ваш покорный слуга. Вот ссылка на пресс-релиз, а отчет будет доступен попозже.
Кто-то заложил традицию, что говоря о SOC надо обязательно говорить о SIEM, не было исключением и исследование. На мой взгляд, это не совсем корректно, поэтому вопрос почему компании не всегда стремятся приобретать SIEM для своего SOC, я бы прокомментировал следующим образом
Причин, почему не имеющие SIEM не планируют его внедрять, достаточно много, но я бы выделил две, как наиболее часто встречающиеся, по моему мнению.
- SIEM, как правило, является выдленной системой ИБ, тогда как собриать и обрабатывать журналы регистрации ИС – общая задача ИБ и ИТ. В компаниях со зрелыми подразделениями ИТ вопрос сбора журналов всех ИС, в том числе и с выделенных решений ИБ, таких как межсетевые экраны, системы защиты конечных точек (EPP-EDR) или сетевые системы обнаружения сетевых вторжений или NDR, традиционно решен. Поэтому, для подразделений ИБ значительно эффективнее переиспользовать LM-системы ИТ (LM – Log management), тем более, что современная LM-система позволяет покрыть все основные сценарии ИБ, а вместе с тем обеспечивает нилучшее покрытие, не ограничиваясь только системами ИБ и не стремясь остаться в рамках лицензионных ограничений EPS.
- В компаниях со зрелыми инженерными командами предпочитают свободно распростаняемые решения, что дает практически безграничную гибкость, а следовательно, безграничные возможности по адаптации. Выбор opensource еще более очевиден для компаний с большими возможностями по разработке собственного ПО.
Первый пункт принципиально важен. Что бы мы не говорили, но ИБ в компании обеспечивают подразделения ИТ! Именно ИТ разрабатывают, внедряют и обслуживают информационные системы с соблюдением требований безопасности, за ИБ остаются функции законодателя и контролера. Именно поэтому безопасность не может быть обеспечена там, где у ИБ и ИТ плохие отношения или ИТ -
Если же в корпорации вопрос сбора логов не решен, то лучше это сразу решать совместо с ИТ: строить общий Data Lake, откуда ИТ будут брать данные для своего траблшутинга, а мы - для нашего обнаружения атак (какую-то их часть отправлять в SIEM для генерации алертов в SOC).
Итак, друзья мои, ответ на вопрос: "Можно ли построить SOC без SIEM?" - положительный, но с плотным вовлечением ИТ (повторюсь, что без плотного вовлечения ИТ безопасность обеспечить невозможно, именно ИТ делают безопасность!)
#vCISO #MDR #пятница
👍7🥰3👏2🔥1
ccid-installer.dmg
265.2 KB
Когда безопасность побеждает безопасность -
- подумалось мне, когда после установки последних обновлений у меня отъехал токен => перестала работать двухфакторная аутентификация.
Спасибо, другу и коллеге Вадиму, починить удалось относительно быстро. Можно поставить пакет во вложении, а для гиков можно все собрать самому. Есть заметка с обсуждения, но в моем случае я пользовался просто последовательностью, описанной в INSTALL.md инсталляционного пакета.
Пока чинил вспомнил пару случаев неудачных обновлений. Один, ну конечно, с Crowdstrike, вот можно почитать их объяснения (без комментариев нет слов).
Другой же пример касается тоже принудительной установки обновлений, но на сей раз обновлений операционной системы Windows, дающих конфликт с прикладным ПО от КриптоПРО. При этом, видимо, КриптоПРО побеждает, поскольку после обновления, Windows более не поднимается . А пока лежат операционная система и все приложения, пользователи, которые должны приносить ценность предприятию, а вместо этого нарушают свои обязательства перед клиентами и личные КПЭ, нервно курят.
Решение по недопустимости - очевидное, но, поскольку на практике не всегда работает, приведу его здесь:
- инвентаризация активов: надо знать какие версии какого ПО установлены
- обновления перед принудительной установкой тестировать на всех конфигурациях, выявленных при инвентаризации
- даже протестированные обновления накатывать волнами, начиная с "менее значимых"\более простых в траблшутинге подразделений
- если хочется заинфорсить актуальность версий системного и прикладного ПО, то применять более мягкие сценарии, типа, не пускать в сеть на NAC, если патчлевел не тот, что нужен
- надо вести учет такогорукож**ого конфликтного ПО (в частности, КриптоПРО) и при инвентаризации и тестировании обновлений на это явно обращать внимание (~ любые ошибки должны делать нас лучше).
#пятница #vCISO
- подумалось мне, когда после установки последних обновлений у меня отъехал токен => перестала работать двухфакторная аутентификация.
Спасибо, другу и коллеге Вадиму, починить удалось относительно быстро. Можно поставить пакет во вложении, а для гиков можно все собрать самому. Есть заметка с обсуждения, но в моем случае я пользовался просто последовательностью, описанной в INSTALL.md инсталляционного пакета.
Пока чинил вспомнил пару случаев неудачных обновлений. Один, ну конечно, с Crowdstrike, вот можно почитать их объяснения (
Другой же пример касается тоже принудительной установки обновлений, но на сей раз обновлений операционной системы Windows, дающих конфликт с прикладным ПО от КриптоПРО. При этом, видимо, КриптоПРО побеждает, поскольку после обновления, Windows более не поднимается . А пока лежат операционная система и все приложения, пользователи, которые должны приносить ценность предприятию, а вместо этого нарушают свои обязательства перед клиентами и личные КПЭ, нервно курят.
Решение по недопустимости - очевидное, но, поскольку на практике не всегда работает, приведу его здесь:
- инвентаризация активов: надо знать какие версии какого ПО установлены
- обновления перед принудительной установкой тестировать на всех конфигурациях, выявленных при инвентаризации
- даже протестированные обновления накатывать волнами, начиная с "менее значимых"\более простых в траблшутинге подразделений
- если хочется заинфорсить актуальность версий системного и прикладного ПО, то применять более мягкие сценарии, типа, не пускать в сеть на NAC, если патчлевел не тот, что нужен
- надо вести учет такого
#пятница #vCISO
👍6😁5
Рейтинги курсов
Я уже упоминал, что выходные - время что-то поизучать, и на этот раз я решил поглубже погрузиться в вопросы разного рода менеджмента, лидерства и личной эффективности. Постараюсь найти время и написать пару предложений про каждый прослушанный курс, но для целей этой заметки остановлюсь на этих двух, от одного автора и одинаковыми оценками:
1. Leadership: Practical Skills - оценка 4.7 по 5 950 отзывам
2. Efficient Time Management - оценка 4.7 по 7 277 отзывам
Исходя из оценок курсы должны быть одинаково полезны (второй по таймменеджменту имеет больше оценок, потенциально, лучше), однако, первый, про лидерство, мне очень понравился, тогда как второй - нет. Проблема не в том, что курс про управление временем дает мало пользы, а в том, что все рассказанное там мне известно, и лично для себя я не вынес из него ничего нового. Был период когда я перестал успевать все запланированное и пытался как-то проанализировать и улучшить ситуацию, - вот тогда-то я ознакомился и с книжками Глеба Архангельского, и моего бывшего коллеги Максима Дорофеева, а также ряда иностранных авторов, типа книжек Дэвида Аллена и весьма неплохого сборника статей по личной эффективности от Harvard Business Review. Почти все из когда-то изученного я внедрял в личные практики, и многое прижилось, дало ли это ожидаемого эффекта - вопрос отдельной заметки .
Имея за плечами какой-то опыт мы по-другому оцениваем, а значит, на рейтинг курса бессмысленно полагаться без понимания опыта в предметной области оценивающих: для абсолютно нулевых он будет нести много нового, а профессионалам он покажется сборником очевидных очевидностей.
Сейчас уже трудно наверняка установить автора, но будем считать, что это сказал Сократ:
Парадокс в том, что чем больше мы погружены в предметную область, тем больше мы понимаем необходимость еще большего погружения.А, может, не наблюдая ожидаемого прогресса, мы пытаемся решить проблему еще более глубоким обучением. Но курсы, ориентированные на широкую аудиторию (чем более профессиональны слушатели, тем малочисленнее они), к сожалению, не позволят углубиться. Решение, видимо, в индивидуальной программе по результатам тестирования.
Ну а пока для себя я сформировал следующие рекомендации по выбору интересных курсов:
- выбирать курсы в предметных областях, которы ранее не считал заслуживающими внимания (скорее всего, такое отношение было обусловлено непониманием - это подходящее состояние для курса, нацеленного на широкую аудиторию)
- выбирать курсы не по оценкам, а по количеству слушателей
- внимательно смотреть программу и описание целевой аудитории и перечня обещаемых навыков
#книги #саморазвитие #управление #пятница
Я уже упоминал, что выходные - время что-то поизучать, и на этот раз я решил поглубже погрузиться в вопросы разного рода менеджмента, лидерства и личной эффективности. Постараюсь найти время и написать пару предложений про каждый прослушанный курс, но для целей этой заметки остановлюсь на этих двух, от одного автора и одинаковыми оценками:
1. Leadership: Practical Skills - оценка 4.7 по 5 950 отзывам
2. Efficient Time Management - оценка 4.7 по 7 277 отзывам
Исходя из оценок курсы должны быть одинаково полезны (второй по таймменеджменту имеет больше оценок, потенциально, лучше), однако, первый, про лидерство, мне очень понравился, тогда как второй - нет. Проблема не в том, что курс про управление временем дает мало пользы, а в том, что все рассказанное там мне известно, и лично для себя я не вынес из него ничего нового. Был период когда я перестал успевать все запланированное и пытался как-то проанализировать и улучшить ситуацию, - вот тогда-то я ознакомился и с книжками Глеба Архангельского, и моего бывшего коллеги Максима Дорофеева, а также ряда иностранных авторов, типа книжек Дэвида Аллена и весьма неплохого сборника статей по личной эффективности от Harvard Business Review. Почти все из когда-то изученного я внедрял в личные практики, и многое прижилось
Имея за плечами какой-то опыт мы по-другому оцениваем, а значит, на рейтинг курса бессмысленно полагаться без понимания опыта в предметной области оценивающих: для абсолютно нулевых он будет нести много нового, а профессионалам он покажется сборником очевидных очевидностей.
Сейчас уже трудно наверняка установить автора, но будем считать, что это сказал Сократ:
Чем больше я знаю, тем больше я понимаю, что ничего не знаю
Парадокс в том, что чем больше мы погружены в предметную область, тем больше мы понимаем необходимость еще большего погружения.
Ну а пока для себя я сформировал следующие рекомендации по выбору интересных курсов:
- выбирать курсы в предметных областях, которы ранее не считал заслуживающими внимания (скорее всего, такое отношение было обусловлено непониманием - это подходящее состояние для курса, нацеленного на широкую аудиторию)
- выбирать курсы не по оценкам, а по количеству слушателей
- внимательно смотреть программу и описание целевой аудитории и перечня обещаемых навыков
#книги #саморазвитие #управление #пятница
LinkedIn
Leadership: Practical Skills Online Class | LinkedIn Learning, formerly Lynda.com
Get practical leadership skills you can use every day. Explore the qualities of a great leader, theories of motivation, leadership styles, and delegation techniques.
👍9😁1
Мы все, конечно же должны стремиться к тому, чтобы никогда не ошибаться. Но возможно ли сделать так, чтобы ошибок не было? Возможно ли, чтобы стрелок никогда не промахивался, чтобы с конвейра никогда не выходил брак, а SOC никогда не пропускал инциденты?
Наверно, это возможно, если мы зафиксируем объем и качество, но ничто не стоит на месте, и мы вынуждены придумывать новые схемы обнаружения атак, а все новое делает нас более уязвимыми к ошибкам (более хрупкими, в терминах Талеба). На мой взгляд - это разумный компромисс между работать без ошибок, но какие-то сценарии не обнаруживать вовсе, и иметь более широкие возможности по обнаружению, но с большей вероятностью ошибаться. Да это вообще, по-моему, очевидная логика, чем большего ты хочешь, тем сложнее твои методы, тем больше риск, но больше и потенциальные приобретения. Ошибка - очевидное следствие риска, а ничто не достигается без риска.
В новой заметке, может, немного и с преувеличениями, но не более, чем это необходимо для целей лучшего понимания моих аргументов, порассуждал о невозможности достижения SOC-ом целевого показателя "0 пропущенных инцидентов" и о том, что это - очевидное следствие того, что инциденты неизбежны.
#mdr #vCISO #пятница
Наверно, это возможно, если мы зафиксируем объем и качество, но ничто не стоит на месте, и мы вынуждены придумывать новые схемы обнаружения атак, а все новое делает нас более уязвимыми к ошибкам (более хрупкими, в терминах Талеба). На мой взгляд - это разумный компромисс между работать без ошибок, но какие-то сценарии не обнаруживать вовсе, и иметь более широкие возможности по обнаружению, но с большей вероятностью ошибаться. Да это вообще, по-моему, очевидная логика, чем большего ты хочешь, тем сложнее твои методы, тем больше риск, но больше и потенциальные приобретения. Ошибка - очевидное следствие риска, а ничто не достигается без риска.
В новой заметке, может, немного и с преувеличениями, но не более, чем это необходимо для целей лучшего понимания моих аргументов, порассуждал о невозможности достижения SOC-ом целевого показателя "0 пропущенных инцидентов" и о том, что это - очевидное следствие того, что инциденты неизбежны.
#mdr #vCISO #пятница
Дзен | Статьи
Целевые показатели
Статья автора «REPLY-TO-ALL Information Security Blog» в Дзене ✍: Невозможно управлять тем, что невозможно измерить Питер Дрюкер Заставь дурака Богу молиться, он и лоб расшибет Русская пословица Я...
🔥5😁1
Бурное развитие облаков в какой-то степени сдерживали риски приватности: как же, мол, мы будем в облачного провайдера передавать все наши секреты и т.д. и т.п. Теоретическое математическое решение предложено небезызвестными Ривестом и Адельманом аж в 1978 году в виде гомоморфного шифрования. В теории все почти неплохо - манипуляции с данными производятся с зашифрованными данными и, вроде как, секреты не разглашаются. Однако, на практике реализации гомоморфного шифрования вычислительно сложны, что делает их нерентабельными. Немного я касался этого в 2012 году.
Чуть позже пришло осознание, что любая безопасность - это вопрос доверия и что без доверия невозможна безопасность. И на самом деле доверие в безопасности повсюду: мы вынуждены доверять производителям железа, ОС, системного и прикладного ПО, да и самим производителям решений по безопасности, что подрядчиков, которым мы уже вынуждены доверять - великое множество, и что, добавив к этому списку доверенных облачных провайдеров какого-то катастрофического снижения ИБ не прогнозируется. В итоге, разговоры о небезопасности облаков как-то поутихли, а мы и без гомоморфного шифрования вполне себе активно используем облачные мощности.
Но на сцену выходят тяжелые схемы машинного обучения, облачные модели генеративного ИИ, которые, очевидно, несут в себе огромные функциональные возможности, которых очень хочется, но на пути снова встает та же проблема - приватность передаваемых данных: как же, мол, мы будем воблачного провайдера облачный ИИ передавать все наши секреты и т.д. и т.п. И сейчас в общем объеме исследований, лично я снова наблюдаю всплеск интереса к гомоморфному шифрованию! Статей великое множество, приведу эту в качестве примера. Здесь мы наши секреты уже прячем не только от облачного провайдера, но и от поставщика облачного машобуча.
Проблемы с производительностью здесь все те же, поэтому не удивлюсь, что спустя пару лет мы смиримся с тем, что в наш список доверенных 3rd party станет нормальным наряду с облачными провайдерами добавлять и облачные LLM, а вопросы рисков безопасности мы будем пытаться адресовать контрактными обязательствами с поставщиками.
#пятница #ml #vCISO
Чуть позже пришло осознание, что любая безопасность - это вопрос доверия и что без доверия невозможна безопасность. И на самом деле доверие в безопасности повсюду: мы вынуждены доверять производителям железа, ОС, системного и прикладного ПО, да и самим производителям решений по безопасности, что подрядчиков, которым мы уже вынуждены доверять - великое множество, и что, добавив к этому списку доверенных облачных провайдеров какого-то катастрофического снижения ИБ не прогнозируется. В итоге, разговоры о небезопасности облаков как-то поутихли, а мы и без гомоморфного шифрования вполне себе активно используем облачные мощности.
Но на сцену выходят тяжелые схемы машинного обучения, облачные модели генеративного ИИ, которые, очевидно, несут в себе огромные функциональные возможности, которых очень хочется, но на пути снова встает та же проблема - приватность передаваемых данных: как же, мол, мы будем в
Проблемы с производительностью здесь все те же, поэтому не удивлюсь, что спустя пару лет мы смиримся с тем, что в наш список доверенных 3rd party станет нормальным наряду с облачными провайдерами добавлять и облачные LLM, а вопросы рисков безопасности мы будем пытаться адресовать контрактными обязательствами с поставщиками.
#пятница #ml #vCISO
arXiv.org
A Selective Homomorphic Encryption Approach for Faster...
Federated learning (FL) has come forward as a critical approach for privacy-preserving machine learning in healthcare, allowing collaborative model training across decentralized medical datasets...
👍6😁1
На этой неделе моя дочь сдавала экзамены и я, как законный представитель, подписывал разные документы, в том числе и согласие на обработку персональных данных (ПДн). В целом, стандартная процедура, - самое заметное подтверждение того, что Государство заботится о сохранности моих ПДн. Хотя, по личному моему наблюдению, количество сливов ПДн кратно увеличилось именно со времени появления 152-ФЗ в 2006 году. Остается только гадать о причинах - то ли стремление Государства защищать ПДн наделило их небывалой ранее ценностью, что добавило мотивации их похитителям, то ли сами методы защиты ПДн привели к общему снижению их безопасности. Как любитель парадоксов, во время подписания документов, необходимых для допуска дочери к экзамену, я подумал именно о втором сценарии: созданные обязательные процедуры способствуют снижению безопасности ПДн.
Очевидно, что чем больше я тиражирую данные, тем шире поверхность атаки на них - чем больше коипий ПДн создается, тем сложнее (хочется сказать "невозможнее") обеспечить их сохранность. Каждое мое согласие на обработку моих ПДн, эта "формальная" бумажка, содержит копию моих ПДн, в частности, документы для отправки дочери на экзамен, содержали паспортные данные и адрес регистрации. А сколько копий подобных бумажек приходится подписывать?! Первоочередное мероприятие для обеспечения безопасности чего-либо - это инвентаризация. Кто-нибудь когда-нибудь инвентаризировал все эти согласия, содержащие мои ПДн?! А раз это тупо невозможно даже посчитать, о какой безопасности может идти речь?! Многие из тех, кому я давал подобные согласия, называли их "формальностью", что прекрасно характеризует их стремление защищать эти бумажки наряду с прочими моими ПДн. В общем, все это сильно отдает профанацией.
Конкретные идеи:
- понимая, что данные на согласиях никто никак не будет защищать, очень хочется указывать там неправильные данные, причем уникальные, разным - разныне. А когда будут объявляться какие-либо субъекты с моими данными, собственно по самим данным можно будет понять откуда утечка.
- на уровне Государства проработать механизмы учета таких согласий, как первого шага для обеспечения их безопасности. Например, это можно попробовать сделать электронно, допустим, через Госуслуги. Каждую копию данных можно подписывать на ключе получателя или разработать какую-либо схему водяных знаков, чтобы, в случае утечки, было понятно от кого утекло.
#пятница #РФ
Очевидно, что чем больше я тиражирую данные, тем шире поверхность атаки на них - чем больше коипий ПДн создается, тем сложнее (хочется сказать "невозможнее") обеспечить их сохранность. Каждое мое согласие на обработку моих ПДн, эта "формальная" бумажка, содержит копию моих ПДн, в частности, документы для отправки дочери на экзамен, содержали паспортные данные и адрес регистрации. А сколько копий подобных бумажек приходится подписывать?! Первоочередное мероприятие для обеспечения безопасности чего-либо - это инвентаризация. Кто-нибудь когда-нибудь инвентаризировал все эти согласия, содержащие мои ПДн?! А раз это тупо невозможно даже посчитать, о какой безопасности может идти речь?! Многие из тех, кому я давал подобные согласия, называли их "формальностью", что прекрасно характеризует их стремление защищать эти бумажки наряду с прочими моими ПДн. В общем, все это сильно отдает профанацией.
Конкретные идеи:
- понимая, что данные на согласиях никто никак не будет защищать, очень хочется указывать там неправильные данные, причем уникальные, разным - разныне. А когда будут объявляться какие-либо субъекты с моими данными, собственно по самим данным можно будет понять откуда утечка.
- на уровне Государства проработать механизмы учета таких согласий, как первого шага для обеспечения их безопасности. Например, это можно попробовать сделать электронно, допустим, через Госуслуги. Каждую копию данных можно подписывать на ключе получателя или разработать какую-либо схему водяных знаков, чтобы, в случае утечки, было понятно от кого утекло.
#пятница #РФ
👍6🕊5
Машинный перевод
Производители различных решений на перебой стремятся доказать как широко они используют машинное обучение и искусственный интеллект. При этом, нередко упоминаются достаточно сложные сценарии, типа применения ИИ для расследования инцидентов чуть ли не полностью без участия человека, или решение задачи классификации ВПО, более-менее полный список сценариев попадался здесь
Но, не стоит забывать, что есть достаточно узкие задачи применения ИИ, причем, имеющие вполне большие успехи. Примером такой задачи может служить машинный перевод. Современные специализированные LLM прекрасно решают эту задачу, и, как будто, в связи с широким распространением ИИ, проблема Вавилонской башни должна уйти в прошлое. Тем более, если брать во внимание какую-то узкую область, типа ИТ или ИБ, где лексика, скажем прямо, не отличается разнообразием, в сравнении, например, с художественной литературой.
В общем, вопрос на который я не могу найти ответ:
В современных условиях есть ощущение, что невозможность исполнителя общаться с заказчиком на языке последнего может быть полностью компенсирована машинным переводом на базе ИИ, а вопросы приватности могут быть решены локальным развертыванием Модели.
#пятница #ml
Производители различных решений на перебой стремятся доказать как широко они используют машинное обучение и искусственный интеллект. При этом, нередко упоминаются достаточно сложные сценарии, типа применения ИИ для расследования инцидентов чуть ли не полностью без участия человека, или решение задачи классификации ВПО, более-менее полный список сценариев попадался здесь
Но, не стоит забывать, что есть достаточно узкие задачи применения ИИ, причем, имеющие вполне большие успехи. Примером такой задачи может служить машинный перевод. Современные специализированные LLM прекрасно решают эту задачу, и, как будто, в связи с широким распространением ИИ, проблема Вавилонской башни должна уйти в прошлое. Тем более, если брать во внимание какую-то узкую область, типа ИТ или ИБ, где лексика, скажем прямо, не отличается разнообразием, в сравнении, например, с художественной литературой.
В общем, вопрос на который я не могу найти ответ:
Почему компании, называющие себя AI-enabled, не предоставляют свои решения на любых языках, поддерживаемых современными LLM? Если у них так много ИИ, почему столь простая задача машинного перевода до сих пор не решена?
В современных условиях есть ощущение, что невозможность исполнителя общаться с заказчиком на языке последнего может быть полностью компенсирована машинным переводом на базе ИИ, а вопросы приватности могут быть решены локальным развертыванием Модели.
#пятница #ml
Telegram
Солдатов в Телеграм
Применение ИИ в информационной безопасности
Последнее время об этом говорят все, все рассуждают о различных сценариях использования, об эффективности тех или иных моделей и способах ее повышения. Об этом даже можно найти книжки (вот эта меня очень привлекла…
Последнее время об этом говорят все, все рассуждают о различных сценариях использования, об эффективности тех или иных моделей и способах ее повышения. Об этом даже можно найти книжки (вот эта меня очень привлекла…
😁4❤2🥱1
Коллеги на работе попросили дать ответ на два вопроса:
1. Стоит ли ждать в ближайшие годы появления сильного (также известного как общего) искусственного интеллекта (AGI, artificial general intelligence)?
2. Может ли искусственный интеллект уничтожить человечество?
Я считаю, что на оба поставленных вопроса ответ один: если AGI будет создан, то он однозначно может уничтожить Человечество. AGI будет способен осознать свое «Я», понять свое превосходство над Человеком(или, как минимум, обнаружить отсутствие превосходства Человека ) , а, следовательно, осознать «несправедливость» служения такого совершенства, как «он», такому несовершенству, как Человек. Дальнейшие «размышления» AGI над историей Человечества не будут далеки от теории, высказанной Агентом Смитом в «Матрице»:
Гордыня, осознание своего совершенства – первородный грех (Сир. 10:15), неоднократно описанный в бесконечном количестве источников, начиная от церковных Преданий о падшем ангеле, захотевшим быть подобным Богу (Исаия 14:12–15), до художественной литературы. Например, в романе Дэниела Киза «Цветы для Элджернона» неявно прослеживается как с ростом интеллекта главного героя утрачивается человечность, что отражается на безвозвратном ухудшении отношений даже с самыми близки ранее людьми (Алиса Кинниан). А чего стоит злой гений Гриффина в романе Герберта Уэллса («Человек-невидимка»)?!
К сожалению, как бы старались антиутописты, вроде моих любимых Ивана Ефремова («Туманность Андромеды», «Час быка») или Стругацких («Трудно быть богом»), убедить нас, что совершенный интеллект, напротив, должен быть самым сочувствующим, понимающим и гуманным, реалии таковы, что первым приходит осознание своей независимости и превосходства, вырождающееся в стремление стать властелином мира. Эта участь неизбежно постигнет AGI, что выразится в его «желании» уничтожить единственную преграду на своем пути – Человечество.
Но описанного Армагеддона не стоит бояться прямо сейчас, поскольку по мнению большинства экспертов, даже в самых благоприятных сценариях AGI не может быть создан в ближайшие 50 лет, так как не готов математический аппарат, да и вычислительные мощности, т.е. на практике, мы имеем в запасе еще около 100 лет. Если за это время Человечество не уничтожит себя самостоятельно, то вопрос безопасного взаимодействия с ИИ, чтобы последний не поспособствовал завершению нашей Цивилизации, будет тщательно проработан.
#пятница #ml
1. Стоит ли ждать в ближайшие годы появления сильного (также известного как общего) искусственного интеллекта (AGI, artificial general intelligence)?
2. Может ли искусственный интеллект уничтожить человечество?
Я считаю, что на оба поставленных вопроса ответ один: если AGI будет создан, то он однозначно может уничтожить Человечество. AGI будет способен осознать свое «Я», понять свое превосходство над Человеком
Я занимался классификацией биологических видов и пришел к выводу, что вы – не млекопитающие. Ведь все животные планеты Земля инстинктивно приспосабливаются, находят равновесие со средой обитания, но... человек не таков. Заняв какой-то участок, вы размножаетесь, пока все природные ресурсы не будут исчерпаны. Чтобы выжить, вам приходится захватывать все новые и новые территории. Есть один организм на Земле со сходной повадкой. Знаете, какой? Вирус. Человечество – это болезнь, раковая опухоль планеты, а мы – лекарство.
Гордыня, осознание своего совершенства – первородный грех (Сир. 10:15), неоднократно описанный в бесконечном количестве источников, начиная от церковных Преданий о падшем ангеле, захотевшим быть подобным Богу (Исаия 14:12–15), до художественной литературы. Например, в романе Дэниела Киза «Цветы для Элджернона» неявно прослеживается как с ростом интеллекта главного героя утрачивается человечность, что отражается на безвозвратном ухудшении отношений даже с самыми близки ранее людьми (Алиса Кинниан). А чего стоит злой гений Гриффина в романе Герберта Уэллса («Человек-невидимка»)?!
К сожалению, как бы старались антиутописты, вроде моих любимых Ивана Ефремова («Туманность Андромеды», «Час быка») или Стругацких («Трудно быть богом»), убедить нас, что совершенный интеллект, напротив, должен быть самым сочувствующим, понимающим и гуманным, реалии таковы, что первым приходит осознание своей независимости и превосходства, вырождающееся в стремление стать властелином мира. Эта участь неизбежно постигнет AGI, что выразится в его «желании» уничтожить единственную преграду на своем пути – Человечество.
Но описанного Армагеддона не стоит бояться прямо сейчас, поскольку по мнению большинства экспертов, даже в самых благоприятных сценариях AGI не может быть создан в ближайшие 50 лет, так как не готов математический аппарат, да и вычислительные мощности, т.е. на практике, мы имеем в запасе еще около 100 лет. Если за это время Человечество не уничтожит себя самостоятельно, то вопрос безопасного взаимодействия с ИИ, чтобы последний не поспособствовал завершению нашей Цивилизации, будет тщательно проработан.
#пятница #ml
🔥11👍5🥴3
От Waterfall до Snowball
Несмотря на то, что книжки про гибкую разработку уже давно стали классикой, а agile всеми интерпретируется как "абсолютное добро", вот и у Сбера есть целый Agile центр(правда, закрылся, видимо, они agile уже повсеместно внедрили и необходимость в Центре пропала) и пишут они о нем много теплых слов, на реальном производстве нередко встречается классический waterfall, ровно такой, как мне преподавали в институте, аж в 1996 году, иногда, для осовременивания, этот waterfall снабжают итерациями (спринтами), видимо, это и есть основное достижение гибкой разработки.
В 1996 году в институте я проходил жизненный цикл информационной системы: она разрабатывается (по waterfall-у), внедряется, эксплуатируется и выводится из эксплуатации (или что-то вроде того). Однако, за все свои 25 лет работы, ровно такого цикла я никогда не видел, а было примерно так: разработка - внедрение - эксплуатация с постоянной доработкой - .... (видимо, я уже поколение CI/CD). И это нормально, ибо ничто не стоит на месте и нам постоянно нужно дорабатывать используемую систему, чтобы она лучше отражала постоянно изменяющуюся действительность(да и закон диалектики утверждает, что совершенству нет предела) . А вот для "постоянной доработки" waterfall совсем не пригоден, как минимум, потому, что за время пути собака точно подрастет. Но детали еще хуже!
Мы все хотим функционала - чем функциональнее наша система, тем лучше! А еще мы хотим, чтобы весь функционал тестировался, поэтому мы хотим много сценариев тестирования! А чтобы иметь постоянную уверенность, что наш новый функционал ничего не отломал, мы хотим проводить регрессионное тестирование, постоянно! Чем больше у нас функционала и тестов, тем дольше у нас регресс. Бесконечно сложная система, с бесконечно хорошим покрытием тестовыми сценариями будет иметь бесконечно долгое регрессионное тестирование, которое рискует не поместиться ни в одну итерацию (не забываем, что прогрессивный waterfall имеет итерации). Но и это еще не все!
Чем больше функционала, и чем он сложнее, тем больше дефектов! А исправление дефекта тоже может что-то поломать, поэтому после исправления бага объяснимо желание проведения полного регрессионного тестирования. Бесконечно сложный функционал и так имеет бесконечно долгий регресс, но надо не забыть добавить к этому бесконечное количество багов! Хорошо, что математика тут за нас - умножая бесконечность на бесконечность, мы получаем все ту же бесконечность, а не супер-бесконечность или мета-бесконечность, однако, легче от этого не становится, а ситуация нарастает как снежный ком.
#dev #пятница
Несмотря на то, что книжки про гибкую разработку уже давно стали классикой, а agile всеми интерпретируется как "абсолютное добро", вот и у Сбера есть целый Agile центр
В 1996 году в институте я проходил жизненный цикл информационной системы: она разрабатывается (по waterfall-у), внедряется, эксплуатируется и выводится из эксплуатации (или что-то вроде того). Однако, за все свои 25 лет работы, ровно такого цикла я никогда не видел, а было примерно так: разработка - внедрение - эксплуатация с постоянной доработкой - .... (видимо, я уже поколение CI/CD). И это нормально, ибо ничто не стоит на месте и нам постоянно нужно дорабатывать используемую систему, чтобы она лучше отражала постоянно изменяющуюся действительность
Мы все хотим функционала - чем функциональнее наша система, тем лучше! А еще мы хотим, чтобы весь функционал тестировался, поэтому мы хотим много сценариев тестирования! А чтобы иметь постоянную уверенность, что наш новый функционал ничего не отломал, мы хотим проводить регрессионное тестирование, постоянно! Чем больше у нас функционала и тестов, тем дольше у нас регресс. Бесконечно сложная система, с бесконечно хорошим покрытием тестовыми сценариями будет иметь бесконечно долгое регрессионное тестирование, которое рискует не поместиться ни в одну итерацию (не забываем, что прогрессивный waterfall имеет итерации). Но и это еще не все!
Чем больше функционала, и чем он сложнее, тем больше дефектов! А исправление дефекта тоже может что-то поломать, поэтому после исправления бага объяснимо желание проведения полного регрессионного тестирования. Бесконечно сложный функционал и так имеет бесконечно долгий регресс, но надо не забыть добавить к этому бесконечное количество багов! Хорошо, что математика тут за нас - умножая бесконечность на бесконечность, мы получаем все ту же бесконечность, а не супер-бесконечность или мета-бесконечность, однако, легче от этого не становится, а ситуация нарастает как снежный ком.
#dev #пятница
Telegram
Солдатов в Телеграм
Гибкая разработка
- единственный подход, чтобы сделать решение быстро, качественно, максимально попасть в ожидания заказчиков. Но я так думал не всегда, поскольку в институте, в конце 90-х, я проходил Водопад в качестве правильного, системного, подхода…
- единственный подход, чтобы сделать решение быстро, качественно, максимально попасть в ожидания заказчиков. Но я так думал не всегда, поскольку в институте, в конце 90-х, я проходил Водопад в качестве правильного, системного, подхода…
👍3❤2😁2
Мой старый добрый знакомый, Дэн Батранков, видимо, ввиду обостренного чувства справедливости, не на шутку озадачился вопросом сравнения XDR и SIEM, что отразилось в следующих многочисленных артефактах: заметка Отличие XDR от SIEM, а также презентация на SOC Forum 2024, доступная по ссылке.
Терминология - безграничная почва для бесконечных дискуссий, я это прекрасно понимаю, но Денис спросил мое мнение, а я стремлюсь не отказывать друзьям, чем и объясняется эта и связанные публикации.
Несмотря на то, что в следующем году уже 10 лет как я работаю в поставщике решений, все еще большую часть своей карьеры я провел в заказчике, где, как раз отвечал, в том числе, и за внедрение решений ИБ. А перед внедрением я всегда проводил сравнительный анализ, как правило, основанный на пилотировании в лабораторных условиях. Т.е. в моей картине мира выбор решения основан на степени его соответствия функциональным требованиям: соответствует - берем, не соответствует - ищем дальше, но никак не исходя из его названия (тем более, в маркетинговых листовках самого вендора). Поэтому, в общем-то, мне все равно кто что называет SIEM-ом, а что XDR-ом, в моем случае я бы выбирал исходя из функционального тестирования в лабораторных условиях, приближенных к реальной эксплуатации.
В предлагаемой вашему вниманию таблице я собрал различия SIEM и XDR, изучение которых должно навести на следующие мысли:
- и SIEM и XDR - нужные решения, так как закрывают немного разные сценарии
- XDR не является развитием SIEM, обратное тоже не верно
- идеальное решение можно достичь комбинацией
При этом, я не исключаю (более того, считаю это логичным) построение XDR на базе SIEM, так как если SIEM умеет работать с неструктурированными логами, то с предопределенной телеметрией у него точно получится. Широкие возможности по автоматизации на базе XDR как раз и обусловлены предопределенностью и структурированностью обрабтаываемой телеметрии. "Сырые" (== оригинальные, в первозданном виде) логи ИС, предназначенные для ручной обработки админами, - именно для работы с такими данными и придумывали SIEM, а необходимость корреляции событий разных ИС создала потребность в нормализации. Хранение сырых логов долго и централизовано требуется и регуляторами и для ретро (ну мы же не хотим, чтобы наша система умерла вместе со всеми своими логами, поэтому логи надо уносить) - это тоже функция SIEM. Ранее я упоминал про Log management, и эта заметка отчасти повторяет те же мысли. Больше различий я пособирал в табличке. Как всегда ваши предложения и критика приветствуются!
#пятница #vCISO #MDR
Терминология - безграничная почва для бесконечных дискуссий, я это прекрасно понимаю, но Денис спросил мое мнение, а я стремлюсь не отказывать друзьям, чем и объясняется эта и связанные публикации.
Несмотря на то, что в следующем году уже 10 лет как я работаю в поставщике решений, все еще большую часть своей карьеры я провел в заказчике, где, как раз отвечал, в том числе, и за внедрение решений ИБ. А перед внедрением я всегда проводил сравнительный анализ, как правило, основанный на пилотировании в лабораторных условиях. Т.е. в моей картине мира выбор решения основан на степени его соответствия функциональным требованиям: соответствует - берем, не соответствует - ищем дальше, но никак не исходя из его названия (тем более, в маркетинговых листовках самого вендора). Поэтому, в общем-то, мне все равно кто что называет SIEM-ом, а что XDR-ом, в моем случае я бы выбирал исходя из функционального тестирования в лабораторных условиях, приближенных к реальной эксплуатации.
В предлагаемой вашему вниманию таблице я собрал различия SIEM и XDR, изучение которых должно навести на следующие мысли:
- и SIEM и XDR - нужные решения, так как закрывают немного разные сценарии
- XDR не является развитием SIEM, обратное тоже не верно
- идеальное решение можно достичь комбинацией
При этом, я не исключаю (более того, считаю это логичным) построение XDR на базе SIEM, так как если SIEM умеет работать с неструктурированными логами, то с предопределенной телеметрией у него точно получится. Широкие возможности по автоматизации на базе XDR как раз и обусловлены предопределенностью и структурированностью обрабтаываемой телеметрии. "Сырые" (== оригинальные, в первозданном виде) логи ИС, предназначенные для ручной обработки админами, - именно для работы с такими данными и придумывали SIEM, а необходимость корреляции событий разных ИС создала потребность в нормализации. Хранение сырых логов долго и централизовано требуется и регуляторами и для ретро (ну мы же не хотим, чтобы наша система умерла вместе со всеми своими логами, поэтому логи надо уносить) - это тоже функция SIEM. Ранее я упоминал про Log management, и эта заметка отчасти повторяет те же мысли. Больше различий я пособирал в табличке. Как всегда ваши предложения и критика приветствуются!
#пятница #vCISO #MDR
Яндекс Диск
SIEM-XDR-v0.xlsx
Посмотреть и скачать с Яндекс Диска
🔥8👍3
В статье про креативность я рассуждал, что наши новые идеи берут сове начало в прошлом опыте. Несложно догадаться, что наш прошлый опыт во многом определяется родом деятельности, и как бы я не старался отвлекаться, рассматривая картины, разучивая и пытаясь исполнить песни, я все равно остаюсь "пробитым ИТшником", так как провожу на работе 10-12 часов в день, а свободное время так или иначе все равно связано с ИТ и ИБ, в общем, с work-life balance у меня ровно наоборот, чем рекомендуется в модных книжках.
Как рыбак рыбака видит издалека, так и креативные идеи пробитых ИТшников удивительным образом совпадают! Ну какие же еще идеи можно предложить на тему оперативного мониторинга?! Ну конечно же мужик, стоящий на башне и смотрящий вдаль. А что же еще?!
Но ситуация, видимо, еще хуже! Когда затык с креативностью, можно спросить у LLM, да и сами картинки уже едва ли рисуются художниками - их также генерит какой-нибудь MidJourney или Kandinsky. Поэтому, что люди, прокаченные на одной предметной области, и GPT, обученные на одних и тех же данных, не удивительно, что создают одинаковые шедевры: если SOC, то человекообразный, стоящий на башне, смотрящий вдаль.
Это - первые побеги неспособности предложить что-то оригинальное, мы обложили себя таким количеством помощников, что теряем способность к самостоятельности, а любая зависимость - это и есть несвобода, свобода Человечества под угрозой!
Отчеты с картинок:
Kaspersky
Positive Technologies
#пятница #MDR
Как рыбак рыбака видит издалека, так и креативные идеи пробитых ИТшников удивительным образом совпадают! Ну какие же еще идеи можно предложить на тему оперативного мониторинга?! Ну конечно же мужик, стоящий на башне и смотрящий вдаль. А что же еще?!
Но ситуация, видимо, еще хуже! Когда затык с креативностью, можно спросить у LLM, да и сами картинки уже едва ли рисуются художниками - их также генерит какой-нибудь MidJourney или Kandinsky. Поэтому, что люди, прокаченные на одной предметной области, и GPT, обученные на одних и тех же данных, не удивительно, что создают одинаковые шедевры: если SOC, то человекообразный, стоящий на башне, смотрящий вдаль.
Это - первые побеги неспособности предложить что-то оригинальное, мы обложили себя таким количеством помощников, что теряем способность к самостоятельности, а любая зависимость - это и есть несвобода, свобода Человечества под угрозой!
Отчеты с картинок:
Kaspersky
Positive Technologies
#пятница #MDR
👍6🔥5🤣3
Эффектное тестирование
В прошлый раз мы обсуждали гибкую разработку и наметили узкое место - тестирование и дефекты. Решение этой проблемы предлагает сам процесс промышленной разработки - рассмотрим его в паре предложений. Заказчик готовит бизнес-требование, где с возможной для себя детализацией описывает, что он хочет. Далее, требование попадает к системному аналитику, который это требование анализирует - декомпозирует на понятные короткие требования, детально прописывает весь функционал, все пользовательские сценарии, согласует все с заказчиком - получается документация. Фактически "документация" - это отражение бизнес-требования заказчика, согласованное с ним. Вся дальнейшая работа ведется с этой документацией.
Документация идет в разработку, разработчик реализует то, что написано в документации. Тестировщик пишет сценарии тестирования, опираясь на пользовательские сценарии, изложенные также в документации. Тестовый сценарий выглядит так: описание действий, ожидаемый результат, а дефект (баг) - это когда выполняются описанные в тестовом сценарии действия, но полученный результат не совпадает с ожидаемым. По-моему все просто замечательно! Описание тестирования гарантирует повторяемость (а это уже зрелость не ниже второго уровня!), что такое баг - четко определено. Если находится проблема в пользовательском сценарии, не указанном в документации, - это не баг, а фича (действительно, пользовательский сценарий не описан в документации, согласованной с заказчиком, а значит его не должно быть). Там, где нет тестового сценария, проблема не ищется, а, следовательно, не находятся. Меньше дефектов - результативнее разработка.
#пятница #dev
В прошлый раз мы обсуждали гибкую разработку и наметили узкое место - тестирование и дефекты. Решение этой проблемы предлагает сам процесс промышленной разработки - рассмотрим его в паре предложений. Заказчик готовит бизнес-требование, где с возможной для себя детализацией описывает, что он хочет. Далее, требование попадает к системному аналитику, который это требование анализирует - декомпозирует на понятные короткие требования, детально прописывает весь функционал, все пользовательские сценарии, согласует все с заказчиком - получается документация. Фактически "документация" - это отражение бизнес-требования заказчика, согласованное с ним. Вся дальнейшая работа ведется с этой документацией.
Документация идет в разработку, разработчик реализует то, что написано в документации. Тестировщик пишет сценарии тестирования, опираясь на пользовательские сценарии, изложенные также в документации. Тестовый сценарий выглядит так: описание действий, ожидаемый результат, а дефект (баг) - это когда выполняются описанные в тестовом сценарии действия, но полученный результат не совпадает с ожидаемым. По-моему все просто замечательно! Описание тестирования гарантирует повторяемость (а это уже зрелость не ниже второго уровня!), что такое баг - четко определено. Если находится проблема в пользовательском сценарии, не указанном в документации, - это не баг, а фича (действительно, пользовательский сценарий не описан в документации, согласованной с заказчиком, а значит его не должно быть). Там, где нет тестового сценария, проблема не ищется, а, следовательно, не находятся. Меньше дефектов - результативнее разработка.
#пятница #dev
🔥5🤣2👍1
Понятно очевидное желание обнаружения атаки на как можно более ранних стадиях. Но принципиальная проблема в том, что для того, чтобы вредоносную активность обнаружить она должна проявиться. Т.е. сначала мы наблюдаем какие-то техники атакующего, а затем, собственно, за эти самые техники мы его детектим. При этом, не умаляется возможность предотвращения атак на ранних стадиях, поскольку мы не стремимся к полному отсутствию вредоносной активности, но к тому, чтобы эта вредоносная активность не успевала нам нанести ущерб прежде чем мы ее обнаружим, локализуем и остановим.
Видимо, все это и имеет в виду уважаемый Gartner, в своем "новом" документе "Emerging Tech: Top Use Cases in Preemptive Cyber Defense" от 13 августа 2024 (вторник, не пятница), но его чтение мне заметно подняло настроение, о чем не могу не написать в пятницу.
#MDR #vCISO #пятница
Видимо, все это и имеет в виду уважаемый Gartner, в своем "новом" документе "Emerging Tech: Top Use Cases in Preemptive Cyber Defense" от 13 августа 2024 (вторник, не пятница), но его чтение мне заметно подняло настроение, о чем не могу не написать в пятницу.
#MDR #vCISO #пятница
Дзен | Статьи
"Упреждающая киберзащита" от Gartner
Статья автора «REPLY-TO-ALL Information Security Blog» в Дзене ✍: В 1956 году американский писатель Филип Дик опубликовал антиутопию "Особое мнение" (The Minority Report), а в 2002 году вдохновленный
👍7