При регистрация на инцидентите при разработка на софтуер говорим за две различни неща, които често се бъркат: уязвимост или неправилност в софтуера, който строите и доставляте, и инцидент в собствената ви разработна среда — средата, в която създавате този софтуер. Това, което записвате, кой трябва да го знае и какъв е следващия етап, се различава в зависимост от вида. Ако не правите това разграничение, често пропускате инцидента, който има най-голямо значение: заразяване в build-pipeline, което се разпространява чрез кода до всички клиенти, които го използват.
Уязвимост в доставления код директно засяга клиента: той изпълнява софтуера, следователно е изложен на риск. Инцидент в разработната среда — откраднат достъп, компрометиран build-акаунт, течане на хранилище със изходния код — засяга преди всичко вас, но може да се разпространи до всеки клиент, който работи с този код. И за двата случая е вярно, че въпросник за безопасност или проверяващ не пита дали някога нещо се е объркало, а дали можете да покажете какво сте записали по този въпрос и какво сте научили.
Какво записвате при инцидент в кода
При уязвимост или неправилност в доставения софтуер е важно да отбележите: кога е открита, от кого или какво (вътрешен тест, клиентско съобщение, сканиране, външно изследване), коя част на софтуера е засегната, какъв е возможният ефект, какво действие е предприето и кога, и кой в организацията е отговорен за проследяването. Добра регистрация също така показва дали поправката е развернута до всички клиенти, които използват съответната версия, или само до този, който я докладва. Последното е точно онова, за което клиентът пита във въпросник: не дали сте имали уязвимост, а дали вашия процес гарантира, че всеки, който е засегнат, ще бъде информиран.
Какво записвате при инцидент в разработната среда
Инцидент в собствената ви разработна среда — компрометиран акаунт с достъп до изходния код, build-сървър, който реагира по неочакван начин, зависимост, която по-късно се оказва злонамерена — изисква малко по-различна регистрация. Тук е важно да отбележите: кой система или акаунт е бил засегнат, кой имаше достъп в периода, когато се е случило, има ли признаци, че кодът е бил променен или преглеждан, и кои клиенти вероятно използват софтуер, който е бил построен или доставлен в този период. Това е типът инцидент, който директно засяга управлението на достъпа в разработната среда: без актуален преглед на това кой има разрешение де къде, отговаряне на този въпрос при инцидент е значително по-сложно.
Кого информирате и кого не
Дали вие сами попадате под зоботелата на Законом за киберсигурност, определя кого информирате за инцидент. Образувания, класифицирани като съществени или важни, имат задължение да докладват на надзирателя; какво точно трябва да се докладва и в какъв срок, е описано в директивата и националния закон, и се различава в зависимост от ситуацията. Софтуерна компания, която е засегната чрез веригата на доставка — т.е. сама не е обвързана, но доставя на клиент, който е — няма това задължение да докладва на надзирателя, но обикновено има договорно съглашение да информира клиента. Това не прави собствената регистрация по-малко важна: клиент, който пита дали някога сте имали инцидент, иска да види конкретен отговор, не преценка направена впоследствие.
Живо хранилище, не архив
Регистрирането на инцидентите работи най-добре като живо управляемо съдържание: списък, в който по всеки инцидент могат да се намерят статус, документално свидетелство и отговорник, вместо отделен доклад, който след разрешението изчезва в папка. Това съответства на начина, по който е структурирано по-широко задължението за разумни мерки, със десет мерки, всяка от които изисква статус и отговорник. Кой желае да видит как регистрирането на инцидентите се съотнася с другите девет мерки, намира това преглед на страницата със всички теми по ситуация.
Дали вашата организация самата попада под задължението за разумни мерки, се засегнатите чрез веригата на доставките, или никое от двете, може да се види с няколко въпроса чрез NIS2-проверката, която с няколко въпроса дава показаниеКой точно желае да знае откъде идва информацията на secria.eu и как се поддържа, чете това на страницата как работиИ кой след четенето желае да знае какво добавя абонамент към това, което тук е безплатно, намира това надзорно при преглед на включеното.
Този текст е общо пояснение и не е юридически съвет относно вашата собствена ситуация. За преценка на вашия конкретен процес на инцидент или задължението за докладване можете да се обърнете към юрист или към надзорния орган, който е компетентен за вашия сектор.