Здесь, в данном исследовании, речь идет о защите безналичных переводов по банковским счетам. Карточки это немного не то, они используют безналичные платежи как «транспорт денег».
Разрешать или не разрешать списание денег по только по номеру карты — вопрос принятия рисков банком-эмитентом (тот что, выдал карту). В большинстве случаев подобные операции запрещены. Исключение иногда делают только для больших торговых площадок, например, Amazon.
При этом, если у вас украли деньги с карты вы всегда можете опротестовать платеж. По российскому законодательству пп. 11, 12 ст. 9 161-ФЗ банк обязан вам вернуть деньги.
Это криптосредства построенные организацией лицензиатом ФСБ России «по крипте» с использованием рекомендованных ФСБ криптоалгоритмов, считай ГОСТов и с учетом требований, которые к этим системам предъявляет ФСБ.
КИБ — инструмент, который с вашим слов удобен и понятен. Ок, не спорю.
Но как любой инструмент он является лишь помощником для достижения какой-либо цели.
Так вот, вопросы:
1. Какие задачи вы с его помощью решаете?
2. На сколько измениться доходная часть бюджета вашей организации (по вашим оценкам) если вы эти задачи решать:
а) другими инструментами (например, OpenDLP / My DLP);
б) перестанете решать полностью;
в) с удвоенной силой и использовать дополнительные решения?
3. Как происходит смена паролей от корпоративных систем, которые перехватил «Кейлоггер» в случае увольнения аналитика, который их видел?
4. Как организована безопасность самого DLP? Как вы проверяйте, что установка DLP агента не создает дополнительных каналов для атаки? Как защищаются данные, хранящиеся в DLP, ведь, по сути, если вы собираете инфу со многих работников, архив DLP становится лакомым кусочком для вражеских «киберразведчиков».
На том же основании, по которому видеоданные собирают управляющие компании.
Видеоданные — да. Правовым основанием сбора видеоданных является «обеспечение безопасности» (это исключение в законе 152-ФЗ) и это легко реализуется путем установки соответствующей таблички про которые вы сказали ранее.
Но голос — не видео. Правоохранительные органы к этому могут весьма щепетильно отнестись (были прецеденты) — УК РФ 137, а горячо «любимый» Хабром Роскомнадзор, посчитать, что это информация избыточная для заявленных целей обработки (видеонаблюдение для обеспечения безопасности), поскольку сотни тысяч организаций довольствуются только видео и все ок. Как следствие административка по ч. 2 ст. 13.11 КоАП РФ
Задаю данные вопросы, поскольку неоднократно был свидетелем ситуаций, при которых проекты, подобные описанному здесь, фейлились из-за нарушений законодательства. Поэтому очень интересно как вы это все узаконили.
Подскажите пожалуйста на основании каких правовых норм, осуществляется запись звука при общении продавец-покупатель, а также передача персональных данных покупателя (его видеоизображение) от автозаправки в вашу компанию.
Вы подняли очень интересную проблему. Правильно указали все уязвимости, но с путями решения не все так однозначно.
Рассмотрим ваши предложения:
Адрес должен содержать структурированные данные
Адрес и сейчас структурирован. Город, улица, дом…
Адрес должен быть цифровым
Цифровой адрес гораздо тяжелее запомнить. Посудите сами, что проще habr.com или 178.248.237.68? Банковский счет в РФ имеет структурированный цифровой формат, например
407 03 810 801810000009 — что (грубо) означает счет физ лица в валюте РФ и номер счет в банке. Насколько это удобно? Для компа — супер, а для людей которые его вводят (или пишут рукой) в платежки это АД.
Текстовый адрес имеет существенно культурологическое значение. Историки проклянут момент когда вместо г. Владимир, будет 0100003004005, а к примеру г. Ковров 1212488487.
Адрес должен присваиваться пользователем
1. DNS имена — адреса придуманные пользователем. К чему это приводит? Например, вы интересный стартап, адрес у вас naviaddress.com, но вы не нравитесь дяде Коле. Он регистрирует адрес naviaddres.com и часть ваших пользователей уже у него. А он то им уже расскажет насколько вы «плохие».
2. Как по адресу придуманным пользователем искать человека, который взял деньги и не отдает?
3. Как быть с адрес-квотерами?
В итоге придем к тому, что процесс выдачи адреса все равно будет регулироваться.
User friendly address. Пользователю должно быть легко создавать и передавать адрес, переезжать со старым адресом на новое место и т.д.
Нужно определиться что мы адресуем. Физическое место положение или пользователя
Безопасность хранения данных.
Blockchain вещь хорошая, но не исключает полностью возможность махинации с адресами (например, проблема контроля 51% нод для bitcoin).
Что касается новой проблемы с MikroTik, то в этом случае используется сниффер, основанный на протоколе TZSP. Он в состоянии отправлять пакеты на удаленные системы при помощи Wireshark или его аналогов.
TZSP — протокол, используемый Mikrotik'ом при реализации функционала CALEA.
Wireshark — ПО, способное принять и понять (деинкапсулировать) трафик передаваемый Mikrotik'ом в формате TZSP.
Автоматизация производства приводит к возникновению угроз информационной безопасности.
Можете поделится вашими наработками в этом вопросе? Например, как ваша система (АИС Диспетчер) уживается с требованиями закона 187-ФЗ. Есть ли типовое решение учитывающее эти требования, какие средства защиты вы рекомендуете ставить и куда.
С русскими хакерами не так все просто. Если посмотреть их работу по банкам (тут и тут), то оказывается что многие русские хакреы вовсе не россияне, а украинцы, белорусы или жители других xUSSR стран.
Статья содержит материал, который может быть интересен большому количеству людей занимающихся схожими проблемами. Хоть я и не занимаюсь этой темой, но материал мне понравился. Прямой рекламы в статье нет, хоть и написана она корпоративном блоге, который ведется на хабре как раз для рекламы.
Неприязнь к кредитам, микрокредитам и прочим адским инструментам не повод хаить труд автора, который пишет то про SEO.
Этот пост часть из серии постов посвященных одной теме — обеспечению информационной безопасности платежей в банках.
Ранее в этом посте мы определили на базе каких требований и как будем строить систему защиты. После этого определили, что для обеспечения практической безопасности нам нужна модель угроз.
Затем, в этом посту, мы рассмотрели как вообще люди занимаются моделированием угроз ИБ. Узнали что есть kill chain, MTIRE ATT&CK Matrix и древовидные модели.
Теперь собственно сама работа. Мы отсюда и отсюда берем описание объекта защиты. Смотрим тут и тут что с реальными угрозами.
В результате данный и следующий пост, в которых в виде заготовок для внутренних документов изложена модель угроз с учетом всего выше перечисленного.
Ради интереса давайте вместе посмотрим как формировалась фраза.
Итак, что такое кража денег у банка? Первое, что приходит на ум — врываются люди в масках и забирают наличные из кассы. Хорошо, но не то. Нас интересуют переводы (платежи), то есть деньги в безналичном виде.
Ок, что такое кража безналичных денег? Это когда злодеи крадут ключи электронной подписи и делают платежку на перевод денежных средств. То есть кража это несанкционированный перевод?
А вот здесь сложнее. В ходе нормальной работы банка у него хоть и редко, но происходят операции, в результате которых происходит некорректное зачисление / списание средств на счетах. Банк обычно их оперативно устраняет и они остаются без последствий как для него, так и для клиентов.
Таким образом мы получаем ситуацию, когда кража это с несанкционированный перевод, который банк в штатном режиме не может откатить, а это может быть только в том случае, когда деньги «вышли» из банка.
Вот так и родилось, то что на первый взгляд показалось (с) «Веревка есть вервие простое». Можете посоветовать более удачную формулировку?
И что дает это «описание угроз с текущим уровнем детализации»?
Данное описание содержит в себе все угрозы, которые были реализованы в реальных банковских преступлениях последних лет. Его будет достаточно для обеспечения должного уровня безопасности большинства банков.
А судья кто?
Модель угроз — основная часть тех. задания на подсистему обеспечения информационной безопасности. Полнота и корректность модели напрямую влияет на качество создаваемой системы защиты. Соответственно «судьей» будет заказчик этой системы.
Но я думаю, что вы хотели спросить про другое.
Использованная методика моделирования не содержит ограничений на глубину декомпозиции. Начиная с абстрактного понятия электронный платежный документ мы в итоге можем прийти к XML-файлу, «invoice-20092018.xml», хранящемуся на файловом сервере «prod-fs27-internal.bank.local» с адресом 10.76.23.98. И здесь возникает вопрос как глубоко нужно капать и что считать требуемым уровнем детализации?
Для ответа на этот вопрос давайте рассмотрим конечных пользователей модели. Условно этих людей можно представить следующим образом:
Соответственно итоговым судьей будет человек, решающий свои задачи с помощью представленной модели. Если для его целей описания будет достаточно, то ок. Если чего-то не хватает то модель можно уточнить, не мешая при этом другим пользователям.
Классические «конечные» модели угроз, оперирующие защитой КДЦ (конфиденциальность, целостность, доступность) абсолютно не подходят для их обсуждения с не IT-специалистами.
Данный документ как раз и претендует на официозно-бюрократический статус. Он сделан таким образом, чтобы на его основании можно было быстро составить свой внутренний документ.
Хабр — информационно /развлекательный проект. Этот материал информационный, он для работы, поэтому и выбран сухой бюрократический стиль.
В модели, когда говорим, например, про АБС, мы не указываем АБС какой фирмы и как используется. Мы просто приводим абстрактную систему, сочетающую в себе основные черты реальных систем и указываем к ней абстрагированные угрозы.
На реальных объектах, где используются конкретные системы, конкретных производителей начинают всплывать нюансы, которые в базовой модели отразить невозможно.
Например, серверов у АБС может быть значительно больше 1, они могут выполнять разные функции и т.д. Эти нюансы должны быть отражены в результирующей частной модели угроз.
Чтобы отразить эти нюансы, специалист, разрабатывающий частную модель должен обладать определенным опытом и знаниями. Если такие опыт и знания есть, он делает уточняющую декомпозицию, если его нет — оставляет описание угроз с текущим уровнем детализации.
Здесь, в данном исследовании, речь идет о защите безналичных переводов по банковским счетам. Карточки это немного не то, они используют безналичные платежи как «транспорт денег».
Разрешать или не разрешать списание денег по только по номеру карты — вопрос принятия рисков банком-эмитентом (тот что, выдал карту). В большинстве случаев подобные операции запрещены. Исключение иногда делают только для больших торговых площадок, например, Amazon.
При этом, если у вас украли деньги с карты вы всегда можете опротестовать платеж. По российскому законодательству пп. 11, 12 ст. 9 161-ФЗ банк обязан вам вернуть деньги.
Это криптосредства построенные организацией лицензиатом ФСБ России «по крипте» с использованием рекомендованных ФСБ криптоалгоритмов, считай ГОСТов и с учетом требований, которые к этим системам предъявляет ФСБ.
Но как любой инструмент он является лишь помощником для достижения какой-либо цели.
Так вот, вопросы:
1. Какие задачи вы с его помощью решаете?
2. На сколько измениться доходная часть бюджета вашей организации (по вашим оценкам) если вы эти задачи решать:
а) другими инструментами (например, OpenDLP / My DLP);
б) перестанете решать полностью;
в) с удвоенной силой и использовать дополнительные решения?
3. Как происходит смена паролей от корпоративных систем, которые перехватил «Кейлоггер» в случае увольнения аналитика, который их видел?
4. Как организована безопасность самого DLP? Как вы проверяйте, что установка DLP агента не создает дополнительных каналов для атаки? Как защищаются данные, хранящиеся в DLP, ведь, по сути, если вы собираете инфу со многих работников, архив DLP становится лакомым кусочком для вражеских «киберразведчиков».
Видеоданные — да. Правовым основанием сбора видеоданных является «обеспечение безопасности» (это исключение в законе 152-ФЗ) и это легко реализуется путем установки соответствующей таблички про которые вы сказали ранее.
Но голос — не видео. Правоохранительные органы к этому могут весьма щепетильно отнестись (были прецеденты) — УК РФ 137, а горячо «любимый» Хабром Роскомнадзор, посчитать, что это информация избыточная для заявленных целей обработки (видеонаблюдение для обеспечения безопасности), поскольку сотни тысяч организаций довольствуются только видео и все ок. Как следствие административка по ч. 2 ст. 13.11 КоАП РФ
Задаю данные вопросы, поскольку неоднократно был свидетелем ситуаций, при которых проекты, подобные описанному здесь, фейлились из-за нарушений законодательства. Поэтому очень интересно как вы это все узаконили.
Подскажите пожалуйста на основании каких правовых норм, осуществляется запись звука при общении продавец-покупатель, а также передача персональных данных покупателя (его видеоизображение) от автозаправки в вашу компанию.
Рассмотрим ваши предложения:
Адрес и сейчас структурирован. Город, улица, дом…
Цифровой адрес гораздо тяжелее запомнить. Посудите сами, что проще habr.com или 178.248.237.68? Банковский счет в РФ имеет структурированный цифровой формат, например
407 03 810 801810000009 — что (грубо) означает счет физ лица в валюте РФ и номер счет в банке. Насколько это удобно? Для компа — супер, а для людей которые его вводят (или пишут рукой) в платежки это АД.
Текстовый адрес имеет существенно культурологическое значение. Историки проклянут момент когда вместо г. Владимир, будет 0100003004005, а к примеру г. Ковров 1212488487.
1. DNS имена — адреса придуманные пользователем. К чему это приводит? Например, вы интересный стартап, адрес у вас naviaddress.com, но вы не нравитесь дяде Коле. Он регистрирует адрес naviaddres.com и часть ваших пользователей уже у него. А он то им уже расскажет насколько вы «плохие».
2. Как по адресу придуманным пользователем искать человека, который взял деньги и не отдает?
3. Как быть с адрес-квотерами?
В итоге придем к тому, что процесс выдачи адреса все равно будет регулироваться.
Нужно определиться что мы адресуем. Физическое место положение или пользователя
Blockchain вещь хорошая, но не исключает полностью возможность махинации с адресами (например, проблема контроля 51% нод для bitcoin).
TZSP — протокол, используемый Mikrotik'ом при реализации функционала CALEA.
Wireshark — ПО, способное принять и понять (деинкапсулировать) трафик передаваемый Mikrotik'ом в формате TZSP.
Можете поделится вашими наработками в этом вопросе? Например, как ваша система (АИС Диспетчер) уживается с требованиями закона 187-ФЗ. Есть ли типовое решение учитывающее эти требования, какие средства защиты вы рекомендуете ставить и куда.
Если это не прикол, то интересно почему спирт, да и еще разбавленный.
Статья содержит материал, который может быть интересен большому количеству людей занимающихся схожими проблемами. Хоть я и не занимаюсь этой темой, но материал мне понравился. Прямой рекламы в статье нет, хоть и написана она корпоративном блоге, который ведется на хабре как раз для рекламы.
Неприязнь к кредитам, микрокредитам и прочим адским инструментам не повод хаить труд автора, который пишет то про SEO.
Ранее в этом посте мы определили на базе каких требований и как будем строить систему защиты. После этого определили, что для обеспечения практической безопасности нам нужна модель угроз.
Затем, в этом посту, мы рассмотрели как вообще люди занимаются моделированием угроз ИБ. Узнали что есть kill chain, MTIRE ATT&CK Matrix и древовидные модели.
Теперь собственно сама работа. Мы отсюда и отсюда берем описание объекта защиты. Смотрим тут и тут что с реальными угрозами.
В результате данный и следующий пост, в которых в виде заготовок для внутренних документов изложена модель угроз с учетом всего выше перечисленного.
Модель угроз ориентирована на практическую безопасность и банковскую нормативку.
Итак, что такое кража денег у банка? Первое, что приходит на ум — врываются люди в масках и забирают наличные из кассы. Хорошо, но не то. Нас интересуют переводы (платежи), то есть деньги в безналичном виде.
Ок, что такое кража безналичных денег? Это когда злодеи крадут ключи электронной подписи и делают платежку на перевод денежных средств. То есть кража это несанкционированный перевод?
А вот здесь сложнее. В ходе нормальной работы банка у него хоть и редко, но происходят операции, в результате которых происходит некорректное зачисление / списание средств на счетах. Банк обычно их оперативно устраняет и они остаются без последствий как для него, так и для клиентов.
Таким образом мы получаем ситуацию, когда кража это с несанкционированный перевод, который банк в штатном режиме не может откатить, а это может быть только в том случае, когда деньги «вышли» из банка.
Вот так и родилось, то что на первый взгляд показалось (с) «Веревка есть вервие простое». Можете посоветовать более удачную формулировку?
Использование БДУ ФСТЭК в обязательном порядке требуется только при формировании угроз для ГИС / МИС и для объектов КИИ.
Данное описание содержит в себе все угрозы, которые были реализованы в реальных банковских преступлениях последних лет. Его будет достаточно для обеспечения должного уровня безопасности большинства банков.
Модель угроз — основная часть тех. задания на подсистему обеспечения информационной безопасности. Полнота и корректность модели напрямую влияет на качество создаваемой системы защиты. Соответственно «судьей» будет заказчик этой системы.
Но я думаю, что вы хотели спросить про другое.
Использованная методика моделирования не содержит ограничений на глубину декомпозиции. Начиная с абстрактного понятия электронный платежный документ мы в итоге можем прийти к XML-файлу, «invoice-20092018.xml», хранящемуся на файловом сервере «prod-fs27-internal.bank.local» с адресом 10.76.23.98. И здесь возникает вопрос как глубоко нужно капать и что считать требуемым уровнем детализации?
Для ответа на этот вопрос давайте рассмотрим конечных пользователей модели. Условно этих людей можно представить следующим образом:
Соответственно итоговым судьей будет человек, решающий свои задачи с помощью представленной модели. Если для его целей описания будет достаточно, то ок. Если чего-то не хватает то модель можно уточнить, не мешая при этом другим пользователям.
Классические «конечные» модели угроз, оперирующие защитой КДЦ (конфиденциальность, целостность, доступность) абсолютно не подходят для их обсуждения с не IT-специалистами.
Хабр — информационно /развлекательный проект. Этот материал информационный, он для работы, поэтому и выбран сухой бюрократический стиль.
На реальных объектах, где используются конкретные системы, конкретных производителей начинают всплывать нюансы, которые в базовой модели отразить невозможно.
Например, серверов у АБС может быть значительно больше 1, они могут выполнять разные функции и т.д. Эти нюансы должны быть отражены в результирующей частной модели угроз.
Чтобы отразить эти нюансы, специалист, разрабатывающий частную модель должен обладать определенным опытом и знаниями. Если такие опыт и знания есть, он делает уточняющую декомпозицию, если его нет — оставляет описание угроз с текущим уровнем детализации.