Именно таким способом с 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, но мы и так не обидимся.
По-моему, это как с «техническим долгом»: какой можно принять, чтобы в краткосрочной и долгосрочной перспективе заработать больше, чем без него.
По-существу.
1.1 Да, вы можете создать инспекцию, добавлять туда комиты по мере их появления и просматривать: добавился новый комит в инспекцию, вам пришло уведомление, посмотрели, прокомментировали. После того, как вы описали проблему, вспомнил, что мы так действительно поступали с большими задачами :-)
1.2 Самый лучший способ, который обеспечивал нас хорошими архитектурными решениями – Design Review. Перед началом того, что я хочу сделать, накидывал прототип, определял основные концепции и выкатывал это своим коллегам, которые критиковали и показывали узкие места. Таким образом, до начала реализации в рабочей системе мы тратили ~10% на прототипирование, зато получали отличные качественные архитектурные решения. CodeReview здесь уже помогает лечить проблему, но не причину. Предназначение же Design Review – лечить причину на корню. Думаю, что самый отличный вариант гармонично совмещать Design Review и CodeReview. Уточню, что Design Review проводили для действительно стоящих новых задач/рефакторинга, для «мелочи» этого не делали.
2. Да, может. Для этого настраивается так называемый Automatic Link – по сути это регэксп, найдя который в текстовых полях шапки инспекции, CC подставляет для него шаблон подстановки. Например, вот такой паттерн #(\d+) превращается у нас в ссылку в TestTrack при помощи такого шаблона ttstudio:///MaxPatrol8/dfct?number=$1 (#11001 -> ttstudio:///MaxPatrol8/dfct?number=11001)
С Джирой можно так же – это точно, на предыдущей работе у нас были ссылки в Джиру. Мы именовали инспекции, просто вводя код запроса из Джиры. Очень удобно. Всё равно краткая инфа в списке инспекций мне ничего не даёт, а вот ссылка на Джиру очень даже хороша. Тем более что есть функция сортировки по полю, так любую инспекцию легко найти.
Сейчас хотим добавлять ссылку в запросе bugtracker’а на инспекцию, чтобы было удобней. Пока что программист в запрос TestTrack вручную будет добавлять ссылку на инспекцию в CC.
Думаю, что такая возможность обязательно представится.
Главное — рассказать в таком формате, чтобы это действительно было интересно аудитории Хабра.
А продукты действительно очень любопытные.
Если имеются в виду общие подходы к юнит тестам, то да, код при проектировании разбивается на абстракции, таким образом, чтобы его можно было легко покрыть тестами.
Кроме того, количество уязвимостей в 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.
линки на каждый из них можно легко нагуглить :)
Для каждого из последующих этапов сканирования, доступность хоста определяется по своему собственному алгоритму, при этом первичный результат пинга, говорящий о недоступности хоста, может быть проигнорирован.
По-моему, не все проекты готовы к такой методике и не для всех она подходит.
Парное программирование плохо прижилось, например, при разработке встраиваемых систем. По-моему, потому что там большое кол-во задач, когда нужно читать документацию на какую-то микросхему или прибор и потом писать по документации код. Читают все с разной скоростью, усваивают так же с разной скоростью и в разных объёмах. Да и вообще, часто нужно с железкой что-то попробовать, поэкпериментировать. Тут второму просто делать нечего. Это лично моё субъективное мнение: почему при разработке встраиваемых систем парное программирование не практикуется или практикуется редко.
Хотя для части кода – лучше именно инспекция. Например, вы портируете драйвер сетевой карты, такой код лучше чтобы проинспектировали ещё и опытные коллеги. Они найдут – где я забыл засинхронизировать доступ к ресурсу или увидят возможность рекурсивного вызова того же обработчика прерывания, а я на такую ситуацию с напарником не заложился :)
По школе помню, что лучше «контролку» проверить, прежде чем её сдать, а то пара обеспечена . А ещё лучше, если её проверит мой сосед :) (мы кстати бывало так делали в школе, проверяли работы друг у друга – находили дефекты :)
Так что, по-моему, инспекция дополняет практику парного программирования.
Инспекция позволяет посмотреть на выполненную работу спокойно и отстранённо, проверить её.
Имхо, конечно всё.
По-моему, это как с «техническим долгом»: какой можно принять, чтобы в краткосрочной и долгосрочной перспективе заработать больше, чем без него.
По-существу.
1.1 Да, вы можете создать инспекцию, добавлять туда комиты по мере их появления и просматривать: добавился новый комит в инспекцию, вам пришло уведомление, посмотрели, прокомментировали. После того, как вы описали проблему, вспомнил, что мы так действительно поступали с большими задачами :-)
1.2 Самый лучший способ, который обеспечивал нас хорошими архитектурными решениями – Design Review. Перед началом того, что я хочу сделать, накидывал прототип, определял основные концепции и выкатывал это своим коллегам, которые критиковали и показывали узкие места. Таким образом, до начала реализации в рабочей системе мы тратили ~10% на прототипирование, зато получали отличные качественные архитектурные решения. CodeReview здесь уже помогает лечить проблему, но не причину. Предназначение же Design Review – лечить причину на корню. Думаю, что самый отличный вариант гармонично совмещать Design Review и CodeReview. Уточню, что Design Review проводили для действительно стоящих новых задач/рефакторинга, для «мелочи» этого не делали.
2. Да, может. Для этого настраивается так называемый Automatic Link – по сути это регэксп, найдя который в текстовых полях шапки инспекции, CC подставляет для него шаблон подстановки. Например, вот такой паттерн #(\d+) превращается у нас в ссылку в TestTrack при помощи такого шаблона ttstudio:///MaxPatrol8/dfct?number=$1 (#11001 -> ttstudio:///MaxPatrol8/dfct?number=11001)
С Джирой можно так же – это точно, на предыдущей работе у нас были ссылки в Джиру. Мы именовали инспекции, просто вводя код запроса из Джиры. Очень удобно. Всё равно краткая инфа в списке инспекций мне ничего не даёт, а вот ссылка на Джиру очень даже хороша. Тем более что есть функция сортировки по полю, так любую инспекцию легко найти.
Сейчас хотим добавлять ссылку в запросе bugtracker’а на инспекцию, чтобы было удобней. Пока что программист в запрос TestTrack вручную будет добавлять ссылку на инспекцию в CC.
Думаю, что такая возможность обязательно представится.
Главное — рассказать в таком формате, чтобы это действительно было интересно аудитории Хабра.
А продукты действительно очень любопытные.