Безпечне кодування - Виклики інформаційної безпеки

ЗМІСТ

• Уразливості в коді
• Відкритий код та атаки на ланцюжки поставок
• Контроль інформаційної безпеки: Control 8.28 - Безпечне кодування
• Принципи безпечного кодування
• Висновок
• Перегляд ISO 27001: Що означає оновлення для вашої сертифікації?
• DQS - Simply leveraging Security.

Уразливості безпеки в коді

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

За таких умов командам розробників важко постійно переглядати та послідовно захищати код свого програмного забезпечення, про що свідчить велика кількість вразливостей, які некомерційна корпорація MITRE щороку публікує у своєму списку CVE (Common Vulnerabilities and Exposures). Регулярні патчі безпеки навіть відомих виробників програмного забезпечення є показником сізіфової роботи з усунення вразливостей, не кажучи вже про їх виявлення ще до того, як вони з'являться на ринку.

Відкритий код - особливий випадок

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

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

На практиці ця довіра тепер повинна оцінюватися диференційовано і критично. Найсерйознішим прикладом є вразливість нульового дня Log4Shell у широко використовуваній бібліотеці логування Log4J для Java-додатків, яка була виявлена в листопаді 2021 року. Можливо, ви чули про червоний рівень тривоги, виданий німецьким Федеральним відомством з інформаційної безпеки (BSI) для Log4Shell. Бібліотека Log4J, що розповсюджується як надійно функціонуючий квазі-стандарт через Apache Foundation, зарекомендувала себе в багатьох системах з 2013 року - в тому числі у відомих веб-сервісах, таких як Amazon AWS.

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

Ще одним фактором незахищеності компонентів з відкритим кодом є так звані атаки через ланцюжок постачання, тобто навмисне використання вбудованих вразливостей зловмисниками, які видають себе за частину спільноти розробників відкритого коду і допомагають у розробці коду. Така вразливість є надзвичайно ефективним способом для хакерів атакувати велику кількість організацій користувачів, що знаходяться "нижче за течією". Тож не дивно, що цей вектор атак стрімко зростає: дослідження Sonatype зафіксувало збільшення на 650%, якщо порівнювати 2020 та 2021 роки.

Контроль інформаційної безпеки 8.28 Безпечне кодування

З метою своєчасного захисту процесу розробки програмного забезпечення Міжнародна організація зі стандартизації (ISO - комітет ISO/IEC JTC 1/SC 27) включила "Безпечне кодування" як новий Control 8.28 у нові стандарти ISO/IEC 27002 та ISO/IEC 27001:2022, Додаток A. Метою технічного заходу щодо безпечного кодування є превентивний захист програмного забезпечення.

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

Принципи безпечного кодування

У Заході 8.28 кілька разів згадуються так звані принципи безпечного кодування. Настанови щодо того, якими вони можуть бути, надаються численними організаціями та інститутами, які регулярно видають посібники та найкращі практики щодо безпечного кодування. Серед них, наприклад, Практика безпечного кодування Фонду OWASP, Стандарти безпечного кодування Команди реагування на комп'ютерні надзвичайні ситуації (CERT - Computer Emergency Response Team) Інституту програмної інженерії (SEI), а також каталог заходів з безпеки веб-додатків німецького BSI. Незважаючи на різні джерела, розробки показують багато паралелей, наприклад, щодо наступних пунктів:

• Перевірка достовірності введених даних
• Безпечна автентифікація та управління паролями
• Безпечний контроль доступу
• Простий, прозорий код
• Стало перевірені криптографічні засоби та компоненти
• Обробка та реєстрація помилок
• Захист даних
• Моделювання загроз

У стандарті ISO/ISO 27002:2022 рекомендовані дії для Control 8.28 розділені на три розділи: "Планування та попереднє кодування", "Під час кодування" та "Перевірка та обслуговування", основний зміст яких викладено нижче.

Планування та попереднє кодування

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

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

Під час процесу кодування

Під час процесу кодування першочергову роль відіграють практики кодування та структуровані методи програмування з урахуванням конкретного варіанту використання та його потреб у безпеці. Небезпечні методи проектування - наприклад, жорстко закодовані паролі - повинні бути послідовно заборонені. Код повинен бути належним чином задокументований та переглянутий для найкращого усунення помилок, пов'язаних з безпекою. Перевірка коду повинна відбуватися як під час, так і після розробки, за допомогою статичного тестування безпеки додатків (SAST - static application security testing) або подібних методів. Методи статичного тестування підтримують підхід "зсуву вліво" ("тестувати рано і часто"), зсуваючись вліво в життєвому циклі за рахунок раннього тестування видимого коду на відповідність правилам.

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

Верифікація та обслуговування

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

Відкритий вихідний код

У сфері верифікації та обслуговування Measure 8.28 додатково містить чіткі інструкції щодо використання зовнішніх інструментів та бібліотек, таких як програмне забезпечення з відкритим вихідним кодом. Цими компонентами коду слід керувати, оновлювати та зберігати в інвентаризації. Це можна зробити, наприклад, за допомогою специфікації програмного забезпечення (Software Bill of Material, SBOM). SBOM - це формальний, структурований запис пакетів і бібліотек програмного забезпечення та їхніх зв'язків між собою і в ланцюжку постачання, зокрема, для відстеження повторно використаного коду і компонентів з відкритим кодом. SBOM підтримує "підтримуваність" програмного забезпечення та цільові оновлення безпеки.

Висновок

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

Завдяки професійному погляду наших досвідчених аудиторів, ми підтримуємо вас у впровадженні цього заходу відповідно до вимог. Завдяки нашому більш ніж 35-річному досвіду в галузі аудиту та сертифікації ми є вашим ідеальним контактним партнером і будемо раді допомогти вам у питаннях інформаційної безпеки та сертифікації відповідно до стандартів ISO/IEC 27001:2022.

Перегляд ISO 27001: що означає оновлення для вашої сертифікації?

Стандарт ISO/IEC 27001:2022 був опублікований 25 жовтня 2022 року. Це призводить до наступних термінів і часових рамок для переходу користувачів:

Остання дата для первинних/ресертифікаційних аудитів відповідно до "старого" ISO 27001:2013

• Після 31 жовтня 2023 року DQS буде проводити первинні та ресертифікаційні аудити лише за новим стандартом ISO/IEC 27001:2022

Перехід всіх існуючих сертифікатів зі "старого" ISO/IEC 27001:2013 на новий стандарт ISO/IEC 27001:2022

• Передбачено трирічний перехідний період з 31 жовтня 2022 року
• Сертифікати, видані відповідно до ISO/IEC 27001:2013 або DIN EN ISO/IEC 27001:2017, будуть продовжувати діяти не пізніше 31 жовтня 2025 року або повинні бути скасовані в цей день.

DQS: Simply leveraging Security.

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

Як експерти з аудиту та сертифікації з більш ніж 35-річним досвідом, ми будемо раді допомогти вам оцінити ваш поточний стан, можливо, в рамках дельта-аудиту. Дізнайтеся від наших численних досвідчених аудиторів про найважливіші зміни та їхню актуальність для вашої організації. Разом ми обговоримо ваш потенціал для вдосконалення і будемо підтримувати вас до отримання нового сертифікату. Скористайтеся нашою компетенцією в галузі інформаційної безпеки! Ми з нетерпінням чекаємо на ваш запит.