---

Hej med jer,

jeg sidder lige og læser om noget IT-sikkerhed (DS484) og her nævnes
"logiske bomber", men hvad er det egentlig? Er det sådan noget DOS-angreb
eller, hvad?

Devast8or

---

Devast8or <invalid@invalid.invalid> wrote:
> jeg sidder lige og l?ser om noget IT-sikkerhed (DS484) og her n?vnes
> "logiske bomber", men hvad er det egentlig? Er det s?dan noget DOS-angreb
> eller, hvad?

"bomber" der springer naar en logisk betingelse er opfyldt. Det
klassiske eksempel er at udvikleren bag loensystemet der lader
appliktionen goere noget slemt den dag hans navn ikke laengere staar i
loendatabasen.

Et meget omtalt tilfaelde er da Tim Lloyd oedelagde vigtige systemer hos
sin arbejdsgiver, Omega Engineering:

http://www.nwfusion.com/research/2000/0626feat.html

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Alex Holst wrote:
> Devast8or <invalid@invalid.invalid> wrote:
>> jeg sidder lige og l?ser om noget IT-sikkerhed (DS484) og her n?vnes
>> "logiske bomber", men hvad er det egentlig? Er det s?dan noget
>> DOS-angreb eller, hvad?
>
> "bomber" der springer naar en logisk betingelse er opfyldt. Det
> klassiske eksempel er at udvikleren bag loensystemet der lader
> appliktionen goere noget slemt den dag hans navn ikke laengere staar i
> loendatabasen.

Ah, ok. Mange tak for det.

> Et meget omtalt tilfaelde er da Tim Lloyd oedelagde vigtige systemer
> hos sin arbejdsgiver, Omega Engineering:
>
> http://www.nwfusion.com/research/2000/0626feat.html

Det ser spændende ud, det vil jeg læse når jeg får tid.

Ved du noget om hvordan man kan sikre sig mod at sådan noget sker, eller
står der noget i artiklen om det?

Devast8or

---

Devast8or <invalid@invalid.invalid> wrote:
> Ved du noget om hvordan man kan sikre sig mod at s?dan noget sker, eller
> st?r der noget i artiklen om det?

Det handler mest af alt om at kunne stole paa folk, og kan man ikke det,
kan audit trails i baade applikations og host aendringer maaske have en
forbyggende effekt.

Hvis man ikke kan slippe afsted med at lave en ondartet aendring, uden
at det tydeligt kan ses paa forhaand hvem der forsoeger paa hvad, vil
nok selv den mest disgruntled medarbejder holde sig vaek.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Alex Holst wrote:
> Devast8or <invalid@invalid.invalid> wrote:
>> Ved du noget om hvordan man kan sikre sig mod at s?dan noget sker,
>> eller st?r der noget i artiklen om det?
>
> Det handler mest af alt om at kunne stole paa folk, og kan man ikke
> det, kan audit trails i baade applikations og host aendringer maaske
> have en forbyggende effekt.

Audit trails, det har jeg ikke hørt før. Det lyder som noget med at logge
hvad der er lavet af ændringer i et program, så man kan gå tilbage og se
det - rigtigt?

> Hvis man ikke kan slippe afsted med at lave en ondartet aendring, uden
> at det tydeligt kan ses paa forhaand hvem der forsoeger paa hvad, vil
> nok selv den mest disgruntled medarbejder holde sig vaek.

Det har du helt ret i :)

Devast8or

---

Den 08 aug 2004 mumlede Devast8or noget i denne stil:

> Audit trails, det har jeg ikke hørt før. Det lyder som noget med
> at logge hvad der er lavet af ændringer i et program, så man kan
> gå tilbage og se det - rigtigt?

Stødte lige på denne her:

http://www.cerias.purdue.edu/homes/rgk/at.html#intro



--
Palle Jensen

---

Palle Jensen wrote:
> Den 08 aug 2004 mumlede Devast8or noget i denne stil:
>
>> Audit trails, det har jeg ikke hørt før. Det lyder som noget med
>> at logge hvad der er lavet af ændringer i et program, så man kan
>> gå tilbage og se det - rigtigt?
>
> Stødte lige på denne her:
>
> http://www.cerias.purdue.edu/homes/rgk/at.html#intro

Kanon. Der er meget at læe, så det bliver når meg får tid, men
introduktionen fortalte mig hvad det går ud på, så det er fint.

Mange tak til jer begge.

Devast8or

---

>Ved du noget om hvordan man kan sikre sig mod at sådan noget sker, eller
>står der noget i artiklen om det?

>Devast8or


Det er mest sund fornuft. Hvis du vil sikre dig mod en utilfreds
exmedarbejder, så checker du med jævne mellemrum at du kan retablere
biksen på basis af noget, som andre ikke kan pille ved.
Og ja, det er formentlig både dyrt og besværligt, så det er en klar
vinder, hvis man er sikker på at kunne stole på folk.
Hvis biksen er stor nok, så er det formentlig næsten
uladsiggørligt, men hvis den er så stor, burde der også være en
backupinstallation, som man jo så kan bruge til at checke
disaster-recovery planen med.

I mine øjne er det her bare en blandt mange scenarier for hvad der
kan ske. Man kan ikke gardere sig 100%, men man kan tænke over
hvor mange 9-taller man vil købe i 99,99999% sikker.
Jeg så engang en tommelfingerregel om at hvert 9-tal kostede det
samme som alle de foregående tilsammen, men om det passer i
praksis ved jeg ikke. I nogle sammenhænge er det formentlig værd
at købe mange 9-taller. Fx vil Maersk-Sealand nok nødig stå i den
situation at deres database over containere ryger sig en tur.

mvh Birger Nielsen (bnielsen@daimi.au.dk)