Отличная статья! Не так давно перешел на обсидиан, и честно говоря, не пожалел. Постепенное внедрение началось с рабочей сферы и желания написать для себя и коллег базу знаний , для комфортного поиска информации, которую раньше каждый хранил в голове. Прочитал интересную книгу «Создай свой „второй мозг“» Тиаго Форте. Кстати, ваш подход сильно перекликается с методологией :
Метод PARA — я теперь делю всё в Obsidian на категории:
Projects (активные задачи, например «Запуск курса»),
Areas (сферы ответственности, вроде «Здоровье» или «Финансы»),
Resources (шаблоны, полезные статьи),
Archives (завершённые проекты). Это помогло избавиться от хаоса в заметках — всё сразу видно, к чему относится.
Прогрессивная обработка (CODE):
Capture — быстро записываю идеи в «Инбокс» (у меня для этого отдельная ежедневная заметка).
Organize — раз в неделю сортирую их по PARA.
Distill — сокращаю до ключевых мыслей (как ваш принцип «каждая заметка — единое целое»).
Express — использую накопленное в проектах (например, статья рождается из 5-6 связанных заметок).
Правило 10%: Сохраняю только 10% из прочитанного/увиденного — то, что реально можно применить. Например, вместо 20 цитат из книги оставляю 2, но сразу пишу, как внедрю их в работу.
Совет из книги, который вас возможно дополнит: «Короткие еженедельные обзоры». Я трачу 20 минут в воскресенье, чтобы:
Проверить, какие заметки можно «поднять» из Archives в Projects (ваш принцип ревизии!),
Удалить лишнее (например, устаревшие задачи в канбане).
Цитата про "ИИ не чувствует, но убеждает" — хочется выгравировать на каждом гаджете. Но как быть с тем, что некоторые нейросети уже проходят тест Тьюринга в узких контекстах? Не рискуем ли мы скатиться в солипсизм, отрицая "субъектность" ИИ лишь потому, что она небиологическая?
Спасибо за пищу для мысли — статья отлично балансирует между технопаранойей и технооптимизмом. Но, кажется, главный вывод в другом: ИИ стал зеркалом, в котором человечество разглядывает свои же когнитивные изъяны. И пока неясно, кто здесь уязвимее — код или нейроны.
Отличный материал, вот что-то такое хочется перманентно видеть на хабре. Ничего сверх-нового не узнал, но представляю как этот труд может помочь тем, кто впервые сталкивается с wine, даже после продолжительной работы под GNU\Linux. Автору плюсик в карму!
Хороший поинт к условному примеру) Конечно, кто в здравом уме не запускает ручной бэкап Mongo в 3:40 ночи, нарушая все корпоративные регламенты, с нетипичного хоста, под новым агентом, без предварительного уведомления? Прям классика DevOps'псины)
Собственно, для такого поведенческая аналитика и существует — не чтобы кидаться на каждый ночной скрипт, а чтобы отличать "нормальную автоматизацию" от "что-то здесь не так, сэр". Она не бьёт по рукам за работу вне графика — она говорит: "А это вообще он? И почему он теперь качает больше, чем обычно, и с другого IP, и не тем скриптом?"
Так что если это действительно бэкап — отлично. Пусть сработает сигнал, система проверит контекст, и ничего не заблокирует. А вот если это слив клиентской БД через curl в tmp-папку — лучше узнать об этом сразу, чем в пресс-релизе через неделю.
Звучит довольно интересно, хотя отказ от шифрования кажется все еще не очень безопасным. А что насчет использования в таких кейсах контроля через поведенческую аналитику( UBA/UEBA )? Как я помню, там логика строится на baseline активности и анализе аномалий. Условный пример: "Этот пользователь обычно работает с 9 до 18, не делает скачивания более 50MB, и никогда не лез в прод-серверы. Почему он в 3:40 ночи качает dump из MongoDB?"
Интересное чтиво, но как человек мало понимающий в этом, хотелось бы отметить два момента. 1. Фокус на количественные показатели — Хотя сокращение портфеля инцидентов и повышение соблюдения SLA — значимые достижения, избыточная ориентация на KPI может привести к «игре с метриками». Команды могут начать избегать регистрации инцидентов или снижать их приоритет для искусственного улучшения показателе. И чем дольше такая система используется, тем больше шанс найти лазейку для злонамеренного использования.
«Мы делим инциденты в зависимости от приоритета, степени отклонения, степени влияния, критичности и срочности.»
2. Это отличный подход, однако для более точной оценки критичности, в моем понимании, важно привлекать бизнес-стейкхолдеров. Техническая команда может воспринимать проблему как малозначительную, тогда как для бизнеса это может быть серьёзной угрозой.
Насколько мне известно для этого используют Business Impact Analysis (BIA) при оценке инцидентов. Она включает:
Оценку финансовых потерь при возникновении инцидента;
Анализ влияния на репутацию и клиентский опыт;
Оценку воздействия на ключевые бизнес-процессы.
«Мы создали дашборды и структуры, которые позволяют командам в реальном времени отслеживать, что происходит в конкретный момент.»
Хотелось бы узнать, используете ли вы системы предиктивной аналитики и машинного обучения для повышения качества и скорости работы?
Эти данные напоминают, что во Вселенной нет окончательных истин — лишь всё более точные вопросы. Возможно, тёмная энергия не столько фундаментальная константа, сколько динамическая характеристика, и нам предстоит пересмотреть само понимание космической эволюции.
С другой стороны, я уже некоторое время скептически отношусь ко всем громким заголовкам в рамках исследований. Уже не один раз подмечено, что исследователи ради финансирования стараются добавить важности и весомости своей теме, даже если по факту работа было не очень значительна. Как и это исследование, ничего не доказало и не опровергло, ибо это просто ступенька на пути к открытию чего-то важного.
Вот такой материал мне нравится, все интересно и подробно. Все хочу начать что-то выращивать, а тут прям целый гайд на свою лабу. Обязательно вернусь к материалу, когда потянет к растениям и даче на старости лет. Удачи в ваших делах, надеюсь ваше дело будет расти)
Звучит это все дело довольно интересно, но я нашел еще 3 отговорки) 1. Риски раскрытия коммерческой тайны и уязвимостей. Попытка рассказать о крутом решении которое я развернул у себя, используя разные фишки, даже в неком абстрактном виде можно интерпретировать как потенциальные уязвимости. Начальство может такое не оценить. 2. Конфликт интересов. Если статья содержит описание решений, основанных на продуктах или услугах определённой компании, это может быть воспринято как реклама. На Хабре аудитория чувствительна к рекламе, и подобные материалы нередко вызывают негативную реакцию. Кроме того, что решение на основе проперитарного софта не будет интересно большей части аудитории, сюда можно приписать еще и банальных страх критики и ощущения, что ты просто расписал для себя красивую методичку, которая особо никому и не нужна. 3.Конкуренция с более опытными авторами. Нередко начинающие авторы опасаются, что их статьи не выдержат конкуренции с материалами от более опытных коллег. И в этом есть доля правды, у человека с большим опытом написания статей, более масштабной и интересной темой соответствено имеет гораздо больше шансов на победу.
Вот и остается участвовать, ради получения опыта и фидбека, что бы стать лучшей версией себя. Звучит конечно хорошо, но стоит ли время тратить на это, вместо развития в чем-то более профитном для себя в текущий момент? Вопрос интересный и открытый. Спасибо за материал, а тем кому все эти отговорки не нужны, удачи и успехов в ваших трудах)
Интересная статья, которая помогает лучше понять, насколько важен грамотный отчет после пентеста. Особенно понравилось объяснение различий между этими видами отчетов. Также отметил для себя важность адаптации содержания под целевую аудиторию. Спасибо за интересный материал)
Ключевая мысль, которую важно подчеркнуть: журналистика не может существовать в вакууме. Даже в условиях цифровых атак редакции адаптируются, ищут новые каналы взаимодействия с аудиторией и продолжают влиять на общественную повестку. Это не вопрос технического сопротивления, а вопрос устойчивости медиа как института. Вообще стоит найти ответ на вопрос, как медиаплатформам строить ИБ-инфраструктуру и управлять репутационными рисками , что бы не терять аудиторию даже во время атак? Это может дать журналистике больше инструментов для выживания в цифровой среде, а не только чувство, что они — вечная мишень. Вообще, было интересно почитать)
Чтиво интересное. Действительно, несмотря на все технические средства защиты, именно люди часто оказываются самой уязвимой частью системы безопасности.Также важное замечание о юридических аспектах — защита личной информации сотрудников и соблюдение законов действительно критичны в таких тестах. Очень здорово, что вы акцентируете внимание на важности этичности и корректности в процессе.
Спасибо за подробный обзор, буду рад почитать про реальные кейсы и более сложные атаки и методы их реализации
Интересная статья, ждал только в конце ультимативной таблице с пересчетом всех метрик от автора, которая покажет золотую середину, а так, вполне неплохо
Отличный обзор! Интересно, насколько Teensy 4.1 оправдывает себя в проектах с реальной нагрузкой, особенно в задачах, требующих активного использования Ethernet и насколько хорошо он справляется с такими сценариями на практике? Было бы интересно узнать про реальные кейсы!
Да, это жестоко, ахахах
Отличная статья! Не так давно перешел на обсидиан, и честно говоря, не пожалел.
Постепенное внедрение началось с рабочей сферы и желания написать для себя и коллег базу знаний , для комфортного поиска информации, которую раньше каждый хранил в голове.
Прочитал интересную книгу «Создай свой „второй мозг“» Тиаго Форте. Кстати, ваш подход сильно перекликается с методологией :
Метод PARA — я теперь делю всё в Obsidian на категории:
Projects (активные задачи, например «Запуск курса»),
Areas (сферы ответственности, вроде «Здоровье» или «Финансы»),
Resources (шаблоны, полезные статьи),
Archives (завершённые проекты).
Это помогло избавиться от хаоса в заметках — всё сразу видно, к чему относится.
Прогрессивная обработка (CODE):
Capture — быстро записываю идеи в «Инбокс» (у меня для этого отдельная ежедневная заметка).
Organize — раз в неделю сортирую их по PARA.
Distill — сокращаю до ключевых мыслей (как ваш принцип «каждая заметка — единое целое»).
Express — использую накопленное в проектах (например, статья рождается из 5-6 связанных заметок).
Правило 10%:
Сохраняю только 10% из прочитанного/увиденного — то, что реально можно применить. Например, вместо 20 цитат из книги оставляю 2, но сразу пишу, как внедрю их в работу.
Совет из книги, который вас возможно дополнит: «Короткие еженедельные обзоры». Я трачу 20 минут в воскресенье, чтобы:
Проверить, какие заметки можно «поднять» из Archives в Projects (ваш принцип ревизии!),
Удалить лишнее (например, устаревшие задачи в канбане).
Цитата про "ИИ не чувствует, но убеждает" — хочется выгравировать на каждом гаджете. Но как быть с тем, что некоторые нейросети уже проходят тест Тьюринга в узких контекстах? Не рискуем ли мы скатиться в солипсизм, отрицая "субъектность" ИИ лишь потому, что она небиологическая?
Спасибо за пищу для мысли — статья отлично балансирует между технопаранойей и технооптимизмом. Но, кажется, главный вывод в другом: ИИ стал зеркалом, в котором человечество разглядывает свои же когнитивные изъяны. И пока неясно, кто здесь уязвимее — код или нейроны.
Полезно, спасибо)
Отличный материал, вот что-то такое хочется перманентно видеть на хабре. Ничего сверх-нового не узнал, но представляю как этот труд может помочь тем, кто впервые сталкивается с wine, даже после продолжительной работы под GNU\Linux.
Автору плюсик в карму!
Ты ему вопрос, он тебе - "очень сложно, но вы приходите, мы решим")
А так, хороший базовый вебинарчик
Хороший поинт к условному примеру) Конечно, кто в здравом уме не запускает ручной бэкап Mongo в 3:40 ночи, нарушая все корпоративные регламенты, с нетипичного хоста, под новым агентом, без предварительного уведомления? Прям классика DevOps'псины)
Собственно, для такого поведенческая аналитика и существует — не чтобы кидаться на каждый ночной скрипт, а чтобы отличать "нормальную автоматизацию" от "что-то здесь не так, сэр".
Она не бьёт по рукам за работу вне графика — она говорит: "А это вообще он? И почему он теперь качает больше, чем обычно, и с другого IP, и не тем скриптом?"
Так что если это действительно бэкап — отлично. Пусть сработает сигнал, система проверит контекст, и ничего не заблокирует. А вот если это слив клиентской БД через curl в tmp-папку — лучше узнать об этом сразу, чем в пресс-релизе через неделю.
Звучит довольно интересно, хотя отказ от шифрования кажется все еще не очень безопасным.
А что насчет использования в таких кейсах контроля через поведенческую аналитику( UBA/UEBA )? Как я помню, там логика строится на baseline активности и анализе аномалий.
Условный пример:
"Этот пользователь обычно работает с 9 до 18, не делает скачивания более 50MB, и никогда не лез в прод-серверы. Почему он в 3:40 ночи качает dump из MongoDB?"
Спасибо за информативный ответ)
Интересное чтиво, но как человек мало понимающий в этом, хотелось бы отметить два момента.
1. Фокус на количественные показатели — Хотя сокращение портфеля инцидентов и повышение соблюдения SLA — значимые достижения, избыточная ориентация на KPI может привести к «игре с метриками». Команды могут начать избегать регистрации инцидентов или снижать их приоритет для искусственного улучшения показателе. И чем дольше такая система используется, тем больше шанс найти лазейку для злонамеренного использования.
2. Это отличный подход, однако для более точной оценки критичности, в моем понимании, важно привлекать бизнес-стейкхолдеров. Техническая команда может воспринимать проблему как малозначительную, тогда как для бизнеса это может быть серьёзной угрозой.
Насколько мне известно для этого используют Business Impact Analysis (BIA) при оценке инцидентов. Она включает:
Оценку финансовых потерь при возникновении инцидента;
Анализ влияния на репутацию и клиентский опыт;
Оценку воздействия на ключевые бизнес-процессы.
Хотелось бы узнать, используете ли вы системы предиктивной аналитики и машинного обучения для повышения качества и скорости работы?
Эти данные напоминают, что во Вселенной нет окончательных истин — лишь всё более точные вопросы. Возможно, тёмная энергия не столько фундаментальная константа, сколько динамическая характеристика, и нам предстоит пересмотреть само понимание космической эволюции.
С другой стороны, я уже некоторое время скептически отношусь ко всем громким заголовкам в рамках исследований. Уже не один раз подмечено, что исследователи ради финансирования стараются добавить важности и весомости своей теме, даже если по факту работа было не очень значительна. Как и это исследование, ничего не доказало и не опровергло, ибо это просто ступенька на пути к открытию чего-то важного.
Вот такой материал мне нравится, все интересно и подробно. Все хочу начать что-то выращивать, а тут прям целый гайд на свою лабу. Обязательно вернусь к материалу, когда потянет к растениям и даче на старости лет.
Удачи в ваших делах, надеюсь ваше дело будет расти)
Звучит это все дело довольно интересно, но я нашел еще 3 отговорки)
1. Риски раскрытия коммерческой тайны и уязвимостей.
Попытка рассказать о крутом решении которое я развернул у себя, используя разные фишки, даже в неком абстрактном виде можно интерпретировать как потенциальные уязвимости. Начальство может такое не оценить.
2. Конфликт интересов.
Если статья содержит описание решений, основанных на продуктах или услугах определённой компании, это может быть воспринято как реклама. На Хабре аудитория чувствительна к рекламе, и подобные материалы нередко вызывают негативную реакцию. Кроме того, что решение на основе проперитарного софта не будет интересно большей части аудитории, сюда можно приписать еще и банальных страх критики и ощущения, что ты просто расписал для себя красивую методичку, которая особо никому и не нужна.
3.Конкуренция с более опытными авторами.
Нередко начинающие авторы опасаются, что их статьи не выдержат конкуренции с материалами от более опытных коллег. И в этом есть доля правды, у человека с большим опытом написания статей, более масштабной и интересной темой соответствено имеет гораздо больше шансов на победу.
Вот и остается участвовать, ради получения опыта и фидбека, что бы стать лучшей версией себя. Звучит конечно хорошо, но стоит ли время тратить на это, вместо развития в чем-то более профитном для себя в текущий момент? Вопрос интересный и открытый.
Спасибо за материал, а тем кому все эти отговорки не нужны, удачи и успехов в ваших трудах)
Интересная статья, которая помогает лучше понять, насколько важен грамотный отчет после пентеста. Особенно понравилось объяснение различий между этими видами отчетов. Также отметил для себя важность адаптации содержания под целевую аудиторию. Спасибо за интересный материал)
Ключевая мысль, которую важно подчеркнуть: журналистика не может существовать в вакууме. Даже в условиях цифровых атак редакции адаптируются, ищут новые каналы взаимодействия с аудиторией и продолжают влиять на общественную повестку. Это не вопрос технического сопротивления, а вопрос устойчивости медиа как института.
Вообще стоит найти ответ на вопрос, как медиаплатформам строить ИБ-инфраструктуру и управлять репутационными рисками , что бы не терять аудиторию даже во время атак? Это может дать журналистике больше инструментов для выживания в цифровой среде, а не только чувство, что они — вечная мишень.
Вообще, было интересно почитать)
Чтиво интересное. Действительно, несмотря на все технические средства защиты, именно люди часто оказываются самой уязвимой частью системы безопасности.Также важное замечание о юридических аспектах — защита личной информации сотрудников и соблюдение законов действительно критичны в таких тестах. Очень здорово, что вы акцентируете внимание на важности этичности и корректности в процессе.
Спасибо за подробный обзор, буду рад почитать про реальные кейсы и более сложные атаки и методы их реализации
Интересная статья, ждал только в конце ультимативной таблице с пересчетом всех метрик от автора, которая покажет золотую середину, а так, вполне неплохо
Отличный обзор! Интересно, насколько Teensy 4.1 оправдывает себя в проектах с реальной нагрузкой, особенно в задачах, требующих активного использования Ethernet и насколько хорошо он справляется с такими сценариями на практике? Было бы интересно узнать про реальные кейсы!