Primärt avser ITGI och ISACA med denna publicering att få in allmänhetens kommentarer för att säkerställa en fullständig slutlig version samt säkerställa dokumentkvalité. En kortare enkät finns tillgänglig till och med 31 juli 2011 på ISACA’s hemsida.

Kim Haverblad

Dela med andra:

Presentationen från ovan ISACA aktivitet finns att ladda när här; ISACA Malmö Seminarium - Regelverk, Standarder och Riktlinjer; samt en kortare introduktion om ISACA finns här; ISACA Malmö - Uppstartsmöte.

Kim Haverblad

Dela med andra:

Jag kommer tillsammans med Erik Ravinder ge tips och förslag på hur man kan strukturera det interna säkerhetsarbetet och underlätta vid IT-revisioner. Aktiviteten kommer att genomföras på plats hos SET Revision i Malmö.

För den som är intresserad av att delta går det bra att kontakta mig för anmälan.

Kim Haverblad

Dela med andra:

Att vi får en standard som inte, än så länge, någon mjukvaru producent stödjer, inte ens Microsoft är i sig rätt intressant. Microsoft avser att ha stöd för den nya standarden i Office 14 vilket lär dröja ett tag till innan vi får se denna. Vidare så har man även, än så länge, aviserat från Microsoft att man avser inte att implementera något stöd eller ge ut någon uppdatering för äldre Office versioner.

Bland det positiva är att internationella ISO kommer se över sina rutiner för hanteringen av nya standards, efter förra årets röstfusk och marknadsstöd till de parter som röstade för OOXML har även svenska SIS sett sig tvungna att se över de egna reglerna. Frågan är om OpenOffice med version 3.0 som blir den första kontorsapplikationen med att implementera stöd för OOXML (import), om detta indikeras det när man tittar på OpenOffice funktions wiki.

Sista ordet är dock ej sagt ännu, men mest troligt är att vi har fått en ny standard som delar utvecklare och användare i två läger. Även EUs konkurrenskommissionär Neelie Kroes har indirekt kritiserat Microsoft och sitt genomdrivande av OOXML; knappast något som är till fördel för Microsoft relation till EUs konkurrenskommission.  En annan tydlig markering har Mark Hennessey, IBMs informationschef gjort i en intern rekommendation där han uppmanar anställda att gå över till öppna alternativ som stödjer öppna dokumentformatet ODF. När får vi se denna typ av utspel i Sverige?

Kim Haverblad

Dela med andra:

PCI DSS är en gemensam industri standard som lanserades av American Express, Discover Financial Services, JCB International, MasterCard Worldwide, och Visa Inc för att säkra upp hanteringen av kreditkorts transaktioner. Inte minst kom detta i fokus i samband med att det avslöjades att amerikanska TJX Companies Inc’s förlorade kunddata till 48 miljoner kunder samt information om 455 000 butiker/handlare som var uppkopplat till TJX centrala transaktions system för betal och kreditkorts hantering. Standarden gäller för alla som handskas med betalnings transaktioner för betalkort och kreditkort.

Nu var det i och för sig inte enbart händelsen med TJX Companies Inc’s som tvingade fram standarden då kreditkortsbolagen sedan tidigare haft riktlinjer kring hanteringen av kort transaktioner och hur dessa skall lagras. Dock så synliggjordes behovet av en tydlig standard för samtliga betalnings kanaler; detaljhandel, postorder, telefon samt e-handel.

Vilka är då kraven som PCI DSS ställer på organisationer som hanterar eller är involverad i att leverera tjänster kring själva hanteringen av kort transaktioner? Följande 12 krav har definierats enligt följande:

Konstruktion och underhåll av säkert nätverk;
1. Installera och underhålla en brandväggskonfiguration för att skydda kortinnehavares data
2. Att ej använda tillverkares standard konfiguration för system lösenord och andra säkerhets parameters.

Skyddande av kortinnehavarens data;
3. Skyddande av kortinnehavares data som lagrats.
4. Kryptering av kortinnehavarens data vid överföring över öppna publika nätverk.

Aktiv sårbarhetshantering;
5. Använda och regelbundet uppdatera antivirus mjukvara eller program.
6. Utveckla och underhålla säkra system och applikationer.

Implementering av stark kontroll access åtgärder;
7. Begränsa access till kortinnehavares data baserat enligt affärs behov.
8. Tilldela unikt ID till samtliga individer med dator access.
9. Begränsa fysisk access till kortinnehavare data.

Regelbundet monitorera och testa nätverk;
10. Spåra och övervaka all access till nätverks resurser och kortinnehavare data.
11. Regelbundet testa säkerhetssystem och processer.

Aktivt underhålla en informations säkerhets policy;
12. Underhålla en policy som adresserar informations säkerhet för anställda och underleverantörer.

Utöver ovan krav finns det även tre steg som samtliga handlare och leverantörer måste genomgå för att uppfylla kraven.

Steg 1. Krav på att säkra all insamlad log data och att denna lagras på ett sådant sätt att det ej går att manipulera samt finnas tillgänglig för analys.

Steg 2. Samtliga företag skall kunna bevisa att de uppfyller ställda krav vid en granskning och uppvisa bevis för att det finns kontroller på plats för skydd av data.

Steg 3. Det måste finnas ett kontrollsystem på plats som automatiskt larmar och övervakar access och användning av data samt varnar vid problem och otillåten access av kort och log data för att kunna åtgärda dessa incidenter direkt.

Tydlig dokumentation och bevis måste finnas för att samtliga ovan tre steg utförs på ett korrekt sätt och i enlighet med standarden.

Vidare så gör man även skillnad mellan handlare och tjänsteleverantör av betalningssystem. För handlare finns det fyra olika nivåer som baseras på antalet årliga transaktioner:

Nivå 1: Handlare med mer än 6 miljoner korttransaktioner samt även handlare som tidigare har förlorat kortdata.

Nivå 2: Handlare med 1 till 6 miljoner korttransaktioner.

Nivå 3: Handlare med 20 000 till 1 miljon korttransaktioner.

Nivå 4: Övriga handlare.

Handlare på nivå 1 måste genomföra en årlig säkerhetsgranskning på plats, dessa utförs av s.k. Qualified Security Assessors (QSA), samt genomföra nätverksskanning kvartalsvis. För övriga nivåer är det nog med att fylla i en självdeklaration där man garanterar att man uppfyller de uppsatta kraven i enlighet med standarden. Dock skall det även genomföras skanning av nätverket kvartalsvis av extern godkänd skannings leverantör, en s.k. Approved Scan Vendor (ASV).

För tjänsteleverantörer inklusive underleverantörer av tekniska lösningar för betalningssystem finns det tre nivåer:

Nivå 1: Alla centrala kortinlösens företag.

Nivå 2: Alla tjänsteleverantörer som inte tillhör nivå 1, men med fler än 1 miljon kreditkorts konton eller årliga transaktioner.

Nivå 3: Tjänsteleverantörer som inte tillhör nivå 1, samt med färre än 1 miljon kreditkorts konton eller årliga transaktioner.

För tjänsteleverantörer krävs det att verksamheten överensstämmer med och kan demonstrera att man uppfyller de 12 kraven på hantering av korttransaktioner. Vidare så gäller det för nivå 1 och 2 leverantörer att man klarar av en årlig säkerhets granskning samt kvartalsvis nätverks skanning medan nivå 3 leverantörer kan genomföra årlig självdeklaration samt kvartalsvis skanning av nätverket. Självdeklaration kan genomföras internt av den egna personalen medan nätverksskanning måste utföras av externt godkänd ASV.

När en organisation väl har uppnått kraven för PCI DSS och fått certifikat att man uppfyller kraven gäller det att arbeta vidare med att löpande förbättra interna processer och aktiviteter för hantering av korttransaktioner. Att bli godkänd enligt PCI DSS standarden handlar inte om att få en stämpel och att man därefter kan ta det lugnt och en gång om året påvisa att man uppfyller standarden. Detta är något som är ett löpande arbetsmoment och att man kan påräkna att en granskning kan göras att man uppfyller nämnda krav samt en arbetsprocess som löpande förbättras och förfinas för att inte tappa koncentrationen och därmed inte riskera att kompromettera kortdata och därmed dess innehavare.

Kim Haverblad

Dela med andra:

Man hade hoppats på att ISO hade tagit till sig av kritiken, men inte. På grund av tidsbrist klumpades majoriteten av förändringsförslagen för OOXML ihop till ett stort beslut som sedan utan diskussion accepterades. Är det denna typ av standarder vi vill ha? Det är en sak att OOXML innehåller brister och fel som bör och kan rättas till, men att arbetet kring en standard så totalt kapitulerar är under all kritik.

EU har nu fått upp ögonen efter senaste veckans oförmåga att hantera förslag på förändringar, detta enligt Financial Times. I ett brev till ISO frågar nu EU hur man avser att hantera den kommande röstningen i slutet av mars baserat på att den tidigare röstningen fått massiv kritik runt om i världen.

Under tiden jobbar Microsoft vidare med att få över fler länder på sin Ja lista eller få Nej sägarna att avstå att rösta.

Att det är stora pengar involverade för alla parter råder det ingen tvekan om; Microsoft ser gärna att OOXML godkänns som en ISO till trots att det redan finns en dokument standard – ISO26300 – även kallad Open Document Format (ODF). IBM och Google har inget till övers för OOXML och pekar just på att OOXML har konflikter med existerande standarder som ISO8601 (definition av datum och tid), ISO639 (definition av namn och språk) eller ISO10118-3 (kryptografisk hash).

Att det finns en politisk agenda för huruvida man avser att stödja OOXML eller ej syns även tydligt då båda lägren lägger ner stora resurser på att bevaka sina intressen. Och det är just detta som på senare år har blivit ett tydligt mönster framtagning av standarder, tyvärr. De arbetsgrupper som i grund och botten skall agera opartiskt är sällan det då de uppenbart drivs av en egen agenda. Om det sedan handlar om att verkligen bidra till arbetet för en standard, bevaka sina affärsintressen eller endast för få med sitt namn i slutdokument kan man spekulera kring.

Kim Haverblad

Dela med andra: