Добрый день.
Хотелось бы задать несколько вопросов для саморазвития.
1) Можете поделиться с общественностью составом применяемых средств защиты информации? Особенно интересуют опыт применения решений для защиты гипервизоров.
2) В приведенных схемах защита от DDoS применена только для защиты каналов обеспечивающих работу ВМ заказчиков, для канала управления (ваши админы) такой защиты нет. Почему?
Подскажите, как с точки зрения информационной безопасности вами оценивается использование инженерами планшетов с подключением к внешним сервисам для своей работы?
Если посмотреть на последнюю картинку то можно предположить что обходы совершаются/логируются с помощью сервиса docs.google.com. Кроме того планшеты используются сотрудниками для личных целей, о чем могут говорить наличие в избранном ссылки на Ютюб, Кубики и т.д.
С одной стороны явной дыры в этом конечно нет, но создаются предпосылки постороннего вмешательства в процесс мониторинга (взлом аккаунта docs.google.com, кража планшета и т.д.), а также зависимость бизнес-процесса от доступности сервисов google.
Интересно, почему для этих целей была выбрана именно такая схема, а не был разработан собственный изолированный корпоративный сервис?
В статье даны универсальные рекомендации, которые подойдут практически для любых случаев. Для читателей интересующихся подобными документами можно порекомендовать посмотреть лучшие практики ИБ в SANS Best practice.
Возвращаясь к политике безопасности следует отметить что кроме мероприятий по защите инфраструктуры необходимо также выстраивать бизнес-процессы управления безопасностью включая: управление доступом, ведение учета, повышения осведомленности и т.д.
О составе подобных бизнес-процессов можно узнать например из комплекса стандартов СТО БР ИББС
При совершении операций внутри страны банки крайне редко запрашивают подтверждение (разве что по очень крупным сделкам). Вы можете перевести деньги контрагенту без каких-либо оснований – требуется лишь отправить в банк поручение осуществить платеж (платежное поручение).
Тут конечно вопрос, что считать очень крупной сделкой. А вообще ПОД/ФТ (115-ФЗ) никто не отменял и там есть критерии обязательного контроля сделок. Если сумма перевода в них попадет, то без доказательств законности перевод не сделают (разрешительная система).
В России установлены определенные требования к организации и функционированию СКЗИ. Эти требования более жесткие нежели, та модель которую предлагает CryptoAPI. Некоторые вопросы вообще не стандартизированы и каждый производитель делает как хочет, например, форматы и способы хранения закрытых ключей. Для инфо в ГОСТ 28147-89 узлы замен отнесены к «долгоиграющему» ключевому материалу, в то время как в импортных стандарты они захардкожены в сам стандарт.
Что я хочу как потребитель — чтобы ключи сделанные на одном СКЗИ могли работать на другом, чтобы для доступа к госсайтам можно было использовать любой сертифицированный криптопровайдер, чтобы производители СКЗИ конкурировали между собой качеством продуктов и поддержкой, а не тем что один сидит на одной «кормушке», а другой на другой.
Но для этого нужна стандартизация, как API, так и форматов. Первые шаги подобной стандартизации сделаны через RFC 4357 с ним появились стандартные узлы замен (S-box). Но этого мало. В статье автор справедливо замечает, что госсайты навязывают определенные СКЗИ.
Но разработчиков тоже можно понять, они делают под определенное СКЗИ, потому что нет универсального API.
Если вы скажете: «А как же MS Crypto API?' Оно не покрывает всех вопросов связанных с работой отечественными СКЗИ. Ради интереса почитайте Руководство программиста для нескольких криптопровайдеров различных производителей.
Без „русского болта“, не обойтись.
P.S. Создание универсального API под любые криптоалгоритмы и любые криптопримитивы это миф, который разбивается об разнообразие выдумок разработчиков систем шифрования.
В этом случае речь уже будет идти не об MS Windows, Interner Explorer и CSP, а о браузерах или других программ с поддержкой https с российскими шифрсьютами
То что вы предлагаете требует переделки практически всего Российского законодательства и подзаконных актов в части регулирования ИБ, электронной подписи и СКЗИ.
«Госсайты» используют квалифицированную ЭП. Требования к квалифицированной ЭП по закону (63-ФЗ) включают в себя использование сертифицированных СКЗИ.
СКЗИ сертифицируется под определенные требования безопасности для применения в конкретной среде функционирования. Сертифицированные экземпляры СКЗИ должны использоваться неизменными, то есть контрольная сумма того, что стоит и того что сертифицировано должна совпадать. Сертифицированные СКЗИ за редким исключением (КриптоПРО CSP 3.8) нельзя вывозить за рубеж.
А теперь вернемся к браузеру и облачному токену предлагаемыми вашей компанией. Они не плохие с точки зрения пользователя. Но с точки зрения действующей законодательной схемы, они в нее не вписываются, нет сертификатов ФСБ. Их применение порождает юридические риски для пользователя в части опротестования электронной подписи.
Нет у нас понятия шифросьюты, у нас есть понятие СКЗИ. Написать програмулину реализующую ГОСТ шифрования могут студенты 3+ курса нормального ВУЗа. Но то что результат ее работы будет совпадать с результатом работы серт. СКЗИ не является основанием для применения ее в гос. органах.
Вырастет компьютерная грамотность населения России, работы у ФАС России станет меньше, никто больше не будет говорить (а точнее навязывать) об использовании конкретных средств, речь будет идти только о стандартных интерфейсах и протоколах
В теории звучит здорово.
На практике, Российские банки сдают отчетность в американскую налоговую (FATCA), там нет ни каких требований по конкретным средствам, есть требования по стандартам, делай чем хочешь, хоть сам пиши.
Но по факту сформировать сообщение это такой квест, по сравнению с которым подобрать нужный браузер для доступа к госсайту, это просто детский лепет. Звонить в Америку узнавать как сделать в итоге приходится не один раз. В том же удостверяющем центре, занимающимся выпуском ключей для госзакупок приходят люди и приносят на флешках вместо сертификатов закрытые ключи, хотя там все четко «навязано» чем пользоваться надо.
Так что свобода, это не значит быстро и просто.
Лично я за то, чтобы навязывания не было.
Начать можно с простого, через ТК-26 сформировать модель CSP, которая бы не зависела от конкретного производителя криптосредств эдакий «Русский CSP».
Хочешь работать с госсайтом твой криптопровадер должен уметь функционал «Русский CSP 1.0» и т.д., а вот кто напишет этот провайдер компания LISSI, КриптоПРО, МО ПНИЭИ,… без разницы.
Начать можно с простого — стандартизировать модель и формат хранения закрытого ключа, чтоб закрытые ключи выпущенные одним СКЗИ подходили для других СКЗИ. Подкиньте идею в ТК-26, обычных смертных (не разработчиков СКЗИ) они не слушают.
Кроме аудита железа и софта надо не забывать про аудит ИБ.
По крайней мере узнать где какие есть криптоключи и когда они заканчиваются. Методику проведения подобного аудита глянуть в статье Аудит СКЗИ и криптоключей
Все это уже проходили, правда не из углекислого газа, а из нефти и иногда из биогаза (метана) — гаприн (http://masterok.livejournal.com/2720715.html)
Сначала тоже говорили как все хорошо, потом как начали делать мнение поменялось и производство вредное и продукт не очень… Хотя сейчас есть попытки возродить. Здесь будет тоже самое думаю.
Соединение защищенной стороны, которое обычно открывается между прокси-сервером и конечным хостом, может обеспечить более низкое шифрование TLS, так как оно находится за устройствами/периметром безопасности.
С точки зрения теории логина понятна. С точки зрения практики какой выигрыш дает переход с AES-256 на AES-128? Когда я проводил подобный эксперимент прирост был незначительным. Есть смутное чувство, что «тормоза» не из-за шифрования как такого, а из-за возникающих в процессе передачи трафика задержках.
К сожалению, этот алгоритм оказался единственным в openssl, который допускает шифрование/дешифровку маленьких блоков данных (предполагается по смыслу статьи — ключей для алгоритмов симметричного шифрования) с помощью асимметричных криптоалгоритмов
Не совсем понятное утверждение. Diffe-Hellman подобное может. Например, RFC4357 для отечественных ГОСТов описывает механизм способы применения DH — для защиты сессионных ключей.
протоколы аутентификации PAP и CHAP, имеет хорошую репутацию и широко распространен
PAP — передает пароль в открытом виде, CHAP — использует небезопасный MD5 хэш.
С точки зрения безопасности использовать данные протоколы можно только внутри защищенного соединения, например IPSec туннеля. В чистом виде они защиты не дают.
«Как начинать тушить огонь до пожара» — а смысл? так даже картошку себе не пожаришь.
Приведенные рекомендации по ИБ для очень хорошо подойдут для сферического коня в вакууме. Применительно к реальной жизни безопасность все таки строится от существующей инфраструктуры.
Пересаживать всех на Win10 при условии, что Win7 работает и обновляется выглядит сомнительной идей. Более того, много «чудо»-софта наколенной разработки но бизнес-критически важного перестанет работать совсем, что тогда?
Обновления должны ставится регулярно, не реже раза в две недели.
Обновления нужны это факт, но просто ставить апдейты — путь к остановке системы. Примеры «плохих» апдейтов уже приводили выше. Ставить апдейт без теста нельзя.
Я думаю реальной скоростью будет не реже раза в месяц для апдейтов ОС в инфраструктур компаний среднего бизнеса 1000+ человек, при условии, что у ИТ будет специально выделенное время для тестирования апдейтов, если его не будет, то не реже раза в квартал. Для апдейтов других систем (СУБД, драйвера, ...) лаг только увеличится.
Критикам предлагаю составить в уме перечень действий, которые нужно предпринять для обновления BIOS на ферме гипервизора с сотней виртуалок, часть которых работает 24/7. Ну и соответственно составить roll-back план.
Скажите пожалуйста, как вы оцениваете перспективы накопления электроэнергии от солнечных батарей за счет использования гидроаккумуляторов по принципу ГАЭС
Хотелось бы задать несколько вопросов для саморазвития.
1) Можете поделиться с общественностью составом применяемых средств защиты информации? Особенно интересуют опыт применения решений для защиты гипервизоров.
2) В приведенных схемах защита от DDoS применена только для защиты каналов обеспечивающих работу ВМ заказчиков, для канала управления (ваши админы) такой защиты нет. Почему?
Подскажите, как с точки зрения информационной безопасности вами оценивается использование инженерами планшетов с подключением к внешним сервисам для своей работы?
Если посмотреть на последнюю картинку то можно предположить что обходы совершаются/логируются с помощью сервиса docs.google.com. Кроме того планшеты используются сотрудниками для личных целей, о чем могут говорить наличие в избранном ссылки на Ютюб, Кубики и т.д.
С одной стороны явной дыры в этом конечно нет, но создаются предпосылки постороннего вмешательства в процесс мониторинга (взлом аккаунта docs.google.com, кража планшета и т.д.), а также зависимость бизнес-процесса от доступности сервисов google.
Интересно, почему для этих целей была выбрана именно такая схема, а не был разработан собственный изолированный корпоративный сервис?
Возвращаясь к политике безопасности следует отметить что кроме мероприятий по защите инфраструктуры необходимо также выстраивать бизнес-процессы управления безопасностью включая: управление доступом, ведение учета, повышения осведомленности и т.д.
О составе подобных бизнес-процессов можно узнать например из комплекса стандартов СТО БР ИББС
Тут конечно вопрос, что считать очень крупной сделкой. А вообще ПОД/ФТ (115-ФЗ) никто не отменял и там есть критерии обязательного контроля сделок. Если сумма перевода в них попадет, то без доказательств законности перевод не сделают (разрешительная система).
Что я хочу как потребитель — чтобы ключи сделанные на одном СКЗИ могли работать на другом, чтобы для доступа к госсайтам можно было использовать любой сертифицированный криптопровайдер, чтобы производители СКЗИ конкурировали между собой качеством продуктов и поддержкой, а не тем что один сидит на одной «кормушке», а другой на другой.
Но для этого нужна стандартизация, как API, так и форматов. Первые шаги подобной стандартизации сделаны через RFC 4357 с ним появились стандартные узлы замен (S-box). Но этого мало. В статье автор справедливо замечает, что госсайты навязывают определенные СКЗИ.
Но разработчиков тоже можно понять, они делают под определенное СКЗИ, потому что нет универсального API.
Если вы скажете: «А как же MS Crypto API?' Оно не покрывает всех вопросов связанных с работой отечественными СКЗИ. Ради интереса почитайте Руководство программиста для нескольких криптопровайдеров различных производителей.
Без „русского болта“, не обойтись.
P.S. Создание универсального API под любые криптоалгоритмы и любые криптопримитивы это миф, который разбивается об разнообразие выдумок разработчиков систем шифрования.
То что вы предлагаете требует переделки практически всего Российского законодательства и подзаконных актов в части регулирования ИБ, электронной подписи и СКЗИ.
«Госсайты» используют квалифицированную ЭП. Требования к квалифицированной ЭП по закону (63-ФЗ) включают в себя использование сертифицированных СКЗИ.
СКЗИ сертифицируется под определенные требования безопасности для применения в конкретной среде функционирования. Сертифицированные экземпляры СКЗИ должны использоваться неизменными, то есть контрольная сумма того, что стоит и того что сертифицировано должна совпадать. Сертифицированные СКЗИ за редким исключением (КриптоПРО CSP 3.8) нельзя вывозить за рубеж.
А теперь вернемся к браузеру и облачному токену предлагаемыми вашей компанией. Они не плохие с точки зрения пользователя. Но с точки зрения действующей законодательной схемы, они в нее не вписываются, нет сертификатов ФСБ. Их применение порождает юридические риски для пользователя в части опротестования электронной подписи.
Нет у нас понятия шифросьюты, у нас есть понятие СКЗИ. Написать програмулину реализующую ГОСТ шифрования могут студенты 3+ курса нормального ВУЗа. Но то что результат ее работы будет совпадать с результатом работы серт. СКЗИ не является основанием для применения ее в гос. органах.
В теории звучит здорово.
На практике, Российские банки сдают отчетность в американскую налоговую (FATCA), там нет ни каких требований по конкретным средствам, есть требования по стандартам, делай чем хочешь, хоть сам пиши.
Но по факту сформировать сообщение это такой квест, по сравнению с которым подобрать нужный браузер для доступа к госсайту, это просто детский лепет. Звонить в Америку узнавать как сделать в итоге приходится не один раз. В том же удостверяющем центре, занимающимся выпуском ключей для госзакупок приходят люди и приносят на флешках вместо сертификатов закрытые ключи, хотя там все четко «навязано» чем пользоваться надо.
Так что свобода, это не значит быстро и просто.
Лично я за то, чтобы навязывания не было.
Начать можно с простого, через ТК-26 сформировать модель CSP, которая бы не зависела от конкретного производителя криптосредств эдакий «Русский CSP».
Хочешь работать с госсайтом твой криптопровадер должен уметь функционал «Русский CSP 1.0» и т.д., а вот кто напишет этот провайдер компания LISSI, КриптоПРО, МО ПНИЭИ,… без разницы.
Начать можно с простого — стандартизировать модель и формат хранения закрытого ключа, чтоб закрытые ключи выпущенные одним СКЗИ подходили для других СКЗИ. Подкиньте идею в ТК-26, обычных смертных (не разработчиков СКЗИ) они не слушают.
По крайней мере узнать где какие есть криптоключи и когда они заканчиваются. Методику проведения подобного аудита глянуть в статье Аудит СКЗИ и криптоключей
Сначала тоже говорили как все хорошо, потом как начали делать мнение поменялось и производство вредное и продукт не очень… Хотя сейчас есть попытки возродить. Здесь будет тоже самое думаю.
Он вроде как умеет все что надо, стоит не дорого да и специалистов много.
С точки зрения теории логина понятна. С точки зрения практики какой выигрыш дает переход с AES-256 на AES-128? Когда я проводил подобный эксперимент прирост был незначительным. Есть смутное чувство, что «тормоза» не из-за шифрования как такого, а из-за возникающих в процессе передачи трафика задержках.
Не совсем понятное утверждение. Diffe-Hellman подобное может. Например, RFC4357 для отечественных ГОСТов описывает механизм способы применения DH — для защиты сессионных ключей.
PAP — передает пароль в открытом виде,
CHAP — использует небезопасный MD5 хэш.
С точки зрения безопасности использовать данные протоколы можно только внутри защищенного соединения, например IPSec туннеля. В чистом виде они защиты не дают.
Приведенные рекомендации по ИБ для очень хорошо подойдут для сферического коня в вакууме. Применительно к реальной жизни безопасность все таки строится от существующей инфраструктуры.
Пересаживать всех на Win10 при условии, что Win7 работает и обновляется выглядит сомнительной идей. Более того, много «чудо»-софта наколенной разработки но бизнес-критически важного перестанет работать совсем, что тогда?
Обновления нужны это факт, но просто ставить апдейты — путь к остановке системы. Примеры «плохих» апдейтов уже приводили выше. Ставить апдейт без теста нельзя.
Я думаю реальной скоростью будет не реже раза в месяц для апдейтов ОС в инфраструктур компаний среднего бизнеса 1000+ человек, при условии, что у ИТ будет специально выделенное время для тестирования апдейтов, если его не будет, то не реже раза в квартал. Для апдейтов других систем (СУБД, драйвера, ...) лаг только увеличится.
Критикам предлагаю составить в уме перечень действий, которые нужно предпринять для обновления BIOS на ферме гипервизора с сотней виртуалок, часть которых работает 24/7. Ну и соответственно составить roll-back план.
Скажите пожалуйста, как вы оцениваете перспективы накопления электроэнергии от солнечных батарей за счет использования гидроаккумуляторов по принципу ГАЭС
Если нет то как реализовать функционал облачного токена в частном облаке?