Часті запитання

LibreKAT Foundation працює над відкритою, контрольованою та перевіреною інформаційною безпекою. Фонд підтримує проекти, обмін знаннями та співпрацю навколо цифрової безпеки.

Це стосується не лише програмного забезпечення. LibreKAT також хоче сприяти кращим методам роботи, більшій прозорості та спільноті, у якій люди можуть разом покращувати цифрову безпеку.

Докладніше на Про фонд LibreKAT.

Digital security is too important to be completely dependent on closed systems, uncontrollable processes or loose promises. Організації повинні мати можливість розуміти, контролювати та покращувати, як працює їхня безпека.

LibreKAT існує, щоб сприяти цьому. Фонд заохочує відкриті технології, обмін знаннями та співпрацю між людьми, які хочуть підвищити цифрову стійкість.

Також прочитайте Які цілі LibreKAT Foundation? та Про фонд LibreKAT.

Ні. LibreKAT є фондом і не має мети прибутку. Фонд може співпрацювати з компаніями, урядами, дослідниками, волонтерами та громадськими організаціями.

Головною метою співпраці є сприяння відкритому, стійкому та перевіреному цифровому захисту.

Докладніше на Про фонд LibreKAT.

Libre означає свободу. Не просто вільне використання, а перш за все свобода вивчення, контролю, адаптації та обміну технологіями.

Це важливо для інформаційної безпеки. Якщо ви хочете покладатися на систему чи метод, ви повинні мати змогу побачити, як вони працюють і як приймаються рішення.

Це пов’язано з основні цінності LibreKAT Foundation.

LibreKAT Foundation хоче покращити цифрову безпеку, заохочуючи відкриту, контрольовану та перевірену інформаційну безпеку.

Конкретно це включає:

• розробка та використання програмного та апаратного забезпечення з відкритим кодом для безпечних цифрових інфраструктур;
• прозорість і відтворюваність процесів безпеки;
• дослідження, навчання та діяльність з цифрової стійкості;
• зв’язок між громадянами, компаніями, урядом і громадськими організаціями.

Докладніше читайте на Про фонд LibreKAT та домашня сторінка фонду LibreKAT.

LibreKAT є основою. OpenKAT — це продукт для аналізу вразливостей з відкритим кодом.

Імена схожі, але не означають те саме. Основа може підтримувати OpenKAT, і OpenKAT відповідає місії LibreKAT, але OpenKAT не є самою основою.

Докладніше про Фонд LibreKAT та OpenKAT.

Відкритий код робить можливим контроль. Люди можуть бачити, як працює програмне забезпечення, знаходити помилки, пропонувати вдосконалення та зменшувати залежність від одного постачальника.

Відкритий код не є автоматичною гарантією безпеки. Це важлива умова прозорості, співпраці та відновлюваності.

Дізнайтеся більше про принципи на Про фонд LibreKAT.

Важливими проектами на цьому сайті є OpenKAT, MIAUW і OciDeck.

OpenKAT допомагає зробити видимими вразливості та цифрові ризики. MIAUW допомагає зробити дослідження інформаційної безпеки перевіреними та гідними аудиту. OciDeck допомагає зі структурованими презентаціями, звітами та безпечним обміном інформацією.

Докладніше про OpenKAT, MIAUW та OciDeck.

LibreKAT призначений для всіх, хто хоче зробити цифрову безпеку відкритою, доступною для перевірки та більш зрозумілою.

Подумайте про фахівців із безпеки, розробників, адміністраторів, аудиторів, дослідників, уряди, компанії, навчальні заклади, громадські організації та залучених громадян.

Докладніше на Про фонд LibreKAT.

так Ви можете брати участь кількома способами: додавати код, покращувати документацію, тестувати, перекладати, ставити запитання, ділитися досвідом або допомагати в зустрічах і громадських заходах.

Вам не обов’язково знати все технічно, щоб зробити цінний внесок. Хороші запитання, практичний досвід і чіткі пояснення також важливі.

Зв’яжіться з нами за адресою контакт.

Це можливо, якщо співпраця відповідає цілям фонду. LibreKAT шукає співпраці, яка сприятиме відкритому, стійкому та перевіреному цифровому захисту.

Прикладами є обмін знаннями, дослідження, розробка з відкритим кодом, документація, навчання або практичне застосування проектів.

Дивіться також Партнери і контакт.

Важливими цінностями є безпека, свобода, відкритість, суверенітет, цілісність, обмін знаннями, співпраця, людяність і спадкоємність.

Зрозумілою мовою: LibreKAT хоче, щоб цифрова безпека була перевіреною, справедливою, стійкою та зручною для людей і організацій, які від неї залежать.

Читайте також статтю Про наші основні цінності.

Скористайтеся сторінка контактів, якщо у вас є запитання, ви хочете зробити внесок або обговорити співпрацю.

Спробуйте коротко описати, про що стосується вашого запитання: фонд, MIAUW, OpenKAT, OciDeck, співпраця, преса чи технічний внесок. Тоді швидше стане зрозуміло, хто може відповісти.

Культура справедливості — це організаційна культура, в якій люди можуть повідомляти про проблеми з безпекою, помилки та можливі інциденти, не шукаючи автоматично когось звинуватити. Організація використовує інформацію, щоб зрозуміти, що сталося, і вдосконалити людей, технології, методи роботи та організацію.

Це не означає, що будь-яка поведінка прийнятна. Справедлива культура заздалегідь дає зрозуміти, де пролягають межі, і оцінює поведінку ретельно, послідовно та в контексті. Європейські авіаційні правила визначають це як культуру, в якій співробітники не караються за дії, що відповідають їхньому навчанню та досвіду, а груба недбалість і навмисні порушення не допускаються. Перегляньте Регламент (ЄС) 376/2014.

Сучасна розробка походить від науки безпеки, що оточує складні організації з високим ризиком. У 1997 році психолог Джеймс Різон описав справедливу культуру як частину інформованої культури безпеки, на додаток до культури звітності, культури навчання та гнучкої культури.

Авіація, зокрема, застосувала цей принцип на практиці. Аварії та можливі аварії можна розслідувати лише тоді, коли пілоти, авіадиспетчери, техніки та інші наважуються поділитися інформацією. Тому авіаційні організації розробили системи звітності, які не карають автоматично типові помилки, але встановлюють обмеження для навмисної або необачної поведінки. SKYbrary описує цю розробку; Європейський Союз запровадив цей принцип у правила звітування про події в цивільній авіації у 2014 році.

Згодом Just Culture також застосовували в охороні здоров’я, залізниці, енергетиці та інших секторах, де важливо вчитися на слабких сигналах. Таким чином, це не авіаційна процедура, яка копіюється один на один, а ширший принцип боротьби з помилками та ризиками справедливим та орієнтованим на навчання способом.

Ні. Культура справедливості запобігає автоматичному покаранню за чесне повідомлення, просту помилку чи ненавмисне порушення. Може знадобитися коучинг, додаткова підтримка або адаптований метод роботи; Це заходи для забезпечення безпечної роботи, а не автоматичні покарання.

У випадках навмисної неправомірної поведінки, саботажу, навмисної нерозсудливості або серйозного ігнорування явного ризику може бути прийнятним вжиття заходів щодо особи. Для цього по-перше, потрібне чесне розслідування фактів, обставин, навчання, наявні ресурси та аналогічні попередні рішення. Справедлива культура також не надає правового імунітету: чинне законодавство продовжує діяти. Цей баланс можна знайти в Стаття 16 Регламенту (ЄС) 376/2014.

Ні. Повна модель «без звинувачень» може виключити відповідальність і неприйнятну поведінку. Справедлива культура шукає справедливу межу між поведінкою, з якої організація повинна вчитися, і поведінкою, з якої вона має звертатися до людини.

Перше питання полягає не в тому, «кого ми можемо покарати?», а в тому, «що сталося, чому цей вчинок тоді здавався логічним і які обставини зіграли роль?». Лише тоді постає питання, чи потрапила поведінка в раніше відомі та постійно застосовувані межі.

Ні. Співробітники залишаються відповідальними за обережність, звітування та співпрацю в розслідуванні. Менеджери відповідають за реалістичні цілі, достатні ресурси, чіткі межі та вирішення структурних проблем.

Підзвітність означає, що вибір і обставини можна обговорювати та контролювати. Звинувачення — це судження про провину. Справедлива культура розділяє обидва, щоб відповідальність не зникала, а розподілялася більш справедливо.

Людська помилка є ненавмисною. Ризикована поведінка може виникнути через те, що хтось недооцінює ризик, небезпечна звичка стала нормальною або цілі суперечать одна одній. Необережна поведінка передбачає свідоме і серйозне ігнорування очевидного ризику. Умисно шкідливі дії утворюють ще одну категорію.

Ці слова не є автоматичними результатами. Ретельне розслідування розглядає навчання, доступну інформацію, робоче навантаження, технічний дизайн, процедури, попередні сигнали та те, як інші діяли в тій же ситуації. Тяжкість шкоди сама по собі не доводить, що поведінка була необережною.

Співробітники зобов’язані своєчасно повідомляти про помилки, ризики та можливі інциденти, висловлювати невпевненість, співпрацювати в дослідженнях і ділитися відповідними знаннями. Очікується, що керівники будуть слухати без передчасних суджень, захищати репортерів, досліджувати факти та контекст і надавати відгуки про те, що відбувається зі звітом.

Організація повинна усунути структурні причини, однаково ставитися до порівнянних випадків і заздалегідь прояснити, яка поведінка є неприйнятною. Приховування, помста, судження лише про результат або дозволення відомим ризикам і далі не вписуються в культуру справедливості.

Інформаційна безпека залежить від ранніх сигналів. Подумайте про відкрите фішингове посилання, неправильно налаштований доступ, майже витік файлу, небезпечне екстрене рішення або вразливість, яку хтось випадково виявив. Страх перед покаранням чи псуванням репутації може призвести до того, що така інформація буде повідомлена занадто пізно або взагалі не буде повідомлена.

Справедлива культура знижує цей поріг і забезпечує швидше розслідування та відновлення. Це не замінює заходи безпеки, реагування на інциденти, зобов’язання щодо звітування чи дії проти зловживань. Це гарантує, що організація отримує більш надійну інформацію для цілеспрямованого використання цих інструментів.

Люди працюють у рамках цілей, інструментів, процедур, тиску часу та технічних обмежень. Якщо кілька людей можуть зробити ту саму помилку, звернення до останньої особи не є повним рішенням. Ті самі умови можуть знову спричинити проблему.

Таким чином, справедлива культура також вивчає дизайн системи, права доступу, навчання, робоче навантаження, контроль, суперечливі цілі та попередні сигнали. Це не виключає індивідуальної відповідальності. Це заважає видимим людським діям приховати від очей глибші причини.

Тестування на проникнення може стосуватися поведінки співробітників, адміністраторів або постачальників. MIAUW вимагає, щоб висновок був обґрунтований доказами, обсягом і контекстом. Тому звіт має описувати спостережувані факти та наслідки, а не приписувати наміри чи особисту провину без розслідування.

Справедлива культура допомагає використати результат для відновлення: які технічні чи організаційні умови зробили проблему можливою, який захід зменшує повторення та кому належить цей захід? Якщо індивідуальні дії видаються доцільними, це вимагає окремого та справедливого процесу; сама оцінка тестування на проникнення не є доказом цього.

Спочатку опишіть, що очевидно сталося, коли, в якому обсязі та з якими наслідками. Потім запишіть відповідні обставини, такі як доступна інформація, інструкції, робоче навантаження, права доступу та технічна безпека. Поясніть, що таке факт, твердження та непідтверджене припущення.

Використовуйте ім’я лише тоді, коли ідентифікація є необхідною та пропорційною. Такі формулювання, як «обліковий запис зміг виконати дію», часто є більш інформативними, ніж «співробітник X спричинив інцидент». У відповідних випадках дайте учасникам можливість виправити фактичні неточності або відсутній контекст.

Індивідуальна відповідальність може бути необхідною у випадку навмисної шкідливої ​​поведінки, навмисного саботажу, обману або серйозного та винного ігнорування явного ризику. Навіть у цьому випадку рішення має випливати з фактів, вислуховування обох сторін, зрозумілих правил і пропорційної відповіді.

Для встановлення винуватості недостатньо наслідків дії. Невелика помилка може випадково завдати великої шкоди, тоді як необачна поведінка іноді закінчується без шкоди. Тому культура справедливості оцінює поведінку та контекст, а не лише удачу чи невдачу в результаті.

Правильно застосована культура справедливості може підвищити готовність повідомляти про помилки, ризики та можливі інциденти. Це дозволяє організації швидше помітити слабкі сигнали, розпізнати повторювані закономірності та зосередити заходи на причинах, а не лише на останній особі в ланцюжку.

Інші можливі переваги включають підвищення довіри, кращі розмови про безпеку, підтримку відданих співробітників і постійне вдосконалення процесів. Ці наслідки виникають не лише від етикетки. нещодавній огляд 36 медичних заходів знайшов такі результати, але також підкреслює, що досі важко точно визначити, які компоненти викликають який ефект. Таким чином, Just Culture — це робочий метод, який підтримує навчання, а не гарантія меншої кількості інцидентів.

Подивіться на якість і розповсюдження звітів, час на отримання зворотного зв’язку, відсоток виконаних заходів щодо вдосконалення, повторення подібних подій і сприйняту справедливість дослідження. Співробітники повинні знати межі та вірити, що подібні випадки розглядатимуть однаково.

Збільшення кількості звітів спочатку може бути доброю ознакою: раніше прихована інформація стає видимою. Тому простого підрахунку звітів недостатньо. Також перевірте, чи організація вчиться з цього, чи підтримує журналістів, бореться зі структурними причинами та мотивує рішення у наслідуваний спосіб.

Ні. Справедлива культура була значно розвинена в авіації, а пізніше була застосована в охороні здоров’я, зокрема, тому що помилки можуть мати серйозні наслідки, а раннє звітування є життєво важливим. Основне — здатність безпечно звітувати, чесно оцінювати поведінку в контексті та вдосконалювати систему — також корисно в інформаційній безпеці, розробці програмного забезпечення, державних службах та інших організаціях, у яких люди працюють зі складними системами.

Розробка повинна відповідати організації. Невеликий фонд має інші ролі, ризики та юридичні зобов’язання, ніж авіакомпанія. Тому дотримуйтесь принципів, але самі створіть чіткі маршрути звітності, повноваження, поведінкові межі та гарантії. Нещодавній [загальний огляд культури справедливості в охороні здоров’я] (https://pubmed.ncbi.nlm.nih.gov/41612347/) також показує, що втручання, які вивчалися, відрізняються, а докази успішного впровадження все ще обмежені.

Психологічна безпека означає, що люди в команді сміють йти на міжособистісний ризик: ставити питання, висловлювати сумніви, визнавати помилку або висловлювати іншу думку. Справедлива культура більш конкретно визначає, що потім організація робить зі звітом або подією: як вона розслідує, оцінює поведінку, захищає репортерів, розподіляє відповідальність і впроваджує вдосконалення.

Поняття підсилюють одне одного, але не є однаковими. Приємний колектив без чіткої та послідовної оцінки – це ще не просто культура. І навпаки, хороший політичний документ не працює, якщо люди не наважуються говорити на практиці. Дослідження психологічної безпеки згадують інклюзивне лідерство, підтримку та орієнтацію на навчання як важливі умови. Перегляньте цей систематичний огляд.

Керівники встановлюють чіткі очікування, спокійно реагують на погані новини та забезпечують незалежне та експертне дослідження звітів. Вони спочатку запитують, що сталося і які обставини зіграли роль, перш ніж робити висновки про людей. Вони також звільняють час, людей і бюджет для заходів із покращення та забезпечують відгук про те, що було зроблено за допомогою звітів.

Їхні власні дії також повинні бути перевірені. Якщо розглядаються лише керівники, а вибір щодо робочого навантаження, ресурсів чи нечітких цілей залишається поза увагою, культура несправедлива. У [Посібнику AHRQ із системного розслідування інцидентів] (https://www.ahrq.gov/patient-safety/settings/hospital/candor/modules/guide4.html) наголошується як на підтримці керівництва, так і на встановленні фактів, а не на пошуку звинувачень.

Співробітники повідомляють про відповідні помилки, можливі інциденти, небезпечні умови та сумніви якомога своєчасніше та фактично. Вони беруть участь у дослідженнях, також діляться інформацією, яка може бути незручною, і допомагають вносити вдосконалення, корисні для щоденної практики. Вони шанобливо підходять до колег і просять про допомогу, коли не вистачає знань, часу чи ресурсів.

Справедлива культура не вимагає ні досконалості, ні героїзму. Працівник залишається відповідальним за те, щоб діяти акуратно в рамках своєї ролі, але організація залишається відповідальною за працездатну систему, належне навчання та реалістичні умови. Тому відповідальність розподіляється, а не перекладається.

По-перше, люди та системи захищені, а отримання звіту підтверджено. Потім уповноважена особа визначає, хто буде обробляти звіт, яка інформація потрібна та яку конфіденційність можна надати. Дослідження реконструює подію, залучає відповідних людей і розглядає технічні, людські та організаційні фактори.

Висновки та заходи потім реєструються, залучені особи отримують відповідний відгук і контролюється, чи заходи були фактично впроваджені та чи працюють вони. Повідомлення без видимих ​​дій підриває довіру. Дослідження систем звітності про інциденти попереджають, що лише збору інформації недостатньо; саме дії щодо вдосконалення та замкнутий цикл навчання визначають цінність. Перегляньте цей систематичний огляд.

Розслідування починається з часових рамок і фактів, які можна перевірити, а не з підозрюваного винного. Дослідники шанобливо розмовляють із залученими, перевіряють різні твердження та вивчають процедури, навчання, інструменти, робоче навантаження, спілкування, вибір дизайну та попередні сигнали. Те, що залишається невизначеним, також записується.

Будь-хто, хто особисто залучений або має конфлікт інтересів, не повинен самостійно вирішувати результат. Залучені особи повинні мати можливість пояснити відповідні факти та виправити фактичні неточності. Обраний захід має відповідати поведінці та обставинам, а подібні випадки мають розглядатися однаково. Тим часом можуть знадобитися термінові заходи безпеки, але вони не повинні представлятися як приховане покарання.

Організація заздалегідь визначає, хто оцінює поведінку, за якими критеріями та з якою можливістю суперечності чи перегляду. Залежно від тяжкості може бути залучено керівника, спеціаліста з безпеки, відділу кадрів, експерта з певної тематики, представника працівників або незалежного комітету. Юридичні питання належать комусь із відповідним досвідом.

Оцінювачі дивляться не лише на результат, але й на передбачуваність, намір, знання, підготовку, доступні альтернативи та обставини на момент дії. Серйозний результат сам по собі не свідчить про необачну поведінку; хороший результат не робить свідомо небезпечну поведінку прийнятною.

Не сприймайте сумнів як доказ проти відповідної особи. Зберіть додаткові факти, попросіть когось із експертними знаннями розглянути реальні варіанти дій і перевірте, чи могли б інші зробити подібний вибір за тих самих обставин. Розрізняйте те, що видно згодом, і те, що людина могла розумно знати на той момент.

Запишіть компроміс і залишкову невизначеність. Рішучий кадровий захід вимагає більш суворого та незалежного процесу із слуханням і можливістю перегляду. Крім того, негайно усувати слабкі місця системи; розбіжності щодо індивідуальної відповідальності не є причиною для існування очевидної проблеми безпеки.

Конфіденційне повідомлення означає, що особа відома лише людям, яким вона потрібна для ретельного процесу. Анонімне повідомлення означає, що одержувач не знає особи. Конфіденційність дозволяє задавати додаткові запитання та особистий відгук; анонімність може знизити поріг, якщо хтось побоюється репресій або конфлікту інтересів.

Запропонуйте обидва шляхи, якщо це доцільно, і чесно поясніть заздалегідь, що можна, а що не можна захистити. Повну анонімність не завжди можна гарантувати технічно чи юридично, а деталі події можуть опосередковано зробити когось впізнаваним. Тому не збирайте більше особистих даних, ніж необхідно, і обмежте доступ і періоди зберігання. Європейські авіаційні правила згадують захист і видалення ідентифікаційних даних як способи підтримки довіри до систем звітності. Див. Пояснення EASA до Регламенту 376/2014.

Справедлива культура та захист викривачів мають пов’язану мету: люди повинні мати можливість повідомляти про серйозні проблеми, не потрапляючи несправедливо в невигідне становище. Однак юридично і практично вони не однакові. Внутрішня угода про культуру справедливості ніколи не може замінити законні права, зовнішній канал звітності чи захист від помсти.

Переконайтеся, що співробітники, підрядники та волонтери знають, який канал відповідає якому звіту та де вони можуть отримати незалежну консультацію. Не сприймайте повідомлення як проблему лояльності та не намагайтеся заблокувати за договором дозволений законом зовнішній канал. Точний захист залежить від чинного законодавства. [Директива ЄС про інформування] (https://eur-lex.europa.eu/legal-content/en/LSU/?uri=CELEX%3A02019L1937-20230502) містить правила щодо конфіденційних каналів, подальших дій і захисту від помсти.

Ні. Зобов’язання повідомляти про інцидент, порушення даних, підозру у вчиненні кримінального правопорушення чи іншу подію продовжують діяти. Наглядач, суддя або уповноважений роботодавець також зберігають свою юридичну роль. Справедлива культура не передбачає, що інформація завжди повинна залишатися в таємниці, і не надає імунітету.

Проте «Культура справедливості» вимагає чітких, пропорційних і послідовних процедур: відокремте навчання від прийняття дисциплінарних рішень, де це можливо, обмежте доступ до звітної інформації та поясніть, коли звітування може бути обов’язковим. Адаптуйте підхід до трудового законодавства, законодавства про конфіденційність, правил сповіщення про викривачі, галузевих правил та наявної участі працівників. Якщо є сумніви, надайте юридичну оцінку конкретної ситуації.

Спочатку визначте, як люди повідомляють зараз, де є страх чи невпевненість і як розглядалися попередні випадки. Потім разом із співробітниками та відповідними представниками розробіть прості правила: що ви повідомляєте, через який канал, хто бачить інформацію, як відбувається розслідування, де межа поведінки та як хтось може переглянути рішення.

Навчайте менеджерів і дослідників на реалістичних прикладах. Практикуйте процес, обережно обробляйте перші звіти та публікуйте анонімні навчальні бали та прогрес. Виміряйте довіру та подальші дії та налаштуйте процес. Краще розпочати з малого й завершеного, ніж із великої програми без можливостей. EASA радить організаціям включити чіткі процеси Just Culture у свою політику безпеки та залучити представників працівників. Див. Інструкції EASA щодо систем звітності.

Поширені помилки включають: ототожнення справедливої культури з тим, що ніколи не говорити, встановлення меж лише після інциденту, плутання серйозності результату з винністю поведінки, дослідження лише останньої людської дії та по-різному розглядання подібних випадків. Широке розповсюдження імен, витоки звітної інформації та керівник, який є одночасно безпосередньо залученим, дослідником та особою, що приймає рішення, також руйнують довіру.

Ще один підводний камінь — запитувати звіти, але не надавати відгуки чи покращення. Тоді репортер несе ризик, поки організація не виконає обіцянку навчання. Засіб можна перевірити: чіткі ролі, захист інформації, своєчасний зворотний зв’язок, видимі дії щодо вдосконалення та періодичне тестування на послідовність.

Справедлива культура, орієнтована на відновлення, розглядає не лише правила, причини та майбутню профілактику, але й шкоду, яку зазнали люди та стосунки внаслідок події та реакції на неї. Серед запитань: хто постраждав, що їм потрібно, хто зобов’язаний щось відновити та як можна відповідально відновити довіру?

Це може призвести до визнання, пояснення, практичної допомоги, відновлення робочих угод або керованої розмови. Участь має бути обережною та доречною; відновлення не повинно ставати засобом тиску з метою вибачення, мовчання чи відмови від прав. Наукової літератури про відновну справедливу культуру стає все більше, але [огляд масштабів 2026] (https://pubmed.ncbi.nlm.nih.gov/41612347/) робить висновок, що докази щодо втручання та успішного впровадження все ще обмежені.

Окремо запитайте, що потрібно тим, кого це безпосередньо стосується, журналістам та іншим залученим сторонам. Подумайте про фактичну інформацію, постійну контактну особу, відпочинок або адаптовані завдання, підтримку однолітків і доступ до професійної допомоги. Поясніть, що дослідження може, а що ні, і коли буде надано зворотний зв’язок. Уникайте спекуляцій і захищайте особисті дані.

Підтримка не є вироком провини і не повинна залежати від подальшої поведінки. У той же час може знадобитися тимчасовий захід безпеки, наприклад, додатковий нагляд або інше завдання. Обґрунтуйте такий захід, обмежте його необхідним і переоцініть його, щойно стане відомо більше фактів.

Під час аварії щось пішло не так або виникла небезпека, але серйозні пошкодження не були спричинені випадковістю, своєчасним втручанням чи додатковим рівнем безпеки. Саме тоді організація може навчитися без того, щоб нікому спочатку нести всі наслідки. Періодичні обхідні шляхи, незрозумілі інструкції та незначні відхилення також можуть бути ранніми сигналами про проблему в системі.

Тому запитуйте не просто «що пішло не так?», а й «що змусило все піти добре?» та «який бар’єр спрацював?». Спростіть звітування та надайте відгук. Систематичний огляд невдалих випадків у сфері охорони здоров’я виявив, що підтримка керівництва, прості шляхи звітування, знання та некаральна реакція впливають на поведінку звітування. Перегляньте огляд на PubMed.

Не обмежуйте Just Culture співробітниками з постійним контрактом. Постачальники, підрядники, дослідники, стажери та волонтери можуть першими побачити вразливість, помилку чи небезпечну ситуацію. Дайте їм зрозумілий шлях звітування, поясніть, який захист застосовується, і чітко вкажіть в угодах, хто проводитиме розслідування та надаватиме відгук.

Організація не може в односторонньому порядку контролювати всі наслідки законодавства про працевлаштування чи договір іншої сторони. Тому заздалегідь домовтеся про те, як буде захищена інформація, коли вона буде передаватись і як помста або конфлікт інтересів будуть запобігати. Окрім працівників, європейські авіаційні правила також стосуються найнятого персоналу; [Правила ЄС щодо сповіщення про порушення] (https://eur-lex.europa.eu/legal-content/en/LSU/?uri=CELEX%3A02019L1937-20230502) також можуть включати, у межах своєї сфери дії, волонтерів, самозайнятих осіб і підрядників.

Ні. Суверенітет не є автаркією і не вимагає повної незалежності. Організації та держави завжди залежать від знань, постачальників, сировини та співпраці.

Мета полягає в тому, щоб залежності були видимими, керованими та замінними, де це необхідно. Ви можете передати роботу стороннім підрядникам і зберегти контроль, доки обов’язки, права, доступ, безперервність і варіанти виходу організовані належним чином.

Жоден продукт не може сам по собі гарантувати цифровий суверенітет. Суверенітет виникає з поєднання управління, контрактів, юрисдикції, архітектури, відкритості, знань, управління та можливих альтернатив.

OpenKAT і OciDeck можуть надати конкретні будівельні блоки: більше розуміння, можливість перевірки, відкриті формати, самокерування та менше непотрібної залежності. Організація повинна свідомо розробляти та продовжувати тестувати ці варіанти.

Запишіть базове вимірювання та бажаний рівень для кожної критичної системи. Потім виміряйте конкретні властивості, такі як частка відомих учасників ланцюга, перевірений експорт даних, ключі, керовані клієнтом, відновлення без постачальника, відкриті інтерфейси та час, необхідний для перемикання.

Також повідомте про залишкові залежності та прийнятні ризики. Прогрес не означає, що будь-яка залежність зникає, а те, що організація отримує більше розуміння, свободи вибору та очевидного простору для дій.

Виставляти вимоги до укладення договору. Запитайте про юрисдикцію, право власності, розташування даних, субпідрядників, віддалене керування, керування ключами, відкриті стандарти, формати експорту, права аудиту, безперервність і припинення.

Також запишіть, як надаються докази та як повідомляється про зміни. Знак якості чи загальна маркетингова заява не замінюють угоду, яку можна перевірити. Використовуйте цілі ECSF і рівні SEAL як спільну мову, де це доречно.

Ні. Європейське зберігання даних актуальне, але не говорить усе про юрисдикцію, власність, управління, ключовий доступ, субпідрядників і технічну залежність.

Тому оцініть всю структуру: які суб’єкти надають послугу, які права можна використовувати, хто може виконувати дії керування, хто керує ключами шифрування та які варіанти виходу доступні?

так Залежність може впливати на доступність, цілісність і конфіденційність інформації. Подумайте про збій або припинення служби, небажаний доступ відповідно до іншої правової системи або зміни, які організація не може контролювати сама.

Ось чому суверенітет належить до регулювання, організації та технології: трьох взаємопов’язаних частин, описаних у книзі як ROT. Це не окреме політичне питання, крім інформаційної безпеки.

Не тоді, коли вимоги спрямовані на контрольовані ризики та застосовуються однаково та з можливістю перевірки до всіх постачальників. Протекціонізм захищає насамперед власну галузь; політика суверенітету захищає контроль, безперервність, цілісність і конфіденційність.

Таким чином, лише національність є слабким критерієм. Юрисдикція, правові угоди, технічна ізоляція, відкритість і варіанти виходу є більш суттєвими.

Ні. Європейська назва чи місцезнаходження не є повною гарантією. Європейський постачальник також може бути захоплений, збанкрутувати, сильно покладатися на неєвропейські технології або надати погані договірні гарантії.

Подивіться на контрольовані структурні особливості: право власності та контроль, застосовне законодавство, управління та доступ до ключів, залежності ланцюга, відкриті стандарти та виконуваний план виходу.

Ні. Відкритий вихідний код надає важливі права на вивчення програмного забезпечення, його модифікацію та підтримку іншими. Тому він може підтримувати прозорість, можливість заміни та формування знань.

Але ці права мають практичну цінність лише за наявності документації, людей, управління, фінансування, безпечних оновлень і доступу до власних даних. Відкритий код також може залежати від одного супроводжуючого, закритої хмарної служби чи інфраструктури, яку важко замінити.

Ні. Суверенітет залежить від контексту. Бажаний рівень випливає з критичності процесу, чутливості даних, правових вимог, схильності до ризику та доступних альтернатив.

Найвищий рівень для всіх систем може бути невиправдано дорогим або нездійсненним. Вмотивований вибір на систему є сильнішим, ніж одна загальна мета без пріоритетів.

Не потрібно. Вимоги до сумісності, прозорості, безпеки та замінності можуть фактично стимулювати інновації, оскільки нові постачальники можуть легше підключатися, а клієнти стають менш прив’язаними.

Існують реальні компроміси щодо вартості, швидкості та функціональності. Вони повинні бути чітко виражені. Контраст між «інноваціями чи суверенітетом» надто простий; мова йде про відповідальні інновації в рамках обраного профілю ризику.

Почніть з проникливості. Створіть огляд критичних процесів, даних, систем, постачальників, субпідрядників, управлінського доступу, застосовної юрисдикції та існуючих варіантів виходу.

Потім пов’яжіть найважливіші залежності з доступністю, цілісністю та конфіденційністю. Тільки тоді, коли зрозуміло, що критично і від чого це залежить, можна вибрати відповідну мету та заходи.

Книга Суверенітет! Як? обговорює історичний розвиток, зв’язок з інформаційною безпекою, ECSF, аргументи з дискусії та практичний шлях розвитку організацій.

Основний меседж приземлений: суверенітет – це не концепція «все або нічого» і не одноразовий проект. Це постійна організація розуміння, напрямок і простір для дій.

Концепція сформувалася в Європі в пізньому середньовіччі та на початку Нового часу. У шістнадцятому столітті Жан Боден описав верховну, постійну державну владу. Тоді Вестфальський мир 1648 року тісно пов’язав суверенітет з територіальними державами та принципом невтручання.

Пізніше легітимність перейшла від монархів до народу, і держави почали здійснювати повноваження спільно, наприклад, у рамках Європейського Союзу. Історія показує, що суверенітет завжди обертається навколо одного й того самого основного питання: хто врешті-решт має останнє слово?

Тому що суверенітет – це не лише ймовірність, а й вплив і здатність діяти. Подія може бути малоймовірною, але мати неприйнятні наслідки для критичного процесу.

Крім того, залежність вже може мати вплив, фактично не блокуючи доступ. Можливість застосування санкцій, правових розпоряджень або припинення може змінити процес прийняття рішень і переговорів.

Уряди, компанії та соціальні організації стали дуже залежними від невеликої кількості постачальників хмарних технологій, офісного програмного забезпечення, комунікацій та ШІ. Водночас можуть змінюватися власність, законодавство, санкції, поглинання та геополітичні відносини.

У результаті формальний контроль може суперечити фактичній залежності. Актуальним питанням є не тільки те, чи надійний постачальник сьогодні, але й те, чи зможе організація діяти завтра, якщо зміниться правила, доступ чи інтереси.

Розрізняйте дійсно незамінні функції та залежності, які виникли через звичку, відсутні знання або старі рішення. Конкретно окресліть підключення, формати даних, ліцензії, процеси та навички.

Потім попрактикуйтеся в експорті, відновленні та альтернативах, поки не настане криза. План виходу, який ніколи не перевірявся, дає мало впевненості. Іноді повна міграція неможлива одразу, але відкриті формати, модульна архітектура та другий шлях реалізації вже можуть покращити позицію.

Тоді доцільним буде поетапний підхід. Спочатку визначте, для яких процесів залежність становить найбільший ризик і які функції дійсно потрібні. Потім вдосконаліть контракти, архітектуру та портативність, а також перенесіть туди, де доступна відповідна альтернатива.

Той факт, що альтернатива є менш зрілою сьогодні, є аргументом щодо темпів і виконання, а не автоматичною причиною ігнорувати ризик. Тому книга обговорює шлях зростання замість одного великого переходу.

Цифровий суверенітет – це ступінь, до якого уряд або організація фактично зберігає контроль над своїми цифровими функціями, даними та залежностями. Враховуються формальні права та фактичні варіанти дій.

Конкретні запитання: де знаходяться дані, хто може отримати до них доступ, який закон застосовується, хто керує ключами, чи може служба продовжувати працювати у разі конфлікту та чи реально можливе перемикання?

ECSF є європейською системою оцінки хмарного суверенітету. Він допомагає громадським організаціям описати ризики суверенітету, встановити вимоги до закупівлі та порівняти поточну та бажану ситуацію.

Структура переносить розмову від загальних тверджень, таких як «європейський» або «суверенний», до властивостей, які можна перевірити. Він розглядає, серед іншого, юрисдикцію, дані, операції, ланцюги, технології, безпеку та сталість.

Суверенітет пов’язаний із владою та керівництвом: хто має останнє слово та несе відповідальність? Автономія — це практична здатність діяти незалежно та використовувати альтернативи.

Організація може бути офіційно авторизованою, але мати невелику автономію, якщо вона не може технічно переключитися або якщо лише постачальник може керувати системою. Тоді суверенітет без достатнього простору для дій здебільшого залишається на папері.

Суверенітет - це повноваження приймати обов’язкові рішення та нести за них відповідальність. У цифровому середовищі головне питання полягає в тому, хто в кінцевому рахунку приймає рішення щодо даних, інфраструктури, технологій і доступу.

Це не означає, що організація повинна будувати чи керувати всім сама. Однак вона повинна вміти робити свідомий вибір, виконувати домовленості та діяти, коли обставини змінюються. Книга Суверенітет! Як? Це практичне адміністративне питання.

Рівні SEAL описують підвищення рівня суверенітету хмари. Рівень 0 — стандартна публічна хмара без додаткових заходів суверенітету; Рівень 4 означає високосуверенне середовище з явною автономією.

Рівні не є оцінкою для постачальника. Вони допомагають організації визначити відповідний поточний рівень (IST) і бажаний рівень (SOLL) для кожної програми. Таким чином, критична система може мати вищу мету, ніж загальнодоступна або легкозамінна служба.

Відкритий вихідний код може допомогти, оскільки організація може вивчати програмне забезпечення, перевіряти, налаштовувати та підтримувати іншу сторону. Таким чином, відкриті права підтримують прозорість, замінність і розвиток власних знань.

Відкритий код не є автоматичною гарантією суверенітету. Практична цінність також залежить від документації, людей, управління, фінансування, безпечних оновлень, відкритих форматів даних та інфраструктури, на якій працює програмне забезпечення.

ECSF виділяє вісім взаємопов’язаних цілей: стратегічний суверенітет; правовий і юрисдикційний суверенітет; суверенітет даних та ШІ; оперативний суверенітет; ланцюговий суверенітет; технологічний суверенітет; безпека та суверенітет відповідності; і стійкість суверенітет.

Ця класифікація запобігає помилковому використанню однієї характеристики, як-от розташування центру обробки даних, як доказу повного суверенітету. Подача може забити сильно в один гол і слабко в інший.

OciDeck підтримує інформаційний і технологічний суверенітет, дозволяючи вмісту презентації залишатися в читабельному Markdown. Відкриті формати роблять контент більш керованим, багаторазовим і переносимим, ніж коли він міститься виключно в закритому форматі програми.

Локальна обробка, офлайн-експорт HTML, цільовий обмін і функції конфіденційності можуть зменшити залежність від сторонніх служб презентації та випадкового розповсюдження. Остаточний суверенітет також залежить від зберігання, керування та вибору користувача. Докладніше на OciDeck.

OpenKAT головним чином допомагає з операційним, технологічним суверенітетом і безпекою. Він об’єднує цифрові об’єкти, зв’язки, спостереження та висновки, щоб організація могла краще розуміти та контролювати власне середовище та ризики.

Оскільки OpenKAT має відкритий вихідний код і його можна запускати самостійно, організація може контролювати його роботу та вибирати, хто керуватиме системою. OpenKAT не забезпечує повного суверенітету: ретельне управління, обсяг, захист даних, знання та подальші дії залишаються необхідними. Докладніше на OpenKAT.

Корисним підходом є: 1. процеси інвентаризації, дані та залежності; 2. визначити бажаний рівень суверенітету на систему; 3. покращити закупівлі, контракти, архітектуру, знання та альтернативи; 4. Періодично перевіряйте, чи все ще працюють заходи, і вносьте корективи.

Розглядайте це як цикл. Зміна постачальників, власності, законодавства та технологій. Тому одноразова оцінка швидко застаріває.

Правління відповідає за напрямок, схильність до ризику та прийняття залишкового ризику. Закупівлі, юридичні справи, інформаційна безпека, архітектура, конфіденційність, управління та власник процесу — кожен із них є необхідною частиною картини.

Оскільки вибір часто має довготривалі наслідки, у книзі суверенітет називається «кухарем». Тема не може обмежуватися лише технологіями чи управлінням контрактами.

Відкритий код є формою ліцензування. Творець або правовласник заздалегідь надає іншим дозвіл на використання, вивчення, копіювання, розповсюдження та адаптацію твору.

Право вносити корективи є важливим. Якщо модифікація заборонена, це не є відкритим кодом.

Ядро законне. Відкритий код стосується способу реалізації авторських прав: через ліцензію, яка надає широкі права на використання.

За цим можуть стояти технічні та соціальні ідеї, але без відповідної ліцензії щось не є відкритим кодом.

Це означає, що правовласник дає дозвіл на використання, вивчення, копіювання, розповсюдження та зміну вихідного коду через ліцензію з відкритим кодом.

Програмне забезпечення залишається захищеним авторським правом. Ліцензія визначає, які права та умови застосовуються.

Відкрите програмне забезпечення та безкоштовне програмне забезпечення стосуються прав: використання, вивчення, обміну та адаптації. Безкоштовне програмне забезпечення зазвичай означає, що щось можна використовувати безкоштовно.

Громадське надбання означає, що більше немає жодних обмежень щодо авторських прав або що власник прав відмовився від них, наскільки це можливо юридично. Це відрізняється від відкритого коду.

Ні. Відкритий код надає багато прав, але завжди в межах умов ліцензії.

Ці умови можуть, наприклад, стосуватися посилання на авторство, збереження текстів ліцензії або спільного використання змін за тією самою ліцензією.

Творець або правовласник залишається власником авторського права, якщо це право не було передано.

Відкритий код не означає, що немає власника. Це означає, що власник через ліцензію надає широкі права іншим.

так Відкритий код не виключає комерційного використання. Компанія може використовувати відкрите програмне забезпечення, продавати послуги з відкритим кодом або пропонувати програмне забезпечення з відкритим кодом.

Ціна та модель доходу відрізняються від прав на відкрите програмне забезпечення.

Відкритий код стосується прав на твір, як правило, на програмне забезпечення. Відкриті стандарти стосуються угод, специфікацій або протоколів, які можуть використовуватися багатьма сторонами.

Вони можуть підкріплювати один одного, але це різні речі.

Ліцензія з відкритим кодом — це попередній дозвіл, наданий власником прав. У ньому зазначено, що інші можуть робити з роботою та які умови застосовуються.

Без такої ліцензії звичайні авторські права продовжують застосовуватися, і повторне використання зазвичай не дозволяється.

Бо авторське право виникає автоматично. В принципі, кожен, хто створює текст, дизайн або програмне забезпечення, має на нього права.

Ліцензія чітко визначає, який дозвіл отримують інші. З відкритим вихідним кодом цей дозвіл є широким і обговорюється заздалегідь.

Тоді код стає видимим, але не вільним для використання автоматично. Видимість не є згодою.

Без ліцензії інша особа зазвичай не може копіювати, поширювати або змінювати код, за винятком обмежених юридичних винятків.

Дозвільні ліцензії надають велику свободу та зазвичай накладають обмежені умови, такі як посилання на авторство та збереження тексту ліцензії.

Ліцензії Copyleft також надають широкі права, але можуть вимагати розповсюдження похідних робіт за такою ж або подібною ліцензією.

Копілефт — це принцип ліцензування, згідно з яким свобода має бути передана. Кожен, хто поширює твір, часто в адаптованій формі, повинен надати іншим такі ж права.

Тому це не відмова від прав, а радше активний спосіб використання прав для підтримки відкритості.

Це залежить від ліцензії та того, що ви робите. Деякі ліцензії з копілефтом можуть вимагати розкриття інформації, якщо ви розповсюджуєте модифіковане програмне забезпечення.

Лише внутрішнє використання зазвичай не призводить до такого зобов’язання автоматично, але точний результат залежить від ситуації та ліцензії.

Так, багато ліцензій з відкритим кодом дозволяють комерційне використання. Це якраз і є характеристикою відкритого коду.

Однак ви повинні дотримуватися умов ліцензії. Спробуйте згадати своє ім’я, текст ліцензії чи умови розповсюдження.

Так, відкритий код повинен дозволяти налаштування. Продаж також можливий за умови дотримання умов ліцензування.

Деякі ліцензії вимагають надання або надання доступу до зміненого вихідного коду під час розповсюдження зміненої роботи.

Це способи зберегти вихідного творця та ліцензію видимими. Атрибуція зазвичай означає атрибуцію. Файл повідомлень містить правові повідомлення. Заголовок ліцензії часто знаходиться у верхній частині файлу.

Ці зобов’язання гарантують, що права та походження залишаються впізнаваними.

Патентне положення гарантує, що користувачі також отримають дозвіл на відповідні патенти від учасників за певних умов.

Це може бути важливо, оскільки на програмне забезпечення можуть впливати не лише авторські, а іноді й патентні права.

Основний ризик полягає в недотриманні ліцензійних умов. Тоді ви можете використовувати твір без дійсного дозволу.

Це може призвести до зобов’язань щодо ремонту, судових позовів, шкоди репутації або проблем із продажем, тендером чи аудитом.

Відповідність відкритому коду означає, що організація знає, який відкритий код вона використовує, які ліцензії на нього надаються та які зобов’язання застосовуються.

В основному це звичайне юридичне та організаційне управління: реєстрація, перевірка, дотримання вимог і можливість пояснити, що було використано.

Ні, не через відкритий код. Безпека залежить від проектування, обслуговування, контролю, використання та моніторингу вразливостей.

Відкритість забезпечує контроль, але не є автоматичною гарантією безпеки.

Ні. Часто кожен може робити пропозиції, але це не означає, що кожен може просто вносити зміни.

Для серйозних проектів адміністратори оцінюють, які внески включені. Надійність залежить від управління та обслуговування, а не лише від типу ліцензії.

Ні. Підтримка може бути добровільною, спільною або комерційною. Багато компаній надають платну підтримку відкритого коду.

Ліцензія визначає права на твір; підтримка є окремою послугою.

Ні. Відкритий код стосується прав на використання, а не ціни.

Продукт із відкритим кодом може бути безкоштовним для завантаження, але підтримка, хостинг, сертифікація, навчання або налаштування можуть бути платними.

Ні. Ціна безкоштовна. Безкоштовність — це права.

Безкоштовний продукт може бути строго закритим. Продукт із відкритим кодом надає права на використання, вивчення, спільний доступ і зміну.

Ні. Відкритий код можуть створювати волонтери, а також компанії, уряди, університети та фонди.

У ліцензії нічого не сказано про професіоналізм. Ви повинні оцінити це на основі якості, управління та контексту.

Ні. Відкритий вихідний код може бути дуже професійним, а комерційне програмне забезпечення може погано підтримуватися. Можливий і зворотний шлях.

Професіоналізм очевидний з обслуговування, документації, управління, якості та угод, а не лише з відкритих чи закритих ліцензій.

Відкритість означає, що кожен може дивитися, включно з зловмисниками. Але це також означає, що можливий контроль з боку користувачів, дослідників і постачальників.

Безпека походить не лише від секретності. Він вимагає обслуговування, реагування та дбайливого використання.

Ні. Законні права актуальні для всіх: користувачів, адміністраторів, покупців, юристів, аудиторів і політиків.

Розробники часто працюють із кодом, але організації також виграють від прозорості, свободи вибору та можливості перевірки.

Це може бути компромісом, але це автоматично не є недоліком. Відкритий код — це свідоме визначення, якими частинами ви хочете поділитися та за яких умов.

Іноді відкритий обмін є стратегічно корисним, наприклад, для сприяння співпраці, довіри чи стандартизації.

Це залежить від проекту. Контроль може надходити від супроводжувачів, користувачів, дослідників безпеки, аудитів, автоматичного сканування та організацій, які розгортають програмне забезпечення.

Відкритий код робить такий контроль можливим, але не організовує його сам по собі.

Це залежить від ситуації. Адміністратори проекту можуть створити оновлення, але користувач або організація також повинні застосувати це оновлення.

Відкритий код не змінює того факту, що кожен, хто використовує програмне забезпечення, несе відповідальність за ретельне керування.

Це дуже різниться. Активні проекти можуть швидко реагувати; не кидайте проекти. Те ж саме стосується і закритого програмного забезпечення.

Тому дивіться не лише на ліцензію, а й на технічне обслуговування, процес звітування та практику випуску.

Supply chain risks arise when you are dependent on parts from others. Якщо така частина є вразливою, зловмисною або погано обслуговується, це може мати наслідки для вашого продукту.

Цей ризик не є винятковим для відкритого коду, але відкритий код часто робить залежності більш помітними.

Залежності — це частини, на яких базується продукт. У програмному забезпеченні це часто бібліотеки або пакунки від інших.

Вони важливі, оскільки права, уразливості та обслуговування цих частин також впливають на ваше власне використання.

Подивіться на ліцензію, технічне обслуговування, документацію, як переглядаються зміни та як обробляються сповіщення безпеки.

Надійність – це поєднання юридичної ясності, якості та управління.

Здорові сигнали — це чітка інформація про ліцензування, останні оновлення, зрозуміла документація, активний процес звітування та видиме прийняття рішень.

Це також допомагає, якщо кілька людей або організацій роблять внесок, щоб проект не повністю залежав від однієї людини.

Шукайте старі випуски, сповіщення без відповіді, відсутню інформацію про ліцензування, незрозумілих супроводжувачів або відсутність відповіді на проблеми безпеки.

Це проектні ризики. Вони трапляються у відкритому та закритому програмному забезпеченні, але у відкритому коді вони часто більш помітні.

Під час аудиту безпеки хтось спеціально оцінює наявність вразливостей або слабких місць. З відкритим вихідним кодом вихідний код можна перевірити безпосередньо.

Аудит – це моментальний знімок. Технічне обслуговування та подальше обслуговування будуть необхідними.

SBOM — це опис матеріалів програмного забезпечення: огляд використовуваних компонентів програмного забезпечення.

Такий огляд допомагає керувати ліцензіями, уразливими місцями та залежностями. Це особливо корисно для організацій, яким потрібно вміти пояснити, що вони використовують.

Проект із відкритим кодом створюється, коли правовласник публікує роботу за ліцензією з відкритим кодом. Це часто включає документацію, місце для внесків і спосіб прийняття рішень.

Ліцензія є правовою основою; спільнота та метод роботи визначають, як проект продовжує розвиватися.

Зазвичай це роблять супроводжувачі або адміністратори проекту. Вони оцінюють, чи внесок відповідає якості, напрямку та угодам проекту.

Відкритий код не означає, що кожна зміна автоматично стає частиною офіційного проекту.

Супроводжувач - це той, хто керує проектом. Ця особа або група переглядає внески, робить випуски, контролює напрямки та підтримує документацію чи процеси.

У відкритому коді ця роль важлива, оскільки права широкі, але співпраця все одно вимагає організації.

Контрибутор — це той, хто робить внесок у проект. Це може бути код, а також проблеми з документацією, перекладом, тестуванням, проектуванням, поясненнями чи звітами.

Тому внески з відкритим кодом є ширшими, ніж програмування.

Форк — це ваша власна копія проекту, над якою хтось може продовжувати працювати самостійно. Це можливо, оскільки відкритий код дозволяє модифікувати та розповсюджувати.

Іноді вдосконалення пізніше відображається в оригінальному проекті. Іноді розвилка росте у свій бік.

Це пропозиція внести зміни до проекту. Адміністратор може переглядати, обговорювати, коригувати або відхиляти зміни.

Це практичний спосіб організації співпраці навколо відкритого коду.

Управління спільнотою стосується угод, за якими проект приймає рішення. Розгляньте, хто може брати участь у прийнятті рішень, як вирішуються конфлікти та як призначаються нові адміністратори.

Ліцензія дає права; управління регулює співпрацю.

У проектах, керованих громадою, контроль лежить переважно на спільноті учасників. У проектах, керованих компанією, компанія часто відіграє головну чи вирішальну роль.

Обидві форми можуть добре працювати, якщо ясно, хто вирішує і за яких умов.

Це залежить від уряду. Деякі проекти мають чіткі правила прийняття рішень, кодекси поведінки або основи. Інші проекти більш неформальні.

Хороші угоди важливі, оскільки відкриті права не означають автоматично, що всі погоджуються.

Проекти припиняються, коли у супроводжувачів закінчується час, бракує фінансування, зникає потреба або з’являється краще рішення.

Це не є унікальним для відкритого коду. Різниця полягає в тому, що з відкритим вихідним кодом інші іноді можуть продовжувати розгалуження.

Компанії не обов’язково заробляють гроші виключно на продажу коду, а на послугах, які його оточують. Розгляньте хостинг, підтримку, впровадження, керування, навчання, сертифікацію або налаштування.

Відкрита ліцензія та бізнес-модель — це два різні рівні.

Загальні моделі включають платну підтримку, керований хостинг, консультації, сертифікацію, навчання, подвійне ліцензування та відкрите ядро.

Відправною точкою часто є: основні права відкриті, але зручність, безпека чи додаткові послуги можуть бути платними.

Відкрите ядро ​​означає, що ядро ​​продукту має відкритий вихідний код, а деякі додаткові функції закриті або платні.

Це може спрацювати, але для цього потрібна чітка комунікація. Користувачі повинні знати, яка частина відкрита, а яка ні.

Подвійне ліцензування означає, що одна і та сама робота доступна за двома різними ліцензіями. Наприклад, ліцензія з відкритим кодом і комерційна ліцензія.

Це може надати організаціям вибір, але це можливо лише за умови, що власник прав має право пропонувати обидві ліцензії.

Керований хостинг або SaaS означає, що хтось пропонує програмне забезпечення з відкритим кодом як послугу. Тоді користувачеві не доведеться самостійно встановлювати програмне забезпечення та керувати ним.

Програмне забезпечення може бути з відкритим вихідним кодом, а сервіс, що його оточує, платний.

Компанії можуть зробити це, щоб підвищити довіру, стимулювати співпрацю, встановити стандарт або прискорити впровадження.

Відкритий код також може допомогти зменшити залежність від одного постачальника та побудувати екосистему.

Тому що іншим дозволено будувати існуючу роботу. Їм не потрібно починати спочатку, і вони можуть поділитися вдосконаленнями.

Ліцензія робить таку співпрацю легально можливою.

Відкритий код може зменшити залежність від одного постачальника, оскільки користувачі мають право вивчати програмне забезпечення, змінювати його та керувати ним в іншому місці.

Це не означає, що перехід завжди легкий, але правова база менш закрита.

Відкритий код цікавий, коли важливі співпраця, прозорість, можливість перевірки, повторне використання чи незалежність.

Він особливо сильний у спільній інфраструктурі, суспільних цінностях і ситуаціях, коли довіра вимагає більше, ніж обіцянка постачальника.

Відкритий код менш підходить, коли правовласник хоче обмежити розповсюдження, доступ або модифікацію. Це стратегічний вибір контролю.

Це також менш прийнятно, якщо організація хоче надати права, не будучи готовою чітко зафіксувати умови ліцензування та управління.

Стартапи можуть швидше розвивати існуючі компоненти та легше завоювати довіру завдяки відкритості. Вони також можуть розвивати спільноту чи ринок навколо відкритого проекту.

Вони повинні знати про ліцензування, позиціонування та свою модель доходу.

Для урядів відкритий код може сприяти прозорості, можливості перевірки, повторному використанню та меншій залежності від одного постачальника.

Це добре поєднується з громадською підзвітністю за умови належного управління, безпеки та дотримання законодавства.

Навчання може використовувати відкритий вихідний код, щоб вчитися на реальних прикладах, ділитися матеріалами та дозволяти студентам робити внески в існуючі проекти.

Оскільки коригування дозволено, навчальні матеріали або програмне забезпечення можна краще узгодити з освітньою практикою.

Відкритий код може допомогти, оскільки організації не повністю залежать від закритих знань або одного постачальника. Вони можуть перевірити, як щось працює, і відрегулювати.

Суверенітет вимагає не лише відкритого коду, але відкриті права є важливим будівельним блоком.

Відкритий вихідний код показує, за яких умов можна використовувати твір, і, у випадку програмного забезпечення, як виглядає вихідний код.

Це полегшує контроль і пояснення. Прозорість справді виникає лише тоді, коли документація та управління також зрозумілі.

Оскільки іншим дозволено використовувати та адаптувати існуючу роботу, не кожен має відтворювати те саме.

Це може зменшити відходи та розділити технічне обслуговування, особливо коли кілька сторін мають однакову проблему.

Відкритий вихідний код показує, як працює організація, до якої якості вона прагне та за що виступає. Люди можуть легко зробити внесок або дізнатися, що відбувається.

Це може бути привабливим для професіоналів, які цінують відкритість і майстерність.

Конкуренти можуть співпрацювати над частинами, які потрібні всім, при цьому ці частини не повинні бути продуктом, що розрізняє їх.

Ліцензія заздалегідь визначає права, тому співпраця менше залежить від окремих угод.

Громадська інфраструктура потребує довіри, безперервності та можливості перевірки. Відкритий код може допомогти, оскільки основа не повністю закрита.

Це робить незалежний контроль і спільне обслуговування більш можливим.

У цих сферах відкритий вихідний код може сприяти перевірці, повторному використанню та незалежним дослідженням.

У той же час належне управління, управління даними, безпека та юридична оцінка залишаються необхідними. Відкритий код є основною вимогою для певних форм контролю, а не повним рішенням.

Почніть з ліцензії: чи дозволено використання, яке ви маєте на увазі? Потім подивіться на обслуговування, документацію, якість і залежності.

Популярний пакет автоматично не підходить. Вибір має відповідати меті, ризику та менеджменту.

Перевірте ліцензію, походження, стан обслуговування, уразливості та необхідність. Також запитайте, чи дійсно деталь потрібна.

Кожна залежність додає права, обов’язки та управління.

Записуйте, які компоненти використовуються, яку версію, яку ліцензію та до складу якого входить компонент.

Також переконайтеся, що чітко визначено, хто відповідає за оновлення та дотримання умов.

Використовуйте комбінацію інструментів реєстрації, періодичної перевірки та сканування залежностей.

Найголовніше: домовтеся про те, хто переглядатиме сповіщення, а хто вирішуватиме оновлення чи заміну.

Існує багато інструментів, які відображають залежності, ліцензії та вразливості. Приклади включають сканери в платформах розробки, менеджери пакетів і спеціалізовані інструменти відповідності.

Інструмент є лише інструментом. Організація ще має зробити вибір і організувати подальші дії.

Спочатку прочитайте інструкції щодо внесення та ліцензію. Чітко опишіть, що ви хочете покращити і чому.

Хорошим внеском може бути код, а також документація, тестування, переклад або чітко описана проблема.

Це має сенс, якщо ви хочете, щоб інші могли використовувати, контролювати, ділитися та змінювати роботу.

Зробіть цей вибір свідомо: визначте мету, ліцензію, технічне обслуговування, управління та те, що ви робите чи не очікуєте від внесків.

Спочатку вирішіть, що ви хочете дозволити та захистити. Якщо ви бажаєте багаторазового використання, зверніть увагу на дозвільні ліцензії. Якщо ви хочете, щоб свобода передавалася, подивіться на копілефт.

Бажано використовувати існуючі відомі ліцензії замість того, щоб писати текст самостійно.

Надайте чітку документацію, доброзичливий спосіб ставити запитання, чітке прийняття рішень і реалістичні очікування.

Спільнота не створюється просто розміщенням коду в мережі. Він вимагає уваги, довіри та догляду.

Розподіліть права та обов’язки. Документуйте процеси, робіть випуски переносними та надайте багатьом довіреним особам права керування.

Це підвищує безперервність і робить проект менш вразливим.

Офіс програми з відкритим кодом, який часто називають OSPO, — це команда або функція, яка організовує використання відкритого коду та внески в організації.

Це допомагає з політиками, ліцензуванням, співпрацею, спільнотами та відповідальною публікацією.

Потрібні як мінімум політики для використання, внеску, публікації, контролю ліцензій і відстеження безпеки.

Політика має бути практичною: люди мають знати, що дозволено, коли звертатися за порадою та хто вирішує.

Поясніть простою мовою, що означають авторські права, ліцензії та зобов’язання. Використовуйте приклади з власних робіт.

Навчання має бути не лише правовим, а й практичним: що реєструєш, що перевіряєш і куди звертаєшся по допомогу?

Все, в залежності від вибору. Юридичний погляд на права та обов’язки. Безпека розглядає вразливі місця та керування. Інженерія дивиться на якість і застосування. Відділ закупівель розглядає контракти та постачальників.

Відкритий код часто впливає на декілька обов’язків одночасно.

Переконайтеся, що ясно, які частини використовувалися, які ліцензії застосовуються, які перевірки були проведені та які рішення були прийняті.

Аудит в основному означає: можливість пояснити потім, що сталося і чому.

Свідомо включайте відкритий код у вимоги, критерії оцінки та умови контракту. Не просто запитуйте про продукт, а й про права, переносимість і керування.

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

Розглядайте підтримку як додаток до прав на відкритий код. Договір може містити домовленості щодо часу відповіді, оновлень, відповідальності, хостингу або управління.

Програмне забезпечення може бути відкритим, а підтримка професійна і платна.

Не дивіться лише на вартість ліцензування. Також включає управління, підтримку, навчання, інтеграцію, міграцію, відповідність і обслуговування.

Відкритий код може бути дешевшим, але справжня цінність часто полягає в контролі, гнучкості та меншій залежності.

Ставтеся до відкритого коду як до частини звичайного управління ризиками. Подивіться на ліцензування, обслуговування, безпеку, залежності та безперервність.

Ризик полягає не в тому, що щось відкрито, а в тому, що використання відбувається несвідомо або без нагляду.

Не просто вимірюйте заощаджені витрати. Також подивіться на повторне використання, швидкість, прозорість, уникнення залежності, співпрацю та якість контролю.

Одна цінність – фінансова, інша – в автономії та довірі.

Ні. Відкритий код надає важливі свободи, але автоматично нічого не говорить про всі етичні рішення щодо використання, впливу чи управління.

Відкритість може сприяти обговоренню, контролю та підзвітності.

Не повністю. Ліцензії з відкритим кодом дозволяють широко використовувати та зазвичай не обмежують, для чого хтось використовує роботу.

Будь-хто, хто хоче швидко обмежити зловживання, виходить за межі класичного відкритого коду та має думати про інші правові чи організаційні засоби.

Класичні ліцензії з відкритим кодом не обмежують цілі використання. Вони дають права всім, навіть якщо творець вважає деякі програми небажаними.

Існують ліцензії з етичними обмеженнями використання, але вони, як правило, не вважаються відкритим кодом у строгому сенсі.

Відкритий код дає іншим можливість контролювати власне використання: вони можуть вивчати, адаптувати та ділитися. Тому оригінальний творець відмовляється від певного ексклюзивного контролю над розповсюдженням і модифікацією.

Це не помилка, а саме той вибір, який робить відкритий код особливим.

Відкритий код може підтримувати такі суспільні цінності, як прозорість, можливість перевірки, повторне використання та незалежність.

Але суспільні цінності також вимагають належного управління, доступності, безпеки, фінансування та відповідальності.

Це дуже різниться залежно від проекту. Деякі спільноти відкриті та корисні, інші важкодоступні або залежать від неформальних мереж.

Інклюзія вимагає активної уваги до мови, поведінки, документації, прийняття рішень і безпечної участі.

Це важливе питання. Значна частина цифрової інфраструктури широко використовується, але не завжди широко фінансується.

Відкритий вихідний код робить можливим використання, але обслуговування вимагає часу, грошей і відповідальності сторін, які від нього залежать.

Відкритий код може поширювати потужність, оскільки користувачі мають більше прав, ніж просто купувати те, що пропонує постачальник. Вони можуть перевірити, налаштувати або переключити його.

Це зміцнює автономію, але лише за наявності знань, спроможності та управління для використання цих прав.

Complete prevention is usually not possible within classic open source. Однак проекти можуть обрати відповідні ліцензії, управління, комерційні угоди та культуру, у якій внески є нормальними.

Користувачі також можуть взяти на себе відповідальність, повернувши технічне обслуговування, гроші або знання.

Відкритий код залишається важливим для цифрової інфраструктури, уряду, освіти, хмари, ШІ та безпеки. Основа залишається законною: надання прав на використання, вивчення, обмін та адаптацію.

Великим викликом є ​​стале управління: забезпечення того, щоб відкриті проекти не тільки використовувалися, але й підтримувалися та відповідально керувалися.

MIAUW розшифровується як методологія дослідження інформаційної безпеки з аудитом. Це спосіб проведення дослідження безпеки, наприклад тесту пера, у структурований спосіб, який можна перевірити.

Мета полягає в тому, щоб організація не тільки отримала звіт, але й могла краще продемонструвати, що було досліджено, як це було зроблено та які висновки з цього випливають.

Докладніше на MIAUW.

Багато розслідувань безпеки дають корисні висновки, але їх важко оцінити згодом. Іноді незрозуміло, що саме входило в сферу дії, які кроки було виконано або які докази підтверджують висновок.

MIAUW допомагає краще фіксувати ці компоненти до та під час дослідження. Це робить дослідження більш корисним для відновлення, підзвітності та аудиту.

Докладніше на MIAUW та Що означає аудиторська вартість?.

Ні. Перевірка — це форма дослідження безпеки. MIAUW — це методологія, яка дозволяє краще структурувати, записувати та робити такі дослідження більш контрольованими.

Таким чином, перо-випробування можна проводити відповідно до MIAUW, але MIAUW є ширшим, ніж просто проведення технічних тестів.

Також прочитайте Що таке проба пера? та MIAUW.

Цінність аудиту означає, що розслідування може бути належним чином оцінено згодом. Аудитор або інший оцінювач повинен мати можливість побачити, що було узгоджено, що перевірено, які є докази та як були зроблені висновки.

Це робить розслідування корисним не лише для технологій, але й для управління, відповідності та підзвітності.

Докладніше читайте на MIAUW та Що таке аудиторський висновок в MIAUW?.

MIAUW призначений для клієнтів, тестувальників на проникнення, аудиторів, спеціалістів із комплаєнсу та директорів.

Клієнт отримує більше контролю над дослідженням. Дослідник отримує чітку структуру. Аудитор отримує більше інформації, яку можна перевірити. Керівники отримують більше впевненості щодо того, що звіт містить, а що ні.

Докладніше на MIAUW.

Ні. Жодна методологія не може гарантувати, що система безпечна.

MIAUW дійсно допомагає краще проводити дослідження безпеки, краще документувати їх і краще використовувати для вдосконалення. Таким чином, це підвищує якість і корисність досліджень, але не замінює ефективне управління безпекою.

Читайте також Що є центральним у дослідженні MIAUW?.

Основна увага приділяється чітким угодам, чіткому охопленню, імітованим доказам, відтворюваним результатам і звітності, корисній для різних цільових груп.

Технічна команда потребує деталей для вирішення проблем. Керівництво хоче знати, що означає ризик. Аудитор хоче мати можливість оцінити, чи ретельно було проведено розслідування.

Докладніше на MIAUW.

Обсяг означає: що є і що не є частиною дослідження. Подумайте про системи, домени, програми, облікові записи, мережі, періоди та питання дослідження.

Чітка сфера запобігає непорозумінням. Без прицілу важко потім сказати, чи було щось навмисно упущено з поля зору, чи випадково не розглянуто.

Дивіться також Як OpenKAT керує областю та дозволами?.

Докази роблять висновки перевіреними. У звіті має бути не тільки сказано, що щось не так, але й показано, на чому ґрунтується такий висновок.

Докази можуть включати журнали, знімки екрана, результати команд, дані конфігурації або інші записи. Природно, з конфіденційною інформацією потрібно поводитися обережно.

Читайте також Що означає безпека, заснована на доказах?.

Висновок – це виявлена ​​проблема, ризик або об’єкт, що привернув увагу дослідження.

Хороший висновок описує те, що було знайдено, чому це важливо, які докази залучено, який вплив може бути та який захід допомагає зменшити або вирішити проблему.

Читайте також Яка різниця між ризиком і вразливістю?.

Вразливість – слабке місце. Ризик полягає в тому, що ця слабкість може означати для організації.

Уразливість у тестовій системі без конфіденційних даних часто має інший ризик, ніж та сама вразливість у загальнодоступній системі з персональними даними. Тому контекст важливий.

Читайте також Що таке знахідка?.

Ні. Великі організації часто мають більш офіційні вимоги до аудиту та відповідності, але менші організації також виграють від чітких угод, кращих доказів і корисної звітності.

MIAUW насправді може допомогти зробити дослідження безпеки більш зрозумілими та доступними для передачі.

Докладніше на MIAUW.

Заява аудитора може допомогти продемонструвати, що розслідування було проведено відповідно до домовленостей, без необхідності широкого розголошення всіх технічних деталей.

Це корисно, коли повний звіт є надто чутливим для широкого розповсюдження, але організація повинна продемонструвати, що було проведено серйозне дослідження, яке можна перевірити.

Читайте також Якщо я роблю пентест за допомогою MIAUW, чи повинен я оприлюднювати його?.

Перо-тест, або повністю тест на проникнення, є контрольованим дослідженням безпеки. Дослідники намагаються знайти вразливі місця раніше, ніж це зроблять зловмисники.

Проба пера – це не випадкова атака. Є домовленості щодо обсягу, дозволу, підходу, звітності та належної уваги. Дослідники використовують методи, які також можуть використовувати зловмисники, але з метою покращення безпеки.

У Методології дослідження інформаційної безпеки з аудиторським значенням (MIAUW) ми детально обговорили визначення, запропоноване паном В.А. Пуз. Це призвело до такого визначення:

“Наступальне розслідування безпеки, яке має проводитися нашим власним персоналом або третіми сторонами, яке передбачає контрольований пошук уразливостей в одній або кількох захищених мережевих та інформаційних системах або їх частинах, які можуть бути використані для злому в ці системи та/або які можуть, ненавмисно чи автономно, порушити обробку даних досліджуваної організації або іншим чином мати несприятливі наслідки.”

Читайте також Що таке MIAUW?.

Ні, це не потрібно. Мета MIAUW – поставити клієнта на перше місце. Якщо ви платите за звіт, це означає, що ви контролюєте продукт, який купуєте. Тому MIAUW дещо говорить про постачальника: він не може накладати на клієнта обмеження на розповсюдження. Це описано так:

На клієнта не накладається жодних обмежень щодо розповсюдження, публікації чи зберігання звіту та відповідних документів. Сюди не входять фінансові дані, пов’язані з проведенням дослідження, такі як погодинна ставка, ціни та рахунки-фактури.

Більша мета полягає в тому, щоб за допомогою проби пера ви також могли продемонструвати, що важливі справи були правильно організовані. Це складно, якщо вам заборонено показувати або надавати дослідження іншим. Фінансову інформацію про дослідження не потрібно поширювати, оскільки вона нічого не говорить про стан безпеки.

Чи забагато конфіденційної інформації у звіті, щоб поширювати її широко? Тоді може допомогти аудиторський звіт. Це дозволяє продемонструвати, що дослідження було проведено та який був основний результат, не розповсюджуючи всі технічні деталі.

Коротше кажучи: клієнт визначає, яким рівнем інформації ділиться з партнерами, регуляторами чи іншими особами, без перешкод з боку постачальника.

Читайте також Що таке аудиторський висновок в MIAUW?.

CVSS 4.0 надає відкритий, нейтральний до постачальника метод для визначення технічних характеристик і серйозності вразливості. Вектор також показує, які значення та припущення призвели до оцінки. Це робить оцінку легшою для перенесення та перевірки, ніж просто позначку «висока» або «критична».

MIAUW використовує цю загальну мову вимірювання, щоб повідомити про серйозність і обґрунтування результатів у імітаційний спосіб. MIAUW не визначає автоматично, чи застосовується вразливість, і не призначає рішення щодо відновлення. Відповідно до офіційна специфікація FIRST, CVSS є вхідними даними для аналізу ризиків, а не повним аналізом ризиків.

Ні. CVSS описує технічну серйозність уразливості. Організаційний ризик також включає, наприклад, ймовірність неправильного використання, цінність і функції системи, постраждалих осіб, юридичні зобов’язання, можливу шкоду та існуючі заходи контролю.

Тому FIRST називає CVSS вхідними даними для аналізу ризиків. Такі фактори, як фінансова шкода, репутаційна шкода, кількість постраждалих клієнтів і юридичні вимоги, охоплюються явно за межами CVSS. Організація зважує ці фактори у власному управлінні ризиками.

так CVSS 4.0 явно включає контекст. Показники загрози описують поточну зрілість зловживання. Екологічні показники обробляють конкретне середовище розгортання, включаючи існуючі заходи безпеки, фактичну доступність, необхідну важливість конфіденційності, цілісності та доступності, змінені технічні характеристики та можливі наслідки для безпеки людей.

Додаткові показники додають додатковий контекст, наприклад безпеку, відновлення, автоматизацію та зусилля з відновлення. Вони не змінюють номер CVSS, але згідно з Поширені запитання про CVSS 4.0 від FIRST можуть впливати на локальний пріоритет.

Публічно опублікований CVSS-B зазвичай містить лише базові показники. Це не те ж саме, що сказати, що CVSS не має контексту: клієнт заповнює показники загрози та навколишнього середовища для своєї власної ситуації й, таким чином, отримує CVSS-BTE. FIRST рекомендує це збагачення для більш значимого результату у вашому власному середовищі.

Основна технічна оцінка може бути однаковою, але місцева оцінка CVSS-BTE необов’язково. Ізольоване тестове середовище, внутрішня робоча станція, публічна служба ідентифікації та критично важливий для безпеки пристрій можуть відрізнятися за доступністю, заходами, необхідним захистом і наслідками для інших систем або людей.

CVSS 4.0 може фіксувати такі відмінності за допомогою показників загрози та середовища. Безпека людини також може безпосередньо вплинути на оцінку показників навколишнього середовища. Додатковий контекст також може вплинути на локальний рейтинг без зміни числа. Внутрішня система не отримує автоматично нижчий бал: кожне коригування має відповідати демонстрованим властивостям фактичного середовища. Перегляньте групи показників і правила оцінювання FIRST.

так Звертання сканера чи відповідний номер версії не доводять, що вразливий код присутній, доступний або виконуваний. Тому спочатку перевірте використовуваний компонент і версію, конфігурацію, маршрут виклику та будь-які заходи. Дослідження вихідного коду, SBOM, VEX, аналіз конфігурації та динамічне тестування можуть надати відповідні докази цього.

Якщо видається, що продукт не зазнає впливу, задокументуйте цю незастосовність доказами. Не призначайте штучно низьку оцінку CVSS уразливості, яка не застосовується. FIRST також описує в поширені запитання щодо CVSS 4.0, що постачальник повинен повторно оцінити оцінку для конкретного продукту та може використовувати VEX для повідомлення про застосовність.

Уніфікований метод дає постачальникам, дослідникам і покупцям однакові концепції та машиночитаний вектор. Це дозволяє їм обмінюватися оцінками, перевіряти припущення та уточнювати оцінку для свого середовища. Дослідження даних про вразливості показує, що непослідовні оцінки серйозності можуть значно знизити якість подальшого визначення пріоритетів (Крофт, Бабар і Лі, 2022).

Ця перевага не означає, що кожна організація повинна використовувати однакову послідовність відновлення. Значуща угода така: стандартизуйте мірило, а не рішення. Локальні загрози, контекст системи, політика та прийняття ризику залишаються вирішальними.

Не в сенсі емпіричної моделі, яка передбачає ймовірність зловживання чи очікувану шкоду. CVSS — це стандартизована угода про вимірювання, заснована на технічних визначеннях і експертних думках. Для версії 4.0 мільйони можливих векторів були згруповані та ранжовані експертами; ПЕРШИЙ публікує цей метод у посібнику користувача.

Є тестування, але воно обмежене. NIST перевірив формулу CVSS 3 проти відгуків дизайнерів. Це підтримує внутрішню роботу цієї формули, а не передбачення інцидентів чи збитків і не автоматичну версію 4.0. Дослідження також виявляють відмінності між людьми, які оцінюють. Тому CVSS корисний як прозорий, спільний метод вимірювання, а не як наукова впевненість.

Ні. Високий бал CVSS означає, що технічні наслідки та умови є серйозними відповідно до вибраного вектора. Немає відкаліброваної ймовірності того, що вразливість буде використана протягом певного періоду часу. Дослідження показують, що визначення пріоритетів виключно за пороговими значеннями CVSS може бути неефективним (Якобс та ін., 2020).

CVSS 4.0 може включати поточну зрілість експлойту в показники загрози. Наприклад, EPSS можна використовувати для оцінки ймовірності; підтверджені атаки та конфіденційна інформація про загрози також актуальні. Ці джерела також не замінюють місцеву оцінку ризику.

Ні. Політика визначає, серед іншого, схильність до ризику, класи системи, терміни, винятки, відповідальних осіб та умови прийняття ризику. CVSS може послідовно фіксувати технічну серйозність, поточну загрозу та фактори навколишнього середовища, але не приймає адміністративне рішення.

Під час обробки ризиків організація поєднує цю інформацію з застосовністю, впливом на бізнес, безпекою, конфіденційністю, юридичними зобов’язаннями та наявними заходами. Потім вона вирішує, наприклад, відновити, обмежити, уникнути, передати або прийняти із зазначенням причин. Оцінка та вектор є доказами цього рішення; вони не замінюють політику, рішення чи викладене обґрунтування.

Корисний порядок:

1. переконайтеся, що вразливість стосується продукту;
2. перевірте базову оцінку CVSS і вектор для цього продукту;
3. додати поточну інформацію про загрозу та фактичні фактори середовища;
4. включати додатковий контекст, такий як безпека, можливість відновлення та юридичні зобов’язання;
5. застосовувати власну політику щодо пріоритету, лікування та прийняття ризику;
6. записати рішення та обґрунтування.

Це не створює список автоматичного ремонту, а рішення, яке можна виконати. FIRST рекомендує використовувати показники загрози та середовища для більш значущого результату та називає результат вхід для вашої власної вразливості та обробки ризиків.

OpenKAT — це відкритий інструмент аналізу вразливостей. Це програмне забезпечення з відкритим вихідним кодом, яке допомагає організаціям скласти карту свого цифрового ландшафту та зробити видимими вразливості, неправильні налаштування та ризики.

OpenKAT — це розуміння: що ми маємо, що видимо, що змінюється і з чим нам потрібно щось робити?

Докладніше на OpenKAT.

OpenKAT допомагає краще зрозуміти вашу цифрову зовнішність і всередині. Він збирає інформацію про системи, домени, програмне забезпечення та налаштування та перетворює її на корисну інформацію.

Зрозумілою мовою: OpenKAT допомагає побачити, де розташовані цифрові двері, вікна та замки та які з них потребують уваги.

Докладніше на OpenKAT.

Поверхня атаки – це все, що зловмисник може спробувати використати, щоб отримати доступ або завдати шкоди.

Подумайте про веб-сайти, поштові сервери, хмарні середовища, API, VPN, старі домени, забуті тестові середовища та неправильно налаштовані служби. Чим краще ви знаєте цю поверхню, тим точніший захист ви можете забезпечити.

Читайте також Чому важливе постійне розуміння?.

Цифрове середовище постійно змінюється. Додаються системи, оновлюється програмне забезпечення, змінюються налаштування та виявляються нові вразливості.

Таким чином, одноразове сканування є знімком. Постійне розуміння допомагає помітити зміни та швидше реагувати, коли щось погіршується або знову стає вразливим.

Читайте також Чи може OpenKAT показувати зміни з часом?.

Ні. OpenKAT і тестування пера доповнюють одне одного.

OpenKAT забезпечує постійну технічну інформацію та може збирати багато сигналів. Проба пера – це цілеспрямоване дослідження людей із контекстом, креативністю та глибиною. OpenKAT може допомогти краще націлити тести на перо та краще відстежувати результати.

Також прочитайте Що таке проба пера? та OpenKAT.

Ні. Жоден продукт безпеки не знаходить усе автоматично.

OpenKAT допомагає зібрати та оцінити багато інформації структурованим способом. Але хороший обсяг, інтерпретація, управління та подальші дії залишаються необхідними. Людський контекст залишається важливим.

Читайте також Як OpenKAT допомагає визначати пріоритети?.

У OpenKAT шахрай – це невелике дослідницьке завдання або сканер, який збирає певну інформацію. Наприклад, він може перевірити щось про DNS, TLS, версії програмного забезпечення чи інші технічні властивості.

Ідея є модульною: багато невеликих завдань разом створюють більш повну картину цифрового середовища.

Читайте також Що таке нормалізація в OpenKAT?.

Знахідка - це сигнал, який вимагає уваги. Це може бути вразливість, а також неправильне налаштування, відсутність заходів безпеки або відхилення від політики.

Знахідка не завжди відразу є інцидентом. Це насамперед привід оцінити, що це означає та які подальші дії потрібні.

Читайте також Як OpenKAT допомагає визначити пріоритети?.

Безпека, що ґрунтується на доказах, означає, що висновки ґрунтуються на записаних даних, а не лише на почуттях чи вільних припущеннях.

OpenKAT допомагає, зберігаючи спостереження та пов’язуючи їх із висновками. Так легше побачити, на чому базується висновок і як ситуація змінюється з часом.

Читайте також Чому докази важливі для MIAUW?.

Відповідність – це демонстрація дотримання правил, стандартів або угод. OpenKAT може пов’язувати технічні спостереження з правилами чи стандартами.

Це робить більш зрозумілим, які технічні висновки також мають адміністративне або юридичне значення. Це допомагає з перевірками, звітністю та визначенням пріоритетів.

Читайте також Чи може OpenKAT допомогти з NIS2?.

Ні. Фахівцям із безпеки потрібні технічні деталі, але OpenKAT також корисний для адміністраторів, аудиторів, команд із відповідності та директорів.

Кожна роль по-різному дивиться на ту саму реальність: технічні деталі для вирішення, огляди для керування та докази підзвітності.

Докладніше на OpenKAT.

так OpenKAT має відкритий вихідний код і його можна використовувати самостійно. Це вимагає технічних знань, управління та ретельного проектування.

Тому деякі організації обирають самоуправління. Інші організації вважають за краще працювати з партнером для розміщення, проектування, управління або підтримки.

Дивіться також Партнери і OpenKAT.

OpenKAT є інструментом безпеки, і ним слід користуватися обережно. Сканування виконується лише в узгодженому обсязі та з дозволу.

Результати можуть бути делікатними, оскільки вони говорять щось про вразливі місця та інститути. Тому добре захищайте цю інформацію та надавайте доступ лише тим людям, яким ця інформація потрібна.

Читайте також Як OpenKAT працює з конфіденційністю?.

OpenKAT працює з об’єктами, які можна перевірити. Це може бути, наприклад, доменне ім’я, IP-адреса, веб-сайт, сервер, сертифікат або інший технічний компонент.

Записуючи такі об’єкти окремо, OpenKAT може встановлювати зв’язки: який веб-сайт належить до якого домену, який сертифікат належить до якої служби та яка знахідка належить до якого компонента.

Докладніше на OpenKAT.

Сканери часто видають приблизний результат. Нормалізація означає перетворення вихідних даних у дані, які OpenKAT може зрозуміти та порівняти фіксованим способом.

Це важливо, оскільки OpenKAT хоче поєднувати інформацію з різних джерел. Лише якщо дані чітко структуровані, ви можете зв’язати їх з об’єктами, висновками, стандартами та часовими шкалами.

Читайте також Що означає безпека, заснована на доказах?.

Сканер уразливостей зазвичай шукає конкретні технічні вразливості. OpenKAT є ширшим: він може поєднувати дані з кількох джерел, встановлювати зв’язки, показувати зміни з часом і пов’язувати результати з політиками чи стандартами.

Таким чином, OpenKAT може використовувати сканери, але сам по собі є перш за все платформою для об’єднання спостережень, контексту та подальших дій.

Докладніше на OpenKAT.

OpenKAT призначений для досліджень у межах узгодженого обсягу. Таким чином, ви скануєте лише системи, на які у вас є дозвіл і для яких зрозуміло, що можна перевірити.

Це важливо з юридичних, технічних та організаційних причин. Дослідження безпеки без чіткого охоплення може спричинити ризики та підірвати довіру.

Дивіться також Який обсяг розслідування MIAUW?.

так Важлива ідея, що лежить в основі OpenKAT, полягає в тому, що вам потрібен не лише моментальний знімок, ви також хочете побачити, як змінюється ситуація.

Це допомагає з такими запитаннями, як: чи проблему було вирішено, чи вона повернулася, чи з’явилося щось нове та ситуація з безпекою покращується чи погіршується?

Читайте також Чому важливе постійне розуміння?.

Не кожна знахідка має однакову терміновість. Технічна проблема в неважливій тестовій системі часто менш серйозна, ніж та сама проблема в загальнодоступній системі з конфіденційними даними.

OpenKAT допомагає, пов’язуючи технічні сигнали з контекстом, політикою та стандартами. Це дозволяє організації краще визначити, що потрібно вирішити в першу чергу.

Читайте також Як OpenKAT допомагає у відповідності?.

OpenKAT може допомогти з практичною стороною демонстрованої цифрової стійкості: отримати уявлення про системи, уразливості, неправильні конфігурації та зміни з часом.

NIS2 — це не лише технологія, але й управління, ризики та демонстративність. OpenKAT може забезпечити технічну підтримку для цього, але не замінює повну програму NIS2.

Читайте також Як OpenKAT допомагає у відповідності?.

OpenKAT здебільшого перевіряє технічні дані, але результати можуть бути чутливими. Звіт про вразливість або помилку конфігурації може бути використаний не за призначенням, якщо він потрапляє не в те місце.

Ось чому важливо обмежити доступ, добре захистити результати та сканувати лише в чіткому діапазоні.

Також прочитайте політика конфіденційності цього веб-сайту та Чи безпечно використовувати OpenKAT?.

Окремі результати сканування часто важко інтерпретувати. Зв’язки пояснюють, як пов’язані компоненти: який домен належить якому веб-сайту, яка служба працює в якій системі та яка знахідка належить якому об’єкту.

Ці зв’язки роблять OpenKAT не просто списком сповіщень. Він стає моделлю цифрового середовища, яка допомагає краще зрозуміти причини, вплив і подальші дії.

Докладніше на OpenKAT.

так OpenKAT цікавий тим, що може поєднувати інформацію з різних джерел. Розгляньте сканери, зовнішні джерела даних, перевірки конфігурації та власні дослідницькі завдання.

Мета полягає не в тому, щоб замінити кожен інструмент, а в тому, щоб краще об’єднати результати та зробити їх корисними для аналізу, моніторингу та звітності.

Докладніше на OpenKAT.

OciDeck — це програма для презентацій, яка фокусується на вмісті. Ви створюєте слайди з чітких форм слайдів, даних і тексту замість того, щоб вручну ковзати об’єкти по полотну.

Докладніше на OciDeck.

OciDeck призначений для людей, які сприймають презентації як носії знань. Подумайте про тренерів, дослідників, спеціалістів із безпеки, розробників, аудиторів, політиків та організації, які хочуть зберегти контроль над своєю інформацією.

Це особливо цікаво, коли важливі вміст, повторне використання, можливість перевірки та безпечний обмін.

Докладніше читайте на OciDeck та Особливості OciDeck.

Багато програм для презентацій починаються з чистого полотна. Ви перетягуєте текстові поля, зображення та фігури на місце.

OciDeck починається з вмісту. Ви обираєте тип слайда, заповнюєте вміст і дозволяєте презентації виникати з нього. Це полегшує перевірку, повторне використання та експорт слайдів.

Читайте також Чому Marp важливий для OciDeck.

Marp — це спосіб створення презентацій за допомогою Markdown. Markdown — це проста текстова нотація.

Marp важливий для OciDeck, оскільки це означає, що презентація залишається простим текстом. Це робить зміни контрольованими та гарантує, що вміст не буде заблоковано у форматі закритого файлу.

Докладніше на Чому Marp важливий для OciDeck.

Не обов’язково. OciDeck пропонує структуровані редактори для кожного типу слайда. Тож ви можете працювати без постійного написання Markdown.

Markdown — це насамперед відкрита основа для презентації. Кожен, хто знає Markdown, може скористатися цим, але це не є суворою вимогою для кожного використання.

Читайте також Що таке Marp?.

Презентації часто містять більш конфіденційну інформацію, ніж люди думають: імена, адреси електронної пошти, дані клієнтів, маркери, знімки екрана, нотатки доповідача або технічні деталі.

OciDeck допомагає зробити таку інформацію видимою раніше, до того, як презентацію буде надано спільний доступ або експортовано.

Докладніше на Функції конфіденційності в OciDeck.

OciWacht локально шукає потенційно конфіденційні дані в презентації. Подумайте про ідентифікаційні номери, адреси електронної пошти, номери телефонів, жетони, ключі чи інші конфіденційні шаблони.

Для кожної знахідки творець може вибрати, що з нею робити: прийняти, позначити або виключити з презентації та експорту.

Докладніше на Функції конфіденційності в OciDeck.

Ні, не для звичайної обробки вашої презентації. OciDeck web працює у вашому браузері: вебзастосунок Flutter завантажується із сервера, а потім редагування, live preview, OciWacht, експорт у PDF/PPTX/HTML і CVSS builder відбуваються на боці клієнта. Вміст презентації не надсилається на backend для обробки.

Також немає вбудованої телеметрії або analytics. Тому сервер хостингу OciDeck не отримує прикладного доступу до вашої презентації, редагувань, результатів перевірки конфіденційності чи експортів.

Є нюанси. Як будь-який webhost, сервер може мати звичайні access logs, наприклад IP-адресу, час, запитані файли та user-agent. Це показує, що хтось завантажив застосунок, але не показує, що ця людина робить в OciDeck.

Також існує опційний fetch proxy для імпорту URL, коли джерело не дозволяє CORS-доступ. Лише коли ви відкриваєте такий non-CORS URL через цей proxy, сервер бачить введений URL і ретранслює байти.

Інші вихідні з’єднання ініціюються користувачем і йдуть до місць, які ви самі вибираєте або налаштовуєте, наприклад опційна AI-допомога, WebDAV/Nextcloud, база CVE, secmodule provisioning або URL, який ви самі імпортуєте.

Якщо ви хочете використовувати OciDeck у браузері, перейдіть на ocideck.nl.

Докладніше на Функції конфіденційності в OciDeck.

Ні. Жодне сканування не знайде все.

OciWacht — це інструмент для раннього виявлення ризиків і більш свідомого поширення їх. Творець залишається відповідальним за вміст і завжди повинен думати за себе в делікатних презентаціях.

Читайте також Чому функції конфіденційності в OciDeck важливі?.

Не кожен слайд призначений для кожної аудиторії. OciDeck може допомогти визначити для кожної презентації та кожного слайда, наскільки широко можна поширювати інформацію.

Таким чином, OciDeck може допомогти запобігти випадковому потраплянню внутрішнього слайда в ширшу презентацію чи експорт.

Докладніше на Поділіться на потрібному рівні.

TLP означає протокол світлофора. Це кольорова система, яка вказує, наскільки конфіденційна інформація та з ким цією інформацією можна ділитися.

Вам не потрібно знати абревіатуру, щоб зрозуміти принцип. Практичне запитання: кому дозволено бачити цю інформацію?

Докладніше на Поділіться на потрібному рівні.

так Графіки в OciDeck залишаються пов’язаними з даними. Це робить їх більш керованими та менш залежними від скріншотів або зображень, створених вручну.

Це корисно для досліджень, звітів, інформаційних панелей і презентацій, де цифри мають залишатися правильними.

Докладніше на Особливості OciDeck.

так Контрольні списки можна перевіряти під час презентації.

Це корисно для тренінгів, семінарів, демонстрацій, оглядів безпеки та звітів, у яких має бути видно прогрес. Тоді контрольний список стає частиною історії, а не доповненням до презентації.

Докладніше на Особливості OciDeck.

так OciDeck зосереджується на роботі з єдиного джерела та експорті у придатні для використання формати, такі як PDF, PPTX і автономний автономний HTML.

Перевагою є те, що той самий вміст можна використовувати для різних цілей, не створюючи кожного разу нові копії вручну.

Докладніше на Особливості OciDeck.

так OciDeck є відкритим кодом. The source code is in Forgejo:

https://pawprint.vigilis.online/LibreKAT/Ocideck

Читайте також OciDeck.

Фігури слайдів – це фіксовані типи слайдів, такі як заголовок, список, таблиця, графік, приклад коду, питання, шкала часу або інформаційна панель.

Працюючи з фігурами слайдів, автору доводиться менше прокручувати вручну. Вміст є центральним, і OciDeck може відображати, контролювати та експортувати цей вміст більш послідовно.

Докладніше на Особливості OciDeck.

так OciDeck підтримує слайди з вихідним кодом і підсвічуванням синтаксису. Код залишається справжнім текстом замість знімка екрана.

Це корисно для технічних презентацій, навчання та звітів про безпеку, у яких код має бути доступним для читання та аудиту.

Докладніше на Особливості OciDeck.

так OciDeck може використовувати безкоштовні слайди Markdown, включаючи діаграми Mermaid і математику LaTeX.

Це означає, що діаграми та формули можна зберігати як вихідний вміст, а не як окреме зображення, яке важко змінити пізніше.

Докладніше про що робить Marp Markdown можливим.

Режим Markdown призначений для користувачів, які хочуть працювати безпосередньо з джерелом тексту колоди. Це може бути корисним для пошуку та заміни, швидкої зміни тексту або технічної перевірки.

Не завжди потрібно використовувати режим Markdown. Структуровані редактори залишаються для тих, хто віддає перевагу працювати по одному слайду.

Читайте також Що таке Marp?.

OciDeck містить додатковий модуль перевірки пера MIAUW. Цей модуль призначений для звітів згідно з Методикою дослідження інформаційної безпеки з аудиторським значенням.

Подумайте про пошук слайдів, резюме, контрольних списків, оглядів обсягів і підтримки звітів. Модуль вимкнено за замовчуванням і призначений для ситуацій, коли MIAUW дійсно актуальне.

Докладніше читайте на Особливості OciDeck та Що таке MIAUW?.

Офлайн-експорт HTML означає, що презентацію можна переносити або ділитися як окрему версію HTML без необхідності доступу до мережі під час відображення.

Це корисно для навчання, демонстрацій і середовищ, де ви не хочете залежати від хмарних презентацій або зовнішніх служб.

Докладніше на Особливості OciDeck.

так OciDeck підтримує презентації, серед іншого, повноекранний дисплей, навігація за допомогою клавіатури, таймер, нотатки, режим репетиції та подвійний екран доповідача.

Це робить OciDeck не лише редактором, а й інструментом для фактичного проведення презентацій.

Докладніше на Особливості OciDeck.

так OciDeck може працювати з нотатками доповідача та окремими нотатками для учасників.

Це корисно, оскільки не вся інформація повинна бути на самому слайді. Доповідачу може знадобитися додатковий контекст, тоді як учасникам потрібне чітке резюме або посилання.

Докладніше на Особливості OciDeck.

так OciDeck може використовувати Nextcloud/WebDAV як джерело для пакетів OciDeck і колод Marp Markdown.

Це підходить організаціям, які вважають за краще зберігати документи під власним керуванням або у власному середовищі спільної роботи.

Докладніше на Особливості OciDeck.

OciDeck зосереджується на доступному інтерфейсі, включаючи елементи керування з клавіатури, мітки для читання з екрана, масштабування тексту та сповіщення про зміну слайдів.

Доступність також стосується структури. Оскільки слайди складаються з реального вмісту, його легше підтримувати зрозумілим і перевіреним.

Докладніше на Особливості OciDeck.

Ви використовуєте Домашнє пиво? Потім виконайте ці дві команди. Перший вказує Homebrew на нашу власну кузню, другий встановлює OciDeck:

brew tap librekat/ocideck https://pawprint.vigilis.online/LibreKAT/homebrew-ocideck.git
brew install --cask librekat/ocideck/ocideck

Адресний рядок дійсно є його частиною. Якщо ви не вкажете це, Homebrew шукатиме GitHub і нічого не знайде.

Це канонічний шлях: і рецепт, і додаток походять із нашої власної кузні. Якщо фордж тимчасово недоступний, дзеркало GitHub є резервною копією. Це робиться однією командою, оскільки коротка форма Homebrew за визначенням вказує на GitHub:

brew install --cask brennodewinter/ocideck/ocideck

Незважаючи на те, що ви встановлюєте, Homebrew отримує випуск безпосередньо з нашої власної кузні та автоматично перевіряє контрольну суму. Програма підписана ідентифікатором розробника Apple і нотаріально засвідчена компанією Apple, тому вона відкривається простим подвійним клацанням.

Щоб оновити до пізнішої версії, виконайте:

brew upgrade --cask ocideck

Cask — це лише посилання на той самий підписаний і нотаризований випуск; Homebrew не розміщує застосунок у себе, і жоден додатковий посередник не додається. Homebrew Cask існує лише для macOS — у Windows і Linux ви завантажуєте OciDeck безпосередньо.

Бажаєте без Homebrew? Тоді завантажте OciDeck безпосередньо зі сторінки OciDeck. Там також пояснено для кожної платформи, як відкрити та перевірити завантаження.