Чи існує “срібна куля” щоб зробити Ваші ІТ системи безпечними? 

Флагманський проект Відкритого проекту з безпеки веб застосунків (OWASP) - Настанови з тестування часто використовується лише як книга рецептів для пошуку вад безпеки. Він і справді в основному наповнений різними техніками аудиту, але для керівників всіх щаблів набагато більш корисною є несправедливо забута частина цих настанов. А саме - другий розділ “Вступне слово”. В ній менеджер зможе знайти безцінні поради по організації безпеки в життєвому циклі розробки програмного забезпечення (ПЗ). Нижче найбільш корисні цитати з “Настанов з тестування безпеки”. 

Рахуйте кошти на зусилля заради безпеки і збитки від вад безпеки 

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

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

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

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

Вірний підхід до безпеки - це збалансований підхід, що включає кілька технік,  від швидких ручних оглядів, до технічного аудиту та інтегрованого в безперервну поставку (CI/CD) тестування. 

Не покладайтесь лише на аудити програмного коду. 

Ефективна програма з тестування безпеки має включати в себе щонайменше: 

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

Не покладайтесь лише на результати автоматизованого тестування безпеки 

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

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

Ручні огляди є однією з найбільш ефективних технік. 

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

Викорінюйте причини проблем безпеки. 

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

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

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

Підсумовуючі ідеї з Настанов: 

В реальності не існує “срібної кулі” щоб вирішити проблему небезпечного програмного забезпечення...