Comments 23
Черный шрифт на сером фоне — эпично
UFO just landed and posted this here
Многие специалисты в сфере кибербезопасности начинали свой профессиональный путь на темной стороне. Есть ли у вас интересная история, связанная с приходом в индустрию?
— О, да, конечно. Сперва в школьные годы в далёком 1998-ом я сделала дефейс сайта майкрософот. Потом, повеселившись ещё немного, я решила начать монетезировать скилы и занялась промышленым шпионажем, ворованные разработки IBM, финансовые данные уолмарт и вот это всё. Когда пару моих друзей поймали и я поняла, что тут могут поймать и отшлёпать, я перешла на светлую сторону силы. А вы с какой целью интересуетесь?
— О, да, конечно. Сперва в школьные годы в далёком 1998-ом я сделала дефейс сайта майкрософот. Потом, повеселившись ещё немного, я решила начать монетезировать скилы и занялась промышленым шпионажем, ворованные разработки IBM, финансовые данные уолмарт и вот это всё. Когда пару моих друзей поймали и я поняла, что тут могут поймать и отшлёпать, я перешла на светлую сторону силы. А вы с какой целью интересуетесь?
Ну такое. Раз нет однозначного ответа на этот вопрос, лучше совсем его не писать, чем вот такое вот лицемерие.
Из описания по ссылке:
(компания) реализует пин-тесты, архитектурный консалтинг, различные тренинги и семинарыНовый термин какой-то)
Многие организации признаются, что стали жертвой WannaCry, но по сути это значит одно: «Мы не обновляем свой софт». Прискорбный факт.
Может ли обновление ПО нарушить безопасность? Конечно.А теперь хотелось бы услышать внятное изложение вопроса — надо ли обновляться. Не растекание мыслью по древу «бывает так, а бывает наоборот» — а чёткое и внятное изложение вопроса о том, как строить политику обновления, чтобы не остаться безоружным перед угрозами и при этом не втащить угрозу внутрь периметра своими же руками.
А если человек не может сказать ничего конструктивного — то и не надо говорить. Таких вот произносителей общих слов — толпы; и я тоже умею языком трепать. Недавно наш начальник нанял «специалиста по безопасности» — так у меня впечатление, что он знает много умных слов, но не понимает их смысла.
чёткое и внятное изложение вопроса о том, как строить политику обновления
Такого не бывает, зависит от многих факторов. Не бывает универсальных политик ИБ.
А в остальном согласен, для карьеры в ИБ гораздо полезнее уметь молотить языком, чем реально что-то делать. Сталкивался, печально. Побеждает не тот, кто хочет добиться реального результата, а тот кто директорату быстрее и красивее лапшу по ушам развесит.
Ну ладно, я не требую универсальной политики ИБ. Но хоть какой-то вменяемый алгоритм действий она предложить может?
Пока что я вижу только описание проблем, причём весьма неконкретное, а просто общие слова. И никакого указания на рекомендуемые действия.
Точнее, даются косвенные указания на противоположные действия. Если мне говорят об опасности от необновления и от опасности обновления — то я не понимаю, что мне рекомендуют: ставить все выходящие обновления немедленно при их выпуске или тянуть с этим. Если тянуть — то сколько времени. Если ставить не все обновления — то как выбирать нужные. Как строить политику обновления для разных продуктов.
Вот это надо говорить. А не рассказывать, что вредоносный код м.б. внутри JS.
Также актуальным мне кажется рассказ о том, каким образом разные фирмы-производители систем (аппаратуры, операцонок, прикладного софта, интегрированных решений) понижают количество ошибок, приводящих к уязвимостям в их продуктах.
Паула пишет: «Я доверяю Azure, потому что это уже зрелый продукт с широкой функциональностью». Ок, но как можно отличить зрелый продукт от незрелого? (Широта функциональности — публикуется разработчиками и достаточно легко проверяется.)
Один товарищ агитирует меня за новомодные способы программирования — декларативное программирование и ответвления от этого направления. Я не очень разобрался в этом вопросе, хоят с первого взгляда видно, что этот путь действительно позволяет частично передать проверку корректности программ компилятору; однако, мне пока неясно, насколько много можно доверить компилятору.
Мне бы хотелось посмотреть, как типичные алгоритмы программирования (тиа сортировок массива разными методами) реализуются на обычном (императивном) языке типа Си и на декларативном — и как декларативный язык избавляет от ошибок, приводящих как к некорректности программ, так и к их неэффективности. И вообще оценить перспективность этого пути.
У меня есть идея, как построить некоторую защиту аппаратными средствами. Для этого нужно реализовать работу с памятью не как с неструктурированным набором байтов, к которому можно обращаится любыми способами; а сделать что-то типа сегментов. Но не таких сегментов, как в x86 (там внутри каждого сегмента — всё равно неструктурированнй набор байтов), а сегментов, имеющих внутреннююю структуру. Например, простой сегмент может содержать в себе только 32-битные целые числа, и это прописано в его дескрипторе; при попытке читать/писать плавающие числа или отдельные байты — «программа выполнила недопустимую операцию».
С массивами такая система будет очень хорошо работать, в т.ч. защитит от переполнения буфера. Впрочем, от переполнения буфера защищают и сегменты в x86; но там сегменты сделаны неудобно, а переключение сегментов очень затратно.
Дальше трудность в том, что программисты используют сложные структуры, сочетающие в себе данные разных типов. Как сделать дескриптор сегмента, описывающий структуру — я не придумал. Не исключено, что эта идея вообще бесперспективна.
Тот товарищ утверждает, что декларативные языки позволяют возложить проверку «не пытается ли программа положить в память значение одного типа, а прочесть значение другого типа» на компилятор. Впрочем, такая проверка была ещё в древнем языке Fortran — за счёт существенных ограничений на свободу программиста. И границы буфера там тоже проверялись.
Может, действительно пора запретить программистам использовать опасные языки? Ну, то есть — если программист допустил ошибку, создавшую уязвимость, то проводится расследование, выявляется виновный, и ему запрещают использовать опасный язык программирования. Ну, не навсегда, а на пару лет. Ответственность за надзор — на работодателе; если же работодатель не уследил — то оплачивает ущерб от уязвимости пострадавшим клиентам. В результате опасные языки будут использовать только высококвалифицированные программисты; или в областях, где уязвимость неактуальна.
Ну а если в каком-то продукте количество ошибок, породивших уязвимости, превышает некоторый предел — то весь продукт переводится на безопасный язык программирования. Ибо нефиг.
Хотя мне кажется, что криворукие недоумки сумеют делать ошибки даже на безопасном языке. Ибо А.Эйнштейн полагал, что есть две бесконечные вещи: Вселенная и человеческая глупость; причём похоже, что Вселенная всё-таки небесконечна (спросита Итана). И ошибки на безрпасном языке найти будет крайне сложно.
Наверно, надо ввести ответственность (материальную, а то и уголовную) производителей программных систем за допущенные уязвимости. Есть же законы о защите прав потребителей, по которым потребитель имеет право на безопасность, и при этом не обязан разбираться в устрйостве/архитектуре купленного товара. Или программистам закон не писан? Тогда почему они апеллируют к закону для защиты от пиратов?
Вернёмся к теме. Может, я зря обвиняю Паулу в фуфлогонстве? Может, это ей такие дурацкие вопросы задали?
Пока что я вижу только описание проблем, причём весьма неконкретное, а просто общие слова. И никакого указания на рекомендуемые действия.
Точнее, даются косвенные указания на противоположные действия. Если мне говорят об опасности от необновления и от опасности обновления — то я не понимаю, что мне рекомендуют: ставить все выходящие обновления немедленно при их выпуске или тянуть с этим. Если тянуть — то сколько времени. Если ставить не все обновления — то как выбирать нужные. Как строить политику обновления для разных продуктов.
Вот это надо говорить. А не рассказывать, что вредоносный код м.б. внутри JS.
Также актуальным мне кажется рассказ о том, каким образом разные фирмы-производители систем (аппаратуры, операцонок, прикладного софта, интегрированных решений) понижают количество ошибок, приводящих к уязвимостям в их продуктах.
Паула пишет: «Я доверяю Azure, потому что это уже зрелый продукт с широкой функциональностью». Ок, но как можно отличить зрелый продукт от незрелого? (Широта функциональности — публикуется разработчиками и достаточно легко проверяется.)
Один товарищ агитирует меня за новомодные способы программирования — декларативное программирование и ответвления от этого направления. Я не очень разобрался в этом вопросе, хоят с первого взгляда видно, что этот путь действительно позволяет частично передать проверку корректности программ компилятору; однако, мне пока неясно, насколько много можно доверить компилятору.
Мне бы хотелось посмотреть, как типичные алгоритмы программирования (тиа сортировок массива разными методами) реализуются на обычном (императивном) языке типа Си и на декларативном — и как декларативный язык избавляет от ошибок, приводящих как к некорректности программ, так и к их неэффективности. И вообще оценить перспективность этого пути.
У меня есть идея, как построить некоторую защиту аппаратными средствами. Для этого нужно реализовать работу с памятью не как с неструктурированным набором байтов, к которому можно обращаится любыми способами; а сделать что-то типа сегментов. Но не таких сегментов, как в x86 (там внутри каждого сегмента — всё равно неструктурированнй набор байтов), а сегментов, имеющих внутреннююю структуру. Например, простой сегмент может содержать в себе только 32-битные целые числа, и это прописано в его дескрипторе; при попытке читать/писать плавающие числа или отдельные байты — «программа выполнила недопустимую операцию».
С массивами такая система будет очень хорошо работать, в т.ч. защитит от переполнения буфера. Впрочем, от переполнения буфера защищают и сегменты в x86; но там сегменты сделаны неудобно, а переключение сегментов очень затратно.
Дальше трудность в том, что программисты используют сложные структуры, сочетающие в себе данные разных типов. Как сделать дескриптор сегмента, описывающий структуру — я не придумал. Не исключено, что эта идея вообще бесперспективна.
Тот товарищ утверждает, что декларативные языки позволяют возложить проверку «не пытается ли программа положить в память значение одного типа, а прочесть значение другого типа» на компилятор. Впрочем, такая проверка была ещё в древнем языке Fortran — за счёт существенных ограничений на свободу программиста. И границы буфера там тоже проверялись.
Может, действительно пора запретить программистам использовать опасные языки? Ну, то есть — если программист допустил ошибку, создавшую уязвимость, то проводится расследование, выявляется виновный, и ему запрещают использовать опасный язык программирования. Ну, не навсегда, а на пару лет. Ответственность за надзор — на работодателе; если же работодатель не уследил — то оплачивает ущерб от уязвимости пострадавшим клиентам. В результате опасные языки будут использовать только высококвалифицированные программисты; или в областях, где уязвимость неактуальна.
Ну а если в каком-то продукте количество ошибок, породивших уязвимости, превышает некоторый предел — то весь продукт переводится на безопасный язык программирования. Ибо нефиг.
Хотя мне кажется, что криворукие недоумки сумеют делать ошибки даже на безопасном языке. Ибо А.Эйнштейн полагал, что есть две бесконечные вещи: Вселенная и человеческая глупость; причём похоже, что Вселенная всё-таки небесконечна (спросита Итана). И ошибки на безрпасном языке найти будет крайне сложно.
Наверно, надо ввести ответственность (материальную, а то и уголовную) производителей программных систем за допущенные уязвимости. Есть же законы о защите прав потребителей, по которым потребитель имеет право на безопасность, и при этом не обязан разбираться в устрйостве/архитектуре купленного товара. Или программистам закон не писан? Тогда почему они апеллируют к закону для защиты от пиратов?
Вернёмся к теме. Может, я зря обвиняю Паулу в фуфлогонстве? Может, это ей такие дурацкие вопросы задали?
Может ли обновление ПО нарушить безопасность? Конечно.
Можно ли обходиться без обновлений? Да, но у вас, предельно безопасно, ничего не будет работать должным образом. Остановка в развитии тоже крайне опасна.
Вспомните момент, когда вы появлялись на свет: это было точно по беспечности ваших родителей. Но как же это прекрасно!
Неужели слово «проникновение» никаким другим нельзя было заменить?
Симпатичная, прям сразу хочется 22 порт открыть)
Ботнеты очень опасны.
И дело не в масштабах,
а в том, что мы можем
не знать об этой активности в нашей среде, о том, что где-то запускается неизвестный нам код.
Ой, даже сколько нибудь продвинутые админы, анализируют активность внутри сетей (и оборудования) и адекватно на неё реагируют, плюс некоторые автоматизированные средства существуют уже лет пятнадцать наверное…
Правда в том, что не возможно защититься от всех мыслимых угроз и оно нафиг не надо, достаточно защититься от реально опасных последствий, а это уже вполне реально…
И вообще, адекватная модель реальных угроз, наше всё, тут мало чисто технических навыков, тут надо буквально по жить на «тёмной стороне», что бы приносить реальную пользу…
Легенда про переход с тёмной стороны на светлую, это литературное бла-бла-бла.
В наше время, наивного сетевого оборудования, школоло массово ходило в корпоративные сети, ради халявного интернета (и йа там быль), там было ещё много чего интересного, только вот спроса на это не было, точнее был но искусственный, искусственно созданный взрослыми дядьками, которые не фига не разбирались в x25 и сиськах, им было достаточно практической криминалистики :-)
So… не трудно было попасть в корпоративную сеть и всех там заразить (а на фига?), сложнее было научиться получать с этого гешефт, причём порою самыми не обычными способами, даже не приводящими к конфликту интересов.
А вот как с точки зрения закона, трактовать деятельность некоторых тестеров безопасности и антивирусных компаний, это хороший вопрос? По факту написать упаковщик который проскочит антивирь, не сложно, не сложно гадкое чего-ето с браузером сотворить используя 0day (причём и первое и второе не обязательно делать самостоятельно, можно просто купить и не так уж и дорого), произвести впечатление на клиента, стричь с него бабки :-) никак при этом не повлияв на реальный расклад в безопасности оного! это мошенничество господа :-)
Народ, неужели вы не видите, что эта дама — из другого мира. Этот мир называется «Корпоративное паразитирование на бессмыслице». Журнал «Информационная безопасность» с его статьями для менеджеров тоже оттуда. По ответам же видно, что как специалист ИБ — я имею в виду настоящую ИБ а не бумажную — она полный ноль.
Она менеджер с дипломом по ИБ, она хорошо развила навыки презентации, выступает на конференциях, пиарится, продвигает свой брэнд. Но она не занимается технической частью.
blogs.technet.microsoft.com/rutechnews/2017/09/25/11-okt-webinar-security-windows-enterprise
По ссылке цитирую: "… В портфолио Паулы Янушкевич сотни проектов как в крупных коммерчских компаниях, так и государственных организациях..." За 14 лет она что лично закрыла СОТНИ проектов в крупных коммерческих и госкомпаниях? Нет конечно!
blogs.technet.microsoft.com/rutechnews/2017/09/25/11-okt-webinar-security-windows-enterprise
По ссылке цитирую: "… В портфолио Паулы Янушкевич сотни проектов как в крупных коммерчских компаниях, так и государственных организациях..." За 14 лет она что лично закрыла СОТНИ проектов в крупных коммерческих и госкомпаниях? Нет конечно!
Всегда было интересно, выходят ли такие девушки замуж.
Sign up to leave a comment.
Этичный хакер Паула Янушкевич о кибербезопасности и гиперугрозах