Дело в том, что самолетом, автобусом и т.д. управляет человеком. Дроны же будут иметь смысл если они полностью автопилотные.
Предположим Интернет-магазин X запустил сервис доставки с помощью автоботов дронов с автоматической системой управления. Дрон сам грузиться, сам летит до пункта назначения и сам возвращается. Все здорово, но 12007-й итерации дрон, во время полета задел и оборвал трос промышленного альпиниста, моющего окна в высотном здании… Кто будет виновным в данном случае?
Внедрение искусственного интеллекта (автоматический дрон), перевернет жизнь не только с технической точки зрения. Мы сами, наши привычки, действующие правила дорожно, авиационного, морского движения должны будут измениться.
Неплохое начало статьи, которое свелось в пустую рекламу в конце. Фразы «наша система надежно защищена» не самые удачные, для того чтобы вызвать интерес у ИТ-шников, являющихся основным контингентом Хабра…
Да и идеи по поводу примения в Банках очень далеки от реальности, хотя бы по тому, что карту могут опустошить в банкомате банка, не являющегося эмитентом карты. А видео клиентов банки между собой никогда передават не будут.
Второй существенной проблемой при использовании биометрии является закон о персональных данных. Если оператор укажет, что в его системах используется биометрия, то это «красная тряпка» для проверяющих поскольку подобные системы будет очень сложно и дорого защищать. Уровень защищенности подобной системы будет минимум УЗ2 (по ПП-1119), со всеми вытекающими (Приказы ФСТЭК 21 и ФСБ 378)
С точки зрения практической безопасности биометрия тоже имеет нюансы/проблемы Хотя бы по тому, что идентификационные признаки у человека меняются. На одной из конференций по ИБ коллеги описали ситуацию, когда внедрив систему авторизации по отпечаткам пальцев столкнулись с проблемой, что после выходных многие женщины не могли авторизоваться, поскольку их отпечатки «плыли», из-за того что они в выходные занимались влажной уборкой…
В целом конечно направление интересное, но в нем не хватает какой-то killer фичи, которая бы запустила процесс. Ведь про эти технологии известно уже очень давно, но широкого применения они так и не нашли.
Преимущество дронов по сравнению с обычными способами доставки в следующем:
1. Скорость
2. Возможность совершения операций доставки в тех случаях, когда нет подходящей транспортной инфраструктуры.
3 Резкое уменьшение участия людей в процессе.
Раньше люди пользовались стационарными телефонами и первые мобильники вызывали тот же вопрос «Зачем?» Зато сейчас стационарная телефонная связь теряет свою актуальность. Тоже самое будет и с дронами. К удобству быстро привыкаешь.
Да, это так. Но прогресс не остановить. Более того, та страна которая быстрее внедрит у себя подобный вид транспорта, с учетом интересов всех заинтересованных лиц, получит серьезный бонус к развитию экономики.
Кстати говоря использование дронов в России для доставки грузов не запрещено. Но процедура законной доставки очень замудрена, что практически полностью убивает весь смысл идеи. В США тоже можно использовать дронов для доставки, но в пределах прямой видимости оператора, управляющим полетом.
Дронов будут грабить, сбивать и т.д. это факт, но насколько часто? Ведь курьеров-людей тоже ведь грабят…
Если система доставки будет более менее точно выявлять кто именно совершил грабеж, то неотвратимость наказания будет существенным сдерживающим фактором. Например Amazon прорабатывает идею использования несольких дронов в операциях доставки. Один доставляет, другой контролирует процесс.
Но даже если ничего не делать, то с точки зрения бизнеса можно вводить лимиты ценности грузов доставляемых с помощью дронов и включать риск утери в стоимость товаров / услуг.
К информационной безопасности сейчас подходят следующим образом — берут специалиста, и говорят ему ты обеспечиваешь ИБ всей компании, вот тебе комп., а дальше крутись как можешь. А в компании сотни бизнес-приложений и точек контроля. Один человек будь он трижды «отцом в ИБ» со всем этим не управиться.
SIEM — это здорово, но нужны люди, которые будут туда смотреть. А в России один ИБист на компанию практически везде (за исключением 100 или 1000 больших компаний).
Возникает идея о внешенем SOC (Security Op. Center), но там цены мама не горюй.
Сейчас существует реальная ниша по обеспечению практической безопасности, но за разумные деньги, когда услуги аутсорса ИБ будут дешевле чем ИБ внутри компании. Но это будет не скоро, а может и никогда. Поскольку деятельность лицензируемая и емкая на инвестиции.
Практическая схема атак, связанных с поиском коллизий второго рода может быть следующей:
1. Есть легитимный электронный документ подписанный электронной подписью (например, платежное поручение).
2. Злоумышленник, вносит изменения в оригинальный документ изменения (например, подменяет реквизиты получателя).
3. Используя алгоритмы поиска коллизий, злоумышленник ищет такое дополнение в к модифицированному файлу, которое позволит сделать его хэш идентичным оригиналу.
4. Злоумышленник подменяет оригинальный документ модифицированным с таким же хэшом.
Так же следует понимать, что создание электронной подписи, в общем случае, это шифрование хэша документа на закрытом ключе подписанта, поэтому в модифицированном документе, электронная подпись будет валидной и соответствовать ЭП оригинального документа.
Стиль программирования определяется менталитетом программиста. Некоторые неплохие программеры не могут следовать стандартам, у них начинается внутренний конфликт который поглощает все их внимание, что резко сказывается на работе.
В таких случаях иногда идут дальше и в команде появляется человек ответственный за унификацию кода и документации.
А вообще без стандартизации в командной работе никуда.
Что делать когда специалист из комплекта выйдет? Специалисто-зависимые бизнес-процессы да еще на производстве… могут привести к большой беде.
Сейчас бы взять и взломать программу на Коболе на неизвестном железе и на редчайшей ОС....=)
Если мы говорим про старые системы, FoxPro, Cobol и др. я бы не сказал что там хорошо с безопасностью. Взять тот же DOS, Win 3.11 и другой раритет содержит баги на уровне архитектуры, знать язык разработки конкретного софта там вовсе не обязательно.
Пример. В DOS нет нормального разделения памяти процессов, одна софтина может получить доступ к памяти отведенной для другого софта, что и привело к созданию тысяч резидентных вирусов.
Поэтому безопасность данной конкретной системы — вещь вопросительная. К сожалению в статье отсутствует информация о том, что делала эта железка.
В чем смысл использовать старый софт? Апдейтов к нему нет, он дырявый, разработчиков к нему нет, развивать его не получится. Сервер ради сервера, вернее ради аптайма.
Замысел статьи был показать «эволюцию» совершенствования мер защиты, где каждый новый вариант усиливает предыдущие, причем усиливает не просто так, а для защиты от конкретных угроз.
Все без исключения перечисленные варианты встречаются на практике. Даже «ненавистный» вариант 1.
Вариант 3 — по сути рекомендация Микрософт при публикации Exchange. Было бы здорово сегментировать и внутреннюю сеть (для защиты Back-End от АРМов сотрудников), но это на мой взгляд выходило за рамки данной статьи.
Вариант 4 — гайд для админов и работников ИБ при обосновании выбора защитных мер.
Разбиение сетей на подсети указано как принцип. Если публикуемых серверов много, выделите для них большего размера, например /16 (поскольку выход серверов Интернет в рассматриваемой статье базируется на DstNAT, сервера имеют внутренние адреса, вы можете по своему усмотрению управлять адресацией).
Вариант 5 — помимо прочих описанных в статье и комментариях случаев подходит для сетей компаний со сложной системой взаимоотношением владельцев, когда например инфраструктурой управляют люди лояльность которых вызывает сомнения, но на ситуацию повлиять нельзя.
Данный вариант показывает что можно построить безопасную сеть только с помощью серверов, без привлечения инфраструктурного оборудования. На back-end фильтруется (отбрасывается) все кроме целвых протоколов. Например, если back-end — СУБД, то оставляется только протокол взаимодействия с СУБД. Данный вариант был успешно внедрен на практике, для защиты платежных систем.
Стали бы вы советовать эти схемы заказчику с 30 офисами и 10 точками присутствия
Безусловно, все рассмотренные меры внедрялись и показали свою работоспособность.
По ходу работы я видел большое количество реальных сетей (в то числе федеральных с десятками офисов по всей географии страны) и честно сказать ситуация с безопасностью была там «не очень», что собственно и натолкнуло меня написать данный гайд.
А, вообще, огромное спасибо за анализ, любая конструктивная критика помогает совершенствоваться.
В общем случае квантовая криптография направлена на взлом криптографии с открытым ключом, но поскольку данная криптография распространена очень широко, то подвержены данному воздействию практически все ИТ-системы.
Но в тоже время не все криптоалгортимы подвержены взлому через квантовый компьютер. Пример устойчивого алгоритма — одноразовый блокнот. Поэтому если ИТ-системы используют устойчивые криптоалгоритмы, то они взломаны не будут.
Отвечая на вопрос про FB или VK, злоумышленик с квантовым компьютером с высокой вероятностью сможет рассшифровать ваш трафик, при работе с данными сетями, а следовательно от туда вытащить пароли.
ДСП — не гриф, это все знают :), это пометка конфиденциальности не имеющая под собой юридической силы.
На текущий момент есть грифы: коммерческая тайна, секретно, сов. секретно, особой важности.
Все это прописано в действующих Федеральных законах и Постановлениях Правительства.
Простой вопрос: зачем нужен антивирус. Ответ на него каждый делает сам.
Для меня как потребителя, антивирус является частью комплексной системы защиты от вредоносного кода.
Курсы нормальные есть, надо просто понять что вам нужно.
Если нужны знания нормативки и методик: УЦ МАСКОМ, Информзащита, АИС, Сюретль — welcome получите корочки которые подойдут для регуляторов.
Если нужно качнуть практическую безопасность — PentestIT, кстати они есть на Хабре или буржуйские CEH и др.
Главное понимать что за один курс невозможно стать и специалистом по методикам и практическим безопасником.
По моей статистике 19 из 20 организаций не знают вообще о неизвестных угрозах и назначении антивируса
Очень хотелось бы работать в организации которая знает о неизвестных угрозах, пока что все живем в мире известного :)
но я лично не видел ни одной нормальной модели угроз в части вредоносных файлов.
И не уведите, так как предметом для моделей является вредоносный код, а не вредоносный файл. Для понимания разницы можно ознакомиться с описанием вируса slammer — это первое.
Второе, а что в этой модели вы хотите увидеть? Перечисление всех зловредов? Классификацию зловредов?
Это делать бесполезно — даказано историей. Все классификации вирусов, которые когда либо пытались сделать на практике рушатся, поскольку вирусмейкерам глубоко плевать, что их творение не вписываеться в те рамки, которые им придумали «умные дяди».
На практике, вредоносный код рассматривается как абстракция, которая имеет функционал нарушающий свойства безопасности информации (целостность, доступность и т.д.).
Детализироваться внутрь особого практического смысла не имеет, поскольку по сути нет разницы зашифрует ли ваши данные вирус, или же уничтожит или перешлет куда либо, главное что будут нарушены свойства безопасности информации, для поддержания которых и строится система защиты.
Современная практика обеспечения защиты от вредоносного кода базируются на борьбе с проникновением и выполнением вредоносного кода на защищаемом объекте, в вот это достигается уже большим числом способов. Начиная с антивирусов, организацией замкнутой программной среды, блокирование каналов проникновения вредоносного кода (Интернет, флешки) и др.
В заключение хочу ответить что модель угроз, сама в себе большого смысла не имеет, она нужна для формирования технического задания на построение системы защиты.
Это утопия:
— специалисты на местах не знают…
— на местах квалификация администраторов недостаточна ...
Это не утопия, это нормальная работа. Другое дело, что за квалификацию нужно платить. Специалисты на местах, администраторы должны имееть соответвующее образование. Просто админ не имеет права заниматься обеспечением ИБ (у госиков),
Возможно я что-то пропустил. Какие сертифицированные МЭ были для рабочих станций?
Как минимум VIPNET, Континент-АП
Сам пользовался http://www.securitycode.ru/products/security_studio_endpoint_protection/ но тут тру печаль, Outpost купил Яндекс, данный продукт походу свернули. На этот софт были самые лучшие сертификаты — как АВ, СОВ и МЭ
Я говорю про то, что необходимость иметь два сертифицированных продукта вместо одного — это рост размера бюджета
Предположим Интернет-магазин X запустил сервис доставки с помощью
автоботовдронов с автоматической системой управления. Дрон сам грузиться, сам летит до пункта назначения и сам возвращается. Все здорово, но 12007-й итерации дрон, во время полета задел и оборвал трос промышленного альпиниста, моющего окна в высотном здании… Кто будет виновным в данном случае?Внедрение искусственного интеллекта (автоматический дрон), перевернет жизнь не только с технической точки зрения. Мы сами, наши привычки, действующие правила дорожно, авиационного, морского движения должны будут измениться.
Очень интересно, как все это разрулится.
Но без людей пока нельзя. Тут даже вопрос не технического, а скорее юридического характера. Кого сажать, если дрон покалечит человека?
Да и идеи по поводу примения в Банках очень далеки от реальности, хотя бы по тому, что карту могут опустошить в банкомате банка, не являющегося эмитентом карты. А видео клиентов банки между собой никогда передават не будут.
Второй существенной проблемой при использовании биометрии является закон о персональных данных. Если оператор укажет, что в его системах используется биометрия, то это «красная тряпка» для проверяющих поскольку подобные системы будет очень сложно и дорого защищать. Уровень защищенности подобной системы будет минимум УЗ2 (по ПП-1119), со всеми вытекающими (Приказы ФСТЭК 21 и ФСБ 378)
С точки зрения практической безопасности биометрия тоже имеет нюансы/проблемы Хотя бы по тому, что идентификационные признаки у человека меняются. На одной из конференций по ИБ коллеги описали ситуацию, когда внедрив систему авторизации по отпечаткам пальцев столкнулись с проблемой, что после выходных многие женщины не могли авторизоваться, поскольку их отпечатки «плыли», из-за того что они в выходные занимались влажной уборкой…
В целом конечно направление интересное, но в нем не хватает какой-то killer фичи, которая бы запустила процесс. Ведь про эти технологии известно уже очень давно, но широкого применения они так и не нашли.
1. Скорость
2. Возможность совершения операций доставки в тех случаях, когда нет подходящей транспортной инфраструктуры.
3 Резкое уменьшение участия людей в процессе.
Раньше люди пользовались стационарными телефонами и первые мобильники вызывали тот же вопрос «Зачем?» Зато сейчас стационарная телефонная связь теряет свою актуальность. Тоже самое будет и с дронами. К удобству быстро привыкаешь.
Кстати говоря использование дронов в России для доставки грузов не запрещено. Но процедура законной доставки очень замудрена, что практически полностью убивает весь смысл идеи. В США тоже можно использовать дронов для доставки, но в пределах прямой видимости оператора, управляющим полетом.
Если система доставки будет более менее точно выявлять кто именно совершил грабеж, то неотвратимость наказания будет существенным сдерживающим фактором. Например Amazon прорабатывает идею использования несольких дронов в операциях доставки. Один доставляет, другой контролирует процесс.
Но даже если ничего не делать, то с точки зрения бизнеса можно вводить лимиты ценности грузов доставляемых с помощью дронов и включать риск утери в стоимость товаров / услуг.
SIEM — это здорово, но нужны люди, которые будут туда смотреть. А в России один ИБист на компанию практически везде (за исключением 100 или 1000 больших компаний).
Возникает идея о внешенем SOC (Security Op. Center), но там цены мама не горюй.
Сейчас существует реальная ниша по обеспечению практической безопасности, но за разумные деньги, когда услуги аутсорса ИБ будут дешевле чем ИБ внутри компании. Но это будет не скоро, а может и никогда. Поскольку деятельность лицензируемая и емкая на инвестиции.
1. Есть легитимный электронный документ подписанный электронной подписью (например, платежное поручение).
2. Злоумышленник, вносит изменения в оригинальный документ изменения (например, подменяет реквизиты получателя).
3. Используя алгоритмы поиска коллизий, злоумышленник ищет такое дополнение в к модифицированному файлу, которое позволит сделать его хэш идентичным оригиналу.
4. Злоумышленник подменяет оригинальный документ модифицированным с таким же хэшом.
Так же следует понимать, что создание электронной подписи, в общем случае, это шифрование хэша документа на закрытом ключе подписанта, поэтому в модифицированном документе, электронная подпись будет валидной и соответствовать ЭП оригинального документа.
В таких случаях иногда идут дальше и в команде появляется человек ответственный за унификацию кода и документации.
А вообще без стандартизации в командной работе никуда.
Что делать когда специалист из комплекта выйдет? Специалисто-зависимые бизнес-процессы да еще на производстве… могут привести к большой беде.
Если мы говорим про старые системы, FoxPro, Cobol и др. я бы не сказал что там хорошо с безопасностью. Взять тот же DOS, Win 3.11 и другой раритет содержит баги на уровне архитектуры, знать язык разработки конкретного софта там вовсе не обязательно.
Пример. В DOS нет нормального разделения памяти процессов, одна софтина может получить доступ к памяти отведенной для другого софта, что и привело к созданию тысяч резидентных вирусов.
Поэтому безопасность данной конкретной системы — вещь вопросительная. К сожалению в статье отсутствует информация о том, что делала эта железка.
Все без исключения перечисленные варианты встречаются на практике. Даже «ненавистный» вариант 1.
Вариант 3 — по сути рекомендация Микрософт при публикации Exchange. Было бы здорово сегментировать и внутреннюю сеть (для защиты Back-End от АРМов сотрудников), но это на мой взгляд выходило за рамки данной статьи.
Вариант 4 — гайд для админов и работников ИБ при обосновании выбора защитных мер.
Разбиение сетей на подсети указано как принцип. Если публикуемых серверов много, выделите для них большего размера, например /16 (поскольку выход серверов Интернет в рассматриваемой статье базируется на DstNAT, сервера имеют внутренние адреса, вы можете по своему усмотрению управлять адресацией).
Вариант 5 — помимо прочих описанных в статье и комментариях случаев подходит для сетей компаний со сложной системой взаимоотношением владельцев, когда например инфраструктурой управляют люди лояльность которых вызывает сомнения, но на ситуацию повлиять нельзя.
Данный вариант показывает что можно построить безопасную сеть только с помощью серверов, без привлечения инфраструктурного оборудования. На back-end фильтруется (отбрасывается) все кроме целвых протоколов. Например, если back-end — СУБД, то оставляется только протокол взаимодействия с СУБД. Данный вариант был успешно внедрен на практике, для защиты платежных систем.
Безусловно, все рассмотренные меры внедрялись и показали свою работоспособность.
По ходу работы я видел большое количество реальных сетей (в то числе федеральных с десятками офисов по всей географии страны) и честно сказать ситуация с безопасностью была там «не очень», что собственно и натолкнуло меня написать данный гайд.
А, вообще, огромное спасибо за анализ, любая конструктивная критика помогает совершенствоваться.
Но в тоже время не все криптоалгортимы подвержены взлому через квантовый компьютер. Пример устойчивого алгоритма — одноразовый блокнот. Поэтому если ИТ-системы используют устойчивые криптоалгоритмы, то они взломаны не будут.
Отвечая на вопрос про FB или VK, злоумышленик с квантовым компьютером с высокой вероятностью сможет рассшифровать ваш трафик, при работе с данными сетями, а следовательно от туда вытащить пароли.
Вот такой неоднозначный ответ на простой вопрос.
На текущий момент есть грифы: коммерческая тайна, секретно, сов. секретно, особой важности.
Все это прописано в действующих Федеральных законах и Постановлениях Правительства.
Для меня как потребителя, антивирус является частью комплексной системы защиты от вредоносного кода.
Антивирусная защита не является темой статьи.
Если нужны знания нормативки и методик: УЦ МАСКОМ, Информзащита, АИС, Сюретль — welcome получите корочки которые подойдут для регуляторов.
Если нужно качнуть практическую безопасность — PentestIT, кстати они есть на Хабре или буржуйские CEH и др.
Главное понимать что за один курс невозможно стать и специалистом по методикам и практическим безопасником.
Очень хотелось бы работать в организации которая знает о неизвестных угрозах, пока что все живем в мире известного :)
И не уведите, так как предметом для моделей является вредоносный код, а не вредоносный файл. Для понимания разницы можно ознакомиться с описанием вируса slammer — это первое.
Второе, а что в этой модели вы хотите увидеть? Перечисление всех зловредов? Классификацию зловредов?
Это делать бесполезно — даказано историей. Все классификации вирусов, которые когда либо пытались сделать на практике рушатся, поскольку вирусмейкерам глубоко плевать, что их творение не вписываеться в те рамки, которые им придумали «умные дяди».
На практике, вредоносный код рассматривается как абстракция, которая имеет функционал нарушающий свойства безопасности информации (целостность, доступность и т.д.).
Детализироваться внутрь особого практического смысла не имеет, поскольку по сути нет разницы зашифрует ли ваши данные вирус, или же уничтожит или перешлет куда либо, главное что будут нарушены свойства безопасности информации, для поддержания которых и строится система защиты.
Современная практика обеспечения защиты от вредоносного кода базируются на борьбе с проникновением и выполнением вредоносного кода на защищаемом объекте, в вот это достигается уже большим числом способов. Начиная с антивирусов, организацией замкнутой программной среды, блокирование каналов проникновения вредоносного кода (Интернет, флешки) и др.
В заключение хочу ответить что модель угроз, сама в себе большого смысла не имеет, она нужна для формирования технического задания на построение системы защиты.
Это не утопия, это нормальная работа. Другое дело, что за квалификацию нужно платить. Специалисты на местах, администраторы должны имееть соответвующее образование. Просто админ не имеет права заниматься обеспечением ИБ (у госиков),
Как минимум VIPNET, Континент-АП
Сам пользовался http://www.securitycode.ru/products/security_studio_endpoint_protection/ но тут тру печаль, Outpost купил Яндекс, данный продукт походу свернули. На этот софт были самые лучшие сертификаты — как АВ, СОВ и МЭ
,
Еще раз повторюсь, так было всегда.