Mainframes: Back to the future

CfCS udtrykker sig utroligt diplomatisk må man sige:

"Det er Center for Cybersikkerheds erfaring, at det blandt mange mainframeejere og -administratorer har været den fremherskende opfattelse, at mainframeinstallationernes tekniske kompleksitet i sig selv udgjorde en beskyttelse mod angreb."

Kun en meget tynd kniv kan klemmes imellem deres og min formulering af denne problemstilling.

For folk der ikke er inde i mainframe-lingo, kan resten af rapporten oversættes til UNIX-lingo nogenlunde således:

  • Antag at hackere kender alt til UNIX
  • Kunder bør ikke antage at deres UNIX leverandør/driftfirma har styr på tingene
  • Check alle jeres setuid/setgid programmer
  • Installer alle sikkerhedspatches med det samme.
  • Lad være med at løse problemer med "chmod 777" og setuid
  • Kør Tripwire eller lign.
  • Læs jeres logfiler
  • Følg op hvis der dukker nye uid==0 konti op i /etc/password
  • /etc/shadow skal ikke være world-readable
  • Sikkerhed er ikke en engangsopgave, det er en process
  • Ryd op i stedet for at gemme gamle ting "hvis nu man fik brug for det..."
  • Følg med i Advisories og opdateringer for jeres software
  • Revurder løbende hvem der skal have sudo adgang.
  • Sørg specielt for at holde apache opdateret og hold øje med .htaccess filerne
  • Hold op med at sætte jeres maskiner direkte på nettet, men brug DMZ offermaskiner med et mere egnet operativsystem til den opgave.

Stort de præcist samme anbefalinger gav jeg selv til folk med uddøende UNIX systemer (Unisys, NCR, DDE osv.) i starten af 1990'erne.

Man bør nok ikke ukritisk konkludere at Mainframes og deres besætninger er 25 år bag af dansen, men omvendt er det nok ikke 10% ved siden af.

For mange år siden lå der et lille dansk softwarehus der hed "S.O.S Data" inde på Gl. Kongevej. De havde et "central brugerdatabase" produkt, som tillod mainframeinstallationer at vedligeholde alle deres brugere i en database og så opdatere mainframe, OS/2, UNIX osv. fra denne centrale database.

Et af problemerne var at når de skulle vise produktet for en ny kunde var der altid inkonsistens i deres RACF databaser og derfor ville deres import program styrte om.

Derfor havde de skrevet et Visual Basic program "fra helvede" som det blev udtrykt og bad propektive kunder have den største PC med VB og masser af RAM klar til besøget.

Jeg var selv med på en tur til en Italiensk kunde, "det statslige forsikringsinstitut for invalidepension" eller noget i den stil og så hvorledes det foregik i praksis.

Efter de indledende høfligheder downloader man en kopi af RACF til PC'en (opstillet i systemfolkenes kontor) og den får lov til at tygge løs i parallel med den egentlig installation.

Jeg rodede f.eks med nogle Siemens SVR4 maskiner.

Men på et tidspunkt var jeg tilbage i systemfolkenes kontor og sludrer med den ene af dem, jeg havde selv været i Italien nogle år tidligere hos Olivetti og der var meget at snakke om.

Mens vi snakker kastede han et blik på skærmen hvor VB programmet havde skrevet noget med rødt (eller gult?) hvorefter han nærmest kastede sig hen over sit skrivebord og gav sig til at taste febrilsk.

Lidt senere indrømmede han lidt skamfuldt at den tidligere vicedirektør med mafia forbindelser stadig havde dial-in adgang og "ret mange rettigheder" når han kom ind.

De to folk fra S.O.S. data kiggede på hinanden "Så er den solgt, skal vi vædde ?" grinede den ene...

RACF er grundlæggende et ACL princip, Access Control Lists og oplevelsen gav mig anledning til at forhøre mig i andre kredse hvor godt det princip egentlig virkede for dem. Svaret var universelt: I teorien er det perfekt, i praksis bliver det et uigennemskueligt mareridt som aldrig kan holdes konsistent.

Hvis ACL's skal virke efter hensigten, skal de være utroligt finmaskede: "Bruger 345 kan interaktivt ændre kundedatabasens addressefelt indenfor normal arbejdstid fra terminalen på hendes skrivebord." Alt hvad der ikke er tilladt skal derefter være forbudt.

Sådan virker verden ikke i praksis, det er ikke realistisk at systemfolkene skal sidde og pille i RACF hver gang nogen er stand-in for en syg kollega.

Den indlysende løsning er at normaliserer ACL databasen: "Bruger 345 er i gruppe KUNDESERVICE", "KUNDESERVICE kun adgang via terminaler i gruppe ANDENSAL", "KUNDESERVICE kan rette addressefelt i kundedatabasen", "Terminaler i ANDENSAL kan bruges indenfor normal arbejdstid" osv. osv.

Og så kommer alle undtagelserne: "Vi skal arbejde i weekenden for at komme igennem kampagnepukklen", "Der er vandskade, så de deler terminaler med bogholderiet", "de skal også kunne rette telefonnummeret" osv. osv.

Gradvist bliver der malet med bredere og bredere strøg og nogle gange ovenikøbet med modsat fortegn: Alt hvad der ikke udtrykkeligt er forbudt i ACLs er tilladt.

Alle seriøse installationer jeg kender til har opgivet ACLs som primær sikkerhedsfacilitet.

I stedet slår man idag en jernring om installationen, stoler (nogenlunde) på dem indenfor og bruger ACL-lignende gateway faciliteter imellem "inde" og "ude": Firewalls, DMZ osv.

Bellovins og Cheswicks bog, der fastslog dette princip, udkom i 1994.

At CfCS finder det nødvendigt overhovedet at komme med den sidste anbefaling er derfor vidnesbyrd om ihvertfald nogle danske mainframe installationer vitterligt er ca. 20 år bagefter.

phk

Kommentarer (50)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
John niss Hansen

Endnu et eksempel på phks lettere selvhævdende, indforståede vrøvl.
Kunne du ikke tage og maile direkte til dem der formodes at forstå dit nonsens, frem for at spilde den almindelige læsers tid.

  • 2
  • 29
Poul-Henning Kamp Blogger

Mig bekendt kan man ikke lave remote logfiler på en mainframe.

I gamle dage kunne man logge direkte til en printer i real-tid.

Jeg vil ikke afvise at man stadig kan konfigurere dette og evt. lade en en pSeries (RS6K) Unix maskine emulere ESCON attached printer, men jeg har ikke hørt det praktiseret.

Nogen burde prøve det.

Problemet kompliceres en anelse af at det ikke kun er en men tværtimod ret mange forskellige logfiler fra alle mulige forskellige niveauer og softwarepakker.

  • 2
  • 0
Jn Madsen

Det var da en underlig indstilling?

Det her er vel ikke et forum for "Pensionist,- lær din computer at kende"?

Yup,- en del af det PHK snakker om engang imellem,- ryger totalt over hovedet på mig.

Jeg fumler i helt andre grene af IT-verdenen,- men jeg påskønner ildsjæle og jeg kan lide at "lytte ved dørene", når nogen snakker om noget helt andet end det jeg kender til.
Inspiration og nice to know.

  • 16
  • 0
Rune Jensen

Jeg forstod, det er noget med ikke at stole på security by obscurity*), at holde øje med, hvem der har rettigheder til at kunne lave om i grunddelen af systemet og fjerne dem, som ikke skal have disse rettigheder**), opdatering og patching, så tidlig implementering af sikkerhedsprocedurer som muligt og så at læse ens logfiler.

Med forbehold for, jeg nok ikke har forstået alt 100%, så er jeg enig i alt det nævnte, og jeg bruger det selv, bare på hjemmesider. Man forstår nok først hvor værdifuld logfilerne er, når man har været udsat for angreb. Uden logfilerne er det altså svært at forsvare sig imod nye angreb. Så jeg logger alt... nok for meget :)

*) https://www.owasp.org/index.php/Avoid_security_by_obscurity
**) https://www.owasp.org/index.php/Access_Control_Cheat_Sheet

  • 0
  • 0
Morten Bøgh

Rigtigt at 'security by obscurty' er en relativt dårlig idé. Altså ideen om at jo mere kaotisk installationen er, jo højere er så sikkerheden. Det kan give nogle uheldige incitatementer til at fremme det første.

Men ellers:

En mainframe er i sagens natur en relativt stor installation med relativt mange ansatte til at håndtere tingene. Tag Danske Bank som eksempel. PHK's forslag om at lægge en jernring uden omkring installationen og stole på dem indenfor, er galmatias.
Ikke fordi vi mainframe-folk sidder fast i 25 år gammel tankegang, men fordi flere hundrede ansatte som man 'stoler' på, i stedet for at give gradueret adgang, vil være rent kaos. Det er fx. ikke godt at give bred adgang til at rette i kontoføringen i en bank.
Jernrings-tankegangen udadtil er også vanskelig at implementere, fordi mainframes alt ovevejende bruges til opgaver med rigtigt mange kunder udenfor 'bygningen'. Dvs også her må man differentiere mellem hvad forskellige grupper kan.

Der er også en anden fejl i indlægget som er 'størrelsesordner' forkert: Vedrørende en mainframe giver man ikke 'kundeservice adgang til at rette kundelisten'. Brugerne har aldrig adgang til at rette direkte i data. Deres tilgang af data går via en applikation som nøje regulerer hvad de kan, og sikrer konsistens i handlingerne. Igen har det ikke direkte noget med mainframe at gøre, men hænger sammen med at mainframe-installationer typisk servicerer rigtigt store organisationer.

Endvidere: RACF systemet på mainframe i vore dage håndterer generelle adgangsbetingelser for større grupper. RACF håndterer ikke den enkelte kundeservice-medarbejders adgang til den enkelte tabel. At gruppen af systemudviklere har adgang til frit at ændre i programbiblioteker håndteres af RACF, at gruppen af teknikere måske ikke har, håndteres ligevis. Men adgangen til den enkelte information, og til at rette i denne, håndteres i databasesystemet. Med udgangspunkt i RACF-autorisation, men den nøjere graduering ligger i databasesystemet selv.
Det er måske uvæsentligt, men kritikken af RACF bliver lidt malplaceret i dette lys.

I mine øjne er RACF et udmærket sikkerhedssystem. Det er et netværk af sikkerhedsmæssige relationer: Hvad grupper har medarbejdere har af rettigheder. Hvor det, man har rettigheder over, er 'grupper af ressourcer'. RACF administrationen kobler mennesker og ressourcer til respektive grupper. Typisk mainframe: tænkt som et netværk, hvor UNIX tænker i hierarki: filer ligger i directories, og til niveauerne her kan knyttes sikkerhedstilladelser for grupper og enkeltpersoner. Også udmærket, men knap som fleksibelt. (Fleksibiliteten i RACF får PHK så til at det skaber kaos - jo alt kan jo håndteres talentløst og i retning af misbrug).

I det hele taget er der interessante grundlæggende forskelle mellem mainframe og UNIX. Men det er en voldsomt nørdet diskussion som ikke egner sig til primetime. Det er heller ikke det der er focus i PHK's indlæg, det er nærmere en nostalgi efter et samfund (for 25 år siden?) hvor administrative organisationer var mindre, og tingene mere gennemskuelige. Det kan man selvfølgeligt kun være enig i.

  • 8
  • 2
Carsten Gehling

Endnu et eksempel på phks lettere selvhævdende, indforståede vrøvl.

Sjovt nok forstod jeg alt i dette indlæg. Jeg har tidligere i min karriere været belastet af at arbejde sammen med mainframe folk, så termerne er på plads i mit hoved. Og jeg fik stor glæde af at læse indlægget.

John du er jo ikke tvangsindlagt til at læse PHK's vrøvl - du kan bare skifte kanal :-)

  • 12
  • 0
Poul-Henning Kamp Blogger

Tag Danske Bank som eksempel. PHK's forslag om at lægge en jernring uden omkring installationen og stole på dem indenfor, er galmatias.

Nu kan vi jo alle vælge at læse som fanden læser biblen, men det er ikke desto mindre stort set præcist hvad Danske Bank praktiserer.

Jeg skrev jo netop ikke, som du åbenbart antager, at man skulle stole lige meget på alle der var indenfor.

Ikke fordi vi mainframe-folk sidder fast i 25 år gammel tankegang, [...]

Jo, det gør I sgu' men I har ikke ligefrem noget valg, når jeres systemer hænger fast i en 50 år gammel sikkerhedsmodel.

Vi kan diskuterer præcis hvor det var IBM's sikkerhedsmodel kørte af sporet, der blev f.eks allerede ved introduktionen fremført ret præcis kritik af VTAM på det punkt og den meget sene konvertering fra den strenge centralistiske kommunikationsmodel, hvor front-ends endte med at være enormt dyre og overkomplekse flaskehalse, hjalp bestemt heller ikke.

Den eneste fornuftige anvendelsesmodel for mainframes idag er som transaktionsserver i et client-server forhold, via firewall'ede applikationsprotokoller og det er præcis den vej alle blot nogenlunde kompetente installationer bevæger sig.

Ikke alle installationer har helt gennemskuet det med at de firewall'ede applikationsprotokoller, mange nøjes stadig med firewalling på netværksniveau og en eller anden form for bruger-autencitering.

(Svagheden ved den model er at hvis forbrydere kan få et WLAN AP smuglet ind i installationen er der alt for meget de kan pille med.)

Et særligt problem er alle de "små" applikationer. Stort set alle bankfolk og forsikringsfolk har stadig et eller flere menupunkter der kaster dem ind i en TN3270.

Men det helt fundamentale og overskyggende problem har CfCS sat fingeren meget præcist på i det citat jeg starter med og som du selv leverer eksemplet på: "I mine øjne er RACF et udmærket sikkerhedssystem."

Nej, RACF er en katastrofe.

  • 8
  • 0
Jens Henrik Sandell

Tak for noget mainframe-woodoo-snak! Jeg synes også det er "rart at lytte ved døren".

Jeg fornemmer dog også, at manglende "accounting" og "configuration control" på autorisationer af brugere og teknikere, bogføring af samme, samt manglende kontrol med opdateringer er den egentlige skurk.

Når der så i tillæg er et multi-sammensurium af forskellige kunder/myndigheder og et meget stort antal brugere på en og samme platform, så bliver kompleksiteten uundgåelig.

Jeg har ligesom PHK den opfattelse at "sikkerhed" ikke var et emne der blev drøftet mest, da statens myndigheder og styrelser udliciterede hver deres servcies til CSC (og forgængerne).

Er der nogen, der tør gætte på hvordan CSC de-conflict'er modstridende kundebehov for opdateringer af software??? (mit gæt: ved fakturering af timeforbrug, på en opgave uden for kontraktgrundlaget, og til højeste timepris?)

  • 2
  • 1
Søren Hersdorf

RACF er et værktøj som styrer adgang til alle ressourcer på z/OS, men det er kun så sikkert som anvenderen evner eller ønsker at bruge det. Det er en dårlig snedker, som skyder skylden på høvlen.

Sikkerheds administration er meget andet en afvisning af sorte hatte og det virker ikke som om det originale indlæg rigtig formidler (forstår?) den kompleksitet, som er hverdagen i en stor mainframe installation. De fleste større installationer supplerer RACF med andre adgangssystemer, som er målrettet forretningsbehovet og de krav som bla. stilles af myndigheder, intern og ekstern revision.

Mange installationer bevæger sig mod en arkitektur med mainframe som backend data- og serviceprovider. Dette er primært drevet af et ønske om en mere moderne brugergrænseflade end den traditionelle 3270. I den proces opstår et behov for at genoverveje hvor sikkerheden bedst placeres, men indtil denne transition fuldt gennemført, er det svært at forstille sig, at en "jernrings" strategi skulle være mere sikkert, med mindre man lever i sort-hvid verden, hvor sikkerhed bare er et spørgsmål om at undgå, at ukendte henter fortrolige oplysninger

  • 5
  • 1
Poul-Henning Kamp Blogger

Det er en dårlig snedker, som skyder skylden på høvlen.

Enig, men det er også en dum kunde der holder fast i en blikkenslager der arbejder med høvl :-)

Sikkerheds administration er meget andet en afvisning af sorte hatte og det virker ikke som om det originale indlæg rigtig formidler (forstår?) den kompleksitet, som er hverdagen i en stor mainframe installation.

Det kan du tro jeg gør.

Men i modsætning til jer "insiders" kan jeg også se hvor meget af den komplexitet der er selvskabt og hvor meget af den der skyldes krampagtig klamren sig til 50 år gamle ideer og principper.

med mindre man lever i sort-hvid verden, hvor sikkerhed er spørgsmål om at undgå, at ukendte henter fortrolige oplysninger

At beskytte fortolige oplysninger imod udefrakommende skal iflg. vores lovgivning have en højere prioritet end at gennemføre den daglige drift.

Det er faktisk forudsætningen for at man overhovedet gennemføre den daglige drift.

Loven giver ingen undtagelser for arkaiske sikkerhedsarkitekturer eller holdninger.

  • 8
  • 1
Søren Hersdorf

At beskytte fortolige oplysninger imod udefrakommende skal iflg. vores lovgivning have en højere prioritet end at gennemføre den daglige drift.

Det er faktisk forudsætningen for at man overhovedet må gennemføre den daglige drift.

Loven giver ingen undtagelser for arkaiske sikkerhedsarkitekturer eller holdninger.

Enig, men det var ikke det der var pointen.
Fortrolighed er kun én af forudsætningerne, og der en hel del andre, som også skal være opfyldt. Kompleksiteten er ikke skabt af systemet, værktøjet eller administrationen, men af kravene til sikkerhed.

Det er klart af en "jernringstaktik" er mere simpel og virker besnærende for en ikke "insider", men den opfylder bare ikke de komplekse nuværende krav til tilstrækkelig sikkerhed.
Det er også værd at bemærke (igen!), at det ikke er den velprøvede arkitektur eller værktøjsbegrænsninger, som skaber diverse sikkkerhedsbrist. Det er den lemfældige omgang med sikkerhed, som kun kan bekæmpes med rettidig omhyggelighed, uanset arkitekturen.

  • 4
  • 0
Gunner Olesen

RACF er jo noget lettere at automatisere end Windows, der kun kan forvaltes af dyre konsulenter. Den sikkerhedspolitik der efterstræbes er:
"En given bruger må kun have adgang til de ressourcer, der er nødvendig for at han kan løse sine opgaver". Og her fejler mange installationer, hvad enten de kører Unix, Windows eller ZOS. De giver brugerne adgang til tabeller eller ressourcer etc. i de mere eller mindre centrale systemer, hvad enten de skal bruges i de opgaver brugeren er i gang med, eller de ikke skal. Hvorfor skal en bankrådgiver have adgang til flere kunder, end dem han i øjeblikket løser opgaver for. Hvis han ikke er i gang med nogen opgaver, skal han kun have lov til en ting: "At modtage opgaver". Ovenstående indlæg bærer langt hen af vejen tegn på, at der krydses klinger på teknisk kendskab, mere end på indsigt i problemdomænet. Med XML baserede services, lidt XPATH og en smule kode til at opdatere RACF ACL lister, er det særdeles overkommeligt at automatisere og organisere brugersiden af sikkerheden i en moderne ZOS installation

  • 0
  • 0
Gunner Olesen

RACF er ikke 50 år gammel ! Typisk at skyde 100 % galt når man ikke er belastet af viden. Racf blev implementeret fra 1985 til 1990 i de danske installationer. Og da var både UNIX og Windows i drift - endda Windows 3.11 som var et flerbrugersystem.

  • 1
  • 2
Gunner Olesen

Den RACF som er fra 1976 var mig bekendt en noget anden implementering end den der findes i dag. SAF routeren kommer væsentlig senere. Og sammen med den kom der som jeg husker det adskillige forbedringer af, hvordan profiler og grupper kunne opbygges.

  • 0
  • 0
Gunner Olesen

Jeg husker fra min tid som integrator at det der RBAC i forbindelse med BIZTALK opsætning var fuldstændig uigennemsigtigt og uigennemskueligt. I hvert fald når det skulle bruges til at administrere 20 bankers brugeres adgang til services i det samme system. Hvor mere eller mindre generiske ACLer var utroligt meget enklere at skrue sammen.

  • 1
  • 0
Gunner Olesen

Når du skriver om RACF mener du så Z/OS? For lidt mere konstruktiv tilgang til emnet så læs f.eks.
systems_z_advantages_charter_security_zSecurity_L4_Security_Elements_of_zOS.ppt
(kan let findes via Google med søgeord: Z/Architecture RACF SAF router)
hit "Introduction to z/OS Security - IBM"
Så hvis du med mainframe mener Z/OS og hvis du med RACF mener sikkerhedssystemet til Z/OS, så vil du hurtigt forstå at det er overkommeligt at anvende f.eks. Windows Active Directory til sikkerhedskontrol. Så - angrib chaufføren og ikke bilen. Brugen af RACF er ikke et must, men et valg som it-personale har truffet. Men præciser dine angreb frem for at slynge dinosaur metaforerne ud ?
Især SAF routeren, der er ZOS systemets facade til sikkerhedsprogrammer og database illustrerer dynamikken i ZOS systemet, som efter min vurdering er noget bedre end både Windows og Unix (eller hvad de nu hedder)

  • 1
  • 0
Gunner Olesen

Hvad er egentlig de kriterier, du bruger til en sådan vurdering - er det fordi du ikke har set det og derfor ikke kan forestille dig det, eller har du set det og gennemskuet problemerne. Hvis du har 400 programmører, der producerer 10 programmer hver om året, og de har arbejdet i 10 år, så er vi vel derhenad. Og det er der da flere danske virksomheder der har.
At systemporteføljen understøtter heterogene virksomheder, betyder vel ikke at der ikke er styr på arkitekturen

  • 0
  • 0
Poul-Henning Kamp Blogger

Hvad er egentlig de kriterier, du bruger til en sådan vurdering

Det er et meget simpelt statistisk argument: I god, veltestet kode er der typisk en fejl per 1000 linier kildetekst.

Lad os som udgangspunkt antage at dine programmer er på 1000 linier hver, dermed er der statistisk en fejl i hvert program.

Eller sagt på en anden måde: Du har ca. 50000 fejl og filfører yderligere 4000 om året.

Men jeg er sikker på at lederne af IT "divisionen" eller hvad det nu kaldes, praler højlydt med alle de store tal i powerpoint præsentationer.

  • 2
  • 0
Søren Hersdorf

Så har man helt sikkert ikke haft styr på sin IT-arkitektur og dermed heller ikke IT-sikkerhed i de senste 10-20 år...

Men jeg er sikker på at lederne af IT "divisionen" eller hvad det nu kaldes, praler højlydt med alle de store tal i powerpoint præsentationer.

På mig virker det som en temmelig nedladende, undvigende og arrogant måde at svare på et meget rimeligt spørgsmål: "Hvad er så en god intern sikkerhedsmodel ?"

Det statistiske antal af fejl i kode ?
Hvad har det med sikkerhedsmodellen at gøre og er der færre fejl i decentral kode ?

Hvis man gerne vil tages alvorligt, specielt som "sikkerhedsekspert" på en platform man ikke kender, så skal man nok finde en anden tone og tilgang.

  • 1
  • 3
Poul-Henning Kamp Blogger

På mig virker det som en temmelig nedladende, undvigende og arrogant måde at svare på et meget rimeligt spørgsmål: "Hvad er så en god intern sikkerhedsmodel ?"

For det første er der ingen forskel på en god intern og en god extern sikkerhedsmodel: vi har kun de samme få værktøjer i kassen: quality code, minimal privilege, isolation, transaction logging og auditing.

For det andet strider netop centraliseringen på en mainframe der deles massivt i den grad imod "minimal privilege" fordi det introducerer unødvendige dependencies.

Tag CSC's mainframe som eksempel:

I månedsvist vidste ingen hvor og hvad hackerne havde lavet eller hvad de havde kopieret.

Den eneste rationelle handling havde været at hive mainframen totalt fra al telekommunikation indtil der var styr på tingene.

Det kunne man naturligvis ikke, det ville rive alle CSC's andre mainframe kunder med i faldet og de var jo "uskyldige" -- bortset fra deres valg af en sikkerheds-inkompetent IT leverandør.

Men hvis nu man havde kørt rigspolitiets systemer på et uafhængigt og isoleret system kunne man have sat kun det i karantæne, som man burde have gjort, og andre mere kompetente kunder ville ikke have været berørt.

Det havde også, by design, gjort det umuligt for hackerne at nå frem til andre CSC-kunders data og dermed fjernet behovet for den meget store (og ufyldestgørende!) udredningsøvelse der aldrig helt fastlog om andre kunder var berøret og i givet fald i hvilket omfang.

For så vidt RBAC, det er præcist hvad jeg beskrev i blogindlægget og har præcist de problemer jeg beskrev der: Det bliver stadig alt for komplext og grovkornet i praksis og som resultat ender RACF med at være inkonsistent.

Hånden op: Hvor mange af jer kører i det hele taget regelmæssigt et konsistens-check på jeres RACF database ?

  • 3
  • 0
Søren Hersdorf

Tag CSC's mainframe som eksempel:


Et fint eksempel og din beskrivelse af omstændighederne viser da også, at sikkerhedsbristen i høj grad skyldtes en utilstrækkelig forvaltning og ikke Z-arkitekturen eller RACF.

Og dit spørgsmål om konsistenscheck på RACF viser også, at der er mulighed for at foretage dette, men det op til administrationen at vælge intervallet. Igen er det ikke værktøjet eller arkitekturen der sætter begrænsningen, men måden hvor på man vælger at forvalte.

  • 0
  • 0
Poul-Henning Kamp Blogger

Et fint eksempel og din beskrivelse af omstændighederne viser da også, at sikkerhedsbristen i høj grad skyldtes en utilstrækkelig forvaltning og ikke Z-arkitekturen eller RACF.

Nej, det er en "både ... og" situation.

Jeg har hørt fra flere mainframe installationer at man efter CSC opdagede at man havde stort set præcist samme problem da man gav sig til at kigge efter.

Det tyder rigtigt meget på at Z+RACF er for svært for de folk der skal administrere det og dermed en del af problemet.

  • 3
  • 0
Søren Hersdorf
  • 0
  • 0
Gunner Olesen

Din statistik passer vist meget godt med virkeligheden, men det gør vel ikke arkitekturen dårligere eller bedre det er da bare skalering, det afhænger vel at det samlede systems kompleksitet i øvrigt?
De der mainframes driftes bl.a. af CSC og IBM, og det er vel dem, der har kørt "security by obscurity". Jeg tror ikke, at de ikke har magtet at gøre det bedre, jeg tror de har valgt det, fordi ingen har formuleret outsourcing kontrakterne tilstrækkelig skarpt.
Hvad angår indpakning - tja vi anvender vel arkitektur med mange lag, og hvert lag rummer sikkerhedsproblemer og løsninger, og det forekommer at CSC har snydt lidt på nogle af lagene da de installerede domino webserveren under USS på ZOS. Installationsvejledningen påpeger faktisk en god bid af de problemer, der ramte CSC. Alle systemer hænger vel på, at brugsanvisningen bør følges, hvis implementeringen skal være sikker.
Og endelig så er der lidt med de der sikkerhedsproblemer - Hvis alle brugere skal være kendt det sted hvor programmerne udføres, så er der et kartesisk produkt (brugereprogrammerdatabaser), der gør den blotte administration besværlig. Men dette produkt ændrer sig ikke af at blive flyttet et andet sted hen, f.eks. ud til brugerne og deres udstyr, det flytter muligvis administratorerne et andet sted hen. Og derfor efterlyser jeg en god sikkerhedsmodel. RBAC er en mulig lagdeling, - hvis organisationsstrukturen er homogen hos brugerorganisationerne. Men hvis de er heterogene med varierende dybde skifter problemerne karakter.
Et problem der afspejler lidt af problemet:
I en bank er der et antal investeringsrådgivere. De skifter somme tider til en anden bank. Hvis de kender alle den første banks gode kunder, hjælper de måske i den nye bank med at kapre de bedste. Den første bank ønsker derfor at sikre, at den enkelte rådgiver kun kender sine egne kunder. Andre medarbejdere i banken skal kunne betjene alle kunder under et. Og så tilbage - hvad var så den gode lagdelte sikkerhedsarkitektur.

  • 2
  • 0
Poul-Henning Kamp Blogger

Jeg har hørt, at det skyldes manglende uddannelse i Z+RACF

I så fald er det jo bare endnu en understregning på at hele kulturen omkring mainframes ikke tager sikkerhed alvorligt ?

Dine egne indlæg her kan alle stort set opsummeres med "vi ved bedre", hvilket er præcise den holdning som CfCS og jeg selv påpeger er det fundamentale sikkerhedsproblem.

"Hovmod står for fald" som man plejer at sige...

  • 3
  • 0
Poul-Henning Kamp Blogger

Jeg tror ikke, at de ikke har magtet at gøre det bedre [...]

Enig, men et skilt med "Skyd ikke på den sikkerhedsansvarlige, han gør det så godt som han kan" nytter jo ikke noget.

Der er en grund til at lastvogne stort set har overtaget al godstrafik i Danmark fra jernbanen: De løser simpelthen opgaven bedre.

Mainframes og det mainframe folk hånligt kalder "decentrale systemer" er præcis samme situation.

  • 2
  • 0
Poul-Henning Kamp Blogger
  1. Meget lidt godstrafik foregår med containerskibe i Danmark (Bemærk hvad jeg skrev, du citerede det selv!)

  2. Lastvogne er netop ikke kun små ladninger. Vindmøllevinger f.eks flyttes med lastvogne frem for togvogne, fordi de sidste netop kun er gearet til container transport nu om dage (Containeren er ofte en sættevognshænger :-)

  3. Hvorfor svarer du ikke på de andre ting :-)

  • 2
  • 0
Gert Madsen

De løser simpelthen opgaven bedre


Grundet deres vægt står de for 9x% af behovet for landets vejbudgetter.
Deres betaling til det, er kun symbolsk.

Skib og bane står stort set selv for omkostningerne til deres infrastruktur. Godsbanen får kun lov at køre om natten.

Det har ingen betydning for decentrale små ladninger, men bestemt betydning for større godsmængder.

Så det er ikke nogen god analogi. Lastvognstrafikken er heftigt subsidieret.

  • 2
  • 0
Gunner Olesen

Jeg synes at debatten illustrerer at PHK ikke ved bedre, og nok heller ikke kommer til det. Når PHK beskylder RACF for at bygge på en gammeldags sikkerhedsmodel, kunne det have været interessant hvis PHK havde evalueret en moderne sikkerhedsmodel mod den han kalder gammeldags.
Som jeg opfatter det stiller operativsystemer og middleware et antal events til rådighed for sikkerhedssystemet, og dette har så et definitionssprog og et Query sprog til at matche event mod definition og så tillade eller ikke tillade at gå videre. Jeg synes PHK burde samle lidt op på hvad der er moderne og hvad der er gammeldags, det er trods alt ham der kalder det "back to the future".
Det er ikke vi andre, der kalder PHK moderne. Jeg vil igen sige at "den der forenkler en kompliceret problemstilling fordummer beslutningstageren". Jeg synes PHKs statements fordummer beslutningstagerne - "skift til en moderne konsulent og dine sikkerhedsproblemer er løst". Ikke en faktuel vurdering af de forskelllige muligheder. Men PHK kalder også sig selv et brokkehoved, så det nok nødbremsen også i denne debat.

  • 3
  • 2
Ulrik Suhr

Hvem er det, der er bedrevidende ?


Nu er det nok over 10 år siden jeg sad i auditoriet og fik en forelæsning af en meget kompetent sikkerhedsmand fra IT industrien.

Han forklarede det meget simpelt.
Det er stort set umuligt at opbygge et 100% sikkert system da det så ikke vil være menneskeligt anvendeligt. Derfor må man formode at alt hvad man gør vil i sidste ende ikke nytte noget da angriberen vil nå igennem.

Så start med at forklare hvad i vil miste og hvor meget i vil give gratis.
Tænk det som om man benytter samme nøgle til alle bankbokse i banken.

Dernæst tænk på hvad de stjæler og hvad de får med. Her kan man benytte krypteret data. Tænk på farve patroner og pengeposer.

Kontrol af systemet skal også tænkes som en sikkerheds parameter da denne kan benyttes til at forbedre sikkerheden(det er en funktion som hele tiden udvikles). Denne kan tænkes at tv kamerarernes bånd maskiner ikke skal tilgås fra banken så tyven lige snupper dem når de forlader banken.
Se det som om logs etc. ikke må ligge i samme område som resten af systemet eller blande admin konto og bruger etc.

Hvis jeg skal overføre det til denne debat så handler det om hvad man giver gratis ved centrale systemer.
Denne argumentation er sund hvis man ikke mener det vil belaste at hele databasen bliver åbnet og kan tilgås. Dette er ikke min overbevisning og derfor har jeg simpelthen ikke forstået hvorfor man skal samle kritisk data? ud over det økonomiske.

for lige at slå fast så har jeg den modsatte holdning af dig.

Jeg vil igen sige at "den der forenkler en kompliceret problemstilling fordummer beslutningstageren"

Jeg mener personligt "at hvis man ikke magter at simplificere en kompliceret problemstilling". Så forstår man reelt ikke problematikken.

  • 1
  • 1
Gunner Olesen

Min erfaring her er baseret på denne type hændelser:

Programmører der sagde at de mangler processorkapacitet. De fik en større processor, men fik ikke bedre svartider.
Projektledere der sagde at de manglede programmører. De fik dem, men blev ikke færdige til tiden.

Og så er det i øvrigt Rainer Werner Fassbinder der har formuleret den, og dokumenteret den i en film.

  • 1
  • 1
Ulrik Suhr

underligt...
jeg var af den opfattelse af det er almen viden at:

Projektledere der sagde at de manglede programmører. De fik dem, men blev ikke færdige til tiden.

tilføjelse af flere resurser i et projekt midtvejs var en større belastning på projektet end at forsætte med den samme bemanding...
Tror ligefrem der er lavet en algoritme mht. hvor meget spild man indføre og hvor dumt det er... brug gerne google hvis du ikke tror på denne påstand.

Det er meget underligt at høre den næste påstand da denne bruges som case på dårligt kode på de fleste uddannelser...

Programmører der sagde at de mangler processorkapacitet. De fik en større processor, men fik ikke bedre svartider.

seriøst? en programmør der mener HW opgradering vil slå en SW optimering? Tror det er enten første års pensum eller en del af SW algoritme lære at forstå matematiske formler og overføre dem til software at hastighederne kan være uheldige eller fornuftige... HW er som regel sidste løsning og hælder mere til en panik handling. Hvis man er bekendt med projektet fra start af har man HW dimensioneret til løsning af dette. Så er det op til SW at få det til at fungere tilfredsstillende.

I film kan alt lade sig gøre.

  • 0
  • 0
Poul-Henning Kamp Blogger

Når PHK beskylder RACF for at bygge på en gammeldags sikkerhedsmodel, kunne det have været interessant hvis PHK havde evalueret en moderne sikkerhedsmodel mod den han kalder gammeldags.

Beklager Gunner, men det er omvendt bevisbyrde og sådan spiller musikken ikke.

Ansvaret for at dokumentere sikkerhedsfaciliteters kvaliteter påhviler altid dem der vælger at beskytte personfølsomme data med dem.

For så vidt at "evaluere en moderne sikkerhedsmodel [mod RACF]" - grunden til at det ikke sker oftere, er at ingen sikkerhedsforskere idag opfatter RACF som interessant eller relevant overhovedet.

De ting der kan læres af "ACL" modellen er lært og modellen er for længst opgivet i alle miljøer der aktivt tænker over og evaluerer sikkerhedsmodeller. Derfor er ACLs' ikke længere (som de f.eks var i 90'erne) hjørnestenen i sikkerhedsmodellen hos DoD og NATO.

I den forbindelser er det interessant at se at fokus skiftede ikke blot fra sikkerhedsmodeller der matematisk kunne bevises at være vandtætte, men i højere grad til i hvilket omfang beviset kan gennemføres i praksis.

Jeg spurgte ovenfor hvor mange af jer der overhovedet kører regelmæssige konsistenscheck, men det eneste svar er fra Søren og det lyder nærmest "Det kan man da godt, ..." uden en eneste flig af evidens for at det faktisk sker i praksis.

Jeg kender selv folk der har prøvet -- og givet op. Primært fordi det er 100% umuligt at finde organisatoriske svar på de adgangsmæssige spørgsmål der opstår.

Ingen mainframe-installationer udenfor DoD's område har forresten nogensinde påvist at have en komplet og fuldstændig foreskrivende sikkerhedsmodel til at drive RACF.

For så vidt at lave en sammenligning som du efterspørger, tvivler jeg meget på at det ville gøre nogen nytte, alt den stund af debatten herover tydeligt viser at CfCS's og min egen vurdering er præcis: Mainframe installationer lider af en hoven "vi ved bedre" holdning der forhindrer dem i at forstille sig at noget andet kan være bedre.

Mainframen er "Guds egen computer" fornemmer man.

  • 3
  • 2
Søren Hersdorf

Lad os vende bøtten på hovedet.

Hr. Kamp skriver:

Alle seriøse installationer jeg kender til har opgivet ACLs som primær sikkerhedsfacilitet.

I stedet slår man idag en jernring om installationen, stoler (nogenlunde) på dem indenfor og bruger ACL-lignende gateway faciliteter imellem "inde" og "ude": Firewalls, DMZ osv.

Venligst angiv hvilke installationer, så vi kan lære af dem?

Bellovins og Cheswicks bog, der fastslog dette princip, udkom i 1994.

Jeg går ud fra at der refereres til "Firewalls and Internet Security: Repelling the Wily Hacker."
En bog som ikke rigtigt beskæftiger sig med andet end at afvise sorte hatte.

Bonus info
Citat fra bogen: "It is also true that UNIX is an administrative nightmare. Vital files are scattered over numerous directories. Setuid programs can change the rules in unexpected ways if the capability is misused."

  • 1
  • 0
Rune Larsen

seriøst? en programmør der mener HW opgradering vil slå en SW optimering?


Med få undtagelser, er min erfaring med mainframe-programmører er, at de ikke har den længste skoling udi datalogien dyder. Måske fordi det ville få dem til at løbe skrigende væk fra platformen og COBOL's arkaiske konstruktioner og datatyper.

  • 1
  • 2
Gunner Olesen

Det udgangspunkt, der er angivet i denne BLOG, er et statement fra CfCS vedrørende mainframes. Jeg synes deres statement er et letkøbt forsøg på at begrunde CSCs sikkerhedsbrist. Så de slipper for at pinne et ansvar på en leder. Og du følger gladelig med ved at sige at forresten kan RACF godt løse opgaven, men ingen kan finde ud af ACL lister, og det er dokumenteret i et eller andet skrift.
Det er dig og ikke CfCS, der har gjort RACF til synderen.
Jeg har forsøgt at få dig til at skitsere hvilket sprog du så ville formulere sikkerhedsløsningen i. Ud fra den betragtning, at når ACL, efter hvad du siger, er tilstrækkelig udtryksfuldt til at formulere løsningen, og du har et (moderne)sprog, der kan formulere sikkerhedsløsningen så må det være muligt at transformere din løsningsbeskrivelse til ACL, og den slags transformationer er normalt overkommelige.
Men dialogen herom stopper ligesom, når du ikke vil skitsere din løsning. Tilbage bliver egentlig, at du siger at ingen RACF administrator kan løse sin opgave fordi de nødvendige ACL er for komplekse til at administrere.
Da jeg i sin tid hold op med at programmere assembler, var begrundelsen ligevis, at ingen kunne finde ud af at administrere dem. Men ethvert program skrevet i et moderne programmeringssprog kan transformeres til maskininstrukser. Så med den rigtig "compiler" kan de relevante sikkerhedsbeskrivelser transformeres til ACL. Så drop det der sludder med hvad der er gammeldags, og hvad der er moderne. I it skifter sprog over tid - alt efter mode og problemkomplexitet. Men det har aldrig været et aldersproblem!
Jeg synes stadig at du er meget nedladende, når RACF administratoren ikke klager sig, men du dømmer ham ude, fordi du har læst, at håndkodet ACL er et problem.

  • 3
  • 1
Log ind eller Opret konto for at kommentere