💥Цей день настав!

Distributed Lab спільно з Prometheus запускають безплатний курс «Solidity Smart Contracts» від найдосвідченіших фахівців сфери.

Про що цей курс?
🔥 дослідження можливостей Ethereum, відмінностей між Bitcoin і Ethereum;

🔥 розуміння технології смарт-контрактів, їхнього життєвого циклу;

🔥 знання різних аспектів мови Solidity як мови високого рівня, орієнтованої на контракти;

🔥 здатність проєктувати та розробляти смарт-контракти на Solidity;

🔥 вміння розуміти та використовувати типи даних, функції, події тощо в Solidity;

🔥 здатність взаємодіяти зі смарт-контрактами та розуміти, як обробляються виклики EVM;

🔥 розуміння внутрішніх та зовнішніх бібліотек, їхнього призначення та використання;

🔥 розуміння специфіки роботи з токенами ERC20, ERC721, ERC1155.

Реєстрація за посиланням:
https://prometheus.org.ua/course/course-v1:Prometheus+SSC101+2023_T2

Адміністрація Сполучених Штатів анонсувала Artificial Intelligence Cyber Challenge - дворічні змагання із напилювання найкрутішого рішення на базі ШІ, що допомагатиме виправляти вразливості безпеки у системах забезпечення роботи Інтернету взагалі та систем на об'єктах критичної інфраструктури.
Ми ж розуміємо, що це лише відправна точка і після ОКІ воно все понесеться у цивільний сектор.
Так що, друзі аппсєк інженери, що бачать скоуп своєї роботи лише в аналізі репортів САСТів/ДАСТів та пентинкання веб сервісів за OWASP top 10: у вас ще є два роки на викручування рейзів зарплатні та оволодіння професією бариста (ти ж давно хотів вийти із АйТі, правда ж? :) ). До речі ось тут є непоганий безкоштовний курс із вирощування ганджубасу канабісу: Doane University Cannabis Cultivation and Processing
Загальний призовий фонд змагань $20 000 000.
Хотів би сказати, що саме час опановувати ШІ у своїй повсякденній роботі, але таки ні. Це треба було робити хоча б рік тому. А тепер лише доганяємо останні вагони.

Лінка на сайт змагань: aicyberchallenge.com

#AI #appsec #cybersecurity #cannabis

SAMM: Implementation | Secure Build | Build Process | L1

За OWASP SAMM метою практики безпечної збірки (Secure Build) є стандартизація процесу, гарантії його повторюваності та використання безпечних компонентів.

Стрім Build Process фокусується на усуненні будь-якої суб'єктивності з процесу збірки, прагнучи до повної автоматизації. Автоматизований пайплайн може включати додаткові автоматизовані перевірки безпеки, такі як SAST та DAST, щоб отримати додаткову впевненість та вчасно виявити зниження рівня безпеки, наприклад, зупиняючи процес збірки.

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

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

Активності, що треба виконувати
- Розбийте весь процес збірки на складові, на чіткі інструкції, які може виконувати людина або автоматизація. Процес має бути описаний настільки повно від початку до кінця, щоб будь-хто міг його виконати степ-бай-степ отримуючи однаковий результат.
- Документацію зберігайте там, де всі її можуть прочитати. Централізовано. Не робіть декілька копій, це зламає вам процес підтримки актуальності інформації.
- В вашій документації НЕ МАЄ бути будь-яких секретів (паролів, токенів, тощо). Ніяких.
- Впевніться, що усі тули, які залучені до процесу збірки, мають актуальні версії та не містять публічно відомих вразливостей. Бажано, щоб тул підтримувався його вендором. Перевірте конфігурацію тула: там не має бути дефолтних секретів, зайвих прав доступу, тощо. Позакручуйте гайки всюди. Для цього вам доведеться розібратися із усіма функціональними можливостями тула та моніторити його оновлення.
- Впевніться, що кожен зібраний артефакт має контрольну суму або навіть підписаний ЕЦП. А ці контрольні суми та приватний сертифікат підпису зберігаються там, де їх цілісність неможливо порушити без запису цієї події в журнал аудиту.
- Не забувайте оновлювати всі тули в пайплайні та слідкувати за виходом виправлень їх безпеки.

Як зрозуміти, що ви описали білд повністю та достатньо? SAMM дає нам критерії:
1. У вас є достатньо інформації про відтворення процесу збірки
2. Ваша документація про процес збірки - актуальна на зараз
3. Ваша документація зберігається там, де її можуть отримати всі, кому це потрібно
4. Для кожного артефакту ваш пайплайн створює контрольні/хеш (геш?) суми для забезпечення можливості їх майбутньої перевірки.
5. Ви захарденили тули, що використовуються для виконання збірки

#SAMM

Лайфхак: оригінальні та функціональні шпалери у вашому робочому просторі https://www.sans.org/blog/the-ultimate-list-of-sans-cheat-sheets/

SAMM: Implementation | Secure Build | Build Process | L2

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

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

Активності, що треба виконувати:
- Автоматизація процесу збірки. Тісна взаємодія із девопсами, чи хто у вас в проекті цим займається. Сперечання, конфлікти, погрози, компроміси, повна автоматизація, успіх. Збірка має виконуватись однаково, в будь-який час, взагалі без взаємодії із людиною. Це суттєво зменшить людський фактор і ймовірність помилок.
- Людський фактор зменшується, а от ризик експлуатації погано зконфігурованого інструменту в пайплайні виходить на перший план. Умовно кажучи, якщо ваш Jenkins без автентифікації стирчить юайкою на всю корпоративну мережу, а не лише на лише на тих, кому він необхідний, то безпеку вашого пайплану доволі не складно ушатати. І це стосується безпечної конфігурації всіх інструментів, що використовуються у пайплані.
- Проконтролюйте, що доступ до секретів та облікових записів, що необхідні для збірки, виконаний такими чином, що мінімізує або унеможливлює витік секретів. Підписуйте згенеровані артефакти за допомогою сертифіката, який ідентифікує організацію або підрозділ, який його створив, щоб ви могли перевірити його цілісність.
- Додайте автоматизовані перевірки безпеки артефакту в пайплайн, наприклад SAST чи IAST, якщо це технічно можливо. Використовуйте автоматизацію для покращення безпеки.

Допоміжне питання самому собі: Ваш білд повністю автоматизований?
Критерії якості відповіді:
1. Процес збірки не вимагає втручання люди взагалі
2. Інструменти виконання збірки захарденені згідно кращих практик та інструкцій від вендора (і ви можете це довести)
3. Ви шифруєте секрети, що необхідні інструментам для збірки та контролюєте доступ за принципом мінімальних привілеїв

#SAMM

Коли занадто сильно намагаєшся бути чемним.

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

Сертифікація, на яку ти заслужив.

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

Upd: і ще таку підбірку підказали.

@secdigestua

Зате у Київстара, мабудь, був атестат КСЗІ і всі документи в порядку

Просто вкиньтеся в цю концепцію:

1. У якості "апрува" від держави, що розроблене вами ПЗ є достатньо безпечним, держава (ДССЗЗІ або ліцензіат, хоча це ще треба уточнити) має провести експертизу вихідного коду цього ПЗ на відсутність незадокументованих функцій, що можуть послабляти систему безпеки.

2. Висновок такої експертизи є у Windows 10.

3. При кожній зміні вихідних кодів експертиза має проводитись повторно.

Ніхера собі в нас люди в ДССЗЗІ працюють. Мало того, що Майкрософт їм свої вихідні коди на всі оновлення надає, так вони ще й мільйони рядків коду вивчили і ще тисячі вивчають приблизно кожен тиждень. І ніхто їх ще не зхантив до себе на 15к+ як стартову позицію. Тупо титани. Тримаємо регуляційний фронт 💪.

#КСЗІ - так багато питань, так мало відповідей.

Цього тижня в Києві відбулася гучна подія із складною назвою Kyїv International Cyber Resilience Forum 2024, яку я не заплановано відвідав. Коротке саммарі, що запам'яталося саме мені (далі йде суб'єктивне оцінювальне судження).

Я вважаю, що слід окремо оцінювати організацію та зміст, так і зроблю.

👉 Організація: на мою думку - топ. Дорого-багато. Дуже солідна локація, прекрасні два великі зали, офігезні відеостіни на сцені за спинами спікерів, нормально організовані стойки реєстрації, перевірка документів та рамка металодетектору на охороні (навіть дві). Охорона не втомлювалася перевіряти кожного, хто навіть палити ходив на вулицю. Скоріш за все це вимога безпеки через доволі велику кількість високопосадовців та іноземців, але все ж таки. Хоча на Дію охоронці просто дивилися, а не сканували. Щось Дії потрібно із цим робити, бо майже ніхто ніде цього не робить і це ламає логіку верифікації, хоча це вже зовсім інша історія.
Також слід відмітити непоганий кейтерінг, наявність фото-відео операторів та нормально організовані місця для нетворкінгу. Не знаючи якихось деталей та приймаючи участь виключно як гість - п'ять зірочок із п'яти від мене організаторам.

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

1️⃣ На доповіді керівник дуже важливого (без жартів) об'єкту критичної інфраструктури розповідав, як на фоні новин у грудні 21 та січні 22 вони задумалися "а може зробимо якийсь план реагування на інциденти?". Після цих слів я пішов пити каву в коридор, де і зустрів друзів-практиків.

2️⃣ На панелі були представники МО, СофтСерв, ГО "Аеророзвідка", SET University та ще пару людей. Представник ГО "Аеророзвідка" значно відрізнявся компетенцією, бо видно, що зтикається з практикою впровадження. Представниця МО також мене трохи здивувала, бо я не очікував такого занурення в предметну область від замміністра, хоча і зрозуміло, що вона не завжди була такою. Схоже їй доводиться по справжньому і постійно працювати з питаннями впровадження безпеки, отримувати практичний досвід. Тарас Кіцмей (SoftServe) сказав, що "на його думку в Україні все дуже непогано із кібербезпекою критичної інфраструктури і вона на високому рівні, бо ми ще живі і все працює". Запам'ятаю собі цю модель оцінки ризиків.

3️⃣ Також не можу не відмітити зауваження колеги Вови Стирана: на іншій доповіді керівник якоїсь важливої установи сказав "нє, ну а шо ви хочете від нас, якщо неможливо правильно порахувати інвестиції в кібербезпеку". Може розкажемо йому?

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

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

Події проходять. Традиції залишаються.

Чат, який працює на протоколі ARP (так так, канальний рівень OSI). Тепер ти бачив більше. https://github.com/kognise/arpchat

Якщо ви параноїте стосовно securiy suppply chain ризиків так само, як і я, але у вас немає можливості або бажання займатися вибудовою автоматизованих контролів для їх пом'якшення, то цей інструмент для вас.

OSS Insight допоможе вам подивитися багато різної статистики про депенденсю: частоту комітів, звідкіля приходятm контриб'ютори та звідки ті, хто ставить зірочки, статистика виправлень, імена контриб'юторів, тощо. Сервіс підкупає своєю юайкою та гістограмами. Є навість можливість порівнювати різні депенденсі за цими показниками на одному графі. Вся інфа береться з репозиторію, де живе депенденся, наприклад з Github. Хоча в ньому і немає багато з того, що я хотів би бачити, але для первинного аналізу та калібровки метрик в проєкті покатить (тільки данні про CVE ще візьміть десь).

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

Відповідь на питання вище може мати дві форми: формальна та неформальна.
Формально, згідно із ЗУ "Про захист інформації в інформаційно-комунікаційних системах" :

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

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

Неформально:
Керівник проєкту в нормі має бути відповідальний за успіх проєкту. Якщо проєкт буде просраний з будь-якої причини - це буде проблема керівника проєкта. Він не має бути компетентний в безпеці, як і в девелопменті чи QA, але він, як керівник, має знайти, залучити та проконтролювати роботу компетентної в цьому домені людини. Для цього керівник проєкту має використовувати ризик менеджмент, а недостатній рівень безпеки буде для нього червоним світлом.
За виховання дитини відповідальні батьки, а не школа. За належний стан авто відповідальний власник, а не СТО. Якщо керівник, батьки чи власник авто не хочуть нести за це відповідальність - вони можуть передати цю відповідальність виділеним командам професіоналів, виділеним вихователям та автосервісам, які здатні на такий рівень послуг. Але це не дешево і відповідальність за вибір такого провайдеру все одно буде лажати на керівникові. Або ж вони можуть включати когось до себе в команду для того, щоб делегувати активності. Або ж купувати консультації, якщо треба економити. І відповідальність за успіх проєкту буде все одно лежати на керівникові проєкту.
На то він (ви) і керівник.