IT-стандарты *

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

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

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

Рыская по интернетам, зашел на страницу про URI и спустя несколько часов осознал, как мало я знал об этом монстре. Признаюсь, до этого я думал, что URI это либо URL, либо URN. Но это не так! Есть и другие варианты идентификации ресурса в сети.

_{От автора перевода: Написанный далее текст может не совпадать с мнением автора перевода. Все высказывания идут от лица оригинального автора, просьба воздержаться от неоправданных минусов. Оригинальная статья выпущена в 2014 году, поэтому некоторые фрагменты кода могут быть устаревшими или "нежелаемыми".}

Содержание статьи:

В статье приведены доводы, которые ставят под вопрос правильность присутствия ORM в рамках ООП.

Привет! Проблема управления безопасностью зависимостей — supply chain security — в настоящее время как никогда актуальна. В качестве примера можно привести историю компании SolarWinds: исходный код разрабатываемой ею утилиты был скомпрометирован и среди клиентов компании распространилось вредоносное ПО. Также возникла тенденция по внедрению деструктивного кода разработчиками open-source проектов, широко используемых коммерческими компаниями.

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

Cyberpunk 2077. Был перенесён больше, чем на полгода.
Atomic Heart. Как ждали бета-версию в конце 2019 года, так и ждём.
Escape from Tarkov. Бета-тестирование длится уже почти пять лет.
Vampire: The Masquerade – Bloodlines 2. Перенесён на бооооольше, чем два года, сильно больше...
Bayonetta 3. За прошедшее с момента первого анонса время уже можно было выпустить игру, спин-офф, тизер сиквела и начать снимать сериал для Netflix - но неееет, всё ещё ждём...
И прочие, и прочие, и прочие.

Ладно, "Побег из Таркова" и Atomic Heart: амбиции, нехватка опыта, технологическая болтанка. Допустим.
Но остальные игры - их как минимум продьюсировали видные деятели в этой сфере. Это не первое их родео в мир ААА-проектов. Что ж так не повезло то им?

А если сместить фокус с геймдева и окинуть взглядом IT в целом?
Куда ни глянь - "не попали в дедлайн", "кранч", "лучше MVP в проде, чем срыв сроков в ххх", etc, etc...

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

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

Когда начинаешь изучать смарт карты, то все выглядит достаточно понятно и логично: команды APDU несложны и описаны в ISO 7816-4, интерфейс winscard описан в MSDN. В глубины PCSC погружаться особо и не приходится. Первые программы можно написать довольно быстро. Непонятные особенности вылезают чуть позже, и выясняется, что известные два протокола T=0 и T=1 на самом деле совсем разные протоколы, и они просто похожи друг на друга. Поначалу возникает соблазн работать с ними одинаково, а это может доставить много хлопот вплоть до сбоя коммуникации в самый неожиданный момент.

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

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

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

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

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

На неделе один из участников Hacker News запустил тематический тред с целью узнать, как «связать» компьютер, колонки и другую акустику в единую звуковую систему.

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

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

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

Я хотел бы кратко рассказать о таких форматах данных, распространенных в ИТ-индустрии, в том числе в области инфраструктур открытых ключей (ИОК), смарт-картах, включая документы нового поколения на базе смарт-карт, в мобильной связи. Хотя рассматриваемые форматы и связаны с ASN.1, но некоторые из них ушли далеко за пределы этой области. О некоторых из них многие знают, но не все знают настолько, чтобы, допустим, уметь отличать BER от DER, а некоторые варианты типа PER вообще являются экзотикой.

Глубоко в тему погружаться не буду. Просто познакомлю с главными особенностями, чтобы понимать, что это такое и с чем это едят. Досконально и в полном объеме всё это описано в соответствующих стандартах ITU-T X.690 и ISO 7816.

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

Правила абстрактной нотации (ASN.1) используются, когда надо специфицировать формат некой структуры данных. Сами правила описаны в стандартах ITU-T X.680–X.683. Пожалуй, что наиболее распространенный вариант применения — это форматы сертификатов X.509 и всего, что имеет к ним отношение. Пример текстовой нотации может выглядеть как-то так:

Люди знакомые с ITSM/ITIL знают о том, что, описывая любую услугу, мы можем выделить характеристики «полезности» (utility) и «гарантии» (warranty). Также нередко обсуждаются характеристики, описывающие опыт (experience: user experience, UX и customer experience, CX).
Как соотносятся эти понятия? Можем ли мы говорить о том, что experience — это ещё одна, третья группа характеристик? Что вообще даёт это понятие, и почему utility и warranty может быть недостаточно?

Привет! Меня зовут Александра, я инженер по информационной безопасности в Delivery Club. Мы используем Go в качестве основного языка для разработки Web-API и представляем вашему вниманию краткое руководство по быстрой проверке сервиса на соответствие базовым требованиям безопасности. Представленную ниже информацию можно адаптировать под проекты, написанные и на других языках.

31 марта 2022 года на сайте IETF был официально размещен текст рабочего документа (копия 1, копия 2) New UUID Formats (далее – стандарт), который должен формально обновить, а фактически заменить давно устаревший и изначально ущербный RFC 4122.

В долгих и жарких спорах удалось выработать стандарт высокого качества. Можно надеяться, что этот стандарт заменит многочисленные «самоделки» энтузиастов и отдельных компаний: ULID, KSUID, CUID и т.д., а в СУБД будут встроены генераторы UUID новых форматов, предназначенных для ключей высоконагруженных систем.

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

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

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

Но, прежде чем рассылать резюме и отклики на подобные вакансии важно привести свое СV в принятый в Европе и Америке вид.