Смешной вопрос, но из жизни.
Существуют ли какие-то общепризанные регалии, которые гарантируют их обладателю некоторый уровень экспертизы в вопросах безопасности?

Скажем, если на работу нанимается человек, который должен ревьювить разрабатываемые АПИ на предмет возможных уязвимостей — что с него можно/нужно требовать? (Кроме справки об отсутствии судимостей и задолженностей).

Здравствуйте, Sinclair, Вы писали:

S>Смешной вопрос, но из жизни.
S>Существуют ли какие-то общепризанные регалии, которые гарантируют их обладателю некоторый уровень экспертизы в вопросах безопасности?
Да как и везде есть свои сертификации.
Например, сертификация ISACA — довольно серьезная штука, но мало у кого есть (там еще и членские взносы надо постоянно оплачивать).
Есть isc2, у них наиболее известна сертификация CISSP (но эта сертификация слабо относится к тому роду деятельности, что у тебя в исходном сообщении). Кстати, их тоже не так много в России.
Есть отдельные сертификации у вендоров (например, у Microsoft MSCE, в свое время, был со специализациями, в том числе, security — сейчас там все поменялось, поэтому хз как оно, у Cisco есть CCSP и CCIE Security и т.п.).
А вот что-то отечественное, чтоб специфику учитывало — с этим сложно.

S>Скажем, если на работу нанимается человек, который должен ревьювить разрабатываемые АПИ на предмет возможных уязвимостей — что с него можно/нужно требовать? (Кроме справки об отсутствии судимостей и задолженностей).
С него надо требовать знание Threat Modelling (например, в изложении Microsoft с их SDL). Сертификацию по этой теме я не знаю Ближе всего CISA от ISACA — но там в целом по аудиту.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Sinclair, Вы писали:

P.S. У самого ни одного вышеозвученного сертификата нет, от вендорской сертификации только MCSA на 2003-й сервер — так что вот и думай, стоит ли меня тут слушать

Здравствуйте, Sinclair, Вы писали:

Уточните — вам надо проверить его репутацию или именно профессиональные знания и опыт? Поскольку, например, если у него, "судимость" за взлом компьютерной системы, то с точки зрения репутации — это минус, а с точки зрения профессионализма — свидетельство того, что кандидат понимает в безопасности

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

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

Здравствуйте, AShirmanov, Вы писали:

AS>Проверить кандидата можно с помощью тестового задания — дать какое-нибудь API и попросить написать проект по безопасности. То есть описать модель нарушителя, модель угроз с вероятностями и критичностями угроз, таблицу деактуализации угроз, выполнить статический и динамический анализ кода (в разумных упрощенных пределах конечно) и подготовить итоговый отчет со списком рекомендуемых исправлений. по полноте модели угроз можно судить о широте квалификации. Из всех кандидатов можно выбрать, например, того, кто напишет наиболее полный отчет в смысле выявленных уязвимостей.

AS>Надо понимать, что работа по составлению такого отчета требует от специалиста по безопасности плотной работы с менеджером проекта, чтобы корректно выполнить работу по выбору модели нарушителя и деактуализации угроз — так как ответы в рамках приоритетов заказчика может дать только заказчик (продукт менеджер, или руководитель), а не сам специалист по ИБ. То есть такой тест поможет проверить кандидата и с этой стороны (коммуникации).

Что-то как-то страшно. Я, конечно, плохо разбираюсь в работе безопасников, но это в любом случае не тестовое задание на пару часов... Нужна _очень_ хорошая мотивация, чтобы человек согласился сделать такое лишь в качестве теста.

Здравствуйте, Sinclair, Вы писали:

S>Смешной вопрос, но из жизни.
S>Существуют ли какие-то общепризанные регалии, которые гарантируют их обладателю некоторый уровень экспертизы в вопросах безопасности?

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

S>Скажем, если на работу нанимается человек, который должен ревьювить разрабатываемые АПИ на предмет возможных уязвимостей — что с него можно/нужно требовать? (Кроме справки об отсутствии судимостей и задолженностей).

1. Понимание концепций моделирования угроз (STRIDE, хотя бы) и оценки их рисков.
2. Владение ЯП, которые планируются использовать в рамках разработки продукта.
3. Способность изобразить в виде реального кода все примеры уязвимостей, приводящих к атакам из http://projects.webappsec.org/w/page/13246978/Threat+Classification
4. Способность изобразить рабочие эксплоиты к уязвимостям, продемонстрированным в п.3. Если не изобразит, значит риски оценивать не сможет.
4. Способность изложить рекомендации по устранению уязвимостей, продемонстрированных в п.3, причем не только очевидные, но и жестко привязанные к любому из этапов разработки. Например, SQL-инъекции возможны в результате ошибок на этапе кодирования, соответственно от претендента требуется способность объяснить, как минимизировать связанные с ними риски на этапе дизайна и развертывания, не устраняя их при этом на этапе кодирования.
5. Задать вопрос, что он знает про этап вывода из эксплуатации, какие меры должны быть предприняты на остальных этапах, чтобы снизить риски уязвимостей на этом (это реально коварный вопрос, если ответит — брать не раздумывая).
6. Спросить, какой он видит цель своей деятельности у вас. Должен ответить, что целью является выпуск продукта с управляемыми рисками по ИБ. Если ответит что-либо на тему, что цель — устранить все уязвимости или что-то в этом роде, типа максимум уязвимостей — значит еще слишком молодой и не имеет достаточного опыта.
7. В ночь перед релизом, он обнаруживает уязвимость этапа дизайна (архитектурную) — его действия? Правильного ответа тут нет, но даст представление о том, что вас ждет в 90% его деятельности.
8. Пусть найдет хотя бы 5 уязвимостей на RSDN (они есть) без доступа к его исходному коду, подготовит эксплоиты и рекомендации по устранению. Человека, который не способен действовать блэкбоксом, допускать к вайтбоксу не стоит. Если напишет толковые пачти — брать не раздумывая, а патчи — накатить на исходник движка, ибо давно пора
9. Задать вопрос, в каких случаях защищенность ИС можно считать стремящейся к 100%. Правильного ответа нет, но даст представление об уровне его матчасти.

Здравствуйте, Ops, Вы писали:

Ops>Что-то как-то страшно. Я, конечно, плохо разбираюсь в работе безопасников, но это в любом случае не тестовое задание на пару часов... Нужна _очень_ хорошая мотивация, чтобы человек согласился сделать такое лишь в качестве теста.

Когда я проходил собеседование на текущее место работы, мне дали тест на 10 вопросов, так или иначе связанных с хаком и рассчитанных на сутки раздумий. И это был лучший тест за все время моей работы в отрасли, реально интересный и дающей представление о будущей работе. Мое IMHO, что человека, который стремается решать тесты в рамках собеседования брать не стоит, т.к. такой лучше удавится, чем будет выкладываться в работу больше, чем по его мнению ему за нее платят. От таких больше проблем, чем реальной пользы.

Здравствуйте, AShirmanov, Вы писали:

AS>таблицу деактуализации угроз,

Угрозу можно либо устранить, либо минимизировать связанные с ней риски. Сделать ее менее актуальной (деактуализировать), это то же самое, что уговорить бизнес, что ущерб, связанный с ней, его не должен волновать

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Ops, Вы писали:

Ops>>Что-то как-то страшно. Я, конечно, плохо разбираюсь в работе безопасников, но это в любом случае не тестовое задание на пару часов... Нужна _очень_ хорошая мотивация, чтобы человек согласился сделать такое лишь в качестве теста.

KV>Когда я проходил собеседование на текущее место работы, мне дали тест на 10 вопросов, так или иначе связанных с хаком и рассчитанных на сутки раздумий. И это был лучший тест за все время моей работы в отрасли, реально интересный и дающей представление о будущей работе. Мое IMHO, что человека, который стремается решать тесты в рамках собеседования брать не стоит, т.к. такой лучше удавится, чем будет выкладываться в работу больше, чем по его мнению ему за нее платят. От таких больше проблем, чем реальной пользы.

Хотя разумеется, тут должна быть разумная грань в плане объема теста. Предлагать в рамках теста цельный проект — не лучшая идея.

Здравствуйте, kochetkov.vladimir, Вы писали:

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

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

S>Спасибо, это поможет. Косвенно связанный с темой вопрос: а как нам убедить кого-то (скажем, совет директоров), что взят правильный человек?

Пусть они найдут кого-то, кто оставит дыру, а он её обнаружит?

Здравствуйте, Sinclair, Вы писали:

S>Спасибо, это поможет. Косвенно связанный с темой вопрос: а как нам убедить кого-то (скажем, совет директоров), что взят правильный человек?

А вот это — десятый вопрос, который нужно задать претенденту

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

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

А джамшуд сертификатами может хоть обвешаться, но выдвигая какие-либо свои предложения, он берет на себя ответственность за дальнейшее развитие ситуации и снимает ее с безопасника. Обычно, одного раза среднестатическому джамшуду, нарвашемуся на грамотного безопасника, хватает с головой Ибо под грузом внезапно свалившейся на него ответственности, он обычно теряется куда подальше от всех этих ИБшних заморочек

Здравствуйте, Sinclair, Вы писали:

S>Смешной вопрос, но из жизни.
S>Существуют ли какие-то общепризанные регалии, которые гарантируют их обладателю некоторый уровень экспертизы в вопросах безопасности?

S>Скажем, если на работу нанимается человек, который должен ревьювить разрабатываемые АПИ на предмет возможных уязвимостей — что с него можно/нужно требовать? (Кроме справки об отсутствии судимостей и задолженностей).

Дать уязвимые апи и попросить запилить сплойт. Если не получится, тогда досвидания. Ваш кэп.

S>Спасибо, это поможет. Косвенно связанный с темой вопрос: а как нам убедить кого-то (скажем, совет директоров), что взят правильный человек?
S>Пока такой проблемы нету, но у нас уже были ситуации, когда наши рекомендации не выполнялись, потому что какой-то местный джамшуд с сертификатом сказал "так делать не надо, надо подругому делать". Ну, то есть хочется иметь в запасе козырь вроде "это мнение высказано сертифицированным специалистом, а не простым завсегдатаем форумов".

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

KV>8. Пусть найдет хотя бы 5 уязвимостей на RSDN (они есть) без доступа к его исходному коду, подготовит эксплоиты и рекомендации по устранению. Человека, который не способен действовать блэкбоксом, допускать к вайтбоксу не стоит. Если напишет толковые пачти — брать не раздумывая, а патчи — накатить на исходник движка, ибо давно пора

Занятное, кстати, предложение.
Есть одна хитрость — кандидат, который нужет (взят) в компанию к Sinclair, может не владеть (довольно-таки необычным) языком, на котором написан RSDN
Поэтому, даже найдя уязвимости, не всегда их можно пропатчить. К тому же, вопрос, что считать уязвимостью, далеко не так прост. Скажем, передача пароля открытым текстом — это, с одной стороны, уязвимость — для пользователя. С другой стороны, серверу-то пофиг

KV>9. Задать вопрос, в каких случаях защищенность ИС можно считать стремящейся к 100%. Правильного ответа нет, но даст представление об уровне его матчасти.

ИС — информационной системы? Не претендуя на большие познания в безопасности, отмечу, что задачу можно свести к математическому доказательству корректности работы системы. А в этом направлении есть немало исследований.
Т.е. реалистичного ответа на вопрос быть не может (равно как и на 100% защищенной ИС на общедоступных black box компонентах вроде тех же x86 процессоров), но потеоретизировать на тему математически доказанной правильности работы (

PS: — заинтересовавшись 8м вопросом, — зачем на RSDN 53 порт (DNS) и 139 (MSRPC) открыты всем желающмм? И уж ASP.NET padding дыру (по мнению некоторых, жуть какую critical — можно web.config посмотреть) могли бы закрыть, для этого даже ASP.NET знать не надо.

S>Существуют ли какие-то общепризанные регалии, которые гарантируют их обладателю некоторый уровень экспертизы в вопросах безопасности?

Про регалии уже написали (они есть, но мало у кого есть и могут не отражать реальной картины).

Дополню чуток по теме, личными ощущениями. Эксперт должен уметь объсянить доступным для понимания языком, что означает та или иная уязвимость, к каким видам атаки ведет, какие последствия ожидаются и т.п.. Это попутно слегка снизит актуальность вечной проблемы отсутствия доверия менеджмента. В конце концов, решение "фиксить!" принимать будет не сам эксперт. Все пойдет в общую копилку фич.

Здравствуйте, SkyDance, Вы писали:

KV>>8. Пусть найдет хотя бы 5 уязвимостей на RSDN (они есть) без доступа к его исходному коду, подготовит эксплоиты и рекомендации по устранению. Человека, который не способен действовать блэкбоксом, допускать к вайтбоксу не стоит. Если напишет толковые пачти — брать не раздумывая, а патчи — накатить на исходник движка, ибо давно пора

SD>Занятное, кстати, предложение.
SD>Есть одна хитрость — кандидат, который нужет (взят) в компанию к Sinclair, может не владеть (довольно-таки необычным) языком, на котором написан RSDN Поэтому, даже найдя уязвимости, не всегда их можно пропатчить.

Учитывая, что RSDN написан на C#, думаю, что Синклера не интересуют программисты, для которых он является довольно-таки необычным языком. Но, в любом случае, если предполагается, что безопасник будет работать с кодом, он должен знать язык на уровне, достаточном для написания патча. И среду, в которой код будет исполняться. В противном случае, уязвимости типа массового присваивания, перезаписи переменных, атак на десериализацию и т.п. (тысячи их), специфичных для конкретных языков и сред — он тупо не увидит.

SD>К тому же, вопрос, что считать уязвимостью, далеко не так прост.

Вообще-то, вопрос о том, что считать уязвимостью — прост, как никогда. Это совокупность факторов и условий, способствующих реализации той или иной информационной угрозы в отношении системы или ее отдельных компонентов (см. http://habrahabr.ru/post/129386/). А вот принимать ли риски, связанные с реализацией тех или иных информационных угроз или пытаться минимизировать их — это уже обсуждаемо и решается владельцем/заказчиков системы.

SD>Скажем, передача пароля открытым текстом — это, с одной стороны, уязвимость — для пользователя. С другой стороны, серверу-то пофиг

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

KV>>9. Задать вопрос, в каких случаях защищенность ИС можно считать стремящейся к 100%. Правильного ответа нет, но даст представление об уровне его матчасти.

SD>ИС — информационной системы? Не претендуя на большие познания в безопасности, отмечу, что задачу можно свести к математическому доказательству корректности работы системы. А в этом направлении есть немало исследований.

Это покроет только уязвимости этапа кодирования. Есть еще этапы проектирования, развертывания и вывода из эксплуатации.

SD>Т.е. реалистичного ответа на вопрос быть не может (равно как и на 100% защищенной ИС на общедоступных black box компонентах вроде тех же x86 процессоров), но потеоретизировать на тему математически доказанной правильности работы (

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

SD>PS: — заинтересовавшись 8м вопросом, — зачем на RSDN 53 порт (DNS) и 139 (MSRPC) открыты всем желающмм?

Потому что, DNS-зона rsdn.ru обслуживается этим же сервером (есть также внешний, вторичный). И не 139, а 135 все же. Он открыт, потому что его блокировка, в свое время, вызвала массу глюков с удаленным доступом по RDP, видимо из-за того, что сервисы Terminal Services Licensing и Terminal Services Session Directory используют этот порт, а помимо внешнего IP, сервер RSDN является также хостом во внутренней сети провайдера и хостом в локальной сети, а доступ по RDP необходим с каждой из этих сетей по ряду причин.

SD>И уж ASP.NET padding дыру (по мнению некоторых, жуть какую critical — можно web.config посмотреть) могли бы закрыть, для этого даже ASP.NET знать не надо.

Знаешь, почему я знаю, что тебе об этом сказал какой-то сканер? Потому что:

1. Правильный шифротекст, правильный паддинг: HTTP 200 http://rsdn.ru/WebResource.axd?d=pynGkmcFUV13He1Qd6_TZGnTfTgL3ZRyEueChIsg-0asfdpF7oZUfCN66TZSvZbLXiGbQg2
2. Неправильный шифротекст, правильный паддинг: HTTP 404 http://rsdn.ru/WebResource.axd?d=
3. Неправильный шифротекст, неправильный паддинг: HTTP 404 http://rsdn.ru/WebResource.axd?d=blablabla

Покажешь, где здесь оракул?

Что касается критичности этой уязвимости, то возможность получить web.config (а если быть точным, то произвольный файл начиная от корня веб-приложения, на который есть права доступа у процесса application pool'а, в котором оно выполняется) — это так, приятный побочный эффект. Основным результатом успешной эксплуатации этого оракула является возможность подделывать аутентификационные билеты ASP.NET, т.е. по сути, представляться любым ASP.NET пользователем и обходить механизмы контроля целостности viewstate и eventvalidation. Поэтому рассуждающие о некритичности этой уязвимости, выглядят, скажем так — не совсем в теме

Здравствуйте, SkyDance, Вы писали:

SD>И уж ASP.NET padding дыру (по мнению некоторых, жуть какую critical — можно web.config посмотреть)

Кстати, даже могу объяснить, почему твой сканер дал false-positive. Вероятно, он тестирует третий случай запросами вида http://rsdn.ru/WebResource.axd?d=<padding oracle test>, в ответ на которые получает HTTP 302 и делает из этого вывод, что эту разницу можно использовать в качестве оракула. Проблема в том, что 302 там получается из-за того, что запрос не проходит request validation, а не потому что произошла ошибка дополнения (до нее в этом случае обработка запроса вообще не доходит).

Именно поэтому, ручной блэкбокс-анализ защищенности дает 60-70%% уязвимостей от числа имеющихся в веб-приложении, а он же инструментальный — только 20-30%% и то, если повезет.

SD>могли бы закрыть, для этого даже ASP.NET знать не надо.

Кстати, расскажешь, как ее правильно закрыть?

KV>Учитывая, что RSDN написан на C#, думаю, что Синклера не интересуют программисты, для которых он является довольно-таки необычным языком.

Если Синклер все еще работает там, куда указывает его емейл — вопрос, вопрос. Возможно, его заинтересует какой-нибудь другой вебсайт на другой платформе.

KV>Понятие "уязвимость для пользователя" в данном случае вообще неприменимо. Есть уязвимости клиентской части, есть серверной (причем зачастую, это разделение контекстно-зависимо, на веб-приложениях свет клином не сошелся), а есть — среды обмена информацией между ними. Передача пароля открытым текстом относится к третьим. С чего бы это серверу станет пофиг, что механизм аутентификации (реализованный, кстати, на его стороне) потеряет свойство достоверности — я не понял

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

Остальное — вопрос терминологии, которой, без сомнения, вы владеете лучше. Уязвомость клиентской части многие менеджеры волевым решением вычеркнут, волюнтаристски выставив флаг "это не уязвомость". Это я с грустью вспоминаю.

KV>Это покроет только уязвимости этапа кодирования. Есть еще этапы проектирования, развертывания и вывода из эксплуатации.

Вы правы. Отмечу лишь, что обязанности "ревьювить разрабатываемые АПИ на предмет возможных уязвимостей" (С) Sinclair вряд ли смогут охватить упомянутые этапы.

KV>И не 139, а 135 все же. Он открыт, потому что его блокировка, в свое время, вызвала массу глюков с удаленным доступом по RDP, видимо из-за того, что сервисы Terminal Services Licensing и Terminal Services Session Directory используют этот порт, а помимо внешнего IP, сервер RSDN является также хостом во внутренней сети провайдера и хостом в локальной сети, а доступ по RDP необходим с каждой из этих сетей по ряду причин.

Конечно, 135, я опечатался. IMHO опаснейший порт ОС Windows. Впрочем, открытый впрямую RDP меня тоже пугает. Как сделал бы я? Сложно сказать. Но с высокой долей вероятности применил бы port knocking для внешних сетей. Не безопасности для, а в целях уменьшения вероятностей DDOS.

KV>Покажешь, где здесь оракул?

Навскидку нет. Но надо подумать, почитать на тему.
Само собой, первый попавшийся сканер сказал. Я мало того что не знаю платформу, на которой RSDN крутится, так еще и не имею достаточно времени для сколь-нибудь разумной оценки и поиска уязвимостей. Поэтому даже не буду пытаться давать рекомендации, что и как закрыть. Тот же login/password открытым текстом — честно сказать, не страшат меня. Ну украдет кто-то мой аккаунт. Честное слово, ничуть не жалко.

Здравствуйте, SkyDance, Вы писали:

KV>>Учитывая, что RSDN написан на C#, думаю, что Синклера не интересуют программисты, для которых он является довольно-таки необычным языком.

SD>Если Синклер все еще работает там, куда указывает его емейл — вопрос, вопрос. Возможно, его заинтересует какой-нибудь другой вебсайт на другой платформе.

"думаю, что Синклера не интересуют программисты" == "думаю, что Синклера не интересуют безопасники", опечатался. В общем-то, и для программиста зачастую не владеть несколькими языками на таком уровне — признак недостатка опыта, хотя и не всегда. Безопасник же, в чьи обязанности входит работа с кодом, обязан знать все языки с которыми ему предстоит работать, причем на довольно высоком уровне. Либо должно быть несколько безопасников. Например, на работе, я занимаюсь всем, что связано с C# частности и дотнетом в целом. Кроме того, в достаточной степени знаком с яваскриптом и питоном. А вот с явой, пхп и руби, например, могу быть только на подхвате, т.к. их спецификой (с т.з. узких мест защищенности) владею не вполне. Но нас — дофига человек в отделе и у каждого своя специализация, в чем-то дублирующая остальных, а в чем-то уникальная. В целом — это и дает неплохие результаты от оценки защищенности всей группой.

Но если у них предполагается один безопасник, то им либо нужно искать универсала, владеющего всеми целевыми языками, либо смириться с тем, что результаты его работы не будут в полной мере отражать реальную картину защищенности. По другому быть не может. Взгляните на статью и обсуждение: https://rdot.org/forum/showthread.php?t=950 и скажите: какой процент пхп-разработчиков владеют языком настолько, чтобы видеть описанные там уязвимости и быть способными показать реальную атаку на них и способы их устранения? А ведь это только один язык...

SD>Что ж тут непонятного? Владельцам сервера может быть совершенно некритична утрата достоверности механизма аутентификации.

Тогда зачем этот механизм реализовывали и тратили время разработчиков?

SD>Остальное — вопрос терминологии, которой, без сомнения, вы владеете лучше. Уязвомость клиентской части многие менеджеры волевым решением вычеркнут, волюнтаристски выставив флаг "это не уязвомость". Это я с грустью вспоминаю.

В Билайне, один такой менеджер однажды отправился искать другую работу. Именно по причине подобного волевого решения. По-всякому бывает

KV>>Это покроет только уязвимости этапа кодирования. Есть еще этапы проектирования, развертывания и вывода из эксплуатации.

SD>Вы правы. Отмечу лишь, что обязанности "ревьювить разрабатываемые АПИ на предмет возможных уязвимостей" (С) Sinclair вряд ли смогут охватить упомянутые этапы.

Смотря, что он подразумевал под API и "ревьюить". Ревью ведь может быть не только кода, но и всего проекта под названием "разрабатываемое API" в целом Думаю, тут проще сначала спросить у Синклера, что он имел ввиду

SD>Конечно, 135, я опечатался. IMHO опаснейший порт ОС Windows.

+1

SD>Впрочем, открытый впрямую RDP меня тоже пугает.

Меня пугает любой сервер, включенный в любую сеть. Вопрос только в степени паранойи

SD>Как сделал бы я? Сложно сказать. Но с высокой долей вероятности применил бы port knocking для внешних сетей.

Ага, а knocking sequence выбирать криптографически-стойкую, да Проще всего поднять там RRAS и пускать на сервер по RDP только из виртуальной сети. Но есть причины, связанные с текущим провайдером, по которым это (и порт-нокинг и впн) реализовать нереально.

SD>Не безопасности для, а в целях уменьшения вероятностей DDOS.

По 80-порту задосить будет всегда проще.

KV>>Покажешь, где здесь оракул?

SD>Навскидку нет. Но надо подумать, почитать на тему.

Особенно что-то читать по PO не стоит. Это была уязвимость фреймворка (ASP.NET) и пропатчена еще в 2010 году. В одном из ближайших номеров "Хакера" выйдет статья, где про padding oracle в ASP.NET будет рассказано как раз в том объеме, который необходим, чтобы не перегружаться реально лишней информацией

SD>Само собой, первый попавшийся сканер сказал. Я мало того что не знаю платформу, на которой RSDN крутится, так еще и не имею достаточно времени для сколь-нибудь разумной оценки и поиска уязвимостей. Поэтому даже не буду пытаться давать рекомендации, что и как закрыть. Тот же login/password открытым текстом — честно сказать, не страшат меня. Ну украдет кто-то мой аккаунт. Честное слово, ничуть не жалко.

А вот, если кто-нибудь украдет аккаунт администратора сайта... Собственно, на RSDN это нереализованно по двум причинам: SSL/TLS с невалидным сертификатом (либо валидным, но подписанным ЦС, инфа о котором "вшита" не во все веб-браузеры/ОС), с точки зрения защищенности — хуже, чем вообще без SSL/TLS. А валидный сертификат нужно приобретать, что в рамках некоммерческого проекта является обременительной задачей. Но главная причина заключается в том, что (опуская все выкладки) шифровать необходимо вообще весь трафик, включая статику, чтобы можно было говорить о том, что SSL/TLS выполняет возложенные на него функции. А это — нагрузка на сервер и прямой путь к DDoS-условиям, что в рамках RSDN куда более вероятная угроза, чем man-in-the-middle на администратора сайта.