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