Упатство за употреба на софтвер за модел за развој на безбедност на AXIS

Софтвер за модел за развој на безбедност на AXIS

Вовед

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

Примарните цели кои ги поттикнуваат напорите за ASDM се

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

Речник

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 за безбедни развојни практики и безбедносна свест во развојната организација.

Сателити
Сателитите се членови на развојната организација кои поминуваат дел од своето време работејќи со софтверски безбедносни аспекти. Причините за постоењето на сателити се:

• Зголемете го ASDM без изградба на голем централен SSG
• Обезбедете поддршка за ASDM блиску до развојните тимови
• Олеснете го споделувањето знаење, на пр., најдобри практики
  Сателитот ќе помогне во спроведувањето на нови активности и одржувањето на ASDM во подгрупата на развојните тимови.

Распоред на активноста на ASDM
Распоредот на активноста на ASDM на развојниот тим е какоtagед процес:

1. Тимот се запознава со новата активност преку обука за одредена улога.
2. SSG работи заедно со тимот за да ја изврши активноста, на пр., проценка на ризик или моделирање закани, за избрани делови од системот(ите) со кои управува тимот.
3. Понатамошните активности поврзани со интегрирање на алатникот во секојдневната работа ќе бидат предадени на тимот и сателитот кога ќе бидат подготвени да работат самостојно без директно вклучување на ССГ. Во оваа фаза, работата е управувана од менаџерот на тимот преку статусот ASDM.
   Воведувањето се повторува кога има достапни нови верзии на ASDM со изменети и/или додадени активности. Количината на времето поминато од SSG со тим е многу зависно од активноста и сложеноста на кодот. Клучен фактор за успешно предавање на тимот е постоењето на вграден сателит кој може да продолжи со понатамошната работа на ASDM со тимот. SSG го поттикнува учењето и доделувањето на сателитот паралелно со започнувањето на активностите.
   Сликата подолу ја резимира методологијата за воведување.

   

SSG дефиницијата за „готово“ за предавање е:

• Извршена обука за специфична улога
• Сателит е доделен
• Тимот е подготвен да ја изврши ASDM активноста
• Воспоставени се повторливи состаноци за статусот на ASDM
  SSG користи податоци од тимовите за да состави извештаи за статусот до повисокото раководство.

Други активности на ССГ
Паралелно со активностите за воведување, ССГ спроведува пошироки активности за обука за безбедност на свеста насочени на пр., новите вработени и повисокото раководство. Дополнително, SSG одржува безбедносна топлинска карта на решенија на Axis за цели на проценка на целокупниот/архитектонски ризик. Активностите за проактивна безбедносна анализа за одредени модули се вршат врз основа на мапата за топлина.

Улоги и одговорности
Како што е прикажано во табелата подолу, постојат некои клучни ентитети и улоги кои се дел од програмата ASDM. Табелата подолу ги сумира улогите и одговорностите во однос на ASDM.

Управување со ASDM

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

• Топлинска карта на ризик на системот за да помогне да се даде приоритет на активностите на ASDM
• План за воведување и статус за да се фокусираат на напорите за обука
• Патоказ за развој на алатникот
• Статус за мерење колку добро се интегрирани активностите на ASDM во организацијата

Така, системот ASDM е поддржан и од тактичка/оперативна перспектива како и од стратешка/извршна перспектива.
Извршното упатство од десната страна на сликата е фокусирано на тоа како да се развие организацијата за оптимална ефективност во согласност со деловните цели на Оската. Важен придонес за ова е известувањето за статусот на ASDM што го врши SSG кон Групата за управување со фирмверот, CTO и управување со производи.

Статусна структура на ASDM

Структурата на статусот ASDM има две перспективи: една тимска насочена имитација на структурата на нашиот тим и оддел, и една насочена кон решение фокусирана на решенијата што ги носиме на пазарот.
Сликата подолу ја илустрира структурата на статусот ASDM.

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

Axis ја дефинира зрелоста на ASDM како верзија на ASDM што тимот моментално ја користи. Бидејќи ASDM се развива, го дефиниравме ASDM верзијата каде што секоја верзија на ASDM содржи уникатен сет на активности. За прampЛе, нашата прва верзија на ASDM е фокусирана на моделирање закани.
Axis ги дефинираше следните ASDM верзии:

Давајќи му на тимот сопственост на која верзија ASDM ја користат значи дека линискиот менаџер е одговорен за усвојувањето на новите ASDM верзии. Така, наместо поставување каде што SSG турка централен план за воведување на ASDM, сега станува заснован на влечење и контролиран од менаџерите.

Статус на компонента

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

Овој имот го нарекуваме покриеност и ги дефиниравме следните нивоа на покриеност:

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

Статус на решение

Статусот на решението го собира безбедносниот статус за збир на компоненти што го сочинуваат решението.
Првиот дел од статусот на решението е анализа на покриеноста на компонентите. Ова им помага на сопствениците на решенија да разберат дали безбедносниот статус на решението е познат или ако не е. Во една перспектива помага да се идентификуваат слепите точки. Остатокот од статусот на решението содржи метрика што го доловува безбедносниот квалитет на решението. Тоа го правиме со гледање на безбедносните работни ставки кои се поврзани со компонентите во решението. Важен аспект на безбедносниот статус е лентата за грешки дефинирана од сопствениците на решенијата. Сопствениците на решенијата мора да дефинираат соодветно безбедносно ниво за нивното решение. За прampова значи дека решението не треба да има отворени работи кои се клучни или со висока сериозност кога ќе биде пуштен на пазарот.

АСДМ активности

Проценка на ризик
Главната цел на проценката на ризикот е да се филтрира кои развојни активности кои исто така ќе бараат безбедносна работа во тимот.
Проценката на ризикот се врши со судење дали нов производ или додадена/модифицирана карактеристика во постоечките производи ја зголемува изложеноста на ризик. Имајте предвид дека ова ги вклучува и аспектите за приватност на податоците и барањата за усогласеност. ПрampДел од промените кои имаат влијание на ризик се нови API, промени во барањата за авторизација, нов среден софтвер, итн.

Приватност на податоците
Довербата е клучна област за фокусирање на 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) е внатрешната контактна точка на оската за ранливости откриени од надворешни истражувачи. Известување за
откриените ранливости и последователните планови за санација се соопштуваат преку product-security@axis.com адреса на е-пошта.
Главната одговорност на одборот за ранливост е да ги анализира и приоритизира пријавените ранливости од деловна перспектива, врз основа на

• Техничка класификација обезбедена од SSG
• Потенцијален ризик за крајните корисници во околината во која работи уредот Axis
• Достапност на компензирачки безбедносни контроли алтернативно ублажување на ризикот без крпење)

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

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