AXIS Security Development Model Software

Въведение

Цели на ASDM
Моделът за развитие на сигурността на Axis (ASDM) е рамка, която дефинира процеса и инструментите, използвани от Axis за изграждане на софтуер с вградена сигурност през целия жизнен цикъл, от създаването до извеждането от експлоатация.

Основните цели, движещи усилията на ASDM, са

• Направете сигурността на софтуера интегрирана част от дейностите по разработка на софтуер на Axis.
• Намалете свързаните със сигурността бизнес рискове за клиенти на Axis.
• Meet increasing awareness of security considerations by customers and partners.
• Създайте потенциал за намаляване на разходите поради ранно откриване и разрешаване на проблеми
  Обхватът на ASDM е софтуерът на Axis, включен в продуктите и решенията на Axis. Групата за сигурност на софтуера (SSG) е собственик и поддържащ ASDM.

Речник

ASDM	Модел за развитие на сигурността на Axis
SSG	Група за сигурност на софтуера
фърмуер управление група	Управление на НИРД
Сателит	Разработчици, които имат естествен афинитет към софтуерната сигурност
Уязвимост дъска	Точка за контакт на Axis във връзка с уязвимости, открити от външни изследователи
Лента за грешки	Цел за сигурност за продукт или решение
DFD	Диаграма на потока от данни

ASDM приключиview

ASDM включва няколко дейности, разпределени в основните фази на развитие. Дейностите по сигурността се идентифицират колективно като ASDM.

The SSG is responsible for governing the ASDM and evolving the toolbox over time. There is an ASDM roadmap and a rollout plan for implementing new activities and increasing ASDM maturity across the development organization. Both the roadmap and rollout plan are owned by the SSG, but the responsibility for actual implementation in practice (i.e., performing activities related to development phases) is delegated to the R&D teams.

Група за сигурност на софтуера (SSG)

SSG е основният вътрешен контактен субект към организациите за развитие по въпроси, свързани със сигурността. Той включва ръководители по сигурността и други със специализирани познания по сигурността в области на разработка като изисквания, дизайн, внедряване, проверка,
както и междуфункционални DevOps процеси.
SSG отговаря за разработването и поддръжката на ASDM за сигурни практики за разработка и информираност за сигурността в организацията за разработка.

Сателити
Satellites са членове на организацията за разработка, които прекарват част от времето си в работа с аспекти на софтуерната сигурност. Причините за наличието на сателити са:

• Мащабирайте ASDM без изграждане на голям централен SSG
• Осигурете ASDM поддръжка близо до екипите за разработка
• Улесняване на споделянето на знания, например най-добри практики
  Сателитът ще подпомага прилагането на нови дейности и поддържането на ASDM в подмножество от екипите за разработка.

Разгръщане на активността на ASDM
Разгръщането на ASDM дейност към екип за разработка е катоtagред процес:

1. Екипът се въвежда в новата дейност чрез обучение, специфично за ролята.
2. SSG работи заедно с екипа за извършване на дейността, например оценка на риска или моделиране на заплахи, за избрани части от системата(ите), управлявани от екипа.
3. Допълнителни дейности, свързани с интегрирането на кутията с инструменти в ежедневната работа, ще бъдат предадени на екипа и сателита, когато са готови да работят самостоятелно без пряко участие на SSG. В тази фаза работата се управлява от мениджъра на екипа чрез статуса ASDM.
   Внедряването се повтаря, когато има налични нови версии на ASDM с модифицирани и/или добавени дейности. Времето, прекарано от SSG с екип, силно зависи от дейността и сложността на кода. Ключов фактор за успешното предаване на екипа е наличието на вграден сателит, който може да продължи по-нататъшната работа на ASDM с екипа. SSG управлява обучението и присвояването на сателита успоредно с внедряването на дейността.
   Фигурата по-долу обобщава методологията за внедряване.

   

Определението на SSG за „готово“ за предаване е:

• Извършено е специфично за ролята обучение
• Сателитът е назначен
• Екипът е готов да извърши дейността ASDM
• Установени са повтарящи се срещи за състоянието на ASDM
  SSG използва информация от екипите, за да състави доклади за състоянието към висшето ръководство.

Други дейности на SSG
Успоредно с дейностите по внедряване, SSG провежда по-широки обучителни дейности за осведоменост относно сигурността, насочени например към нови служители и висше ръководство. Освен това SSG поддържа топлинна карта на сигурността на решенията на Axis за целите на цялостната/архитектурната оценка на риска. Дейностите за проактивен анализ на сигурността за конкретни модули се извършват въз основа на топлинната карта.

Роли и отговорности
Както е показано в таблицата по-долу, има някои ключови субекти и роли, които са част от програмата ASDM. Таблицата по-долу обобщава ролите и отговорностите във връзка с ASDM.

Роля/Существо	Част от	Отговорност	Коментирайте
Експерт по сигурността	SSG	Управлявайте ASDM, развивайте инструментариума и стимулирайте внедряването на ASDM	100% възложени на SSG
Сателит	Развойна линия	Помогнете на SSG да внедри ASDM за първи път, тренирайте екипи, провеждайте обучения и гарантирайте, че екипът може да продължи да използва Кутията с инструменти като част от ежедневната работа, независимо от SSG. Отговорност между екипи (няколко екипа), необходима за ограничаване на общия брой сателити.	Заинтересовани и ангажирани разработчици, архитекти, мениджъри, тестери и подобни роли, които имат естествен афинитет към софтуерната сигурност. Сателитите отделят поне 20% от времето си за работа, свързана с ASDM.
Мениджъри	Развойна линия	Осигурете ресурси за внедряване на ASDM практики. Проследяване и отчитане на ASDM статус и покритие.	Екипите за разработка притежават внедряване на ASDM, със SSG като ресурс за поддръжка.
Група за управление на фърмуера (FW SG)	Управление на НИРД	Взема решение относно стратегията за сигурност и действа като основен SSG канал за докладване.	SSG докладва на FW SG редовно.

Управление на ASDM

Системата за управление се състои от следните части:

• Топлинна карта на системния риск за подпомагане на приоритизирането на ASDM дейностите
• План за внедряване и статус, за да се съсредоточите върху усилията за обучение
• Пътна карта за развитие на кутията с инструменти
• Статус за измерване на това колко добре дейностите на ASDM са интегрирани в организацията

По този начин системата ASDM се поддържа както от тактическа/оперативна гледна точка, така и от стратегическа/изпълнителна гледна точка.
Насоките на изпълнителния директор от дясната страна на фигурата се фокусират върху това как да се развие организацията за оптимална ефективност в съответствие с бизнес целите на Axis. Важен принос за това е докладването на състоянието на ASDM, извършено от SSG към групата за управление на фърмуера, техническия директор и управлението на продуктите.

Структура на състоянието на ASDM

Структурата на състоянието на ASDM има две гледни точки: една, ориентирана към екипа, имитираща структурата на нашия екип и отдел, и една, ориентирана към решения, фокусирана върху решенията, които предлагаме на пазара.
Фигурата по-долу илюстрира структурата на състоянието на ASDM.

Състояние на отбора
Състоянието на екипа съдържа самооценката на екипа за неговата ASDM зрялост, показатели, свързани с техните дейности по анализ на сигурността, както и обобщение на състоянието на сигурността на компонентите, за които отговарят.

Axis определя зрелостта на ASDM като версията на ASDM, която екипът използва в момента. Тъй като ASDM се развива, ние дефинирахме ASDM версии, където всяка версия на ASDM съдържа уникален набор от дейности. Напримерample, нашата първа версия на ASDM е фокусирана върху моделирането на заплахи.
Axis дефинира следните версии на ASDM:

ASDM версия	Нови дейности
ASDM 1.0	Оценка на риска и моделиране на заплахи
ASDM 2.0	Статичен код review
ASDM 2.1	Поверителност по дизайн
ASDM 2.2	Анализ на състава на софтуера
ASDM 2.3	Външен тест за проникване
ASDM 2.4	Сканиране на уязвимости и противопожарна тренировка
ASDM 2.5	Състояние на сигурността на продукта/решението

Даването на собственост на екипа върху това коя версия на ASDM използва означава, че прекият мениджър е този, който е отговорен за приемането на новите версии на ASDM. Така че вместо настройка, при която SSG прокарва централен план за внедряване на ASDM, сега той става базиран на изтегляне и се контролира от мениджърите.

Състояние на компонента

• Имаме широка дефиниция на компонент, тъй като трябва да покрием всички видове архитектурни единици, вариращи от Linux демони в платформата, през сървърен софтуер чак до облачни (микро) услуги.
• Всеки екип трябва да вземе собствено решение за ниво на абстракция, което работи за тях в тяхната среда и архитектура. Като основно правило екипите трябва да избягват измислянето на ново ниво на абстракция и да запазят всичко, което вече използват в ежедневната си работа.
• Идеята е всеки отбор да има ясно view на всички техни високорискови компоненти, което включва нови, както и наследени компоненти. Мотивацията за този повишен интерес към наследените компоненти е свързана с нашата способност да разглеждаме състоянието на сигурността на решенията. В случай на решение, ние искаме да имаме видимост в състоянието на сигурността на всички нови и стари части на решението.
• На практика това означава, че всеки екип трябва да прегледа инвентара си от компоненти и да направи оценка на риска.
• Първото нещо, което трябва да знаем е дали компонентът е преминал анализ на сигурността. Ако не е, наистина не знаем нищо за качеството на сигурността на компонента.

Ние наричаме това покритие на собствеността и сме дефинирали следните нива на покритие:

Покритие	Описание
Анализът не е направен	Компонентът все още не е анализиран
Анализът продължава	Компонентът се анализира
Направен анализ	Компонентът е анализиран

Метриките, които използваме за улавяне на качеството на сигурността на компонента, се основават на елементите за работа по сигурността в неизпълнените задачи, които са свързани с компонента. Това може да са контрамерки, които не са приложени, тестови случаи, които не са изпълнени, и грешки в сигурността, които не са адресирани.

Състояние на решението

Състоянието на решението обобщава състоянието на сигурността за набор от компоненти, които съставят решението.
Първата част от състоянието на решението е покритието на анализа на компонентите. Това помага на собствениците на решение да разберат дали състоянието на защита на решението е известно или не. В една перспектива помага да се идентифицират слепите петна. Останалата част от състоянието на решението съдържа показатели, които улавят качеството на сигурността на решението. Ние правим това, като разглеждаме работните елементи на сигурността, които са свързани с компонентите в решението. Важен аспект на състоянието на сигурността е лентата за грешки, дефинирана от собствениците на решението. Собствениците на решението трябва да дефинират подходящо ниво на защита за своето решение. Напримерample, това означава, че решението не трябва да има отворени критични или високосериозни работни елементи, когато бъде пуснато на пазара.

ASDM дейности

Оценка на риска
Основната цел с оценката на риска е да се филтрират кои дейности за развитие също ще изискват работа по сигурността в екипа.
Оценката на риска се извършва чрез преценка дали нов продукт или добавена/модифицирана функция в съществуващи продукти увеличава излагането на риск. Имайте предвид, че това включва също аспекти на поверителността на данните и изисквания за съответствие. ПрampПромените, които имат въздействие върху риска, са нови API, промени в изискванията за оторизация, нов междинен софтуер и т.н.

Поверителност на данните
Доверието е ключова област на фокус за Axis и като такава е важно да се следват най-добрите практики при работа с лични данни, събрани от нашите продукти, решения и услуги.
Обхватът на усилията на Axis, свързани с поверителността на данните, е дефиниран така, че да можем:

• Изпълнявайте законови задължения
• Изпълнете договорните задължения
• Помогнете на клиентите да изпълнят задълженията си

Ние разделяме дейността по поверителност на данните на две поддейности:

• Оценка на поверителността на данните
  • Извършено по време на оценката на риска
  • Идентифицира дали е необходим анализ на поверителността на данните
•  Анализ на поверителността на данните
  • Извършва се, когато е приложимо, по време на моделиране на заплахи
  • Идентифицира лични данни и заплахи за личните данни
  • Определя изискванията за поверителност

Моделиране на заплахи
Преди да започнем да идентифицираме заплахите, трябва да вземем решение за обхвата на модела на заплахата. Начин за артикулиране на обхвата е да опишем нападателите, които трябва да вземем предвид. Този подход също ще ни позволи да идентифицираме повърхностите за атака на високо ниво, които трябва да включим в анализа.

• Фокусът по време на обхвата на заплахата е върху намирането и категоризирането на нападателите, с които искаме да се справим, като използваме описание на високо ниво на системата. За предпочитане е описанието да се направи с помощта на диаграма на потока от данни (DFD), тъй като улеснява свързването на по-подробните описания на случаите на употреба, които се използват, когато се прави моделът на заплахата.
• Това не означава, че всички нападатели, които идентифицираме, трябва да бъдат взети под внимание, това просто означава, че сме изрични и последователни по отношение на нападателите, които ще адресираме в модела на заплахата. Така че по същество атакуващите, които решим да разгледаме, ще определят нивото на сигурност на системата, която оценяваме.
  Обърнете внимание, че нашето описание на нападателя не взема предвид способностите или мотивацията на нападателя. Избрахме този подход, за да опростим и рационализираме моделирането на заплахи, доколкото е възможно.

  

Моделирането на заплахи има три стъпки, които могат да бъдат повторени, както екипът сметне за добре:

1. Опишете системата с помощта на набор от DFD
2. Използвайте DFD, за да идентифицирате заплахи и да ги опишете в стил на злоупотреба
3. 3. Определете противодействие и проверка на заплахите
   Резултатът от дейността по моделиране на заплаха е модел на заплаха, който съдържа приоритетни заплахи и противодействия. Работата по разработката, необходима за справяне с мерките за противодействие, се управлява чрез създаване на билети на Jira както за прилагане, така и за проверка на мерките за противодействие.

   

Статичен анализ на кода
В ASDM екипите могат да използват анализ на статичен код по три начина:

• Работен процес на разработчици: разработчиците анализират кода, върху който работят
• Работен процес на Gerrit: разработчиците получават обратна връзка в Gerrit
• Наследен работен процес: екипите анализират високорискови наследени компоненти

  

Сканиране на уязвимости
Редовното сканиране за уязвимости позволява на екипите за разработка да идентифицират и коригират уязвимостите на софтуера, преди продуктите да бъдат пуснати публично, намалявайки риска за клиентите при внедряването на продукта или услугата. Сканирането се извършва преди всяка версия на хардуер, софтуер) или по график (услуги), като се използват пакети за сканиране на уязвимости с отворен код и търговски. Резултатите от сканирането се използват за генериране на билети в платформата за проследяване на проблеми Jira. Билетите се дават специално tag да могат да бъдат идентифицирани от екипите за разработка като идващи от сканиране за уязвимости и че трябва да им се даде повишен приоритет. Всички сканирания за уязвимости и Jira билети се съхраняват централно за целите на проследяване и одит. Критичните уязвимости трябва да бъдат разрешени преди пускането или в специална версия на услугата с други, некритични уязвимости,
проследени и решени в съответствие с цикъла на издаване на фърмуера или софтуера. или повече информация за това как се оценяват и управляват уязвимостите, вижте Управление на уязвимости на страница 12

Външен тест за проникване
В избрани случаи се извършва тест за проникване на трета страна на хардуерни или софтуерни продукти на Axis. Основната цел на провеждането на тези тестове е да се предостави представа и увереност относно сигурността на платформата в определен момент от време и за определен обхват. Една от основните ни цели с ASDM е прозрачността, така че ние насърчаваме нашите клиенти да извършват външни тестове за проникване на нашите продукти и се радваме да си сътрудничим при определянето на подходящи параметри за тестване, както и при дискусии около интерпретирането на резултатите.

Управление на уязвимостта
От 2021 г. Axis е регистриран орган за именуване на CVE (CNA) и следователно може да публикува стандартни отчети за CVE в базата данни MITER за използване от скенери за уязвимости на трети страни и други инструменти. Платката за уязвимости (VB) е вътрешната точка за контакт на Axis за уязвимости, открити от външни изследователи. Отчитане на
откритите уязвимости и последващите планове за коригиране се съобщават чрез product-security@axis.com имейл адрес.
Основната отговорност на борда за уязвимости е да анализира и приоритизира докладваните уязвимости от бизнес гледна точка, въз основа на

• Техническа класификация, предоставена от SSG
• Потенциален риск за крайните потребители в средата, в която работи устройството Axis
• Наличие на компенсиращи контроли за сигурност lалтернативно намаляване на риска без корекция)

VB регистрира CVE номера и работи с репортера, за да присвои CVSS резултат на уязвимостта. VB също управлява външна комуникация с партньори и клиенти чрез услугата за известия за сигурност на Axis, съобщения за пресата и новинарски статии.

Модел за развитие на сигурността на Axis © Axis Communications AB, 2022

Документи / Ресурси

AXIS Security Development Model Software [pdf] Ръководство за потребителя Модел за развитие на сигурността, софтуер, софтуер за модел за развитие на сигурността

Референции

• Ръководство за потребителя