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

Відповіді на поширені запитання про LibreKAT Foundation, MIAUW, OpenKAT і OciDeck.

Фонд LibreKAT 13 запитань

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, співпраця, преса чи технічний внесок. Тоді швидше стане зрозуміло, хто може відповісти.

Суверенітет 29 запитань

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

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

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

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. Періодично перевіряйте, чи все ще працюють заходи, і вносьте корективи.

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

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

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

Відкритий код 100 запитань

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ліцензії 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 15 запитань

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenKAT 23 запитань

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 25 запитань

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.