Инфобез

Постоянное использование ИИ ведёт к когнитивной атрофии: люди перестают развивать и сохранять ключевые мыслительные навыки, — утверждает профессор Массачусетского технологического института Эрик Со.

Учёба эффективна лишь когда человек сталкивается с трудностями и проходит через ошибки, поясняет он. Это "продуктивная борьба", а ИИ убирает это трение, предлагая мгновенные ответы. Мозг привыкает не напрягаться.

Кроме того, ИИ начинает вредить бизнесу. Искусственный интеллект призван ускорить производственные процессы, сократить расходы и повысить эффективность, однако некоторые компании уже начинают пересматривать свои подходы из-за ошибок в сгенерированном контенте и потери мотивации сотрудников.

Нередко вместо экономии времени нагрузка на сотрудников возрастает, так как сгенерированную ИИ информацию приходится проверять, исправлять ошибки и доводить результаты до должного состояния. Данный феномен получил название "помойной работы".

Забавная зарисовка от канала Месть доброй воли

Вроде вот сказал и полегчало, но ненадолго.
Недавно сам развернул пост бюрократии, потому что кто-то боится ответственности. Причём против тех, кого два года торопил. Такое вот двойное послание получилось: 1) давайте быстрее 2) пишите письма.
А потом удивляемся, откуда у людей начальные признаки шизофрении.
Казалось бы. Метод параллельного перехода, пусть ручного, не автоматического (со старой версии на новую) - какие могут быть риски...
Но кто-то боится ответственности, поэтому бюрократия ему за благо...
Простите, товарищи, если обидел кого, так я не по своей воле.

#безопаснаяРазработка #бюрократы #самтакой

Пока каждый гонится за куском сыра или высоким стулом, дело стоит, потому что вы заняты не работой, а карьерой. Вы даже в одном направлении двигаться не можете, потому что пресловутый кусок сыра у каждого свой, вот и получается как в басне Ивана Андреевича Крылова про лебедя, рака и щуку...
Одумайтесь, товарищи, общее дело делаем! Рабочий порядок не случайно назван рабочим, господа-бюрократы!

#накипело #стагнация #деньги #слава #власть #бюрократы

Недавно до того дошли, что в одном из модулей внедренного ПО нашли ручку, которая отдает кешированные сессии. С логином и паролем. В открытом виде. Неавторизованному пользователю.
Казалось, что дно - вот оно, но снизу опять стучат.

#БезопаснаяРазработка #НИИТП #уязвимости

Пришёл комплекс программ, где софт требует привилегий пользователя на игнорирование всякого рода меток контекста безопасности.
Мотивировано тем, что софт разработан на фортране в далёких 2012-2016 годах и переписывать его на языках высокого уровня никто не будет, т.к. "этот маленький манёвр будет стоить нам 51 год".
В итоге закрыли пользователям низшие метки и всё. Так и живём.

#МИС #БезопаснаяРазработка #Уязвимости #РоссийскоеПО #astralinux

Не так давно мой директор сказал, что безопасная разработка ему не нужна. Ну не нужна, так не нужна.
Современный мир софта для разработок - это как магазин с костылями, только одни костыли прочные и надёжные, а некоторые насквозь проржавели или изъедены термитами.
Так вот, кто отказывается от безопасности в разработке программного обеспечения, тот стреляет себе в ногу... чтоб обеспечить себе побольше времени с костылями.

#БезопаснаяРазработка #FatalError

С начала 2022 года ландшафт ИБ в разработке изменился кардинально. Внедрение Safe Board ушло, вендоры SAP ушли, а количество целевых атак (APT) на репозитории и пайплайны только выросло.

Если вы отвечаете за безопасность разработки или внедряете процессы DevSecOps «с нуля» в текущих реалиях, вот на что я рекомендую обращать внимание сегодня.

1. Импортозамещение — это не про «галочку», а про риск
Мы все перешли на российские ОС, СУБД и средства сборки (GitFlic, СберТех и др.).
Главная боль: инструменты новые, багов в них много, а эксплойты под нулевые дни (0-day) для российского ПО уже активно продаются на теневых форумах.
Внедряйте DAST и IAST на этапе тестирования. Не верьте, что «раз российское, значит безопасное». Проверять код придется даже тщательнее, чем раньше, пока экосистема не устаканится.

2. Зависимости (Open Source) стали минным полем
NPM, PyPI, Maven — оттуда мы продолжаем качать библиотеки. Но теперь популярный пакет может внезапно удалить автор (как было с colors.js) или его могут взломать.

Обязательно поднимайте репозиторий-кэш (артефакторий) типа Nexus или JFrog внутри контура.
Никаких прямых go get или pip install с продакшн-серверов. Только через прокси с проверкой.

3. Сдвиг влево (Shift Left) на российский лад
Раньше мы могли купить SaaS-решение и сканировать код в облаке. Теперь многие облака либо недоступны, либо требуют аттестации.
Встраивайте сканеры кода (SAST) прямо в раннеры вашего GitLab CI / GitHub Enterprise. У нас есть достойные инструменты (например, от Solar, Positive Technologies), которые умеют работать в изолированных контурах. Лучше найти ошибку в момент коммита, чем когда код уже упал на стенд.

4. Контейнеризация и безопасность образов
Все на Kubernetes. Все на Docker (или Podman). Но базовые образы мы теперь тянем не из официального Docker Hub, а из Nexus или c Nexus Registry.

Сканируйте базовые образы на уязвимости (CVE) перед сборкой. Часто в «замороченный» образ разработчик докидывает утилиты для отладки, которые превращают подушку безопасности в решето.
Запретите запуск контейнеров от root. Это база, но о ней постоянно забывают.

5. Люди и компетенции
Безопасников, которые понимают и код, и Kubernetes, и российское ПО, — единицы.
Что делать: Растить внутри. Не наказывать разработчиков за найденные уязвимости, а выстраивать процесс так, чтобы найти баг было почетно (Bug Bounty внутри команды). Если разработчик боится безопасника — он будет прятать костыли, а не чинить их.

Руководить безопасной разработкой сейчас — значит быть буфером между требованиями регуляторов (ФСТЭК, приказы Минцифры) и реальностью кода. Нужно уметь объяснять, почему защита конвейера сборки важнее, чем очередной «бумажный» документ.

#DevSecOps #БезопаснаяРазработка #InfoSec #РоссийскоеПО #CICD

Когда надо сетевой сканер, а сетевого сканера нет:

cat /etc/hosts | grep -vE '^#|^$' | awk '{ print $1 }' | xargs -I '{}' ping -c 1 {} | grep ^64

Вместо /etc/hosts можно использовать любой ip-лист (по одному ip на строку).
Не работает, если в сети запрещен протокол ICMP.

#разведка #bash #debian #astralinux

ИБ как страховой полис: почему управление рисками — это язык, на котором говорит ваш совет директоров

Вы можете месяцами тушить уязвимости, как героический пожарный. Можно годами вкладывать в самые модные системы защиты. Но рано или поздно прозвучит простой и смертельный вопрос: «А насколько нам вообще стало безопаснее? И сколько денег мы на этом сэкономили?»

Если вы не можете ответить на эти вопросы, ваша безопасность — это не инвестиция, а дорогое хобби. Управление киберрисками — это не про поиск всех уязвимостей. Это про понимание того, какие из них действительно могут разорить бизнес.

Три иллюзии, которые превращают ИБ-бюджет в пустую трату денег:

1. «Чем дороже технология, тем мы безопаснее»
Вы купили самый разрекламированный EDR.Он генерирует 1000 предупреждений в день. Ваша команда тонет в этом шуме, а реальная атака проходит незамеченной среди ложных срабатываний. Вы закрыли технологический вакуум, но не снизили риск. Вы лечили симптом, а не болезнь.

· Решение: Инвестируйте в риски, а не в технологии. Сначала спросите: «Какую угрозу бизнесу мы снижаем, покупая эту систему?». Технология — это инструмент для снижения конкретного риска, а не магический артефакт.

2. «Наш главный риск — хакеры из интернета»
Вы укрепляете периметр,пока бывший сотрудник с флешкой в кармане уносит к конкурентам ваше ноу-хау. Вы боитесь DDoS, пока ошибка в обновлении вашего собственного ПО вызывает 12-часовой простой, стоивший компании миллионы. Вы смотрите не туда.

· Решение: Составьте Карту рисков. Регулярно проводите оценку (Risk Assessment). Что для вас ценнее: доступность сайта или конфиденциальность базы клиентов? Какая угроза ударит больнее: шифровальщик в цехе или утечка чертежей? Риски должны быть видны, измерены и расставлены по приоритетам.

3. «Мы закупили все по фреймворку, значит, мы в безопасности»
Вы формально выполнили все пункты NIST или ГОСТ Р 57580.Поставили галочки. Но фреймворк не знает специфики вашего бизнеса. Он не знает, что ваш новый облачный CRM стал самым лакомым активом для атакующего. Вы защищаете вчерашний день.

· Решение: Говорите на языке бизнеса. Переведите технические уязвимости в финансовые потери. Не «у нас уязвимость CVE-2024-XXXX», а «из-за этой уязвимости мы можем потерять 5 млн рублей в час простоя и 20 млн — в виде штрафов от регулятора». Совет директоров понимает язык денег, а не язык CVE.

Ваша цель — не «ноль рисков». Ваша цель — «осознанный риск».

Зрелая программа управления рисками позволяет вам прийти к руководству и сказать:

· «Мы понимаем наши 10 главных киберугроз.»
· «Мы контролируем 8 из них на приемлемом уровне.»
· «Вот 2 самых опасных, и вот план по их снижению с бюджетом X, который сэкономит компании Y.»

Это превращает вас из просителя бюджета в стратегического партнера. Вы больше не «тушите пожары». Вы — штурман, который прокладывает безопасный курс корабля бизнеса в бушующем океане цифровых угроз.

#УправлениеРисками #RiskManagement #Киберриски #ИБ #ИнформационнаяБезопасность #БизнесБезопасность #Стратегия #NIST #ГОСТ #RiskAssessment #SecurityStrategy