Роль Информационной Безопасности в управлении проектами или почему скрипач нужен

1. Роль информационной безопасности в управлении проектами или Почему скрипач нужен Евменков Алексей isqa.ru

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

3. Представление • СпециалистпоИБ,попроцессам икачествувИТобласти • Внедряюиподготавливаю к сертификации-ИСО27001и9001 • Разрабатываю &внедряю процессыразработкиПО, ИБ • Профессиональныйаудиторпо ИБипроцессам

4. ПОЧЕМУ ЭТО ВАЖНО?

5. Почему тема ИБ важна для управления проектами • Разрабатываемыесистемыстановятсяболеесложными • Вероятностьошибок,связанныхсИБвозрастает ОшибкавмодулестребованиямиИБ(например,модуль авторизации)–приводиткуязвимостивсейсистемы • Возрастаетценностьданных,соответственноинтерессо сторонызлоумышленников • ПрименениеИБнапроектахиворганизациивцелом- движениеорганизациикбольшейзрелости • Неочевидныесвязимеждувещами,напримерпрограммаBASи будущийбизнессЕвропой

6. Почему тема ИБ важна для управления проектами • Аналогиясмашиной,самое главное-доехатькуданужно, вовремя,инедорого • Какивпроекте,ценакачествоисрок • Нониктонеподумаетнепристегнутьсяилиотключить подушкибезопасности • Впроектномуправлении,ИБ-этоцентррастрат,какиремни безопасностивмашине. • Новозможноэтосохранитвашукарьеру

7. ОПРЕДЕЛЕНИЯ

8. Что такое ИБ ИнформационнаяБезопасность(ИБ) - свойствоинформации сохранятьконфиденциальность,целостностьидоступность. [Источник:ИСО27001] Примерсбазойданных • Конфиденцильность–конфиденциальностьданных,неразглашениениприкаких условиях(госучреждениекпримеру) • Целостность–непротиворечивыеданныевбазе,защитаотсбоев • Доступность-доступтолькоутех,комунужно,внужноевремя(еслибазадоступнатолько поночам–недело) Иногдадобавляются: • Неотказуемость, • Подотчетность • Аутентичность • Достоверность

9. СистемаМенеджментаИБ (СМИБ)–наборорганизационных, управленческихитехническихмерзащиты информации. Что такое СМИБ

10. СМИБ–чтоподкапотом? Что такое СМИБ Напрямую касается управления проектами

11. Двигатель СМИБ - управление рисками Угроза: нарушение лицензионности, использование чужого кода Уязвимость: Из-за отсутствия необходимых знаний у членов команды Актив: программные компоненты (deliverables) Защитная мера: проведение тренингов, постоянная коммуникация, процедурная поддержка

12. Ценность анализа рисков • За год от падения кокосов погибает в десятки раз больше людей, чем от акул – Часто мы боимся не то, что нужно • Мужчины поражаемы молнией в 4 раза более часто чем женщины – В жизни бывают странные закономерности • Шанс выйграть в лотерею обычно ~1 из 14млн. Шанс заболеть птичьим гриппом 1 из 100млн. – Наши ожидания и страхи зачастую иррациональны, пока не проанализируешь их Анализ рисков дает основания для объективных решений

13. ОРГАНИЗАЦИОННАЯ ИБ

14. Мир ИБ 2011-09-07 Technologies war Government challenges Business requirements

15. Война технологий

16. Организационные проблемы

17. Требования бизнеса

18. Организационная ИБ • Informationsecuritypolicies • ПомогаетвыстроитькультуруИБворганизации • Organizationofinformationsecurity • Тренингидляпроектнойкоманды,обработкапроектных инцидентовИБ,помощьсИБвопросами • !Правилаудаленнойработы • !Правилаработысмобильнымиустройствами • Humanresourcessecurity • Надежныйперсоналнапроекте • Решаетбазовыевопросысперсоналом

19. Правилаудаленнойработы

20. Организационная ИБ • Assetmanagement • Предоставляеткатегоризацию активов(включаяпроектные) • Классификацияинформации • Правилаработысфизическимиактивами,уничтожение, выносзапределыофиса • Accesscontrol • Управлениеправамипользователейнапроектах • Новыйчленкоманды,увольнение/переводсотрудника, закрытиепроекта • Правила“leastprivilege”и“needtoknow”

21. Классификацияинформации

22. Управлениедоступом

23. Организационная ИБ • Physicalandenvironmentalsecurity • Регламентируетповедениесотрудников • Чистыйстолиэкран • Производитвпечатлениеназаказчиков:) • Operationssecurity • Управлениеизменениями • Управлениемощностью(capacity) • Обеспечениеантивируснойподдержки • Обеспечениерезервногокопирования • Логгированиеимониторингсобытий(всети,всистемах)

24. Организационная ИБ • Communicationssecurity • Базоваябезопасностьсети • Безопасностьпроектнойсреды(железо+ПО) • SLAотИТотдела • Правилараспространенияинформации–всоц.сетях,в интернете,впочте,насобеседованиях:) • Confidentialityornondisclosureagreements

25. Организационная ИБ • Systemacquisition, development andmaintenance • Правилабезопаснойразработки • Правилаsecurityengineering(соответствиеcoding standardsидр.) • Безопасныйoutsourcing • БезопасныеизменениявПО,управлениерискамии многоедругое.

26. Организационная ИБ • Supplierrelationships • Правилакоммуникации,соглашения • Informationsecurityincidentmanagement • Предотвращениеиобработкаинцидентовнапроекте • Informationsecurityaspectsofbusinesscontinuity management • Надежноеоснованиедляведенияпроекта(наслучай непредвиденныхобстоятельств)

27. Организационная ИБ • Compliance • Интеллектуальнаясобственность • Персональныеданные • Криптографическиеконтролы

28. ИБ В УПРАВЛЕНИИ ПРОЕКТАМИ

29. Применимость ИБ на проектах ПреждечемприменятьтребованияИБ, оцениреальность • Типпроекта • Fixedprice/time-material • Productdevelopment? • Стартап? • Размерпроекта • 2хнедельныйPOC?Или1йэтапна6мес? • Типзаказчика • Небольшаяфирмасзаказомсайта • Международнаякорпорация • Типдеятельности?Gambling,finance?

30. Надежда РП В95% случаев,управление проектамирассчитанона добрыхлюдей • поспособам коммуникаций • похранениюданных- заказчикаисвоей организации • по способамудаленной работы

31. Где РП может научиться ИБ ? • ВPMBOK5th –словоsecurity встречается9раз- на619стр. • Всевхождения–либопроsecurityrequirements либослучайные Учитьсянужносамостоятельно, требоватьподдержкууруководства:)

32. 2 подхода к ИБ в управлении проектами • Включитьправила,требованияИБв производственныйпроцесс либо • РеагироватьнаинцидентыИБ ЛучшевключитьтребованияИБв процесс управленияпроектами!

33. КакиетребованияИБв процесс управленияпроектами?

34. Следовать внутренним правилам ИБ организации • Физическаябезопасность,мобильныеустройства,удаленная работаит.д.–всеэтодолжнобытьчастьюкультурынапроекте • ТребуйтеобученияпоИБотМенеджерапоИБ • КейссPOC- переиспользовалимодульодногозаказчика-конкурента, невырезалилоготипыдаже • Кейс снелицензионнымкодомидр.

35. Включить цели ИБ (security objectives) • ЦелиИБ(securityobjectives)должны бытьвключенывобщиецелипроекта (projectobjectives) • ЦелиИБоснованынаCIA (Confidentiality,Integrity,Availability) • Сохранитьконфиденциальностьданных заказчика(testdata,projectdataetc.) • Целипособлюдениюстандартов шифрованияикриптографии • Сохранитьцелостностьрепозитариевс кодом

36. Произвести анализ рисков ИБ • ПроизвестианализрисковИБнараннейстадиипроекта (совместнособщиманализомрисков) • Часто,рискинапрямуюследуютизцелейИБ • рискисвязанныеснарушениемцелостностирепозиториевкода, • доступностьсерверов,конфиденциальностьсредств коммуникации

37. Произвести анализ рисков ИБ Анализрисков–долженбыть основаннабизнес-реальности Реальностьзависит–отразмера проекта,оттипапроекта,от вашегоопытаит.д.

38. Интегрировать ИБ во все фазы процесса разработки ПО • Встраиваниедополнительных контрольныхточекв жизненныйциклразработкиПО • Накаждойфазежизненногоцикла,нарядус обычнымикритериями(качествокода,соответствие спецификацииит.п.),нужнопроверятьтребования ИБ

39. Пример интеграции ИБ в V-model Требования к ПО Технические решения Код Модульное тестирование Системное тестированиеТЕСТИРУЕТСЯ ТЕСТИРУЕТСЯ Ревью требований с точки зрения безопасности Ревью архитектуры с точки зрения безопасности Ручной аудит кода Практики Code Review Статический аудит кода Анализ результатов аудита Динамическое тестирование и тестирование на проникновение НАСТРОЙКА ПРАВИЛ НАСТРОЙКА ПРАВИЛ

40. Некоторые аспекты ИБ в процессе разработки ПО • Ревьютребований • Раздел–нефункциональныетребования. Связаносанализомрисков. • Ревьюархитектуры • Идентификацияииспользованиеsecuritydesignpatterns • Анализиспользуемыхплатформ,фреймворковипаттерновс т.зр.ИБ • КоммуникациясчленамикомандыпотемеИБ • Ручнойаудиткода(codereview) • Стандартныепрактикиcodereview • Использованиерасширенныхчеклистов–свключенными требованиямиИБ Secure the weakest link Keep it simple Fail securely Follow the principle of least privilege

41. Некоторые аспекты ИБ в процессе разработки ПО • Статическийанализкода • Использование специальныхинструментов дляанализакодана уязвимостиИБ • Тестынапроникновение (penetrationtests) • Использование специального инструментарияиметодик

42. Примеры уязвимостей • CodeInjection(SQLинъекция) невалидированныйпользовательскийввод,используемыйдля интерпретациикоманд,можетбытьиспользованзлоумышленниками длявыполнениянедокументированнойфункциональности • SensitiveDataExposure(Нарушениеконфиденциальности) конфиденциальныеданныепубликуютсявнезащищенныйканал.Тем самым,злоумышленникможетдостаточнопростополучитьдоступк даннымвобходсложныхмеханизмовзащитысистемы • UnreleasedResource:Streams вызываютнепредсказуемоеповедениесистемы.Незакрытыепотоки записиичтенияресурсовспособнывызыватьутечкупамятии/или утечкуинформацииосистемечерезнепредвиденныеошибкии исключениявработеприложения,вплотьдополнойегоостановки

43. Пример интеграции ИБ в waterfall Security and Privacy Risk Analysis Manual Code Review Threat Modeling Static Analysis Dynamic Analysis Security Architecture & Design Review Final Security Review Fuzz Testing Secure Design Guidelines Security and Privacy Requirements REQUIREMENTS IMPLEMENTA TION Regulations, Policies and Standards Secure Coding Guidelines Quality Gates /Bug Bars Attack Surface Analysis RELEASE Security Deployment Review Automated Tools VERIFICATION DESIGN AND ARCHITECTURE Attack Surface Review

44. Пример интеграции ИБ в waterfall Обучение основам безопасно сти Задание требований безопасности Создание контрольных условий качества и панелей ошибок Оценка рисков безопасности и конфиденци- альности Задание требования проектирова ния Анализ возможных направлений атак Моделирован ие рисков Применение утвержденн ых инструмен тов Отказ от небезопасн ых функций Статический анализ Динамическ ий анализ Нечеткое тестирова ние Проверка возможных направле ний для атак Планирова ние реагиро вания на инциденты Окончательн ая проверка безопас ности Архивация выпуска Выполне ние плана реагирова ния на инциденты Обучение Требования Дизайн Реализация Проверка Выпуск Реакция

45. Пример интеграции ИБ в Agile

46. Комплексный подход по обеспечению безопасной разработки ПО • SAMM - Software Assurance Maturity Model http://www.opensamm.org • Может быть адаптирована под любую компанию • Позволяет оценивать усилия на проект, описывает кто вовлечен, какие метрики необходимы и др.

47. Другие важные моменты для РП Взаимодействие сзаказчиком • ВовремяпропиаритьсвойИБ уровень,предложитьработатьпо «нашим»методам • ОсобоевниманиенаИБ требованиязаказчика(случайс проверкойкоданаподлинность-> вылилосьв+неск.месяцев переработок) • Оборудованиезаказчика–учет, использование,возврат(!)

48. Другие важные моменты для РП • Взаимодействие споставщиками/вендорами • Четкий,содержащийтребованияИБдоговор • Вчастности,соблюдениевендоромвнутреннихправил компаниипоИБ • Найти спонсора для ИБ • Обычно,этозаказчик • Номожетбытьироднаяфирма,если стратегическизаинтересованавзаказчикеи проекте

49. Другие важные моменты для РП • Ревьюправдоступа напроекте • Newcomer • Сотрудникуволился • Проектзавершился(закрытиетекущихправ) • Действуй на основании классификации информации • Public/Internal/Secret

50. ЗАКЛЮЧЕНИЕ И ВЫВОДЫ

51. Что должен уметь достичь каждый ПМ? • Завершитьпроектвсрок, бюджет,стребуемым качеством • Заказчикдолженбыть счастлив • Остальныесчастливы (членыкоманды, руководство,семья) • Вовсемэтомне упоминается,чтоПМтоже долженостатьсясчастлив • Получитьопыт, самореализоваться, научитьсяновому, подготовитьсякследующим вызовам • Статьболее профессиональным • ВтомчислевобластиИБ

52. Роль РП в процессе внедрения ИБ • РольРПвобластивнедрениятребованийИБна проекте-ключевая. • Реальнаявластьнадлюдьми–уРП • ЕслиРПпонимаетважностьИБ,тоиостальныепоймут • Инаборот

53. Заключение • Неигнорируйтеправила ИБ • Применяйтетребования ИБ,исходяизреальности • “Securityisaprocess,not aproduct!”[Bruce Schneier]

54. Ссылки • InformationSecurityandtheSDLCbyRonClement • SAMM - Software Assurance Maturity Model http://www.opensamm.org

55. Спасибо за внимание Алексей Евменков evmenkov@gmail.com isqa.ru https://twitter.com/evmenkov

Роль Информационной Безопасности в управлении проектами или почему скрипач нужен

You are reading a preview.

Роль Информационной Безопасности в управлении проектами или почему скрипач нужен

More Related Content

Featured

Related Books

Related Audiobooks