Nagu kommentaarides mainitud, olen ka mina nõus, et 4 tundi kuus on liiga madal. Mõistke ja mis veelgi tähtsam, andke oma sidusrühmadele mõista, et 4 tunni pärast ei tohiks nad palju oodata. Arvestades, et nad on teile andnud 4 tundi, ei tundu, et nad ka selle rakenduse turvamisega tõsiselt tegeleksid.

Püüan kommentaaride, vastuste ja enda mõtete põhjal midagi kokku panna. Minu arvates peaksid teie võimalused korras välja nägema.

1. Küsige rohkem aega. Andke neile mõista, kui nad tahavad rakendust turvata vaid 4 tunniga, see on praktiliselt kasutu.
2. Palgake agentuur ja veetke oma 4 tundi nende ulatuse määratlemisel, nende tegevuste tähtsuse järjekorda seadmisel ja tulemuste ülevaatamisel. (@Nelson)
3. kui te ei saa ülaltoodut teha, soovitaksin madalate rippuvate puuviljade kinnitamist, nii et katate 4h jooksul rohkem maad. Siin on minu arvates olulised
   • seadistage oma väliseid teenuseid värskendama. (~ 1h, et leida ja seadistada olulised rakendused värskendamiseks). Sulgege mittevajalikud pordid / teenused, mis pole teile kasulikud.
   • Seadistage MFA (~ 10 minutit) - kuna teil pole palju aega, seadistage kiiresti asjad, kaitske teid levinud rünnakute eest ja hoiatab teid.
   • Vaadake üle oma saladused - veenduge, et need oleksid turvaliselt salvestatud, käskige koodil skannerid, et leida raskesti kodeeritud saladusi. (~ 1h)
   • Katastroofi taastamine - ma soovitaksin kulutada mingi osa oma väärtuslikust 4 tunnist kaitsete seadistamiseks, kui asjad valesti lähevad, sest nii lähevad. Alustage varukoopiate (võimaluse korral 2) loomist erinevates tsoonides. Eeldan, et platvorm aitab teil seda teha, kuid see võtab siiski aega. Selle aja jooksul saate koostada ka ligikaudse katastroofide taastamise kava. (~ 1,5 h)
   • lõpuks dokumenteerige, kui vähest aega on jäänud. Dokumenteerige, mida olete teinud, mida te pole teinud ja millised peaksid olema järgmised sammud järgmisel korral, kui keegi saab rakenduse täiendavaks turvamiseks 4h. (~ järelejäänud)

DoS-kaitse on hea ja nõutav, kuid ma lihtsalt ei leidnud viisi, kuidas seda ülaltoodud plaaniga sobitada, ja ma ei suutnud ka selle vastu midagi välja vahetada. Võib-olla tuleks see järgmistes toimingutes dokumenteerida.

Üldiselt on see kaugelt otsitud taotlus midagi 4 tunni jooksul turvata. Aga kui mulle see tehtaks, teeksin seda ülaltoodud sammudega. Ma pole kindel, kas nende 4 tunni jooksul on võimalik uurida, kas süsteemi on juba sisse häkitud. Kui teile antakse turvalisuse tagamiseks 4 tundi, võite selle kas kulutada rakenduse kaitsmiseks võimalike ohtude eest või uurida oma süsteemi ründajate jaoks (vajab teistsugust plaani). See esmane valik on teie.

Alustage Azure tippturvalisuse parimatest tavadest, et saaksite oma Azure'i lahenduse turvalisust samm-sammult hooldada ja parandada:

1. leppige kokku ja värskendage oma Azure'i tellimus Azure Security Center Standardile. See aitab teil leida ja parandada turvanõrkusi, rakendada juurdepääsu ja rakenduste juhtelemente pahatahtliku tegevuse blokeerimiseks, analüüside abil ohtude tuvastamiseks ja rünnakutele kiireks reageerimiseks;
2. salvestage oma võtmed, andmebaasi mandaadid, API võtmed ja sertifikaadid Azure Key Vault. Lisaks veenduge, et lahenduse võtmeid ja saladusi ei salvestataks rakenduse lähtekoodi;
3. installige veebirakenduse tulemüür (WAF), mis on Application Gateway funktsioon ja kaitseb teie veebirakendust levinud ekspluateerimise eest ja haavatavused;
4. sundida administraatorikontode jaoks mitme teguri kinnitamist;
5. krüptima oma virtuaalsed kõvakettafailid;
6. ühendada Azure'i virtuaalmasinad ja -seadmed teiste võrku ühendatud seadmeid, paigutades need Azure'i virtuaalsetesse võrkudesse;
7. leevendage DDoS-i ja kaitske selle eest DDoS Protection Standardiga, mis pakub täiendavaid leevendusvõimalusi;

Kui olete 1–7-ga valmis, keskenduge järgmistele.

8. oma VM-i värskenduste haldamine, kuna Azure ei lükka Windowsi värskendusi automaatselt
9. veenduge, et seadistaksite oluliste pilvetoimingute jaoks protsessid nagu plaastri haldamine, varundamine, juhtumite haldamine muudatuste haldamine, erakorraline juurdepääs kasutajale, privilegeeritud juurdepääs;
10. lubage paroolihaldus ja väärkasutuse vältimiseks kasutage sobivaid turvapoliitikaid;
11. vaadake üle oma turbekeskuse juhtpaneel, et säilitada ülevaade turvalisuse olekust kõik teie Azure'i ressursid, nii et kui vaja, võite soovituste osas toimida;

Lugege Microsofti dokumentatsiooni Azure'i turbetöö heade tavade kohta.

Dokumentatsioon :

Microsoft Azure'i turvalisuse põhialused

Microsoft Azure'i turbedokumentatsioon

See on vasakpoolse välja vastus (ehk sel on tegeliku turvalisusega vähe pistmist), nii et ignoreerige minu nõuandeid julgelt. See küsimus on iseenesest üsna arvamuspõhine, nii et mõtlesin, et prooviksin hoopis teistsugust "tüüpi" vastust.

Teile on pandud rakenduste turvalisus. See on hea asi!

Kahjuks ootab teie tööandja rakenduse turvalisuse tagamiseks väga ebareaalset ootust. 4 tundi pole piisavalt lähedal, et seda tööd hästi teha. Selguse huvides on see siiski parem kui enamikul ettevõtetel (kes määravad täpselt 0 tundi kuus spetsiaalset turvaaega). Reaalsus on siiski see, et 4 tundi on piits. Nii teete seda:

1. kandideerige kõigi soovitustega, mida inimesed siin esitavad
2. kulutage palju rohkem kui 4 tundi kuus
3. vältimiseks muutes tööandja õnnetuks või otsustest eiramatuks, tehke lisatööd ise. Plaanige järgmise paari kuu jooksul veeta regulaarselt palju lisatunde.
4. Sel ajal saate teada näiteks turvanõrkuste koodi ülevaatamisest, SEIM-süsteemide installimisest ja kasutamisest. logimissüsteemide (tavaliselt kasutatakse ELK-i virna), sissetungimise tuvastamise süsteemide, rakenduste automaatse skannimise ja muu installimine ja kasutamine! (täielik nimekiri on ilmselt liiga pikk, õppige see kõik mõne kuu tööga vabal ajal, kuid andke endast parim!)
5. Teie ettevõte saab lõpuks kasu teie tasuta tööjõust, mis on natuke kurb, kuid ...
6. Teil on hea võimalus ennast turvatöötajaks koolitada (kui soovite ametinimetust, olete teel Rakenduseks Turvainsener) osana oma ametikohustustest, tagades tootmisel kasutatava tegeliku veebirakenduse!
7. hakake kandideerima oma järgmisele töökohale rakendusturbeinsenerina. Tõenäoliselt leiate parema töö, mis teeb lõbusamat tööd, ja tõenäoliselt saate ka paremat palka!

Ilmselgelt ei saa ma anda mingeid garantiisid selle kohta, kuidas asjad välja kukuvad, kuid tegelikult on teile antud luba hakata ennast karjäärimuutuste jaoks koolitama. Võimalus investeerida oma tulevikku! Turvaspetsialistid on isegi inseneride järele nõutumad, nii et isiklikult võtaksin selle ja jookseksin sellega kaasa. Eriti kui see minu kasuks tuleks, ei heidaks ma isegi oma praegust tööandjat selle tasuta töö eest, mida neile lühinägelikkuse tõttu anda kavatsesin.

Soovitaksin

1. alustage riskihindamise tegemisega
2. koostage siin toodud loendid (nii ise kui ka vastustes) ) vaidlustatavateks üksusteks
3. Minge tulemusega tagasi ülemuste juurde ja küsige kas rohkem aega või nende prioriteetsust.

Nagu teised on juba 4 tundi maininud, on liiga vähe vaeva, kuid annan mõned soovitused juhuks, kui leiate, et neist on kasu.

• Käivitage haavatavuse skanner, näiteks Qualys või muu sarnane. See kogub mitmeid kasulikke rakenduste haavatavusi, nagu XSS, SQL-i süstimine, CSRF ja muud sarnased.
• Käivitage koodi ülevaatuse tööriist, et tuvastada ilmseid halbu tavasid (st mitte pääseda kasutaja sisendist õigesti enne andmebaasi saatmist)
• installige hea sisemine (hostipõhine) ja väline ( serva- või pilvepõhine) WAF, mis kaitseb OWASP-i ohtude ja muu eest. Mitmed pilvepõhised WAF-id kaitsevad ka DDoS-i ja mõne toore jõu rünnakute eest.
• Eraldage oma infrastruktuur usalduse abil vlan-tsoonideks ja tagage nende vahel minimaalne andmevoog (nt Edge, esitlus, äriloogika, andmed)
• Keegi teine ​​mainis seda varem, kuid väga oluline: veenduge teile salvestame privilegeeritud mandaadid (API võtmed, db krediidid jne) lähtekoodist eraldi.
• karastage kogu infrastruktuur.
• See võib võtta aega, kuid ma soovitaksin teil koostada kuumakaart või tasakaalustatud turvariskide tulemuskaart ja tagada, et see oleks ka teie vanematele sidusrühmadele nähtav. Hea turvapraktika võib riski vähendada, kuid ükski neist pole omaette hõbekuul.

Eeldan, et rakendus on äärmiselt väike, kirjutate logidele skripte, et asju kohatu otsida (ideaalis seda nelja tunni tööperioodil ei tehta), katastroofi taastamine peaks olema juba suuremate jaoks olemas rakendus (kontrollige, kas rakendus nõuab sellist pingutust.).

1. Dokumentatsioon on ülioluline, kuna see peaks andma teada, mida kasutatakse ja kes seda kasutab, kui sageli ka. See aitab skripti välja töötada.

2. Kuu logide tihendamiseks on vaja skripte, nii et valige see hoolikalt.

3. Kontrollige varukoopiaid.

4. Kontrollige alati kasutatavaid tehnoloogiaid ja kas on olemas POC-i või ärakasutamist. Ärge hüpake sellesse ja proovige ennast ära kasutada, teil on ainult 4 tundi.

5. Kui rakendus on ülioluline, taotlege täiendavat tuge.

Ideaalis peaks ainult dokumentatsioon ja skriptimine võtma aega, puhkeaja peaks olema üsna lihtne. See pole parim, mida peate projekti väärtuse määrama ja valima, kas 4h on piisav.

Sihtmärgi mõistmine aitab teil seda paremini kaitsta.

Olen kindel, et leidub parem vastus, loodetavasti nad selle ka annavad.

OP, tundub, et olete peamiselt arendaja, vaadates teie kaastöid. Mida saab arendaja turvalisuse suurendamiseks teha?

Esimesel kuul:

• 2 tundi: proovige versiooniga kokku puutuda mõned välised sõltuvused / komponendid / teegid ja proovige rakenduse uuesti ülesehitamiseks. Kui ebaõnnestute, dokumenteerige vastuolud.
• 2 tundi: tehke kõik, mis on vajalik teie enda muudatuste edastamiseks läbi CI / CD, testimise, master haru kaudu ja tootmisse. Proovige muud arengut tagasi lükata, kui neid on, kuid pöörake sel juhul erilist tähelepanu sellele, et jätaksite suusarajad, kus olete tegelikult midagi kasulikku teinud (nt kirjutanud mõned PR-id).

Korrake iga kuu, kuid korrigeerige nende kahe vahelist eraldusjoont. (Võimalik, et lõplik jagamine on pigem 10 minutit versus 3 tundi 50 minutit.)

Nii saate parandada halvima vektori - et ühel populaarsel komponendil / teegil on mitu kuud avaldatud haavatavus ( CVE). Bottide sülemid hakkavad kogu haavatavat juurutamist kogu Internetti skannima. Kui täiendate lihtsalt kolmandate osapoolte komponente, isegi ainult (informeeritud?) Oletusi tehes, on korralik võimalus, et te ei saa kunagi ohvriks ega pea kunagi vaja tegelema ebameeldivate olukordadega.

See on arendajatele üsna tühine, kuid enamikus ettevõtetes väldivad arendajad sellist ebahuvitavat hooldust. See muutub tüüpiliste turvaosakondade jaoks suureks probleemiks (kuna nad ei kompileeri rakendusi uuesti). Suured jõupingutused "logide analüüsimiseks" või "WAF-ide rakendamiseks" või "haavatavuse skannimiseks" on mõeldud peamiselt selle tühimiku katmiseks kõigi võimalike nurkade alt.

Teie küsimusest näib, et te küsite, kuidas oma õppimist suunata. Tahaksin selle oletuse vaidlustada siin ja praegu. Kes eraldas teile 4 tundi kuus, katkestas juba oma rakenduse teie eneseharimisest kasu saamise. Neist vastutustundetu! Sellele projektile pühendatud sisu õppimiseks rakendage see, seejärel õppige oma vigu ja korrake ... Seda ei saa teha iga kuu nelja tunni kaupa. Ärge seda "parandage", sest see polnud teie otsus! Selle projekti ajal tehke asju, mida teate juba hästi.

See on algaja. See, mida proovite vabal ajal õppida ja rakendada, on teie eelistus ja teie enda asi. Ma arvan, et see on selle saidi jaoks liiga lai (kuna võib juhtuda, et otsustate, et teid ei huvita turvalisus, mis on täiesti hea), kuid teised andsid teile niikuinii hulgaliselt müügivihjeid. Kasulikke asju otsige ka teiste projektide käigus. Mõni esimene või teine ​​mahub selle nelja tunni sisse ja aitab projekti seisu parandada.

Süsteemiadministraatorilt, kes on pidanud selliseid asju tegema, soovitaksin luua lihtsalt arendaja VM, mille saate tootega vahetada.

1. Varundage oma server.
2. Eraldage oma andmebaasid oma serveritesse. Veenduge, et nad saaksid suhelda ainult ühe IP-aadressiga - tootmisserveri / teenusega, mis seda vajab. (Ühekordne muudatus, väga oluline.)
3. Kloonige põhiserver ja andke uuele teine ​​IP-aadress.
4. Tehke kõik vajalikud muudatused, värskendused, ülevaated ja kontrollid.
5. Kui 4-tunnine aken on saadaval, viige põhiteenused alla.
6. Varundage andmebaasid. KRIITILINE SAMM.
7. lükake kõik kohalikud muudatused peamistest kloonituteks.
8. Veenduge, et kõik näeks hea välja ja töötaks korralikult.
9. Vahetage IP-aadressid peamiste ja kloonitud vastu .
10. Kloonitud on nüüd peamine.
11. Tehke kõigest veel üks varukoopia. (Jah, tehke teine.)
12. Too põhiteenused üles.
13. Jätke teine ​​süsteem varuks varuks, kui midagi juhtub.

Te ei maini riske: kas see salvestab isikuandmeid jne. Kuid kui see on keeruline rakendus, siis on üks üsna ajaefektiivne lähenemisviis fuzz-testimine: eraldage logidest mõned kehtivad taotlused, muutke need sellised metamärgid, mis võivad olla süstimisrünnakus, ja teatage haavatavusest iga kord, kui saate tõrke 500. paistab, et oled. Ja haavatavuse muutmine ekspluateerimiseks võtab rohkem kui eelarves neli tundi.

Alternatiivne vastus: veetke aega oma CV lihvimiseks, sest see tööandja võib igal ajal oma tegevuse lõpetada.