Кіраўніцтва карыстальніка праграмнага забеспячэння AXIS Security Development Model

Праграмнае забеспячэнне мадэлі распрацоўкі бяспекі AXIS

Уводзіны

Мэты ASDM
Мадэль развіцця бяспекі Axis (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 для бяспечных практык распрацоўкі і інфармаванасці аб бяспецы ў арганізацыі-распрацоўшчыку.

Спадарожнікі
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.

Кіраванне ASDM

Сістэма кіравання складаецца з наступных частак:

• Цеплавая карта сістэмных рызык, якая дапамагае вызначыць прыярытэты дзеянняў ASDM
• План распаўсюджвання і статус, каб засяродзіцца на намаганнях па навучанні
• Дарожная карта для развіцця панэлі інструментаў
• Статус для вымярэння таго, наколькі добра дзейнасць ASDM інтэграваная ў арганізацыю

Такім чынам, сістэма ASDM падтрымліваецца як з тактычнай/аператыўнай пункту гледжання, так і са стратэгічнай/выканаўчай пункту гледжання.
Праваруч на малюнку кіраўнічыя інструкцыі сканцэнтраваны на тым, як развіваць арганізацыю для дасягнення аптымальнай эфектыўнасці ў адпаведнасці з бізнес-мэтамі Axis. Важным укладам у гэта з'яўляецца справаздачнасць аб стане ASDM, якую SSG накіроўвае ў групу кіравання прашыўкай, тэхнічнага дырэктара і кіраўніцтва прадуктам.

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

Структура статусу ASDM мае дзве перспектывы: адну, арыентаваную на каманду, якая імітуе структуру нашай каманды і аддзела, і другую, арыентаваную на рашэнні, арыентаваную на рашэнні, якія мы прадстаўляем на рынак.
На малюнку ніжэй паказана структура стану ASDM.

Статус каманды
Статус каманды змяшчае самаацэнку каманды адносна сталасці ASDM, паказчыкі, звязаныя з іх дзейнасцю па аналізе бяспекі, а таксама сукупны стан бяспекі кампанентаў, за якія яны адказваюць.

Axis вызначае сталасць ASDM як версію ASDM, якую каманда выкарыстоўвае ў цяперашні час. Паколькі ASDM развіваецца, мы вызначылі кіраванне версіямі ASDM, дзе кожная версія ASDM змяшчае унікальны набор дзеянняў. Напрыкладample, наша першая версія ASDM сканцэнтравана на мадэляванні пагроз.
Кампанія Axis вызначыла наступныя версіі ASDM:

Перадача камандзе права ўласнасці на тое, якую версію 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
• Наяўнасць кампенсацыйных сродкаў кантролю бяспекі (альтэрнатыўнае зніжэнне рызыкі без выпраўлення)

VB рэгіструе нумар CVE і працуе з рэпарцёрам, каб прысвоіць адзнаку CVSS уразлівасці. VB таксама забяспечвае знешнюю сувязь з партнёрамі і кліентамі праз службу апавяшчэнняў бяспекі Axis, прэс-рэлізы і навінавыя артыкулы.

Мадэль развіцця бяспекі Axis © Axis Communications AB, 2022