Download to read offline
![Что такое ИБ
ИнформационнаяБезопасность(ИБ) - свойствоинформации
сохранятьконфиденциальность,целостностьидоступность.
[Источник:ИСО27001]
Примерсбазойданных
• Конфиденцильность–конфиденциальностьданных,неразглашениениприкаких
условиях(госучреждениекпримеру)
• Целостность–непротиворечивыеданныевбазе,защитаотсбоев
• Доступность-доступтолькоутех,комунужно,внужноевремя(еслибазадоступнатолько
поночам–недело)
Иногдадобавляются:
• Неотказуемость,
• Подотчетность
• Аутентичность
• Достоверность](https://image.slidesharecdn.com/random-151110164319-lva1-app6892/85/slide-8-320.jpg)
![Заключение
• Неигнорируйтеправила
ИБ
• Применяйтетребования
ИБ,исходяизреальности
• “Securityisaprocess,not
aproduct!”[Bruce
Schneier]](https://image.slidesharecdn.com/random-151110164319-lva1-app6892/85/slide-54-320.jpg)
Uploaded bySQALab
Роль информационной безопасности в управлении проектами или Почему скрипач нужен
Документ рассматривает роль информационной безопасности (ИБ) в управлении проектами, подчеркивая важность интеграции ИБ в процессы разработки программного обеспечения. Основное внимание уделяется необходимым мерам для защиты данных и предотвращению уязвимостей, а также формированию культуры безопасности в организации. Автор обсуждает методы и подходы к управлению рисками, включая анализ рисков и внедрение ИБ на всех этапах проекта.
More Related Content
Similar to Роль информационной безопасности в управлении проектами или Почему скрипач нужен
Роль информационной безопасности в управлении проектами или Почему скрипач нужен
- 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 Governmentchallenges 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 •Интеллектуальнаясобственность • Персональныеданные • Криптографическиеконтролы
- 29. ИБ В УПРАВЛЕНИИПРОЕКТАМИ
- 30. Применимость ИБ на проектах ПреждечемприменятьтребованияИБ, оцениреальность •Типпроекта • Fixedprice/time-material • Productdevelopment? • Стартап? • Размерпроекта • 2хнедельныйPOC?Или1йэтапна6мес? • Типзаказчика • Небольшаяфирмасзаказомсайта • Международнаякорпорация • Типдеятельности?Gambling,finance?
- 31. Надежда РП В95% случаев,управление проектамирассчитанона добрыхлюдей •поспособам коммуникаций • похранениюданных- заказчикаисвоей организации • по способамудаленной работы
- 32. Где РП можетнаучиться ИБ ? • ВPMBOK5th –словоsecurity встречается9раз- на619стр. • Всевхождения–либопроsecurityrequirements либослучайные Учитьсянужносамостоятельно, требоватьподдержкуу руководства:)
- 33. 2 подхода кИБ в управлении проектами • Включитьправила,требованияИБв производственныйпроцесс либо • РеагироватьнаинцидентыИБ ЛучшевключитьтребованияИБв процесс управленияпроектами!
- 34.
- 35. Следовать внутренним правилам ИБорганизации • Физическаябезопасность,мобильныеустройства,удаленная работаит.д.–всеэтодолжнобытьчастьюкультурынапроекте • ТребуйтеобученияпоИБотМенеджерапоИБ • КейссPOC- переиспользовалимодульодногозаказчика-конкурента, невырезалилоготипыдаже • Кейс снелицензионнымкодомидр.
- 36. Включить цели ИБ(security objectives) • ЦелиИБ(securityobjectives)должны бытьвключенывобщиецелипроекта (projectobjectives) • ЦелиИБоснованынаCIA (Confidentiality,Integrity,Availability) • Сохранитьконфиденциальностьданных заказчика(testdata,projectdataetc.) • Целипособлюдениюстандартов шифрованияикриптографии • Сохранитьцелостностьрепозитариевс кодом
- 37. Произвести анализ рисковИБ • ПроизвестианализрисковИБнараннейстадиипроекта (совместнособщиманализомрисков) • Часто,рискинапрямуюследуютизцелейИБ • рискисвязанныеснарушениемцелостностирепозиториевкода, • доступностьсерверов,конфиденциальностьсредств коммуникации
- 38. Произвести анализ рисковИБ Анализрисков–долженбыть основаннабизнес-реальности Реальностьзависит–отразмера проекта,оттипапроекта,от вашегоопытаит.д.
- 39. Интегрировать ИБ вовсе фазы процесса разработки ПО • Встраиваниедополнительных контрольных точекв жизненныйциклразработкиПО • Накаждойфазежизненногоцикла,нарядус обычнымикритериями(качествокода,соответствие спецификацииит.п.),нужнопроверятьтребования ИБ
- 40. Пример интеграции ИБв V-model Требования к ПО Технические решения Код Модульное тестирование Системное тестированиеТЕСТИРУЕТСЯ ТЕСТИРУЕТСЯ Ревью требований с точки зрения безопасности Ревью архитектуры с точки зрения безопасности Ручной аудит кода Практики Code Review Статический аудит кода Анализ результатов аудита Динамическое тестирование и тестирование на проникновение НАСТРОЙКА ПРАВИЛ НАСТРОЙКА ПРАВИЛ
- 41. Некоторые аспекты ИБв процессе разработки ПО • Ревьютребований • Раздел–нефункциональныетребования. Связаносанализомрисков. • Ревьюархитектуры • Идентификацияииспользованиеsecuritydesignpatterns • Анализиспользуемыхплатформ,фреймворковипаттерновс т.зр.ИБ • КоммуникациясчленамикомандыпотемеИБ • Ручнойаудиткода(codereview) • Стандартныепрактикиcodereview • Использованиерасширенныхчеклистов–свключенными требованиямиИБ Secure the weakest link Keep it simple Fail securely Follow the principle of least privilege
- 42. Некоторые аспекты ИБв процессе разработки ПО • Статическийанализкода • Использование специальныхинструментов дляанализакодана уязвимостиИБ • Тестынапроникновение (penetrationtests) • Использование специального инструментарияиметодик
- 43. Примеры уязвимостей • CodeInjection(SQLинъекция) невалидированныйпользовательскийввод,используемыйдля интерпретациикоманд,можетбытьиспользованзлоумышленниками длявыполнениянедокументированнойфункциональности •SensitiveDataExposure(Нарушениеконфиденциальности) конфиденциальныеданныепубликуютсявнезащищенныйканал.Тем самым,злоумышленникможетдостаточнопростополучитьдоступк даннымвобходсложныхмеханизмовзащитысистемы • UnreleasedResource:Streams вызываютнепредсказуемоеповедениесистемы.Незакрытыепотоки записиичтенияресурсовспособнывызыватьутечкупамятии/или утечкуинформацииосистемечерезнепредвиденныеошибкии исключениявработеприложения,вплотьдополнойегоостановки
- 44. Пример интеграции ИБв 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
- 45. Пример интеграции ИБв waterfall Обучение основам безопасно сти Задание требований безопасности Создание контрольных условий качества и панелей ошибок Оценка рисков безопасности и конфиденци- альности Задание требования проектирова ния Анализ возможных направлений атак Моделирован ие рисков Применение утвержденн ых инструмен тов Отказ от небезопасн ых функций Статический анализ Динамическ ий анализ Нечеткое тестирова ние Проверка возможных направле ний для атак Планирова ние реагиро вания на инциденты Окончательн ая проверка безопас ности Архивация выпуска Выполне ние плана реагирова ния на инциденты Обучение Требования Дизайн Реализация Проверка Выпуск Реакция
- 46. Пример интеграции ИБв Agile
- 47. Комплексный подход по обеспечениюбезопасной разработки ПО • SAMM - Software Assurance Maturity Model http://www.opensamm.org • Может быть адаптирована под любую компанию • Позволяет оценивать усилия на проект, описывает кто вовлечен, какие метрики необходимы и др.
- 48. Другие важные моментыдля РП Взаимодействие сзаказчиком • ВовремяпропиаритьсвойИБ уровень,предложитьработатьпо «нашим»методам • ОсобоевниманиенаИБ требованиязаказчика(случайс проверкойкоданаподлинность-> вылилосьв+неск.месяцев переработок) • Оборудованиезаказчика–учет, использование,возврат(!)
- 49. Другие важные моментыдля РП • Взаимодействие споставщиками/вендорами • Четкий,содержащийтребованияИБдоговор • Вчастности,соблюдениевендоромвнутреннихправил компаниипоИБ • Найти спонсора для ИБ • Обычно,этозаказчик • Номожетбытьироднаяфирма,если стратегическизаинтересованавзаказчикеи проекте
- 50. Другие важные моментыдля РП • Ревьюправдоступа напроекте • Newcomer • Сотрудникуволился • Проектзавершился(закрытиетекущихправ) • Действуй на основании классификации информации • Public/Internal/Secret
- 51.
- 52. Что должен уметьдостичь каждый ПМ? • Завершитьпроектвсрок, бюджет,стребуемым качеством • Заказчикдолженбыть счастлив • Остальныесчастливы (членыкоманды, руководство,семья) • Вовсемэтомне упоминается,чтоПМтоже долженостатьсясчастлив • Получитьопыт, самореализоваться, научитьсяновому, подготовитьсякследующим вызовам • Статьболее профессиональным • ВтомчислевобластиИБ
- 53. Роль РП впроцессе внедрения ИБ • РольРПвобластивнедрениятребованийИБна проекте-ключевая. • Реальнаявластьнадлюдьми–уРП • ЕслиРПпонимаетважностьИБ,тоиостальныепоймут • Инаборот
- 54. Заключение • Неигнорируйтеправила ИБ • Применяйтетребования ИБ,исходяизреальности •“Securityisaprocess,not aproduct!”[Bruce Schneier]
- 55. Ссылки • InformationSecurityandtheSDLCbyRonClement • SAMM- Software Assurance Maturity Model http://www.opensamm.org
- 56. Спасибо за внимание АлексейЕвменков evmenkov@gmail.com isqa.ru https://twitter.com/evmenkov
Editor's Notes
- #6 Например,
- #16 Кто то приносит и втыкает свой лаптоп, или другой девайс в сетку – границы организации тяжело зафиксировать Похищают данные с сайтов Данные текут постоянным потоком – вопрос в том, ищет ли их кто-нибудь
- #17 ФЗ-152 Внутренние проблемы – разный язык – даже у разных юнитов
- #18 Пост изменения бизнес условий
- #40 Не нужно для стартапов оценивать специфические риски двойного бэкапирования и т.п.
- #47 https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet
- #56 Например,