Unix serverių saugumas


Bendrieji principai

Pateikus gerai žinomus pagrindinius saugumo principus galima nuspėti grėsmes ir suformuluoti tikslus serverių saugumo užtikrinimui:







Nr. Principas Grėsmė Tikslas
1. Konfidencialumas Neautorizuota prieiga Užtikrinti prieiga tik autorizuotiems subjektams
2. Prieinamumas Paslaugų nepasiekiamumas Užtikrinti paslaugų pasiekiamumą
3. Vientisumas Neautorizuotos modifikacijos Apsaugoti nuo neautorizuotų modifikacijų
4. Autentiškumas Apsimetinėjimai Apsaugoti nuo apsimetinėjimų
5. Atitinkamumas Kaltinimai 🙂 Užtikrinti logų kaupimą

Visą tai padaryti reikia minimaliais resursais, ką lemia akademinė specifika (ir vyraujantys ekonomijos vėjai), kai IT saugumas (saugumo priemonių planavimas, testavimas, diegimas, reagavimas į incidentus, konsultacijos) yra sistemų administratorių pareiga.

Kadangi kaip apsaugos taip ir puolimo metodikos ir technologijos keičiasi, labai svarbu, kad saugumo užtikrinimas taptų iteraciniu procesu, kurio planas būtų toks:

10 Inventorizacija
20 Priemonių planavimas
30 Priemonių diegimas
40 Rezultatų įvertinimas
50 GOTO 10

Siekiant efektyvumo, šituos žingsnius reikėtų kartoti nustatytais intervalais kartu su kitais sistemų ir servisų administratoriais.

Inventorizacija

Tikslas – gauti administruojamų sistemų, jų operuojamų duomenų ir paslaugų sąrašą, o taip pat ryšius su kitomis sistemomis. Tarkime turime 4 administruojamus serverius:

  1. Organizacijos Pirminis DNS
  2. Organizacijos Antrinis DNS
  3. MySQL serveris, skirtas WWW serveriui (4)
  4. Vidinės reikšmės WWW serveris

Taip pat reikia sukurti vertinimo sistemą ir įvertinti sistemos bei servisų „svarbumo lygi“, pavyzdžiui pagal tokius kriterijus kaip svarba bendrai infrastruktūros veikimui, saugomų duomenų svarbumas/slaptumas bei tiekiamos paslaugos svarbumas organizacijai (1 – svarbiausias).

Inventorizacijos pavyzdys būtų toks:






Sistema Hosto vardas IP adresas Paslaugos Ryšiai Svarbumo lygis
Pirminis DNS dns1.pvz.lt 10.1.0.1 named, ssh

1
Antrinis DNS dns2.pvz.lt 10.1.0.2 named, ssh dns1.pvz.lt:domain 2
MySQL serveris db.pvz.lt 10.1.0.3 mysqld, ssh

3
Vidinis WWW intra.pvz.lt 10.1.0.4 apache2, ssh, webmin db.pvz.lt:mysql 3

Kita informacija:

  • Serverių potinklis: 10.1.0.0/24
  • Organizacijos potinklis: 10.0.0.0/8
  • Administratorių darbo vietų potinklis: 11.1.1.0/24
    • 11.1.1.2 – vyr. adminas
    • 11.1.1.3 – adminas
    • 11.1.1.5, 11.1.1.6 – web adminai

Priemonių planavimas

1. Užtikrinti prieigą tik autorizuotiems subjektams

Prieigos kontrolė gali būti vykdoma dvejuose lygiuose: tinklo ir paslaugų (servisų). Plačiausiai naudojama tinklo lygio priėjimo kontrolės priemonė Linux sistemose yra iptables (BSD šeimoje – pf, Packet Filter). Rekomenduojama tinklo lygio priėjimo kontrolės schema yra:

  • Praleisti administratorius.
  • Praleisti tinklus, kuriems tiekiamos paslaugos.
  • Uždrausti visą kitą.

Esant reikalui (pvz, jei planuojama automatizuoti iptables taisyklių kūrimą), galima suskirstyti administravimo ir paslaugų priėjimo kontrolę į atskiras grandines (iptables terminologijoje – chains).

Siūlomas iptables šablonas, pritaikytas dns1.pvz.lt:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [11690:1055675]
:adm - [0:0]

-A INPUT -i lo -j ACCEPT
-A INPUT  -p icmp -m limit --limit 10/second -j ACCEPT
-A INPUT  -p icmp -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# ADMINISTRATORIAI
-A adm -s 11.1.1.2/32   -j ACCEPT
-A adm -s 11.1.1.4/32 -j ACCEPT
-A adm -j REJECT --reject-with icmp-host-prohibited

# ADMINISTRAVIMO SERVISAI
# ssh
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j adm
# webmin
#-A INPUT -p tcp -m state --state NEW -m tcp --dport 10000 -j adm

# SERVISAI
# dns -A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT # Atmesti visus kitus su 'no route to host' -A INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT

Siekiant didesnės kontrolės, galima loginti sėkmingus/nesėkmingus bandymus prieiti prie servisų (su -j LOG) ir/arba kontroliuoti bandymų greitį (pvz: -m limit --limit 10/second). Kadangi dauguma servisų naudoja syslog ir patys registruoja bandymus prisijungti, tai iptables loginimas dažniausiai naudojamas NAT serveriuose. Priklausomai nuo paranojos lygio galima taip pat vykdyti ir išeinančių srautų kontrolę (outbound, -A OUTPUT):

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m state --state NEW -m tcp -d lt.archive.ubuntu.com --dport 80 -j ACCEPT
-A OUTPUT -j REJECT --reject-with icmp-host-prohibited

Tai gali būti papildoma saugumo priemonė, pavyzdžiui, web serveriams, naudojantiems potencialiai nesaugius skriptus (labas, phpBB!), kurie mėgsta atsisiųst trojanus iš išorinių adresų.

Serviso lygio priėjimo kontrolė pilnai priklauso nuo pačio serviso. Pvz, OpenSSH tai būtų kombinacija iš AllowUsers direktyvos sshd_config faile, nurodant administratorių naudotojų vardus sistemoje:

AllowUsers fil saulius

Bei nurodant administratorių darbo vietos IP adresus (ar jų blokus) faile /etc/hosts.allow:

sshd: 11.1.1.2 11.1.1.3

Ir uždraudžiant priėjimą visiems kitiems faile /etc/hosts.deny:

sshd: ALL

(/etc/hosts.allow ir /etc/hosts.deny veiks tik tuomet jei sshd sukompiliuotas su tcpwrappers palaikymu. Patikrinti galima su komanda:

$ ldd `which sshd` | grep wrap
  libwrap.so.0 => /lib/libwrap.so.0 (0xb7719000)

Be to, labai patartina išjungti autentifikaciją slaptažodžiais (password-based) sshd (bent kritinėse sistemose) ir naudoti SSH raktus.

MySQL naudoja vidines priemones priėjimo kontrolei, todėl (jei tai įmanoma) kuriant naudotojus labai patartina nurodyti jų priėjimo šaltinio adresą, duombazę darbui bei būtinas teises. Mūsų pavyzdyje, naudotojas wwwintra.pvz.lt prieina prie duombazės wwwdb ir turi nurodytas SQL vykdymo teises:

CREATE USER 'www'@'intra.pvz.lt' IDENTIFIED BY 'slaptasslaptazodis';
GRANT SELECT,INSERT,DELETE,UPDATE ON wwwdb.* TO 'www'@'intra.pvz.lt';

DNS paslaugos apribojimai dažnai būna tokie:

  • Leisti zone transfer aukštesnio lygio bei žemesnio lygio DNS serveriams
  • Leisti rekursines užklausas savo organizacijai

BIND serverio atveju tai įsikūnija į named.conf.options eilutes:

options {
  allow-transfer {  10.1.0.2; 195.8.218.44; };
  allow-recursion { 10.0.0.0/8; }
}

Apache serverio priėjimo kontrolė vykdoma su allow from ir deny from. Dažniausiai naudojamos schemos yra tokios (naudojamos viduje <Directory> arba <Location> direktyvų blokų):

Leisti iš visų adresų, išskyrus tam tikrus (piktadariai iš Kinijos):

Order Allow,Deny
 Allow from all
 Deny from 60.0.0.0/11 

Leisti tik iš organizacijos tinklų, neleisti iš visų kitų:

Order Deny,Allow
 Deny from all
 Allow from 10.0.0.0/8 

Leisti iš organizacijos tinklų, išskyrus potinklį 10.1.1.0/24:

Order Allow,Deny
 Allow from 10.0.0.0/8
 Deny from 10.1.1.0/24 

Allow from ir Deny from direktyvos gali kartotis ir/arba turėti keletą adresų ar subdomenų, atskirtų tarpu.

Čia buvo tik keletas pavyzdžių, kitų servisų priėjimo kontrolė apibrėžiama kitaip, patartina peržiūrėti konfigūracijos failus. Konfigūracijos failus Debian/Ubuntu sistemose galima surasti su komanda (pvz., ieškome courier-pop paketo konfigūracija):

  $ dpkg -L courier-pop | grep /etc
  /etc
  /etc/courier
  /etc/courier/pop3d
  /etc/logcheck
  /etc/logcheck/ignore.d.server
  /etc/logcheck/ignore.d.server/courier-pop
  /etc/logcheck/violations.ignore.d
  /etc/logcheck/violations.ignore.d/courier-pop
  /etc/pam.d
  /etc/pam.d/pop3
  /etc/init.d
  /etc/init.d/courier-pop

Jei priėjimo kontrolė iš servisų ir tinklo pusių kartu jums atrodo paranojiškai, galima naudoti tik vieną iš jų, tačiau patartina padaryti sprendimą pagal serverio/serviso svarbumo lygį, kurio paskirtis ir yra įtakoti šį ir panašius sprendimus.

2. Užtikrinti paslaugų pasiekiamumą

Paslaugos diegimas apima instaliaciją, konfigūraciją, testavimą ir paleidimą. Po šito momento paslauga tampa veikiančia, ir kad užtikrinti jos pasiekiamumą, reikia laikas nuo laiko ją testuoti. Jei paslaugos veikimas sutrikdytas, reikia identifikuoti ir išspręsti problemą. Kadangi priežastis gali būti pačioje paslaugos programinėje įrangoje, jos darbą užtikrinančioje sistemoje, arba kitose paslaugose, nuo kurių ji priklauso, labai svarbu vykdyti bendrą sistemų bei paslaugų monitoringą. Šiai užduočiai atlikti plačiausiai naudojamos sistemos yra Nagios ir Zabbix. Dėl administravimo patogumo bei automatinio sistemų aptikimo rekomenduojamas brolių latvių sukurtas Zabbix. Jis turi pakankamai daug šablonų sistemų ir tinklo įrangos apkrovimui, diskams bei RAM išnaudojimui stebėti, o taip pat leidžia paprastai rašyti specifinius testus, tokius kaip DNS užklausų per sekundę skaičius, MySQL prisijungusių naudotojų skaičius ir t.t. Tokiu būdu, monitoringas leidžia operatyviai gauti perspėjimus dėl įvykusių gedimų, prognozuoti diskų išnaudojimą ateityje, o taip pat stebint sistemų apkrovimą užtikrinti paslaugų kokybę ir esant reikalui perkelti paslaugą į galingesnę sistemą.

Nors monitoringas leidžia pastebėti problemą, tačiau hardwaro gedimo arba failų sistemos loginės korupcijos atveju padėti gali tik atstatymas iš atsarginių kopijų (backup’ų), kas užima sąlyginai daug laiko ir atsarginė kopija dažniausiai atsilieka nuo darbinės. Turint tą omeny, palaikyti paslaugų pasiekiamumą (t.y. minimizuoti downtime) galima skirtingais būdais:

  1. Dubliuoti sistemas, kaip mūsų pavyzdyje dns1.pvz.lt ir dns2.pvz.lt. Tokiu atveju, jei dns1 lūžta, jo IP galima priskirti dns2 kaip interfeiso alias’ą (arba net automatizuoti tokį dalyką per monitoringą), ir DNS paslauga vėl bus pasiekiama. Dubliavimas plačiau naudojamas aukšto svarbumo lygio sistemoms (laikant vieną kopiją atsargine). Taupant resursus, galima dubliuoti sistemą į virtualią mašiną ir laikyti ją išjungtą, kol neįvyks gedimas.

  2. Balansuoti paslaugas (per load balancer’į) – panašu į sistemų dubliavimą, tik dubliuotų (vienodų) sistemų gali būti tiek, kiek reikia paslaugos kokybei užtikrinti + N atsarginių. Tai yra aukšto pasiekiamumo ir plečiamumo (high availability/high scalability) sprendimas, tačiau nevisas paslaugas galima lengvai balansuoti (ypač laikančias sesijas), ir pats balanceris yra dar vienas gedimo taškas.

  3. Virtualizuoti sistemas. Turint mažiausiai 2 galingus hypervizorius galima padidinti pasiekiamumą perkeliant virtualias mašinas iš sugedusio hypervizoriaus į veikiantį (atsarginį). Kitas variantas – hypervizorius su virtualizuotomis turimų fizinių sistemų kopijomis. Tokiu atveju sugedus fizinei sistemai laikinai pakeliamas virtualus jos analogas.

Visi paminėti sprendimai yra gana sudėtingi ir neišsprendžia duomenų sinchronizavimo problemos tarp dubliuojamų sistemų. Nors vienas iš sprendimų būtų laikyti duomenis atskirai nuo sistemų patikimoje duomenų saugykloje, tačiau tai gali neigiamai įtakoti našumui bei duomenų vientisumui iškilus tinklo problemoms.

Daugelis bandymų, atliktų VGTU, parodė, kad paprastesnis ir patikimesnis sprendimas yra naudoti LXC (Linux Containers, BSD analogas – Jails, Solaris analogas – Zones) kad išspręsti patikimumo/pasiekiamumo/našumo/atsarginių kopijų darymo problemas. Pagrindinės LXC savybes:

  • Leidžia įkrauti guest Linux sistemą (konteinerį) iš subkatalogo.
  • Izoliuoja konteinerio procesus ir tinklo interfeisus nuo host’o.
  • Leidžia valdyti konteinerio resursų išnaudojimą.
  • Itin mažas, < 1% virtualizacijos overhead.
  • Konteinerio sukūrimas, paleidimas, sunaikinimas užima keletą sekundžių.
  • Administravimas galimas ir nepaleisto konteinerio, tiesiog redaguojant jo failus arba su chroot() į konteinerio katalogą.
  • Plikas minimalus Linux konteineris užima ~200MB.

LXC turi ir minusų:

  • konteineriai dalinasi kernelį su hostu
  • palaikomas tik Linux (geriausia kai host ir guest OS versijos yra vienodos arba nedaug besiskiriančios)

VGTU atveju minusai yra nereikšmingi (Windows serveriams jau naudojamas Hyper-V, o visame Linux ūkyje naudojama Ubuntu distribucija). LXC naudojimo planas:

  • Fiziniai serveriai yra hostai.
  • Hostai montuoja NFS failų sistemą su konteinerių katalogais iš duomenų saugyklos.
  • Prieš paleidimą konteineris kopijuojamas į lokalų diską arba su cachefs paleidžiamas tiesiai iš saugyklos.
  • Laikomasi principo „vienas konteineris – viena paslauga“.
  • Hosto gedimo atveju konteineris paleidžiamas ant kito (mažiausiai apkrauto) hosto.
  • Nauji serverių konteineriai sukuriami iš paruoštų šablonų, kuriuose jau sukonfigūruotas monitoringo agentas, nuotolinis loginimas, ugniasienė, sukurtos administratorių paskyros.
  • Kas naktį (arba dažniau) daromas konteinerių incremental snapshot į saugyklą su glastree.

3. Apsaugoti nuo neautorizuotų modifikacijų

Tikslas – modifikacijos neturi likti nepastebėtos. Priklausomai nuo sistemos svarbumo lygio, tai gali būti arba /etc katalogo, arba visų sisteminių failų md5sum() skaičiavimas ir rezultatų palyginimas su ankstesniais (svarbu, kad etalonai būtų nepasiekiami modifikacijai iš stebimos sistemos). Programinės įrangos duomenis, ypač tie, kurie keičiasi dažnai (pvz, MySQL bazės), sudėtingiau apsaugoti nuo modifikacijų. Čia didžiausią vaidmenį atlieka prieigos kontrolė ir teisių ribojimai (kaip aptarta anksčiau). Itin svarbioms paslaugoms galima taip pat pritaikyti MD5 skaičiavimus – tam reikia identifikuoti ir atskirti duomenis, kuriuos reikia stebėti. Pvz, jei MySQL saugo svarbus duomenis lentelėje ir jų modifikacijos turi būti stebimos, tai galima tokią lentelę ištraukti su mysqldump ir tada skaičiuoti jos MD5 ir/arba naudoti versijavimą (pvz, su git arba svn). Versijavimas taip pat geras būdas stebėti konfigūracijos modifikacijų istoriją. Be abejo, modifikacijos aptikimai turi būti integruoti į stebėjimo sistemą.

4. Apsaugoti nuo apsimetinėjimų

Šioje srityje plačiausiai naudojamas būdas apsisaugoti – naudoti patikimus pripažintus sertifikatus, kas su LitNet TCS paslauga yra labai paprasta. Naudojant SSL sertifikatus svarbu saugoti privačius raktus, ir atšaukti sertifikatą jei įtariamas privataus rakto nutekėjimas. Apsaugoti raktą su slaptažodžiu yra problematiška WWW serverio atveju, kadangi teks vesti slaptažodį serverio starto metu (tai saugiau, bet paranojiška ir gali neigiamai įtakoti paslaugos pasiekiamumui, kadangi automatinis paleidimas tampa negalimas), bet būtina bent įsitikinti, kad privataus rakto failo savininkas yra root, ir pats failas nėra world-readable/writable.

SSH atveju sutikti vieši raktai yra saugomi .ssh/known_hosts ir SSH automatiškai perspėja jei jau matyto serverio sertifikatas pasikeičia. Tokiais atvejais reikia įsitikinti, kad rakto pasikeitimas yra teisėtas (pvz, perinstaliuotas serveris).

5. Užtikrinti logų kaupimą

Kaupti logus reikia incidentų tyrimams, problemų sprendimams bei statistikai, bei siekiant atitikti įstatymų reikalavimams. Pagal nutylėjimą šiuolaikinės UNIX-like sistemos saugo savo logus /var/log kataloge ir „apsuka“ juos pagal /etc/logrotate.d konfiguraciją. Turint daug serverių patartina naudoti centralizuotą logų kaupimą. Tai suteikia sekančius privalumus:

  • Ekonomiškiau – taupoma vieta serveriuose.
  • Saugiau – įsilaužimo į vieną iš serverių atveju, kai logai pratrinami, jie vis tiek liks centrinėje logų kaupykloje.
  • Paprasčiau – palengvina paiešką kai reikia koreliuoti įvykius.

Standartinis syslogd turi galimybę siųsti/gauti syslog pranešimus, tačiau kai reikia daugiau kontrolės (ateinančių logų filtravimas pagal šaltinius/lygius/programas, dislokacijos išskirstymas ir pan.) labai gerai tinka syslog-ng. Centralizuoto logų kaupimo schema gali būti tokia:

  • Kiekvienas serveris sukonfigūruotas siųsti logus į centrinę kaupyklą ir saugo logus lokaliai 7 dienas (administravimo patogumui).
  • Centrinė kaupykla priima logus iš serverio potinklio.
  • Centrinė kaupykla rašo logus į failus su siuntėjo hosto vardu pavadinime.
  • Kas naktį praeitos dienos logai perkeliami į katalogus pagal datą. Pvz, /logs/2012/02/01/.
  • Po 7 dienų logų failai suspaudžiami su gzip.
  • Lygiagrečiai kaupykloje atskiriami aukšto prioriteto (critical, alert, emergency) bei autentifikacijos (auth facility) pranešimai ir saugomi atskiruose failuose.

Greitai paieškai per web interfeisą realizuoti galima visą logų srautą praleisti pro filtrus, atmetančius neesminius pranešimus, konvertuoti srautą į SQL INSERT komandas ir rašyti į FIFO soketą, iš kurio pastoviai skaitantis mysql procesas jas įvykdys. Turint logus SQL indeksuotoje duombazėje galima ne tik greitai vykdyti paiešką, bet ir kontroliuoti priėjimą prie jos skirtingiems naudotojų grupėms (pvz, tinklo administratoriai gali matyti tik tinklo įrangos logus).

6. Papildomos saugumo priemonės ir procesai

Priklausomai nuo sistemos svarbumo lygio galima suplanuoti ir papildomų priemonių diegimą, tokiu kaip IDS (pvz, snort su saikingu taisyklių rinkiniu), automatinius juoduosius sąrašus (pvz,log2ban, kuris blokuoja įtartinus šaltinius ugniasienės lygyje), NetFlows anomalijų aptikimus, periodinius trojanų buvimo patikrinimus su chkrootkit.

Gera papildoma apsauga Linux sistemose yra AppArmor, kurios esmė – ribotų galimybių suteikimas konkrečiam paleidžiamam failui pagal nurodyta šabloną (papildomai prie standartinio owner-permission mechanizmo). Pvz, galima nurodyti kuriuos konkrečius failus galima skaityti, į kuriuos katalogus galima rašyti, o taip nurodyti konkrečias galimybes (POSIX 1003.1E capabilities), tokias kaip CAP_NET_BIND_SERVICE jei procesui galima klausyti porto. Daug programų paketų Ubuntu Linux distribucijoje ateina su paruoštais šablonais, kurie įsigalioja po instaliacijos, bet esant reikalui nesunku ir pačiam parašyti šablonus pagal analogiją. Panašias į AppArmor galimybės suteikia SELinux bei GRSecurity.

Atskirai reikia paminėti apie informacijos nutekėjimo prevencijos svarbumą – VISOS paslaugos, kur naudojama autentifikacija, sesijos arba keliami svarbūs duomenys PRIVALO būti apsaugoti šifruotu kanalu. Tai gali būti kaip specialiai pritaikytas servisas (pvz, courier-pop-ssl), taip ir rankiniu būdu sukurtas SSL tunelis (pvz, Oracle-to-Oracle per stunnel).

Galimų saugumo pažeidimų prevencijai yra naudinga stebėti specifinius informacijos šaltinius – gamintojų tiekiamus saugumo pranešimus, CERT pranešimus, o taip pat mailing list’us, tokius kaip „Full Disclosure“ (http://seclists.org/fulldisclosure/), kur galima gauti ankstyvą informaciją apie galimus pažeidžiamumus ir kartais surasti paruoštą workaround’ą, kol gamintojas paruoš saugumo pataisymą.

Priemonių diegimas

Į serverius diegiamos visos suplanuotos priemonės, į monitoringą – priemonių kontrolė:

  • dns1.pvz.lt

    • ssh leisti iš 11.1.1.2 (iptables) + vartotoją fil (sshd_config) + autentifikaciją tik per SSH raktus.
    • named leisti rekursiją iš organizacjos tinklų (named.conf) + leisti zonų perkėlimą iš dns2.pvz.lt ir nemunas.sc-uni.ktu.lt (named.conf).
    • papildomai, chkrootkit kas naktį.
  • dns2.pvz.lt
    • ssh leisti iš 11.1.1.2, 11.1.1.3 (iptables) + vartotojus fil, saulius (sshd_config) + autentifikaciją tik per ssh raktus.
    • named leisti rekursiją iš organizacijos tinklų (named.conf) + leisti zonų perkėlimą iš nemunas.sc-uni.ktu.lt (named.conf).
    • papildomai, chkrootkit kas naktį.
  • db.pvz.lt
    • ssh leisti iš 11.1.1.2, 11.1.1.5, 11.1.1.6 (iptables).
    • mysql leisti iš intra.pvz.lt (iptables, mysql) vartotojui www (mysql).
  • intra.pvz.lt
    • ssh leisti iš 11.1.1.2, 11.1.1.5, 11.1.1.6 (iptables).
    • webmin leisti iš 11.1.1.2, 11.1.1.5 (iptables)
    • apache leisti priėjimą tik iš organizacijos tinklų (iptables, apache2.conf)` + SSL sertifikatas.
  • Visiems serveriams
    • syslogd siųsti pranešimus į logs.pvz.lt.
    • visų servisų procesai veikia su AppArmor šablonais.

 

Taip pat reikia suplanuoti programinės įrangos atnaujinimo politiką. Ji galėtų būti tokia (Ubuntu Linux atvejis):

  • Sistemos naudoja serverinės LTS distribucijos versijas (išleidžiamos kas 2 metus, 5 metus palaikomos).
  • Kuo greičiau diegiami saugumo atnaujinimai (pagal poreikius/galimybes prieš tai atlikus testavimą).
  • Distribucijos atnaujinimai (dist-upgrade) vykdomos centralizuotai, kad palaikyti vienodą distribucijos versiją.
  • Kiek įmanoma, naudojama programinė įranga stable versijos, o ne testing arba experimental.

Rezultatų įvertinimas

Saugumo užtikrinimo procese svarbu suplanuotais intervalais vykdyti rezultatų vertinimą, nagrinėjant logus, įvykusius saugumo incidentus bei statistiką. Nagrinėjant kurį nors incidentą gali neužtekti logų, operatyvūs logai gali būti užteršti pasikartojančia nereikšminga informacija. Turint paslaugų naudojimosi statistiką galima įvertinti ir prognozuoti sistemos apkrovimus. Saugumo incidentų bei help desk’o problemų statistika gali būti reikšmingi įdiegtų saugumo priemonių efektyvumo rodikliai.

GOTO 10

Visos aptartos procedūros formuoja saugumo užtikrinimo procesą, kuris su kiekviena iteracija leidžia padidinti saugumo užtikrinimo efektyvumą bei aktualumą. Šis procesas turi atitikti organizacijos saugumo politiką, arba tapti vienu iš jos formavimo pagrindu. Svarbiausia nepamiršti, kad:

  1. Visa sistema tiek saugi, kiek saugi jos silpniausia grandis.
  2. Sudėtingumas yra saugumo priešas.
  3. Žioplių daugiau nei jūs galvojate.