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

Приветствую уважаемую публику Хабра от лица условно анонимного представителя компании «Актив», занимающейся производством небезызвестных средств аутентификации и электронной подписи.

В этой статье хотелось бы рассказать об одном из менее известных направлений деятельности подразделения Рутокен, связанного с обеспечением киберфизической безопасности. В рамках данного направления компания уже не первый год производит встраиваемые в управляющее и управляемое оборудование устройства линейки Рутокен Модуль. Не так давно в эти устройства (а заодно в токены и смарт-карты Рутокен ЭЦП 3.0) добавилась поддержка протокола CRISP, и это отличный повод рассказать и о самом протоколе, и о принципах интеграции устройств Рутокен Модуль, и об организации процессов разработки в компании.

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

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

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

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

В этой статье я рассказала, как и зачем в Компании «Актив» мы делаем видеоинструкции на примере одного важного кейса: здесь про цели, сценарий, запись звука и программы для монтажа.

Должно быть интересно!

Добрый день, Хабр! 

В данной заметке я постараюсь сравнить два разных подхода к задаче запутывания машинного кода – это протектор и обфускатор, построенный на базе LLVM-фреймворка. Нам пришлось с этим столкнуться, когда возникла задача защиты библиотек Guardant под разные операционные системы и разные ARM-архитектуры. Для x86/x64 мы используем протектор Guardant Armor, который является полностью нашей разработкой. В случае ARM-архитектуры было принято решение параллельно посмотреть в сторону открытых обфускаторов на базе LLVM с целью их модификации и использования для защиты своих продуктов.

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

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

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

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

В этой статье мы рассмотрим достоинства и недостатки блокчейн‑технологий и попытаемся классифицировать сферы их применения, после чего дадим обзор формализованных методов выбора: «блокчейн или не блокчейн».

Привет, Хабр! Недавно мы с коллегами стали вспоминать, как выглядела работа с электронной подписью (ЭП) и ключевые носители, когда мы только начали работать в этой области. Мы искренне удивились тому, как за такое короткое время технологии шагнули вперед. Так родилась идея для этой статьи. Она для всех, кто когда‑нибудь имел дело с настройкой компьютера для работы с ЭП, отправкой отчетности в контролирующие органы, знает, что такое токены, оказывал техническую поддержку по работе с электронным документооборотом. Особенно для тех, кто помнит Windows XP, шариковые мышки и дискеты.

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

Муки самоопределения, кринжовые стажировки и собеседования, первый опыт, портфолио редактора...или как филолог искала работу в ИТ.

В этой статье — об увлекательно случайной истории пути от стажера-копирайтера до технического писателя. Как мне тут работается, почему не хочется уходить и помогает ли мне образование филолога. Отвечаем вместе на вопрос "Есть ли гуманитариям место в ИТ?".

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

Различные методы эволюции ключей (терминология не устоялась, предпочитаю использовать такой перевод словосочетания «key-evolving techniques») асимметричных криптоалгоритмов позволяют защититься от компрометации секретных ключей путем периодической модификации ключевых пар. Подобная защита направлена не на предотвращение компрометации секретного ключа, а на минимизацию последствий такой компрометации: поскольку ключи периодически модифицируются, эволюционируют, данные методы позволяют ограничиться отрицательным воздействием компрометации ключа на свойство целостности или конфиденциальности сообщений, зашифрованных или подписанных только в течение определенного, относительно короткого периода, оставляя защиту сообщений других периодов ненарушенной. Большинство протоколов с эволюцией ключей подразумевает достаточно активный обмен сообщениями между сторонами защищенного обмена данными. При этом бывают сценарии, когда возможности для интерактивного взаимодействия у сторон отсутствуют.

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

Приветствую, Хабр! Меня зовут Сергей Панасенко, я работаю в компании «Актив» директором по научной работе. По роду занятий мне достаточно часто требуется знание (а иногда и решение вопросов практического применения) нормативных документов регуляторов в области ИБ, в том числе приказов ФСТЭК России, которые устанавливают требования по защите данных в информационных системах различного назначения (подробнее о них – под катом), а также меры по защите информации, применимые для обеспечения соответствия данным требованиям. Одна из таких мер – контроль перемещения машинных носителей информации за пределы контролируемой зоны, вызвала мой  особый интерес. Данная мера выглядит важной для обеспечения безопасности, но ее реализация напрямую (проверка сотрудников на выходе с предприятий) выглядит весьма затруднительной: носители (для определенности – USB-флешки) становятся всё более миниатюрными, и проверка их отсутствия у выходящего с территории сотрудника может превратиться в проблему и для сотрудников, и для проверяющих.

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

Итак, начнем.

Привет, Хабр! Я Анастасия Дмитриева, работаю ведущим техническим писателем в компании “Актив”. Долгое время я была единственным техническим писателем в компании. Но в какой-то момент мне стало понятно, что задач очень много, и одной мне просто не справиться. Я начала поиск junior-а. Особой спешки не было, и я понимала, что я могу потратить какое-то время и научить его всему. 

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

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

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

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

Для .Net, например, есть ASP.NET Boilerplate (https://aspnetboilerplate.com/), полностью реализующая все компоненты DDD – Entity, Value, Repository, Domain Service, Unit of Work и еще много всего. Но мы для одной из своих внутренних информационных систем используем Go. 

Мы решили использовать фреймворк Flamingo, распространяемый под лицензией MIT. Он разработан немецкой компанией AOE GmbH в 2018 году и к настоящему моменту “дорос” до версии 3.4 и до 331 звезды на Github. Flamingo используется в информационных системах аэропортов Окланда, Франкфурта и Хитроу, а также в T-Mobile.

Данный текст не является руководством по внедрению двухфакторной аутентификации в Linux на основе токенов / смарт-карт. Подобные (и весьма подробные) руководства вы сможете найти как на сайтах производителей токенов, так и операционных систем. Я лишь хочу перечислить возможные варианты реализации 2ФА, а заодно побудить ответственных за информационную безопасность предприятия реализовать столь необходимую защиту от кражи паролей пользователей.

Друзья и коллеги, всем здравствуйте!

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

О том, как в компании организовать оперативное получение "отпускной" (и не только) информации далее и пойдет речь.

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

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

Автор серии публикаций - Алексей Лазарев, руководитель Департамента защиты кибер-физических систем Компании «Актив»

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

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

Улитка заходит в бар, но бармен заявляет: "У нас строгая политика в отношении улиток!", — и ногой выпихивает ее на улицу. Через неделю улитка возвращается в бар и говорит бармену: "Ну и зачем ты это сделал!?"

А ведь все еще помнят, как прекрасно начиналось развитие интернета вещей. Все, что связано с IoT, IIoT, M2M поднимало волну хайпа, уступавшую разве что криптовалютной истерии. Огромное число стартапов, многие из которых казались настоящим прорывом для своего времени (“Цифровизация экономики”, “Индустрия 4.0” и др.) пробуждало немалый интерес как среди специалистов, так и у государственных лиц. Одни видели в IoT возможности реализации смелых и перспективных идей, другие – эффективный инструмент для привлечения в экономику регионов новых ресурсов. Мы же, как "безопасники", не оставались в стороне и пристально следили за развитием событий. Вот какие наблюдения нам удалось сделать.

Аспекты безопасности в IoT - в выигрыше предусмотрительные

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

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

Не так давно Компания «Актив» предоставила в открытый доступ на GitHub исходный код версии продукта Рутокен VPN Community Edition. В этой статье мы хотим рассказать зачем и для кого мы это сделали, как можно воспользоваться исходным кодом, и чего ожидаем в результате от сообщества разработчиков.

Зачем нужен еще один VPN? 

Как известно, события последних полутора лет стимулировали развитие рынка VPN, и сегодня он переживает эпоху роста. Конкуренция на этом рынке значительная, цены на услуги растут. Одновременно Россия в 2021 году остается в десятке топ-потребителей VPN сервисов, т.е. спрос на рынке присутствует.  

Создавая Рутокен VPN, основной «фишкой» мы решили сделать ориентацию на малый и средний бизнес, т.е. на компании, которые, вероятно, не имеют в штате постоянного и высококвалифицированного системного администратора. Именно для таких компаний мы сделали версию продукта Рутокен VPN, которая упрощает настройку VPN-сервера и клиента. Кроме того, нашей целью было предоставить разработчикам возможность развивать интересный и востребованный продукт, совершенствовать свои навыки, получая таким образом бесценный опыт и дополнительные очки к своему CV. Не скроем также, что заинтересованы и в советах участников профессионального сообщества по улучшению Рутокен VPN, которым будем максимально рады. 

В этой статье мы познакомимся со стандартом PKCS#11, предназначенным для работы с различными криптографическими устройствами. Для демонстрации мы будем использовать токены и смарт-карты Рутокен ЭЦП 2.0.