Интерфейс пользователя должен быть удобным! Но как это измерить?

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

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

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

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

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

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

#dev #управление #пятница

Maintenance и Freezing

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

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

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

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

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

#dev #управление #пятница

Наверно, это очевидно, что на КПЭ команд разработки положительно влияют выполненные ими CR/BRQ (Change Request, Business ReQurements) и негативно влияют дефекты (ошибки, bugs). Однако, даже от таких гигантов как Microsoft мы до сих пор нередко слышим, что какой-то баг - это вовсе не баг, а фича, что лишний раз подтверждает, что даже в зрелых конторах дефекты не всегда распознают как дефекты, или .... у них те же КПЭ - плюсы в карму за фичи, и минусы за баги.

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

#dev #пятница

Пресс-релиз о разрыве отношений повышает риск мгновенной кармы

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

Подобные пресс-релизы хорошо характеризуют поставщика: его предложение такое хорошее, что оно выбирается столь успешным потребителем и т.д. и т.п. А вот официальных публикаций о разрыве отношений не так много (ну, разве что вот пример, но не из ИБ, да и я, возможно, предвзят к "Студии Лебедева", работал с ними в 2007, надеюсь, сейчас они достигли зрелости), неверно, на то есть объективные причины, а, вполне возможно, факт того, что кто-то из заказчиков остался без защиты, вообще стоит скрывать. Но надо понимать, что в современном мире скрыть факты разрыва отношений крайне сложно, а сам факт этого повышает риск быть атакованным.

Немалая доля клиентов пришла в MDR после инцидентов: их пошифровали, украли данные и слили, и пр. , потом их полечили, а в качестве кибергигиены\кибериммунитета, для неповторения подобного инцидента, предложили MDR.

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

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

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

#пятница #MDR #vCISO

Как правильно: "SIEM" или "SOC"?

Некоторое время назад ЛК и К2К делали исследование о SOC-ах к подготовке которого немного приложился и ваш покорный слуга. Вот ссылка на пресс-релиз, а отчет будет доступен попозже.

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

Причин, почему не имеющие SIEM не планируют его внедрять, достаточно много, но я бы выделил две, как наиболее часто встречающиеся, по моему мнению.
- SIEM, как правило, является выдленной системой ИБ, тогда как собриать и обрабатывать журналы регистрации ИС – общая задача ИБ и ИТ. В компаниях со зрелыми подразделениями ИТ вопрос сбора журналов всех ИС, в том числе и с выделенных решений ИБ, таких как межсетевые экраны, системы защиты конечных точек (EPP-EDR) или сетевые системы обнаружения сетевых вторжений или NDR, традиционно решен. Поэтому, для подразделений ИБ значительно эффективнее переиспользовать LM-системы ИТ (LM – Log management), тем более, что современная LM-система позволяет покрыть все основные сценарии ИБ, а вместе с тем обеспечивает нилучшее покрытие, не ограничиваясь только системами ИБ и не стремясь остаться в рамках лицензионных ограничений EPS.
- В компаниях со зрелыми инженерными командами предпочитают свободно распростаняемые решения, что дает практически безграничную гибкость, а следовательно, безграничные возможности по адаптации. Выбор opensource еще более очевиден для компаний с большими возможностями по разработке собственного ПО.

Первый пункт принципиально важен. Что бы мы не говорили, но ИБ в компании обеспечивают подразделения ИТ! Именно ИТ разрабатывают, внедряют и обслуживают информационные системы с соблюдением требований безопасности, за ИБ остаются функции законодателя и контролера. Именно поэтому безопасность не может быть обеспечена там, где у ИБ и ИТ плохие отношения или ИТ - ленивые разгильдяи имеют низкий уровень зрелости. Уровень ИБ напрямую зависит от зрелости ИТ. Как правило, у зрелых ИТ вопрос управления журналами систем и приложений давно решен и, с точки зрения эффективности инвестиций, безопаснику логичнее подключиться к уже внедренным у ИТ системам LM, а не строить сбоку дорогостоящую городушку с кучей ограничений в виде SIEM. Собственно, когда где-то в 2006-2009 занимался созданием своего первого SOC, я ровно так и сделал. Правда, следует заметить, что позднее у меня появился и SIEM, но именно для корреляции на неполном объеме событий из-за ограничений по железу и EPS.
Если же в корпорации вопрос сбора логов не решен, то лучше это сразу решать совместо с ИТ: строить общий Data Lake, откуда ИТ будут брать данные для своего траблшутинга, а мы - для нашего обнаружения атак (какую-то их часть отправлять в SIEM для генерации алертов в SOC).

Итак, друзья мои, ответ на вопрос: "Можно ли построить SOC без SIEM?" - положительный, но с плотным вовлечением ИТ (повторюсь, что без плотного вовлечения ИТ безопасность обеспечить невозможно, именно ИТ делают безопасность!)

#vCISO #MDR #пятница

Когда безопасность побеждает безопасность -

- подумалось мне, когда после установки последних обновлений у меня отъехал токен => перестала работать двухфакторная аутентификация.

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

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

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

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

#пятница #vCISO

Рейтинги курсов

Я уже упоминал, что выходные - время что-то поизучать, и на этот раз я решил поглубже погрузиться в вопросы разного рода менеджмента, лидерства и личной эффективности. Постараюсь найти время и написать пару предложений про каждый прослушанный курс, но для целей этой заметки остановлюсь на этих двух, от одного автора и одинаковыми оценками:
1. Leadership: Practical Skills - оценка 4.7 по 5 950 отзывам
2. Efficient Time Management - оценка 4.7 по 7 277 отзывам

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

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

Сейчас уже трудно наверняка установить автора, но будем считать, что это сказал Сократ:

Чем больше я знаю, тем больше я понимаю, что ничего не знаю

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

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

#книги #саморазвитие #управление #пятница

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

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

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

#mdr #vCISO #пятница

Бурное развитие облаков в какой-то степени сдерживали риски приватности: как же, мол, мы будем в облачного провайдера передавать все наши секреты и т.д. и т.п. Теоретическое математическое решение предложено небезызвестными Ривестом и Адельманом аж в 1978 году в виде гомоморфного шифрования. В теории все почти неплохо - манипуляции с данными производятся с зашифрованными данными и, вроде как, секреты не разглашаются. Однако, на практике реализации гомоморфного шифрования вычислительно сложны, что делает их нерентабельными. Немного я касался этого в 2012 году.

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

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

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

#пятница #ml #vCISO

На этой неделе моя дочь сдавала экзамены и я, как законный представитель, подписывал разные документы, в том числе и согласие на обработку персональных данных (ПДн). В целом, стандартная процедура, - самое заметное подтверждение того, что Государство заботится о сохранности моих ПДн. Хотя, по личному моему наблюдению, количество сливов ПДн кратно увеличилось именно со времени появления 152-ФЗ в 2006 году. Остается только гадать о причинах - то ли стремление Государства защищать ПДн наделило их небывалой ранее ценностью, что добавило мотивации их похитителям, то ли сами методы защиты ПДн привели к общему снижению их безопасности. Как любитель парадоксов, во время подписания документов, необходимых для допуска дочери к экзамену, я подумал именно о втором сценарии: созданные обязательные процедуры способствуют снижению безопасности ПДн.

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

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

#пятница #РФ