При помощи описанного алгоритма удалось найти множество оптимизаций, которые улучшили производительность продуктов Positive Technologies.
Хотелось бы увидеть какие-то приближенные к реальности примеры находок. Допустим вот Вы запустили инструмент и что было дальше? Как увидели проблему, как нашли итоговый кусочек кода, который надо оптимизировать.
Считаю что статья заслуживает второй практической части.
Давайте немного уточним. Человек уровня CTO, как и любой грейд, понятие растяжимое. В зависимости от компании и ещё многих факторов это может быть как бывший вчера мидл, так и человек, который работал с перфокартами или писал под MS-DOS (и это не говорит, что он хороший CTO). И как бывший вчера мидл я бы мечтал иметь такую книгу чтобы получить какое-то руководство к действию => аудиторию даже среди CTO книга точно найдет (а автор статьи указал, кто является аудиторией книги, и там не только CTO).
К документации. Да, с процессом создания грустно, вся глава по большей части - перечень типов и их описания. С другой стороны, это тоже важно, так как в целом необходимо понимать, а что можно (и нужно) писать в документации и для какой аудитории.
Ко второй проблеме - проблематика описана корректно, вопросов нет. Просто кажется, что это должно быть описано в других главах, например, главы 4-7 (4 главы про управление командой), а бюджет в главе 3 "Долгосрочное видение" (хотя там очень скупо про бюджет, судя по всему)
По поводу мифа 4: вы правы лишь отчасти. Организации с начальным уровнем зрелости обычно либо не имеют процессов реагирования на ИБ, либо находятся на этапе построения. И неясно как оценивать уровень зрелости компании в целом. Я бы рекомендовал таким заказчикам сначала проходить пентест для определения уровня защищенности, закрытия очевидных уязвимостей, проверки работы различных СЗИ, включая SIEM-системы.
Хотелось бы увидеть какие-то приближенные к реальности примеры находок. Допустим вот Вы запустили инструмент и что было дальше? Как увидели проблему, как нашли итоговый кусочек кода, который надо оптимизировать.
Считаю что статья заслуживает второй практической части.
Ключевое слово - "пока". А потом происходит что-то по типу взлома LastPass.
Надеюсь, что вы следите за уязвимостями в своем ПО.
Конечно, я думаю не только мне интересно)
А что за движок внутри IPS и откуда появились 85к правил? На 2023 год у FortiGate'а было ~10-16k правил (source).
Давайте немного уточним. Человек уровня CTO, как и любой грейд, понятие растяжимое. В зависимости от компании и ещё многих факторов это может быть как бывший вчера мидл, так и человек, который работал с перфокартами или писал под MS-DOS (и это не говорит, что он хороший CTO). И как бывший вчера мидл я бы мечтал иметь такую книгу чтобы получить какое-то руководство к действию => аудиторию даже среди CTO книга точно найдет (а автор статьи указал, кто является аудиторией книги, и там не только CTO).
К документации. Да, с процессом создания грустно, вся глава по большей части - перечень типов и их описания. С другой стороны, это тоже важно, так как в целом необходимо понимать, а что можно (и нужно) писать в документации и для какой аудитории.
Ко второй проблеме - проблематика описана корректно, вопросов нет. Просто кажется, что это должно быть описано в других главах, например, главы 4-7 (4 главы про управление командой), а бюджет в главе 3 "Долгосрочное видение" (хотя там очень скупо про бюджет, судя по всему)