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.
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.
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.
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.
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
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)
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.
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.
Hvis man har 6000 ansatte, et par millioner kunder og 50000 programmer, der kan bearbejde data gennem 3000 serviceoperationer, hvad er så en moderne sikkerhedmodel (når nu de der 25 år gamle modeller ikke er OK) ? Det kunne jeg da godt lide at vide
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.
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
Hvorfor skal der være højhastighedsinternet og 4g mobildækning i Danmark?
Det er en skærpende omstændighed ? Altså den samme handling på den samme private virksomheds computer (CSCs) straffes forskelligt alt efter om man får fat på virksomhedens egne data eller data som tilhører det offentlige. Specielt er det spændende at opsætningsfilen der blev ændret IKKE er statens, men CSCs ejendom. Kan de finde deres egne ben - de gode dommere ?
Jeg har med mainframes siden 1970, med Java siden 1999 og med C# og Biztalk på Windows i perioden 2005 til 2012. Intet af det du har skrevet adskiller mainframes fra Windows fra unix. Jeg synes du gør dig bedrevidende på et svagt fundament, og tilbyder til enhver tid at imødegå dine letkøbsargumenter.
"Hvis man forenkler en kompliceret problemstilling fordummer man beslutningstagerne". Citat af Rainer Werner Fassbinder. Værd at huske når der skal løses problemer omkring eller med it.
Så kunne der da rigtig blive debat ? Er det navnet / navnene eller feltdefinitionerne der bærer opfindelsen ? CSC Hackersagen viser hvor lidt juraen forstår it - så hvordan sammenligner man APIer og finder dem identiske ? Er det når de kan compileres med den samme compiler og danner identiske strukturer til identiske systemer ? Det er da vist svært !
Typisk aflæses automatens tælleværker en gang i døgnet og afstemmes med den tilhørende kassekonto. Og eftersom de eneste der betaler i en bank er kunderne, så går pengene indirekte fra alle kunder. Men den kasserer, der har fyldt maskinen op, kunne faktisk stå med et problem hvis hacket blev udført i virkeligheden. Hvor let beviser han, at han ikke har taget pengene ?
Derfor skal han kanøfles. Er det ikke sådan nogenlunde anklagerens argumentation. Det har ikke meget med retssamfund at gøre. Bare fordi staten har outsourcet it til virksomheder, der sætter profit højere end sikkerhed, skal de der dokumenterer det i praksis, vel ikke stilles for retten med en usammenhængende anklage. Jeg synes CSC skulle have ofret et ordentlig låg på kagedåsen.
Normalt slipper http requests vel igennem firewalls på port 80, så hovedproblemet er stadig at CSC har fremstillet den billigst mulige løsning ved at bruge den "gamle" server uden at ofre fornøden omhu på opsætning. Hele ZOS USS setup ser ud til at være benyttet stort set "as is" uden omtanke.
Godt at sagen bliver dækket. Jeg forstår ikke helt, at de store medier ikke tænker lidt mere over det vi har hørt. En fremmed magt har uden videre kunnet skaffe rigtig mange af statens informationer via de afslørede huller. Og eftersom gentagen fejlagtig sign-on til en userid typisk medfører at pågældende userid spærres, indikerer informationerne at politiets adgang til deres systemer effektivt har kunnet blokeres med en lille robot, der foretager fejlagtig sign-on for samtlige brugere - og muligvis startende med de brugerid, der tilhører de sikkerhedsansvarlige, således at de ikke kan foretage reset af andre brugere og give dem nye passwords. Så jeg tror lidt på at nogen har fortalt de store medier at det er ok at beskæftige sig med de tiltalte personer, men statens sikkerhedsproblemer bør man ikke dyrke offentlig.
Gunner Olesen