Как го­во­рят ме­ди­ки, аб­со­лют­но здо­ро­вых людей прак­ти­че­ски нет, есть недо­об­сле­до­ван­ные. То же можно ска­зать и об ин­фор­ма­ци­он­ных си­сте­мах: прак­ти­че­ски у каж­дой из них есть дыры и про­ре­хи в ин­фор­ма­ци­он­ной без­опас­но­сти, ко­то­ры­ми могут вос­поль­зо­вать­ся зло­умыш­лен­ни­ки. Впро­чем, при опре­де­лен­ных об­сто­я­тель­ствах уяз­ви­мо­сти «вы­стре­ли­ва­ют» и без их вме­ша­тель­ства, и ка­ки­ми в этом слу­чае ока­жут­ся по­след­ствия, можно толь­ко гадать...

Что можно про­ти­во­по­ста­вить уяз­ви­мо­стям, как их вы­яв­лять и как от них за­щи­щать­ся? «Мы при­ме­ня­ем соб­ствен­ные ме­то­ди­ки об­на­ру­же­ния и сни­же­ния рис­ков, — рас­ска­зы­ва­ет Дмит­рий Ко­ст­ров, ди­рек­тор по про­ек­там де­пар­та­мен­та ИБ ком­па­нии «МТС». — Также мы ис­поль­зу­ем опыт наших ИТ-парт­не­ров и ак­тив­но ра­бо­та­ем с про­из­во­ди­те­ля­ми про­грамм­ных про­дук­тов — они пе­ри­о­ди­че­ски пуб­ли­ку­ют спис­ки уяз­ви­мо­стей и ре­ко­мен­да­ции по их устра­не­нию и ми­ни­ми­за­ции ущер­ба от них».

Сер­гей Ко­но­шен­ко, ди­рек­тор де­пар­та­мен­та ИБ ком­па­нии «Ка­бе­ст» (вхо­дит в груп­пу «Асте­рос»), в ка­че­стве ме­то­ди­че­ской ос­но­вы для ком­плекс­но­го управ­ле­ния уяз­ви­мо­стя­ми ре­ко­мен­ду­ет при­ме­нять стан­дарт ISO 27001.

В слу­чае если ин­фор­ма­ци­он­ные си­сте­мы ор­га­ни­за­ции под­па­да­ют под дей­ствие го­су­дар­ствен­ных ре­гу­ля­то­ров, необ­хо­ди­мо учи­ты­вать и их тре­бо­ва­ния. «Мно­гие ре­гу­ля­то­ры пред­пи­сы­ва­ют вести по­сто­ян­ный мо­ни­то­ринг и конт­роль ин­фор­ма­ци­он­ных си­стем на пред­мет по­ис­ка и устра­не­ния уяз­ви­мо­стей в них», — по­яс­ня­ет Коношенко.

Ком­па­ни­ям сле­ду­ет учи­ты­вать и тре­бо­ва­ния меж­ду­на­род­ных стан­дар­тов. На­при­мер, тем, кто стал­ки­ва­ет­ся с об­ра­бот­кой бан­ков­ских карт, необ­хо­ди­мо вы­пол­нять тре­бо­ва­ния PCI DSS (Payment Card Industry Data Security Standard) и вни­ма­тель­но от­но­сить­ся к пред­пи­са­ни­ям ре­гу­ли­ру­ю­ще­го ор­га­на в этой сфере — PCI Security Standards Council, на­по­ми­на­ет Игорь Ан­то­нов, на­чаль­ник от­де­ла ауди­та и кон­сал­тин­га ком­па­нии «Андэк».

Ран­жи­ру­ем уязвимости

По мне­нию Ко­ст­ро­ва, можно ис­поль­зо­вать раз­лич­ные типы клас­си­фи­ка­ции уяз­ви­мо­стей. На­при­мер, можно раз­де­лять уяз­ви­мо­сти, по­явив­ши­е­ся при про­ек­ти­ро­ва­нии раз­ра­ба­ты­ва­е­мой си­сте­мы, при вводе ее в экс­плу­а­та­цию, а также те, что по­яви­лись на этапе экс­плу­а­та­ции и при мо­дер­ни­за­ции. «Од­на­ко более пра­виль­ной, на мой взгляд, яв­ля­ет­ся клас­си­фи­ка­ция в за­ви­си­мо­сти от кри­тич­но­сти уяз­ви­мо­стей», — счи­та­ет он.

Ко­но­шен­ко по­ла­га­ет, что при клас­си­фи­ка­ции уяз­ви­мо­стей стоит от­тал­ки­вать­ся от ре­зуль­та­тов ис­сле­до­ва­ния угроз и рис­ков, пред­став­ля­ю­щих опас­ность для дан­ной ор­га­ни­за­ции в об­ла­сти за­щи­ты ин­фор­ма­ции. Ан­то­нов ре­ко­мен­ду­ет опи­рать­ся на клас­си­фи­ка­цию CVSS (Common Vulnerability Scoring System), по­сколь­ку имен­но эта об­ще­при­знан­ная клас­си­фи­ка­ция ис­поль­зу­ет­ся в от­рас­ле­вых стан­дар­тах (в част­но­сти, в PCI DSS) и под­дер­жи­ва­ет­ся боль­шин­ством ин­стру­мен­тов, пред­на­зна­чен­ных для вы­яв­ле­ния уязвимостей.

Наи­боль­шую ве­ро­ят­ность сра­ба­ты­ва­ния имеют уяз­ви­мо­сти, свя­зан­ные с ошиб­ка­ми при уста­нов­ке «за­пла­ток» (пат­чей), от­ме­ча­ет Ко­ст­ров: «Ин­фор­ма­ция о взло­ме си­сте­мы из-за оши­бок раз­ра­бот­чи­ков ПО рас­про­стра­ня­ет­ся с огром­ной ско­ро­стью. Слож­ный про­цесс уста­нов­ки но­во­го ПО (ис­поль­зо­ва­ние те­сто­вых зон, про­вер­ка ра­бо­то­спо­соб­но­сти всех при­ло­же­ний после уста­нов­ки но­во­го па­ке­та об­нов­ле­ний и пр.) поз­во­ля­ет зло­умыш­лен­ни­кам вос­поль­зо­вать­ся ин­фор­ма­ци­ей о воз­мож­но­сти взло­ма. «Бю­ро­кра­ти­за­ция» ИТ дает им вре­мен­ной лаг».

К наи­бо­лее опас­ным по мас­шта­бам воз­мож­но­го ущер­ба Ко­ст­ров от­но­сит уже об­на­ру­жен­ные уяз­ви­мо­сти, «за­плат­ки» к ко­то­рым еще не вы­пу­ще­ны. Боль­шую опас­ность пред­став­ля­ют и бреши, свя­зан­ные с непра­виль­ной кон­фи­гу­ра­ци­ей си­стем и средств за­щи­ты, внед­ре­ни­ем про­грамм­ных мо­ду­лей, целью ко­то­рых яв­ля­ет­ся сбор, ана­лиз ин­фор­ма­ции кон­фи­ден­ци­аль­но­го ха­рак­те­ра и пе­ре­сыл­ка этой ин­фор­ма­ции вовне, а также уяз­ви­мо­сти, свя­зан­ные с ошиб­ка­ми в коде при раз­ра­бот­ке про­грамм­ных продуктов.

«Самые ве­ро­ят­ные уяз­ви­мо­сти — те, что были об­на­ро­до­ва­ны, — со­гла­ша­ет­ся Ни­ко­лай Фе­до­тов, глав­ный ана­ли­тик ком­па­нии InfoWatch. — Во всем мире по­дав­ля­ю­щее боль­шин­ство ин­ци­ден­тов ИБ, в том числе за­ра­же­ний вре­до­нос­ны­ми про­грам­ма­ми, про­ис­хо­дит имен­но через такие уяз­ви­мо­сти. Для их ней­тра­ли­за­ции чаще всего либо уже име­ет­ся «за­плат­ка», либо из­ве­стен спо­соб вре­мен­но­го «при­кры­тия». Го­раз­до более ин­те­рес­ны необ­на­ро­до­ван­ные (0-day) уяз­ви­мо­сти — о них чаще го­во­рят, но в ста­ти­сти­ке ин­ци­ден­тов ИБ они встре­ча­ют­ся го­раз­до реже. Что ка­са­ет­ся раз­ме­ра убыт­ков, то он за­ви­сит лишь от дан­ных и си­стем, до ко­то­рых зло­умыш­лен­ник может до­брать­ся, ну и, ко­неч­но, от его замысла».

По мне­нию Ан­то­но­ва, сте­пень опас­но­сти уяз­ви­мо­стей силь­но за­ви­сит от осо­бен­но­стей кон­крет­ной си­сте­мы: «Если для нее кри­тич­но время про­стоя, то наи­бо­лее опас­ны уяз­ви­мо­сти, свя­зан­ные с от­ка­зом в об­слу­жи­ва­нии, если же более всего кри­тич­на кон­фи­ден­ци­аль­ность хра­ни­мой ин­фор­ма­ции, сле­ду­ет об­ра­тить пер­во­оче­ред­ное вни­ма­ние на уяз­ви­мо­сти, поз­во­ля­ю­щие по­лу­чить до­ступ к дан­ным (на­при­мер, по­сред­ством SQL-инъекции)».

Эль­ман Бей­бу­тов, ру­ко­во­ди­тель на­прав­ле­ния без­опас­но­сти баз дан­ных и кор­по­ра­тив­ных цен­тров управ­ле­ния со­бы­ти­я­ми ИБ ком­па­нии «Ин­фо­си­сте­мы Джет», наи­бо­лее зна­чи­мы­ми с точки зре­ния ре­а­ли­за­ции атак счи­та­ет при­ло­же­ния на базе веб-тех­но­ло­гий: «Ис­поль­зо­ва­ние зло­умыш­лен­ни­ка­ми уяз­ви­мо­стей веб-при­ло­же­ний часто ста­но­вит­ся при­чи­ной ре­а­ли­за­ции угроз и по­лу­че­ния до­сту­па к кон­фи­ден­ци­аль­ной ин­фор­ма­ции. На­при­мер, более 80% всех атак на веб-сер­ви­сы ре­а­ли­зу­ют­ся с по­мо­щью всего трех ме­то­дов: внед­ре­ние SQL-ко­да, под­дел­ка меж­сай­то­вых за­про­сов и вы­пол­не­ние ко­манд опе­ра­ци­он­ной си­сте­мы. При­чем атаки в этих слу­ча­ях могут быть на­це­ле­ны не толь­ко на кон­фи­ден­ци­аль­ность и це­лост­ность, но и на до­ступ­ность ин­фор­ма­ции, что осо­бен­но ак­ту­аль­но для си­стем, ра­бо­та­ю­щих в ре­жи­ме 24х7».

Поиск и обнаружение

К по­ис­ку и об­на­ру­же­нию уяз­ви­мо­стей сле­ду­ет при­вле­кать и со­труд­ни­ков, от­ве­ча­ю­щих за ИБ, и спе­ци­а­ли­стов по ИТ, по­сколь­ку те хо­ро­шо знают от­дель­ные ИТ-ком­по­нен­ты и под­си­сте­мы, раз­вер­ну­тые на пред­при­я­тии. По мне­нию Ко­ст­ро­ва, для по­ис­ка уяз­ви­мо­стей эф­фек­тив­но при­вле­кать груп­пу быст­ро­го ре­а­ги­ро­ва­ния на ин­ци­ден­ты ИБ (Computer Security Incident Responce Team, CSIRT), если та­ко­вая есть в дан­ной от­рас­ли, или хотя бы центр управ­ле­ния со­бы­ти­я­ми ин­фор­ма­ци­он­ной без­опас­но­сти пред­при­я­тия (Security Operations Center, SOC).

Эф­фек­тив­ным ор­га­ни­за­ци­он­ным ин­стру­мен­том для вы­яв­ле­ния уяз­ви­мо­стей яв­ля­ет­ся аудит си­стем. Стан­дарт ISO 27001 ре­ко­мен­ду­ет пе­ре­хо­дить к непре­рыв­но­му внут­рен­не­му ауди­ту ИБ, а пла­но­вые внеш­ние ауди­ты про­во­дить не реже раза в год, на­по­ми­на­ет Коношенко.

Ме­то­ди­ки по­ис­ка уяз­ви­мо­стей, от­ме­ча­ет Ко­ст­ров, сво­дят­ся к двум ос­нов­ным на­прав­ле­ни­ям: по­сто­ян­ный мо­ни­то­ринг предо­став­ля­е­мой ИТ-про­из­во­ди­те­ля­ми ин­фор­ма­ции о вы­яв­лен­ных уяз­ви­мо­стях их про­дук­тов и ска­ни­ро­ва­ние си­стем с ис­поль­зо­ва­ни­ем спе­ци­аль­ных ин­стру­мен­тов — ска­не­ров уяз­ви­мо­стей. Пе­ри­о­ди­че­ское ска­ни­ро­ва­ние на на­ли­чие уяз­ви­мо­стей, срав­ни­ва­ние по­лу­чен­ных ре­зуль­та­тов с преды­ду­щи­ми (лучше в ав­то­ма­ти­че­ском ре­жи­ме) — вот про­стей­ший ре­цепт вы­яв­ле­ния бре­шей. Ко­ст­ров со­ве­ту­ет также от­сле­жи­вать пуб­ли­ка­ции и дис­кус­сии на раз­лич­ных ин­тер­нет-фо­ру­мах спе­ци­а­ли­стов по ИБ.

«Для на­ча­ла нужно ор­га­ни­зо­вать от­сле­жи­ва­ние об­на­ро­до­ван­ных уяз­ви­мо­стей и вы­пус­ка­е­мых «за­пла­ток», — ре­ко­мен­ду­ет Фе­до­тов. — Бреши в ИБ надо за­кры­вать как можно быст­рее. Пер­со­нал сле­ду­ет ма­те­ри­аль­но за­ин­те­ре­со­вать как в ко­ли­че­стве, так и в быст­ро­те их за­кры­тия. Кроме того, важно с боль­шим вни­ма­ни­ем от­но­сить­ся к об­ра­ще­ни­ям (в том числе извне) по по­во­ду уяз­ви­мо­стей и ин­ци­ден­тов, при­чи­на­ми ко­то­рых могут стать дыры в си­сте­мах. Еще одна мера по сни­же­нию числа уяз­ви­мо­стей свя­за­на с вы­бо­ром ПО: к про­цес­су необ­хо­ди­мо при­вле­кать служ­бу ИБ, при­чем с пра­вом ре­ша­ю­ще­го го­ло­са. Лучше от­да­вать пред­по­чте­ние менее «кра­си­во­му», но более за­щи­щен­но­му ПО».

Для по­ис­ка уяз­ви­мо­стей в уже уста­нов­лен­ных си­сте­мах могут ис­поль­зо­вать­ся как ав­то­ма­ти­зи­ро­ван­ные про­вер­ки (ска­ни­ро­ва­ние), так и руч­ные (тест на про­ник­но­ве­ние, тех­ни­че­ский аудит и пр.), де­лит­ся сво­и­ми ре­ко­мен­да­ци­я­ми Ан­то­нов. Пе­ри­о­дич­ность их про­ве­де­ния, а сле­до­ва­тель­но, и сто­и­мость на­пря­мую за­ви­сят от сто­и­мо­сти ин­фор­ма­ции, со­дер­жа­щей­ся в ин­фор­ма­ци­он­ной си­сте­ме, и кри­тич­но­сти ин­фор­ма­ци­он­ной си­сте­мы для бизнеса.

Что ка­са­ет­ся веб-при­ло­же­ний, то, по сло­вам Бей­бу­то­ва, уяз­ви­мо­сти в них можно вы­яв­лять двумя ос­нов­ны­ми спо­со­ба­ми: по­сред­ством ана­ли­за без­опас­но­сти кода при­ло­же­ний и путем ре­гу­ляр­но­го ска­ни­ро­ва­ния уяз­ви­мо­стей. При этом кор­рек­ти­ров­кой кода ре­ко­мен­ду­ет­ся за­ни­мать­ся в ходе раз­ра­бот­ки при­ло­же­ния. Устра­нять вы­яв­лен­ные уяз­ви­мо­сти в уже ис­поль­зу­е­мых при­ло­же­ни­ях необ­хо­ди­мо с мак­си­маль­ной опе­ра­тив­но­стью. Хо­ро­шие ре­зуль­та­ты по ми­ни­ми­за­ции рис­ков, свя­зан­ных с уяз­ви­мо­стя­ми в уже уста­нов­лен­ных веб-при­ло­же­ни­ях, обес­пе­чи­ва­ют меж­се­те­вые экра­ны с функ­ци­ей virtual patching, поз­во­ля­ю­щие быст­ро бло­ки­ро­вать атаки и ав­то­ма­ти­че­ски предот­вра­щать экс­плу­а­та­цию еще не вы­яв­лен­ных уязвимостей.

Ре­гу­ляр­но ста­вим «заплатки»

Свое­вре­мен­ная уста­нов­ка «за­пла­ток» и па­ке­тов сер­вис­ных об­нов­ле­ний поз­во­ля­ет эф­фек­тив­но бо­роть­ся с уяз­ви­мо­стя­ми ис­поль­зу­е­мо­го ПО, уве­рен Ан­то­нов, но вме­сте с тем она никак не вли­я­ет на уяз­ви­мо­сти, свя­зан­ные с ошиб­ка­ми в конфигурировании.

«Если ста­вить все вы­пу­щен­ные за­плат­ки в те­че­ние 12 часов после их вы­хо­да, вы мо­же­те со спо­кой­ной со­ве­стью при­нять остав­ши­е­ся риски, — счи­та­ет Фе­до­тов. — Прав­да, кроме бре­шей, за­кры­тых «за­плат­ка­ми», есть уяз­ви­мо­сти, ко­то­рые по­яв­ля­ют­ся в ходе раз­ра­бот­ки ПО соб­ствен­ны­ми си­ла­ми или из-за нестан­дарт­но­го кон­фи­гу­ри­ро­ва­ния ти­ра­жи­ру­е­мых си­стем. Такие уяз­ви­мо­сти при­дет­ся вы­яв­лять и устра­нять самим».

По мне­нию Ко­ст­ро­ва, ра­бо­та по уста­нов­ке об­нов­ле­ний пред­став­ля­ет собой палку о двух кон­цах: если об­нов­ле­ние вышло, его надо сроч­но ста­вить, од­на­ко же уста­нов­ка «за­плат­ки» без ее про­вер­ки в те­сто­вой зоне может при­ве­сти к пла­чев­ным ре­зуль­та­там — есть риск, что эти об­нов­ле­ния ста­нут при­чи­ной сбоя од­но­го из клю­че­вых биз­нес-при­ло­же­ний и, как ре­зуль­тат, по­те­ри денег.

Не стоит по­ла­гать, что уста­нов­ка «за­пла­ток», вы­пус­ка­е­мых вен­до­ра­ми, решит все про­бле­мы, свя­зан­ные с уяз­ви­мо­стя­ми. Впро­чем, во­об­ще не нужно пи­тать ил­лю­зий от­но­си­тель­но от­сут­ствия бре­шей в ин­фор­ма­ци­он­ной си­сте­ме — они будут в ней при­сут­ство­вать, пока их не устранят.