The Vulnerability Lifecycle and Patchingسووڕی ژیانی خاڵی لاواز و پینەکردن

A vulnerability is born the day a mistake enters the code — but nobody knows yet. Its story really starts when someone finds it. Lecture 4 calls this story the vulnerability lifecycle and gives it four steps:

خاڵێکی لاواز ئەو ڕۆژە لەدایک دەبێت کە هەڵەیەک دەچێتە ناو کۆدەوە — بەڵام هێشتا کەس نایزانێت. چیرۆکەکەی بە ڕاستی کاتێک دەست پێ دەکات کە کەسێک دەیدۆزێتەوە. وانەی چوارەم ئەم چیرۆکە ناو دەنێت سووڕی ژیانی خاڵی لاواز و چوار هەنگاوی بۆ دادەنێت:

Who finds vulnerabilities? Security researchers (including the maker's own testers and bug-bounty hunters), attackers, and automated tools. The lecture names three ways an organisation can find them in its own systems:

کێ خاڵە لاوازەکان دەدۆزێتەوە؟ لێکۆڵەرانی ئاسایش (لەوانە تاقیکەرەوەکانی خودی دروستکەرەکە و ڕاوچییانی خەڵاتی دۆزینەوەی باگ (Bug bounty))، هێرشبەرەکان و ئامرازە خۆکارەکان. وانەکە سێ ڕێگا ناو دەبات کە ڕێکخراوێک دەتوانێت لە سیستەمەکانی خۆیدا بیاندۆزێتەوە:

How scanners work in detail is in Finding and rating vulnerabilities. Penetration testing is allowed only with the owner's written permission — see Ethics and ethical hacking.

چۆنیەتیی کارکردنی سکانەرەکان بە وردی لە دۆزینەوە و هەڵسەنگاندنی خاڵە لاوازەکاندایە. تاقیکردنەوەی دزەکردن تەنها بە مۆڵەتی نووسراوی خاوەنەکەی ڕێگەپێدراوە — سەیری ئەخلاق و هاککردنی ئەخلاقی بکە.

To exploit a vulnerability means to use it to make a system do something it should not: reveal data, accept a fake login, or run the attacker's code. The lecture gives two examples:

قۆستنەوەی خاڵێکی لاواز واتە بەکارهێنانی بۆ ئەوەی سیستەمێک کارێک بکات کە نابێت بیکات: دراوە ئاشکرا بکات، چوونەژوورەوەیەکی ساختە قبووڵ بکات، یان کۆدی هێرشبەر جێبەجێ بکات. وانەکە دوو نموونە دەهێنێتەوە:

A real case joins both examples. From 27 May 2023, the criminal group CL0P exploited a SQL injection flaw in MOVEit Transfer, a program many organisations use to send large files. Nobody else knew about the flaw. In a few days the group copied files from many organisations around the world and then demanded money not to publish them. The maker, Progress Software, published its warning and a patch on 31 May; the flaw received the ID CVE-2023-34362 on 2 June.

ڕووداوێکی ڕاستەقینە هەردوو نموونەکە پێکەوە کۆ دەکاتەوە. لە ⁦27⁩ـی ئایاری ⁦2023⁩ـەوە، گرووپی تاوانکاری ⁦CL0P⁩ کێشەیەکی تێخزاندنی SQLـی لە ⁦MOVEit Transfer⁩ـدا قۆستەوە، بەرنامەیەک (Program) کە زۆر ڕێکخراو بۆ ناردنی فایلی گەورە بەکاری دەهێنن. کەسی تر بە کێشەکەی نەدەزانی. لە چەند ڕۆژێکدا گرووپەکە فایلی زۆر ڕێکخراوی لە سەرانسەری جیهاندا کۆپی کرد و پاشان داوای پارەی کرد بۆ ئەوەی بڵاویان نەکاتەوە. دروستکەرەکە، ⁦Progress Software⁩، لە ⁦31⁩ـی ئایاردا ئاگادارکردنەوە و پینەکەی بڵاو کردەوە؛ کێشەکە لە 2ـی حوزەیراندا ناسنامەی ⁦CVE-2023-34362⁩ـی وەرگرت.

Disclosure means reporting the vulnerability to the affected organisation or through responsible channels. In a good disclosure the finder reports privately, the maker gets time to fix, and only then are the details made public. Two things are created at this step: a CVE ID is reserved for the flaw (next screen), and the maker prepares a security advisory — a public notice saying which versions are affected and how to fix them.

ئاشکراکردن واتە ڕاپۆرتکردنی خاڵە لاوازەکە بۆ ڕێکخراوە پەیوەندیدارەکە یان لە ڕێگەی کەناڵە بەرپرسیارەکانەوە. لە ئاشکراکردنێکی باشدا دۆزەرەوەکە بە نهێنی ڕاپۆرت دەکات، دروستکەرەکە کاتی بۆ چاککردن دەدرێتێ و تەنها دواتر وردەکارییەکان ئاشکرا دەکرێن. لەم هەنگاوەدا دوو شت دروست دەبن: ناسنامەیەکی CVE بۆ کێشەکە دەگیرێت (پەڕەی داهاتوو) و دروستکەرەکە ئاگادارکردنەوەیەکی ئاسایش ئامادە دەکات — ڕاگەیاندنێکی گشتی کە دەڵێت کام وەشانانە کێشەکەیان تێدایە و چۆن چاک دەکرێن.

The two kinds of disclosure in the lecture — responsible (coordinated) and full disclosure — and the deadlines researchers use, such as Project Zero's 90 days, are explained in Responsible disclosure and bug bounties.

دوو جۆرەکەی ئاشکراکردن لە وانەکەدا — ئاشکراکردنی بەرپرسیارانە (Responsible disclosure) (هەماهەنگکراو) و ئاشکراکردنی تەواو (Full disclosure) — و ئەو وادانەی لێکۆڵەران بەکاریان دەهێنن، وەک ⁦90⁩ ڕۆژەکەی ⁦Project Zero⁩، لە ئاشکراکردنی بەرپرسیارانە و خەڵاتەکانی دۆزینەوەی باگ ڕوون کراونەتەوە.

What a CVE is — one public ID for each vulnerability, given out by CVE Numbering Authorities — is explained in CVE: one name for each vulnerability. This screen follows a CVE ID along the lifecycle and shows how defenders use it.

CVE چییە — یەک ناسنامەی گشتی بۆ هەر خاڵێکی لاواز، کە دەسەڵاتەکانی ژمارەدانانی CVE دەیبەخشن — لە CVE: یەک ناو بۆ هەر خاڵێکی لاواز ڕوون کراوەتەوە. ئەم پەڕەیە بەدوای ناسنامەیەکی CVEـدا دەڕوات بە درێژایی سووڕی ژیانی خاڵی لاواز و نیشان دەدات بەرگریکاران چۆن بەکاری دەهێنن.

The CVE Program names three states for a record: Reserved (the ID is taken), Published (the details are public) and Rejected (the ID should no longer be used, for example because it was a duplicate). Note that the year in an ID is the year the ID was reserved (or the year the flaw was made public) — not the year it was discovered or attacked.

بەرنامەی CVE سێ دۆخ بۆ تۆمارێک ناو دەبات: گیراو (ناسنامەکە گیراوە)، بڵاوکراوە (وردەکارییەکان ئاشکران) و ڕەتکراوە (ناسنامەکە چیتر نابێت بەکار بهێنرێت، بۆ نموونە لەبەر ئەوەی دووبارە بوو). سەرنج بدە کە ساڵی ناو ناسنامەیەک ئەو ساڵەیە کە ناسنامەکە گیراوە (یان ئەو ساڵەی کێشەکە ئاشکرا کرا) — نەک ساڵی دۆزینەوە یان هێرشەکە.

How defenders use the ID in the patching steps that follow: they search their scanner results and software lists for the ID, read the maker's advisory for that ID, check whether it is in KEV, and track the fix in a ticket named after it until every affected system is patched. One ID lets the scanner, the advisory, the patch notes and the ticket all point at the same flaw.

بەرگریکاران لە هەنگاوەکانی پینەی دواتردا ناسنامەکە چۆن بەکار دەهێنن: لە ئەنجامەکانی سکانەر و لیستی نەرمەواڵەکاندا بەدوای ناسنامەکەدا دەگەڕێن، ئاگادارکردنەوەی دروستکەرەکە بۆ ئەو ناسنامەیە دەخوێننەوە، دەپشکنن ئایا لە KEVـدایە و چاککردنەکە لە داواکارییەکی کاردا (تیکێت) کە ناوی ئەو ناسنامەیەی لەسەرە بەدواداچوونی بۆ دەکەن تا هەموو سیستەمێکی کێشەدار پینە دەکرێت. یەک ناسنامە وا دەکات سکانەر، ئاگادارکردنەوە، تێبینییەکانی پینە و تیکێتەکە هەموویان ئاماژە بە هەمان کێشە بکەن.

A zero-day is a vulnerability that attackers know and use before the maker knows about it or has a patch — the defenders have had 'zero days' to fix it. NIST describes a zero-day attack as one that exploits a previously unknown vulnerability. MOVEit in May 2023 was a zero-day: CL0P used the flaw for at least four days before anyone else knew.

خاڵی لاوازی ڕۆژی سفر خاڵێکی لاوازە کە هێرشبەرەکان پێش ئەوەی دروستکەرەکە پێی بزانێت یان پینەی هەبێت دەیزانن و بەکاری دەهێنن — بەرگریکاران «سفر ڕۆژ»یان بۆ چاککردنی هەبووە. NIST هێرشی خاڵی لاوازی ڕۆژی سفر وا وەسف دەکات کە خاڵێکی لاوازی پێشتر نەناسراو دەقۆزێتەوە. MOVEit لە ئایاری ⁦2023⁩دا خاڵی لاوازی ڕۆژی سفر بوو: ⁦CL0P⁩ لانیکەم چوار ڕۆژ پێش ئەوەی کەسی تر بزانێت کێشەکەی بەکار هێنا.

An n-day is a vulnerability that is already public and has a patch, but is still open on systems that were not updated; n is the number of days since the fix appeared. Equifax was an n-day: the patch was 67 days old when the data theft began. So was WannaCry: Microsoft had patched the Windows flaw two months before the worm spread.

خاڵی لاوازی ڕۆژی n خاڵێکی لاوازە کە پێشتر ئاشکرا کراوە و پینەی هەیە، بەڵام هێشتا لەسەر ئەو سیستەمانە کراوەیە کە نوێکردنەوە نەکراون؛ n ژمارەی ئەو ڕۆژانەیە کە لە دەرچوونی چارەسەرەکەوە تێپەڕیون. Equifax خاڵی لاوازی ڕۆژی n بوو: کاتێک دزینی دراوە دەستی پێکرد، پینەکە ⁦67⁩ ڕۆژ تەمەنی بوو. WannaCryیش هەروا بوو: Microsoft دوو مانگ پێش بڵاوبوونەوەی کرمەکە (Worm) کێشەکەی Windowsـی پینە کردبوو.

In the lecture's last step the organisation that makes the software releases an update or fix. But for everyone who uses the software, the work starts there: the patch must reach every affected system. The lecture gives three rules:

لە دوا هەنگاوی وانەکەدا ئەو ڕێکخراوەی نەرمەواڵەکە دروست دەکات نوێکردنەوەیەک یان چارەسەرێک دەردەکات. بەڵام بۆ هەموو ئەوانەی نەرمەواڵەکە بەکار دەهێنن، کارەکە لەوێوە دەست پێ دەکات: پینەکە دەبێت بگاتە هەموو سیستەمێکی کێشەدار. وانەکە سێ یاسا دەدات:

The first two rules push for speed, the third for care. NIST's patching guide (SP 800-40 Rev. 4, 2022) explains how to hold both: treat patching as preventive maintenance, like servicing a company's cars before they break down. A patch may sometimes disrupt work, but that disruption is planned and controllable; the disruption from a successful attack is not.

دوو یاسای یەکەم پاڵ بە خێراییەوە دەنێن، سێیەمیان بە وریاییەوە. ڕێبەری پینەکردنی ⁦NIST (SP 800-40 Rev. 4⁩، ⁦2022⁩) ڕوون دەکاتەوە چۆن هەردووکیان پێکەوە ڕابگریت: پینەکردن وەک چاککردنەوەی پێشوەختە مامەڵە بکە، وەک چاککردنەوەی ئۆتۆمبێلەکانی کۆمپانیایەک پێش ئەوەی تێک بچن. لەوانەیە پینەیەک هەندێک جار کار پچڕێنێت، بەڵام ئەو پچڕانە پلانی بۆ دانراوە و کۆنترۆڵ دەکرێت؛ پچڕانی هێرشێکی سەرکەوتوو وا نییە.

A big organisation may face hundreds of new patches every month. The lecture's rule: prioritise patching by the vulnerability's severity, its impact and the systems it affects, so the critical ones are fixed first. Today two more questions are added: is it being exploited right now (is it in KEV?) and is the system exposed to the internet?

ڕێکخراوێکی گەورە لەوانەیە هەموو مانگێک ڕووبەڕووی سەدان پینەی نوێ ببێتەوە. یاسای وانەکە: پینەکردن بەپێی توندیی خاڵە لاوازەکە، کاریگەرییەکەی و ئەو سیستەمانەی کێشەکەیان تێدایە ڕیز بکە، بۆ ئەوەی زۆر مەترسیدارەکان یەکەم جار چاک بکرێن. ئەمڕۆ دوو پرسیاری تریش زیاد دەکرێن: ئایا ئێستا دەقۆزرێتەوە (لە KEVـدایە؟) و ئایا سیستەمەکە بۆ ئینتەرنێت (Internet) ئاشکرایە؟

The full method — CVSS bands, the KEV catalog, CISA's directive BOD 26-04 and EPSS — is taught in Which one first? CVSS + KEV + exposure.

ڕێگا تەواوەکە — ئاستەکانی CVSS، لیستی KEV، ڕێنمایی ⁦BOD 26-04⁩ـی CISA و EPSS — لە کامیان یەکەم؟ ⁦CVSS + KEV +⁩ ئاشکرابوون فێر دەکرێت.

The lecture's second strategy: test patches thoroughly before deploying them, so they do not introduce new problems, and have a rollback plan — a tested way to return to the previous version if the patch breaks something. A common way to do this is a staged rollout:

ستراتیژی دووەمی وانەکە: پینەکان پێش دامەزراندن بە وردی تاقی بکەرەوە، بۆ ئەوەی کێشەی نوێ نەهێنن و پلانێکی گەڕانەوەت هەبێت — ڕێگایەکی تاقیکراوە بۆ گەڕانەوە بۆ وەشانی پێشوو ئەگەر پینەکە شتێک تێک بدات. ڕێگایەکی باو بۆ ئەمە بڵاوکردنەوەی قۆناغ بە قۆناغـە:

Sometimes a patch is not possible right away: it does not exist yet (a zero-day), the product is no longer supported (end of life), or the system must keep running, as in a hospital or a factory. NIST lists ways to handle the risk until then:

هەندێک جار پینە یەکسەر ناکرێت: هێشتا نییە (خاڵی لاوازی ڕۆژی سفر)، بەرهەمەکە چیتر پشتگیری ناکرێت (کۆتایی ژیان)، یان سیستەمەکە دەبێت بەردەوام کار بکات، وەک لە نەخۆشخانە یان کارگەیەکدا. NIST چەند ڕێگایەک بۆ مامەڵەکردن لەگەڵ مەترسییەکە تا ئەو کاتە دەژمێرێت:

Doing all this by hand on hundreds of computers is impossible. The lecture names patch-management systems: tools that automate the deployment of software updates and patches. Their two big advantages:

ئەنجامدانی هەموو ئەمانە بە دەست لەسەر سەدان کۆمپیوتەر ناکرێت. وانەکە سیستەمەکانی بەڕێوەبردنی پینە ناو دەبات: ئامرازگەلێک کە دامەزراندنی نوێکردنەوەکان و پینەکانی نەرمەواڵە خۆکار دەکەن. دوو سوودە گەورەکەیان:

NIST describes the whole job as a short cycle that every organisation repeats:

NIST هەموو کارەکە وەک خولێکی کورت وەسف دەکات کە هەموو ڕێکخراوێک دووبارەی دەکاتەوە: