IT Band

Денис Колошко - CEO и основатель проекта по веб-безопасности Dhound.io, cертифицированный CISSP эксперт. Более 15 лет занимается разработкой ПО (банковские и страховые системы, автоматизация бизнеса), последние 8 лет в роли СТО были тесно связаны с безопасностью. В интервью он расскажет об отношении белорусского IT-сообщества к вопросам информационной защиты и даст несколько рекомендаций, которые помогут снизить риски взлома и утечки данных.

- Денис, расскажите, что такое безопасность для вас?

- Безопасность для меня - это прежде всего процесс. Процесс управления безопасностью, который начинается ещё на стадии сбора требований к системе и их верификации. Мало выстроить защиту, её необходимо ещё и постоянно поддерживать, мониторить и управлять ею. Приведу пример, есть знакомая компания, которая приобрела монитор безопасности. Когда в пайплайне оказалось слишком много инцидентов для исследования из-за того, что команда постоянно отвлекалась на “срочные” функциональные задачи, они отказались на время от монитора и начали искать человека, который постоянно будет заниматься управлением безопасностью системы и будет нести персональную ответственность.

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

Сертификация компаний в области безопасности всегда оценивает прежде всего именно процессы.

- А как возникла идея создать свой проект в сфере веб-безопасности?

Для меня, как для СТО, остро встал вопрос защиты используемых нами серверов. Мы давно работаем с достаточно серьезными бизнес-системами, которые оперируют с персональными данными, что требовало применения особых мер в плане безопасности еще задолго до GDPR. Нам не хватало прозрачности безопасности на наших серверах, поэтому обратили внимание на  IDS (прим. IDS - intrusion detection system, система обнаружения вторжений), и после длительных поисков ни одно решение нас не устроило. Все найденные варианты можно было разделить на два лагеря: очень громоздкие и дорогие enterprise решения или open source в стиле “гики для гиков”, для которых слово UX было чуждым. Так и пришла идея разработать свою IDS для своих собственных нужд, которая со временем начала обрастать и другими полезными фичами и сервисами, и затем превратилась в продукт.   

- В последнее время вопросы безопасности данных действительно стали очень актуальными, для Беларуси это тоже характерно?

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

В целом уровень “security maturity” в белорусском сообществе все еще относительно низкий, этот термин означает уровень зрелости компаний в управлении безопасностью и поставки высоко-защищенных систем. Здесь можно говорить и о недостатке кадров, нехватке знаний, малой мотивированностью.  Но мы уже способны предлагать качественные решения, быть проактивными, не быть просто исполнителями, а быть экспертами - за что, кстати, зарубежные клиенты идут в Беларусь.

В основном, сейчас осознание приходит, когда уже “петух клюнул”. То есть после взломов, или того хуже - утечек данных. Это, к сожалению, уже поздно. Не привыкли у нас работать на профилактику, а о том, что на “лечение” взломанной системы уйдет гораздо больше средств, чем на ту самую пресловутую профилактику, никто не думает. Если IT сообщество еще хоть как-то “в теме”, то взять любые другие сферы - там совсем все плачевно. Например, спросите владельца или управляющего белорусского не сетевого отеля: “У Вас останавливаются гости из ЕС? А как вы обеспечиваете безопасность его персональных данных, которые попадают в вашу компьютерную систему после его регистрации? А вы слышали про GDPR? А кто у вас ответственный за информационную безопасность?” Как вы думаете, после ответа на первый вопрос, вы получите еще ответы?

- А в вашей компании все сотрудники вовлечены в вопросы безопасности?

- Да, все, тем или иным способом, но все. Часть процесса управления безопасностью - это постоянное обучение и развитие команды. У нас разработан свой собственный Security Development LifeCycle, который интегрирован в процесс разработки на каждую стадию, начиная со стадии сбора требований по безопасности и их верификации, проработки архитектуры, соответствия стандартам безопасности и документирования в Architecture Design Document перед началом работ, и заканчивая регулярным мониторингом поставленных систем.

Также у нас есть хорошая традиция, раз в месяц объявляется Security Day, и в этот день один из разработчиков, назначаемый Head of Dev, занимается проверкой безопасности на всех проектах компании, а после проверки всех систем он рассылает команде письмо с краткими результатами выполненной работы. Далее инициируется обсуждение и исправление выявленных ошибок. Еще одна хорошая традиция - это внутренние конференции. Ежеквартально мы у себя проводим небольшие внутренние конференции, когда несколько сотрудников, обычно 5-6, готовят доклады по темам, которых они тесно касались в своей работе в последнее время, или им просто очень нравится тема, и они хотели бы с ней поработать в будущем. Один из докладов всегда связан с безопасностью. Вот так и получается занятный ликбез по вопросам безопасности на ежеквартальной основе.

- Говорят, что безопасность это дорого. Так ли это?

Все в этом мире относительно. Выстраивание системы безопасности и процессов управления - это всего лишь средство. Конечная цель - снизить риски для конечного бизнеса. Для этого их необходимо правильно определить и оценить. Риск можно либо нивелировать, либо принять его, что он такой есть. Многослойная защита с набором дорогостоящих контролов безопасности не всегда нужна для небольшого или среднего бизнеса, потому что это только может создать новый для них риск. Но все равно есть минимальный уровень, ниже которого опускаться не стоит, поставляя непроверенную систему и не предлагая мер по защите. Поэтому сам владелец системы определяет, что ему дороже - взять экспертизу по безопасности и по архитектурам и нивелировать риск, либо принять риск и быть готовым оплачивать последствия.

- Часто вообще в Беларуси компании подвергаются хакерским атакам?

- Конечно, как и везде. Ни ваше местонахождение, ни размер вашей компании никак на это не влияют. Бытует мнение, что хакерам интересны только большие корпорации. Это не так, под угрозой все, и не надо думать, что если ваш бизнес маленький, то вы никому не интересны. Конечно, при взломе системы большой и известной компании хакеры получают информацию, которую можно очень дорого продать или требовать за нее выкуп. Но а взломав сервера небольшой компании, можно с них спамить или проводить дальнейшие атаки, и быть уверенным, что вас обнаружат ой как нескоро, ведь какое дело маленькой компании до безопасности, правда? Хакерские атаки происходят постоянно, и сохранность вашей системы и ваших данных зависит от того, насколько грамотно выстроена защита и насколько быстро вы способны обнаружить и отреагировать на злоумышленника. А если злоумышленник ваш сотрудник, или он уже уволен, но никто не позаботился о том, чтобы закрыть все его доступы к системе? Таких обнаружить очень сложно, но при создании нашей IDS мы это учитывали - возможность обнаружить подозрительную активность даже легитимных пользователей системы. А иногда сотрудники, даже не имея злых намерений, могут стать угрозой для бизнес-системы просто нажав на подозрительную ссылку в письме. Поэтому очень важно, чтобы забота о кибербезопасности в компании лежала не только на плечах конкретного отдела или сотрудника, все должны быть вовлечены в это, проводите ликбезы для вашей команды: какими должны быть пароли, где они должны храниться, что может случиться при их передаче коллеге - это азы, но это поможет серьезно снизить риски быть взломанным по причине человеческого фактора, а эта причина превалирует в мире в последние годы.

- Денис, Вы являетесь одним из трех обладателей сертификата CISSP (Certified Information Security Systems Professional) в Беларуси, расскажите немного о сертификации.

- CISSP сертификация одна из топовых сертификаций в индустрии безопасности и требует достаточно широких знаний в этой сфере. Сам экзамен действительно был сложным. CISSP сертификат ценится особенно за рубежом, где без подобного подтверждения экспертизы нельзя претендовать на некоторые должности, например, Chief Information Security Officer.

Сертификация позволяет освежить знания и легче ориентироваться в стандартах, регламентах, процессах, управлении рисками, новых подходах и контролах безопасности. Крупные игроки обычно умеют оценивать собственные риски, поэтому перед заключением контракта присылают длинные листы с вопросами по безопасности, стандартам, соответствиям, и CISSP сертификация расценивается ими как доказательство экспертизы в области безопасности.

- А что такое тестирование на проникновение?

- Тестирование на проникновение (или penetration testing) - это поиск уязвимостей в системе. Часто одним из условией для поставки enterprise решений является проведение пен-теста сторонней компанией не реже, чем раз в год. Мы сами предоставляем подобную экспертизу, иногда приходится заказывать пен-тест на стороне для наших же систем. Найти хорошего пен-тестера ещё нужно постараться, часто они используют автоматические инструменты, которые дают достаточно низкий результат, и меньше уделяют времени ручному тестированию. Мы со своей стороны наоборот основной упор делаем именно на ручное тестирование, чтобы каждый параметр каждой страницы был проверен. Мало провести тестирование, нужно ещё сделать правильный delivery в виде отчета, в котором отражена проделанная работа, найденные уязвимости, оценены риски и даны рекомендации по их уменьшению. Ещё ни один наш отчет не обходился без найденных уязвимостей.

Если совсем уверены в защите, можете зарегистрировать систему на площадках типа HackerOne, где обычно быстро развеивают уверенность в безопасности системы на 100%.

- Какие базовые рекомендации вы бы дали тем, кто хочет повысить уровень безопасности своих веб-проектов?

- Проводя тренинги, я обычно исхожу из гипотезы, что “нельзя защитить то, что не знаешь, как взломать”. Поэтому учитесь взломам, новым техникам, пробуйте различные инструменты.

Основные принципы надо закладывать еще на стадии построения архитектуры, например, уменьшение области атак. Лучший способ защититься - это вообще свести к нулю возможность поломать или побрутфорсить вашу админку по SSH, FTP или RDP. Это надо учитывать при проектировании защищенной архитектуры.   

Далее файерволы, благо их уже все стали использовать. Но если с фильтрацией входящего трафика справляются, то исходящий трафик обычно не контролируется, а очень зря. Потому что, если злоумышленник обошел вашу защиту и начал сливать данные, засечь его как раз таки можно будет по исходящему трафику. Так можно предотвратить или минимизировать утечку данных. Особый упор на мониторинг исходящего трафика мы делали и в нашей IDS.

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

Шифрование данных, двухфакторная аутентификация, много чего хочется посоветовать, но тогда это превратиться в лекцию. К тому же любая система имеет свои особенности и требует специфических мер по защите.

- Ну и последний вопрос, Денис, недавно вы окончили факультет философии БГУ, что же вас подтолкнуло к этому, и как это помогает вам в жизни или работе?

- На dev.by была как-то статья о нехватке гуманитарного знания у белорусской IT сферы. Полностью соглашусь с этим. Поставляемые системы - это не просто набор форм, реализованных по вайфрэймам. Это решение определенной проблемы для бизнеса. И это решение не всегда требует только лишь технических знаний.

Обычно выделяют три уровня мышления и деятельности: операционный, тактический и стратегический. Философия и на работе, и в жизни помогает выйти на более высокий уровень - смысловой. Когда постоянно задаешься предельными вопросами смысла того, что делаешь, над чем работаешь и для чего это все надо. Любая система определяется не выбранной стратегией, а смыслом своего собственного существования. Любая форма заканчивает свое существование в момент исчерпания своего собственного смысла (система, архитектура, физическое тело). Именно смысловой уровень позволяет отрефлексировать, взглянуть на принимаемые решения со стороны и правильно принять решения на более низких уровнях, избегая ненужной и бессмысленной деятельности.

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

Приветствую читателей dev.by!

Некоторое время назад столкнулся с необходимостью найти достойную систему обнаружения вторжений (intrusion detection system - IDS), далее по тексту будем использовать сокращение IDS. Необходимо было мониторить сервера, на которых хостятся приложения наших клиентов. И после длительных и утомительных поисков все найденные варианты можно было разделить на два лагеря:

1. Гики для гиков:  сложные для управления и понимания open source решения, которые даже не имеют вменяемого интерфейса, работать в них можно только через консоль, и без солидного опыта и знаний в сфере кибер-безопасности с ними не разберешься. Да, мы для себя могли использовать такой вариант, но отдать это клиентам (которые, в свою очередь, далеко не технические люди)  мы не могли.
2. Дорогие enterprise решения: рассчитаны на сложные и большие структуры, половина их функционала просто не нужна web-приложениям, а платить огромные суммы за установку и обслуживание системы, в которой будут использоваться пару функций, как-то очень не хочется.

Всё это натолкнуло нас на мысль написать свою IDS, покрывающую наши нужды: простую и удобную в управлении, имеющую понятный и привлекательный интерфейс систему. Благо, большой опыт консультирования по вопросам безопасности и свой CISSP специалист в штате позволяли это сделать.

Так родилась наша IDS, ее основными функциями стало отслеживание доступов к серверу, проверка наличия сторонних соединений и подозрительной активности, оповещение об успешных подозрительных событиях, возможность создания собственных правил (групп доверенных источников, IP-адресов), и всё это для интернет-серверов.

После успешного имплементирования и работы системы на наших проектах мы подумали, что, возможно, кто-то столкнулся с похожей проблемой и находится в поисках простой и эффективной IDS. Выдвинули гипотезу, что такая система будет интересна не техническим людям, имеющим малый/средний бизнес, построенный на работе их web-приложения. И, собственно, пошли в народ проверять нашу гипотезу.

Мы не ожидали очень высокого интереса к вопросам web-безопасности у данной аудитории, но, как оказалось, интерес к этой теме отсутствовал вовсе.

“Web-безопасность? Нет, не слышали” – так можно охарактеризовать их подход. Найденные и представленные им уязвимости их никак не мотивировали. То, что их приложения работают с персональными данными их клиентов и, как следствие, требуют особой защиты, тоже не стало мотиватором. Заинтересованными представителями данной аудитории были только те, кто сам приходил за помощью после реального взлома. Правильно, не привык наш бизнес работать на профилактику/предотвращение угроз – «это может коснуться всех, но не меня», думаем мы.

Поразмыслив над всем этим, мы перешли к формированию другой гипотезы. Текущая гипотеза такова, что в использовании системы обнаружения вторжений могут быть заинтересованы техлиды, CTO (Chief Technology Officer) или CIO (Chief Information Officer) в средних и крупных IT-компаниях (стартапах или близких к IT: новостные порталы, туристические порталы, системы онлайн бронирования и др.)  

Но перед этим хотелось бы вообще в принципе проверить уровень осознания у IT-сообщества того, что web-безопасность важна и необходима (так называемая security maturity). И просим неравнодушных читателей dev.by поучаствовать в исследовании.

Спасибо за внимание!

 Денис Колошко, CISSP

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

Прежде чем будем искать применение блокчейну нужно понять, что же это такое и какое конкурентное преимущество по сравнению с другими технологиями оно дает.

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

По своей сути блокчейн схож с паттерном CQRS, в основе которого лежит event sourcing. Если максимально упростить, и там и там есть только поддержка insertов, если говорить терминами баз данных. Update и delete для сущностей не поддерживаются. И если в системах построенных по CQRS никто не мешает удалить или обновить событие из журнала, то в блокчейн это невозможно из-за целостности всего журнала.

Отсюда вытекает первое и основное требование к системам, в которых стоит применять блокчейн - это априори недоверие пользователей системы друг к другу. Т.е по умолчанию каждый участник считается лжецом, который может скомпрометировать данные.  По сути, блокчейн - это способ защиты от мошенничества в информационных системах. Не было бы “мошенников” в нашем мире, не было бы необходимости в блокчейне.

Ключевым свойством технологии blockchain, которое отличает ее от традиционной технологии баз данных, является общедоступная проверка, которая обеспечивается целостностью и прозрачностью.

• Целостность - каждый пользователь может быть уверен, что данные, которые он получает, являются неповрежденными и неизменными с момента их последней записи.
• Прозрачность - каждый пользователь может проверить, как блокчейн обновлялся с течением времени.

Преимущества распределенной системы журнала транзакций выходят за рамки сектора финансовых услуг, который является основным “заказчиком” блокчейна. В государственном секторе безопасный распределенный регистр может обеспечить большую открытость и прозрачность, а также преобразовать такие услуги и процессы, как лицензирование, личная идентификация, голосование,  управление прибылью и многое другое. Такие отрасли, как розничная торговля и производство, могут также выиграть от лучшего управления цепочками поставок, умных контрактов, не опасаясь, что информация будет искажена.

Еще одной сферой применения блокчейна является здравоохранение. В здравоохранении журнал транзакций устраняет все громоздкие, дорогостоящие сторонние верификаторы, напрямую связывая записи пациентов с клиниками и финансово заинтересованными сторонами. Информация, хранящаяся в блочной цепочке, может использоваться для обеспечения быстрого, надежного, аутентифицированного доступа к персональным медицинским документам для организаций здравоохранения.

Теперь перейдем к минусам данной технологии.

1. Для того чтобы обеспечить пресловутую прозрачность блокчейна, необходимо чтобы все данные были публичными. Это означает, что нет возможности скрыть часть данных от пользователей, которые к ним доступа иметь не должны. Хотя уже существуют проекты, которые позволяют обойти это ограничение. Например, Hyperledger.
2. Для меня до сих пор остаётся вопросом, кто будет “майнить”, т.е собирать транзакции в блоки цепочки. Если в криптовалютах за этот процесс майнеры берутся за вознаграждение, то кто будет этим заниматься в корпоративных блокчейнах? Если только централизованный сервер, но опять таки возникает риск компрометации данных.
3. Также не маловажным фактором при выборе блокчейна является производительность системы и объемы памяти, занимаемые журналом транзакций. Если производительность стоит на первом месте, и количество транзакций ожидается приличным, то стоит дважды подумать, выбирая блокчейн.
4. И как же без всеми любимого GDPR. Тут появляется проблема попадания пользовательских данных в блокчейн. Однажды оказавшись в журнале, уже не получится их оттуда удалить. “Что написано пером, того не вырубишь топором”.

Что хотелось бы сказать в заключение, всегда тщательно взвешивайте технические решения, которые будете принимать на проектах.

Ссылки:

https://blogs.msdn.microsoft.com/uk_faculty_connection/2016/05/12/so-what-is-blockchain/

https://azure.microsoft.com/en-us/blog/blockchain-the-catalyst-for-a-collaborative-economy/

https://hackernoon.com/blockchains-versus-traditional-databases-c1a728159f79

https://techbeacon.com/Blockchain-relational-database-which-right-for-your-application

Автор - Михаил Шишло, Руководитель отдела разработки IT Band, Dhound

Как давно вы проверяли надежность своего SSL? Мало просто купить SSL сертификат и  его установить, нужно его и настроить.

Почему это важно. Внешний анализ безопасности (ручной или автоматический) обычно начинается с проверки SSL-конфигурации. SSL конфигурация обычно показывает общий уровень защищенности всей системы защиты данных. Поэтому продвинутые пользователи начинают слать запросы типа “как вы можете защитить мои персональные данные, если у вас ещё SSL v3 включён”. В рамках GDPR надежная настройка SSL относится к техническим мерам по защите персональных данных.

Тестирование конфигурации SSL

Проблемы связанные с версиями SSL протоколов:

• SSL v2 небезопасен, устарел и не рекомендуется для использования. См. атаку DROWN по этому протоколу.
• SSL v3 небезопасен и устаревший инструмент. См. атаку POODLE.
• TLS v1.0 также является устаревшим протоколом, но на практике он все же оказывается необходим. Его основная слабость (BEAST) была смягчена в современных браузерах.
• TLS v1.1 и TLS v1.2 оба не имеют известных проблем с безопасностью, но только v1.2 предоставляет современные криптографические алгоритмы.

SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1).

Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.

Анализ конфигурации SSL

Есть замечательный инструмент SSLLabs Test Tool для проверки тестирования надёжности конфигурации SSL.

A+ и А - это наилучший показатель конфигурация SSL. F - наихудший уровень.

Пример теста SSL для одного из сайтов продуктов (Dhound)

Ниже приведен еще один пример того, как быстро проверить уровень SSL-конфигурации с помощью инструмента nmap:

Надежные шифры

Низкий уровень конфигурации SSL в большинстве случаев связан с использованием устаревших и слабых алгоритмов шифрования.

Этот ресурс предоставляет информацию о том, как настроить хорошие SSL-алгоритмы на Apache, nginx, HAProxy и т. д.

Конфигурация на Nginx

Ниже приведен пример конфигурации веб-серверов Dhound nginx, которые повысили настройку SSL с уровня B до A + и повысили защиту системы:

Конфигурация на Windows

Windows Server 2016 и выше уже имеют конфигурацию SSL, которая соответствует действующим регламентам безопасности (например, SSL v2 и SSL v3 отключены).

В более ранних версиях Windows Servers (2008, 2012) SSL v3 все еще включен, т. е. Вам необходимо вручную отключить устаревшие протоколы. См. рекомендации Microsoft: как отключить PCT 1.0, SSL 2.0, SSL 3.0 или TLS 1.0

Мы используем инструмент IIS Crypto tool, который предоставляет графический интерфейс для отключения слабых шифров и устаревших протоколов. Это позволяет избежать опасной ручной работы с реестром Windows.

Использование SSLLabs Test Tool, его советов и функциональных возможностей позволяет быстро защитить SSL / TLS на Windows.

Реальный пример конфигурации SSL для Windows Server 2012 R2

Для большей информации о настройке SSL смотрите Dhound Knowledge Center.

Автор - Денис Колошко, CISSP, CEO at Dhound

CEO стартапа по обнаружению внешнего воздействия на ИТ-системы Dhound.io Денис Колошко написал для dev.by колонку о том, как компаниям стоит подготовиться к вступлению в силу европейских правил по защите данных — и каким компаниям стоит это сделать.

Автор: Денис Колошко, CEO at dhound.io

 CISSP (Certified Information Security Systems Professional) относится к “золотому стандарту” в индустрии безопасности и входит в топы IT сертификаций. На 1-ое января 2018 года сертифицированы только два человека в Беларуси, одного из которых я знаю - Иван Подобед. 13 февраля 2018 был сертифицирован третий человек - Денис Колошко, автор статьи, которая собственно и расскажет о самом сертификате и процессе сертификации.

Сложность сертификации

Изначальные требования для прохождения сертификации достаточно высоки, возможно, поэтому это отпугивает многих: минимум 5 лет подтвержденного опыта в области безопасности как в минимум в 2 из 8 доменов, которые покрывает CISSP (о доменах ниже).

Экзамен действительно сложный. До этого у меня было 12 Майкрософт сертификаций, которые рядом не стояли по сложности, требованию к уровню знаний. CISSP требует очень широких знаний безопасности, покрывается большой диапазон от физической защиты активов до управления безопасностью на предприятии уровня enterprise.

Все эти сложности определенно сказываются на качестве и ценности самой сертификации.

Что дает сертификат

Из 15 лет опыта в IT, около 7-8 из них тесно связаны с безопасностью (разработка высоко-защищенных архитектур, web security анализ, ручной пенетрейшн тестинг, разработка собственной lightweight intrusion detection system-ы dhound.io, управление безопасностью). И каждый раз, когда дело касается безопасности, продавцы и клиенты задавали один и тот же вопрос “как вы можете подтвердить свой опыт”.

То есть первое, что я получил от сертификации - наличие доказательства экспертизы в области безопасности.

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

Если говорить в целом о безопасности. Мало знать некие отдельные технические детали -  современные условия требуют знаний управления самой безопасности. Оценка и управление рисками, моделирование угроз, многоуровневая защита, стандарты и фреймворки безопасности, Business Continuity и Disaster Recovery планы, уровни классификации данных, что выливается в многочисленные политики, гайдланы, процедуры и так далее. Согласно тому же GDPR (General Data Protection Regulation), если вы не можете документально показать, что соответствуете этому предписанию, то уже не важно, насколько хорошо ваша система построена - вы не соответствуете. Со всем этим делом был уже знаком, но CISSP помог структурировать информацию относительно тех же стандартов и их требований.

Ещё один немало важный момент - сама подготовка к экзамену позволяет освежить знания, которые не требуются каждый день и подзабываются. Кто сейчас сходу может вспомнить, какой режим симметричного шифрования в каких случаях лучше всего использовать: ECB, CBC, CFB, OFB или CTR? В чём отличия между HMAC, CBC-MAC и СМАС для гарантии целостности сообщения? Вот и я про то. Главное, даже не в том, чтобы это запомнить (для экзамена придётся), а в том, чтобы в дальнейшем знать куда посмотреть, чтобы принять правильное решение. “Припомнить” хорошо забытые знания полезно время от времени.

Домены

Как было сказано выше, CISSP покрывает 8 доменов в области безопасности.

Домен #1. Security and Risk Management - вопросы стандартов и фреймворков безопасности (ISO/IEC 27000, ITIL, SABSA, COBIT, NIST, ...), регламентов и актов (GDPR, PCI DSS, HIPAA, Patriot Act, ...), конфиденциальность, фреймворки по управлению рисками (ISO 31000, COSO, NIST). Короче, всё, что связано с мировыми практиками и стандартами в области безопасности.

Домен #2. Asset Security - классификация данных, жизненный цикл данных, уровни ответственности в организации, политики хранения данных, стратегии защиты и удаления данных

Домен #3. Security Engineering - криптография, системы управления ключами, защитные механизмы операционных систем, модели доступа к данным, физическая защита зданий

Домен #4. Communication and Network Security - топология и стандарты сетей, сетевая защита, защита каналов, угрозы и сетевые атаки, управление безопасностью коммуникаций

Домен #5. Identity and Access Management - контроль физического и логического доступа, системы доступа и их управление, биометрический доступ, атаки на системы доступа, системы обнаружения и предотвращения проникновений

Домен #6. Security Assessment and Testing - методы проведения анализа безопасности, тестирование на проникновение, уязвимостей, бэкапов данных, восстановление бизнеса в случае непредвиденных обстоятельств, организация отчётности

Домен #7. Security Operations - расследование инцидентов по безопасности, управление физической защитой, системы управления инцидентами, управление изменениями, стратегии восстановления бизнеса в случае происшествий

Домен #8. Software Development Security - практики безопасности, внедренные в процесс разработки, управление изменениями и конфигурацией, защита репозиториев

Как видно, сама сертификация покрывает ОЧЕНЬ большую область безопасности и во многом связана с управлением, калькуляцией, процессами и стандартами безопасности.

Процесс сдачи

Теперь немного о шагах самой сдачи:

• Найти существующего CISSP, который подтвердит опыт и квалификацию

Перед сдачей на сертификат, необходим референс от существующего сертифицированного специалиста CISSP, который готов поручиться за ваш опыт. У меня им выступил Иван. Если проблематично такого найти, можно запросить его у ISC2.

• Купить онлайн экзамен в Pearson VUE

Стоимость 699 USD. В Минске данный экзамен сдать не получится. Ближайшие аккредитованные центры для сдачи CISSP в Москве, Вильнюсе, Киеве. Выбор пал на Москву..

• Подготовка к экзамену

Основным источником выступила книга CISSP® All-in-One Exam Guide, Seventh Edition. Не стоит обольщаться, что, прочитав её, можно сдать экзамен:

• это 1300 страниц забористого текста с кучей аббревиатур
• многие моменты приходилось искать дополнительно на просторах Интернета
• на экзамене помню вопрос, который был упомянут одним коротким предложением в книге

Чем хорош этот источник:

• хорошо структурирована информация и хорошая подача
• действительно ориентирован на экзамен
• в конце каждого домена есть список вопросов для проверки
• до сих пор служит настольной книгой, когда вопросы касаются безопасности

Пару рекомендаций:

• читайте всё изначально в английском варианте
• не пытайтесь найти вопросы, которые будут на экзамене и заучить их - вопросы постоянно тусуют; в конце сдачи список вопросов никто никому не предоставляет
• не забудьте выучить Code of Ethics, часть вопросов будет по нему

• Сдача экзамена

В Москву прибыл за день до сдачи. Гостиница Варшава находится в том же здании, где и экзамен проходит. С приезда до глубокой ночи гонял ещё список вопросов. После - два-три часа бредового сна. Не знаю, советовать выспаться или нет - это сугубо личный момент. Чувствовал на утро себя нормально.

В центре сдачи всё пафосно-серьёзно - снимают отпечатки пальцев, обыскивают карманы, снимают на видео. От берушей лучше не отказываться, рядом будут другие ребята сдавать свои экзамены. На экзамен выделяется 6 часов, 250 вопросов. То есть меньше 2 минут на вопрос. Поэтому без ответов вопросы лучше не оставлять, возможно, вы не успеете к ним вернуться. Полагайтесь на свой опыт и интуицию. Можно помечать себе вопросы, в которых не до конца уверены.

Специфика экзамена: в предложенном списке ответов все ответы могут быть правильными, но нужно выбрать самый подходящий. Поэтому метод “от обратного” не всегда будет работать. Самым главным активом всегда является человеческая жизнь. Поэтому, как только видите её в ответах, выбирайте её.

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

Ответ дают сразу - сдал или нет. Ответить нужно правильно минимум на 75% вопросов. Если сдали, то не скажут процент правильно отвеченных вопросов.

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

• Сертификация CISSP

Сдать успешно экзамен ещё только середина пути. Дальше нужно подтвердить свой опыт - минимум пять лет в минимум двух доменах. Причем подтверждать нужно документально: необходимо предоставить копии договоров или трудовой книжки, в которых указана должность.

Последние 7 лет работаю в должности Chief Technical Officer. В отдельном документе расписал детально все 8 доменов, отсортировав их в порядке своей крутости в каждом. Документ добавил вместе с остальными сканами к форме заявления. На форме коротко весь опыт расписал.

Первое подтверждение опыта должен сделать CISSP из пункта #1. Далее комиссия (ISC)² должна ещё раз проверить предоставленную информацию, и сделать заключение - достоин ты носить тайтл CISSP или нет, занимает это до 6 недель. Не забудьте обновить свой LinkedIn, заметил, что на профайл заходили неизвестные люди.

12 декабря 2017 успешно сдал экзамен, и только 13 февраля 2018 комиссия подтвердила сертификацию.

• Поддержка сертификата CISSP в активном состоянии

И снова пройти сертификацию ещё мало: её нужно поддерживать в активном статусе. Каждый год нужно сабмитить определённое количество Continuing Education (CPE) кредитов, и поддержка будет стоить около 85 USD в год.

Заключение

1. “Не так страшен чёрт, как его описывают”. Главное - это желание.
2. Крутая сертификация требует очень хорошей подготовки, проскочить не получится
3. Нельзя ставить точку в экспертизе по безопасности (как и в любой другой), это есть постоянный рост

Автор: Алла Ломака

24-26 ноября в Минске проходила юбилейная международная конференция по вопросам качества программного обеспечения. На этот раз решили засветиться на ней бравые QA engineers нашей банды. Имея уже опыт посещения данной конференции, но несколькими годами ранее, в предвкушении новенького и полезненького, мы отправились на сию конференцию в гостиницу Ренессанс.

День 1

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

Итак, выбираем первого докладчика. Им оказался Gerrard Paul из UK c докладом "A new Model for Testing".  Доклад нам очень понравился и оказался по душе. Краткое содержание заключалось в том, что тестировщики должны пользоваться мозгами. Донес до всех идею «shift-left»: как ни крути, а тестировщик должен быть вовлечен в разработку ПО на самых ранних стадиях. А также глубоко тронули фразы «Agile is no longer "innovative"» или вот «Agile doesn’t work but being Agile might».  Totally agree!

Следующий доклад, который мы хотели послушать, но не выдержали, был от Сергея Атрощенкова из города Питера (EPAM) на тему «The emotional intellect in testing». Забыла добавить выше, что первый день конференции был ознаменован как English Day, вследствие чего все доклады вещались на английской «мове». Но до чего же невозможно слушать доклады на инглише от русско-говорящих людей. Бывают, конечно, исключения, но конкретно в этом случае мы просто удалились из зала. Всё, что нам запомнилось - это «обнимашки спасут мир». Утрирую, но посыл нами был услышан примерно так :)

Следующий доклад, к счастью, оказался таким же интересным и занимательным, как и первый. Тема звучала «Inspection used in various ways» by Niels Malotaux (Germany). В данном докладе основная мысль заключалась в раннем ревью дизайна, который приведёт к «better Quality On Time: delivering better results, spending less time».

После чего мы отправились узнавать «Why we should care about leftovers» by Olivier Denoo (Belgium).  Доклад был не только на тему тестирования ПО, но и также про тестирование software в повседневной жизни, так как вокруг нас все больше и больше digital software. Не стоит полностью полагаться и доверять искусственному интеллекту. А также больше внимания к UX и Security.

И напоследок прослушали докладчика из той же Бельгии Pilaeten Michael на тему «What to do with the problems you cannot solve?» И первый слайд, на котором мы увидели  “F*ck Quality” , сделал наш день :) .

День 2

В этот день участников конференции прибавилось. А также на второй день привезли робота Гуди развлекать гостей на конференции. Ну что сказать, он оказался очаровашкой, и согласился сфотографироваться с нами, и даже не один раз.

И в этот день мы также нацелились на докладчиков, вещающих на английской «мове».  Ими же снова оказались докладчики первого дня. Список посещенных докладчиков и их докладов:

Paul Gerrard "Advancing testing using axioms"

Olivier Denoo "Psychology and testing"

Niels Malotaux "Examples how to move towards Zero Defects"

Michael Pilaeten "How to reduce your test cases …. Magically!"

Barta Vojtech "From Scrum to Kanban – what does it means for QAs?"

Можно было бы кратко рассказать, но как-нибудь в другой раз :)

День 3

Первая ассоциация с этим днем - новомодное слово от российских докладчиков «фичА». Причем понять, почему ударение пришлось на последний слог (в оригинале «feature» с ударением на первый слог), нам так и не удалось. Видно риторический вопрос.

Третий день оказался менее оживленным. Полагаем, что наложила свой отпечаток вечерняя программа в Cotton club, которую, увы мы, девочки, пропустили.

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

Прослушали мы два доклада посвященные автоматизации.

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

А второй доклад был полон высказываний «фе» в адрес мануальных тестировщиков. Ну вот хотят «выжить» нас автоматизаторы. А также категоричное заявление, что сеньор разработчик будет не сеньором, если он не пишет юнит тесты. Так что господа разработчики:

Запомнился нам доклад Павла Матолыгина «Git Hooks на страже качества кода». Очень полезно и крайне интересно было сходить на сий доклад. Респект их команде, которая наладила процесс в этом ключе. Мы подумаем, как нам расширить ресурсы и внедрить данную практику.

Также мы поприсутствовали на прямой трансляции Radio QA.

Где не менее интересно было послушать «истории» от основателя портала tut.by Юрия Анатольевича Зиссера. Он ответил на самые разные вопросы. В том числе он смело заявил, что тестировщики, по его мнению, и не нужны вовсе. Что разработчик, далее утрирую, осознавая свою значимость, и только свою ответственность, будет максимально качественно писать код и сам досконально все проверит.

Однако, в штате разработчиков у Юрия Зиссера тестировщики всё-таки присутствуют, ибо справедливости ради нужно сказать, что думать можно одно, а на деле без нас, проверяющих-контролирующих, ну ни-ку-да! Спорные высказывания повлекли за собой бурное обсуждение в чате Radio QA.

Не прошли мы и мимо доклада про анализ инструментов автоматизации мобильного тестирования от Дмитрия Химиона. По результатам анализа было выяснено, что ни лицензионные инструменты, ни инструменты из Open Source не идеальны и требуют еще много доработок. Нет смысла платить за лицензионные инструменты, так как не хуже с задачей автоматизации справляются инструменты из Open Source. Main-stream & Trend инструменты ниже:

• DeviceAnywhere Studio
• SeeTest
• Appium 2
• XCTest
• Calabash
• Espresso 2+

Ссылки на упомянутые выше доклады вставим в нашу статью по мере их появления в сети.

От себя добавим, что походы на конференции - это не только узнать что-то новенькое, но и «пожрать» что-то новенькое.