1. Видео конкретно этого доклада нет (архив других выступлений на сайте), все выступления мы позже зальем на ютуб. Слайды также выкладываем на SlideShare, но пока не все до конца собрали.
2. Как таковой рассылки мероприятий у нас нет — есть анонсы вебинаров на сайте, а про PHDays можно прочитать, помимо хабра, на оф. сайте, в блоге, и в соц. сетях (вк, фб, твиттер) — где удобнее.
3-4. Можно, в целом, объединить ответы. В прошлом году этот конкурс также проводился, мы в блоге выкладывали задания и прохождения плюс были райтапы от участников конкурса, что в том году, что в этом, также можно поискать информацию в них.
По поводу SSH на сетевом оборудовании «да». Это имеет место быть в крупных сетях, где количество сетевого оборудования исчисляется несколькими тысячами устройств.
По поводу отрезание ААА: все шаги в ходе анализа защищенности согласовываются с заказчиком. Поэтому ответ «да», было :)
Атаки на телеком, где речь идет о нескольких тысячах роутеров происходят именно в лоб. И вероятность ошибки в настройке оборудования в этом случае не нулевая. И поверьте cisco/cisco – вполне жизненная ситуация ;)
Наше задание было по максимуму приближено к реальности. В большинстве случаев, анализ защищенности компаний начинается с изучения внешнего периметра, доступных сервисов и тп. Если же предполагается, что вы будете находится на площадке провайдера и снифить трафик, то вероятность получения конфиденциальных данных равна 99,999%. :) Поэтому и выбран путь с дефолтными учетными записями, тем самым намекая, что мы прошли через внешний периметр.
Пока в планах нет, поскольку подготовка заданий требует определённых усилий. Но у нас есть образовательная программа, в рамках которой проводятся вебинары.
Как обычно, пригласили несколько коллег и друзей, предложили попробовать свои силы. Получилось 50 минут — среднее время прохождения. Скорее всего мы не учли присутствие некоторого стресса и отвлекающих факторов для участников на площадке, вот и промахнулись на 15 минут :).
О да, всех веселят статьи о взломе с правами админа :) Но не придирайтесь, тут совсем другое дело: это все таки конкурс для проверки знаний и как в любом конкурсе сложность заданий возрастает постепенно. Можно было бы предложить участниками брутить учетки, но, сами понимаете, на это может уйти много времени, а значит динамика состязания исчезнет.
Да, любой желающий. На самом деле возраст не имеет значения. Михаил, к примеру, моложе вас, но вполне себе выступает на серьезных мероприятиях http://blog.ptsecurity.ru/2012/11/mongo-db.html
Нет, конечно не только. У нас был Call For Papers в ходе которого можно было заявки на выступление отправлять, так что будут докладчики из разных организаций/компаний/стран :).
Ну это как сказать. Семинары некоторых экспертов, что будут на PHDays, по одному стоят примерно как билет на два дня форума. Так что все относительно :). В любом случае, мы работаем и над организацией трансляции с площадки.
Попытка номер 2 с утра: ) Согласны, проблема была специфическая, только для нашей команды. Но она уже решена, благодаря ревизиям кода и команду вполне устроила.
Суть проблемы: Был активный процесс разработки тестов. Было очень много тестов. Команда каждый день писала еще больше тестов. И, соответственно было много комитов. Периодически, при мерже, по невнимательности, кто-то у кого-то перетирал уже написанные тесты (например, если использовал вызовы уже старых методов, или свои тестовые данные). Как было отмечено выше, после реализации теста и его код-ревью к нему уже не возвращаются и он отправляется на постоянную прогонку. Очень часто, смену логики теста можно было и не заметить. И, например, через какое-то время изменить тест ещё раз уже самому. В итоге, приходилось тратить много времени, отслеживая историю изменения по коду. Это было чрезвычайно неудобно (множество тестов – множество комитов, как отмечал linuxoid выше: «там будет ад и содомия»).
В этом конкретном случае, нам помог механизм ревизий. Написав один раз простенький модуль, и используя его постоянно, мы себя подстраховали. Система сама нас предупредит, если кто-то «несанкционированно» изменил код старых функций. Ничего особенного в таком решении проблемы нет, нашу команду это устроило и мы пользуемся: )
Насчет разделения — вы не поняли :) оно условное. Разумеется мы в одной команде с разработчиками и всеми остальными — аджайл-стайл))
Ручной запуск функциональных и приемочных тестов — это нормально. Зачем лишняя автоматизация? Ради автоматизации? Но ведь и так работает, а запустить тестовую систему раз в 2 недели — не проблема. Разумеется также, что полный набор всех тестов прогоняется перед Демонстрацией продукта, на отладочной ветке репозитория. Затем результаты обрабатываются и ставятся задачи по доработке в следующей версии.
Функциональные тесты в разработке используются, но для ежедневного прогона — не полный набор.
1. Видео конкретно этого доклада нет (архив других выступлений на сайте), все выступления мы позже зальем на ютуб. Слайды также выкладываем на SlideShare, но пока не все до конца собрали.
2. Как таковой рассылки мероприятий у нас нет — есть анонсы вебинаров на сайте, а про PHDays можно прочитать, помимо хабра, на оф. сайте, в блоге, и в соц. сетях (вк, фб, твиттер) — где удобнее.
3-4. Можно, в целом, объединить ответы. В прошлом году этот конкурс также проводился, мы в блоге выкладывали задания и прохождения плюс были райтапы от участников конкурса, что в том году, что в этом, также можно поискать информацию в них.
По поводу отрезание ААА: все шаги в ходе анализа защищенности согласовываются с заказчиком. Поэтому ответ «да», было :)
Суть проблемы: Был активный процесс разработки тестов. Было очень много тестов. Команда каждый день писала еще больше тестов. И, соответственно было много комитов. Периодически, при мерже, по невнимательности, кто-то у кого-то перетирал уже написанные тесты (например, если использовал вызовы уже старых методов, или свои тестовые данные). Как было отмечено выше, после реализации теста и его код-ревью к нему уже не возвращаются и он отправляется на постоянную прогонку. Очень часто, смену логики теста можно было и не заметить. И, например, через какое-то время изменить тест ещё раз уже самому. В итоге, приходилось тратить много времени, отслеживая историю изменения по коду. Это было чрезвычайно неудобно (множество тестов – множество комитов, как отмечал linuxoid выше: «там будет ад и содомия»).
В этом конкретном случае, нам помог механизм ревизий. Написав один раз простенький модуль, и используя его постоянно, мы себя подстраховали. Система сама нас предупредит, если кто-то «несанкционированно» изменил код старых функций. Ничего особенного в таком решении проблемы нет, нашу команду это устроило и мы пользуемся: )
Ручной запуск функциональных и приемочных тестов — это нормально. Зачем лишняя автоматизация? Ради автоматизации? Но ведь и так работает, а запустить тестовую систему раз в 2 недели — не проблема. Разумеется также, что полный набор всех тестов прогоняется перед Демонстрацией продукта, на отладочной ветке репозитория. Затем результаты обрабатываются и ставятся задачи по доработке в следующей версии.
Функциональные тесты в разработке используются, но для ежедневного прогона — не полный набор.