Category Archives

5 Articles

Sikkerhet/Tilfeldig

Norge, IT-sikkerhet og cyber terrorisme

Posted by ragnar harper on

Jeg har siden jeg var 10 år vært intressert og nysgjerrig på IT-sikkerhet – og jeg har jobbet med temaet siden 1996.
Det er derfor med stor interesse jeg har fulgt de siste tiders hendelser i Norge.

Telenor sliter med mobilnettet, A-Hus sliter med sine systemer og bank systemene er nede titt og ofte.

“Driftsproblemer i en organisasjon kan ha flere årsaker, og det er bortimot umulig å gardere seg 100% mot feil.
Flere ganger har jeg hørt på TV eller på radio noen si “vi jobber med å lokalisere feilen” fordi man ikke vet hvor den er.
Det er ikke å komme bort ifra at de fleste av dagens løsninger har blitt for komplekse og på mange måter blir det å finne feil som å leite etter nåla i den berømte høystakken.

Påstand: Kompleksiteten kommer som en konsekvens av manglende arkitektur og føringer på infrastruktur.

For ofte kjøres prosjekter i bedrifter hvor “noen” får bestemme hva de vil benytte av teknologi. Så lenge man integrerer seg mot det man skal, er det ikke så nøye hvilken teknologi det er. Mange ganger ser du ett hav av ulike databasemotorer, applikasjonsrammeverk, operativsystemer og kommunikasjonsteknologier. Selv om disse fra ett applikasjonssyn er istand til å integrere seg med hverandre, er de fra ett infrastruktursyn vanskeligere å drifte, overvåke, oppdatere og feilsøke.

 

Påstand: Uten komplett oversikt blir oppetid og sikkerhet umulig

Når applikasjonene blir overført til driftsorganisasjonen er det viktig at overvåkning og driftsverktøy er på plass og automatiserte. Man kan bli skremt av å vite om alle de “finurlige”, “smarte” løsningene der ute som ikke overvåkes og automatiseres godt nok.
Som driftsorganisasjon sitter man med en blanding av teknologier som rent applikasjonsteknisk snakker sammen, men som ikke lar seg overvåke og automatisere på samme måte.

 

Påstand: Den største trusselen kommer innenfra

Og det er ikke fra hackeren – men fra ledelsen. Ved å mangle kunnskap og kompetanse om hvilke krav som må stilles til infrastruktur, blir fokuset reint applikasjonsteknisk. Sikkerhet og stabilitet blir en “selvfølge” der man ikke er villig til å ta kosten for å bygge en god nok plattform.

 

MEN! Hva om problemene skyldes ondsinnede angrep?
Hva om noen med overlegg planter disse problemene?
Hva om det ikke fanges opp at det er ubudne gjenster i systemet?

Hvis problemene er forårsaket av organisasjonene selv – hvor motstandsdyktige er de da mot målrettede, profesjonelle eksterne angrep?

Hvor mye verdt vil det være for en kriminell gruppe å sitte med disse systemene?
Hva er det verdt å kontrollere helseinformasjon, finansinformasjon og kommunikasjon….

Det at du ikke er paranoid, betyr ikke at ingen vil ta deg!

Er Norge forberedt for ett digitalt 11 september?

Jeg tror ikke det ….

Powershell/Sikkerhet

Noen tanker rundt sikkerhet, Powershell og skuespill

Posted by ragnar harper on

Det er med forundring jeg iaktar sikkerhetsteateret som fortsatt spilles i programvareindustrien. For eksempel selges kryptering fortsatt som en magisk formel som sikrer sikkerhet, og jo større nøkkellengde, jo bedre. De matematiske egenskapene som krypteringen hviler på er sjelden de reelle utfordringene som sikkerheten faktisk møter. Det er i selve implementeringen av sikkerhet at vi feiler. I implementeringen av kryptering – ikke i det matematiske grunnlaget for kryptering. Det spiller derfor sjelden en stor rolle om krypteringen er 128, 256 eller 512 bits – så lenge man kan gå rundt.

Om du låser døra med verdens beste låser – hva betyr vel det så lenge du lar vinduet stå åpent?

Sagt på en annen måte, det hjelper ikke hvor tykk døra er når vinduet står åpent.

Det er lett å glemme , men uansett like viktig, at sikkerheten aldri blir bedre enn det dårligste leddet i en kjede av elementer. I den virkelige verden er det enda lettere å faktisk oppdage at vinduet står oppe, enn det er i den virtuelle verden.

I den virkelige verden hvor man har behov for høy sikkerhet er det mange problemstillinger som ødelegger muligheten for maksimal sikkerhet. Elementer som brukervennlighet, bakoverkompabilitet og ytelse kommer ofte, eller alltid, foran sikkerhet.

Istedet konsentrerer vi sikkerhet rundt et teaterstykke, hvor vi “føler” oss trygge. Vi skaper en illusjon om at noe er sikkert. I programvare versjonen av dette teaterstykket er begrep som nøkkellengde viktig. Andre ting vi føler er utrygt er hashingalgoritmer, på grunn av “birthday” syndromet som disse har. Vi gidder ikke ta innover oss den faktiske reelle betydningen av problemstillingene, da disse ikke passer inn i teaterstykket.

For å kunne vurdere elementer mot hverandre er av vi avhengige av måleparametre. Dette gjelder også sikkerhet. Vi ønsker å måle den eksakte graden av sikkerhet, slik at dette kan være med i vår vurdering. I denne hunger etter falsk informasjon, blir det gjort snarveier. En av disse er at nøkkellengden og algoritmen benyttet til kryptering er en sannferdig beskrivelse av sikkerheten i ett system. Dette er kun for markedsføring, og har ingen reell betydningen for den faktiske sikkerheten en løsning innehar. Ok, la oss fortsette til det jeg egentlig ville skrive om:

En av de andre stykkene som spilles på dette teateret er av leverandører av sikkerhetsprogramvare. Disse gjør desperate stunt for å si noe om sikkerheten til ett system, og prøver alt de kan for at du skal kjøpe disse forsvarsmekanismene. I sommer har dette tatt en forunderlig vending. På BlackHat konferansen i Las Vegas har to personer demonsterert hvordan Powershell er et kraftfullt shell for Windows. De har demonstrert at dette shellet også kan utnyttes for ondsinnede handlinger. De ser styrken i Powershell, og demonsterer at man kan gjøre farlige kommandoer med automatisering. Foredragsholderne har en ganske edruelig holdning til Powershell og sikkerhet – men det gjøres ett par stunt for å få deltakere til sesjonen.

En sikkerhetsleverandør (hvis navn ikke skal nevnes her) demonstrerer nå sin kraftige inkompetanse på sikkerhet generellt og Powershell spesiellt. De hevder at det er utgikk en “0-day exploit” for Powershell, og at de sikrer mot denne. I tillegg beskriver de “ExecutionPolicy” i Powershell som en sikkerhetsteknologi – noe det aldri har vært, og aldri tillagt egenskapen som fra Microsoft. ExecutionPolicy i Powershell er en flott løsning for å unngå kjøring av ad-hoc script ved en misforståelse. ExecutionPolicy hindrer deg ikke i å kjøre kommandoer – kun rettigheter i systemet nekter deg det. Selv om du har ExecutionPolicy satt til “Restricted”kan du kjøre en hvilken som helst kommando – dog får du ikke startet og kjørt .ps1 filer direkte fra kommandolinjen. Det betyr at alle kommandoene i scriptet kan kjøres, og du kan ganske enkelt laste inn alle kommandoene i en fil, og utføre denne, linje for linje med for eksempel Invoke-Expression cmdlet.

Alle som har satt seg nogenlunde inn i Powershell har fått med seg dette. Man skulle anta att en sikkerhetsleverandøre som leverer sikkerhet som også “omfatter” Powershell, også hadde tatt seg bryet med å forstå grunnleggende elementer av Powershell.

Problemet er at mange leser kun overskrifter av det som skrives på Internett – og – ikke bli overrasket nå – tror på det de leser.Selv om en hel artikkel er feil, kan denne lett referes til som en sannhet. Det provoserer når noen søker å selge produkter du ikke trenger, for å beskytte deg mot en trussel som ikke finnes. Mange selskaper som selger sikkerhet selger sikkerhetsprodukter du ikke trenger, fordi du tenker “det skader ikke å være på den sikre siden”. Men hva er den sikre siden i slike tilfeller? Hva med risikoen slike programmer kan innføre i? Når ett selskap tar lett på sannheten, og ikke setter seg godt nok inn i det de søker å beskytte deg mot – hvor mye har de da å tilføre av sikkerhet med sine produkter?

Vi vil alltid erkjenne forsvarerens dilemma – som forsvarer må vi sikre og forsvare alle elementene i vår løsning. Som angriper derimot trenger vi å kun finne ett svakt punkt.

Desverre finnes det digitale kvakksalvere anno 2010 som selger deg noe du ikke trenger, ja, som faktisk kan gjøre ting værre.

Det er dessverre vanskelig for de som ikke jobber med sikkerhet og avdekke disse (faktisk også for de som jobber med sikkerhet).

AD RMS/PKI/Sikkerhet/Windows Server 2008

Hvorfor Active Directory Rights Management Services?

Posted by ragnar harper on

For tiden jobber jeg ganske tett på AD RMS, og tenkte i den anledning å skrive noen innlegg om AD RMS.

Behovet for sikkerhet har endret seg. Tidligere var det kanskje nok med med adgangsstyring på mappe nivå i filsystemet. Nå kopieres dokumenter til USB enheter, sendes på epost og ligger på bærbare datamaskiner rundt omkring.

Med Active Directory Rights Management Services (AD RMS) kan man legge beskyttelsen i dokumentet – og den følger dokumentet. Utover tradisjonell kryptering gir dette støtte for at man også kontrollerer hva man får gjort med innholdet. For eksempel kan man nekte utskrift, nekte endring eller sette utløpsdato på innholdet.

En epost kan for eksempel sendes med en policy som nekter mottaker å videresende eposten.

Om en bruker kopierer et dokument til en USB minnepinne og tar denne med seg hjem til sin hjemmemaskin, vil dokumentet fortsatt ha samme grad av beskyttelse som om det fortsatt lå i bedriftens datasenter.

AD RMS er brukervennlig og integrert med Microsoft Office, Sharepoint og Exchange. Det fungerer også på Windows Mobile enheter, og gjennom tredjepartsleverandører har det bred støtte for ulike dokument format.

Hvilke typiske tilganger kan du styre gjennom AD RMS?

• Se innhold

• Se rettigheter

• Skrive ut

• Lagre

• Lagre som

• Klipp og lim

• Redigere

• Kjøre makroer

• Videresend (epost)

• Svar(epost)

• Svar alle(epost)

• Utløpsdato

• Utløper etter N dager

AD RMS gir deg sentral oversikt over hvem som aksesserer hvilke dokumenter, og du kan begrense brukere og/eller applikasjoner fra å kunne benytte RMS beskyttet innhold.

Iforhold til tradisjonell kryptering er AD RMS en mer dynamisk tilnærming, hvor adgangen også kontrolleres etter at den er gitt. Man kan trekke tilbake adganger som, og man kan gi adganger, selv etter at krypteringen er utført.

Selvsagt finnes det måter for en som har adgang til å gå rundt en slik sikring – for eksempel gjennom "det analoge hullet” – men det er stopper utilsiktede lekkasjer.

Konferanse/Sikkerhet

HackCon 2009

Posted by ragnar harper on

Jeg skal prate om Windows Server 2003/2008 på HackCon 2009. Teamet vil være “How Microsoft does IT”, og jeg skal prate om sikring og sikkerhet rundt Windows Server. Dette er på en egen Microsoft dag den 16 Februar.

Hvis du er der – husk å si hei 🙂

Certificate Services/Sikkerhet/Windows Server 2008

Kort om Windows Server 2008 Certificate Services

Posted by ragnar harper on
Hva er PKI?

Public key infrastructure (PKI) er et system bestående av digitale sertifikater, sertifikat utstedere (Certification Authority,CA), samt registreringsautoriteter som verifiserer og autentiserer gyldigheten av hver entitet som er involvert i en elektronisk transaksjon gjennom bruk av kryptering med offentlige nøkler(public key cryptography). Standardisering av PKIs er fortsatt under rivende utvikling, selv om PKI er bredt implementert som et nødvendig element for ehandel.

Microsoft PKI støtter en hierakisktisk CA modell som er skalerbar og tilbyr sameksistens med andre CA produkter.

I sin enkleste form består et slikt hieraki av en enkelt Certification Authority (CA). I praksis er det vanlig å benytte flere CA for å klart definere et hieraki. I et hieraki vil underliggende noder (barn) være sertifisert av nivået over, og på denne måten binde identiteten sammen. På toppen av hierakiet sitter Root CA, og de CA som ligger under benevnes subordinate CA.

I Windows er det slik at hvis du har etablert tillit til root CA (ved at root sertifikatet til root CA ligger i Trusted Root Certification Authorities) , så har du også tillit til alle gyldige subordinate CA.

Det kan være flere årsaker til at man ønsker å benytte subordinate CA, for eksempel:

  • Bruk. Sertifikater kan utstedes for ulike formål, slik som for eksempel sikker epost og nettverksautentisering. Regelverk for utstedelse av disse sertifikatene kan være ulikt, og separering tilbyr ulik administrasjon av dette.
  • Organisasjonens oppbygning. Det kan være ulikt regelverk for administrasjon og utstedelse av sertifikat , avhengig av rollen i organisasjonen. Med subordinate CA kan du skille ut dette.
  • Geografisk oppbygning. Organisasjonen kan være spredt over et store geografisk område. Avhengig av nettverkstilkoblingen mellom disse kan det være vi krever dedikerte subordinate CA for noen eller alle av lokasjonene.
  • Last balansering. Hvis din PKI skal benyttes til et stort antall sertifikater, kan det å kun ha en CA resultere i en betydelig nettverksbelastning for denne. Bruk av flere subordinate CA til å utstede sertifikatene deler belastningen mellom disse CA.
  • Backup og feiltoleranse. Flere CAer øker sannsynligheten for at ditt nettverk alltid vil ha en CA tilgjenglig for å svare på henvendelser.

Et hieraki med flere CA kan også tilby administrative fordeler, slik som :

  • Fleksibelt CA sikkerhetsmiljø for å skreddersy balansen mellom sikkerhet og brukervennlighet. For eksempel kan du benytte en maskinvarebasert kryptering på root CA, plassere CA fysisk adskilt og sikret, eller ha root CA offline.
  • Mulighet for å “slå av” en spesifikk del av CA hierakiet uten at det påvirker etablerte relasjoner. For eksempel kan du enkelt stenge ned en CA certificate som er assosisert med en spesifikk avdeling uten at det påvirker andre deler av organisasjonen.
Ulike typer Certification Authorities (CA)

En CA mottar en forespørsel om å utstede et sertifikat, verifiserer forespørselen basert på policy som er satt, og deretter bruker CA sin private nøkkel til å signere sertifikatet som blir utstedt. CA utsteder deretter sertifikatet til subjektet på sertifikatet som nå kan benytte sertifikatet som en identifisering i PKI. En CA er også ansvarlig for å trekke tilbake sertifikater og publisere en liste over sertifikater som er trukket tilbake(certificate revocation list (CRL)).

En CA kan være en ekstern aktør, slik som VeriSign, eller en CA kan opprettes internt gjennom installasjon av Active Directory Certificate Services. Hver CA kan ha ulike krav til identifisering for utstedelse av sertifikat. Identifisering av forespørselen kan for eksempel gjøres mot domenekonto, ansatt id kort, førerkort eller lignende.

En Windows Enterprise CA kan bruke en persons brukerkonto som bevis på identitet. Med andre ord, hvis du er pålogget en konto i domene, og ber om et sertifikat fra en enterprise CA, kan sertifikatet utstedes med bakgrunn i domenekontoen du er logget på med.

Alle CA har et eget sertifikat som bekrefter identiteten til CA´en som er utstedt av en annen CA i hierakiet. Root CA derimot, utsteder sertifikatet til seg selv. Husk at alle kan opprette en CA, det er altså viktig at vi har retningslinjer for hvordan vi angjør om vi skal ha tillit til en CA eller ikke.

Root og subordinate CA

En root CA er den enheten med størst tillit i en organisasjons PKI. Hvis en root CA blir kompromitert eller utsteder sertifikater til uautoriserte entiteter vil enhver sertifikatbasert sikkerhet i din organisasjon bli sårbar. Derfor er vanligvis både fysisk sikkerhet og utstedelseeespolicyen på root CA sterkere enn for subordinate CA´er. Selv om det er mulig å benytte root CA til å utstede sertifikater til sluttbrukere, er det mer vanlig at dette utføres av subordinate CA´er istedet.

En subordinate CA er en CA som har fått sitt eget sertifikat signert av en annen CA. Typisk bruk av en subordinate CA er for spesifikk bruk, slik som sikker epost, webautentisering eller smartkort autentisering. En subordinate CA kan igjen også utstede sertifikater til andre CA´er under seg selv. Gjennom en slik lenke med CA´er fra root CA og ned gjennom subordinate CA´er får vi et hieraki.

Enterprise og stand-alone CA

Windows Server 2008 støtter to typer CA, enterprise og stand-alone.

Enterprise CA

Enterprise certification authorities (CA) kan for eksempel utstede sertifikater for digital signatur, sikker epost (S/MIME), web autentisering (SSL og TLS) og pålogging til domene gjennom bruk av smartkort.

Egenskaper til en enterprise CA:

  • Krever adgang til Active Directory Domain Services (AD DS).
  • Benytter Group Policy for å legge sitt eget sertifikat i Trusted Root Certification Authorities for alle brukere og maskiner i domene.
  • Publiserer bruker sertifikater og certificate revocation lists (CRL) til AD DS. For å kunne publisere sertifikater til AD DS, må CA serveren være medlem av gruppa Certificate Publishers. Dette skjer automatisk for det domenet serveren er medlem, men serveren må bli delegert nødvendige rettigheter for å kunne publisere sertifikater I andre domener.

Merk! Du må være medlem av Domain Admins for å installere en enterprise root CA.

En enterprise CA utsteder sertifikater basert på maler. Følgende funksjonalitet er mulig gjennom bruk av maler:

· Enterprise CA utfører identifisering av brukeren ved utstedelse av sertifikat. Alle maler har rettighetsstyring som angir om den som forespør sertifikatet er autorisert til å få et sertifikat av typen den ber om.

  • Subjektets navn i sertifikatet kan genereres automatisk fra Active Directory Directory Services eller bli angitt eksplisitt av den som forespør. (Subjektets navn er navnet som sertifikatet blir utstedt på)
  • Malene har ett sett med forhåndsdefinerte utvidelser som legges inn i sertifikatet. Dette reduserer behovet for å angi informasjon ved forespørselen.
  • Sertifikater kan rulles ut automatisk med autoenrollment.
Standalone CA

Stand-alone certification authorities (CA) kan utstede sertifikat for oppgaver som digitale signaturer,sikker epost (S/MIME) og autentisering av servere (SSL, TLS).

En stand-alone CA har følgende egenskaper:

  • Krever ikke Active Directory Domain Services (AD DS) (slik en enterprise CA gjør) Selv om du benytter AD DS kan en stand-alone CA bli brukt som en offline trusted root CA i ditt CA hieraki eller brukes til å utstede sertifikater til klienter over et extranett eller Internet.
  • Brukeren må legge ved identifiserende informasjon og spesiefisere hvilken type sertifikat som ønskes utstedt. (dette gjøres ikke når vi sender en forespørsel til en enterprise CA da denne henter
    identiteten fra AD DS og sertifikattypen basert på malen som er valgt). Autentiseringsinformasjon om forespørselen hentes fra maskinen lokale SAM database.
  • Som standard vil alle forespørsler måtte vente på en godkjennelse. En administrator kan godkjenne forespøreselen.
  • Maler kan ikke benyttes.
  • Stand-alone root sertifikat må manuellt installers i trusted root.
  • Hvis det benyttes en krypografisk provider med støtte for elliptic curve cryptography (ECC), en stand-alone CA will honor every key usage for the ECC key. For more information, see Cryptography Next Generation (http://go.microsoft.com/fwlink/?LinkID=85480).

Merk : Ved å kombinere stand-alone CA med AD DS,har CA følgende egenskaper:

  • Hvis en medlem av Domain Admins gruppa installerer en stand-alone root CA,vil den bli automatisk lagt til i Trusted Root Certification Authoritiesfor alle brukere og maskiner i domenet. På grunn av dette anbefales det ikke at du endrer standardhåndteringen av forespørsler i slike tilfeller. Ellers risikierer du å ha tillit til en CA som utsteder sertifikater uten noen form for sjekk om gyldigheten av identiteten.
  • Hvis en stand-alone CA installers av en bruker some r medlem i Domain Admins I domenet, så vil stand-alone CA publisere sitt CA sertifikat og certificate revocation list (CRL) til AD DS.
Windows Server 2008 PKI funksjonalitet

Sertifikathåndtering og PKI håndteres i Windows av Certificate Services. I Windows Server 2008 heter denne Active Directory Certificate Services (AD CS). Tidligere versjoner av Windows Server, slik som Windows Server 2003 og Windows 2000 Server støtter og sertifikattjenester. Funksjonaliteten er derimot forskjellige mellom disse versjoner, slik at det er viktig at man har oversikt over hvilke krav man har, slik at man velger riktig versjon. Implementeringen kan gjøres fra helt enkle enserver installasjoner til flere servere. Ved bruk av flere servere har man som oftest root, policy og issuing CA servere, samt andre som er Online Responders.

Merk! AD CS kan ikke installeres på Server Coreeller Itanium baserte Windows Server 2008 systemer. Kun et begrenset utvalg av server roller er tilgjenglig for disse versjonene.

Oversikt over AD CS komponenter på ulike Windows Server 2008 versjoner:

Komponent

Web Edition

Standard Edition

Enterprise

Datacenter

Certification Authority

Nei

Ja

Ja

Ja

Network Device Enrollment

Nei

Nei

Ja

Ja

Online Reponder

Nei

Nei

Ja

Ja

Web enrollment

Nei

Ja

Ja

Ja

Oversikt over hvilke Certification Authority (CA) komponenter som støttes på Windows Server 2008:

CA egenskap

Web Edition

Standard

Enterprise

Datacenter

Tilpassbare version 2 og version 3 certificate templates

Nei

Nei

Ja

Ja

Arkivering av nøkkel (key archival)

Nei

Nei

Ja

Ja

Rolle separering

Nei

Nei

Ja

Ja

Certificate manager restrictions

Nei

Nei

Ja

Ja

Delegated enrollment agent restrictions

Nei

Nei

Ja

Ja

Administrasjon av Windows Server 2008 PKI

Følgende Microsoft Management Console snapins benyttes til konfigurasjon av AD CS:

  • Certification Authority. Verktøyet for å administrere CA,tilbakekalle sertifikat, og utstede sertifikat.
  • Certificate Templates. Benyttes til å duplisere og konfigurere sertifikat maler som skal publiseres i Active Directory Domain Services (AD DS) og benyttes av enterprise CA.
  • Online Responder. Konfigurering og administrering av Online Certificate Status Protocol (OCSP) responders.
  • Enterprise PKI. Overvåking av flere CA´er, certificate revocation lists (CRLs), og lokasjoner hvor informasjon lagres, slik som authority information. Administrerer også AD CS objekter som er publisert til AD DS.

· Certificates. Benyttes for å se og administrere sertifikater for en maskin, bruker eller tjeneste.

Alle disse snapin´ene kan hentes opp i mmc.exe, og når komponenten er installert på en server, vil du også finne snarveier til verktøyene under Administrative Tools.