Пробовали и используем. Действительно, в некоторых случаях работает более эффективно чем студийный build без clean. Для MSVS эта штука называется clcache, мы немного отредактировали ее первоначальный вариант отсюда https://github.com/frerich/clcache
Как вы внимательно смотрели видео :)
Да, к сожалению, при подготовке презентации в данные вкралась ошибка. По старым данным получалось что строка кода у нас длиной под 300 символов :)
Именно таким способом с compile time dependency injection — нет, не весь, только те части которые используют traits идиому.
Если имеются в виду общие подходы к юнит тестам, то да, код при проектировании разбивается на абстракции, таким образом, чтобы его можно было легко покрыть тестами.
Это проблемы декомпилятора, он очень часто выдает нерабочий код. Но, как правило, основная логика работы приложения понятна. В данном случае никакого return там, конечно, нет
К сожалению не всегда получается однозначно классифицировать уязвимость на основе существующего описания.
Кроме того, количество уязвимостей в ICS не так велико, чтобы можно было использовать более детальную классификацию, как CWE. Поэтому мы укрупнили до использованной в исследовании.
Buffer overflow – манипуляция памяти, когда последствия непонятны
Remote Code Execution – явно приводят к выполнению кода
Web (Server/Client) – согласно WASC/OWASP соответственно
Ну и далее. Отдельно выделили проблемы управления «секретами», поскольку их очень много, практически 23%. С нашей точки зрения это показывает насколько мало задумывались о безопасности при проектировании SCADA и прочих, поскольку в большинстве случаев это архитектурный баг.
Да, действительно, интеграция с MES и ERP может приносить неприятные сюрпризы, например такие Что касается изоляции, она зачастую достаточно условна. Пример из жизни: на энергогенерирующем предприятии для загрузки проекта на SCADA/PLC необходимо использовать токен для авторизации. Иначе никак. Однако PLC внезапно доступен по telnet/ftp с root: и можно просто заливать туда что душе угодно. Тот же проект, например, с приятными сердцу модификациями
Цель аналитики не абсолютные цифры (мы приводим процентные доли), к тому же просканировать весь интернет смысла нет. Методика поиска систем описана в исследовании (Google, ShoudanHQ ERIPP и т.д.).
Вообще в тексте исследования (со страницы 24) приводится достаточно большое количество показателей.
Вы совершенно верно рассуждаете, рассматриваемый в статье процесс пинга является лишь небольшой частью процесса сканирования и его целью является пропинговать как можно больше хостов за короткое время.
Для каждого из последующих этапов сканирования, доступность хоста определяется по своему собственному алгоритму, при этом первичный результат пинга, говорящий о недоступности хоста, может быть проигнорирован.
К сожалению у нас пока нет возможности полностью перейти на новый стандарт, в связи с большим кол-вом клиентов, некоторые из которых используют старые версии ОС.
Лично сам я ощущаю так же, лучшая инспекция – парное программирование.
По-моему, не все проекты готовы к такой методике и не для всех она подходит.
Парное программирование плохо прижилось, например, при разработке встраиваемых систем. По-моему, потому что там большое кол-во задач, когда нужно читать документацию на какую-то микросхему или прибор и потом писать по документации код. Читают все с разной скоростью, усваивают так же с разной скоростью и в разных объёмах. Да и вообще, часто нужно с железкой что-то попробовать, поэкпериментировать. Тут второму просто делать нечего. Это лично моё субъективное мнение: почему при разработке встраиваемых систем парное программирование не практикуется или практикуется редко.
Хотя для части кода – лучше именно инспекция. Например, вы портируете драйвер сетевой карты, такой код лучше чтобы проинспектировали ещё и опытные коллеги. Они найдут – где я забыл засинхронизировать доступ к ресурсу или увидят возможность рекурсивного вызова того же обработчика прерывания, а я на такую ситуацию с напарником не заложился :)
По школе помню, что лучше «контролку» проверить, прежде чем её сдать, а то пара обеспечена . А ещё лучше, если её проверит мой сосед :) (мы кстати бывало так делали в школе, проверяли работы друг у друга – находили дефекты :)
Так что, по-моему, инспекция дополняет практику парного программирования.
Инспекция позволяет посмотреть на выполненную работу спокойно и отстранённо, проверить её.
Да берите конечно. Не проблема! Не жалко :) Можно без надписей даже, ну или если хотите можно ссыль на сайт вставить www.ptsecurity.ru, но мы и так не обидимся.
Да, к сожалению, при подготовке презентации в данные вкралась ошибка. По старым данным получалось что строка кода у нас длиной под 300 символов :)
Если имеются в виду общие подходы к юнит тестам, то да, код при проектировании разбивается на абстракции, таким образом, чтобы его можно было легко покрыть тестами.
Кроме того, количество уязвимостей в ICS не так велико, чтобы можно было использовать более детальную классификацию, как CWE. Поэтому мы укрупнили до использованной в исследовании.
Buffer overflow – манипуляция памяти, когда последствия непонятны
Remote Code Execution – явно приводят к выполнению кода
Web (Server/Client) – согласно WASC/OWASP соответственно
Ну и далее. Отдельно выделили проблемы управления «секретами», поскольку их очень много, практически 23%. С нашей точки зрения это показывает насколько мало задумывались о безопасности при проектировании SCADA и прочих, поскольку в большинстве случаев это архитектурный баг.
Вообще в тексте исследования (со страницы 24) приводится достаточно большое количество показателей.
ICS-CERT,
NVD,
CVE,
Bugtraq,
OSVDB,
Mitre Oval Repositories,
exploit-db,
Siemens Product CERT.
Сборники эксплойтов:
SAINTexploit,
Metasploit Framework,
Immunity Canvas,
Agora Pack,
Agora SCADA+,
D2 Exploit Pack,
White Phosphorus exploit pack,
VulnDisco Exploit Pack.
линки на каждый из них можно легко нагуглить :)
Для каждого из последующих этапов сканирования, доступность хоста определяется по своему собственному алгоритму, при этом первичный результат пинга, говорящий о недоступности хоста, может быть проигнорирован.
По-моему, не все проекты готовы к такой методике и не для всех она подходит.
Парное программирование плохо прижилось, например, при разработке встраиваемых систем. По-моему, потому что там большое кол-во задач, когда нужно читать документацию на какую-то микросхему или прибор и потом писать по документации код. Читают все с разной скоростью, усваивают так же с разной скоростью и в разных объёмах. Да и вообще, часто нужно с железкой что-то попробовать, поэкпериментировать. Тут второму просто делать нечего. Это лично моё субъективное мнение: почему при разработке встраиваемых систем парное программирование не практикуется или практикуется редко.
Хотя для части кода – лучше именно инспекция. Например, вы портируете драйвер сетевой карты, такой код лучше чтобы проинспектировали ещё и опытные коллеги. Они найдут – где я забыл засинхронизировать доступ к ресурсу или увидят возможность рекурсивного вызова того же обработчика прерывания, а я на такую ситуацию с напарником не заложился :)
По школе помню, что лучше «контролку» проверить, прежде чем её сдать, а то пара обеспечена . А ещё лучше, если её проверит мой сосед :) (мы кстати бывало так делали в школе, проверяли работы друг у друга – находили дефекты :)
Так что, по-моему, инспекция дополняет практику парного программирования.
Инспекция позволяет посмотреть на выполненную работу спокойно и отстранённо, проверить её.
Имхо, конечно всё.