Наталья Касперская выступит 22 марта на саммите в Санкт-Петербурге

Наталья Касперская выступит 22 марта на саммите в Санкт-Петербурге

Наталья Касперская выступит 22 марта на саммите в Санкт-Петербурге

22 марта в городе на Неве состоится крупнейшее событие отрасли информационной безопасности Северо-Западного региона – второй Business Information Security Summit St. Petersburg 2018. Ключевой темой конференции станет информационная безопасность цифровой экономики Северо-Западного региона. Среди самых ожидаемых спикеров мероприятия – Наталья Касперская (президент ГК InfoWatch), Денис Чамара (председатель комитета по информатизации и связи Санкт-Петербурга), Георгий Грицай (исполняющий обязанности директора направления «Информационная безопасность» АНО «Цифровая экономика»). Кроме того, в работе форума примет участие зарубежная делегация представителей крупного бизнеса стран Ближнего Востока.

Принятая в 2017 году в РФ государственная программа «Цифровая экономика» на сегодняшний день включает в себя пять основных направлений развития, одним из которых является информационная безопасность. В чем заключается основная задача государственной программы? Как в ее рамках выстроена работа направления информационной безопасности? Какие темы ИБ-направления являются приоритетными и получат развитие уже в ближайшем будущем? На эти и другие важнейшие вопросы ответят эксперты рабочих групп и центров компетенций госпрограммы «Цифровая экономика» в пленарных дискуссиях и докладах на предстоящем саммите.

Специально для представителей СМИ в рамках саммита состоится пресс-брифинг, на котором Наталья Касперская резюмирует самые важные тезисы пленарной дискуссии, а Денис Чамара анонсирует программу Цифрового Форума 2018 – правительственного мероприятия на высшем уровне, которое пройдет 18-20 апреля в городе на Неве.

Цифровая экономика предполагает появление новых информационных систем и сервисов. Но если зависимость новой экономической модели от ИТ очевидна, то влияние информационной безопасности на ее эффективность требует новых доказательств. В частности, обновленная инфраструктура предусматривает встроенные средства ИБ, а не «навесные». А для этого ИБ-специалисты должны быть вовлечены в инфраструктурные ИТ-проекты на самых ранних стадиях. О том, как этого добиться, пойдет речь в секционной части саммита.

Одним из наиболее ожидаемых событий секционной части станет круглый стол «Проблемы образования в информационной безопасности», партнером которого выступит Федеральное учебно-методическое объединение в сфере высшего образования по информационной безопасности. Среди наиболее острых вопросов – какие важные для бизнеса компетенции отсутствуют у выпускников направления ИБ? Текущие проблемы образования по направлению ИБ. Варианты взаимодействия образования и бизнеса. Как реализовать потребности в качественных специалистах? Накопившиеся проблемы обсудят директор института математики и информационных систем ВятГУ Антон Земцов, заведующий кафедрой «Информационная безопасность компьютерных систем» Санкт-Петербургского государственного Политехнического университета Петр Зегжда, декан факультета безопасности ИТ ИТМО Данил Заколдаев и др.

Подробнее о мероприятии: https://www.anti-malware.ru/event/2018/02/22

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

Такая версия Проводника всё ещё есть в Windows ради совместимости со старыми приложениями. Обычно современные системы почти не используют этот путь. Но в данном случае сторонний деинсталлятор каким-то образом заставлял систему обращаться именно к этому устаревшему компоненту.

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

Поскольку процесс повторялся в цикле, повреждение памяти постепенно накапливалось. В какой-то момент указатель стека уезжал в область активного кода, и Проводник падал.

Со стороны всё выглядело как типичная системная ошибка: софт снова и снова аварийно завершал работу, создавая ощущение, что проблема в самой Windows. На деле операционная система лишь показывала последствия ошибки в стороннем ПО.

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

RSS: Новости на портале Anti-Malware.ru