Use cases или подходы к проведению пилотных проектов

Use cases или подходы к проведению пилотных проектов
Посетив мероприятие IBM пришел к выводу, что подходы, которые мы применяем в рамках проведения пилотных проектов по линии решений класса Security Information and Event Management (SIEM) совпадают с виденьем западных коллег, при этом многие новомодные понятия (например, «Use cases», «PoC») являются аналогами хорошо известных нам вещей.

Решил поделиться этой информацией с целью минимизации обманутых ожиданий, которые, к сожалению, очень часто возникают в рамках пилотирования из-за отсутствия полной картины (недосказанности как со стороны заказчика, так и исполнителя) и маркетинговой информации.
 
Начать хотелось бы с терминологии:
- PoC (Proof of Concept) или Trial – это пилотный проект, т.е. активность, которая длится порядка 4 недель и нацелена на демонстрацию заказчику функционала интересующего его решения и/или решение поставленных задач (очень важный момент – союзы «и» или «или», если поставленных задач нет, то ситуация должна насторожить и исполнителя, и заказчика);
- Use cases – сценарии, которые будут моделироваться, по сути это поставленные задачи.

Если сценариев нет, а очень хочется, чтобы они были, то оказалось, что здесь наши мнения с западными коллегами совпали в части одного из ориентиров – документ «Top 10 SIEM Implementer's Checklist» от AccelOps, который включает в себя:
- SIEM Best Practice #1 – Malware control;
- SIEM Best Practice #2 – Boundary defenses;
- SIEM Best Practice #3 – Access controls;  

- SIEM Best Practice #4 – Acceptable Use Monitoring;
- SIEM Best Practice #5Application defenses;
- SIEM Best Practice #6 – Compliance and audit data requirements;
- SIEM Best Practice #7 – Monitoring and reporting requirements;  
- SIEM Best Practice #8 – Deployment and infrastructure activation;  
- SIEM Best Practice #9 – Network and host defenses;
- SIEM Best Practice #10 – Network and system resource integrity.  
 
Но больше всего порадовало, что для вендора первичным вопросом оказались имеющиеся в ИТ-инфраструктуре организации источники событий и их возможности. Это то, на чём я акцентирую внимание последние несколько лет в наших SIEM-проектах, на профильных мероприятиях (например, Уральский форум) и в своих публикациях.

Дело в том, что по какай-то причине (пути маркетинга неисповедимы) при инициации активностей по линии SIEM, мы бросаемся в область корреляционных правил (есть/нет, писать свои/брать чужие), списков поддерживаемых источников событий (100+, 500+, кто больше?) и других features, забывая о том, что основой для работы SIEM-решения будут имеющиеся у вас в ИТ-инфраструктуре источники событий.

Используя в качестве источников событий устройства уровня Home или SMB, которые в ряде случаев даже не поддерживают возможность ведения или выгрузки log-файлов, не стоит ожидать вообще каких-либо результатов от SIEM-системы даже класса Enterprise.

Эта идея закреплена, в т.ч. в прекрасном документе NIST SP 800-92 «Guide to Computer Security Log Management», который определил первым компонентом в составе log management infrastructure (в нашем случае как развитие термина – event management infrastructure) именно источник, генерирующий событие.

Нет источника, значит нет события, т.е. нечего обрабатывать в SIEM и, как следствие, нечего отрабатывать в рамках use cases.

Такая вот незамысловатая логика.


Удачи при пилотировании!
Alt text

Подписывайтесь на каналы "SecurityLab" в TelegramTelegram и TwitterTwitter, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Александр Кузнецов

Заметки про управление в области информационной безопасности и не только