Продовжуємо рубрику OWASP SAMM
Governance | Strategy & Metrics | Measure and Improve | L1
Метрики та вимірювання. Тема, що особисто мене цікавить найбільше. Го розбиратися з рекомендаціями від SAMM.
Рівень перший - це рівень оперування базовими відомостями про ефективність та результативність вашої АппСєк програми. Це вже більше, ніж у 90% ваших колег :D
Активності.
Визначити та задокументувати метрики оцінювання результативності та ефективності програми. Це піздєц як важливо і це велика помилка багатьох. Не можеш виміряти, знач не контролюєш. А вмів би вимірювати, то вмів би доводити до керівництва, під що конкретно тобі потрібні гроші та підтримка.
Пам'ятаємо, що девелопмент є дуже динамічним середовищем, тому метрики мають складатися із вимірювань наступних категорій:
1. Зусилля (Effort) - метрики, що дозволяють вимірювати зусилля, вкладені в безпеку. Наприклад, години тренінгів, години рев`ю коду, кількість аплікух, просканованих на вразливості, тощо.
2. Результат - метрики вимірювання результатів зусиль. Приклади включають кількість ненакатаних патчів (тобто відомих дефектів безпеки) та кількість інцидентів безпеки, пов'язаних із уразливістю аппликейшна.
3. Середовище (Environment) - метрики вимірювання середовища, де мають місце зусилля безпеки. Наприклад кількість додатків або строк коду як міра складності.
Кожна метрика само по собі несе інформацію, але кореляція метрик може надавати розуміння якихось різких змін показників. Так наприклад, різке зростання загального числа вразливостей може бути спричинене впровадженням кількох нових софтин, що раніше не піддавалися реалізованим контролям безпеки.
Для того, щоб ваші метрики були якісними, рекомендується дотримуватись наступних критеріїв:
• Послідовне вимірювання
• Недорогі в збиранні
• Виражається кардинальним числом чи відсотком
• Виражається одиницею вимірювання
Усі ваші показники мають бути задокументовані, включаючи їх опис та метод збору. Також опишіть рекомендовані методи для об'єднання окремих показників у значущі показники. Наприклад, кількість програм і загальна кількість дефектів у всіх програмах можуть бути не корисними самі по собі, але в поєднанні як кількість дефектів с високим северіті на аплікейшн, може мати сенс.
Питання, що треба задати собі: "Чи я використовую набір метрик та вимірювань ефективності та результативності АппСєк програми чи ні?"
Критерії якості відповіді:
1. Ви задокументували кожну метрику, включаючи описання джерел, покриття вимірювання, та інструкцію, як її використовувати для пояснення аппсєк трендів.
2. Метрики включають вимірювання зусиль, результатів та середовища, як вимірювальних категорій.
3. Більшість метрик вимірюються часто, прості чи недорогі у збиранні, виражаються числом або процентами.
4. АппСєк команда та девелопери публікують ці метрики.
Складно, але важливо.
#SAMM
Governance | Strategy & Metrics | Measure and Improve | L1
Метрики та вимірювання. Тема, що особисто мене цікавить найбільше. Го розбиратися з рекомендаціями від SAMM.
Рівень перший - це рівень оперування базовими відомостями про ефективність та результативність вашої АппСєк програми. Це вже більше, ніж у 90% ваших колег :D
Активності.
Визначити та задокументувати метрики оцінювання результативності та ефективності програми. Це піздєц як важливо і це велика помилка багатьох. Не можеш виміряти, знач не контролюєш. А вмів би вимірювати, то вмів би доводити до керівництва, під що конкретно тобі потрібні гроші та підтримка.
Пам'ятаємо, що девелопмент є дуже динамічним середовищем, тому метрики мають складатися із вимірювань наступних категорій:
1. Зусилля (Effort) - метрики, що дозволяють вимірювати зусилля, вкладені в безпеку. Наприклад, години тренінгів, години рев`ю коду, кількість аплікух, просканованих на вразливості, тощо.
2. Результат - метрики вимірювання результатів зусиль. Приклади включають кількість ненакатаних патчів (тобто відомих дефектів безпеки) та кількість інцидентів безпеки, пов'язаних із уразливістю аппликейшна.
3. Середовище (Environment) - метрики вимірювання середовища, де мають місце зусилля безпеки. Наприклад кількість додатків або строк коду як міра складності.
Кожна метрика само по собі несе інформацію, але кореляція метрик може надавати розуміння якихось різких змін показників. Так наприклад, різке зростання загального числа вразливостей може бути спричинене впровадженням кількох нових софтин, що раніше не піддавалися реалізованим контролям безпеки.
Для того, щоб ваші метрики були якісними, рекомендується дотримуватись наступних критеріїв:
• Послідовне вимірювання
• Недорогі в збиранні
• Виражається кардинальним числом чи відсотком
• Виражається одиницею вимірювання
Усі ваші показники мають бути задокументовані, включаючи їх опис та метод збору. Також опишіть рекомендовані методи для об'єднання окремих показників у значущі показники. Наприклад, кількість програм і загальна кількість дефектів у всіх програмах можуть бути не корисними самі по собі, але в поєднанні як кількість дефектів с високим северіті на аплікейшн, може мати сенс.
Питання, що треба задати собі: "Чи я використовую набір метрик та вимірювань ефективності та результативності АппСєк програми чи ні?"
Критерії якості відповіді:
1. Ви задокументували кожну метрику, включаючи описання джерел, покриття вимірювання, та інструкцію, як її використовувати для пояснення аппсєк трендів.
2. Метрики включають вимірювання зусиль, результатів та середовища, як вимірювальних категорій.
3. Більшість метрик вимірюються часто, прості чи недорогі у збиранні, виражаються числом або процентами.
4. АппСєк команда та девелопери публікують ці метрики.
Складно, але важливо.
#SAMM
👍5🔥1
Forwarded from RUH8
На россии лег спутниковый провайдер с боевитым названием ДоZор-Телепорт, который подключает клиентов через спутники "Экспресс" и "Ямал". Как и в случае с атакой на Viasat в день вторжения, хакеры возможно повредили клиентское оборудование и ядро сети. Найти прошивку к спутниковым модемам и коммутаторам, когда ты плывешь на газпромовском танкере посреди льдов будет нелегко. Клиенты спутникового интернета (включая МО, ФСБ, Росатом, Газпром, Россети) обычно находятся в такой жопе мира, что там можно разве что медведя позвать в качестве консультанта. Полагаю, что для того чтобы восстановить ядро сети уйдет от нескольких дней до нескольких недель, а на восстановление терминалов уйдут месяцы. Даже жаль, что такой прекрасный провайдер достался пригожинским бандитам. С другой стороны, спутниковые провайдеры не закончатся никогда, да и смотреть как россияне бомбят Воронеж можно вечно 🙂
👍4
Коли в мене знову будуть просити "дай чек-ліст для девелоперів, як код написати, щоб точно безпечно було, а не оце все незрозуміле" буду надавати це посилання. Правда потім будуть питання "Так і шо, де вразливості? Ти покажи як зламати, а не посилання давай" але то вже зовсім інша історія.
😁1
Forwarded from Security Digest UA
Mitre випустили оновлений Топ-25 слабких місць программного забезпечення.
🔺 Через подібні слабкі місця потім і виникають вразливості в ПЗ.
@secdigestua
🔺 Через подібні слабкі місця потім і виникають вразливості в ПЗ.
@secdigestua
🔥4
Forwarded from DC8044 F33d
crimea_providers_all.json
1.6 MB
Наконец-то стал доступен список таргетов vulnerability hub для тренировок и прокачивания скиллов в пентесте.
❤6
Forwarded from CyberPeople
💥Цей день настав!
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
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
🔥1
Адміністрація Сполучених Штатів анонсувала Artificial Intelligence Cyber Challenge - дворічні змагання із напилювання найкрутішого рішення на базі ШІ, що допомагатиме виправляти вразливості безпеки у системах забезпечення роботи Інтернету взагалі та систем на об'єктах критичної інфраструктури.
Ми ж розуміємо, що це лише відправна точка і після ОКІ воно все понесеться у цивільний сектор.
Так що, друзі аппсєк інженери, що бачать скоуп своєї роботи лише в аналізі репортів САСТів/ДАСТів та пентинкання веб сервісів за OWASP top 10: у вас ще є два роки на викручування рейзів зарплатні та оволодіння професією бариста (ти ж давно хотів вийти із АйТі, правда ж? :) ). До речі ось тут є непоганий безкоштовний курс із вирощуванняганджубасу канабісу: Doane University Cannabis Cultivation and Processing
Загальний призовий фонд змагань $20 000 000.
Хотів би сказати, що саме час опановувати ШІ у своїй повсякденній роботі, але таки ні. Це треба було робити хоча б рік тому. А тепер лише доганяємо останні вагони.
Лінка на сайт змагань: aicyberchallenge.com
#AI #appsec #cybersecurity #cannabis
Ми ж розуміємо, що це лише відправна точка і після ОКІ воно все понесеться у цивільний сектор.
Так що, друзі аппсєк інженери, що бачать скоуп своєї роботи лише в аналізі репортів САСТів/ДАСТів та пентинкання веб сервісів за OWASP top 10: у вас ще є два роки на викручування рейзів зарплатні та оволодіння професією бариста (ти ж давно хотів вийти із АйТі, правда ж? :) ). До речі ось тут є непоганий безкоштовний курс із вирощування
Загальний призовий фонд змагань $20 000 000.
Хотів би сказати, що саме час опановувати ШІ у своїй повсякденній роботі, але таки ні. Це треба було робити хоча б рік тому. А тепер лише доганяємо останні вагони.
Лінка на сайт змагань: aicyberchallenge.com
#AI #appsec #cybersecurity #cannabis
The White House
Biden-Harris Administration Launches Artificial Intelligence Cyber Challenge to Protect America’s Critical Software
Several leading AI companies – Anthropic, Google, Microsoft, and OpenAI – to partner with DARPA in major competition to make software more secure The Biden-Harris Administration today launched a major two-year competition that will use artificial intelligence…
🤷♀2👍1🤔1
SAMM: Implementation | Secure Build | Build Process | L1
За OWASP SAMM метою практики безпечної збірки (Secure Build) є стандартизація процесу, гарантії його повторюваності та використання безпечних компонентів.
Стрім Build Process фокусується на усуненні будь-якої суб'єктивності з процесу збірки, прагнучи до повної автоматизації. Автоматизований пайплайн може включати додаткові автоматизовані перевірки безпеки, такі як SAST та DAST, щоб отримати додаткову впевненість та вчасно виявити зниження рівня безпеки, наприклад, зупиняючи процес збірки.
Перший рівень зрілості наступає, коли ви можете відповісти на одне просте питання: Ваш весь процес білда описаний формально?
Якщо ви починаєте працювати в проекті коли якісь процеси вже існують - слід із цього почати. Взагалі, із моєї практики, всі завжди починають саме із розділу імплементації (середній стовпчик на схемі вище). Гадаю, я розумію причини цьому, але це для окремої публікації.
Головний бенефіт від досягнення першого рівня даної практики це обмеження ризику людського фактору під час виконання збірки, що мінімізує проблеми із безпекою.
Активності, що треба виконувати
- Розбийте весь процес збірки на складові, на чіткі інструкції, які може виконувати людина або автоматизація. Процес має бути описаний настільки повно від початку до кінця, щоб будь-хто міг його виконати степ-бай-степ отримуючи однаковий результат.
- Документацію зберігайте там, де всі її можуть прочитати. Централізовано. Не робіть декілька копій, це зламає вам процес підтримки актуальності інформації.
- В вашій документації НЕ МАЄ бути будь-яких секретів (паролів, токенів, тощо). Ніяких.
- Впевніться, що усі тули, які залучені до процесу збірки, мають актуальні версії та не містять публічно відомих вразливостей. Бажано, щоб тул підтримувався його вендором. Перевірте конфігурацію тула: там не має бути дефолтних секретів, зайвих прав доступу, тощо. Позакручуйте гайки всюди. Для цього вам доведеться розібратися із усіма функціональними можливостями тула та моніторити його оновлення.
- Впевніться, що кожен зібраний артефакт має контрольну суму або навіть підписаний ЕЦП. А ці контрольні суми та приватний сертифікат підпису зберігаються там, де їх цілісність неможливо порушити без запису цієї події в журнал аудиту.
- Не забувайте оновлювати всі тули в пайплайні та слідкувати за виходом виправлень їх безпеки.
Як зрозуміти, що ви описали білд повністю та достатньо? SAMM дає нам критерії:
1. У вас є достатньо інформації про відтворення процесу збірки
2. Ваша документація про процес збірки - актуальна на зараз
3. Ваша документація зберігається там, де її можуть отримати всі, кому це потрібно
4. Для кожного артефакту ваш пайплайн створює контрольні/хеш (геш?) суми для забезпечення можливості їх майбутньої перевірки.
5. Ви захарденили тули, що використовуються для виконання збірки
#SAMM
За OWASP SAMM метою практики безпечної збірки (Secure Build) є стандартизація процесу, гарантії його повторюваності та використання безпечних компонентів.
Стрім Build Process фокусується на усуненні будь-якої суб'єктивності з процесу збірки, прагнучи до повної автоматизації. Автоматизований пайплайн може включати додаткові автоматизовані перевірки безпеки, такі як SAST та DAST, щоб отримати додаткову впевненість та вчасно виявити зниження рівня безпеки, наприклад, зупиняючи процес збірки.
Перший рівень зрілості наступає, коли ви можете відповісти на одне просте питання: Ваш весь процес білда описаний формально?
Якщо ви починаєте працювати в проекті коли якісь процеси вже існують - слід із цього почати. Взагалі, із моєї практики, всі завжди починають саме із розділу імплементації (середній стовпчик на схемі вище). Гадаю, я розумію причини цьому, але це для окремої публікації.
Головний бенефіт від досягнення першого рівня даної практики це обмеження ризику людського фактору під час виконання збірки, що мінімізує проблеми із безпекою.
Активності, що треба виконувати
- Розбийте весь процес збірки на складові, на чіткі інструкції, які може виконувати людина або автоматизація. Процес має бути описаний настільки повно від початку до кінця, щоб будь-хто міг його виконати степ-бай-степ отримуючи однаковий результат.
- Документацію зберігайте там, де всі її можуть прочитати. Централізовано. Не робіть декілька копій, це зламає вам процес підтримки актуальності інформації.
- В вашій документації НЕ МАЄ бути будь-яких секретів (паролів, токенів, тощо). Ніяких.
- Впевніться, що усі тули, які залучені до процесу збірки, мають актуальні версії та не містять публічно відомих вразливостей. Бажано, щоб тул підтримувався його вендором. Перевірте конфігурацію тула: там не має бути дефолтних секретів, зайвих прав доступу, тощо. Позакручуйте гайки всюди. Для цього вам доведеться розібратися із усіма функціональними можливостями тула та моніторити його оновлення.
- Впевніться, що кожен зібраний артефакт має контрольну суму або навіть підписаний ЕЦП. А ці контрольні суми та приватний сертифікат підпису зберігаються там, де їх цілісність неможливо порушити без запису цієї події в журнал аудиту.
- Не забувайте оновлювати всі тули в пайплайні та слідкувати за виходом виправлень їх безпеки.
Як зрозуміти, що ви описали білд повністю та достатньо? SAMM дає нам критерії:
1. У вас є достатньо інформації про відтворення процесу збірки
2. Ваша документація про процес збірки - актуальна на зараз
3. Ваша документація зберігається там, де її можуть отримати всі, кому це потрібно
4. Для кожного артефакту ваш пайплайн створює контрольні/хеш (геш?) суми для забезпечення можливості їх майбутньої перевірки.
5. Ви захарденили тули, що використовуються для виконання збірки
#SAMM
❤7
Лайфхак: оригінальні та функціональні шпалери у вашому робочому просторі https://www.sans.org/blog/the-ultimate-list-of-sans-cheat-sheets/
SANS Institute
The Ultimate List of SANS Cheat Sheets
Need help cutting through the noise? SANS has a massive list of Cheat Sheets available for quick reference.
🔥5
SAMM: Implementation | Secure Build | Build Process | L2
Давайте по свіжій пам'яті розберемося чим перший рівень безпечно білда за SAMM відрізняється від другого.
Якщо дуже коротко, то перший ви досягаєте, коли знаєте в деталях кожен крок кожного пайплайну, а другий - коли пайплайн повністю автоматизований. Далі - за звичною структурою: навіщо, активності, питання та критерії якості.
Головний бенефіт
Ви будете мати ефективний процес збірки із інтегрованими інструментами безпеки.
Активності, що треба виконувати:
- Автоматизація процесу збірки. Тісна взаємодія із девопсами, чи хто у вас в проекті цим займається. Сперечання, конфлікти, погрози, компроміси, повна автоматизація, успіх. Збірка має виконуватись однаково, в будь-який час, взагалі без взаємодії із людиною. Це суттєво зменшить людський фактор і ймовірність помилок.
- Людський фактор зменшується, а от ризик експлуатації погано зконфігурованого інструменту в пайплайні виходить на перший план. Умовно кажучи, якщо ваш Jenkins без автентифікації стирчить юайкою на всю корпоративну мережу, а не лише на лише на тих, кому він необхідний, то безпеку вашого пайплану доволі не складно ушатати. І це стосується безпечної конфігурації всіх інструментів, що використовуються у пайплані.
- Проконтролюйте, що доступ до секретів та облікових записів, що необхідні для збірки, виконаний такими чином, що мінімізує або унеможливлює витік секретів. Підписуйте згенеровані артефакти за допомогою сертифіката, який ідентифікує організацію або підрозділ, який його створив, щоб ви могли перевірити його цілісність.
- Додайте автоматизовані перевірки безпеки артефакту в пайплайн, наприклад SAST чи IAST, якщо це технічно можливо. Використовуйте автоматизацію для покращення безпеки.
Допоміжне питання самому собі: Ваш білд повністю автоматизований?
Критерії якості відповіді:
1. Процес збірки не вимагає втручання люди взагалі
2. Інструменти виконання збірки захарденені згідно кращих практик та інструкцій від вендора (і ви можете це довести)
3. Ви шифруєте секрети, що необхідні інструментам для збірки та контролюєте доступ за принципом мінімальних привілеїв
#SAMM
Давайте по свіжій пам'яті розберемося чим перший рівень безпечно білда за SAMM відрізняється від другого.
Якщо дуже коротко, то перший ви досягаєте, коли знаєте в деталях кожен крок кожного пайплайну, а другий - коли пайплайн повністю автоматизований. Далі - за звичною структурою: навіщо, активності, питання та критерії якості.
Головний бенефіт
Ви будете мати ефективний процес збірки із інтегрованими інструментами безпеки.
Активності, що треба виконувати:
- Автоматизація процесу збірки. Тісна взаємодія із девопсами, чи хто у вас в проекті цим займається. Сперечання, конфлікти, погрози, компроміси, повна автоматизація, успіх. Збірка має виконуватись однаково, в будь-який час, взагалі без взаємодії із людиною. Це суттєво зменшить людський фактор і ймовірність помилок.
- Людський фактор зменшується, а от ризик експлуатації погано зконфігурованого інструменту в пайплайні виходить на перший план. Умовно кажучи, якщо ваш Jenkins без автентифікації стирчить юайкою на всю корпоративну мережу, а не лише на лише на тих, кому він необхідний, то безпеку вашого пайплану доволі не складно ушатати. І це стосується безпечної конфігурації всіх інструментів, що використовуються у пайплані.
- Проконтролюйте, що доступ до секретів та облікових записів, що необхідні для збірки, виконаний такими чином, що мінімізує або унеможливлює витік секретів. Підписуйте згенеровані артефакти за допомогою сертифіката, який ідентифікує організацію або підрозділ, який його створив, щоб ви могли перевірити його цілісність.
- Додайте автоматизовані перевірки безпеки артефакту в пайплайн, наприклад SAST чи IAST, якщо це технічно можливо. Використовуйте автоматизацію для покращення безпеки.
Допоміжне питання самому собі: Ваш білд повністю автоматизований?
Критерії якості відповіді:
1. Процес збірки не вимагає втручання люди взагалі
2. Інструменти виконання збірки захарденені згідно кращих практик та інструкцій від вендора (і ви можете це довести)
3. Ви шифруєте секрети, що необхідні інструментам для збірки та контролюєте доступ за принципом мінімальних привілеїв
#SAMM
"Аудит - це перевірка чогось на щось". І моє прізвище, як автора цитати запостили мені вчора слухачі лекції у коментарі. Ну добре, спробую готуватися трохи ретельніше.
😁10
Forwarded from Security Digest UA
🔥 Коротше, тут якась добра людина зробила всю роботу за нас і створила підбірку різних пропозицій з кібербезпеки на чорну п'ятницю. Бачу там реально круті штуки. Усе тут.
Upd: і ще таку підбірку підказали.
@secdigestua
Upd: і ще таку підбірку підказали.
@secdigestua
👍1
Просто вкиньтеся в цю концепцію:
1. У якості "апрува" від держави, що розроблене вами ПЗ є достатньо безпечним, держава (ДССЗЗІ або ліцензіат, хоча це ще треба уточнити) має провести експертизу вихідного коду цього ПЗ на відсутність незадокументованих функцій, що можуть послабляти систему безпеки.
2. Висновок такої експертизи є у Windows 10.
3. При кожній зміні вихідних кодів експертиза має проводитись повторно.
Ніхера собі в нас люди в ДССЗЗІ працюють. Мало того, що Майкрософт їм свої вихідні коди на всі оновлення надає, так вони ще й мільйони рядків коду вивчили і ще тисячі вивчають приблизно кожен тиждень. І ніхто їх ще не зхантив до себе на 15к+ як стартову позицію. Тупо титани. Тримаємо регуляційний фронт 💪.
#КСЗІ - так багато питань, так мало відповідей.
1. У якості "апрува" від держави, що розроблене вами ПЗ є достатньо безпечним, держава (ДССЗЗІ або ліцензіат, хоча це ще треба уточнити) має провести експертизу вихідного коду цього ПЗ на відсутність незадокументованих функцій, що можуть послабляти систему безпеки.
2. Висновок такої експертизи є у Windows 10.
3. При кожній зміні вихідних кодів експертиза має проводитись повторно.
Ніхера собі в нас люди в ДССЗЗІ працюють. Мало того, що Майкрософт їм свої вихідні коди на всі оновлення надає, так вони ще й мільйони рядків коду вивчили і ще тисячі вивчають приблизно кожен тиждень. І ніхто їх ще не зхантив до себе на 15к+ як стартову позицію. Тупо титани. Тримаємо регуляційний фронт 💪.
#КСЗІ - так багато питань, так мало відповідей.
😁11😱8🙈3